"Sometimes we have to slow down to make faster progress."
by Dann Gustavson
An insightful former manager of mine frequently reminded his team members of this counter-intuitive axiom. Usually it was because some unexpected problem had us stymied, and our team’s problem solving response was to pour ever more effort and time (“brute force”) to make faster progress, in order to resolve or at least neutralize it before the project schedule was blown and not recoverable. Such situations can cause people to develop a blind spot to some crucial aspect of the problem that, if and when revealed, would lead to a way out of the “mess.”
It can be tempting to try to solve a problem in one day that has been brewing for several months, by skipping some crucial steps such as precisely defining the problem.
Sometimes, it is just symptomatic of a failure to plan thoroughly, or to consider fully the possible risks and risk responses at the inception of a project or program. An example illustrates.
I worked for an electronic manufacturing services (EMS) business, a.k.a. contract manufacturer. One of the customers we served was a personal computer OEM who contracted with us to manufacture their motherboards and other peripheral boards and assemblies. It was high-volume business, with short product life cycles. Like all PC OEM’s, their new product launches were timed to coincide with the new releases of the microprocessor around which each new motherboard was designed.
The OEM encountered an issue, a test failure on the motherboard during Design Verification Test (DVT) of the newest product using the newest microprocessor, less than 3 weeks before the planned launch day.
They announced, launched, and ramped up anyway, attempting to close out the project and transition to Operations and the market before understanding and resolving the test failure.
In our EMS production plants, we experienced about an 8-10% failure rate in production at board functional test in our factories, due to that design defect. Our customer directed us to keep building motherboards, and to set aside the failed boards for later disposition. Since the OEM did not yet have root cause or a correction to their test software, we built up a bonepile of more than 4,000 defective boards in the global EMS factories in the first five weeks. The OEM managers reasoned that the high number of boards awaiting disposition would inspire their engineers to make faster progress in developing a design and test solution.
However, by then, over $3.5M of material cost was tied up in the bonepile. At 15 minutes test time, it would require 1,000 hours just to retest them all, after root cause and corrective action were implemented. We were contractually getting paid for our work, but the OEM was burning cash every day.
The solution to the design problem required a board redesign with a new fab. A rework for the existing boards was devised, but even so, about half of the failed boards could not be recovered, and ultimately had to be scrapped.
The cost of this failure consumed most of the OEM’s first quarter’s margin for the product, a major hit to their profitability on that product. Yes, they launched on schedule, but at great cost.
The Program Manager and Executive Sponsor made the decision for the new product launch program to go full speed ahead, in keeping with the company’s cultural norms of moving forward aggressively and not letting obstacles get in the way of a market launch. They tasked Engineering to find the cause of the failures, and hoped the problem Root Cause would be found quickly and be simple to “fix.”
The technical term for this type of approach is the "Get Lucky Plan."
Unfortunately, they were not lucky this time.
OK, Dann – What’s my Take-away? How about an alternative: In the Program Charter or Risk Management Plan, the project team can adapt a valuable technique from Lean Six Sigma, by establishing “Project Stop” authority for the PM and team members (referred to as Jidoka in Lean terminology). The Plan can specify conditions, such as critical DVT or Validation failures, to stop the program until the root cause is determined.
As in a Lean Six Sigma production environment, invoking a Project Stop would immediately divert applicable team members and other expert resources onto an action team to find Root Cause and devise the Corrective Action. In Lean Six Sigma production processes, Line Stops typically last a few minutes. Likewise, a typical Project Stop would be brief, too, usually less than a day except for severe problems. The project would resume at its planned pace after the action plan is underway and the PM, sponsor, and senior leaders have a high-confidence date for cutting in the corrective action.
How can a Project Stop help you make faster progress?
Project Stop is not a numbered task on the Gantt chart, not a box in the program network diagram, not a process identified anywhere in the Project Management Institute PMBOK®. But as a key risk response tool, it can potentially save your project if used under the right circumstances.
In our example, and in hindsight, the OEM would have been financially better off stopping the project to find Root Cause before building the large bonepile of defects, and risk being second or third to market with a robust product. Instead, they tied for first to market with their competitors, but with near-zero margin for the first 3-4 months, which they never recovered over the life of the product due to the excessive volume of defective motherboards produced.
In other words, they would have been better off calling for a Project Stop, in essence slowing down, and by doing so, make faster progress.
Another example of Next Level Leadership!
Dann Gustavson, PMP®, Lean Six-Sigma Black Belt, helps Program Managers and their teams achieve superior results through high-impact program execution. Prepare, structure, and run successful programs in product engineering, manufacturing operations (including outsourcing), and cross-functional change initiatives.
Contact Dann@Lean6SigmaPM.com.