Problems use the same prioritisation as incidents. In order to prioritise, the impact and severity must be assessed.

1. ITIL
Problem
Management

2. Contents
Roles
Process
Policy
Purpose of Problem Management
2

3. 3
Contents
Purpose of Problem Management

4. Terms (Service Operations)
1
Something is broken or about
to break.
Repair as quickly as possible.
Open incidents are measured
against SLAs.
Incident
2
Underlying “root-cause.”
Remains open until
underlying issue is resolved.
Open Problems are not
measured against SLAs.
Creates “work-around.”
Problem
3
Routine pleas for help – but
nothing is broken. These
include items like “can you tell
me Joe Blow’s phone
number”, “can you unlock my
account”, and “will you reset
my password.”
Service Request

5. Problem Guidelines
There is no time SLA target associated with
problem resolution. Resolution of the root cause
of a problem may take hours or days or even
years
Problems do not need prior approvals to be worked
and resolved. They only need to be prioritised to
work the most critical problems first
If it appears that root cause identification and
resolution are not readily apparent and the impact
is medium or high, effort should be focused first
on providing a suitable documented work around
5

6. Problem Prioritisation
Problem Priority
Impact: People & Service
Severity: Time
Severity
3-Low
User cannot
perform a portion
of their duties.
2-Medium
User cannot perform
critical time
sensitive functions
1-High
Major portion of a
critical service is
unavailable
Impact
3-Low
 One or two personnel
 Degraded Service Levels but still
processing within SLA constraints 3-Low 3-Low 2-Medium
2-Medium
 Multiple personnel in one physical
location
 Degraded Service Levels at or below
SLA constraints
 Cause of problem falls across multiple
functional areas
2-Medium 2-Medium 1-High
1-High
 All users of a specific service
 Personnel from multiple agencies are
affected
 Public facing service is unavailable
 Any item listed in the Crisis Response
tables
1-High 1-High 1-High
6
Problems use the same prioritisation as incidents. To prioritise,
the impact and severity must be assessed.

7. Contents
Roles
7

8. Roles
8
 Problem Reporter
 Anyone can request a problem case to be opened
 The typical sources for problems are the Service Desk, Service
Provider Groups, and proactive problem management through
Quality Assurance

9. Roles
9
 Service Desk
 Ensure that all problems received/ identified by the Service Desk
are recorded in your ITSM software
 Delegates responsibility by assigning problems to the
appropriate provider group for resolution based upon the
categorisation rules
 Performs post-resolution customer review to ensure that all work
services are functioning properly
 Quality Assurance
 Owns all reported problems
 Prepare reports showing statistics of problems resolved /
unresolved

10. Roles
10
 Service Provider 2nd Line Groups
 Composed of technical and functional staff involved in
supporting services
 Perform root cause analysis of the problem and develop
potential solutions
 Test potential solutions and develop implementation plan
 Service Provider 3nd Line Groups
 Composed of external technical staff involved in supporting
services
 Perform root cause analysis of the problem and develop
potential solutions
 Test potential solutions and assist in development of
implementation plan

11. Contents
Process
11

12. 12
Process Flow

13. Process Flow - Identification
 Anyone within 1st, 2nd 3rd line can request that a problem record be
opened
 All initial information relative to a problem will be logged, especially
related incidents
 Before continuing, the Service Desk will verify the related service
having the issue and correlate it with an existing service and SLA
 After problem verification, the Service Desk will attempt to establish
urgency and impact which define priority.
13

14. Process Flow – Analyze & Resolve
 Primary root cause analysis will be performed by the Service
Provider Group
 As soon as the problem is clearly documented with identifying
symptoms, linked to the incident, a known error record can be
created within the ITSM software so that if additional incidents
occur, they can be related to the existing problem
 Once the solution is determined, it should be implemented
following the Change Management Process
 Once the solution is implemented and verified, the problem record
may be closed
14

15. Contents
Policy
15

16. Problem Policy
Problems must be logged with the Service Desk
before they are worked on
There is no SLA target date connected to problem
resolution (e.g. a start and complete by date)
If a work around for the problem has been
discovered, it should be provided to the Service
Desk and logged into the ITSM software and a
known error recorded
16

17. 17