Home �   ITIL�  Index

ITIL is Continual Service Improvement

Continuous improvement is an oxymoron, writes George Spalding of Pink Elephant.
Jan 5, 2010

George Spalding

It’s 1998. In the United States, Mark McGwire hit 70 home runs, Bill Clinton was impeached by the House of Representatives, Sex and the City premiered on HBO and Microsoft released its latest version of DOS (Windows 98).

I’m teaching Windows NT 4 to network administrators and NT 4 security (an oxymoron, btw) for auditors, providing consultation for providing effective user support and beginning the technical research for a geek book about NT 5 (later renamed Windows 2000/XP) for network professionals.

I hear rumblings about some kind of IT operating standard out of the UK that has some good help desk stuff in it. I’m certain it can’t be any good since, like many red-blooded Americans, I suffer from the if-it’s-not-invented-here-I-don’t-care syndrome. However, just so I can rule out and continue to ignore this operating standard, I tentatively start looking into it. On closer inspection, I see that it’s an IT management framework called ITIL, an acronym for the Information Technology Infrastructure Library.

Well, as Jim Nabors would say, “Surprise, surprise!” I learned that this ITIL thing is right on the money, makes total sense and in many ways completely validates much of what I said for years in my user support classes. Not only that, it vastly expanded my understanding of IT operations and related risks.

There was more: I learned the difference between a standard and a framework. You must comply with every element of a standard to be certified by an accredited audit. Whereas a framework is similar to a strong suggestion about how you might want to accomplish something; with an explicit encouragement to adopt the guiding principles then adapt them to the needs and requirements of your specific organization. Furthermore a standard is binary: one or zero, pass or fail. You either comply with everything or you don’t. End of story. A framework such as ITIL seeks to help you create a better IT organization next month than you had this month. There is no compliance to set standards, no pre-defined checklists and no IT bible.

In 1998, it seemed that most IT shops were better positioned for the steady improvement and measurable gains that a framework could offer rather than the all or nothing standards-based approach. Flash forward to 2009: The leading IT frameworks in place today are the ITIL and Control Objectives for Information and Related Technology (COBIT). Both have embraced the time-honored improvement principles of Dr. W. Edwards Deming, creator of the Deming Cycle of Plan-Do-Check-Act (PDCA):

Deming created this PDCA cycle in the early ‘50s as a guide for process improvement in manufacturing environments, proving that it worked in Japan. It seems a bit simplistic but it produces steady, continual improvement with almost no backsliding over time.


  1. Plan – Develop a plan for exactly what you want to improve. Keep it S.M.A.R.T. (specific, measurable, achievable, relevant, time-bound). Because this will no doubt involve changing something, be sure to also consider and manage risk.
  2. Do – Do it. (This differs greatly from the paralysis-by-analysis method employed by many people who never take risks).
  3. Check – Immediately evaluate the results. What went well? What didn’t?
  4. Act – Based on the evaluation, implement changes to the next plan. When satisfied that your organization has accomplished all it can from this cycle, start again. Improvement equals better but not perfect.

Another point that Deming makes with PDCA is that improvement happens in cycles. This may seem a minor point but it’s not. Organizations must go through each step of the cycle to achieve real and lasting improvement. There is no suggested time line for one cycle. It could be 60 minutes, two weeks, a month, a year, whatever. But this cyclic approach flies in the face of the commonly used term continuous improvement.

I’m sure that what is meant here is that organizations should never stop trying to improve. In reality, though, they can’t improve continuously but rather continually, or cyclically, because to improve implies that they must complete multiple steps in a cycle. Thus, the reason behind the title of the ITIL v3 book, Continual Service Improvement.

When Gary Case and I sat down to write that book, we had the opportunity to redefine this cycle, throw it out, or create a whole new paradigm. We quickly determined that not only was PDCA still valid more than 50 years after its creation, but it also clearly demonstrated the key principles that we had seen in a number of successful IT improvement initiatives. As we met with the other v3 authors, we struggled with where improvement activities should be placed in v3’s service lifecycle approach. Historically, CSI was always positioned at the end of ITIL’s list of books and still is. However, did that mean it was actually at the end of the service lifecycle? All of us knew it wasn’t.

Improvement activities occur in every phase of the service lifecycle; in every service, every process, every task and every work instruction. So, as the IT industry’s collective understanding of CSI evolves it’s obvious that it’s not a single phase in the lifecycle. Rather, each phase of the service lifecycle took place in a climate of continual improvement. This relationship is exemplified by the now familiar ITIL V3 logo:

The goal of any framework is steady and continual improvement over time that resets the baseline to the current (and hopefully improved) level at the end of each cycle. I believe that is the primary focus and end goal of ITIL, as well: Not to create a new IT bible that dictates chapter and verse how things must be done, but rather to provide clear and compelling guiding principles that give managers a jump start on making a better IT environment for tomorrow. Not all areas will progress at the same rate, some may not move forward at all, however, the end result is simply a better way to manage an improved IT organization.

That’s why I believe that ITIL is CSI.

As well as EVP of Pink Elephant, George Spalding is co-author of ITIL v3’s Continual Service Improvement core volume, and is one of the world’s most insightful and engaging IT service management and support experts. In addition to his extensive commitment to improving the industry, George spent several years as a consultant to the White House on technical presentations and White House conferences. He also coordinated technical presentations for members of the President's cabinet, the Smithsonian Institute, and the Federal Bureau of Investigation. George is an ITIL Expert, the highest level in the ITIL certification program, is a regular author of IT articles and white papers, and is a presenter at global ITSM conferences and events.

CSI, ITIL, ITSM, Pink Elephant, Deming cycle

IT Management Daily Newsletter

Related Articles

Most Popular