We have been exposed in recent years to many project management and product development methodology terms with often subtle differences in meaning. The latest version of the PMBOK, for example uses the term “progressive elaboration” to describe the eventual realization of project scope after multiple iterations of planning. The project scope becomes more explicit and detailed over time, as opposed to requirements creep — which is considered uncontrolled change. Most of us have long known that full realization of requirements, and visualization of the product, often takes multiple iterations of design, with feedback loops from modeling and testing activities. (And sometimes the customer doesn’t fully realize what he can do with the product until he has it in hand.)
The term spiral development premiered in 1988 and was particularly relevant to the software industry where Barry Boehm’s use of this visual depicted a cycle of efforts to fully define the product and reduce risk of failure to meet goals.
He specified its use for an environment of rapidly changing requirements or uncertain architecture. He also pointed out that not only can developers demonstrate functionality in an incremental way, but we can also commit corporate resources in an incremental way. And I think that for easily changed and somewhat intangible products like software, this model has been very appropriate.
The application of the term to hardware product releases recognizes that requirements start out broadly and become refined over time. All the while technology is changing: perhaps settling on a new standard interface or protocol: or breakthroughs might occur that can be applied. So wouldn’t it make sense to strategically plan for these refinements and insertions rather than to become victims of them? And simply have separate product releases rather than wait for everything to settle down, and gamble on one grand design that incorporates all inputs, — and is nevertheless surpassed while in a lengthy production phase — again by ever-changing technology or operational conditions.
“Pre-planned product improvement” has also been in use for a long time for advanced product features that had to come later. “Progressive” or “Evolutionary” acquisition is the relatively new term, involving perhaps more iterations than just one pre-planned product improvement. In one evolutionary approach, the incremental approach, the ultimate functionality can be defined at the beginning of the program, with the content of each marketable increment determined by maturation of key technologies.
In the other approach, the spiral approach, the ultimate functionality cannot be defined at the beginning of the project and each marketable increment is defined by the maturation of technologies and matched with the evolving needs of the end user.
How does it work in your world? It seems to be all about risk really: and control of change. It could be argued that everything we have out there in the way of products was developed incrementally. But, was the delivery of them deliberate or ad hoc?
Drivers of Your Strategy?
In time, everything changes:– but in product development, changes are either strategically planned beforehand or tactically innovated when realized later. What determines the strategy we choose? I think it’s likely based upon factors of practicality and market need. Market need often drives decisions about time to delivery: like the annual cycle of toys or automobiles. Another consideration is perhaps the quantities involved: is this a one time production: like a building or pharmaceutical drug — or a long production run of many items? Can we deal with lot/model/and type diversity from a supportability standpoint?
Undoubtedly, technical readiness is key. If emerging technology is the pacing item in your project — there are useful heuristics to reduce the scope of the effort in advanced development and reduce risk: Technology Readiness Levels
Even though concurrency of activities is part and parcel to every project, we should be cautious about trying to manage technology, design, and manufacturing risk at the same time. . If going the incremental route, we must at least have an architecture that supports tech insertion. And so whichever methodology we choose in developing our products, for every product or increment of a product, we should know all we can about the technology and requirements before commencing design, and know all we can about the design before commencing production.
Agile and incremental development actually requires greater rigor and structure than traditional waterfall development, as it has a greater propensity to deteriorate into cowboy coding. Peer review? No, we don’t do that — we’re agile. No, we don’t do “testing” per se — that’s not part of our methodology. No, we don’t have requirements — we know what we want to develop.
Your point about trying to manage “technology, design, and manufacturing risk at the same time” is a great one. The spiral method, if used correctly, will allow for adequate risk containment, but again offers a great opportunity for those who want to cut corners….