Make It Better!: Using ITIL's Continual Service Improvement Model

Using ITIL's Continual Service Improvement Model

by Jim McKennan

You may be accustomed to seeing my Service Doctor articles in SupportWorld, but I’m not Dr. Jim in this issue. This time I am just plain old Jim the IT Management Consultant, writing about a subject that interests me: continual service improvement.

W. Edwards Deming (1900-1993), an American statistician best known for his work with Japanese manufacturers after World War II, is the Father of Improvement. He showed the Japanese how, by using statistical process control (SPC), they could improve the quality of products they produced. Improved quality coupled with low cost increased the demand for Japanese products in the global marketplace, and the rest, as they say, is history.

It wasn’t until the end of his life that Deming’s work gained recognition in the United States. For this, we can thank the Ford Motor Company. In the early 1980s, Ford was sourcing transmissions from both Japan and the United States. Even though both transmissions were built to the same specifications, customers preferred the cars with Japanese transmissions. Ford’s engineers couldn’t understand why customers preferred the Japanese transmissions, so they dismantled one of each. The American transmission performed as expected, but the Japanese transmission performed better, since the Japanese were able to build the transmission with smaller tolerances. The Japanese were obviously doing something right, so Ford recruited Deming to help it launch its quality improvement initiative. By 1986, Ford had surpassed GM to become the most profitable car manufacturer in the US.

So, how can IT “make it better”? In my consulting practice, I focus on the Information Technology Infrastructure Library (ITIL). One of the phases in the ITIL lifecycle model is continual service improvement (CSI), a collection of disciplines and methodologies that one can use to improve anything.

Why Do We Need to Improve?

Recently, I had a conversation with my boss, one that we have every year. You probably have one like it with your boss, too. Here is what she said to me: “Jim, you were way too productive last year. You travelled too much, visited too many clients, and generated too much revenue for the company. This year we want you to be about 12 percent less productive than last year.” Before I could shout “Yes, I can!” I was rudely interrupted by…my alarm clock! Of course, I was dreaming. No one ever has that conversation about their performance. No matter how well we perform, we are always expected to improve, to perform “better” than we did in the past. The same goes for our services, processes, technologies, and employees.

What Should We Improve?

ITIL has devoted an entire lifecycle phase to continual service improvement (CSI). The name, however, is a little misleading. It implies that information technology (IT) should improve the services it delivers to the business. Of course, it should, but there is a multitude of areas we can focus our improving efforts on, including services, processes, technology performance, departments, and individual employee performance. This is a model we can apply to everything we do in IT.

How Do We Do It?

The ITIL core curriculum book on CSI is over 200 pages long, so it would be impossible to do justice to the the subject in a short article. Let’s just focus on some of the basic, high-level concepts.

What’s In It For Me?

In order to improve, we must change the way we work. In general, people don’t like change. Or, rather, they don’t like to be changed. Countless studies have shown that to get people to change the way they work, you must explain the benefits to them and help them understand what they’ll get out of it (i.e., “What’s In It For Me?”). And you must also involve them in the process of creating the change you are trying to implement, so they are more likely to embrace the change than resist it.


ITIL emphasizes the importance of assigning ownership to all services and processes. Ownership of CSI is no less important. So you will likely need to appoint a specific “manager” to make sure that improvement best practices are accepted and adopted by all areas of the organization. This manager must have specific quality management methodology training and should be high enough in the organizational structure to command authority, influence the behavior of others, and ensure their compliance. The CSI manager will be its owner and chief advocate.

CSI champions must be embedded in the organization and should include executives, middle management, and the actual worker bees. Eventually, CSI will become just another part of the way IT does business.

The Backbone of CSI

Service level management (SLM) processes are the backbone of CSI. Having business requirements for services and service levels is essential for establishing agreements between IT and the business. This ensures that everyone understands the level of service required for the business to be successful. Whenever we fail to reach the goals set forth in the service level agreement (SLA), the service level manager (SLM process owner) will be required to create and institute a service improvement plan (SIP) to get the service level back up where it belongs. The CSI manager can play an important role here, by helping the service level manager develop effective SIPs.

Plan, Do, Check, Act

For steady, ongoing quality improvement, Deming can’t be beat. The Deming Cycle can be used for implementing CSI initiatives, improving services, and improving service management processes. It has four stages or steps: 

  • Plan: Planning for improvement initiative 
  • Do: Implementation of improvement initiative 
  • Check: Monitor, measure, and review services and service management processes 
  • Act: Continual service and service management improvement

The CSI Model

The CSI model, as laid out in the CSI book, provides some general guidance on what steps to take to ensure successful improvement initiatives. Answering this series of questions help us make sure we are organizing our CSI activities effectively. 

  • What is the vision? We must look to the business and business executives to provide the vision, goals, objectives, and guidance necessary to make sure we are on the right path.
  • Where are we now? To answer this question, you must conduct a baseline assessment of your current level of maturity, focusing on the processes or services you want to examine. A baseline assessment will give you a point of reference for measuring the progress and success of your improvement initiative. Many organizations bring in an experienced consultant (with no emotional attachment to your company’s services or processes) to perform such assessments. CMMI (Capability Maturity Model Integration) is one popular assessment tool. 
  • Where do we want to be? The results of your assessment should tell you what needs improving. Set measurable targets for whichever area(s) you decide to improve. 
  • How do we get there? This is where you implement your service improvement plans (SIPs) or process improvement plans (PIPs). The Deming Cycle is particularly useful for this step. 
  • Did we get there? Develop metrics to measure the results of your SIPs or PIPs so you can compare them to your baseline and see how much you have improved. 
  • How do we keep the momentum going? That’s easy! Give the improvements time to stabilize and then answer the questions again to see what else you can improve. The cycle never really ends.

The 7-Step Improvement Process

One of CSI’s fundamental concepts is measurement and CSI uses the 7-Step Improvement Process, along with the Deming Cycle and the CSI model, for just that purpose. To begin this process, start by identifying the vision, strategy, tactical goals, and operational goals, just as you did with the first steps in the CSI model.

  1. Defining what you should measure. This should be defined in the service strategy and service design phases of the lifecycle. It corresponds to the Where are we now? question. 
  2. Defining what you can measure. This step is related to the Where do we want to be? and How do we get there? questions. It is defined in the service design and service transition phase of the service lifecycle and it entails identifying new service level requirements and performing gap analysis to identify improvement opportunities. 
  3. Gathering the data. Data is gathered during the service operation phase in the service lifecycle. The raw data corresponds to the Did we get there? question. 
  4. Processing the data. The purpose of this step is simply to make the data consistent for comparison purposes. We can then begin data analysis. 
  5. Analyzing the data. Data analysis helps us better understand trends and service gaps and their impact on the business. Analysis converts data into information. 
  6. Presenting and using the information. Here we can address the Did we get there? question by formatting, packaging, and presenting the information to the various stakeholders. Be sure to present the information in the format required by each stakeholder. 
  7. Implementing corrective action. Now we have more than just data or information—we have knowledge. Knowledge can be leveraged to make improvements, establish a new baseline, and begin the cycle again.

Of course, we haven’t covered everything about continual service improvement; just some of the basic high-level concepts that may help whet your appetite for improvement. Because your boss will never say, “You work too hard. Be less productive than you were last year!”


Jim McKennan is often recognized for his highly developed customer service skills, as well as for being an adept call center manager, speaker, and award-winning sales and IT professional. Jim is a senior consultant with Pink Elephant and is active in the Sacramento HDI local chapter. He is also the past Western region director of the HDI Member Advisory Board and a member of HDI’s Support Center Certification Standards Committee. Jim holds a BA in psychology from California State University.

Tag(s): process, practices and processes


More from Jim McKennan :