A few weeks ago, I had a conversation with an IT Support Manager who questioned why his team would benefit from a process improvement initiative. I’ve had similar questions over the years from different leaders, some of whom simply felt that it would be too time-consuming to learn the methods and undertake projects to address improvements.
This impression was sometimes bolstered by outside process improvement professionals who jumped into projects to try and improve IT services without taking the time to truly understand the process. They simply tried to force a set of templates onto the process, resulting in frustration and aggravation on the part of the IT services team.
It’s true that adapting continuous process improvement (CPI) methods to services can be a challenge. The idea of continuous improvement was originally developed for manufacturing, where defects were often clearly visible. That’s not always the case for a services industry.
There are quite a few different improvement methodologies; you may have heard of some of them – Six Sigma, LEAN, Kaizan, TQM, etc. The ancestor of all of these is simply CPI. This was an approach developed by Edward Demming and Walter Shewhart in the early 20th century. Their methods had a tangible impact on the United States war efforts during WWII. Later, Donald J. Wheeler was prolific in refining the concepts. Others then built on their work resulting in many of the above branches of improvement methodologies.
The bottom line is that there are many CPI tools that can benefit a services organization. As a manager, you don’t necessarily need to be a process improvement professional to leverage and use these tools to benefit your team.
Let’s take a look at one of those tools - process control charts:
Process Control Charts
Control charts are foundational to process improvement, and were one of the first things I ever learned about CPI. The control chart was originally developed by Walter Shewhart, and its purpose is to examine a process over time and measure how it changes. In its most basic form, it has three components – a baseline (mean, or average), a line indicating the upper control limit, and a line indicating the lower control limit.
If you’re familiar with a normal curve, where the center of the curve is the mean (average), typically the ends are three standard deviations from the mean – or the curve is six standard deviations from one side to the other. A control chart could be considered to be a normal curve flipped on its side and then plotted over time. It’s measuring what is normal for a process, and as long as the data remains between the upper and lower limits, it’s usually good (as with anything statistical, there are exceptions, but we won’t worry about those now). If the data jumps outside the upper or lower limits, the process may be experiencing problems and need further examination.
Let’s use the example of ticket volume as a basic measure. For the purposes of IT services, a time measure of a week is often best. A chart shows that the mean (average) is around 155 tickets per week. In a normal curve, the upper limit is around 187 tickets, and the lower limit is around 123 tickets. Most of the time, the volume of tickets is reasonably consistent, and hover around the mean. When this is the case, the process is probably under control.
However, there are two outliers on this chart. The first is at week 14, where the volume spiked to 195 tickets. This is outside the upper limit, so is called either an outlier or an exception, and we would want to investigate what happened to generate the increased volume. Often, the answer is readily apparent – perhaps there was a major system outage that generated increased calls to support.
The second outlier is at week 24 at the lower limit, with a low volume of only 120 tickets. Investigation may show that this was holiday week, so a lower number would be expected. I’ve always advised keeping a process diary, where results of process investigations are documented.
If we were to see a series of data points suddenly outside the control limits, it tells us that something significant has impacted the process we’re measuring, and would drive investigations.
This is a very basic view of process control charts. There are a number of enhancements that can make them even more helpful. If you know the capability of your process is higher or lower than the control limits, additional measures can be added in the form of a spec limit. These would be dotted or different-colored lines that show what we expect the process to do vs. what the data shows the process can handle. If an improvement is introduced that visibly impacts the data, perhaps giving a false result that the process is out of control, a shift can be added. This recalculates the control limits and restarts the chart from the point of the shift.
Michael Hanson has a broad background in information technology, and is an IT executive with over 30 years of experience leading IT Operations, Service, and Support, and has extensive experience leading globally distributed teams. He is ITIL, Six Sigma, and HDI certified, has a BS in Business Technology, and is a regular contributor to industry conferences and publications. His passion is building effective, happy teams and leveraging business and IT process improvement techniques to make processes more efficient, cost-effective, and reliable for both IT staff and their customers. Today, he leads the IT Service Desk at PSCU, one of the USA's premier financial services organizations.