Assessment Criteria for Incident and Problem Management

We will soon begin our review of Incident and Problem Management offerings in the ITSM market place. As with our previous comparison of REQUEST FULFILMENT – Our goal is to highlight the key strengths, competitive differentiators and innovation in the industry.

During Request Fulfilment our original aim was to look at how the tool supported the process, but refreshingly vendors who participated also shared their experiences and some insight into their consulting approaches.

When assessing the bread-and-butter elements of Incident Management, the challenge will be to identify be true differentiators in a discipline that is quite rigid.

We would like to encourage the same philosophy of identifying how deployment experiences have shaped the evolution of tools.

Incorporating Incident & Problem Management for a review

From my experience, deployments often implement Request Fulfilment, and Incident Management in the early phases of projects, but often Problem Management is left until later phases.

Yet the two processes, in tool terms are often linked together – quite often the record functionality and layout is the same for Incident, Problem (and Request for that matter).

My assessment criteria for the Incident and Problem Management review are below, if you have any comments or recommendations please contact us.

Suggested Criteria for Incident & Problem Management

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?

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 and problem 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/problem 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?


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

But there can be a lot more to tracking these records 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” a record may face if wrongly assigned?

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/problem and its linkage to other processes.

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


  • How are priorities determined and managed (out-of-the-box)?
  • What happens when the priority is adjusted during the lifecycle of the incident/problem?
  • We would like to also give vendors an opportunity to show us how they link SLAs to 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/problem has NOT been resolved satisfactorily
  • Demonstrate integration between incident and other processes

Major Incidents and Problems

Much like categorisation, this can be very simple, or can be made so complex, and more time can be spent negotiating the process than fixing the issue in the first place.

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

Incident & Problem 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 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 Models, and we want to see how tools help in this aspect.

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

Incident & Problem Closure

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

  • Show how an incident/problem 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.

But more importantly, Problem Management is often left to later phases, while organisations focus on processes like Request Fulfilment, Incident and Change – perhaps there is a case to make for implementing them hand in hand?

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.