ITIL is Continual Service Improvement
Continuous improvement is an oxymoron, writes George Spalding of Pink Elephant.Im 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.
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 dont. 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.
Briefly:
- 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.
- Do Do it. (This differs greatly from the paralysis-by-analysis method employed by many people who never take risks).
- Check Immediately evaluate the results. What went well? What didnt?
- 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 its 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.
Im sure that what is meant here is that organizations should never stop trying to improve. In reality, though, they cant 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 v3s service lifecycle approach. Historically, CSI was always positioned at the end of ITILs 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 wasnt.
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 industrys collective understanding of CSI evolves its obvious that its 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.
Thats why I believe that ITIL is CSI.
As well as EVP of Pink Elephant, George Spalding is co-author of ITIL v3s Continual Service Improvement core volume, and is one of the worlds 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.