June 2014

In the late 1980s and early 1990s, industry aggressively sought to understand the correlation between product requirements and product outcomes. HP, IBM, Corning, Northern Telecom, Motorola, Analog Devices, and a few others led multi-faceted multi-year campaigns to understand the correlation. An article by Ashok Gupta in California Management Review’s Winter 1990 issue best captured the findings. In short, 71% of what goes wrong in product development can be traced to missing or incomplete or inaccurate requirements.

During these years, except for mission critical and complex systems requiring zero-defect or fail-safe outcomes, the responsibility for product requirements began migrating away from technical functions to marketing and product management organizations to improve corporate abilities to unilaterally focus on them. Product champions became the stars.  The number of technical professionals involved in defining requirements gradually declined, as did their architectures.

Think about that 71% figure. It implies three out of four errors in product development are at least partially avoidable by good up-front planning and analysis. Younger readers may say, “looks like some old fogie is writing the article. We can be agile, rational, scrum, and sprint! And software is easier to modify, more flexible, and better all around.”

That’s all well and good, but the number of designs that are “spaghetti-like” in their architecture has been increasing. Requirements rarely ever arrive in a single package at the same time these days. Isn’t that necessary for a robust architecture? Sure the wizards get the rabbit out of the hat and make the product work, somewhat. But are we giving our companies and customers a best-in-class product? Missed, incomplete, and misinterpreted requirements are the ingredients that go into spaghetti architectures.

We should learn from history and ensure technical professionals again get heavily involved in the requirements definition and management process. We should emphasize strong relationships between product architecture, systems, and technical professionals, and the product or marketing organizations now responsible for defining requirements.

Product Architecture In The Digital Age [Machine Design – June 12, 2014] discusses industry’s movement away from systems engineering approaches that brought both technical and customer requirements together at the beginning of a new product development project.