There are many different ways to approach Cost of Delay. It ranges from very simple categorisation or qualitative assessments, to more rigorous quantification of Cost of Delay. None of these is inherently “wrong”. (Rarely are things as black and white as that.) That does not mean they are equal, however. Some approaches to Cost of Delay are a lot more useful to us than others.
It also depends what decisions you are trying to make. Cost of Delay is a useful input to many decisions we frequently find in Product Development. There is much more to it than simply better prioritisation – although this tends to be one of the most obvious applications. It is a shame that prioritisation seems to be the only decision that people focus on, however. As always, Don says more, with fewer words, than anyone else:
“We need Cost of Delay to evaluate the cost of queues, the value of excess capacity, the benefit of smaller batch sizes and the value of variability reduction. Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organisation.” – Donald G. Reinertsen
Unfortunately, you only get what Don is highlighting above if you actually quantify the Cost of Delay. Let’s start at the bottom end of the scale of usefulness and work our way up, looking briefly at each approach in turn.
1) Ignore Cost of Delay (e.g. HiPPO, MoSCoW, Value over Effort, ROI, BCR, etc)
In many cases, this is the current situation. Most organisations have no real understanding of what Cost of Delay is for the things they are working on. If this is the alternative, then any of the approaches above this are an improvement of sorts. Even a relatively poor categorisation or qualitative approach is better than the status quo you tend to find.
There are many different ways to focus on something other than Cost of Delay. It is rare, however, that there isn’t some attempt to categorise or rank things. The usual suspects are things like:
- MoSCoW (Must have, Should have, Could have, Would have). Problem with this is that the majority tends to end up in the “must have” category. (DSDM even specifies up to 60% of total effort can be “must have”).
- Value over Effort is popular with Scrum practitioners, usually with Fibonacci sequence in place of real numbers. Takes no account of the impact of time on the value, however.
- Return on Investment (ROI) and Benefit Cost Ratio (BCR) and other ratios are the sort of thing you get from Finance people, since this is the stuff that B-schools teach – along with the myth that capital is scarce. The good news is that these quantification methods contain many of the inputs that can be used for quantifying Cost of Delay. (They’re also not afraid of using real numbers, something that I.T. folks seem petrified by.)
- Highest Paid Person’s Opinion (HiPPO) is rarely something that an organisation would admit relying on, but it often heavily influences whatever system is prescribed. If there is no system, you generally find a very strong HiPPO component to the way decisions get made. Startups in particular are some of the worst offenders here. Large corporates come in a close second though.
With all of these you can often observe a “fudging” to handle cases where it is obvious to everyone that the Cost of Delay is very high. For example, severe production defects are often handled as exceptions. In other cases, the numbers get massaged to reflect our “gut feel”. This fudging and massaging might be ok if people had good intuition about Cost of Delay, but unfortunately there is no evidence that our intuition about Cost of Delay is any good.
Unfortunately, for the vast majority of the work organisations do, the Cost of Delay is effectively ignored.
2) Cost of Delay in Name Only (e.g. SAFe’s current formula)
In an admirable attempt to make Cost of Delay easy to use, SAFe has a simple formula for it, which includes a parameter they call “Time Criticality”. This gets added to two value parameters (all using relative Fibonacci sequence). How this formula was derived isn’t clear, but it doesn’t bear much scrutiny. At least they acknowledge that Cost of Delay is important, and I’m sure their intentions are good – but it needs an iteration before it can be recommended. (See here for the smallest possible tweak so that it at least makes sense).
Whether SAFe’s formula is better than ignoring Cost of Delay is debatable. In some cases it will almost certainly be worse (see here and here). Looking on the positive side, at least it is introducing Cost of Delay to a wider audience. Let’s hope the SAFe community adopts some suggested simple improvements!
3) Categorisation by Urgency (e.g. Classes of Service)
The most common example of categorisation by urgency is probably “Classes of Service”. At some point in their history these were given four urgency profiles. The problem is that it’s not always clear what units are on the vertical axis, and the scale is also missing. This limits their usefulness somewhat. The biggest problem with this approach (from the perspective of understanding Cost of Delay) is that simple categorisation of Cost of Delay by urgency profile alone doesn’t really work because of its distribution.
For example, an option where the Cost of Delay is a constant $900,000/week should really be scheduled urgently and well before an option where the Cost of Delay is $100/week today and increasing at a rate of $100/week each week. Based on the urgency profile alone though, the latter best matches the “expedite” curve, whilst the former is closer to the “standard” or “fixed date” profiles. We could go further, but in short, whilst Classes of Service are incredibly useful in terms of communicating how work will be processed, it’s not terribly useful for communicating the Cost of Delay.
Urgency is “necessary, but not sufficient” in understanding Cost of Delay. Yes, the shape of the urgency profiles are indeed important, but because Cost of Delay in our portfolios has a power law distribution you can immediately see that scale (which is only revealed when quantifying the value side as well) is just as important. You can’t bake a cake with yeast alone.
4) Qualitative Cost of Delay
Now we are at least getting to the point where we are combining some understanding of value AND urgency. However, there are some people who seem very scared of real numbers. To help them get started despite this affliction, we’ve proposed a very simple 3×3 matrix qualitative approach to Cost of Delay. In the same vein, we have also suggested the smallest possible change to SAFe’s Cost of Delay formula (using the current inputs) that could potentially bring it up to a similar level.
Qualitative Cost of Delay approaches suffer from three main challenges, however:
- We are left with Apples and Oranges comparisons. Subjective, qualitative assessments cannot be used to inform most of the trade-off decisions we see in product development. Usually, these decisions involve spending real money in order to speed up development. If you’re trading off money for time, it really helps if you know what that time is worth to you in the same currency you are spending. (You might even consider this a fiduciary responsibility.)
- Even for an individual, it’s difficult to hold more than 20 potential options in our heads using a qualitative approach. At some point, it gets hard to remember why one was more (or less) than another. Unless you capture some objective reasoning, you’re likely to start losing track of the basis on which you made the assessment in the first place.
- You cannot compare qualitative Cost of Delay assessments between two different people. This of course is the norm in most large organisations. One person’s “High” will be another person’s “Medium”. Putting Fibonacci numbers on it doesn’t make this any better. It might be possible to normalise these subjective opinions to a common or shared scale. This would at least improve the use of a qualitative Cost of Delay across a larger portfolio of options. It would be very time consuming to maintain though, as it would need to be repeated frequently enough to handle incoming demand. Going to the next step would be more practical, and would also solve points 1. and 2. above.
5) Quantified Cost of Delay
By quantifying Cost of Delay we unlock a whole raft of uses. From here, we can see further and more clearly and make much better decisions. Not just better prioritisation (using WSJF or CD3), but much better trade-off decisions during development itself and for improving the system as a whole, as well as an opportunity to change the focus of the conversation.
Now we can understand the cost of large batches, the cost of queues and the value of WIP constraints. The other advantage we have seen is that making an attempt to put numbers on the Cost of Delay forces us to surface assumptions. In doing so, we are confronted with the reality that our intuition about value and urgency is very poor, until we wake up System Two thinking. By surfacing our assumptions we get a chance to disinfect them with some sunlight, by making them visible and more open to questioning.
Part of the challenge people have with this is that they are worried that the Cost of Delay estimates will be “wrong”. But again, this depends on what you are comparing it to. We don’t have to do a lot of work to improve on the accuracy of our intuition, which we know from experience is quite wrong. If we’ve learned anything from taking people on this journey it’s that people are often surprised just how easy it is once you get going. Most of what holds us back is fear of the unknown. Our intuition tells us that space travel is impossible, and so we write it off and never try it.
Summary of Cost of Delay Approaches
Below is a matrix to help visualise which of the “features” of Cost of Delay that the different approaches unlocks.
| Feature | Cost of Delay Ignored | Cost of Delay in Name Only | Categorise by Urgency Profile | Qualitative Cost of Delay | Quantified Cost of Delay |
|---|---|---|---|---|---|
| HiPPO, Value/Effort, ROI, BCR | Original SAFe formula | Classes of Services | 3×3 Cost of Delay Reformed SAFe formula | Maersk Line and others | |
| Better than random? | Yes | Yes | Yes | Yes | Yes |
| Differentiates by Value? | Yes | Yes | No? | Yes | Yes |
| Differentiates by Urgency? | No | Yes? | Yes | Yes | Yes |
| Scales to more than ~20 options? | Yes? | No | No | No | Yes |
| Scales beyond a single decision-maker? | Yes | No | No | No? | Yes |
| Maximises ROI for a scarce capacity? | No | No | No | Yes? | Yes |
| Makes the cost of queues visible? | No | No | No | No | Yes |
| Enables better trade-off decisions? | No | No | No | No | Yes |
| Changes the focus of the conversation? | No | No | No | No | Yes |
How to get started with Cost of Delay
One last point: don’t fall into the trap of thinking that the journey to quantifying Cost of Delay needs to be linear and sequential. You don’t have to start at the bottom and work your way up. There are clear benefits to be gained from the relatively small amount of additional effort to reach higher and there is nothing really stopping you from going straight there in one go.
You also don’t even have to apply it everywhere: you can try it out with just one outcome, initiative, project or feature, or perhaps work with just one Product Owner or Product Manager to apply to their part of the portfolio.
Give it a try. You just might surprise yourself.