Avoiding Mistakes when Implementing Incident and Problem Management


Published on

Many organizations find it attractive to consider Incident and Problem Management as a foothold for implementing IT Service Management. Quite often, such attempts result in situations wherein process immaturity, excessive bureaucratization or deficient connections between processes become evident.

The lack of a holistic vision of IT and poor organizational change are often some of the reasons behind most these issues.

Javier Garcia shares his thoughts and 25 years of practical expertise to help you identify and rectify common mistakes to ensure that your ITSM strategies will result in both efficiency and maturity moving forward.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Avoiding Mistakes when Implementing Incident and Problem Management

  1. 1. Flawless design, implementation and improvement of Incident and Problem Management Javier García Bolao @JGarciaBolao fgarciabolao@gmail.com Avoiding Mistakes
  2. 2.  ITIL®: most commonly accepted set of best practices for IT Service Management.  Incident: The unplanned interruption or degradation of an IT service, or the failure of a component that has not yet impacted in the service.  Problem: underlying cause of one or more incidents.  Any IT organization DEALS with incidents and problems, but MANAGING them requires putting processes in place. Laying the Groundwork
  3. 3.  Identifying usual mistakes common to many implementations of IT processes for incident and problem management.  Finding possible solutions to such mistakes.  Understanding the relevance of: – Adopting a holistic vision to IT Service Management. – Ensuring the connections between ITSM processes. Objectives of this webinar
  4. 4.  Every business has a different answer for this question.  Interdependence with other processes (sets of activities)  It is likely that IM and PM could be implemented first, as long as we don’t neglect the rest of the SLC. Which process should I implement first?
  5. 5. Thinking that IT is all about the Operation Stage
  6. 6. Linking Incident and Problem Management
  7. 7.  A problem is the underlying cause to one or more incidents  An incident NEVER becomes a problem  A problem is not an incident that has to be investigated  A problem is not a major incident  A problem is not an escalated incident  Incident and problem are different concepts Misunderstanding the concept of “problem”
  8. 8.  In order to restore the Service, it may be necessary applying a bypass solution (workaround)  The aim of Problem Management should be providing a permanent solution to the the problem. Workarounds becoming permanent solutions
  9. 9.  Your Service Desk knows what it takes for being efficient at solving incidents. – Ask them to assist you at defining the IM process – It will facilitate change – It will help you to discover gaps in other SLC stages Defining without taking stakeholders into account
  10. 10. Linking Incident Management with CSI and KM
  11. 11.  Your Customers are the requestors. Start managing expectations right from the beginning. – Meetings for LISTENING and UNDERSTANDING – Satisfaction surveys – Periodic follow-up meetings Defining without taking stakeholders into account
  12. 12.  Most things work best if they are kept simple (K.I.S.S.) – The “S” of K.I.S.S. does NOT stand for “sloppy”  When designing: – Define the objective of the process – Keep in mind the objective along the design stage – First draft with every detail supporting the objective – Final draft only with the essential elements – Simple writing, adequate for different audiences  Mind the culture of the organization – “Culture eats Strategy for breakfast”. Bureaucratizing processes
  13. 13.  Understand that you’re leading a change  Put the right people at the right place  Maintain the communication with stakeholders  Service may slip before improving: act in advance  Be proactive in your relationships with customers. Transitioning without good communication
  14. 14.  Do NEVER lie about expected outcomes of processes  Drive the change, but MAKE IT THEIR IDEA  You are not “doing ITIL”: you are enabling ITSM Poor organizational change
  15. 15.  Know what and when to communicate  Educate and re-educate  “Evangelizing” might not be a good idea within certain organizational cultures.  Communicate with your team: share evidences of improvements. Being unaware of the organizational culture
  16. 16. Links to Organizational Change Management
  17. 17.  If the role has been assigned to the Service Desk Manager, a certain level of authority has to be clearly defined. Incident Manager doesn’t have enough authority
  18. 18.  Getting every incident registered might be challenging, especially at early stages of the implementation.  Not registering systematically will delay the maturation of the process.  Promote the use of Self-Service tools. Incidents are not consistently registered
  19. 19.  Stress is a cause for people leaving the SD  Define an operational margin that will enable them to manage peaks  Hold meetings that would allow them to “open the pressure valve” without risk  Do NOT tolerate abuse, but manage the required solution through the right channels Ignoring that your Service Desk is under pressure
  20. 20.  SLAs have to be clearly defined and communicated  Users may want their issues fixed “right now”  The success of your Service Desk will depend on your ability to train them on what, when and how to do things. Lack of links with Service Level Management
  21. 21. Links to Knowledge Management
  22. 22. “Those who forget History Are doomed to repeat it” Marcus Tullius Cicero (106 BC – 43 BC)  Make sure that you preserve the knowledge gained along the IM process and make it available to others who may need to address a similar incident in the future. Not managing the knowledge gained at IM
  23. 23.  Measuring is the first thing you should do for improving the performance of your processes.  Start with a baseline of the situation, saving data of how the activities are performing right before the implementation.  If you couldn’t capture a baseline, the first measurement can become your baseline.  Culture: Metrics are NOT bad! Not measuring
  24. 24.  Objective CSF KPI Measurement  Mind the business when you define the objective and the CSFs  Present the right information in the right format to the right persons  Data Information Knowledge Wisdom Not measuring (or measuring the wrong thing)
  25. 25. Conclusions
  26. 26.  A process is just a set of activities for accomplishing a specific objective.  Understand that your IT is a system on which different processes should be naturally inter-connected.  Make sure that the links between processes are connected, “clean” and operational.  MIND THE BUSINESS Conclusions
  27. 27. There is no one perfect approach for everyone
  28. 28. Javier García Bolao @JGarciaBolao fgarciabolao@gmail.com es.linkedin.com/javiergarciabolao/ Thank you for attending