I’ve outlined five potential costs of delay in the previous five posts:
- The delay from not releasing on time, part 1
- The delay from multitasking,part 2
- The delay from indecision, part 3
- The delay from technical debt, part 4
- The delay from other teams as part of a program, part 5
The real problem is this: Why should you care? Maybe you have a “sweet spot” in the way you start your projects or release them. “It just takes that long here.” (That’s the sign of a system impediment.)
Cost of Delay, Back of the Napkin
Let me show you two pictures. The first you’ve already seen, the back of the napkin, where you see the effect on your potential maximum revenue.
Now, let’s try to calculate that cost of delay.
The longer your delay, the more your cost of delay moves your curve to the right. The more sales you lose out of the Maximum potential sales.
The longer it takes for you to release, the more sales you lose from the maximum potential sales. You wait a month to release? You lose a month of max sales. You wait a year to release? You lose a year of max sales.
Cost of Delay,
Showing Effect of Delay on Sales
That’s right. Do those numbers start to look big and scary now?
You not only have aggravation and impediments in your current project from the delays from multitasking, technical debt, indecision, slowdowns from other teams, you lose the potential revenue from maximum potential sales, every week you don’t release.
Now, I am not saying you should release horrible product. Goodness knows, we have enough of horrible product that barely works or doesn’t work at all out in the field. I want to see great products! The idea behind this picture is so people understand that it is worth their while to consider change.
You can change to shorter projects and release something useful faster. (See Manage It! Your Guide to Modern, Pragmatic Project Management)
You can change to agile or incremental lifecycles so they can see progress and release something useful faster. (See What Lifecycle? Selecting the Right Model for Your Project and Manage It! Your Guide to Modern, Pragmatic Project Management for an in-depth discussion of lifecycles. You have more options than just waterfall and agile.)
You can adopt a more reasonable approach to the project portfolio, and make decisions more frequently. (Does anyone really think project portfolio decisions last a year? Come on.) (See Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects)
You can consider paying off some technical debt. I used the build system in my example. I could have used automated tests or the thousands of defects some of you have in your defect tracking systems. It’s whatever prevents you from knowing you could release on a “moment’s” notice. I would like that moment to be under an hour. I bet for many of you, less than a day would be a huge improvement.
You can optimize for the entire project or program, not their feature or team. Too often, I hear, “My part is done.” That does not matter. It matters what the entire team, project, or program finishes.
In my talks about project portfolio management, I am fond of saying, “It doesn’t matter how many projects you start, it matters how many you finish.”
With cost of delay, it matters when you finish them. Because until you finish them, no one pays you.
I have taken a high level approach to cost of delay in these posts. I wanted to simplify it so you and I could understand it, a zeroth approach, if you will. If you want more information, start here:
Cost of delay is why you cannot take an ROI or use date or budget estimates to manage the project portfolio. This is why you must use value. I look forward to your comments.
