How to do problem management with no budget

Pink Elephant – Translating Knowledge into Results
How to do Problem Management with NO Budget!
Problem Management – Down and Dirty!
Presented by: Peter Hubbard,
Pink Elephant EMEA
Pink Elephant EMEA Ltd
Think Differently. Think Pink

© Pink Elephant, 2015. All Rights Reserved.
ITIL® is a registered trademark of Axelos Limited.
Introduction – Peter Hubbard
 Principal ITSM Consultant
 Worked in ITSM for over 17 years
 Worked in all sorts of organisations, large and small.
 One got to pelt his co-worker with plastic balls in name
of Release Mgt
 Finds his job quite fun.
City of London

3
Problem Management in the wild
“We know we need to do something, but do not know what.”
Problem Management Common Characteristics:
 No responsibility for the process – no process owner or manager
 High reliance on individual ‘heroes’ to spot underlying problems or
errors
 Similar incidents continue to occur.
 For every similar incident the ‘wheel is reinvented’.
 Services are restored but it is not clear who is responsible for
solving the actual problems.
 Confusion over Incidents vs Problems
 Problem & Incident Manager is often the same individual
 A knowledge base mistaken for a KEDB
 Problem Management is not measuring the right things
 Link between Problem & Change Management missing

Problem Managers through the ages…
4

 There is near universal confusion at the ‘sharp end’
about WHAT the difference is between Incident and
Problem Management!
 Incident Management
 The primary objective of
Incident Management is to
restore normal service
operation as quickly as
possible and to minimise the
adverse impact on the
business
 Problem Management
 The primary objectives of
Problem Management are to
prevent problems and
incidents, eliminate recurring
incidents and to minimise the
impact of incidents that
cannot be prevented
The hole that we dug for ourselves
5

Problem Management!
business
cannot be prevented
6

Problem Management!
business
cannot be prevented
7

Problem Management!
business
cannot be prevented
8

Something that
hurts a lot?
An Incident
that keeps
coming back?
Something that
can’t be fixed
at first line?
Anything
affecting a VIP?
The Problem: What is a Problem?

Something that
hurts a lot?
An Incident
that keeps
coming back?
Something that
can’t be fixed
at first line?
Anything
affecting a VIP?
The Problem: What is a Problem?
A ‘problem’ is the unknown cause of one or
more incidents

 “Its easy to forget that you came to drain the swamp
when your up to your neck in Alligators!”
 Incident = Alligator Bite
 Incident Management = Band Aid
 Major Incident Support = Tourniquet
 Problem = Alligator
 Problem Management = Alligator Shooting
 Known Error Database = Alligator Tagging
 Project = Alligator's Nest of Eggs
 Production Handover = Hatching Time
 Cowboy Tech = Alligator Farmer
Incident vs Problem:- Explained
11

 “Its easy to forget that you came to drain the swamp
when your up to your neck in Alligators!”
 Incident = Alligator Bite
 Incident Management = Band Aid
 Major Incident Support = Tourniquet
 Problem = Alligator
 Problem Management = Alligator Shooting
 Known Error Database = Alligator Tagging
 Project = Alligator's Nest of Eggs
 Production Handover = Hatching Time
 Cowboy Tech = Alligator Farmer
Incident vs Problem:- Explained
12
Problem Management starts with
a change of mindset by those
involved in supporting IT

 Incident Record = Fix it
now! Quick!
 Problem Record = What
was that?! How do I stop it
happening again?
 Incident Records
 User details
 Description of the issue
 Problem Records
 Symptoms of Problem
 Frequency of Incidents
associated to Problem
 Count of related Incidents
 Recent RFCS on
impacted service
Problems Problems Everywhere…
13
1st Tip
Separate Problem
records from
Incident records in
your support tool.

 Incident Manager is concerned with Speed.
 Problem Manager is concerned with Investigation and
Diagnosis.
 Don’t make Problem Manager the Change Manager
either!
 If these roles are not separated Problem Management
will wither on the vine.
 Problem Manager does not HAVE to be a full time role.
14
2nd Tip
Separate the roles of Problem Manager and
Incident Manager

 Place a white board near the Service desk of top 10
problems.
 Update it each day
 If Service Desk have a team meeting ask to attend and
speak at it on a regular basis.
 Do not forget to close the loop and let them know when
a problem is closed.
15
3rd Tip
Keep the Service Desk informed of ongoing
Problems

 % Reduction in number of repeat incidents
 % Reduction in average time to resolve incidents
 Number of new registered Problems identified through
Trend Analysis.
 Average amount of time taken to create a workaround
and deploy it to the Incident Management process
 Number of Incidents resolved by Known Errors
16
4th Tip
Measure and report on the right things. You
get what you INSPECT, not what you
EXPECT

My suggestions... Problem Mgt
 % Reduction in Incidents - Value
 Number of Incidents resolved by KE- Quality
 Number of Proactive Problems - Compliance
 Number of Problems by priority – Workload
 Average time to provide a workaround by priority – Efficiency
 “The total number of Incidents was 3% less than the same time
last year. In addition we directly supported the first time fix of over
5,000 incidents by providing the relevant workarounds in the
KEDB.
 On average Problems that were identified had an effective
workaround identified and deployed within 4 hours , and we
stopped 2,000 incidents from even affecting the user base.
 Oh and we identified and removed 500 issues in our infrastructure
before they could impact the users directly.

 70%-80% of incidents can be traced to poorly
implemented Changes
 Problem Management should have a regular agenda
item to report on Problems encountered and especially
where these are caused by changes.
 Start to show the effects of poorly planned change to
alter mindsets of technicans
18
5th Tip
Problem Management should be key
members of CAB

 Both need to be maintained and policed
 Need to have control over the quality of the information
that can be entered.
 Both need to be in an easy to read and easy to search
format. Your audience thinks ‘Google’ is how all
search engines work.
 Out of date information is harmful
19
6th Tip
A Knowledge Base is NOT the same thing as
a Known Error Database but they are both
important

 Its not one size fits all
 They are tools in your toolkit
 Know when to use each one
20
6th Tip
Learn the key Problem Analysis
Techniques…and what you use them for!

Problem Analysis Techniques
 Chronological Analysis
 Kepner and Tregoe
 Brainstorming
 5-Whys
 Technical observation post
 Ishikawa Diagrams
Provides a timeline of events
21

 Brainstorming
 5-Whys
 Fault Isolation
 Affinity Mapping
 Hypothesis testing
 Pareto Analysis
1. Define the problem
2. Describe the problem
3. Establish possible causes
4. Test most probable cause
5. Verify true cause
22

 Brainstorming
 5-Whys
A structured Mind map
23

 Brainstorming
 5-Whys
Typically produces a root cause
after five iterations of “Why?”
24

Houston, We Have A Problem...
“A change was implemented last night. It wasn’t
successful so we had to back it out. The customer is
REALLY cross and we’ll have to do it again!”

We Can Learn a Lot from Children…!

“Why oh Why, oh Why...?”
So what about my Problem, the Unsuccessful Change….???
1. Why Was it Unsuccessful?
There wasn’t time to test it properly
2. Why Didn’t You Have Enough Time to Test?
It came through as an Emergency RFC
3. Why was it an Emergency RFC?
It needed to go in tonight and it’s been waiting with the customer
4. Why was it Waiting with the Customer?
The customer likes to see all changes before they are submitted to CAB
5. Why Do they Like to See All Changes BEFORE Submission to CAB?
For their own records, in case anyone asks them what’s happening

Ahh! So the Problem is…
 The change didn’t go in successfully because of the additional
step prior to CAB submission
 The step resulted in rework, additional downtime and
frustration to the customer
 The customer was not actually approving anything with this
step. The CAB is for approval and had customer
representation
 The Forward Schedule of Change gave the customer the
same information and in a more structured way

 Brainstorming
 5-Whys
 Ishikawa Diagrams Real-time monitoring of events
29

 Brainstorming
 5-Whys
 Ishikawa Diagrams Documenting causes and effects
(a.k.a. fishbone diagram)
30

Ishikawa in action
31

Problem Management
 Problem Management does not have to be just ‘The
clever bits’ its about changing the way that issues are
thought about.
 Its one of the most important steps in moving an IT
department from System management to Service
Management as mindsets start to change.
 Reduces Incidents
 Moves Knowledge closer to front line
 Improves Service Quality
 Removes repetitive ‘boring’ incidents
32

No more alligators thank you!
33

Questions?
info@pinkelephant.co.uk
www.pinkelephant.co.uk
Please rate our webinar.
What are we doing well? How can we make it better?
34
Follow us:

How to do problem management with no budget

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

How to do problem management with no budget