Incidents Mismanagement - For good and for worst

Incidents… No matter how many projects we run, no matter how many people we task to problem solving, no matter how much money, time, sweat and blood we invest in IT Production, there are always INCIDENTS !

Their management tends to be an end in itself, a core business for many people that (perhaps?) need incidents to justify their jobs, proficiencies, and lives even.

Enough of empty words: perhaps you want to learn something useful here?

Here’s a recurring question: “how d we account incidents” ?

Basically, there are two approaches (who said “that of the IT Production and the good one”?)

1) The IT Production monitors all IT services by itself. It thus can detect incidents, often before the end users. Monthly reports of how many incidents were spotted by the IT Production are then sent to the Client -> that’s a bad approach, because you give numbers irrelevant to the users. This gives the impression that the IT Production is always in a mess. Ok… It’s true most of the time, but still: the end user don’t give a shit about that, this just might be used against you

2) The IT Production lets the end users report service interruptions. Then, it tries frantically to restore the service. At the end of the month, you will have a report of the total number of incidents spotted by your end users (who said “Clients”?). However this is a bad approach, since everybody will blame your lack of anticipation.

Now the “best practice”? You must adopt the “first approach” to manage incidents, and the second to report on incidents… This should minimize the incidents actually impacting the users, and diminish the number of incidents on monthly reports…

Otherwise, there are plenty of “bad practice” tricks to cover-up, makeup and hide incidents… But… Hey… I don’t know them, of course!

Nobody does…

At least, not in our IT Production!