Problem Management Metrics

Here are some Problem Management metrics:


Key Performance Indicators
Average resolution time (MTTR) < X days (depending on the Service)
% reduction of time to implement fixes to Known Errors
% reduction of time of undiagnosed Problems
# Incidents linked to a Problem record
# Open Problems by severity
Frequency of updates / Service on Watch minutes
% problems opened proactively
Weekly trending exercises
Percentage reduction in repeat Incidents
Percentage reduction in the Incidents affecting service to Customers
Percentage reduction in the known Incidents/Problems encountered
Percentage reduction in downtime
Improved Customer Satisfaction Surveys responses on business disruption caused by Incidents and Problems
Major Incident reports to be distributed within 5 working days of the incident being resolved
% Number of Problem record closed within the targeted specific time frame
% reduction of time to implement fixes to Known Errors
% reduction of time of undiagnosed Problem.


Critical Success Factors
Improve service quality
Minimise impact of problems

Critical To Quality
A mature Problem Management process meaning
All Major Incident reports are issued within 5 working days
Proactive & Reactive Problems are raised
Trending is carried out
Problem review boards are held once a month
MSR information is provided
All Problems are updated on at least a fortnightly basis
All Problems should have a valid Change record against remedial activities

What do you think? What do you use to measure the success of your Problem Management processes?

Problem Management – how to log Major Incidents

Following on from my previous post about reactive Problem Management, here are some of the things to look at when starting to document Major Incidents

Problem Management – reactive activities when starting out

When implementing Problem Management I have always started with reactive activities to blitz any potential quick wins. The first things I have done in the past when implementing Problem Management are as follows:
(1) Create a way of logging Major Incidents. If I don’t have a Service Management toolset, I use MS Office, for example, a word document to capture the detail and a spreadsheet to track the reference numbers, dates and summary details.

(2) Create a way of logging Problems and any associated reports in a similar way for tracking Major Incidents (above)

(3) Look at categorisation and prioritisation

(4) Create basic reports / metrics to provide a summary of Major Incident & Problem Management activity to all stakeholders.

(5) Set up Problem Review Boards. These are regular meetings with all stakeholders to review and progress all outstanding Problem records.

(6) Engage with the Service Desk and establish clear roles and responsibilities.

(7) Engage with Change Management and attend the CAB to give and receive updated on Problem Management related Change activity.

(8) Look at Problem open / close criteria

I will focus on each of these items in later posts.

Change Management – how to create Change communication notice to be issued via the Service Desk

Following on from my previous post on thinks to look at when reviewing a Change; you might find it useful to have a template for Change communications. The following is a sample communication template:

SERVICE A
Release Note

Release Date: Sunday 3rd August 2008


1. Overview.. 1



Overview

This document outlines the content of the release at a high level. The intended readership is for Volunteer testers, and those people that wish details about what is changing in the TBC system.
The general format is; Change or Known Error Number, followed by a brief summary of the enhancement / issue, then some detail about how it has been addressed.

Change 1234 – Service A Enhancements
This SERVICE A release is to include new …

The following data items have been added:

etc, etc

Change Management – how to create Change implementation plans

Following on from my previous post on thinks to look at when reviewing a Change, you might find it usefully to have a template for implementation plans. Depending on the nature of the change, simple tasks like making a network port live may only require a couple of sentences but more complex change will require a plan (or support from your Release Management function if you have on). The following is a sample plan for updating a website, you will see that as well as detailing each task, the owner, contact and escalation details are included for visibility.

Change Management – how to create a risk matrix

Following on from my previous post on things to look at when reviewing a Change, it is important to investigate risk to ensure that stakeholders are aware and that appropriate activities are taken to mitigate impact and probability as appropriate.

Using a matrix can be a useful tool as it will enable your Change owners to be able to consistently apply a tangible level of risk to a Change and will avoid the “if in doubt select medium” scenario.

I have used the attached file as a starting point in previous engagements to assign risk levels to Changes.

Change Management – thinks to look at when reviewing a Change

One of the most commonly asked questions is what to look out for when reviewing Change Requests. I use the below list when assessing Changes to make sure that my review is as comprehensive as possible.


Title – is it clear and easy to understand?
Description – does it clearly set out what the Change is for?
Reason for the change – could include impact of not doing the Change
Impacted service(s)
Locations impacted by the change
User base impacted by the Change
Change requester details
Change implementer details
Pre implementation testing
Implementation plan
Post implementation verification
Priority
Risk analysis – based on impact & probability – may be useful to have a matrix for this.
Risk mitigation – notes on any activities that could be carried out to reduce risk
Back out plan
Will change impact other environments?
Will the change be mirrored automatically to your Disaster Recovery environment?
Authorisation
Communication – will it be invisible to the user community? If not, will a communication be issued via the Service Desk?
Change closure

I will provide guidance on how to create a risk matrix, implementation plans and communications in my later posts.