Tuesday, October 27, 2009

Close Incident when Problem raised?

What's the relationship between Incident closure and Problem creation? One school of thought, reported by Juan Jimenez is that

(A) Incident ALWAYS ends when Problem raised.

This is apparently favoured by Management who are keen to show the best possible SLA statistics - so they grasp any possible excuse to close an Incident, even if the service disruption has not yet ended. "Why would you want to keep 2 tickets open?", they might reason. "The Incident has been evaluated and the cause is understood - Incident Management can take a back seat and let Problem Management deal with it." Clearly this is for expediency, not logical thinking. Or maybe it's just that these people work in a world where Incidents and Problems cannot coexist, e.g. because an inadequate ServiceDesk tool uses a single record type for both things, treating 'Problem' as a status in the lifecycle of a ticket which may start off life at an 'Incident' status.

Juan presents an alternative view, that

(B) Incident ALWAYS ends only when Problem ends.

Juan's reasoning seems to be as follows: ITIL documents that Problem closure can include closing any Incidents that were caused by the Problem. Therefore the Incidents must still be open.

Maybe I could agree with this, depending on what you mean by 'open'. The Incident, i.e. the service degradation, may have ended (perhaps by itself, or via the use of a workaround) but the Incident Record may still be held open, so that it can still be worked on in some way - e.g. preventative measures are being worked on. But I don't agree with that thinking. The Incident is over when the Incident is over. Abstracting the Incident record from the Incident itself for administrative purposes is just confusing. We can avoid such confusion by managing the resultant work (e.g. preventative measures) via Problems and/or RFCs.

What I'm saying is that Incidents' and Problems' respective closure dates are not consistently related. I'm saying sometimes it will be A and sometimes B, and sometimes something else, depending on whether and when a workaround brings the end user Service back to normal. Sometimes, even, the Incident will stay open long after the root cause Problem has been corrected, because an RFC is required to rectify some of the damage that had been caused.

Incidents and Problems are different animals with lives of their own, coexisting also with Events, Workarounds and RFCs, and they will often be related, but they won't always start and end in any particular order.

1 comment:

  1. I'm with you. Sometimes an incident closes before the problem does, if the user is agreeable (contrary to what Juan suggests), and often a problem is opened well before an incident is closed (contrary to what ITIL V3 implies, though it is hopelessly muddy on the relationship between the two).

    ReplyDelete