What Is Cost of Delay?

Don Reinertsen famously refers to cost of delay as the “golden key”. It helps you expose and estimate the cost of queues, make smarter tradeoff decisions, and get far better at prioritization. In short, it is a valuable tool that should not be ignored. Many people nevertheless find this concept confusing. In this post we’ll dive into what it is and how to can be leveraged. In the next post we’ll discuss ways to estimate it.

Cost vs. Delay Cost

A good way to understand delay cost is to compare it to traditional cost. Cost is how much money you pay to do something, whereas delay cost is the change in lifecycle profit if a piece of work is late. Basing decisions on cost alone often leaves value on the table. As an example, imagine you are sequencing three items, shown below. Your product team could do any of them in month, at a cost of $200K.

Though their “cost” is the same, what would happen if you prioritized Option X first? By prioritizing X, you are also delaying Y and Z. That delay has an additional cost. Delaying Y four weeks costs $8MM. Delaying Z four weeks costs $2MM. By prioritizing X first, even though they “cost” the same, you’re now out $10MM. (Your boss should not be impressed.) When the value being lost from delay is exposed, traditional cost often becomes chump change.

Now, you may have heard the objection that traditional cost is “real” whereas delay cost is not. Don’t let this fool you. The cost of delay is also real—it’s just typically left unaccounted for. You may have also heard the claim that since value cannot be known up front that focusing on delay cost is a waste of time. This argument, which is exceedingly bizarre, was addressed here. For present purposes just note that you do not need precise predictions to make better tradeoff decisions.

As Joshua Arnold points out, the practice of simply facilitating cost of delay conversations greatly improves prioritization practices and helps to shift the focus from cost avoidance to value amplification. Further, such assumptions about value are already there, baked into the work—they’re just typically invisible. Anything you can do to surface and expose them and replace intuition with information and diverse opinions will add value.

Incidentally, this goes both directions. If an option has negative ROI, and many do, then delaying it (ideally forever) creates value, in which case there is a benefit of delay. You maximize the benefit of delay and minimize the cost of delay by making smarter bets, by capturing and challenging the assumptions being made and leveraging quick research to derisk them.

Queues

Estimating cost of delay allows you to expose the otherwise hidden cost of queue time (a.k.a. “wait waste”). Consider what Reinertsen calls the “Urgency Paradox”, shown in the image below (adapted from Joshua Arnold). In this example there are 32 weeks of lead time. The Urgency Paradox describes the fact that organizations are typically only concerned with the velocity of Time B, ignoring that the cost of delay for Time A is the same.

Once a team begins work suddenly everything is “urgent”, ignoring that allocating work to a product team does not somehow magically change its delay cost. Time A, what Reinertsen calls the “fuzzy front end”, typically accounts for 80% of total lead time. Thus, focusing only on Time B is an expensive mistake. Work is not “free” simply because no one is working on it!

Tradeoffs

As the above example illustrates, if you aren’t paying attention to cost of delay, then you have no idea how much queue time is costing you. This is made worse by the fact that product work queues are not physical items—they are largely invisible. Because of this it is easy to neglect the cost of queues while overestimating the benefit of keeping people busy.

Managers tend to assume deterministic, factory-like conditions, where capacity utilization is fine until it hits 100%. Product work, however, is not like this. Here, increasing utilization past a certain point greatly increases queue length. Ignoring this, most managers try to minimize cost by removing excess capacity. This adds to the length of queues and significantly increases costs.

As shown above, since the tradeoff between capacity and queue cost is a U-curve, optimization does not occur at either extreme. As Reinertsen observes, the good news is that this curve has a long flat bottom, which means you don’t need to be very accurate in your estimates in order to improve your economics.

Prioritization

Cost of delay also makes clear that queue cost depends on how work is batched and sequenced. Large batch sizes cost more, plain and simple. They result in slower feedback and reduced quality. Annual budget cycles institutionalize large batches at the project level, often starting projects simultaneously. One of the things cost of delay makes clear is that this maximizes cost. (If you have four projects, then starting them at the same time is the single most expensive way to sequence them.)

This also helps you get better at prioritization. When flow is homogeneous, as it is in manufacturing, changing the sequence of work does not produce cost savings. In product work, however, both duration and cost of delay often vary. This means there’s money to be made by getting better at prioritization. Here, a WSJF (weighted shortest job first) sequencing will often cost less than FIFO (first in first out), HVF (highest value first), or SJF (shortest job first) prioritization.

Reinertsen’s WSJF can be calculated as the estimated cost of delay per unit of time divided by estimated duration. In general, the higher the delay cost and the shorter the duration the greater the priority.

Conclusion

OK, so throughout this post we’ve been talking about the cost of delay of options in a generic way, whether they be outcomes, solutions, features, what have you. This begs the question, at what level is it best to apply this concept? Joshua Arnold makes the following recommendations.

• Start with quantifying the cost of delay of outcomes, not output. Duration applies to work, which is output, not to what that work achieves, which are outcomes. How outcomes will be achieved should be kept separate from deciding which are the most value-adding to pursue.

• Allow teams to figure out how they will contribute to prioritized outcomes. Contributions may include experiments, feature sets, or even just small changes. Don’t ignore what Arnold calls “tiny wins”, those high cost of delay quick changes that are typically only discovered in a bottom-up fashion.

• Teams (or PMs) should estimate what percent of the target outcome they think their contribution will achieve. This percent multiplied by the outcome’s cost of delay then gives the numerator for a WSJF calculation.

• You don’t have to get overly fussy estimating output duration. Have teams use a rough T-shirt size of how long each option will likely block the pipeline. Use a number for Small, another for Medium, and one for Large. This gives the denominator for a WSJF calculation.

• If something has a very high cost of delay and it’s clearly a Small, just do it! If stuff is floating around the Medium or Large categories, then you can experiment and apply slicing to discover the minimal path to value.

To close, you increase value by achieving outcomes with a larger cost of delay and/or discovering faster/cheaper ways to achieve them. In general, the most value-adding work will be whatever contributes the greatest percent to the highest-value outcomes in the shortest time (smallest duration).

Leverage quick research to generate additional value-adding options for contributing to outcomes. Try slicing existing options into something smaller that still achieves the same percent of the outcome. Applying slicing at the level of experiments, features, and solutions helps achieve outcomes faster, which minimizes total cost of delay.

While duration is estimated at the level of output, note that the delay cost is explicitly tied to the outcome level. After all, the value is delivered when (and thus delayed until) the outcome is achieved, and not before. This reinforces that delivery does not necessarily mean value. All work is a hypothesis, and should be treated as such. Expressing cost of delay as the percent of the outcome achieved represents this fact nicely.

Again, don’t forget to look for “tiny wins”. Orgs typically only subject their “biggest” decisions to analysis, leaving all the rest to HiPPOs—the “highest-paid person’s opinion”. This is what Reinertsen calls the “Pareto Paradox”. As the Pareto Paradox states, there is usually far more value and opportunity to be found in the neglected 80% of “little decisions” that are left unexamined.

Finally, always make sure that you are capturing assumptions and making them visible for all to see. Move the group’s thinking from their heads out into the world. Don’t strive for precision. Make assumptions visible and expose them to the air. This will be enough to produce the rank orderings you need. Below is a template, from Sean Barrett, that can help with this.

In the next post we’ll look at ways you can estimate cost of delay.

Until next time.