Determining value using Cost of Delay

This short blog post is the last one of three this week in which I explore methods for determining which features are valuable.

In the previous parts, we covered the following:

Value Poker – a technique for estimating the relative value between features

Impact Mapping – a visual planning technique that helps us prioritise based on how each feature contributes to our objective

Arguably, both these techniques are largely subjective. We make assumptions based on intuition, saying “this is more valuable than that”. Hopefully, we then validate these assumptions as early as possible during the build.

In this part, we’ll be looking at how to quantify the value more objectively: the Cost of Delay.

What is Cost of Delay?

The idea behind Cost of Delay is to calculate the impact different delivery dates have on the financial bottom line. For instance, this analysis is useful when determining in which order to tackle our deliverables to maximise value.

Why use this method?

“Urgent” and “valuable” are two very different things. Just because something is more urgent than something else doesn’t necessarily mean that we should do it first – or at all! By calculating the Cost of Delay, in monetary terms, we can more objectively weight alternatives against each. Either to allow us to decide which option to pursue or the order in which to tackle them.

How to use it

The first when using Cost of Delay is to create a model describing how the value of each of our options is affected by the delivery date. We then use these models to compare different scenarios.

Cost of Delay is typically made up of the business value of the feature, the decay of that value over time and the value of information discovery (e.g. avoiding the risk of additional costs).

Depending on what it is we’re analysing, the Cost of Delay will look different:

Long life-cycle, peak unaffected by delay – For example, let’s say that migrating to a new hosting provider will save us £500 per month. Delaying this migration will cost us £500 each month we delay.

Long life-cycle, peak affected by delay – In some cases, a delay will limit how much revenue we will be able to make. For example, a competitor beating us to market might mean we won’t be able to get as many customers as we otherwise would.

Short life-cycle, peak affected by delay – When the opportunity has got a short lifetime, a delay will significantly limit how much revenue we are able to make. A website selling merchandise for the Rio 2016 Olympics would have missed much of its potential revenue if it didn’t launch until the second week of the competition. After the closing ceremony, there would probably be little point launching at all.

An example how to calculate the Cost of Delay

Let’s say we have an old legacy system which has a monthly support cost of £3,000 and that are deciding between two options:

Spend 3 months to migrate the functionality to using our new system, where the support cost would be £1,000 per month. This would save us £2,000 per month.

Keep using the old system a while longer. Instead, spend 5 months building a mobile app, which will give us £3,000 additional revenue per month once finished.

Final thoughts

This is just a very brief introduction to Cost of Delay. I recommend further reading before putting this method into practice.

I was first introduced to the concept of Cost of Delay in a Adventures With Agile meetup with Don Reinertsen, which is available on YouTube. This is a good watch if you want to learn more!

The obvious challenge with this method is to create the models to describe the Cost of Delay. Don’t let this put you off, though. As with the methods discussed in previous posts, the process itself is a useful exercise to learn more about what value means for our product.

Have you been using Cost of Delay? Was it useful? Please share your experiences in the comments below.