Here’s a interesting real-life story of a requirement from one of the delivery teams that I have worked with which emphasises how a focus on cost-of-delay helps.
The story concerns requirement RQ-0672 which took 46 weeks to go from being captured as a idea to being live in production. We have a fair idea of which weeks there were activities happening (green) and which weeks nothing happened (red); shown in the value stream map below (See here to learn more about value stream mapping techniques):
Observation 1: It’s pretty clear there was a lot of “waiting waste”. Most weeks, nothing happened!
We introduced the concept of cost-of-delay to this team – i.e. measuring the opportunity cost to the company for every week this requirement was not implemented. This turned out to be $214,000 per week. Cost-of-delay figures often have high levels of uncertainty (particularly if the benefits of the requirements are around increasing revenue as in this case) but in this case, this number is fairly certain.
This particular delivery stream is capable of delivering a requirement like this within 13 weeks. Had this been delivered within 13 weeks instead of 46 i.e. 33 weeks earlier, this would have improved the company’s revenue by:
$214,000 x 33 = $7,062,000
Wow. Big number, particularly in the content the actual cost of making the change was around $4,200.
Obseveration 2: There can be significant value in reducing cycle time.
So why didn’t we make it happen earlier? The pipeline was setup without a focus on cost-of-delay which means there is no sense of the urgency associated with each requirement – they are all treated the same. Once we know the urgency, then we know what trade-offs to make.
In this case, you could say that it makes sense for the company overall to spend up to $214,000 for every week we could bring forward the go-live date for this requirement. You can also see from the value stream mapping that there was a proof-of-concept done for this requirement. This proof-of-concept took a week to execute – plus some mobilisation time – probably several weeks – hard to know exactly. Lets say 2 weeks mobilisation for the sake of argument. The cost of delaying the go-live by 3 weeks to do the proof-of-concept was:
3 x $214,000 = $642,000
The purpose of this proof-of-concept was to be able to accurately estimate the cost of the change. Remember, this change actually came in at a cost of $4,200. Given the enormous benefits, it would still have made sense for the company to implement this change if the cost had come in at $4,200,000. Perhaps we should have skipped the proof-of-concept stage for this requirement!
Observation 3: Not all estimating activity is truly value-adding
I have selected an extreme example of course. Even so, its real. It happened. It serves to emphasis that some requirements have high cost-of-delay which needs to be managed. A good innovation process design should expedite these types of requirements by:
Prioritising quickly based on cost-of-delay (ideally within a week)
A frequent “pull” of the top requirement from the top of the dynamic prioritised list of requirement
- Fast cycle time from the time of “pull” to go-live through a pipeline which is not clogged up with too many other requirements