Skip to main content

Posts

Should Service Requests be Included in First Call Resolution metrics?

I recently had a question regarding the inclusion of Service Requests into metrics for First Call Resolution. As always, the answer is “it depends”! ITIL now treats Service Requests and Incidents as two different processes – Service Request Fulfillment and Incident Management. Both are generally logged into the same tool and owned by the Service Desk. They are also measured by their own key performance indicators and metrics. ITIL does not consider first call resolution as a process metric - it is more of a service desk performance measurement. First call resolution historically helps measure the handling of incidents by the Service Desk. The definition of an incident is usually pretty clear. However, since the definition of a service request can vary greatly from organization to organization, the value of including requests in incident metrics may also vary. If your definition of a service request includes pre-authorization and funding, then the Service Desk’s ability t

Financial Management and SACM KPIs

A learner who is working towards developing a Cost Management department recently asked about key performance indicators (KPIs) for the Financial Management and Service Asset and Configuration Management (SACM) processes.      ITIL 2011 actually maps Critical Success Factors (CSFs) to KPIs for each process.   Key performance indicators for Financial Management can be found in section 4.3.8 of the Service Strategy book while those for SACM can be found in section 4.3.8 of the Service Transition book. While I cannot list all of the KPIs for both processes, here is a good sample: Financial Management The financial management for IT services framework specifies how services will be accounted for, and regular reports are submitted and used as a basis for measuring the service provider’s performance. All strategies have a comprehensive analysis of investment and returns, conducted with information from financial management for IT services. Internal service providers receive the fu

What are IT Services So Hard to Define? (Part 2)

In my last blog, I provided some suggestions for overcoming challenges in obtaining agreement on the scope and definition of IT Services.  As I mentioned, the Service Catalog is one of the first and most important assets in any service management program. Today we are going to take a high level look at mapping IT Services to business processes.   The first step is to understand what your business or customer does and how it does it. In truth, every business only has five primary focus areas - regardless of whether it is public, private, governmental, non-profit, small or large.  Consider this: Every business designs, develops or acquires products and/or services Every business communicates, markets and sells those products or services Every business delivers those products or services Every business supports its products or services Every business has to have a corporate infrastructure (HR, IT, Finance, etc.) Can you identify where these activities are performed within your

Why are IT Services So Hard to Define? (Part 1)

A Service Catalog is one of the first assets that an organization should build when initiating their Service Management program.  After all, how can you manage services if you do not have a clear understanding what services your IT organization provides? Unfortunately, many organizations struggle with obtaining agreement on the scope and definition of end-to-end, business enabling services.  If left unchecked, these struggles can turn political and widen the divide between IT and the business as well as cause conflict between internal IT units.  To avoid some of the potential challenges in service definition exercises, here are some helpful suggestions: Set the stage by providing IT staff with a chart of business processes and begin integrating business vocabulary into service parameters ("Order Processing" not "Ecommerce").   Have business stakeholders conduct "lunch and learn" presentations that educate IT on how each unit uses IT Services.  Start

Leadership Lessons from Fusion 2011

Having recently attended the Fusion 11 conference in Washington DC, I came away with some key insights that I thought I would pass along. The event brought together the worlds of IT Service Management and Help Desk in a great mix of information sharing and learning through breakout sessions and emotion and motivation in the form of five fantastic keynotes. One of the sessions I attended talked about being a leader in an ever globalizing world. The presenter shared her knowledge and wisdom of how to build a framework of leadership by embracing diversity and different cultures. A couple key take-aways: “I’m different, like you” : Understand that we all have different cultures, backgrounds, knowledge and experience that make us important and unique individuals. Embrace the differences and use them to your advantage. It is our differences that make us similar as people trying to be successful in a complex and technology filled world. “Help me understand” : Keep an open mind and s

Dr. Deming's Cycle

Many of you have probably heard of Dr. William Edwards Deming. But how many of you really know who he was and why he is so important to IT Service Management and ITIL? I mean going beyond the contribution of the Plan-Do-Check-Act cycle to Continual Service Improvement? What was the most important contribution of Dr Deming and why should we care so much about his other efforts? According to Wikipedia, Dr. Deming (1900-1993) was a statistician, professor and consultant by trade, hailing originally from Iowa. He went on to earn degrees from the Universities of Wyoming and Colorado, and a Ph.D. from Yale University. One interesting fact of which most people are not aware was his relationship to Walter Shewhart, the originator of the ideas of statistical process control. In fact the Plan-Do-Check-Act cycle was originally an idea generated by Shewhart (and is sometimes referred to as the Shewhart Cycle, rather than the Deming Cycle). We must remember though, Dr. Deming’s contributions go m

The Beginning of Good Process Implementation

Many organizations that I meet with often are struggling to implement best practice processes into their environments.   They sound completely overwhelmed and often I hear “Where do we begin?”   I smile and usually respond with “At the beginning of course”.   The beginning of good process implementation of course is “defining and analyzing your customer’s requirements”.   I once read that to provide good services a service provider must have good customers.   I think this statement also holds true for processes as well.   Good customers / employees must: Understand the process Understand the expected results of the process Know where they fit into the process Understand how they and others contribute to produce the expected results When your employees understand the processes within your environment they can easily identify new customer requirements and positively respond to rapidly changing customer needs.   This is the basis for making it part of the service culture within you

Resources for Business Relationship Management

A student recently asked for resource references for about Business Relationship Management (BRM). BRM is emerging as a critical process in several prominent service management frameworks and standards.   Recently, BRM was formalized in the 2011 edition of Service Strategy as part of the core ITIL library.    This is a significant addition since many believed that BRM and Service Level Management (SLM) were the same process.     While similar, BRM strategically focuses on the relationship between a service provider and it’s customer (more like an Account Executive) where SLM operationally focuses on the negotiation and achievement of service performance. The ISO/IEC 20000 standard has mandatory requirements and suggested guidance for Business Relationship Management.   Even if your organization is not considering ISO certification, the standard does define the minimum essential activities for each process, including BRM.     Put together with ITIL 2011, it’s a powerful com

The Purpose and Value of Business Impact Analysis

When discussing Service Design I am often asked the purpose and value of a Business Impact Assessment (BIA).   The purpose of a BIA is to quantify the impact to the business that the loss of a service would have.   It is a valuable source of input when trying to ascertain the business needs, impacts and risks that the organization may face in the delivery of services.   The Business Impact Assessment is an essential element of the overall business continuity process.   It identifies the most important services to the organization and therefore will help to define the overall strategy for risk reduction and disaster recovery.   At a more granular level these assessments enable the mapping of critical service applications and technology components to critical business processes.   It is an invaluable input for Continuity Strategy, Availability Design, and Capacity Management.   The BIA’s strategic purpose is to show which parts of the business will be most affected by a major incident

ITIL 2011: Strategy Management

The publication of ITIL 2011 has brought several new or revamped processes to light. One of those is the Strategy Management for IT Services process. This Strategy process is not actually new. It represents the formalization of best practice guidance for managing strategies contained in earlier editions of the ITIL publications. The purpose of this newly minted process is to use a company’s perspective, position, plans and patterns to ensure better management, governance and control of the IT services an organization provides to support the business outcomes. The basic principles of the Strategy Management process include helping to identify the overall business strategy and then tie an underpinning IT strategy (including an IT service strategy) or manufacturing strategy to the business outcomes through integration and alignment activities. Once an IT strategy emerges in relation to the business strategy, the organization can then decompose the IT strategy into IT tactics and

Major Incidents and Problem Records

The other day someone asked me if a Problem Record should be opened for all Major Incidents. Not necessarily – the goal of a Major Incident is still to restore service when a major event occurs that has significant impact on the business. Incident Management is not necessarily looking for a permanent solution but for some level of regained productivity. If viable and necessary, raising a Problem Record will engage the necessary resources to find the root cause (if not already known) and find a permanent solution to remove the error (if one is available). However, sometimes the root cause of a Major Incident is immediately known and a permanent solution not viable at the time. Here is a practical example – we have hurricanes in Florida that can cause massive power outages. We know the root cause and the permanent solution is to repair the power lines. This will likely take some time. Do we need a Problem Record to capture that information? Maybe, if there is a need to document th

Reasoning for Problem Management

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

Incident vs Problem

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.”

The Service Design Package (SDP)

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

Quick Wins

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

Is ITIL Best Practice or Good Practice?

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

Juran and Quality

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 2011 Edition of the ITIL Library

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

Measuring Service Management Maturity

I was recently asked about how to measure service management maturity when the maturity of individual processes is not equal. Frankly, it’s a bit of chicken and egg. It can be difficult to define where your organization is as a whole compared to each individual process when the processes are at different levels. When we look at a specific process we have to judge it against a specific set of criteria. Each organization will develop this criteria based on the organizational goals and objectives. Each process may have a different set of criteria, different levels of benefit or impact so therefore a different level of need-based maturity. For example, for organizations that are highly dependent on suppliers and outsourcing, the need for a mature Supplier Management process is critical. Other organizations may not focus on Supplier Management but invest their focus and resources on other processes such as Configuration Management. The maturity of individual Service Management process

The Difference Between a Service and a Good

What is the difference between a service and a good? When answering questions like these, I attempt to look at things from a simplified view. I try to stay away from complexity and decompose or deconstruct the parts of an answer to its most basic form. As a result, for me the difference between a service and good is very simple. A service is intangible (an abstraction or an idea) while a good is tangible (having physical characteristics). In terms of the creation or production of each, they are both “manufactured” or “created” using the exact same approach. Raw materials are “processed” into a finished output. So both services and goods could be considered “products” of a manufacturing “process.” In this way services and goods are the same thing. The difficulty arises for many people when it comes to the idea of “manufacturing” services. Because they can see, taste, smell or feel a service as it makes its way through the “manufacturing” process, they end up thinking or believing that