In a previous job, I was asked for a requirements document under two circumstances.

In one case, a client asked for a requirements document because they felt that our proposal for a development project was too “open-ended.” The expectation was that clearer requirements would create certainty about the cost and duration of the project.

In another case, a vendor asked for a requirements document before providing a development estimate. The expectation was that clearer requirements would create certainty about the effort required to complete the project.

Now, I can see how a requirements document creates certainty about what the product is, or what the project is expected to achieve, but it wasn’t clear how it could create certainty about cost, effort, or duration.

A causal relationship was assumed in making both requests: planning (as evidenced by documentation) increases certainty.

There are good reasons for this assumption, but in information technology, the causal relationship is weak or non-existent.

The roots of this assumption are deep in the history of human civilization. Perhaps the earliest adopters of this idea were warring leaders. Those who properly planned military campaigns, to assure victory, defeated those who failed to plan. Indeed, they eliminated them from the gene pool.

More recently, Socialist governments have attempted centralized planning to assure distribution of wealth.

Even today, manufacturing companies invest in product planning to assure market success.

“Iterations” in these arenas took place over such long periods of time that they were not even recognized as such. Specialists in strategic planning were rarely experts in tactics, and vice versa. Failure meant physical death, so there was no hope of “learning from failure”.

Planning never creates absolute certainty, and there are diminishing returns of certainty from investment in planning. This is understood by military leaders as “the importance of the ground war,” by governments as “the importance of individual freedom” to the creation of progress, and by manufacturing companies as “the importance of sales tactics”.

The idea has roots in information technology as well. In the early days, computer time was prohibitively expensive, and prevention of waste in computer time was well worth large amounts of advance planning (known as business analysis, systems analysis, architecture, and design).

The rapid evolution of information technology has caused the widespread, gross overestimation of the returns of certainty from investment in planning.

Information technology has dramatically reduced the cost of going from a plan to an execution. Consequently, the limits of certainty are reached much sooner than expected. Investment in planning beyond that point is wasted.

A small impediment to agility can quickly grow into an insurmountable barrier.

It all comes down to the assumption that if a problem is anticipated, it can be solved, and the best solution for any problem is better planning.

As a result of these assumptions, projects frequently go into endless planning to surmount all anticipated problems.

Agility assumes that not all problems can be anticipated, nor will all anticipated problems actually occur.

Why do people strive for the perfect requirements? Engineers want to know when they can call the project done. They want to know when they can get paid. Requirements are a contract representing agreement about work to be done. It gives producers plausible deniability—any dissatisfaction with the work, whether defects or market failure, can be answered with, “functions as required”.

Consumers want to ensure that they are getting good value (sufficient numbers of features, functions, and other appealing qualities) for their dollar.