Conducting a root cause investigation on a 3rd party

Every Incident record has a Problem record

It's possible to argue that incident and problem records are simple artefacts of the way in which any organisation has chosen to implement their incident and problem processes; nevertheless, there's no simple getting away from the reality that every (ITIL Definition) Incident has an underlying (ITIL Definition) Problem.

To clarify: I agree with the Skeptic. Every Incident record requires a corresponding Problem record.

Those who have difficulty determining what should be logged and when are confused and haven't separated the processes sufficiently to understand the points of interface between them. Incident records are managed by Incident management. Problem records are managed by Problem management.

Every time an incident is resolved successfully, a solution is applied. If that solution is a new one which the support staff have generated spontaneously, it requires analysis to determine if, for example, the solution is temporary (a workaround) or permanent. In other words, do we have a resolved problem or a known error? The solution may need to be examined for cost, practicality and potential unintended consequences.

The task of performing that analysis falls to problem management and the responsibility for maintaining that solution, determining the impact of the ongoing incidents which arise from this problem and justifying the resources necessary to investigate and implement a more permanent solution also rests with them.

Technical staff document their diagnostics and attempts to resolve the incident in the original record. The incident record is a record of the progression of the incident process. In other words, the management of the symptoms of the incident. The problem record is a record of the progression of the problem process. In other words the management of the underlying root cause of the incident.

Thus, Problem records are solely created, updated and maintained by the Problem Management team. That team is responsible for sifting through the original incident record to determine the salient facts which are fed into the analytical (Kepner-Tregoe etc..) stage. In extreme cases, the Problem management team may have to sift through dozens, hundreds or thousands of instances of these incidents to extract the data required.,

Now, while every incident requires a corresponding Problem record, it does not require a corresponding UNIQUE problem record. Incidents which are clear repetitions of an earlier incident merely need to be linked to the original Problem record.

Once you shift your thinking from wading through a morass of incidents to simply linking Incident and Problem records together, the reporting which becomes available allows you to clearly demonstrate which Problems are causing you the most pain.

A few final points:

* Incidents without a Problem record cannot be closed. This enforces the following-

* Resolved incidents which have no corresponding problem record should be routed to Problem Management who will create a Known Error.

* Unresolvable incidents become open Problem records. If an incident cannot be resolved at all, this information is relevant to the urgency of the Problem. A problem record linked to 1,000 unresolved incidents which continue to impact customers will gain rapid attention as the "minutes of impact" metric climbs.