Variation in Your Processes—A Game of Chance (Part One of Two)

image of woman rolling diceAs most of you know, variation is a very big deal in manufacturing, because even the smallest change in production processes can have big consequences down the line. Keeping variation low means fewer defects, less waste, higher quality, and lower costs.

That’s why manufacturers use statistical process control, charting numbers to see where variation lies because high volumes make variation impossible to pinpoint with the naked eye. But all too often, leaders don’t understand the charts they’re using, overreacting to small data points without considering the larger context. And they make decisions without understanding whether the variation they’re seeing is the result of common causes or special causes.

Without understanding which type of cause is the root of your problem, any proposed solution can make things worse instead of better. That’s why interpreting statistical process control charts shouldn’t be taken lightly—there are rules to follow regarding whether something should be considered an actionable signal. (For a great read on this topic, I recommend Mark Graban’s 2018 book Measures of Success: React Less, Lead Better, Improve More.)

Reducing variation in the business office improves outcomes. But make sure you know what causes the variation before you act.

Can this manufacturing analysis be applied in the business office to improve performance? Yes—but as usual, with an important caveat. With administrative or knowledge work, there’s far more variation than you’d find in a manufacturing process, and everything is context-dependent rather than predictable and mathematical. So much so, in fact, that you can’t really collect a statistically significant sample for analysis.

But you still need to reduce that variation, and to do that, you need to figure out what’s causing it. Where do you start?

Common Causes—Like Rolling Dice

Whenever you roll a die, you expect that the outcome will be a number between one and six. And you know that any of those results is normal, and the variation in results that you get has no outside cause. You can try to roll the die differently, or blow on it, or have someone else roll it for you, but that doesn’t change the fact that you’re going to come out with some number between one and six. Every time.

This is what we call a common cause variation. In other words, it’s a variation that’s inherent in the system design. A variation that’s expected (even if not desired).

Common cause variation in the business office happens as a direct result of how your organization normally executes processes. It’s the variation between . . .

  • your boss’s intent and your actions
  • your intent and your employees’ actions
  • what you should be doing and what you end up doing
  • the way your coworkers do a task and the way you do the same task
  • how you do your task one day versus how you do it on another day
  • the quality and timeliness of the inputs you need to make your outputs
  • the different criteria of different approvers who must sign off on your work
  • changing or unknown criteria from single approvers who must sign off on your work
  • the focus of the organization from one week to the next
  • the amount of time needed to find documents or emails in your system
  • the number of emergencies you need to address from day to day

Some processes simply lend themselves to a lot of variation no matter how well they’re designed—one example is budgeting and forecasting. When you have to gather data from many sources to forecast an uncertain future for expenses, quantities, or delivery times, usually there are many estimates from many people. You may also consult historical data, which can be helpful but which may not reflect the future. This increases variation even more.

All these examples are common cause variation as long as they’re a direct result of the system’s design. When an undesired outcome occurs, you can’t say it wasn’t expected. You can add more people or start more tasks (roll more dice), but that just increases the number of possible outcomes. With all of the variations listed above—which is like rolling at least a dozen dice—many, many random outcomes can be expected, not all of them good.

To reduce common cause variation, you’ve got to clean up your processes to reduce the expected number of outcomes for each step.

Special Causes—When the Dice Are Loaded

Special causes, on the other hand, are known factors that that influence particular outcomes—outcomes that aren’t random at all, but are instead directly assignable to a source. Special cause variation is not part of the design of the system. Something else is at work.

In one classroom simulation I ran with dice to illustrate common cause, one of the students added dots to the die with a pen, causing him to win more throws and producing some weird outcomes. I was questioning the value of my own simulation until I figured it out. That’s a classic example of a special cause variation! (It’s also food for thought about how often people game the system to make their metrics look better.)

In the business office, legitimate examples of special causes would be . . .

  • Unforeseen trends
  • Unexpected or protracted employee absences
  • Natural disasters or rare weather events
  • IT systems going down (if it’s an isolated occurrence)
  • Mergers and reorganizations
  • Leadership changes
  • Poor performance by individuals—ranging from incompetence to negligence to outright cheating
  • Force majeure

People like to blame special causes for outcomes because it’s easier than examining their own processes.

Correcting special cause variation doesn’t require overhauling the system; it simply requires eliminating the cause. As you can imagine, this often makes blaming special causes—more often than not, blaming people—more attractive than it should be.

So how do you figure out whether you’re dealing with a special cause or a common cause? How do you isolate a problem when you can’t map it statistically? This was a problem I faced when I first got my Six Sigma black belt and was eager to use my new learnings to fix an unruly contracting process at work—but quickly found there was so much variation in the process I couldn’t tell what was noise and what would really help.

Stay tuned for Part 2 (coming May 1), when I’ll tell you how I got to the bottom of the problem and isolated the issues that were causing us to lose business.