# 3 - Flexibility

Here is one definition of product development flexibility: The ability to make changes in the product being developed or in how it is developed, even relatively late in development, without being too disruptive. The later one can make changes, the more flexible the process is. The less disruptive the changes are, the more flexible the process is.

Change is fundamental to product innovation, which, after all, is about bringing something new that has not existed before. The more innovative your product, the more likely you are to make changes during its development.

Recent studies show that innovation connects strongly with long-term corporate success, and corporate executives regularly list innovation as a top critical success factor. For example, one global survey ranks innovation as the top strategic priority for 40 percent of senior executives and among the top three strategic priorities for 72 percent of these executives (Boston Consulting Group). Nevertheless, research shows that corporate product portfolios are becoming less innovative. 

Many explanations are possible, but it is likely due to competitive pressures and short term outlook. Today’s executives simply cannot afford to be wrong. Seeing the great advances achieved in the factory by driving variation out of the manufacturing process, they also want to reduce product innovation to a predictable activity. This also explains the current great interest in Lean Six Sigma, which is a methodology to drive variation out of all parts of the business.

Lean Six Sigma and similar quality systems are not the only culprits. Stage-Gate, Product Development Process (more to come on this topic in a future post), and similar phased product development systems encourage heavy up-front planning followed by sticking to the plan. And you can add to these the recent growth of project management, project office, and similar methodologies that promote plan-your-work, work-your-plan approach.

None of these approaches is misguided or has net negative effects. When applied to high-risk, highly innovative programs, however, they have had an unnoticed side effect of putting innovation in a straitjacket, thus making it increasingly difficult to make changes in project midstream in development. Those who must make such changes are often penalized and regret what they are doing when, in fact, they are innovating. For stable projects, the current trends of greater planning and control are properly aligned, but for the more volatile ones, developers need more flexibility to make midstream changes.

From the definition of flexibility provided earlier, it could be easy to conclude that the more flexibility, the better. But flexibility can be expensive, so it must be used with discretion. This is an area where cost-benefit thinking pays off.

Usually, managers resist change in a project -quite correctly- because it is expensive, and change usually leads to schedule slippage. Furthermore, change can open the door to product defects. So any attempt to encourage change must consider its cost. Although each change has different effects on the project, the cost of a change, in general, rises the later it occurs in the project. As shown in several studies, the cost rises exponentially by a factor of 100 from the requirements phase to the operational phase. At Toyota, a major duty of engineering managers is to manage the rate of convergence of the design space: not so fast as to rule out change unnecessarily but not so slow as to leave too much uncertainty late in the project.

The principle of iteration is fundamental to flexible development. Iteration forces the change to occur early in the project - when the cost of change is low. Although this seems simple enough, it is not easy. 

First, some people are quite uncomfortable without a clear destination. They want to know when they will be finished. Management, in particular, tends to have concerns about any project without a clear endpoint. Even if the project plan is fiction, having it is more comfortable than believing that the team or the customer will tell us when results are acceptable (Agile approach). In practical terms, management does need a schedule at the beginning of a project to plan resources and coordinate with other projects.

Second, there is clearly some waste here. The team will repeat some activities, and some of their work will go unused. This is true, and this is why these flexible techniques work best for developing novel products. For upgrades, you know where you are going, and you don’t need a flexible approach. But for innovative products, the apparent waste associated with some dead ends and rework is the price of a winning product. Keeping the cost of change low will help minimize this waste. Here are some cost reduction possibilities to consider:

• Hold off on some tasks, such as documentation, until you are finished
• Find less expensive ways to make and change prototypes (e.g. additive manufacturing)
• Reduce travel, shipping
• Think at a higher level: what is the fundamental learning you need from an iteration, and what are you doing that is extraneous to this?