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

Cost of Delay Due to Indecision, Part 3

In Part 1, we discussed the cost of delay of not shipping on time. In Part 2, we discussed the cost of delay of multitasking. In this part, we’ll discuss a cost of delay due to management indecision.

Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop. I ask about the environment. The manager tells me these things:
 
 
 
 

  • The developers meet their dates and the testers never do (this is not an estimation problem)
  • The project starts on time, and the project staff comes in close, but not quite on time (this might be an estimation problem)
  • The project starts off late (this is not an estimation problem)

When the developers meet their dates but the testers never do, it’s almost always a couple of things: Schedule Chicken, or technical debt masquerading as done in a waterfall project.

If the project starts on time and it’s close, it might be an estimation problem, assuming no one is multitasking.

But if the project starts late, this is not an estimation problem. This is a cost of delay due to management indecision.

Wouldn’t it be nice if you could say,

A lack of planning on your part does not constitute an emergency on my part

to your managers? Well, just call me the Queen of the Career Limiting Conversation. This is why managers are supposed to manage the project portfolio.

When I hear the plea for the estimation workshop, it’s for these reasons:

  • The managers have received estimations for the work, and they don’t like the estimates they have received.
  • Someone other than the project team did the estimation two years ago. They know the estimate is out of date, and they need a new estimate.
  • The managers still can’t make a decision, because they are trying to decide based on ROI, date, or cost or some sort of hard to predict quantitative measure, rather than on value.

The managers are, ahem, all tied up in their shorts. The can’t decide, which is a decision. They don’t fund the potentially transformative projects or programs. They go with the safe bets. They do the same projects over and over again.

If they get lucky, they choose a project which is small and has a chance of success.

How do you discuss this cost of delay? You ask this question:

When did you first start discussing this project as a potential project? or When did this project first go on our backlog?

That provides you the first date you need. This is your next question:

When did we actually start working on this project?

You want to see how long it takes you to consider projects. It’s okay to consider some projects for a while. The difference between the time you first start discussing a project and the time you start working on it is your management cost of delay. I just made that up. I bet there’s a real name for it.

What is the difference in those two dates?

Project lead time is the time you started discussing a potential project and the time you finished it. Project cycle time is the time you started a project and the time you finished it. Yes, we normally discuss lead time and cycle time for features. But sometimes, it makes sense for projects, too.

If you release projects, not features, and you have managers who have decision problems, they need to know about this cost of delay. Because the project lead time will take time out of your maximum revenue. The longer that lead time is, the more it will take.

The worst part is this: how much value does the project have, if the project lead time is “too long?”

What can you do?

  1. Track your project lead times. Decide how much time a project can spend on the backlog in the project portfolio before you decide to transform or kill it. Yes, I am serious.
  2. Shorten all your projects, so you release something at least every six months, or more often. That provides you more capability in assessing your project portfolio and frees teams for more work.
  3. Move to an incremental lifecycle or an agile approach.

I didn’t say it was easy. It’s healthier for your organization.

Who do you think can measure this cost of delay in your organization? What do you think might have to change to make this cost of delay visible?
 

Related Whitepaper:

The Retrospective Handbook

A FREE guide for agile teams.

Are you running retrospectives regularly? Perhaps you run retrospectives once a week, or fortnightly. Do you feel like you could be getting more out of your retrospectives and fuelling continuous improvement in your teams? You may already find retrospectives valuable, but suspect there are ways of making them better.

Get it Now!  

Leave a Reply


six + = 7



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close