The 'Incident Life Cycle'

This is a follow-on post from Introducing Incident Management.

This blog post is going to talk about what ITIL calls the ‘the Incident Life Cycle’. If it sounds complicated it isn’t – and it’s probably something you’ll recognise from your own Incident handling work.

Incident Life Cycle

Incident logging. This is simply where we have reported to us (or detect through automated tools) that an Incident has occurred.

Classification. We classify the Incident, and offer initial support to the customer. At this stage we are looking to get a handle of the business impact of the Incident, assigning a priority and seriousness, and classify the type of Incident.

Investigation, analysis and diagnosis. This is the ‘meat’ of the process, where we try to understand how we can restore service to users. It’s important to note here that resolution of the Incident should not be the only thing that we are considering as outputs – workarounds are useful to users in some cases (for instance, where we see the resolution of the Incident as possibly staking some time).

Resolution. Taking our analysis we resolve the Incident and restore services to users. Note that this may have entailed raise a Change and/or Problem.

Incident Closure. We close the Incident, allocating Cause data and contract codes as appropriate.

What I want to talk about know is something referred to by ITIL as the ‘Workflow Position’ – this is something that confuses some people, but again is really quite straightforward.

Refer to the life cycle above, and consider this. We log and Incident, and at some time in the future we resolve an Incident. In the middle we ‘do stuff’. For example, you might

  • Assign the Incident to a specialist team for assessment
  • Put the Incident on hold, because the Customer has gone on a 3 month holiday
  • Escalate the Incident to a Team Leader

The Workflow Position is simply a signpost about where we are with an Incident. In the ‘Service Support’ book (published by TSO) the following examples are listed:

New, Accepted, Scheduled, Assigned to Specialist, Work in Progress, On Hold, Resolved, Closed

Please note that ITIL is not prescriptive, so these are listed as examples to communicate meaning and foster understanding. It doesn’t mean that is what you must have in order to be ‘ITIL Compliant’ – you are expected, as someone who works in ITSM, to fit this to your particular organisation (and that means extending these with status values that make sense to you).

Workflow Position is useful in Incident Management, and here’s why. It allows you to easily create status reports that tell you where you are with the unresolved Incidents you are currently handling. For example, you might run a status report that says:

Waiting for customer response 12

On hold 6

In progress 30

With external suppliers 10

Awaiting assessment 12

This is more useful than simply saying ’70 Incidents open’ as a status of our current status.

I’ll continue this thread about Incident Management in coming posts.