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.”