When it comes to Problem Management two things should come to mind: Root Cause Analysis (RCA) and finding a permanent resolution. How often have you thought about what it takes to conduct these aspects of Problem Management? An important underlying aspect of conducting a Root Cause Analysis and finding the permanent resolution are the reasoning approaches used. Three types of basic reasoning approaches are: Inductive: Reasoning from specific examples to general rules Deductive: Reasoning from general rules to specific examples Abductive: Reasoning to the most likely answer Each has its own uses and can be applied to problem solving and Problem Management at different times and for different reasons. However, when performing the Problem Management process we should be open to using all three reasoning approaches. They all complement each other with Inductive and Deductive reasoning forming two ends of a spectrum while Abductive thought looks for the balance between the other two a

In a recent conversation I was asked about the difference between an Incident and a Problem. This is one of the most often confused points in all of IT Service Management and ITIL. Part of the confusion comes from the fact that both words are used (at least in the English language) to express similar ideas. Each reference some kind of issue occurring that potentially could lead to human action. However, in ITIL words are more clearly defined and have particular contexts for usage. Incident: Any unplanned event that causes, or may cause, a disruption or interruption to service delivery or quality Problem: The cause of one or more incidents, events, alerts or situations While Incidents have to do with disruption of delivery or quality, problems have to do with causes. From these distinct definitions we can see that not every incident would result in a problem, and not every problem even needs to be related to an incident. Keep in mind that “Incidents never grow up to be Problems.” Th

I was recently asked by one of my followers if I might have an example of a Service Design Package (SDP).  When seeking to implement ITSM and ITIL, we often seek to find examples and models we can use to give us more guidance. This is no less true of the SDP.  Unfortunately when we try to seek out specific examples of a SDP it can often be difficult, if not near impossible. So why is it hard to find actual examples of a SDP? It goes to the very nature of the guidance of what we call best practices. ITIL is not prescriptive as to what should go into a SDP or what one might look like. It provides best practice guidance on the types of items contained, but not the exact look and feel of the content. Therefore each SDP will be unique to the organization that creates it. The organization, type of content, what the content says, and how it is managed are all decisions made by each organization to meet the needs of their customers and users. Just like a Service Catalog or a set of Service L

Not too long ago we discussed John Kotter’s Eight Steps towards Leading Organizational Change.   The sixth step outlined the necessity of establishing Quick Wins.   As IT Service Management professionals we need to show upper management service improvements within a short time frame.   We also need to get our IT staff on board with the ITIL program and what better way than showing benefits quickly.   I have outlined 10 quick wins, some are for those who are just starting their service improvement journey, and some are for those at a higher maturity level. To help illustrate this, we are going to try something new.  The ITSM Professor would like to solicit your opinions and success stories on Quick Wins and IT Service Management improvements.     We may publish your stories in upcoming blogs on topics such as Recording every Incident and Service Request Defining  models for your frequently occurring Incidents Starting to create a Standard Change library Producing trending re

By definition, ITIL is a set of best practices (refer to glossary and section 1.2.3 of any of the books)  It is also considered a "source" of good practice.   While this may be confusing, it is important to understand the distinction. There are many sources of good practice but not all of those sources are  validated as "best" practice.   While the term is loosely used, best practices should be repeatedly proven to demonstrate tangible value in actual organizations.  In fact, today's documented best practice could be tomorrow's good or common practice.  That's how service management evolves, improves and becomes institutionalized. Building a service management program can also involve other sources of good practice (i.e., other frameworks, standards, and proprietary knowledge). ITIL makes it clear that it's best-practice guidelines  are not intended to be prescriptive.  Each organization is unique and must 'adapt and adopt' the gui

Several key individuals played a significant part in the creation of the movement to develop the ideas and usage of quality in the production of goods and services. Joseph Juran was one of these main contributors. His main efforts came in the form of the Quality Trilogy and the Quality Roadmap. Each of these approaches helped to set the foundational concepts and practices of achieving quality for customers. Juran began with a basic definition of quality: “Quality is conformance or fulfillment of customer requirements” The Quality Trilogy states that there exist three basic stages or aspects of achieving quality: Quality Planning: quality does not happen by accident Quality Control: checks and balances, structure and governance ensure quality Quality Improvement: we must always seek a better way to do things Once we have our basic aspects laid out we can then create a “roadmap” or plan for attaining quality. For the delivery of goods and services we could try to create this r

The Professor has kindly lent me his blog to share the latest ITIL Library update - Jayne It was recently announced that the 2011 Edition of the ITIL Core Library will publish on July 29, 2011. Notice that I did not refer to the new release with a new version number - and with good reason. All future revisions to the ITIL publications will be referenced by the year that it was published. ITIL will finally just be ITIL. If you regard the 2011 ITIL update as the equivalent to the revision of a college textbook, you'll understand why this is not a big deal. Academic textbooks are revised on a regular schedule without much fanfare or impact on prior or future students. Past attendees do not retake their final exams or replace their textbook. Just a normal course of continual improvement. Do you base your decision on whether to take a college course on the edition of the textbook being used?  Not really.  What's important is the relevancy of the topic.    The 2011 ITIL Edit