ITIL Problem Management Workflow - Process Guide

Problem Management
PROBLEM MANAGEMENT
(PM)
Process guide
Author Name
[E-Mail-Adresse]
2017
text

Problem Management
Table of Content
TABLE OF CONTENT.................................................................................................................3
1. INTRODUCTION.................................................................................................................5
2. KEY DEFINITIONS .............................................................................................................6
3. PURPOSE AND OBJECTIVES...............................................................................................9
4. SCOPE..............................................................................................................................10
5. POLICIES.........................................................................................................................11
6. TRIGGERS, INPUTS, OUTPUTS.........................................................................................14
7. PROCESS FLOW ...............................................................................................................16
8. ROLES AND RESPONSIBILITIES......................................................................................29
9. RACI MATRIX ..................................................................................................................33
10. CSF AND KPI ..................................................................................................................36
11. ROLE ASSIGNMENT........................................................................................................40
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/itil-problem-management-workflow-process-guide-3021

Problem Management
1. Introduction
Problem is a cause of one or more incidents.
Problem management process manages the lifecycle of all problems, from first identification through
investigation and documentation to eventual removal. Problem management seeks to minimize the
adverse impacts of incidents and problems and to proactively prevent any recurrence of such incidents.
Ultimately it is about seeking the root cause of incidents and problems and initiating actions to rectify or
improve the situation.
Problems are categorized in a similar way to incidents, but the goal is to understand causes, document
workarounds and request changes that permanently resolve the problems.
Workarounds are documented in a known error database.

Problem Management
Key definitions
of the configuration management system, or may be stored
elsewhere in the service knowledge management system.
Problem Record
A record containing the details of a problem. Each problem
record documents the lifecycle of a single problem.
Known Error
Record
A record containing the details of a known error. Each known
error record documents the lifecycle of a known error, including
the status, root cause and workaround. In some
implementations, a known error is documented using additional
fields in a problem record.
Workaround
A temporary solution to a problem. Provides the ability to
restore service for the customer, potentially through alternative
delivery means (e.g. print on a different printer).
Reducing or eliminating the impact of an incident or problem for
which a full resolution is not yet available – for example, by
restarting a failed configuration item. Workarounds for problems
are documented in known error records. Workarounds for
incidents that do not have associated problem records are
documented in the incident record.

Problem Management
3. Purpose and Objectives
Problem management seeks to minimize the adverse impacts of incidents and problems and to
proactively prevent any recurrence of such incidents by seeking the root cause of incidents and problems
and initiating actions to rectify or improve the situation.
The primary objectives of Problem Management are:
• to prevent problems and resulting incidents from happening,
• to eliminate recurring incidents
• to minimize the impact of incidents that cannot be prevented.
Problem Management includes the activities required to diagnose the root cause of incidents and to
determine the resolution to those problems. It is also responsible for ensuring that the resolution is
implemented through the appropriate control procedures, especially Change Management and Release
Management.
Problem Management will also maintain information about problems and the appropriate workarounds
and resolutions, so that the organization is able to reduce the number and impact of incidents over time.
In this respect, Problem Management has a strong interface with Knowledge Management, and tools
such as the Known Error Database will be used for both.

Problem Management
5.Policies
Policies are guidelines that drive the process or procedures. Following are the Problem Management
process policies:
Policies Problem Management Process
Policy 1
Service ownership
exists for all
services.
Service Ownership is a critical component to
assuring the quality of services provided by IT. The
Service Owner must be designated for each service
to be managed by the Problem Management
process. The Service Owner works to ensure that
any Problem that may impact their service is
controlled.
Policy 2
Updated Problem
records
Each person who works on a problem will be
responsible for updating the Problem record and
Problem status on an ongoing basis.
Policy 3
Major Problems A major Problem is declared when the degree of
impact on the user community is high. The Major
Problem procedure will be followed for these
problems.

Problem Management
Policies Problem Management Process
for Problem
Management.
requirements will be based on the scope of the
problem. Resources from the business and
technical analyst teams will be required.
Policy 10
Service ownership
exists for all
services.
Service Ownership is a critical component to
assuring the quality of services provided by IT. The
Service Owner must be designated for each service
to be managed by the Problem Management
process. The Service Owner works to ensure that
any Problem that may impact their service is
controlled.
Policy 11
Updated Problem
records
Each person who works on a problem will be
responsible for updating the Problem record and
Problem status on an ongoing basis.

Problem Management
Triggers, Inputs, Outputs
Inputs
• Incident records for incidents that have triggered problem
management activities
• Incident reports and histories that will be used to support proactive
problem trending
• Information about Configuration Items (CIs) and their status
• Communication and feedback about incidents and their symptoms
• Communication and feedback about Requests for Change (RFCs) and
releases that have been implemented or planned for implementation
• Communication of events that were triggered from event management
• Operational and service level objectives
• Customer feedback on success of problem resolution activities and
overall quality of problem management activities
• Agreed criteria for prioritizing and escalating problems
• Output from risk management and risk assessment activities
Outputs
• Resolved problems and actions taken to achieve their resolution
• Updated problem management records with accurate problem detail
and history RFCs to remove errors
• Workarounds for incidents
• Known error records
• Problem management reports
• Output and improvement recommendations from major problem review
activity.

Problem Management
Problem Management
Initiator/
Requestor
Problem Analyst
Problem Manager, Problem Coordinator &
Problem solving functions
Other
Processes
End
Functional escalation
needed?
13. Problem Closure
Major Problem ?
yes
yes
9. Problem
Investigation and
Diagnosis
8. Functional
Escalation and
Assignment
12. Problem
Resolution
1. Problem
Detection
no
4. Problem Logging
Major Problem
Review
ServiceDesk
Quality Assurance
Incident
Management
Supplier or
Contractor
5. Problem
Categorization
6. Problem
Prioritization
RaiseKnown
Error record?
11. Create Known
Error record
Problem
Resolved?
no
Knowledge
Management
Quality
Assurance
Change needed?
Change
Management
Start
Workaround
needed?
10. Implement
Workaround
Incident
Management
yes
yes
yes
yes
no
no
no
no
Meeting
criteria for
investigation?
3. Return to
requestor
Root Cause
known?
no
yes
yes
no
7. Assign Problem
2.Assess Problem for
consideration

Problem Management
NR. STEP DESCRIPTION ACTIVITIES IN DETAIL
Problem Manager may choose to obtain input
from a Quality Management or some other
Steering Committee that can assist in
committing resources. (Until PM is fully
implemented and embraced in an organization,
personal judgment is required in identifying the
problems to be addressed.)
Meets criteria
for
investigation?
Meets Criteria? If the problem meets the
criteria for continued investigation, move on to
step 4. Problem Logging otherwise move to step
3. Return to requestor.
3. Return to
requestor
Notify requestor with rationale that problem
doesn´t meet criteria for investigation and go to
Problem closure.
4. Problem
Logging
Associate Problem with other relevant
records: Make sure to associate all relevant
records such as incidents that caused it, Known
Errors to which it might relate etc.
Log all relevant Problem data: Include all
relevant details, including but not limited to:
• User details
• Problem details including service
impacts, incident affects etc.
• Equipment details
• Priority and categorization
• Associated Incidents
• Details of all diagnostic or attempted
recovery actions taken, for problem
team consideration to create as a formal
KM record
• Description of how the problem met the
criteria to become a recognized problem.

Problem Management
8. Functional
escalation &
assignment
Accept and take ownership of the
Problem: The Problem Coordinator receives
the problem record and accepts ownership.
Identify required skill sets for problem
resolution team & obtain commitment:
The Problem Coordinator determines who else
is required to participate as part of the
resolution team. The Problem Coordinator,
along with the Problem Analysts identified are
the core problem resolution team and Subject
Matter Experts (SMEs) can be called upon as
needed to provide expertise during the
investigation and resolution stage. Assignees
update the tasks as their investigation activities
continue. The problem coordinator updates the
problem task when/if required.
Resources Secured? The Problem
Coordinator seeks the required individual
involvement and if successful the problem can
continue on to the Investigation stage. If the
Problem Coordinator is not successful in
obtaining the resources, the Problem
Coordinator may need to work with the Problem
Manager to escalate within the organization.
Work to obtain necessary resource
involvement: The Problem Coordinator and
Problem Manager may need to consider
alternatives if desired resources are unavailable.
(For example, they may seek alternate SMEs,
delay investigative activities, escalate to senior
management, etc.)
Functional or
hierarchic
escalation
needed?
Appropriately
escalating if
needed.
• Functional escalation needed: As soon
as it becomes clear that current functional
group is unable to resolve the incident itself
(or when target times for resolution have
been exceeded – whichever comes first),
the incident must be immediately escalated
for further support.

Problem Management
Proceed with investigation? At any point in
the process it may be determined that further
investigation is not required. This decision is
made by the Problem Coordinator in
consultation with a variety of stakeholders
including the Service Owner, SMEs, etc. It may
be determined that the effort involved in further
investigation does not out-weigh the benefit
from resolving the problem. If the decision is
made to NOT proceed with problem activities, it
must be clearly noted in the problem record.
Workaround
needed?
10. Implement
Workaround
Document Workaround and submit for
authorization:
Upon identifying a workaround, the problem
resolution team documents the workaround for
use by Service Desk and potentially by end
users. In cases where a workaround is found, it
is vital that the problem record remains open
and that details of the workaround are always
documented within the problem record.
Accurate and complete information on the
workaround is documented in a Known Error
Database
Authorize Workaround: The Problem
Coordinator, who is ultimately responsible for
the resolution of the problem, authorizes the
workaround or engages appropriate
authorization body.
Deploy Workaround: Upon adequate
authorization, the workaround is deployed to the
appropriate levels in the organization.

Problem Management
and will help to form the case towards a
resolution.
Approve Known Error: The Problem
Coordinator, who is ultimately responsible for
the resolution of the problem, approves the
known error.
Update Knowledge Record and make
available to Service Desk: Upon approval,
the known error workaround is deployed to the
appropriate levels in the organization.
Change
needed?
Ideally, as soon as a solution has been found, it
should be applied to resolve the problem – but
in reality safeguards may be needed to ensure
that this does not cause further difficulties. If
any change in functionality is required this will
require an RFC to be raised and approved before
the resolution can be applied. If the problem is
very serious and an urgent fix is needed for
business reasons, then an Emergency RFC
should be handled by the Emergency Change
Advisory Board (ECAB). Otherwise, the RFC
should follow the established Change
Management process for that type of change –
and the resolution should be applied only when
the change has been approved and scheduled
for release. In the meantime, the KEDB should
be used to help resolve quickly any further
occurrences of the incidents/problems that
occur.
12. Problem
resolution
Work to resolve problem: The problem
resolution team works to identify temporary or
permanent solutions or potentially alternatives
to be considered by the Service Owner. The
solution alternatives and options should be
documented so the Service Owner has all the

Problem Management
Note: There may be some problems for which a
Business Case for resolution cannot be justified
(e.g. where the impact is limited but the cost of
resolution would be extremely high). In such
cases a decision may be taken to leave the
Problem Record open but to use a workaround
description in the Known Error Record to detect
and resolve any recurrences quickly. Care
should be taken to use the appropriate code to
flag the open Problem Record so that it does not
count against the performance of the team
performing the process and so that
unauthorized rework does not take place.
Problem
resolved?
13. Problem
closure
Update Problem Record with sufficient
coding & detail: Once the Problem has been
resolved or it has been decided that problem
activities are to not continue, the problem
record is closed. Note: This requires an
opportunity to confirm that the problem has
truly been addressed through the change, and
may require an extended timeframe to validate.
Part of closing the problem record is to ensure
all approvals are documented, the coding is
accurate, and rationale for decisions is
documented.
Major
Problem?
Once the problem has been officially closed, if it
is a Major Problem, it requires a Major Problem
Review.
Major
Problem
Review
Perform Major Problem Review: It is
important to review the lifecycle of any Major
Problems. Major Problems are those that have

Problem Management
8.Roles and responsibilities
The following roles have been identified within the Problem Management Process:
Roles and responsibilities
Problem Management
Process Manager
Responsibility for every day execution of the Problem
Management process in the organization and all process outputs.
• Oversee day to day process execution
• Drive the efficiency and effectiveness of the PM process.
• Produce management information.
• Monitor the effectiveness of PM and make recommendations
for improvement.
• Develop and maintain the PM systems.
• Managing the work of problem solving functions
• Manages major problems until the appropriate problem owner
is identified
• Developing and maintaining the problem management
process and procedures.
• Coordinating interfaces between problem management and
other service management processes
• Ownership and maintenance of the KEDB

Problem Management
Roles and responsibilities
• Answer questions as needed
• Confirm resolution
Problem Analyst • Receives Problem notification from Initiator
• Determines IT Services and CI’s affected
• Associates Problem with relevant records
• Logging relevant problem data
• Analyzes symptoms
• Assesses problems for consideration
• Categorizes and prioritizes the problem
• Assigns the Problem to appropriate Problem Coordinator
• Selects the appropriate SMEs (Subject Metter Experts) who
will respond to the Problem tickets. If a Known Error and
matching Workaround exist, a decision should be made
about whether this Workaround should be employed to
resolve the Incident/Problem at this time.
Problem coordinator
• Coordinates SMEs
• Monitors resolution progress and escalates if needed
• Observes the implementation of the Request for Change
and receive information on the outcome via the Release
Management process
Problem solving
functions
The actual solving of problems is undertaken by one or
more support groups and/or suppliers or support
contractors. These may include support resources who

Problem Management
9. RACI Matrix
RACI authority matrix is used for indicating roles and responsibilities in relation to processes and
activities. RACI is an acronym for the four main roles of:
• R- Responsible The person or people responsible for correct execution – for getting the job
done
• A - Accountable The role who has ownership of quality and the end result. Only one person can
be accountable for each task
• C - Consulted The people who are consulted and whose opinions are sought. They have
involvement through input of knowledge and information.
• I - Informed The people who are kept up to date on progress. They receive information about
process execution and quality.

Problem Management
Nr. Initiator Problem
Analyst
Problem
Manager
Problem
Coordinator
Problem
solving
functions
/SMEs
Problem
Management
process
owner
Change
needed?
A R
12. Problem
resolution
A I R
Problem
resolved?
AR I C
13. Problem
closure
C,I AR R
Major
Problem?
A R R
Major problem
review
A,R R R
End
Ownership,
Monitoring,
Tracking,
Escalation &
Communication
I R A,R R C I
Process design
and Ownership
C C R R C A,R

Problem Management
Critical Success Factors (CSF) & Key Performance Indicators (KPI)
CSF KPI
Minimize the impact to the
business of incidents that
cannot be prevented
• The number of known errors added to the KEDB
• The percentage accuracy of the KEDB (from audits of
the database)
• Percentage of incidents closed by the service desk
without reference to other levels of support (often
referred to as ‘first point of contact’)
• Average incident resolution time for those incidents
linked to problem records
Maintain quality of IT
services through
elimination of recurring
incidents
• Total numbers of problems (as a control measure)
• Size of current problem backlog for each IT service
• Number of repeat incidents for each IT service
Provide overall quality and
professionalism of problem
handling activities to
maintain business
confidence in IT
capabilities
• The number of major problems (opened and closed and
backlog)
• The percentage of major problem reviews successfully
performed
• The percentage of major problem reviews completed
successfully and on time
• Number and percentage of problems incorrectly
assigned
• Number and percentage of problems incorrectly
categorized
• The backlog of outstanding problems and the trend
(static, reducing or increasing?)
• Number and percentage of problems that exceeded
their target resolution times

Problem Management
Specific procedures
PROBLEM MANAGEMENT
(PM)
Process guide

Problem Management
12. Problem Sources
The problem source identifies the path through which the problem has been reported.
Problem sources are:
PROBLEM SOURCES
Problem source code Description
INCIDENT MANAGEMENT – SERVICE DESK Identified by the Service Desk, Incident related
INCIDENT MANAGEMENT – TIER 2+ Identified by Tier 2+, Incident related
QUALITY ASSURANCE (QA) Reported by QA analysis.
VENDOR Reported (and managed) by vendor
IMPROVEMENT ACTIVITIES Identified through service improvement activities
(trend analysis, knowledge management,…)
OTHER The problem has been identified through some other
means.

Problem Management
Problem progress status codes
IN PROGRESS
• RESEARCH
• KNOWN ERROR
• WORKAROUND PROVIDED
• SOLUTION PROVIDED
The problem is accepted and is being actively
considered:
• RESEARCH: investigation and diagnosis
• KNOWN ERROR: root cause is known
• WORKAROUND PROVIDED: workaround is
provided
• SOLUTION PROVIDED: proposed solution
or patch is waiting for authorization
RESOLVED A resolution of a problem has been put in place.
CLOSED Problem is formally closed.
PENDING
• PENDING – PARTNER SUPPORT
• PENDING – RELEASE OR
UPGRADE
• PENDING – RFC
• PENDING – SCHEDULED
• PENDING – OTHER
The definition of pending, in general terms, must
be: “delay by some reason”.
• PENDING – PARTNER SUPPORT: Waiting
for external supplier´s action. Problem has
been sent to external Partner to provide
solution/patch.
• PENDING – RELEASE OR UPGRADE:
Waiting for new release/upgrade.
• PENDING – RFC: Request for Change
(RFC) has been raised and waiting for
Change Management approval.
• PENDING – SCHEDULED: Resolution is
planned on a known date-time. This
should also eventually be changed to
resolved.
• PENDING – OTHER: All other reasons.

Problem Management
15. Prioritization
Unlike incident management where high impact and high urgency equals high priority, problems are
focused on removing high impact and low complexity problems first. This approach provides the
greatest gain to the organization for the least effort, and supports a reduction in Tier 2 firefighting
activities, freeing up more time to work on more complex problems over time.
Problems often incur costs, either directly or through the assignment of critical support resources to
perform diagnosis and resolution activities. In addition, there is significantly more subjectivity in the
prioritization of problems vs. incidents, due to the nature of the process itself. The goal is to remove
impacts to customers and thus, there are often competing factors that must be considered including cost
to the business in lost revenue, technical complexity of the problem, relative impacts to customers and
costs to determine root cause (e.g. result of committing highly skilled, and therefore high cost resources
to the problem teams).
Priority is calculated/evaluated based on Impact and Complexity;
Sample Impact Matrix:
IMPACT MARTIX - SAMPLE
Impact Description
High The problem is causing a high number of customer impacts, often derived
through the volume and priority (e.g. high impact) of associated incidents.
In addition, problems that are deemed to be incurring high expense or lost
revenue would be considered high impact.

16. Cause codes
Problem Cause code indicates WHY the problem occurred i.e. cause of a problem.
When a problem is closed a cause code must be assigned. Cause codes are used to produce reports
which allow analysis to be done to reduce occurrence, frequency of incidents and problems.
At Problem cause indicates root-cause:
PROBLEM CAUSE CODES - SAMPLE
Problem cause code Description
Code bug
Configuration bug
Client issue
• External cause issue
• System issue
• User mistake
• External cause issue: Client can’t use the service
because of some external factor issue (Electricity,
Telecom services, Problem with client supplier)
• System issue: Issues with customer infrastructure
(HW,SW,OS)
• User mistake
Vendor issue

PROBLEM Management (PM)
2
17. Closure codes
Additionally, as problem is closed, more detailed information can be specified via problem closure
codes;
PROBLEM CLOSURE CODES
Problem closure codes reflect the way problem has been closed.
Problem closure code Description
REJECTED Problem was rejected during initial assessment and didn’t
qualify for further investigation.
RESOLVED - SOLUTION
IMPLEMENTED
Problem resolved by implementing a solution.
RESOLVED – BY WORKAROUND Problem is addressed by implementing a workaround.
Further investigation is abandoned.
DOCUMENTED – KNOWN ERROR Root Cause is known. Further investigation is abandoned.
DOCUMENTED – SOLUTION NOT
APPROVED
Solution is known but it is not approved (too costly, too
risky).

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

ITIL Problem Management Workflow - Process Guide

Recommended

Recommended

More Related Content

More from Flevy.com Best Practices

More from Flevy.com Best Practices (20)

Recently uploaded

Recently uploaded (20)

ITIL Problem Management Workflow - Process Guide