Yale University Problem Management

Process Guide

Yale University Problem Management Process 1 of 21

Table of Contents
Introduction .................................................................................................................................................. 3
Purpose ..................................................................................................................................................... 3
Scope ......................................................................................................................................................... 3
Problem Management Overview .................................................................................................................. 3
Problem Management Key Concepts ....................................................................................................... 4
Problem Management Policies ................................................................................................................. 5
Problem Management Process Flow ............................................................................................................ 6
Roles and Responsibilities ............................................................................................................................. 6
Process Procedures ....................................................................................................................................... 8
1.0 Problem Detection .............................................................................................................................. 8
2.0 Problem Logging & Categorization ..................................................................................................... 9
3.0 Problem Prioritization & Assignment ................................................................................................. 9
4.0 Investigation & Diagnosis .................................................................................................................. 10
5.0 Workaround Creation ....................................................................................................................... 11
6.0 Known Error Creation ....................................................................................................................... 12
7.0 Problem Resolution........................................................................................................................... 13
8.0 Problem Closure ................................................................................................................................ 14
9.0 Major Problem Review...................................................................................................................... 14
Problem Sources ......................................................................................................................................... 16
Problem Types ........................................................................................................................................ 16
Problem Prioritization ............................................................................................................................. 17
Problem Closure Codes ........................................................................................................................... 18
Problem States ........................................................................................................................................ 19
Process Metrics ....................................................................................................................................... 20
Document History ....................................................................................................................................... 21

Yale University Problem Management Process 2 of 21

Introduction

Purpose
This document will serve as the official process of Problem Management for Yale University. This
document will introduce a Process Framework and will document the workflow, roles, procedures, and
policies needed to implement a high quality process and ensure that the processes are effective in
supporting the business. This document is a living document and should be analyzed and assessed on a
regular basis.

Scope
The scope of this document is to define the Problem Management Process, and process inputs from,
and outputs to, other process areas. Other service management areas are detailed in separate
documentation. This document includes the necessary components of the Process that have been
confirmed for the organization.

Problem Management Overview

What is Problem Management?

 To prevent problems and resulting incidents from happening

 To eliminate recurring incidents
 To minimize the impact of incidents that cannot be prevented

Why is Problem Management Important?

 Stability! Mature Problem Management directly correlates to increased Service

Availability
 Increase end-user satisfaction and perception
 More efficient usage of resources (less repetition of work, less firefighting, less
overtime, more time to do proactive work)
 Better prioritized workloads and resource allocation
 Increased accountability, decreased turnaround time for Root Cause Analysis (RCA)
Requests
 Increased Knowledge Management
 Increased transparency and awareness

Yale University Problem Management Process 3 of 21

Problem Management Key Concepts

Problem • A Problem is the unknown cause of one or more (potential or

occurring) incidents.
Known Error • A problem that has a documented root cause.
• Optimally, determination of the root cause includes the
identification of a workaround.
Root Cause Analysis • A Problem which we investigate and document the Root Cause of
and provide this information to the requestor.
Incident • Something has broken and needs to be fixed right away…
• Restore normal service as quickly as possible.
• If it breaks again, you have another incident.
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).
Assumptions & • Incidents can exist without problems.
Observations • Problems primarily exist with Incident associations (reactive
problem management).
• Incidents do not become problems - incidents are symptoms of a
problem.
• Problems do not become changes. A request for change is an
output of problem management as a result of solution
identification.
• A workaround can be identified prior to a root cause being
determined and hence, a known error.
• Workarounds can be identified by the problem resolution team, or
others (e.g. customer, help desk etc.)
Reactive Problem • Executed as part of regular operations and triggered through day-
Management to-day operational support
• Primarily driven by incidents, where trends are identified or where
major incidents prompt a root cause analysis (RCA) review to
minimize future impacts
• Goal is to remove recurring incidents and to provide service
interruption workarounds prior to problem resolution
Proactive Problem • Executed as part of Continual Service Improvement (through
Management proactive data analysis activities) or Service Transition activities
(through the identification of acceptable known errors prior to
production release of a new or changed service)
• Primarily driven by events or activities that have yet to cause a
service impact (i.e. Incident)
• Typically introduced as the problem management or other
processes mature/evolve (e.g. Release and Deployment
Management)

Yale University Problem Management Process 4 of 21

Problem Management Policies
There will be one Problem Management Process for all of the IT organization.
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.
Each Problem Analyst who works on a problem will be responsible for updating the Problem record and
Problem status on an ongoing basis.
A major Problem is declared when the degree of impact on the user community is high and the
complexity is low (Priority 1). This is based on the normal Priority Table taking impact and complexity
into account. The Major Problem procedure will be followed for these problems.
When the root cause of a Problem is identified the Problem status will be changed into a Known Error
(KE). KE information (including a workaround or Quick Fix) will be made available for the Incident
Management Process.
Each Problem will be assigned a Priority based on complexity and urgency. The impact of a Problem
describes how broadly the Problem will be realized. Complexity represents the effort required (cost,
resourcing etc.) to diagnosis and resolve.
Each Problem will be assigned a Category using the same classification system used by Incident and
Change Management.
Problem investigations will determine the Root Cause and Configuration Item (CI) at fault.
The Problem Management process will identify the single best solution to the Known Error based on
business requirements.
The Problem Manager will receive sufficient resources to perform the task of administrating the
process of Problem Management. Resource requirements will be based on the scope of the problem.
Resources from the business and technical analyst teams will be required. Problem teams may have the
need to call on Users to help identify root causes. The business service owner will be responsible for
arranging User support of problem teams.
After executing a successful Change resulting in the removal of a Known Error, that Change and that
Problem will be evaluated for a period of time. This is to ensure that the Known Error has been
permanently removed.

Yale University Problem Management Process 5 of 21

Problem Management Process Flow

Roles and Responsibilities

The following roles have been identified within the Problem Management Process.

Role Description
Problem Management Process  Ensures that all aspects of the problem management process are being executed
Owner effectively. The Problem Manager takes a quality assurance rule over problem
resolution teams and is responsible for assembling teams effectively.
Problem Owner  Assigned a problem and uses the Problem Analysts, Subject Matter Experts and
others to help assess and resolve the assigned problem. In some cases, the
Problem Owner will also be the Service Owner. The problem record will be
assigned to the Problem Owner.
Problem Manager /  Manages execution of the Problem Management process and coordinates all
Coordinator(s) activities required to respond to problems in compliance with SLAs and SLO's.
Receives problem candidates, assesses against criteria and initiates the problem
activities and eligible problems.
Service Owner  Ensures the service is managed with a business focus, the definition of a single
point of accountability is absolutely essential to provide the level of attention
and focus required for its delivery.
 The Service Owner is accountable for Continual improvement and the
authorization of changes and improvements to the service and has financial
accountability.

Yale University Problem Management Process 6 of 21

Role Description
Problem Analyst (including  As part of the resolution team, these resources come from stakeholders of a
SMEs) service and include but are not limited to the business analysts, technical
analysts and Users of a service. Their responsibilities include assessing problems,
investigating the root cause and evaluating workaround for effectiveness. The
analyst is also responsible for producing the essential documentation.
 Subject matter experts may be called upon to provide specific guidance on a
problem root cause or work around without actually be a member of the
problem resolution team.

The following illustrates the Responsibility, Accountability, Consulted and Informed (RACI) matrix related
to the key Problem Management Activities:

Service Owner Problem Problem Analyst Problem Owner Problem Process

Manager / (SMEs) Owner
Coordinator

1.0 Problem Detection

R AR R

2.0 Problem Logging &

Categorization A R

3.0 Problem Prioritization &

Assignment C AR

4.0 Problem Investigation &

Diagnosis R AR

5.0 Workaround (KMDB)

Creation A R R

6.0 Problem Resolution

C C R AR

7.0 Problem Closure

C C R AR

8.0 Major Problem Review

C A R R C

Process Maturity and Evolution

R R R A

Yale University Problem Management Process 7 of 21

Process Procedures

1.0 Problem Detection

Step Activities

1.1 Create Problem A problem can be triggered from a variety of sources. It generally is created from:
Record (candidate)  Release Note or Vendor that states a known error
and submit for  Major Incident where the root cause is unknown and problem investigation is requested by
consideration the Situation / Incident Manager
 Proactive analysis of incident trend data
When a problem is detected, it is recorded with initial data and the rationale in considering the problem
for further investigation. This could include the association of incidents, log reports through event
management, written rationale from a Service Owner or notification from the developers or vendors
stating a known error is released into the environment.
1.2 Assess Problem Once a problem is detected it is assessed against pre-defined organizational criteria by the Problem
Record for Manager. During the initial stages of Problem Management, it may not be possible or logical to begin to
consideration work on ALL problems identified. There is some discretion the Problem Manager has to determine
which ones will be addressed in what order. This criteria may simply based on the Priority of the
Problem, ie only address Priority 1 Problems, or problems that have a minimum number of incidents
associated, etc. The Problem Manager may choose to obtain input from a Steering Committee that can
assist in committing resources.

By implementing Problem Management, effort required for Incident Management will decline and
resource effort will shift to Problem Management. Until PM is fully implemented and embraced in an
organization judgment may be required in identifying the problems to be addressed.
1.3 Meets Criteria? If the problem meets the criteria for continued investigation, move on to step 2.0 otherwise the
problem record can be closed with rationale and notification back to the initial detector.

Yale University Problem Management Process 8 of 21

2.0 Problem Logging & Categorization

Step Activities

2.1 Complete Problem Finalize all the coding and categorization (using same categorization as Incident) of the
categorization including results Problem making sure to associate all relevant incidents and include all relevant details,
from initial assessment 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
Also include a description of how the problem met the criteria to become a recognized
problem.

3.0 Problem Prioritization & Assignment

Step Activities

3.1 Prioritize the Problem Update the Problem record with Impact and Complexity based on the Priority Matrix. Problem
prioritization is similar to Incident prioritization, however, it takes into account factors such as
costs, effort to resolve etc.
3.2 Identify and assign The Problem Manager determines who should be assigned ownership and assigns the Problem
Problem Owner to the appropriate Problem Owner (which is often the Service Owner).

Yale University Problem Management Process 9 of 21

Step Activities

3.3 Accept and take The Problem Owner receives the problem record and accepts ownership.
ownership of the Problem
3.4 Identify required skill The Problem Owner determines who else is required to participate as part of the resolution
sets for problem team. The Problem Manager, along with the Problem Analysts identified are the core problem
resolution team & obtain resolution team and SMEs can be called upon as needed to provide expertise during the
commitment investigation and resolution stage.
Identification is performed through the creation of tasks that can be assigned to assignment
groups for queue managers to identify a resource(s) to perform this activity. Assignees update
the tasks as their investigation activities continue. The problem owner updates the problem
task when/if required.
3.5 Resources Secured? The Problem Owner seeks the required individual involvement and if successful the problem
can continue on to the Investigation stage. If the Problem Owner is not successful in obtain
resources the Problem Owner may need to work with the Problem Manager to escalate within
the organization.
3.6 Work to obtain The Problem Owner and Problem Manager may need to consider alternatives if desired
necessary resource resources are unavailable. For example, they may seek alternate SMEs, delay investigative
involvement activities, escalate to senior management, etc.

4.0 Investigation & Diagnosis

Yale University Problem Management Process 10 of 21

Step Activities

4.1 Perform Root Cause Analysis The resolution team, made up of Problem Analysts (and calling on SMEs as
required), work at determining the root cause of the problem. The appropriate
level of resource and attention is determined by the priority of the problem.
Along with various problem solving techniques and tapping into available
knowledge such as Known Error Database can help to pinpoint the point of failure.
This step kicks off 2 potential questions… Is the root cause known and is there a
workaround available. A workaround may not be known but root cause is known
whereas a workaround may exist without knowing the root cause. These 2
streams can be done simultaneously.
4.2 Root cause known? Once the root cause is known, proceed to the “known error creation” step.

4.3 Workaround? If during the investigation and diagnosis stage a workaround is identified, process
to the “workaround creation” step.

4.4 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 Owner 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.

5.0 Workaround Creation

Step Activities

5.1 Document Workaround Upon identifying a workaround, the problem resolution team documents the workaround
and submit for authorization for use by Service Desk and potentially by end users.

Yale University Problem Management Process 11 of 21

Step Activities

5.2 Authorize Workaround The Problem Owner, who is ultimately responsible for the resolution of the problem,
authorizes the workaround.

5.3 Deploy Workaround Upon authorization, the workaround is deployed to the appropriate levels in the
organization.

5.4 Root cause known? Although a workaround is identified, the Root cause may still not be known. If root cause is
known proceed to the “Known Error Creation” step and if it isn’t known, go back to the
“investigation and diagnosis” step.

6.0 Known Error Creation

Step Activities

6.1 Document Known Error and Upon identifying the root cause, the problem resolution team documents the
submit for approval known error in assigned tasks. The problem owner reflects the consolidated root
cause details in the problem record.

It is important to note that occasionally Known errors are identified with new
applications or by vendors, it is important to ensure these are recorded. This
allows a mechanism to track how often these known errors are being
encountered and will help to form the case towards a resolution.
6.2 Approve Known Error The Problem Owner, who is ultimately responsible for the resolution of the
problem, approves the known error.
6.3 Update Knowledge Record and Upon approval, the known error workaround is deployed to the appropriate
make available to Service Desk levels in the organization.

Yale University Problem Management Process 12 of 21

7.0 Problem Resolution

Step Activities

7.1 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
information necessary to make an information decision on the course of action.
7.2 Validate solution and/or options The Problem Owner works with the resolution team to validate the solution
options being put forward for approval.

7.3 Assess solution alternatives and The Problem Owner and Service Owner discuss the available options to
approve course of action determine the best course of action. In some cases the Service Owner may need
to bring the decision to another decision-making body usually if additional
funding is required.
7.4 Solution Approved If the solution is approved, it will proceed through the Change Process. If the
solution is not approved a decision is made to continue investigation to come up
with an alternative solution or to discontinue efforts.
7.5 Problem Resolved? Once the solution is implemented, the Problem Owner together with the Problem
Analysts determine if the solution did in fact resolve the problem. If it did,
proceed to close the problem. If it did not, a decision is made to continue
investigation to come up with an alternative solution or to discontinue efforts.
7.6 Proceed with Investigation? This decision is made by the Problem Owner 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.

Yale University Problem Management Process 13 of 21

8.0 Problem Closure

Step Activities

8.1 Update Problem Once the Problem has been resolved or it has been decided that problem activities are to not
Record with sufficient continue, the problem record is closed.
coding & detail 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 (e.g. monthly batch
processing may have to occur to be certain the change addressed the problem).
Part of closing the problem record is to ensure all approvals are documented, the coding is
accurate, any rationale for decisions are document.
8.2 Major Problem? Once the problem has been officially closed, if it is a Major Problem, it requires a Major Problem
Review.

9.0 Major Problem Review

Yale University Problem Management Process 14 of 21

Step Activities
9.1 Perform Major Problem It is important to review the lifecycle of any Major Problems. Major Problems are those
Review that have a high Priority and therefore have a large affect on the organization. The
following are some items (not limited to) that are addressed in the review:
 Process adherence
 Clarity of roles and responsibilities
 Availability of resources to participate in problem activities
 Proper supporting documentation
 Follow-up actions required
9.2 Document agreed actions As part of the review a set of action items may be identified that are intended to improve
service delivery and process capability.
9.3 Provide Improvement Often these reviews will identify improvements to the process. These recommended
recommendations to Problem improvements are to be documented and provided to the Problem Process Owner for
Process Owner consideration as future enhancements to the Process.

Yale University Problem Management Process 15 of 21

Problem Sources

Incident Management - Tier 1 •Identified by the service desk.

Incident Management - Tier 2+ •Identified by Tier 2+ resources.

Continuous Service Improvement •Determined through service improvement activities.

Release and Deployment Management •Acceptable known errors captured during release review.

Change Management •The problem is likely related to an unsuccessful change.

Customer-Reported •A functional enhancement request.

Vendor-Identified •The problem is being managed or was reported by a vendor.

General Root Cause Request •Typical problem manager trend analysis activities.

Problem Management •The problem is related to a previous or inter-related problem.

•The problem was identified through a non-impacting (i.e. no

Event Management
incident generated) event.

Other •The problem was identified through some other means.

Problem Types
Level 1 Level 2 Level 3 Descriptions
Reactive Trend Consistent The problem is based on a clearly identified and recurring
associated incidents trend.
Reactive Trend Inconsistent The problem is based on a trend of associated incidents that is
inconsistent but recurring.
Reactive One-Time Authorized The problem is related to incidents generated from a suspected
Change authorized change.
Reactive One-Time Un-Authorized The problem is related to incidents generated from a suspected
Change unauthorized change.
Reactive One-Time Major Incident The problem is related to a major incident where root cause
analysis was requested directly or determined to be necessary in
the major incident review.
Reactive Other The problem is related to one or more incidents that share some
other characteristic(s).
Proactive Release Pre- The accepted known error was identified as part of release and
Deployment deployment review activities. This also includes known errors
Known Error identified for COTS packages (i.e. release notes).

Proactive Event-Driven The problem is related to event monitoring warnings where the
(Warning) service has not yet been impacted from a customer’s
perspective.
Proactive Other The problem has been identified proactively through some other
means.

Yale University Problem Management Process 16 of 21

Problem 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 (direct costs such as licenses/hardware etc., or as a result of
committing highly skilled, and therefore high cost resources to the problem teams).

Prioritization Matrix

N/A N/A N/A N/A N/A

High 3 2 1 N/A
Impact

Medium 4 3 2 N/A

Low 5 4 3 N/A

High Medium Low N/A

Complexity

Impact Values

Value 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.
Medium The problem is causing a some customer impacts, often derived through the volume and
priority (e.g. medium impact) of associated incidents. In addition, problems that are deemed
to be incurring expenses or potentially lost revenue would be considered medium impact.
Low The problem is having a minimal impact on customers, often derived through the volume and
priority (e.g. low impact) of associated incidents. No appreciable revenue lost is predicted.

Yale University Problem Management Process 17 of 21

Complexity Values

Value Description
High The problem is complex due to factors including very high costs and/or significant effort
required by IT support staff to diagnose and/or remove the problem.
Medium The problem presents some complexity due to a combination of cost and/or requirement to
focus a large number of resources (or a selct few who are critical) to diagnose and/or
remove the problem.
Low Acceptable or minimum complexity due to costs and/or resource requirements to diagnose
and/or remove the problem.

Problem Closure Codes

•The problem was closed without root cause determination
Deferred (e.g. costs are too high to diagnose, value to remove is too low
etc.).

Accepted Known Error - Workaround •The problem will not be removed as the workaround is
Implemented acceptable.

Accepted Known Error - No •The problem will not be removed and no workaround exists
Workaround however the impacts are minimal/acceptable.

•The problem affects stopped and during an accepted

Resolved - No Action Taken
monitoring period the problem did not resurface.

•The most common closure code, indicating that a change was

Resolved - Root Cause Removed
successfully implemented to remove the problem.

•The criteria required to accepted a problem were never met

Unresolved – Rejected
and the problem has been rejected by the problem manager.

•Used when a feature request has been raised, but the cost of
Unresolved – Cost the request is too high to action and acceptable to the
business/customer (payer).
•The feature request was already defined for a future release.
Unresolved - Future Release Unresolved problem may be associated to an originating
problem for the initial request.

Yale University Problem Management Process 18 of 21

Problem States
A state model allows for the capture of key process milestones. Each milestone represents an important point in time within the process that
needs to be captured, often for performance measurement purposes.

Rejected

Root Change Resolved

Problem
Problem Cause Scheduled –
Accepted
Proble

Logged by
In Known Pendin Root
New Draft Problem Progres Error g Cause Closed
s
m

Chang
e
Unresolved /
Resolved – No Action Taken /
Accepted Known
Deferred

RCA
Cause

RCA Task RCA

Root

Task Assigned In Task

Assign
Open Assigned to Progre Closed
ed
ss

Yale University Problem Management Process 19 of 21

Process Metrics
The following table describes the Process KPIs identified.

Yale KPI Fruition Partners Operational Measure / Notes

Ref #:4 % Repeat Incidents Consider replacing with Incident to Problem Ratio?

Ref #:5 Variation in problems logged N/A - Quickbase calculated?

Future consideration to report on process consistency / QA / Audit

Ref #:9 % of problems not resolved within Recommend against SLA reporting for PM
SLA targets

Ref #:11 % problems reopened Problems are not reopened – they are only resolved with problem removal is
confirmed

Ref #:12 % of problems with customer Problems associated to incidents / Incident to Problem Ratio? (Exclude
Impact incidents resolved with workarounds)

Ref #:14 % Problems responded on time Recommend against SLA reporting for PM

Ref #:15 % Problems resolved on time Recommend against SLA reporting for PM

Ref #:16 Cost of solving a problem Cost to resolve captured – calculate in QuickBase?

Ref #:6 % of problems resolved Problem Resolution Rate

Ref #:7 Average problem resolution time Mean time to close problem

Ref #:8 % of problems unresolved Volume of problems not in resolved state

Ref #:10 % of problems not linked to Known Volume of problems with Known Error Flag
Errors records

Ref #:13 % Ageing problems Volume of undiagnosed (i.e. no known error) problems – backlog

Ref #:17 Total number of problems caused Volume of problems by Incident Source = unauthorized change
due to unauthorized changes

Ref #:18 Problems not associated with Volume of problems with no associated incidents
incidents

Proposed Mean time to known error identification

Proposed Mean time to Workaround Deployment

Proposed Volume of undiagnosed problems

Proposed % Problems with Workarounds Published to KMDB

Yale University Problem Management Process 20 of 21

Document History
Version Date Changes Author
01 02/03/2012 Initial Document Angie Massicotte /
Michael Oas
02 02/04/2012 Minor Updates Michael Oas

Yale University Problem Management Process 21 of 21