I am always looking for things that work. I often find things outside of IT that work really well for IT. A few years ago, I cut through the positive and negative hype around Six Sigma and found that the underlying principle is powerful and effective.

 

This principle is this: We define a standard. We measure actual performance and results. We compare actual performance and results against the standard and learn from the variances.

 

That is it. I can probably ignore statistical analyses. I can ignore green belts, black belts, and muave belts. I can unleash the benefits of Six Sigma if I simply learn from variances and plow that learning back into my processes.

 

Suppose we have scoped that a project will last 9 weeks. This becomes our standard. It turns out that actual performance was a timeline of 8 weeks. That gives us a positive variance of 1 week. Now we need to learn what caused this variance so that we can apply what we learn to our project methodologies and processes. Was the sponsorship better than expected? Did our use of iterative methods reduce rework? If so, we revise our processes and exploit what we learned.

 

If, on the other hand, we scoped 9 weeks and the project took 12 weeks, what can we learn from the negative variance? Did the project scope change? Were the resources available when we needed them? Did we overburden some resources? Did we have too many critical path items? Once we have learned the cause of the variation, we apply those lessons to future projects. Over time, we reduce the variations and improve project performance.

 

What if our system reliability standard is downtime of no more than 30 minutes per week? Just as with projects, we track actual results against this standard to identify any variances. One week, the downtime is two hours. Why? We find out and apply the lessons learned to our IT processes and operations. Another week, the downtime is zero minutes. Why? What can we learn from this positive variance? Once we have learned the reasons, we use these lessons to continuously improve our processes.

 

I have used this “learn from the variances” principle to improve all types of IT processes. If software testing goes better than expected, what can we learn from the variance that we can use to continuously improve our software development and testing processes? The standard for our change review process is that we never make changes to production systems that cause downtime. Do we always hit this standard? No way. However, each time we do have a variance, we learn from it. Over time, the number and severity of variances has dropped dramatically.

 

Because we learn from the variances, what we pick as our standard is almost irrelevant. The standard can start out as our current performance, our desired performance, service level agreements, or benchmarks. As we improve our processes and change our expectations, we update our standards. So, all we need in order to get started is to start.

 

As a caveat, using this “learn from the variances” principle will not make you a Six Sigma green belt, black belt, master black belt or any other type of belt. It will not help you master fishbone diagrams or controls sheets. It will certainly not help you perform Chi-Squared tests. So, I leave such things to the Six Sigma zealots and just use something that I have learned works.

 

Related Links
Alan Koch encourages us to know what we'd like to measure before we start by actively planning for quality-related activities. (But don't forget to say "when".) Measuring variance is impossible unless you had a schedule to begin with. Use this checklist to insure it's not complete fiction. Pete's Estimating Laws encourage us to consider our estimates for those schedules as changeable, since they probably will.