I enjoyed this recent article over on Industry Week that identified the need for new development processes that will make product development faster, less expensive, and more successful in its outcomes and that covered agile development, knowledge-based development, and spiral development processes as potential processes a company could use to improve product development and associated outcomes. But it made me think about the alternatives not mentioned — namely risk-based development. But first, let’s discuss why new development methodologies are needed.
As noted in the article, a 2008 survey showed that companies met their product launch dates only 45% of the time. Furthermore, a recent survey by Boston Consulting found that only 52% of senior executives were satisfied with their companies’ innovation ROI. That’s clearly a fail. NPD is hard, and not every project will succeed, but these results are equivalent to saying that management is okay with failing half of the time. That’s not acceptable.
However, according to the article, besides making sure that there is a formally defined (and followed) process in place, the only way to see significant improvement is to identify the “next big thing” — the idea, invention, or improvement that will make the product development process faster, less expensive, and more successful. And while I don’t necessarily agree that it has to be “big”, I do agree that, in most cases, improvement is needed. But what kind?
According to the article, the leading contenders are agile development, knowledge-based development, and spiral development processes. Agile development, which started in software, mandates incremental development by teams in short time frames, such as one to four weeks. The frequent inspection and adaption is designed to allow changes to be introduced quickly, and before doing so would be prohibitively expensive. Spiral development, which also started in software, mandates multiple iterations of the entire process, improving and expanding the product in each iteration. For example, in new cell phone development, spiral one would be the base hardware and core OS, spiral two would include the camera and motion centre and API for core apps, etc. Knowledge-based development focusses on the creation of reusable knowledge through learning cycles that use set-based design. Multiple options are created and then refined and eliminated until the winning design is found.
They are all great processes, and they call confer advantages above and beyond the traditional staged development usually employed by manufacturers, but they all miss the point. If the reasons for failure are analyzed, it will quickly become clear that the primary reason most NPD projects miss their deadlines, or outright fail, is because something didn’t go according to plan — a disruption occurred. A risk, known or unknown, materialized and set everything back.
This seems to indicate that what we really need is risk-based development. In risk-based development, after identifying a feature/function list and a few potential high-level designs, the first thing the team would do would be to identify what new innovations are needed to succeed. The team would then rank the innovations on a scale from 1, or incremental renovation of existing technology, to 10, revolutionary invention so that the innovations with the highest score carry the highest risk. Then, the team would attack the highest risk innovations first in a multi-round/multi-stage development process. If the highest risk innovation could not be solved, the project would be suspended until a new idea was identified or terminated if the cost/reward ratio to solve the risk was determined to be too high. This would prevent the situation where the product is taken to 90% completion only to find out that the “killer-app” feature can’t be completed, which makes the product worthless and costs the company millions of dollars and dozens (or hundreds or even thousands) of man years. And this development methodology would work with any stage-based or phase-based process that is already being utilized by the company. It just makes sense.