Mr. Big looked angrily at the latest status report from his engineering team. The MegaBurp project just reported that it was four weeks behind schedule. "How could this be?" he thought. He pulled out the status report from the previous week, and there it was—the smoking gun.
Last week, the team reported that it was on time. "Now I've got them," he said. "No project can slip by four weeks in a single week." He then thought back to the wisdom he had read in a project-management book in the distant past: "Projects slip one day at a time."
Clearly, an irresponsible team had been collecting slippage, foolishly hoping that it would be bailed out by a miracle. Well, the trick had failed. It was time for another inspirational pep talk to the engineering department about not sweeping problems under the rug. Remember, he thought he'd tell the team—we'd all be better off if you told management the truth in the first place.
Yes, the ancient sages of product development once said that projects slip one day at a time. But does this make it true? Not always. The problem of project slippage is more complex than Mr. Big realizes.
Imagine that your project is on day 30 of a 30-day test. You receive the test report, but instead of passing, the product fails. Since you live on planet Krypton and your name is Superman, you instantaneously diagnose, procure, and install a fix to the problem. Unfortunately, you still have to rerun a 30-day test, so you just fell behind a month in one day.
This problem is even worse on Earth. On our planet, when you ask the test department to restart the test immediately, it just chuckles and points to the test schedule posted on the blackboard. "The next test stand becomes available in four weeks," the team members say. This means that you fell 60 days behind in a single day. Try explaining this difficult situation to Mr. Big.
I'm aware of the problem of slippage amplification, you say, but what can I do about it? Perhaps we should educate Mr. Big. Though a new hire might be optimistic about the prospects of doing this, a seasoned engineer would be more cautious. Teaching management to expect slippage amplification simply perpetuates the trouble. A smarter approach would be to attack the root causes of the problem.
First, use smaller batch sizes in your test process. If you broke your 30-day test into 10 three-day subtests, you almost certainly would have found the failure earlier. Large batch sizes inherently amplify slippage. Try to shorten the time between when an error is discovered and when it is corrected.
Second, don't create large queues in your test area by overloading the test process. If you load a process with variability to high levels of utilization, you place yourself in a strongly non-linear zone of a queuing curve. In this zone, slight changes in workload or productivity produce massive changes in queue size. In other words, they amplify slippage. Such development process queues are deadly, but they are virtually always a self-inflicted wound. Measure your queues, calculate what they cost you, and reduce them.
While we can never make the amplification of slippage disappear from engineering processes, we can definitely reduce it.