In Part 1 of this series, I showed how frequent releases and prioritizing features increased the value of a project. In this Part 2 we’ll see what happens when things don’t go exactly according to plan.
First, here’s the main data for the project as outlined in Part 1:
- It is scheduled to last for 12 months
- During that time it costs 5 million USD
- The resulting product will provide a financial benefit of USD 200,000 per month (extra revenue or saved costs minus any monthly expenses), until
- The product abruptly stops producing its benefit 4 years after the project is started. You may say there’s a 4-year window of opportunity for this particular product.
- (I also assume a 10 percent discount rate in the NPV calculations)
Baseline: Waterfall As Planned
We’ll reuse the baseline project from Part 1. If all goes according to plan, the product is released after 12 months and will generate 36 months x USD 200,000 = USD 7,200,000. The project will have cost 5,000,000. All in all, a nice net profit of 2,200,000.
This is what the cash flow will look like:
|Break Even||37 months|
|Net Present Value (NPV)||USD 920,000|
|Internal Rate of Return (IRR)||20,7 %|
Yikes! A Four Month Delay
The alarm goes – the project is going to be 4 months delayed! Suddenly, the project doesn’t look so good…
|What||Waterfall, as planned||Waterfall, 4 months delay|
|Break Even||37 months||Never|
|ROI||44,0 %||-4,0 %|
|Net Present Value (NPV)||USD 920,000||USD -1,280,000|
|Internal Rate of Return (IRR)||20,7 %||-2,0 %|
The product, when released, doesn’t bring any less benefit on a monthly basis. However, it starts producing the benefit four months later and is still abruptly put out of production four years after the project started. What’s more, the development of the product is more expensive. Net effect? The value of the project, NPV, is negative. The initial investment is never paid back. The project is no longer financially sound.
Frequent Releases to the Rescue
Let’s say we’ve already managed to prioritize the functionality and that 20% of the functionality provides 80% of the value. Also, say we’re sticking to a “release every 3 months” strategy. Will that save a project that isn’t proceeding as fast as it should? In this example case: Yes!
|What||Waterfall, as planned||Waterfall, 4 months delay||Frequent releases, 4 months delay|
|Break Even||37 months||Never||39 months|
|ROI||44,0 %||-4,0 %||29,8 %|
|Net Present Value (NPV)||USD 920,000||USD -1,280,000||USD 796,000|
|Internal Rate of Return (IRR)||20,7 %||-2,0 %||20,0 %|
As we can see, the project is turned from a waste of money into something profitable. Even though the total delay still hits us, the early release means we start to get some benefit early, and the project doesn’t look so grim. In fact, the “frequent release” project with a four month delay is nearly as profitable as the waterfall project would be without any delays! How’s that for a risk reduction strategy?
In the next article, which might be viewed as part 3 of this series, I’ll take these concepts to their logical endpoint: What if we only develop and release the 20% most valuable parts of a product, and then move on?