Cost of delay is the economic cost of delivering something later rather than sooner: the value you lose for every unit of time a project is not finished. It answers a question most portfolios never quantify, which is what a month of waiting actually costs. Put a number on it and prioritization stops being an argument about opinions and becomes arithmetic.
The idea comes from product development economics, popularized by Donald Reinertsen. Its power is that it converts "this is urgent" into a figure you can compare across projects. Two initiatives can have identical returns and completely different costs of delay, and the one that bleeds value faster while it waits is the one you sequence first.
Key takeaways
- Cost of delay is the value lost per unit of time a project is late or unstarted, usually expressed in dollars per week or per month.
- It is what makes urgency comparable. Two projects with the same total value can have very different costs of delay, and that gap should decide their order.
- Delay is not always linear. Reinertsen names four profiles: linear, fixed-date, expedite, and standard (intangible). Each behaves differently over time.
- CD3, cost of delay divided by duration, ranks work by the value it unblocks per unit of time. Highest CD3 goes first.
- An approximate cost of delay you actually use beats a precise one you never calculate. The relative order between projects is more robust than the absolute figures.
- Cost of delay is the numerator inside WSJF. Understand it first, then the scoring model built on it makes sense.
What is cost of delay?
Cost of delay is the amount of value an organization forgoes for each period a benefit is delayed. If a project will earn 120,000 dollars a year once live, then every month it slips costs roughly 10,000 dollars in benefit never recovered, plus any competitive or compliance cost on top. That monthly figure is the cost of delay, and it is money already gone the moment the delay happens, not a future risk.
The reason it matters for a portfolio is that value and urgency are different things. A large project that delivers value slowly can have a lower cost of delay than a small project that unlocks revenue immediately. Sequencing by size or by total return alone gets this backwards. Cost of delay is the correction.
What is the cost of delay formula?
At its simplest, cost of delay is the value delivered divided by the time over which it is delayed:
Cost of delay = value lost per unit of time (for example, dollars per week)
For a benefit that accrues steadily, estimate the annual value and divide down to the period you sequence in. A project worth 240,000 dollars a year has a cost of delay of 20,000 dollars per month, or about 4,600 dollars per week. Where delay also carries a one-off penalty, a missed regulatory deadline, a lost contract, a fixed fine, add that to the running figure for the periods after the deadline. The output you want is a rate: value at risk per week or per month, per project, on a comparable basis.
How do you calculate cost of delay?
Calculate cost of delay in four steps, and accept estimates rather than chasing precision you do not have:
- Estimate the value. Annual revenue, cost saving, risk reduction, or benefit the project delivers once live. Use the same value basis you use in the project business case so the numbers reconcile.
- Choose a time unit. Weeks or months, matching the cadence you actually sequence and fund in.
- Convert value to a rate. Divide annual value by 52 or 12 to get value per week or per month. That rate is the linear part of the cost of delay.
- Add non-linear penalties. If there is a deadline, contractual date, or step change in value, layer that on for the periods it applies. A project whose value collapses after a regulatory date has a cost of delay that jumps sharply at that point.
Do this for every project competing for the same capacity, and you have a common currency for urgency. The relative ordering is the durable output. Even if every absolute figure is off by 20 percent, the ranking between projects usually holds, and the ranking is what you need.
What are the four cost of delay profiles?
Reinertsen observed that delay does not cost the same shape over time. Four profiles cover most real projects, and knowing which one applies changes how hard you should push to start.
| Profile | How the cost behaves | Typical example |
|---|---|---|
| Linear | Steady loss for every period of delay | A feature that earns a fixed amount per month once live |
| Fixed date | Little cost until a deadline, then a cliff | A compliance change due on a regulatory date |
| Expedite | Very high, urgent cost from day one | A production outage or a time-critical market window |
| Standard (intangible) | Low now, rising later, hard to quantify | Technical debt or a usability gap that compounds |
Swipe to see more →
The trap is the standard, intangible profile. Because its cost is low and fuzzy today, it loses every prioritization fight to the linear and fixed-date work, and the delay quietly compounds until it becomes an expedite. Naming the profile forces that conversation before the cliff, not after.
What is CD3 (cost of delay divided by duration)?
CD3, cost of delay divided by duration, ranks work by how much value each item unblocks per unit of time it occupies your capacity. You divide each project's cost of delay by how long it takes to deliver, and you do the highest result first. It formalizes an intuition good schedulers already have: a quick job that stops a large bleed should jump ahead of a slow job that stops a small one.
An illustrative comparison. Project A has a cost of delay of 20,000 dollars a month and takes 4 months, giving a CD3 of 5,000. Project B has a cost of delay of 12,000 dollars a month and takes 1 month, giving a CD3 of 12,000. Project B is smaller and less valuable in total, yet it should go first, because it clears far more value per month of the capacity it consumes. Sequencing by total value alone would have picked A and left money on the table.
What is the difference between cost of delay and WSJF?
Cost of delay is the value lost per unit of time; WSJF (weighted shortest job first) is a scoring model that divides cost of delay by job size to produce a prioritization score. In other words, cost of delay is the numerator and WSJF is the full fraction. CD3 and WSJF are the same idea; WSJF is the name SAFe gives it and it approximates cost of delay from three components (business value, time criticality, and risk reduction or opportunity enablement) rather than a single dollar figure.
Use raw cost of delay when you can estimate value in money and want the honest economic figure. Use WSJF when money estimates are unreliable and a relative scoring proxy is good enough, which on a fast-moving backlog it often is. The full mechanics of WSJF, including how the three components are scored, live in the weighted shortest job first guide, alongside RICE and weighted scoring.
How do you estimate cost of delay when nobody knows the value?
Ask the sponsor what they would pay to have it a month sooner, rather than what the project is worth. Willingness to pay for time is a question business owners can answer from experience, while total lifetime value is a finance exercise they usually cannot do on the spot. The answer to the first question is already a cost of delay, expressed in the unit you need.
This reversal is the single most useful trick on this page, and it exists because the standard approach fails at the first meeting. You ask for annual benefit, the sponsor says it is hard to quantify, the conversation dies, and the portfolio goes back to sequencing by whoever spoke last. The reverse question sidesteps the estimate entirely. "If I could hand you this four weeks earlier, what would that be worth to you?" produces a number, an argument about a number, or an admission that it would not be worth much. All three outcomes are more useful than silence.
Different situations call for different framings. Pick the one that matches what the sponsor actually knows.
| Situation | Question that gets a usable number | What the answer gives you |
|---|---|---|
| Revenue-generating work | What does a month of this running produce in revenue or margin? | A direct linear rate |
| Cost-saving work | What are we spending every month that this removes? | Avoided cost per period |
| Sponsor cannot value it at all | What would you pay to have it four weeks sooner? | Willingness to pay, already a delay rate |
| Deadline-driven work | What happens on the day we miss the date, and what does that cost? | The size of the cliff, plus the date |
| Nobody will commit to any figure | Which of these two projects would you rather have first, and by how much? | A relative ranking, which is what you needed |
Swipe to see more →
That last row matters more than it looks. Cost of delay is used to order a queue, and an order can be built from pairwise preferences without anyone naming a dollar figure. If the sponsors consistently prefer A to B and B to C, you have a sequence. Absolute numbers make the sequence auditable and let you compare across departments, but they are a refinement, not a prerequisite.
The delay bill shows what your queue costs every week
Once you have delay rates for the work in your pipeline, one number falls out that almost no portfolio calculates: the total cost of delay of everything approved but not yet started, per week. Call it the delay bill. It is what the organization is paying, every week, to hold a backlog it has already decided is worth doing.
The calculation is straightforward. Take every initiative that has passed prioritization but has not started, sum their weekly costs of delay, and publish the total alongside your pipeline report. A portfolio holding fourteen approved initiatives at an average of 6,000 dollars per week of delay is running a delay bill of 84,000 dollars a week. That figure changes the conversation about whether to hire, whether to stop something, and whether the backlog is a healthy queue or an expensive parking lot.
Read it as a trend against your own history rather than against an industry number, because the absolute size depends entirely on how big your portfolio is and how generously you estimate. What you are watching is the direction and the ratio.
| Reading | What it usually means | What to do about it |
|---|---|---|
| Delay bill flat quarter over quarter | Intake and completion are roughly balanced | Nothing. This is the healthy state |
| Delay bill rising while headcount is flat | You are approving faster than you deliver | Tighten approval, not delivery. The problem is upstream |
| Delay bill larger than the annual cost of the delivery teams | The queue is worth more than the capacity holding it | A genuine hiring or outsourcing case, with the arithmetic attached |
| Delay bill dominated by two or three items | A small number of high-value items are stuck | Unblock those specifically. Do not reorganize the whole queue |
| Delay bill cannot be calculated | Nothing in the pipeline has a delay estimate | Estimate the top ten only. That is enough to act on |
Swipe to see more →
One honest caveat. The delay bill overstates reality whenever the queue contains work that would not really start even with more capacity, because it is waiting on a vendor, a decision, or a dependency instead of on people. Strip those out or mark them separately, or the number becomes a lobbying tool rather than a management one, and it will be dismissed the first time somebody checks it.
A worked sequencing example comparing value order with CD3 order
The reason to do any of this is that the order changes. Here are five initiatives competing for one delivery team, with total value, estimated duration, weekly cost of delay, and the resulting CD3. The figures are illustrative, chosen to show the effect rather than drawn from a specific organization.
| Initiative | Total value | Duration | Cost of delay per week | CD3 | Rank by value | Rank by CD3 |
|---|---|---|---|---|---|---|
| Billing platform replacement | 1,200,000 | 40 weeks | 23,000 | 575 | 1 | 4 |
| Self-service returns | 420,000 | 8 weeks | 8,100 | 1,013 | 3 | 2 |
| Pricing rules engine | 310,000 | 6 weeks | 5,900 | 983 | 4 | 3 |
| Regulatory reporting change | 180,000 | 5 weeks | 15,000 | 3,000 | 5 | 1 |
| Warehouse integration | 650,000 | 30 weeks | 12,500 | 417 | 2 | 5 |
Swipe to see more →
Sequencing by total value puts the billing platform first and the regulatory change last. Sequencing by CD3 exactly inverts that. The regulatory change is the smallest item on the list and it goes first, because it bleeds 15,000 dollars a week and it clears in five weeks, so starting it costs almost nothing in queue time and delaying it is expensive. The billing platform is the most valuable initiative in the portfolio and it should still not go first, because forty weeks of holding everything else behind it costs more than the forty weeks of its own delay.
That is the whole argument for the method in one table. It is also why the biggest project so often turns out to be the wrong thing to start first, and why portfolios that sequence by importance quietly destroy value while feeling responsible.
How do you calculate cost of delay for compliance or technical debt work?
Use avoided cost for compliance and the expedite threshold for technical debt. Compliance work has a real, datable penalty, so its delay cost is near zero until the deadline and then equals the fine or the business you cannot legally do. Technical debt has no natural date, so instead ask at what point you would drop everything to fix it, and work backwards.
The expedite threshold test is the practical way to price intangible work. Ask the engineering lead a single question: what would have to happen for this to become the only thing we work on? The answers are usually specific, such as a second outage in a quarter, a failed audit, or the moment onboarding a new developer takes longer than a month. Each of those has an estimable cost and a rough probability by date. Multiply and you have a rising delay curve rather than a shrug, and the work stops losing every prioritization round to items that merely happen to be countable.
This matters because the standard, intangible profile described above is where portfolios accumulate their worst problems. The cost is genuinely low today, so the work never wins, and it keeps not winning until the profile flips to expedite and the organization pays the cliff price. Pricing the threshold in advance is how you get the conversation to happen while it is still cheap.
How accurate does a cost of delay estimate need to be?
Accurate enough that the ranking does not move when the numbers do. Run a rank stability check: take your estimates, vary every one of them by 30 percent in the direction that hurts most, and re-sort. If the top three items are still the top three, your estimates are good enough to act on and refining them is wasted effort.
Most teams over-invest here because the numbers feel invented and they want to make them defensible. The stability check reframes that. You are not trying to be right about the value, you are trying to be right about the order, and order is far more robust than magnitude. It is common to find that estimates would have to be wrong by a factor of two or three before the sequence changes, which is a much easier standard to meet and a much easier thing to defend in a governance meeting.
When the check fails, and the top of the list reshuffles under a modest perturbation, that is genuinely useful information too. It tells you those items are effectively tied, and the choice between them should be made on grounds the model does not capture, such as team readiness, dependency risk, or the fact that one of them unblocks three others. Do not spend another two weeks refining the estimates to break a tie the estimates cannot break.
Where cost of delay goes wrong
The method fails in a small number of repeatable ways, and most of them are about units or about who supplied the number rather than about the arithmetic.
| Failure | How it shows up | The fix |
|---|---|---|
| Mixing rates and totals | One project scored in dollars per week, another in lifetime value | Force every entry into the same per-period unit before comparing anything |
| Sponsors estimate their own delay cost | Every project turns out to cost a fortune per week | Have one person normalize all estimates, or score them side by side in one session |
| Duration measured differently across items | CD3 favors whoever quoted the most optimistic timeline | Define duration once: elapsed weeks from start to benefit, not effort |
| Ignoring the profile | Fixed-date work sequenced as if it were linear, then expedited late | Tag the profile on every item and re-check dated items each cycle |
| Counting value that will not be measured | Delay costs that never appear in any later benefits report | Tie the value basis to the business case and revisit it after delivery |
| Scoring the whole backlog | Weeks spent estimating items that will never be funded | Estimate only what is genuinely competing for the next slot of capacity |
Swipe to see more →
Is cost of delay the same as opportunity cost?
They are closely related but not identical. Opportunity cost is the value of the best alternative you gave up by choosing this project. Cost of delay is the value lost by finishing this specific project later than you could have. One compares different choices, the other prices time on a single choice, and in a capacity-constrained portfolio the two meet: the opportunity cost of starting the wrong thing first is exactly the delay cost you inflicted on everything behind it.
Why is cost of delay important in a portfolio?
Cost of delay matters because portfolio sequencing decisions are usually made on the wrong variable. Teams fund the biggest project, the loudest sponsor's project, or the one that is easiest to estimate, and they treat the order of delivery as a scheduling afterthought. But the order is where most of the value is won or lost. Two portfolios with the same projects and different sequences produce different amounts of value, and the difference is the sum of avoidable delay costs.
The common mistake is treating cost of delay as too hard to estimate and therefore not estimating it at all, which defaults you to a worse method. A rough figure that changes the sequence beats a perfect figure that arrives after the decision. Fold the estimates into how to prioritize a project portfolio, and make sure the value you assume is the value you later measure in benefits realization management, or the numbers become fiction the second time you use them.