Product development programs all start with great optimism regarding their potential to provide an excellent product to customers, along with excellent profits to the company. But research shows that a majority of product developments end in failure. The reasons for each failure are unique, but the overarching reason often can be described as the lack of systems engineering.
I managed a program several years ago that is a great example of how programs that have an excellent idea, sound technical basis and talented people working on them can still fall into this trap, and how systems engineering and a systems mindset can rescue these programs from the brink of failure and propel them to a successful conclusion.
Here’s the scenario: Scientists working for a Department of Defense electronics supplier devised and patented a method for doubling the frequency range of a radar amplifier in the same physical footprint. Additionally, advances in technology allowed two of the most sensitive components to be replaced by components that were substantially more reliable, increasing the amplifier’s projected life by more than 500 percent. Further, these new components were not destroyed by the absence of a vacuum, allowing easier, faster and cheaper repair of the parts. Funding was secured, and the product development process commenced. The project was not plagued by requirements issues (though many product developments are), as the performance requirements were identical to the product it was replacing, aside from the increase in bandwidth and reliability.
Unfortunately, prototypes were failing to meet the requirements in either bandwidth, power or both. As the program neared the end of its allocated development funding and the pressure on the engineering team increased, each subsequent amplifier prototype was billed as being “full spec,” with multiple changes made in each iteration to meet this promise. Each prototype failed to live up to this billing, and the program was eventually deemed a failure and scheduled for termination.
How did this program devolve to this point? The scientists and engineers involved were brilliant individuals with a history of successful projects and a long list of patents to their names. The requirements were well-understood, and the program had avoided the all-too-common pitfall of neglecting to consider how the piece would fit into the overall system and its effects on upstream and downstream components, overall system power and cooling budgets, etc., which tends to happen in projects run by component designers that focus on the design and capabilities of their particular widget. However, as the program budget and schedule for development was steadily consumed, those involved felt obliged to make each next prototype do everything, rather than taking a deep breath, seeing how far they’d come and how far they had left to go and then creating a road map to get there.
When I was brought in to the program and we had secured some additional development funding, we got down to the business of creating the road map. In addition to the electronics company’s scientists and engineers, we brought in experts from both academia and a federally funded research and development center to review the initial concept and progress to date, determine whether the program had a path forward and, if so, delineate a series of experiments that would culminate in a successful prototype.
Termination of programs is always an option and should not necessarily be viewed as a bad outcome for a program in dire trouble. In evaluating whether it the right move, look beyond the siren call of spent budget, take a stark look at the chances for success and determine if the program or project can still deliver its anticipated benefits. Many programs in trouble attempt to recover by “dumbing down” the requirements; while that may offer an “out” for a development that is in trouble and allow the program to move to the next phase, ask whether continued investment in the system worth the lesser benefits of a product that meets the revised, easier requirements.
After careful review, we determined that the program had a path to success. A series of six prototypes were planned: three experiments to evaluate the performance of individual design changes, a fourth to combine successes from the three experiments, a fifth planned to be production representative/fully specification-compliant and a sixth to show repeatability.
With this new plan in place, the project was able to proceed in a systematic fashion without pressure to produce instant success. Previously, multiple improvement ideas were incorporated into each new prototype with the hope that this would be the full-spec version, and the program could then proceed into production (and the company could reap its financial reward). Experiments were defined up front, and their results were evaluated without the uncertainty of multiple changes masking the successes (or failures) of individual changes.
Success was achieved on the fourth prototype, and the program eventually was successful in creating a significant capability and reliability enhancement for this weapon system. Much of the credit belonged to the hard work and dedication of the engineering leader for the electronics firm (who received its Product Development of the Year award). But even more so, the credit for this dramatic (and very unusual) recovery was earned by the team that had the wherewithal to take a step back and apply basic systems engineering principals to lay out a plan to recover the project from its death spiral.
All too often, companies or program offices bring in a “Cleaner,” but many of these are just tyrants who bully everyone into working long hours, hoping that if you try everything under the sun, something will work. A systems engineer, however, has the composure to take a step back and review, despite the immense schedule pressure. Rather than rushing into the next setback, a systems engineer will look at what the program or project is supposed to accomplish (high-level requirements), review the efforts underway to support those requirements and set a plan with discrete steps and measurable progress points. By not trying to do everything all at once, wherein successes and failures are indistinguishable and possibly masking each other, having a systematic (there’s that word “system” again) approach allows the system engineer to move toward a path that will result in meeting the original requirements.
About the Author/ Jay Schatz
Jay Schatz is senior program manager at Base2 Solutions. He is a high-performing technical project management and program management professional with the breadth of experience that comes from over 22 years of experience managing programs for the aerospace industry and in the US Air Force. Jay is currently providing program management and systems engineering support to the Boeing 787 program, providing expert advice to clients on program management, supplier relations and engineering solutions. Connect with him on LinkedIn.