Cost of Delay

What is Cost of Delay? Why is it the “one thing” to quantify? How can I quantify the Cost of Delay for my project or feature? How do I get started with actually using Cost of Delay?

Lots of people (especially in the Lean and Agile community) talk a lot about Cost of Delay. We hear it mentioned all the time. But what we don’t see so much of is people actually quantifying it. We also see them boiling it down to just a different way of prioritising – but that’s really only one of the reasons why you might want to quantify the Cost of Delay. This 3 minute video explains why:



Here is a fairly typical value stream map for a feature being delivered by a software team. If you were to track the value-add and time spent waiting in your organisation you will probably find something similar:


Seems crazy, doesn’t it? The thing is, most organisations are blind to queues. We tend to focus predominantly on the efficiency of the parts of the process, not the speed of the end-to-end delivery of value. For instance, it is normal to find approval and funding processes that are optimized for the efficiency of those doing the approving, seriously impacting the speed and efficiency of the whole system. Part of what drives this is that we have a really poor understanding of how much the delays are actually costing us.

What is Cost of Delay?

If we are to make better decisions we need to understand the value of the things we are working on, and how that value decays over time. Only then can we understand the cost of queues and all the waiting. In the value stream above, the cost of delay for this feature turned out to be worth over $200,000 per week. The 38 weeks that this opportunity spent waiting in various queues cost the organisation nearly $8m in lost revenue. Knowing this puts the cost of waiting into perspective, doesn’t it?

Why is it the “one thing” to quantify?

When developing new or improved products and services, understanding the Cost of Delay helps in three ways:

  1. Better Decision-making – by making the economic trade-offs visible
  2. Better Prioritization – by using CD3 (Cost of Delay Divided by Duration) we deliver more total value
  3. By changing the focus – from efficiency and cost (which encourages the wrong behaviours), to speed and value

Put simply, Cost of Delay is a way of communicating the impact of time on value. It combines urgency and importance, two things that humans are not very good at separating. It should matter to us to know not just how valuable something is, but how urgent it is. The value that we miss out on when we deliver late, or while waiting can be enormous. It is often far more valuable to get something even a week earlier than it is to make it slightly cheaper. These trade-offs are simply not obvious though, unless we understand the Cost of Delay.

How do I do quantify the Cost of Delay for my project or feature?

Most cases of Cost of Delay can be easily approximated using the following graph as a guide. It shows the impact of being late for a feature where the benefits are long-lived and the peak benefits are unaffected by delay. There are other urgency profiles, but this is the most common in large organisations.

cost of delay long life peak unaffected

Usually, the ramp up to the peak is the same whether we have it now, or later. By visualising the impact of delay we can easily see that it is the peak benefits that we are delaying. In cases where the peak is also affected by delay, the cost of delay can be even higher, especially if the impairment is permanent.

How do I get started with Cost of Delay?

Getting started with Cost of Delay

Step 1: Have a look here for some scaffolding to help you think about value. (Note: It’s not just about financial benefits either).

Step 2: If you want to understand more about how value decays over time, take a look at some common urgency profiles.

 Step 3: If you want to know more about estimating the peak benefits, this might help. (Be brave).

Step 4: Here is a canvas that some find is a useful guide for helping capture assumptions, and calculate the Cost of Delay (and CD3 for prioritisation).

Other things you might want to consider: the value of information; the value of options; the value of continuous delivery.

If you want to learn about why you might want to use Cost of Delay for prioritisation, read here and here to see how it works. Don’t get stuck there though: Cost of Delay is not just about improved scheduling – it’s also an important ingredient in making better trade-off decisions and for changing the focus on the conversation. If you don’t quantify it, you don’t get these benefits.

If this all sounds a bit theoretical to you, let’s be clear: this is not just theory. We’ve actually done this in lots of organisations: public and private sector, in large, medium and small organisations. We even wrote about using Cost of Delay across a $100m portfolio at a Fortune 500 company. If you need buy-in from others to get started with Cost of Delay, you’ll find some interesting before and after results that might help to make the case. In our experience, using Cost of Delay really helps to discover, nuture and speed up the delivery of value.

(See here for a primer on Cost of Delay in French, by Agnès Haasser. Thanks Agnés!)

If you want some help to introduce these concepts and help you get going with Cost of Delay we run tailored workshops designed for people leading product development (like Product Owners and senior execs) as well as teams. The feedback on this is pretty good too.

Lastly, if you have a question, or would like help with any of this, feel free to drop us a note below.

Your Name (required)

Your Email (required)


Your Message

2 thoughts on “Cost of Delay

  1. Thanks for helping spread the word that COD can be applied to IT projects. When we’ve tried to teach this, the team members often tell us they can’t estimate the value of their projects. But then they find out that management has often had to do a business case justification in order to get the project approved. That will help sort the project order and often have numbers in it that they can use to help estimate the feature level benefits within those projects. And even if the feature level benefits are wrong, they’re probably proportionally correct so at least you’ll get them in the correct order, or a lot closer to it. It may seem like work, but it’s a lot better than guessing, or worse, not caring.

Leave a Reply

Your email address will not be published. Required fields are marked *