Learning about Problem Management

Review incident requests

The Problem Management process usually begins with an incident request review, which the problem coordinator performs at regularly scheduled intervals. During the review, the problem coordinator analyzes the incident request information to identify the problems with the services they are responsible for.

Create the problem investigation

If a problem investigation already exists for an incident request, the problem coordinator relate that incident request to the existing problem investigation. When a new problem is identified, the problem coordinator creates a problem investigation and relates it to the corresponding incident requests. The problem coordinator then assigns the problem investigation to a specialist who has the appropriate combination of skills, availability, and access rights to perform a root cause analysis.

Problem investigations can also be triggered by other processes. For example, a service desk specialist can create a problem investigation if they think that an incident request was caused by an underlying problem. Emergency changes as well as periodic availability management and capacity management reviews can also trigger problem investigations. 

Perform a root-cause analysis

When a problem investigation is assigned to a specialist for root cause analysis, the specialist looks for a temporary workaround to restore the affected service. If the specialist implements a workaround, they add information about it to the problem investigation record. This helps other specialists resolve future incidents caused by the problem until a permanent or structural solution is implemented. Next, the specialist looks for the root cause of the problem. The specialist can also create a known error related to the problem investigation. If the specialist finds a root cause, they update the problem investigation with information about the root cause, workaround, and resolution.

Identify changes

If the specialist thinks that a change is required to remove the root cause or to enable a workaround, they inform the problem coordinator that the change coordinator must be included in the analysis. Otherwise, the specialist implements the preferred structural solution. If the specialist cannot find the root cause or cannot propose a structural solution, the specialist adds the reason to the problem investigation record. Regardless of whether a structural solution is proposed or implemented, the specialist informs the problem coordinator when the root cause analysis is completed. 

Close or reassign problem investigations

After the root cause analysis is completed, the problem coordinator reviews the analysis. If the coordinator is unsatisfied with the root cause analysis, the coordinator reassigns the problem investigation for further analysis. If the problem is resolved, the problem coordinator closes the problem investigation. During closure, the problem coordinator performs a final assessment of the problem investigation. If the problem coordinator is satisfied that the root cause of the problem has been permanently removed, the coordinator closes the problem investigation. If the root cause analysis concluded that no permanent workaround or solution to the root cause exists, and the problem coordinator agrees, the problem coordinator indicates that the problem investigation is at an impasse. This indication leaves the investigation open for periodic review in the event that an appropriate solution becomes available in the future. If, however, the resolution did not remove the root cause, or if the problem coordinator thinks that an appropriate solution is available, the problem coordinator reassigns the problem investigation for further analysis.

The problem investigator also closes the investigation if the specialist performed a sound analysis but could not propose a structural solution. If the specialist did propose a structural solution but did not implement it because the specialist believes that a change is required, the problem coordinator must confirm that the change is required. If a change is required, the problem coordinator generates a known error and passes it to the change coordinator of the affected service. This action starts the Change Management process. Later, after the change is implemented, the change coordinator reassigns the known error to the problem coordinator for closure.

Known errors can also be generated during the release management process. Known errors are also assigned to the problem coordinator for closure.