Where Is All The Incident Classification Best Practice?

I recently spoke with a Forrester I&O client looking for “incident classification best practice.” I knew that I should have had knowledge of this, or at least access to it, but all I had was a loose set of guiding principles that are probably more “common sense” rather than “best practice.”  I was happy to talk with the client but wanted to know what I had missed.

Google seemed a great place to start. After all, Googling “ITIL” results in 21 million hits (I do appreciate that not all of these will relate to the IT service management best practice framework though). So I Googled “incident classification best practice” (plus “incident categorization best practice”) and was surprised at the results. Well, the LACK of results. There was no freely available advice or guidance on this subject.

The main reason for my surprise is that, with the wealth of IT service management best (or good) practice out there (especially with ITIL espoused as THE framework of IT service management best practice), this is one area where I definitely think that value could be derived by documenting successes and the pitfalls to avoid.

Given that many organizations adopting ITSM best practice, or ITIL, will start with the service desk and incident management, the creation of a robust incident classification hierarchy is something they will need to do. A similar opportunity also arises when organizations switch between competing ITSM products as part of the well-documented ITSM tool churn. For others it is relevant when the realization sinks in that the existing incident classification hierarchy is cumbersome and ineffective. Incident classification is important, so where is the best practice?

Why is nothing available? Some say that we shouldn’t be prescriptive. I agree, in that one size doesn’t fit all. One could also argue that the creation of an incident classification hierarchy is a good opportunity for ITSM tool vendors and ITSM consultants to log more billable days, but I imagine that there would be better, more productive, opportunities to increase the consultancy/professional service revenue stream than spending so much time “reinventing the wheel” here.

Surely there must have been many opportunities over the last twenty or so years to create a list of incident classification “dos and don’ts”; or a framework, for want of a better phrase, through which an organization can be guided through the incident classification hierarchy setup process to achieve an incident hierarchy. Importantly, one that meets business needs across and beyond the incident management process.

I could gripe on about this, but I’d rather start something positive here. So what is my loose set of principles?

  1. The hierarchy needs to be business not IT driven.
  2. There is an obvious need to make incident capture easy, but this should not be to the detriment of back-end analytical activities such a trend analysis for problem management and continuous improvement, or for reporting and benchmarking.
  3. Categorization should facilitate workflow and the shortening of the incident life cycle.
  4. Try to classify facts not symptoms.
  5. Too many levels of classification impede speed of capture and encourage mis-categorization, particularly with the misuse of “Other.” Three levels of categorization, at a push four, should cover all eventualities.
  6. Consider why you are thinking of more than 10 level-one categories. Surely 10 are enough? Same for the other levels.
  7. There should be minimal use of “Other” pots; some would argue that there should only be one route to “unknown.” Going through three levels of classification to log an incident as “Other” seems futile.
  8. There should be strict rules as to what should go where. It seems obvious, but redundancy should be avoided.
  9. Don’t allow the addition of incident categories on the fly.
  10. Closure codes can add value. In particular is assessing the accuracy of incident capture and resolution routing.
  11. Finally, try to rise above internal politics, and individual opinions, to create something that services many needs.

I would love to hear your thoughts on this but please remember that this is just a quickly written blog not a “three-year academic initiative to find the optimal incident classification hierarchy.”


Please check out my latest blog ... http://blogs.forrester.com/stephen_mann


incident categorization

I think incident categorization is the most challenging part of this process when it comes to defining it. We regularly face 2 cases for categorization:
- customers that don't use business services and CIs in their incident > the result is that the categorization is a replacement of these 2 concepts and therefore the customer builds a complex category structure (hence the 'mistake' we see a lot about many levels of categories etc). Reality is that without business services and CIs identified in the incident, this is the only suitable solution
- customers that use business services and CI in their incident > then, yes, I fully agree with your post. This is where a light and efficient categorization can take place, because it's combined with 2 new dimensions like business service (the service impacted, communicated by the customer) and the configuration item (the technical/logical component affecting the incident). Having these 2 dimensions available, the categorization takes a new complementary logic.
One advise I give to my customers is that any category should be applicable in principle with any service/CI.


Great start of all the different aspects to think about for classification. (For classification is comprised of several categorization fields) What I find in practice that we do not understand why we are using categorization. If we understand the objective of categorization fields then it becomes easier. In my opinion some categorization fields are used for reporting purposes. In that case you need to have categorization that helps you in reporting about Incidents (linked to your goals, CSFs and KPIs). The categorization field now has a clear goal and it makes it easier to come up with a hierarchy.
If I am interested in amount of incidents with certain symptoms I would have symptoms in the category. If I am more interested in the amount of incidents that created certain actions I would put that in the category.
Next to the reporting category I would still use a product / service category (as part of the overall classification set)
For monitoring and tracking purposes you can have a different set of categorization fields. Again it has a different goal.

When you setup the classification of the incident, you will end up with different category tables.

and of course what drives this? What the customer requires you to do.

just my initial thoughts on this... :-) this could/should be an article...

"One could also argue that

"One could also argue that the creation of an incident classification hierarchy is a good opportunity for ITSM tool vendors and ITSM consultants to log more billable days"

If there are still software solutions out there that require the vendor to create codes for incident categories, then I would suggest that the business needs to update their software and get out of the 90's. However it is surprising the number of businesses out there that have made a meal out of their incident classification hierarchies. Too many top levels redundancies can lead to duplication and other anti-data practices.

Nothing new

Fully agree with your blog Stephen and the feedback on the reasons (lack of CIs, Problem Mgt, and Closure Codes are top of my hit list) and that essentially is the problem. We all know this, but it fails to be implemented and/or maintained. Maybe, as an ITSM community (me included), we are failing to demonstrate the value of the categorisation and ensuring that the contents of categorisation are put under strict Change Control to ensure continuity? Following on from Peters comment, in my view key process information, such as categorisation should be treated as a Service Asset and not just a data list. It can fundamentally affect the efficiency of the process and has value if you understand what you're trying to achieve with it.