The IT Skeptic is at it again: this time trying to explain why ITIL has made a mistake with the definition of Incident and Problem. According to ITIL, an incident is “an unplanned interruption to a service, or the failure of a component of a service that hasn’t yet impacted service”. This is the beginning of the IT Skeptic’s difficulty with the definition. Incident management should only be concerned with restoring service to normality; so if there is a “failure of a component of a service that hasn’t yet impacted service”, why does incident management get involved? Wouldn’t service already be normal (hence no impact)? Furthermore a Problem is defined as “a cause of one or more incidents”, and that Problem management proactively prevents incidents. This is what is most confusing: Clearly, in order for proactive Problem Management to even exist, the definition of a Problem should be the cause or potential cause of zero or more Incidents. A failed service component is a Problem that will potentially cause Incidents. How it ever got dumped in the Incident definition is beyond me. My suspicion is that in many organisations Incident Management behaves with urgency and Problem Management doesn’t, and that was why “failed component” got called an incident. It’s a dumb reason but I can’t think of a more plausible one. So what’s the solution? Redefine incident management and problem management, of course. The IT Skeptic provides the following new definitions:
- Incident: a user reporting an unplanned interruption to a service
- Problem: a cause or potential cause of incidents
- Problem Management: to remove problems
- Incident Management: identifies cause or suspected cause of incident, creates problem record, restores service to users, prioritizes problems
While ITIL isn’t likely to take the IT Skeptic’s changes into account for the next version, he does point to some very important questions around the definitions and confusions that occur with those who want to truly implement ITIL in their organizations.