We humans have an amazing ability to take a simple concept and find ways to make it overly complex. Take, for example, the principle underlying Six Sigma, which is a methodology to improve product quality through our manufacturing processes. First we created a comprehensive set of Six Sigma tools. Then we created Six Sigma green belts and black belts to identify those who have learned or mastered these tools. (For all I know, there could be mauve belts.) These Six Sigma belts can create fishbone diagrams and perform chi-squares and who knows what else.
Along the way, I fear we've lost sight of the powerful principle that underlies Six Sigma: To improve any process, start by defining a simple standard or benchmark. Then measure variation from the standard and investigate the reason for variation. Apply what we learn to improve the process. I find that using Six Sigma's fundamental principle significantly improves both business and IT processes.
And here's how we can use it to improve IT performance.
Let's take an example. The expected timeline for a project is 12 weeks. So 12 weeks becomes the standard time frame, but the project actually takes 15 weeks to complete. So we ask, "What caused the variance? Did the project scope change? Were the resources available when we needed them? Did we overburden some resources?" Once we learn the cause of the variation, we apply these lessons to future projects. Over time, we reduce variation and improve project performance.
Of course, there can be positive variations: Instead of the expected 12 weeks, what if the project took only 10 weeks to complete? This is a positive variation, albeit a variation nonetheless. What caused the variance? Did our use of iterative methods reduce rework? Once we learn the cause of the variation, we can apply our knowledge to future projects.
Applying the fundamental principle of Six Sigma to improve IT operations also works well. Suppose our system reliability standard is downtime of no more than 30 minutes a week. Just as with projects, we compare actual results with this standard to identify variances. One week, downtime is two hours. We find out why and apply the lessons learned to our IT processes and operations. Another week, downtime is zero minutes. Why? And what can we learn from this positive variance? Once we understand the reasons, we can use our knowledge to continuously improve our processes, thereby improving IT operations.
Improvements Early and Often
The nice thing about using the fundamental principle of Six Sigma is that we don't have to do much research to define the initial standard. We can start with today's performance and then, by measuring and investigating variances, continually improve the processes and performance. I have found that this approach works well with most IT processes, including help desk response times, project scoping and so on.
We should experiment with a subset of our processes as we get the hang of the Six Sigma principle. Relying on Six Sigma's fundamental approach to process improvement won't qualify you for the Master Black Belt title (I'm not sure how you become a master, but it sounds painful), but it can help you become a credible provider of IT products and services. And ultimately, providing better IT is what really matters.
Niel Nickolaisen is vice president of strategy and innovation at EnergySolutions Inc. in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at firstname.lastname@example.org.
This was first published in July 2006