Agile

Cost of Delay: Why You Should Care, Part 6

I’ve outlined five potential costs of delay in the previous five posts:

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
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
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.
 

Johanna Rothman

Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
SkorpEN
SkorpEN
10 years ago
Back to top button