“When does the business need it?” is far more important than “When will the developers have it ready?”. Business needs should drive schedules, 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. Its the art of the possible and its 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 need 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?”
Lets me do an example analysts 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… lets set up the scenario…
Image its Christmas 2016, at one of those family gathering 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 himself to help you, 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.
Some more analysis and you conclude competitors will steal increasing chunks of your revenue, 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 axis, 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 outcomes.
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 loosing 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-1 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 an day-1.
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 lets 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?”
Lets 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. Lets assume a perfect correlation between the percentage of product built and the revenue captured and lets 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 relaxed 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.
| Reference: | Using cost of delay to determine schedule from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
