Problem Management Process

Objective

The primary objectives of the Problem Management process are to prevent problems and resulting incidents from happening, to eliminate recurring events, and to minimize the impact of incidents that cannot be avoided.

Scope

The scope of Problem Management includes root cause analysis of incidents to determine the underlying cause of one or more Incidents and to identify the permanent fix or workaround to those problems. It is also responsible for ensuring that the Resolution is implemented through the appropriate control procedures, such as the Change Management process.

The scope of SoftwareOne Problem Management consists of both reactive and proactive approaches:

Problem Management Policy Statements

1. SoftwareOne support teams shall use the currently approved documented Problem Management process and standardized methodology.

2. All problems must be recorded in ServiceNow.

3. All problems will be reported, recorded, managed, and appropriately communicated.

4. Any activity performed for a problem must be documented in the work notes section of the problem ticket.

5. If a problem is related to an incident, the incident record must be attached to the problem ticket.

6. The Problem Manager will ensure the Problem Management process is followed.

7. The Problem Manager of the specific service/technology will assign appropriate resources to conduct Problem Management activities, such as Root Cause Analysis (RCA), creation of workarounds, and proactive trend analysis.

8. If a Change Request is created to resolve a Problem, the Change ticket shall be attached to the Problem ticket.

9. Any Problem that requires a Change Request to aid in its Resolution can only be closed after successfully implementing the Change Request and validating that no further incidents occur due to the identified error.

10. As soon as the diagnosis is complete, and particularly where a workaround has been found (even though it may not yet be a permanent resolution), a Known Error Record must be raised and placed in the Known Error Database so that if further incidents arise, they can be identified and resolved quickly.

Criteria for raising a Problem ticket

1. Major Incident

2. Detection of recurring incidents by the support team.

3. The support agent might have resolved an incident but has not determined a definitive cause and suspects it will likely reoccur. Hence, we shall raise a Problem ticket to perform root cause analysis.

4. A supplier or contractor is notified of a problem, and an RCA is required.

5. Analysis of events/incidents as part of proactive Problem Management, resulting in the need to raise a Problem ticket.

Process

RACI Matrix: Problem Management

Key:

R=Responsible
A=Accountable
C=Consulted
I=Informed

Root Cause Analysis

What is Root Cause Analysis?

Root Cause Analysis (RCA) is a systematic process for finding and identifying the root cause of a problem or event. RCA aims not only to figure out where the issue came about but also to find a solution to prevent it from happening again.

Purpose of Root Cause Analysis

The primary purpose of Root Cause Analysis is to analyze problems or events to identify:

• What happened

• How it happened

• Why it happened

• Actions for preventing reoccurrence

Root Cause Analysis Model

• Define the Problem.

• Gather information, data, and evidence.

• Identify all issues and events that contributed to the problem.

• Determine root causes.

• Identify the Solution for eliminating or mitigating the reoccurrence of problems or events.

• Implement the identified solution.

Root Cause Analysis techniques

Root Cause Analysis is to identify all and multiple contributing factors to a problem or event. The root cause analysis can be performed through any of the analysis methods.

Many methodologies, approaches, and techniques exist for conducting root cause analysis. Some methods used to conduct RCA include:

• The "5-Whys Analysis" is a simple problem-solving technique that helps users quickly get to the root of the problem. This strategy involves looking at a problem and asking "why" and "what caused the problem." The answer to the first "why" prompts a second "why" and so on, providing the basis for the "5-why" analysis.

• Fish-Bone Diagram or Ishikawa Diagram: Derived from the quality management process, it's an analysis tool that provides a systematic way of looking at effects and the causes that create or contribute to those effects. The diagram design looks much like a fish skeleton, hence the designation "fishbone" diagram.

• Pareto Analysis: Pareto Analysis is a technique used for business decision-making based on the 80/20 rule. It is a decision-making technique that statistically separates a limited number of input factors as having the most significant impact on an outcome, either desirable or undesirable.

Major Problem Review

Upon closure of the Problem ticket, the Problem Manager may conduct a review while memories are still fresh to learn any lessons for the future.

Note: A review may be conducted for a Problem triggered by a Major Incident. It is up to the discretion of the Problem Manager to determine when a Problem Review will be performed.

• A Problem Review is conducted to determine:

• Things that are done correctly

• Things that are done wrong

• What could be done better in the future

• How to prevent a recurrence

Such reviews can be used as part of training and awareness activities for support staff – and any lessons learned should be documented as inappropriate procedures, work instructions or diagnostic scripts, or Known Error Records. The Problem Manager shall facilitate the session and document any agreed actions.

Priority Matrix

Priority Calculator

The priorities are derived from impact and urgency.

Impact Definitions

Urgency Definitions