I am yet to see any convincing explanation on why ITIL V3 has done away with the concepts of ‘Problem Control’ and ‘Error Control’ – the two parts of the Problem management process that used to be there in V2.

  • If this was not required/ if that is not a best (good) practice, why was that in V2?( I believe there is a value in subdividing the process into those two stages, which I will explain in a short while)
  • Was it, in any way causing any sort of issues in implementing and following Problem management?
  • Is there a real value in making Problem management one consolidate process flow, as it is in V3? (In other words, is this a better practice, compared to the concept of having Problem and Error Control?)

Why are we concerned with this removal?

I used to find the earlier concept of Problem and Error Control a very logical one. Here are some of my arguments in support of  such a subdivision into two stages:

 

  1. When the organization is starting with some thing ‘unknown’ (problem), there might be an obvious need (in most cases) for cross-functional teams to analyze the same and arrive at a root cause. (You never really know if the cause is hardware, software, network, environmental, human errors or anything else). So Problem control can involve such a team/group. Once the root cause is identified, the domain of the cause is narrowed into – hence the specialists in that domain can work on resolving that cause permanently using Error Control.
  2. As even ITIL V3 points out, there might not be a business case for Problem resolution in many cases (for example, where the cost of problem resolution is not justified) – but it is important to diagnose the cause and create a known error. This would mean (if we follow the two-staged approach)- Problem control is completed, and Error control is not taken up. In other words, the objective of Problem management looked very logically in two parts: “Diagnose the problem to the root cause” (Problem control) and then if there is a business case, “resolve the same permanently” (error control).
  3. If the Known errors are diagnosed/made available by other processes – may be from Development, from the vendor, Incident management etc- , it is a good practice to document those into the known error database. As per the two-staged approach, Problem management could have just initiated ‘Error Control’ activities, to permanently resolve that known error. Does the current flow indicate that problem management has to again do the diagnosis, if that error need to be resolved? Or can it trigger the solution (not clear!).

One of the reason that might have triggered this change in V3 could be, the new idea that ‘ in some cases, it might be advantageous to raise a known error even before the whole diagnosis is over’.

I am not able to get any other valid reason for this change – and would really welcome any inputs in this regard…