Don Reinertsen frequently talks about how surprised teams are when they first try to quantify the cost of delay on one of their projects/programs and an exercise he runs to help surface the wide range of intuitive estimates of the cost of delay amongst the team and how a little bit of analysis can help get a much better figure. Inspired by my “Cost of Delay”-themed last week (when I had a hefty amount of Don time spiced up by meeting Joshua Arnold face to face and spending some time with him) I decided to bring the Cost of Delay topic more explicitly into a management thinking workshop I had with a HW/SW Product Development company this week. When I tweeted about the experience it got a couple of retweets as well as a request for more details.
First time I ran @DReinertsen cost of delay intuition exercise got range of 0-16M$ 🙂 and great discussion of assumptions and CoD curves.
— Yuval Yeret (@yuvalyeret) November 11, 2014
@yuvalyeret Would love to know more about how you went about it.
— Andrew Doran (@adoran2) November 13, 2014
I couldn’t find a canonical description of the exercise so here is a short facilitation guide below. I hope this helps. And again, to be clear, this is just going through what I learned from Donald Reinertsen in the Lean Product Development 2nd Generation workshop last week.
Running the Cost of Delay Intuition Exercise
After spending a bit of time explaining the need and potential for thinking about product development as a flow-based design factory I explained the need to quantify the Cost of Delay in order to be able to effectively weigh the tradeoff of things like Holding Cost and Transaction cost when deciding upon Batch Size. I mentioned Don’s results when asking teams what would be the Cost of a 1-month Delay on one of their programs and asked them if they want to try that exercise themselves. They were quite enthusiastic to try.
We chose a relatively big project in their portfolio. We had the finance people in the room so it was easy to get the projected total life-cycle profit for that project which was
around 16M$. I then made sure we all understand the scenario – the product will be delivered and available for the customers to integrate one month later than originally planned for.I DIDN’T hold any discussion with them about profit curves over time etc. since I wanted them to think fresh of their own assumptions.
I then asked each participant to think what the impact would be on the total life-cycle profit and write the answer to himself without sharing or consulting with his peers. We then collected the results by doing a round-robin poll of the group. The range was 0-16M$ (How’s that for a wide range???) with most answers ranging between 15
0K and 2M$. So even ruling out the 0 the range was 1-100. At that point we asked some of the extremes to explain their assumptions and way of thinking and I drew some accumulated cost of delay curves to help picture the different alternatives.
After a bit of discussion it became clear that the 16M$ was based on a “lose the opportunity window entirely” which can happen if you’re aiming for a big design win without any other market opportunities for that product (Think aiming to deliver the iPhone display and delivering late… ). This came from one of the senior guys in the room. The other extreme of zero impact basically assumed that the sales/evaluations ramp-up was slow anyhow and they could make do with hand-waving and expectations management to avoid losing any deals due to the delay. The finance and product management people estimated the number to be around 1-2M$.
That was it. The exercise took around 15-30 minutes I believe and was well worth the time. In the retrospective at the end of the two days Cost of Delay was mentioned as one of the A-Ha moments. I found that having this discussion was also a great way for me to gain insight into their ecosystem and way of working. It surfaced issues around customer expectations and interfaces very quickly.
I’m glad I used this exercise and will probably use it often moving forward.