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?
Cost of Delay is a way of communicating the impact of time on the outcomes we hope to achieve. More formally, it is the partial derivative of the total expected value with respect to time.
This 3 minute video hopefully explains why quantifying Cost of Delay is so important in Product Development:
Don’t be confused
You may hear a lot of people talk about Cost of Delay, but it’s not always clear what people actually mean. Some talk about it as a classification of urgency profiles alone, or worse, a nonsensical formula. Unfortunately, this boils the essence out of Cost of Delay, watering it down to something much less useful. What you don’t often see is people attempting to actually quantify it.
You may also observe people wrongly thinking it is simply a different way of prioritising – but that’s only one of the reasons why you might want to quantify the Cost of Delay.
Why it matters:
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.
Why is it urgent?
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? It’s one thing for an organisation to be blind to queues. It’s another layer of blindness to have no clue what those queues are costing. We need to understand the Cost of Delay of the things flowing through the system.
Why is it the “one thing” to quantify?
When developing new or improved products and services, understanding the Cost of Delay helps in three main ways:
1. Better Decision-making – by making the economic trade-offs visible. These trade-off decisions are an inherent part of the creative process, where we desperately need fast feedback about what works and what doesn’t. There are also lots of trade-offs at the system level, where understanding the Cost of Delay is a key part of managing the flow of work.Whether it is experimenting with WIP limits, controlling the length of queues, optimising batch sizes at various points or trying to work out appropriate levels of capacity utilisation, Cost of Delay is the one piece of information you really need.
2. Better Prioritization – by using CD3 (Cost of Delay Divided by Duration) we deliver more total value. We don’t have an infinite capacity to develop everything we want, so we have to control the demand somehow. We need to decide where to start, what order we should do things in, and perhaps most important, when to stop and move on to something more valuable and urgent. If you want to move on from prioritisation by gut-feel, you need the Cost of Delay.
3. By changing the focus – from efficiency and cost (which encourages the wrong behaviours), to speed and value. It’s no good asking people to not do something (like estimating cost or delivery dates) if you don’t give them a viable alternative that actually helps them. By talking in terms of Cost of Delay, you get more of what you want and less of what you don’t.
Put simply, Cost of Delay is a way of communicating the impact of time on value. It combines urgency and value, 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.
For this Urgency Profile, Cost of Delay is shown on the y-axis. The area between the two curves is the Delay Cost incurred. Cost of Delay is a rate (per week or per month usually) and can change over time. Delay Cost incurred is the cumulative sum. Be careful to observe the units on the y-axis!
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 other urgency profiles, 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?
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 4: Combine the estimated peak benefits and your understanding of the urgency to produce an estimate of the Cost of Delay, usually in $/week or $/month.
If you’re really struggling with estimating the peak benefits you may want to talk to someone in your Finance department. Given that we are usually investing real money in the things we are developing, there is usually some sort of quantification of expected benefits. If you’re still struggling, you could try this qualitative approach to help you at least get familiar with the key parameters.
If you want to learn about using Cost of Delay for prioritisation, read here and here for an introduction to CD3 to see how it works. PLEASE, don’t get stuck there though: Cost of Delay is not just about improved scheduling – it’s also a vital 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 those benefits. And it’s not like these decisions won’t get made anyway, they will – they will just be based on hidden assumptions (gut-feel) rather than shared ones.
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.
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 isn’t bad.
Lastly, if you have a question, or would like help with any of this, feel free to drop us a note below.