Blog post summary: Prioritizing with Cost of Delay

Prioritizing with Cost of Delay is an article by Jeff Palmer (web, twitter, linkedin).

This article had me engrossed with the opening paragraph. It is a short article (6 minute) read, so I suggest reading it directly, but find a summary below, mainly for my own benefit.

Development teams often say things like:

• We don’t have time to fix that
• Product won’t let us fix our technical debt
• All we do is build new features

The problem, Palmer says, is that while product teams know how to quantify the financial benefits of projects, the benefits of technical projects (e.g., infrastructure upgrades, security fixes) are often described in opaque technical terms. Those hand-wavy technical descriptions make it hard to compare and prioritize even across other technical projects, never mind against feature development with defined financial impacts.

How can we better define impacts of technical projects?

Cost of Delay

“Cost of Delay” captures the idea that you can quantify the financial impact of delaying work and measure it in dollars / time unit. This can provide a consistent way to compare the impact of any type of project. Donald Reinertsen talks about the idea here (youtube.com).

This is all very well in theory, but how do you do it?

Calculating Cost of Delay for a Project

First identify the ways that the project can impact the organization. For example, those impacts could be to:

• reduce operational costs,
• reduce security risks,
• generate revenue,
• eliminate time-wasting development friction

Then create a model, to attach costs, to those impacts.

An example: Reducing Build time

The article then works through an example for calculating the Cost of Delay  for a project to reduce build times. It starts by identifying the ways that the project could benefit the org, including

• Reduction in continuous integration provider costs
• Reduction in developer “downtime”

It uses hard data such as

• the number of engineers,
• developer salaries (average),
• the current build time and
• CI infrastructure costs.

It uses estimates and assumptions for things such as

• how many PRs each developer creates per week,
• how many reviews on average each of those PRs requires

And uses a spreadsheet to put hard financial numbers on the cost of having developers wait for builds to complete.

For what it worth, it calculated that each 1 minute reduction in build time saves $300 a week or $15,000 annually.

It makes the point that the goal is not to perfectly reflect reality, but to represent the project’s impacts in a way that allows us to compare the impacts of one project to others.

How to rank project importance

The final “Prioritizing Projects with Cost of Delay” section of the article focuses on CD3 (Cost of Delay Divided by Duration). This section took my the longest to understand, particularly how the “Reduce build time” numbers related to the previous section, but once I did, it does seem like a fairly straightforward way of comparing projects’ relative importance and hence how they should be order.

 

Conclusion

If you can describe project impacts in financial terms, you can use Cost of Delay can help you understand project impacts and prioritization and advocate for technical initiatives.

 

Tags: costofdelay, summary