Quality of the ITIL® documentation

Many people in the IT service management industry refer to the ITIL® documentation as being the bible of IT service management. To dissapoint all of you, it is not. If it would be sent down from heaven it would be unquestionable and would never contain any errors. To criticize one part of the serivce operations book, I would like to pick on the problem management process. If done right, this process will start a continous improvement, since it focuses an organization on improving instead of blaming.

Let us first have a look at the problem management graph as shown on page 60 of the service operations book.

The graph shows us how to handle a problem, when to create a known error and what to do with workarounds as well as when we should have a review. Usually the ITIL® processes are well thought of and taken from practice. But this graph is plain wrong and can be improved greatly.

1. Workaround? seems to be a decision. Do you see what is decided here? The decision form just has one exit and this exit is not annotated. So no matter if we have a workaround or not, the flow will go to Create KnownError Record.
2. The step Create KnownError Record immediatly follows the decision about workarounds. A problem becomes a known error when the cause is known. This is not the same as having a workaround.
3. After the known error is created, we find the decision Change Needed?. Yes, this is a decision, but is this important at this stage? Do we already know how we want to resolve the problem? Most problems can be resolved by using different strategies so we need to decide on how to resolve the problem before we know if we need change management.
4. Resolution has an unconditional exit going up again to Investigation & Diagnosis and to Workaround? and maybe even to Create Known Error Record. This would create an endless loop with increasing parallel activities. What is it, the two Davids want to tell us here? If the Resolution fails, we need to go back and analyse? Well, they should have used a decision and a single return point.

Next time, I will post a flow which will cover all the aspects of problem management in a much simpler and more clean chart.