the lost world of problem management (2009)

I DON’T GET

IT

ISN’T IT MAJOR

INCIDENT

HANDLING?

Australian IT Service Management & Help Desk Summit 2009

 “……ITIL’s clarifica/on of an “incident” versus a “problem” clears up confusion about what ac/ons need to take place during which process”

 “An incident occurs at the moment a service request or outage is

called into a service center. ACer that call the company works to get that customer up and running, at which point you close the incident and deploy a separate team to handle the problem, which is defined once the team find a series of incidents that can be /ed together”

 “That’s when you have your root cause which becomes a known error”

Susana Schwartz quo/ng John Long (Tivoli technical strategist for IBM)

5 Australian IT Service Management & Help Desk Summit 2009

 An Incident is: An unplanned interrup-on to an IT Service or reduc-on in the quality of an IT Service. Failure of a Configura-on Item that has not yet affected Service is also an Incident.

 A Problem is: A cause of one or more Incidents. The cause is not usually known at the -me a Problem Record is created, and the Problem Management process is responsible for further inves-ga-on.

An Incident NEVER becomes or turns into a Problem!!!!


 “Whilst most organisa/ons develop processes and procedures around Incident Management many fail to do the same for Problem Management”

 “OCen this is due to a lack of clear understanding of the characteris/cs of the two ac/vi/es.”

 “Incident Management is the simplest ac/vity to understand because it involves puQng structure around the response to service interrup/ons”

Victor Capella “A Framework for Incident and Problem Management”


 ITIL itself is to blame!

 Quality Incident Management data

 Major Incident handling is INCIDENT MANAGEMENT

 Problem Management should be inves/ga/ng root cause


 The “Hero Factor”

 Ask the hard ques/ons

 Change the reward system

 Management commitment

 Quick Wins

 Marke/ng – sell, sell, sell!!!


 Don’t underes/mate the effort  Good Incident Management

 The right people "  Business knowledge "  Facilita/on and coordina/on "  Think outside the square "  Good verbal and wri_en communica/on skills

"  Analy/cal and diagnos/cs skills "  Problem solving techniques

CULTURE CHANGE!


 Knowledge base  Ownership  Suppor/ng tools  Business priori/es

 Target preventa/ve ac/on / resources  Interfaces

 Suppliers

 Development


 Integra/on  Incident Management  Configura/on Management  Change Management & Release Management  Financial Management for IT Services  Availability Management  IT Service Con/nuity Management  Service Level Management  Development lifecycle


 Kepner Tregoe Analysis  What? Where? When? How much?

 Ishikawa Diagram  Cause and Effect Analysis

 Pareto Analysis  80/20 rule

 Causal Table  Why-Because Technique

 Creative Problem Solving  Lateral Thinking / SIMPLEX / SCAMPER etc.


 Grid Analysis  Used when a number of good alternatives exist and many

factors are to be taken into account

 Force Field Analysis  Looks at all forces for and against

a decision

 Analytical Hierarchy Process (AHP)  Decision making tool when both qualitative and

quantitative aspects need consideration


 Remove “red herrings”

 Educa/on

 Design

 Tes/ng

 “Super-‐user”

 Delete the cover-‐ups


  Financial   Problems fell by 39%   Reduced mean/me to iden/fy failures by 20%   Reduced mean /me to resolve by 27%   Reduced mean /me to recovery by 52%

  Educa/on   Reduc/on in cri/cal & urgent Incidents from 22 per week to 1 over 12 months

  Energy   30% reduc/on in high severity Incidents over 3 months

  Outsourcer   Opportunity


 Don’t implement Problem Management in the guise of Incident Management

 Retain “true” Problem Management staff

 Equip staff with the right tools and techniques  Acknowledge the conflict of interest  Ensure the experts you engage really understand the

difference!


[email protected]


the lost world of problem management (2009)

Technology