When there’s a possibility that we’ll deliver late1¹ There almost always is, especially in the early stages of the project., the wrong response is to “wait and see.”

Instead, we should figure out immediately how much it will cost to be late, and then tell our developers to make whatever changes they want to the requirements as long as it improves the delivery time and comes in at a unit cost lower than the cost of being late. We can do this for any other constrained resource, like network bandwidth, latency, or what have you.

This works particularly well because it requires little coordination beyond establishing the price of the constrained resource. The rest is done autonomously.

When we work on a software project that nears its deadline, we are in short supply of time, but we usually have high demand for it, because there are almost always things unfinished tasks remaining. Good practise, in this situation, is to throw out requirements to make the deadline.2² If the deadline is not important enough to throw out requirements for, then there was no deadline to begin with. (No matter what the project manager says.) As we near the deadline, we get ever more desperate and we’re willing to pay an increasing price to gain some extra time. At the end, we are throwing out even quite valuable requirements to make the deadline. We have very little choice, so we are forced to pay dearly for time by throwing out whatever we can, no matter the cost. Once we’re in that position, it’s the sensible thing to do.

But wait! There’s another way.

At the start of the project, we have plenty of time and ample choice. We can find ways to buy time cheaply, by identifying low value/high risk requirements. The problem is setting up a framework that allows us to harvest these early opportunities for cheap time.

Reinertsen suggests a simple solution3³ The Principles of Product Development Flow; Reinertsen; Celeritas Pub; 2009.: allow engineers to scrub any requirement they can think of to gain time, as long as it doesn’t change lifetime profits by more than so-and-so money per day of schedule purchased. This requires that everyone has an approximate idea of what each requirement is worth in terms of lifetime profitability. Setting the maximum price on time also requires having an approximate idea of what early or late delivery is worth. These are numbers someone in the organisation should know at least an approximation to – ideally many people.

The other example I know is a jetliner manufacturer4⁴ Maybe Boeing? I forget. which had a weight problem on a new model in development. They approximated what financial penalties they would have to pay for each kg of weight over the specification limit, and then said to their designers that they were free to make any changes they want5⁵ E.g. switch to a lighter, more expensive material, throw out a low-value convenience, go with an earlier version of a subcomponent, etc. as long as it came in under so-and-so many dollars per kg gained. Sure enough, the aircraft got designed at just the right weight.

What’s cool is it requires almost no coordination. Look at the alternative: someone could try to decide centrally that in order to reduce weight by so-and-so many kg, the fuselage must be \(x\) kg lighter, and the oxygen generators \(y\) kg lighter, and the landing gears \(z\) kg lighter. But they will get it wrong. Either their decision will be impossible to implement, or at least very expensive. Localising the decision to an expert in each area means it can be done efficiently.

You can guess the immediate generalisation of this: if you have any constrained resource (of which time is just a very common example), figure out what an increase or reduction would be worth, and then allow people to make any changes to the requirements they want, as long as it decreases lifetime profitability by less than the maximum you’re prepared to pay for the constrained resource.

By giving designers free reign within the correct economic parameters they will optimise locally in a way that optimises globally. The one thing to watch out for is interaction effects between changes, so people will still need to talk to each other a little bit.

• Markets vs. Politics and Organisational Structure