Assessment Criteria for Incident Management

Our Request Fulfilment assessments have concluded. The full analysis will be published very shortly. Digging into Request Fulfilment have revealed some interesting elements!

The original aim was to look at how the tools supported the process. Rather refreshingly, the vendors who participated also shared their experiences and some insight into their consulting approaches.

We now turn our attention to the bread-and-butter elements of Incident Management. Our challenge is to identify the true differentiators in a rigid discipline.

Suggested Criteria

Overall Alignment

  • Have our target vendors aligned to ITIL and if so, to which version?
  • How do the set up roles and users to perform functions?
  • What demo capabilities can they offer potential customers?

Incident Logging & Categorisation

These can either be made simple, and to great effect, or made so complex, that they become irrelevant as the Service Desk totally ignore them and pick the first thing on the list!

  • What information is made mandatory on the Incident record?
  • What categories and/or sub-categories are provided out-of-the-box?
  • How easy is it to customise these fields and values?
  • Show us how Incident Matching and linkage to known errors are presented to users and/or service staff to expedite the process
  • How much administration is needed to do bespoke changes?

Incident Tracking

“Oh come on now,” I hear you cry, “What tool cannot track incidents?”

But there can be a lot more to tracking the humble incident than meets the eye:

  • What statuses are included out-of-the-box and how easy is it to add/modify status definitions to suit customer requirements
  • Can your tool show how many “hops” an incident may face if wrongly assigned?

Incident Lifecycle Tracking

Perhaps the best way of allowing vendors to show off their tool’s capabilities is for them to really go to town in terms of playing out scenarios.

The aim of this assessment is to look at how tools can help keep communication going during the lifecycle of an incident.

  • First time Fix from the Service Desk
  • Resolved via support group(s)
  • Demonstrating visibility of the incident through its lifecycle, from  end-user, Service Desk and support group(s) points of view

Prioritising Incidents

  • How are priorities determined and managed (out-of-the-box)
  • What happens when the priority is adjusted during the lifecycle of the Incident
  • We would like to also give vendors an opportunity to show us how they link SLAs to Incidents

Escalating Incidents

  • Demonstrate routing to multiple groups
  • Show the tool’s capability for handling SLA breaches – in terms of notifications and the effect on the Incident record during that time
  • Show us what happens when an Incident has NOT been resolved satisfactorily
  • Demonstrate integration between Incident and other processes (the most obvious being Problem and Change Management)

Major Incident

Much like categorisation, this can be very simple, or can be made so complex, more time can be spent negotiating the process than fixing the major incident!

  • Provide and end-to-end scenario to demonstrate how the tool handles the management and co-ordination across multiple groups for a Major Incident.

Incident Models

All of the above criteria are what I consider the basics of an ITSM tool.

But I am keen to delve deeper into what vendors understand by the concept of Incident Models.

In turn, how can their tools add significant value in this area?

There are several ways of looking at this concept (there will be no points for throwing it over the fence to Problem Management and focussing on Known Errors).

There are assessment criteria around the handling of Incident Models, and we want to see how tools help in this aspect.

  • Demonstrate how your tool facilitates the use of Incident Models (include if/where links to other relevant processes/support groups as part of the demonstration).

Incident Closure

It makes sense to end our list of assessment criteria examining how tools resolve and/or close incidents by default.

  • Show how an incident is routed for closure.

This assessment will be quite scenario heavy, and we want to give participating vendors the freedom to develop their scenarios without limiting them to defined parameters (for example, specifying which service has failed, or which groups to use).

A key part of the assessment will also include how flexible the tool is with regards to customisation.

Incident Management can sometimes be taken for granted, so we would like participating vendors to really take a look at how Incident Management can made “everyone’s” business.

What is your view, what have we missed?

Please leave a comment below or contact us. Similarly if you are a vendor and would like to be included in our review please contact us. Thanks, Ros.

2 thoughts on “Assessment Criteria for Incident Management”

Comments are closed.