Flexible Development Isn’t Free

If flexible product development is so valuable for enhancing innovation, which is highly coveted, why isn’t it widely practiced? The answer is that it has its difficulties and its price. Consequently, you only use it when its benefits outweigh its costs. This page outlines some of these difficulties so that you are aware of them.

The Cost of Options
One of the techniques of flexible development is building and maintaining options, so that when circumstances change, you can move to an alternative path easily and quickly (low cost of change). However, creating and maintaining these options usually costs effort or money. This is the main reason that you should be selective in where you apply flexibility: apply it to the parts of the project or product where you anticipate change and avoid it elsewhere. Of course, you will misjudge on occasion, but this is still much better than ignoring change altogether.

The Cost of Capacity
When change happens, often you will have to change a design, make new parts, and retest them. This means that you will need design, fabrication, assembly, and testing services that are responsive so that you can turn work around quickly when change happens.

You may have seen this question addressed with a mention of queueing theory and a corresponding graph like this:

This is interesting, but because it has no numbers on the Y-axis, it leaves the question open: just how long might the wait be? Furthermore, if there are no numbers, does anyone know how long the queue is or is it all conjecture? Well, it is not conjecture. There is a well-established branch of mathematics called queueing theory, and professors spend their lives calculating the lengths of queues. A basic queue, which applies to many product development situations, such as waiting for a design to be retested in the lab, is called an M/M/1/∞ queue. It looks as shown below (the single arrivals curve):

From Flexible Product Development by Preston G. Smith, Jossey-Bass, 2007 by John Wiley & Sons. Used with permission.

In this graph, service time is the time spent actually obtaining service, for example the time actually required to retest the design. Waiting time includes both service time and the additional time spent in queue waiting for retesting to start. You can see that this waiting time (on average, since it is a random process) is twice the service time when the lab operates at 50 percent of capacity and ten times service time when the lab is at 90 percent of capacity.

This simple model does not cover some product development situations well, because some arrivals are not only random in time but are “clumpy,” for instance, multiple variations of a design arrive at the lab simultaneously for testing (the M/M/1/∞ queue assumes that they arrive alone). In this case, assuming that they arrive three at a time on average, waiting time rises to five times service time at 50 percent utilization and 22 times service time at 90 percent utilization.

Clearly, you will need to invest in capacity to remove bottlenecks if you want to deal flexibly with design changes.

More Project Management
Those who practice agile software development (a forerunner similar to flexible development but only valid for software development) have often been accused of not planning and not managing project risk. The fact is that they do even more planning and risk management than traditional project managers, but it is dispersed, as needed, throughout the project where it isn’t so identifiable.

A flexible project will require more management attention than a project in a stable environment. However, when the environment is in flux, traditional project management is less effective than flexible project management, because long-term plans made upfront will have to be revised repeatedly (great waste), and traditional risk management will simply miss many risks that appear in the midst of change.

Consequently, when the environment is stable, traditional project management is the better choice, but when you expect rapid or repeated change, flexible project management is less costly.

Abusing Flexibility
Flexibility allows you to make changes relatively late in development without paying a high price for them (low cost of change). Using this capability to full advantage is hard work. It involves identifying areas where change is most likely and collecting information related to the change in advance—for instance, developing alternatives and understanding their consequences.

Unfortunately, some managers abuse this capability to vacillate on decisions and delay action after its last responsible moment. If you use flexibility as a crutch rather than a tool, you will pay the price of flexibility without enjoying its benefits.