Using Cost of Delay to Determine Schedule

DZone's Guide to

Using Cost of Delay to Determine Schedule

Once one starts discussing business value and how potential revenue changes over time it very quickly becomes clear that business need and value should drive the development schedule, not developer estimates.

[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.

When does the business need it? is far more important than When will the developers have it ready?

Business needs should drive schedules and engineers need to create solutions which fit within business schedules. That does not mean cutting corners. It does not mean shipping with bugs or technical debt. It's the art of the possible and it's what engineers have always done.

One of the tenets of #NoProjects is that work should be guided by business benefit, better still value delivered.

That very quickly means that one needs to start talking about opportunity cost of delay. As I’ve said before, I don’t think “cost of delay” is the best name for this idea, I’d rather it was called something like “benefit foregone through delay” but cost of delay is the name we have.

Once one starts discussing business value and how potential revenue changes over time it very quickly becomes clear that business need and value should drive the development schedule, not developer estimates.

Rather than saying:

How long will X take to build?

We need to be saying:

Given that there is M money to capture, in timeframe T, what can we build for that much money in that much time and have a respectable profit left?

Time and money are inherently linked. Everyone gets that more time creates more costs but fewer people get that more time probably means less revenue.

To put this more succinctly:

How much of X can we build in time Y and how much of the total potential value M will that capture?

Let me do an example analysis to show how a cost of delay analysis — with value estimates — can be used to substitute effort estimates. So here goes, I'm putting on my economist hat... Let's set up the scenario.

Imagine it's Christmas 2016. At one of your family gatherings, you see Uncle George who works for a successful start-up. George says the back-end he has been working on is great and has a nice REST API. The start-up wants to grow an ecosystem and the company is about to open the API up to third party apps. The startup will pay a small "finders fee" from 1 February for the first few months to each of these third parties for each customer they bring in.

Back in the office on 2 January you make some calls and find everything Uncle George said is true. In fact, the start-up is falling over itself for help — they are desperate for apps.

You have an opportunity. And you have at least a four-week head start on any competitor.

Some quick "what if" calculations tell you there is €10,000 a week to be made. But you also know that competitors will come into the market the finders fee will decline. As you have a 4-week head start, you probably have 4 weeks from the start of February before your revenue starts to fall off.

After more analysis, you conclude competitors will steal increasing chunks of your revenue and you think it will decline €1,000 a week after February. Thus you can draw the following graph:

The blue bars show the weekly revenue. The red line shows the total lifetime revenue — the lifetime being from the start of February to early May. What happens after May is uncertain so to play it safe you have assumed no revenue at all.

The red line is important.

Note: this chart uses two axes, the one on the left is for the blue bars, the one on the right for the red line. The red line shows the maximum revenue you could make, it forms an upper boundary.

It doesn't matter whether you release your product tomorrow or 31 January, there is no extra revenue to be made during January. As long as you have a product in the market on 1 February, you can start to capture some value. If you have a fully functional product then you can capture €10,000 a week.

Yes, the delivery date is important, earlier is better, but so is the amount of product. Since revenue declines from March onwards delivering something smaller sooner may well make more total revenue than delivering more later. Less (functionality) may well mean more (revenue).

As you can see, releasing a product anytime before the end of January will result in €85,000 of revenue in total. After this the later the product is released the less revenue if will make. Your deadline is not a binary event, it is an elastic range of options which each produce a different outcome.

Time is money, but money is both cost and revenue. The longer you spend developing your product the greater the costs, but more importantly if the product is not in the market by 1 February you are losing revenue. The longer you go without a product the greater the costs and the lower the revenue.

This is a simple model. Like any good economist, I have confined my analysis. I have assumed "all other things being equal," specifically, I have assumed other competitors do not spot the opportunity before 1 February. I have assumed your product could grab the entire market on day one without a ramp-up time. I have also assumed that even launching in March when there are other competitors in the market, you can still grab sizeable market share on day one.

These assumptions do not invalidate the model. These assumptions may all be relaxed with a more complex model but the basic message will still be the same.

This analysis does not use any effort estimates; it does use value estimates. So let's now consider effort.

In the first instance, armed with this analysis, you go to you development team and instead of saying:

How long will it take to build this?

You say:

Given this analysis, what can we build in the next four weeks which can capture some of this value?

It is not a question of:

Can you build X?

But:

What can you build in this time for this much money?

Let's suppose you and the team quickly envisage a product — a product that can be rolled out in stages, say 10% per week. Even the first 10% will be useful. Let's assume a perfect correlation between the percentage of product built and the revenue captured and let's add this to the model.

Notice in this model it is impossible to capture all the €85,000 potential revenue because the product cannot be ready in full on 1 February. If you wait until the product is 100% complete before releasing it will be mid-March and you will only make €28,000 in total. This contrasts with the €64,400 you could make by launching with reduced functionality earlier, i.e. launching a smaller incomplete product earlier allows the capture of €36,400 more.

As I said before, I could relax some of my assumptions and enhance the model but I’m keeping this simple.

You can also play what if games, for example, what if you halted development at the half way point?

If development halted at the beginning of February at 50% done

and the product remained in use until May

then it would generate €41,500 of revenue (64% of the total that could be made)

This does not consider the savings in development costs. Perhaps more significantly, the same people would be available to work on something with greater returns.

After all the product only has an anticipated lifespan of three months. Once March arrives the product revenues are falling, why would continue to invest?

There are many directions you can take this analysis and I’m not denying the effort and cost estimates have a role to play in the complete analysis. However benefit estimates and cost of delay analysis can be performed without any effort estimates when value analysis is available it can be used to inform the effort estimation process.

[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.