Ask why a website or software project launched late and you'll often hear about technical problems. Look closer and the real cause is usually quieter: decisions that waited. A design approval that sat for a week. Copy that arrived late. Feedback that took three rounds because it went to five people. Each felt harmless at the time. Together, they cost more than any line of code.
That's the idea behind cost of delay, a term popularised in product development by Don Reinertsen: the value you lose by doing something later rather than sooner.
Why delays are invisible
A delayed decision has no invoice attached. Nobody pays a fee for leaving an approval in their inbox for a week. The cost shows up later, as a launch date that slips, and by then it's hard to trace back to the decision that caused it.
How one decision delays everything
Projects are chains of dependencies. If the homepage design isn't approved:
- Developers can't build the templates that use it.
- Content can't be placed in pages that don't exist yet.
- Testing can't start on pages that aren't built.
- Launch moves.
The decision sits on the critical path, the longest chain of dependent work, so every day it waits, launch waits too. Some decisions have slack and others don't, which is why knowing which approvals are critical matters.
How to calculate your cost of delay
You don't need precision. A rough weekly figure changes how decisions get prioritised.
- What will the new site or app achieve per week? Extra sales, leads, bookings, staff hours saved or support tickets avoided.
- Put a value on it. For example, 12 extra enquiries a week at a 25% close rate and £2,000 average value: 12 × 0.25 × £2,000 = £6,000 a week.
- Add deadline effects. Missing a seasonal peak or launch event can be worth far more than the weekly figure.
- Multiply by the delay. A two-week slip costs about £12,000 in this example.
Even if your numbers are rough, a figure like that makes "I'll look at it next week" a conscious choice rather than a default.
Where projects lose the most time
| Cause | Why it delays | Fix |
|---|---|---|
| Approvals waiting | Blocks dependent work | Set response times; one decision-maker |
| Late content | Pages can't be finished | Agree content dates at kick-off |
| Feedback by committee | Conflicting notes, extra rounds | Consolidate feedback before sending |
| Unclear feedback | Rework | Point at specifics; see giving design feedback |
| Scope changes | Re-planning | A fair swap process; see managing scope creep |
How to make decisions faster
- Name one decision-maker with authority to approve.
- Agree response times at the start, such as two working days for approvals.
- See the stakes. Knowing a decision is adding four days to launch is motivating.
- Make approving easy. One tap beats finding the right email thread.
- Batch reviews into a regular slot so feedback doesn't wait for a free afternoon.
- Decide with good-enough information. Most decisions can be revisited; waiting for perfect information is itself a decision with a cost.
Prioritising with CD3
When several things compete for attention, a technique popularised in the lean product community helps: CD3, cost of delay divided by duration.
| Item | Cost of delay per week | Duration (weeks) | CD3 |
|---|---|---|---|
| New checkout | £6,000 | 3 | 2,000 |
| Blog redesign | £1,000 | 1 | 1,000 |
| Booking integration | £4,000 | 1 | 4,000 |
Do the highest CD3 first: here, the booking integration, then the checkout, then the blog. Short, valuable work goes first, which gets value flowing sooner.
Not all delays cost the same
Cost of delay has different shapes:
- Steady: every week late costs about the same, such as lost sales on a store.
- Fixed date: little cost until a deadline, then a lot, such as a seasonal campaign or a trade show.
- Rising: the longer you wait, the more it costs, such as a competitor gaining ground.
- Intangible: hard to measure now but real, such as security fixes or technical debt.
Knowing the shape tells you what to prioritise. A fixed-date item can wait until it can't, then must jump the queue.
A decision log template
Track pending decisions in one place:
| Decision | Owner | Requested | Needed by | Blocks | Status |
|---|---|---|---|---|---|
| Approve homepage design | Client lead | 3 Nov | 6 Nov | 4 page templates | Waiting |
| Choose payment provider | Finance | 1 Nov | 10 Nov | Checkout build | Decided |
| Final menu copy | Café manager | 4 Nov | 12 Nov | Menu page | Waiting |
Review it in every project meeting. Decisions with a "Blocks" column full of work, and a "Needed by" date passing, are the ones costing the most.
For clients: how to stay off the critical path
- Block time each week for project reviews.
- Give one person authority to approve.
- Prepare content early, before the pages that need it are built.
- Ask the team which decisions are blocking work, and do those first.
- When unsure, approve with notes rather than waiting for certainty.
Delay and forecasting
Delays show up clearly in probabilistic forecasts: blocked work stops the forecast cone narrowing. Our guide to Monte Carlo forecasting explains how to see that early.
Making the cost visible
Zelvorm's Cost-of-Delay Clock shows every pending decision with its live effect on the launch date, calculated from the project's real task dependencies, plus the cost in pounds from the client's own numbers. Approving is one tap. When the cost is visible, decisions get made.
The short version
Cost of delay is the value lost by doing something later. In projects, slow decisions on the critical path delay everything behind them. Put a rough weekly value on your project, make each decision's stakes visible, name one decision-maker and agree response times.
