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

http://images.google.co.uk/imgres?imgurl=http://services.exeter.ac.uk/eml/images/NHS_Logo.jpg&imgrefurl=http://services.exeter.ac.uk/eml/ehlnlh.html&usg=__Wfk8IZ1Vc7C2RglGrX-nJGeWP1Q=&h=286&w=705&sz=15&hl=en&start=1&um=1&itbs=1&tbnid=pan5rHuDRnJg9M:&tbnh=57&tbnw=140&prev=/images%3Fq%3Dnhs%2Blogo%26um%3D1%26hl%3Den%26safe%3Doff%26rlz%3D1I7GPEA_en%26tbs%3Disch:1

http://images.google.co.uk/imgres?imgurl=http://services.exeter.ac.uk/eml/images/NHS_Logo.jpg&imgrefurl=http://services.exeter.ac.uk/eml/ehlnlh.html&usg=__Wfk8IZ1Vc7C2RglGrX-nJGeWP1Q=&h=286&w=705&sz=15&hl=en&start=1&um=1&itbs=1&tbnid=pan5rHuDRnJg9M:&tbnh=57&tbnw=140&prev=/images%3Fq%3Dnhs%2Blogo%26um%3D1%26hl%3Den%26safe%3Doff%26rlz%3D1I7GPEA_en%26tbs%3Disch:1


ITIL® is a registered trademark of Axelos Limited.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 TipLearn 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





Kepner and Tregoe

Brainstorming

5-Whys

Fault Isolation

Affinity Mapping

Hypothesis testing


Ishikawa Diagrams

Pareto Analysis

1. Define the problem2. Describe the problem3. Establish possible causes4. Test most probable cause5. Verify true cause

22





Kepner and Tregoe

Brainstorming

5-Whys


Ishikawa Diagrams

A structured Mind map

23





Kepner and Tregoe

Brainstorming

5-Whys


Ishikawa Diagrams

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





Kepner and Tregoe

Brainstorming

5-Whys


Ishikawa DiagramsReal-time monitoring of events

29





Kepner and Tregoe

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?

[email protected]

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

Leadership & Management

Transcript of How to do problem management with no budget