Cost of Delay: Put a Price on Waiting

Two requests arrive in the same week. A sales director wants a new dashboard before the quarterly review. Support reports that one step of checkout fails for some customers, and those orders are lost. Both requests are marked urgent. The director is in the planning meeting. The customers who gave up at checkout are not. You can guess which request goes first.

Nobody in that room is being careless. They are comparing two adjectives, and "urgent" from a senior person sounds more urgent than "urgent" in a support ticket. Without a number, the only thing left to compare is volume.

Every item in the backlog has a price for waiting

The broken checkout step costs the orders it loses each week. The dashboard costs the hours analysts spend assembling the same figures by hand. An unpatched security issue costs the risk you carry until the fix ships. The question is the same for all three: what does one more week of waiting cost?

That price is called the cost of delay. I count three parts in it:

• Revenue you do not earn while the work waits, such as lost orders or a later launch.
• Costs you keep paying that the work would remove, such as manual effort or an old system you cannot switch off yet.
• Risk you keep carrying, such as a security gap or a contract penalty that gets closer every week.

Don Reinertsen, the author of The Principles of Product Development Flow (2009), is clear that guessing does not work here. In a 2012 interview he said people's intuitive sense of it "is way off". His advice: "It is much better to calculate a cost of delay."

Divide by how long it takes

Cost alone does not set the order. A team does one thing at a time, so a large item blocks every small one behind it. In the same interview, Reinertsen said the best sequence will "prioritize projects with the highest cost of delay per unit of scarce resource consumed". For a software team, the scarce resource is usually the team's time.

Joshua Arnold and Özlem Yüce gave this rule a short name in a 2013 paper on applying cost of delay at Maersk Line: CD3, cost of delay divided by duration. Work out the cost per week, divide by the weeks the work will take, and do the highest score first. If your organisation runs SAFe, its weighted shortest job first is the same idea, with the cost of delay scored on a relative scale instead of in money.

If you have studied operating systems, you have met this before. It is shortest job first with a weight attached, and it exists for the same reason: short jobs should not sit in a queue behind long ones.

A worked example

Here are the two requests from the opening, plus a third item, with invented figures:

Source: invented for this example.

Each item costs its weekly figure until it ships. The work takes eight weeks in any order, but the total cost of waiting does not:

• Dashboard first, then the fix, then the payment method: $27,000.
• Highest weekly cost first, so the payment method, the fix, then the dashboard: $28,500.
• Highest CD3 first, so the fix, the payment method, then the dashboard: $21,000.

Same team, same work, same eight weeks. The order alone is worth $6,000. Look at the middle line as well: ranking by cost alone did worse than ranking by volume, because it parked a one-week fix behind five weeks of work.

The three figures are not equally solid, and that is fine. The checkout number is the easiest to defend, and an engineer can often produce it in an afternoon: count the checkouts that fail at that step and never complete, then multiply by the average margin per order. The dashboard number is analyst hours. The payment method number is a guess at lost sales and deserves a range. Duration is an estimate too, and estimates, targets and commitments are different things. Here you only need the order, not a date.

Not every week costs the same

The table assumes a steady weekly cost. Arnold and Yüce's paper describes urgency profiles, the shape of that cost over time. In my words, with my examples:

• Short life, peak affected by delay: a seasonal campaign. Value rises and falls quickly, so a late launch loses most of it.
• Long life, peak affected by delay: a new market. Latecomers find it hard to recover the share they missed.
• Long life, peak unaffected by delay: an internal tool. Being late postpones the benefit and costs only the weeks lost.
• External deadline: a regulatory change. The cost of delay stays near zero until the last responsible moment, then climbs steeply.

The deadline item is the one CD3 handles worst. On a quiet week it scores near zero, so it slips, and keeps slipping, until it is suddenly the most expensive thing in the building. Take it out of the ranking: work out the latest date it can start and still finish, put that date in the plan, and rank everything else around it.

Questions for the next planning meeting

1. What changes when this ships? Name the behaviour and the number it moves. If nobody can, the cost of delay may be zero, however loudly the item was requested. Shipping is not success; the change in behaviour is.
2. What does one more week cost? In money where possible. Where it is risk, say what could happen and how likely it is.
3. Is the cost steady, or tied to a date? Dates go into the plan as latest start dates.
4. How long will it take? A range is enough.
5. What is the score? Divide, rank, and publish the assumptions next to the ranking.

The last step changes the meeting. When the dashboard's sponsor disagrees with the order, the argument becomes "is it really $500 a week?" instead of "whose request matters more?". Evidence can settle the first question. Only seniority settles the second.

This is the question from an older post, show me the money, asked of the calendar instead of the feature. Your backlog already puts a price on waiting. If you do not write it down, the loudest person in the room sets it for you.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.