What is Cost of Delay?
Cost of delay (CoD) is a prioritization framework that helps a business quantify the economic value of completing a project sooner as opposed to later. Product teams use this approach to calculate and compare the ongoing monetary costs that would result from delaying the completion of each initiative on the team’s backlog.
Here’s a simplified version of how to calculate the cost of delay:
1. Estimate the revenue per unit of time (say, monthly) that a new project will generate.
2. Estimate the amount of time your team will need to complete the project.
3. Divide the monthly-profit number by the project’s estimated time duration.
This number tells you how much money each month it will cost your organization to delay the delivery of the finished project.
Why Should Product Managers Use the Cost of Delay Approach?
As CoD expert and author Don Reinertsen famously said, “If you only quantify one thing, quantify the cost of delay.”
Here are some of the reasons Reinertsen and many other product development experts believe the cost of delay approach is so important.
It leads to more accurate estimates of the value and costs of each initiative.
Reinertsen argues that most people—even seasoned business executives—have a poor ability to estimate cost of delay. They don’t take into account all of the negative factors a delay could cause. They also underestimate the amount of time completing the project will take. As a result, their guesses about the cost of delay are usually extremely low.
Using this framework forces the organization to do the calculations to arrive at a data-backed estimate for cost of delay. Reinersten even says that it is far easier than most people expect. This estimate allows the team to make better-informed decisions when they weigh which projects to prioritize.
It helps the team better allocate resources.
As we’ve written in a previous post on why product managers should calculate cost of delay, this approach can give the product team clarity about how to use its limited development resources. As we wrote in that post:
“One of the more interesting outcomes of employing cost of delay techniques to backlog prioritization is realizing that spreading out product development resources across multiple features is sometimes a bad idea. Although this strategy does mean there will eventually be lots of features available, in the short term, there will be nothing new coming out, and therefore nothing driving incremental revenue.”
It can provide useful data points to stakeholders asking for changes in priority.
Product managers often face urgent requests and demands to add new functionality. Otherwise, they upend the strategic plan captured in the product roadmap. These urgent requests can come from executives, sales reps, investors, and other sources.
Without sound reasoning for sticking to the existing product development process, on what basis will the product team be able to turn down these demands and protect their developers from having to shift gears abruptly?
When using the approach, a PM can show stakeholders the actual economic impact of delaying their work on the agreed-upon product functionality.
When it comes to speaking with your company’s senior leadership, this approach can be particularly useful. The bottom line motivates executives, board members, and investors. Show these stakeholders that you’ve developed a cost-of-delay estimate for all of your primary initiatives. Then, your effort demonstrates that your product team is mindful of the economic impact on all of the work you’re doing. Specifically, the impact on costs to the company and in additional revenue or profit your work can generate.
Note: The cost of delay is a critical component in another popular agile prioritization framework: Weighted Shortest Job First (WSJF).
Check out the following webinar to learn more about prioritization.
Want more help prioritizing your team’s work? 