Featured Product
This Week in Quality Digest Live
Operations Features
Daniel Croft
Noncontact scanning for safer, faster, more accurate, and cost-effective inspections
Ashley Hixson
Partnership with Hexagon’s Manufacturing Intelligence division provides employable metrology skills
Krysten Crawford
Stanford researchers designed a program to accelerate hiring for minorities and women
Using the CASCO Toolbox to repair and restore
Peter Büscher
Best practices for fluid sampling in cleanliness analysis

More Features

Operations News
Alliance will help processors in the US, Canada, and Mexico
Strategic partnership expands industrial machining and repair capabilities
Supports robots from 14 leading manufacturers
Ultrasonic flaw detector now has B/C scan capability, improved connectivity, and an app to aid inspection
ASI Construction partners with end users to deliver solutions to production operations
New technology can reduce pollution, bolster energy storage
Algorithms protect data created and transmitted by IoT and other small electronics
Investigating hyperspectral imaging on unmanned systems

More News

Ken Levine


How to Determine the Worst Case for a Process

Have confidence in the confidence interval

Published: Wednesday, June 29, 2016 - 16:56

How do you determine the “worst case” scenario for a process? Is it by assuming the worst case for each process task or step? No. The reason is that the probability of every step having its worst case at the same time is practically zero. What we’re looking for is a value that will occur a very small percentage of the time, but still be a possibility.

In statistics, we do this with a confidence interval, typically plus or minus three standard deviations from the mean to achieve 99.7-percent confidence.

For example, let’s say that we have a three-step process, with means and standard deviations of x1 = 20, s1 = 3; x2 = 30, s2 = 5; and x3 = 60, s3 = 9, respectively. Since variation (variance) is additive, the variance of the entire process is therefore:
S2Process = 32 + 52 + 92 = 9 +25 + 81 = 115, and the process standard deviation is:
SProcess = SQRT(115) = 10.7.

If the measure of x is time in minutes, or another measure where a high value is undesirable, the “worst case” should be the mean time plus three standard deviations for the process, or (20 + 30 + 60) + 3*10.7 = 110 + 32.1 = 142.1. (This assumes that there is no wait or lead time between the process steps—not a good assumption, but for now, this will simplify the main point attempting to be made here.)

By contrast, taking the upper limit of each individual process step and adding them together would result in an overly pessimistic worst case of:
[20 +3(3)] + [30 +3(5)] + [60 + 3(9)] = 29.0 + 45.0 + 87.0 = 161.0 minutes.

This difference can be significant, as overly pessimistic worst-case assumptions are expensive. They often result in excessive inventory and carrying costs, as well as other related costs.

In general, if we use 99.7-percent confidence, then the probability of the worst case for a single process step would be (1.00 - 0.997)/2, or 0.0015. If the process has two steps, the probability of each step experiencing its worst case at the same time would be 0.00152 = 0.00000225 (or, expressed in scientific notation, 2.3E-6).

Note that the probability of a defect when a process is at Six Sigma quality is 3.4 defects per million, or 3.4E-6. So experiencing the worst case simultaneously in each step of a two-step process is roughly equivalent to the very small probability of getting a defect when a process is at Six Sigma quality.

If there are four steps in the process, this probability is 5.1E-12, or thirteen zeroes after the decimal point before a non-zero value occurs. And, of course, the number of steps in a process chosen for process improvement is often much more than four. Clearly, the probability of this occurrence cannot be called “zero,” but it is so small that it would be inappropriate to use it for worst case contingency planning in a decision-making situation.

Earlier in my career, I was the assistant controller at a major bank in Atlanta. Each month, the controller calculated the worst possible case for the following month by calculating the worst case for each income statement item. I tried to explain to him that the worst case would most likely never happen. He didn’t get it.

Don’t fall into this same trap. The worst case is often not as bad as it might seem.


About The Author

Ken Levine’s picture

Ken Levine

Ken Levine is a Lean Six Sigma management consultant. He retired as director and lead instructor in the Lean Six Sigma certification program at Georgia State University in Atlanta in 2019. He holds a doctorate in business administration. Levine retired from The Coca-Cola Company in 2000 where he held the position of director of continuous improvement in the Coca-Cola USA division for three years. Levine is a Six Sigma Master Black Belt and Certified Purchasing Manager. He has previously published “Root Cause Analysis Takes Too Long,” “How to Determine the Worst Case for a Process,” “Recycling Your Meeting Waste”, “What Really is a Stretch Objective”, and “Ensuring LSS Success with a Robust Define Phase” in Quality Digest.

For more articles by Levine, click here.




Worst Case

There's lies, damn lies and statistics.  As a junior engineer, I worked in a factory that started making reject.  I was told to keep away while "experts" were brought in to fix it.  They made reject for a month and filled a warehouse with product with "hold" tags.  Suddenly the factory started making good product again.  No one knew why.  The experts were sent home.

Where's the probability figures for that?

Several months later, exactly the same problem occurred during the middle of the night when I was on as shift foreman, in control of the whole factory and two others.  First step was to find the cause, which I did.  The "experts" had forgotten this key action.  My next step was to design a solution.  By morning I'd made major changes to the process and was making good product again.  When management arrived and saw the changes I'd made to the process, I was crucified.