Cost of Delay Due to Indecision, Part 3 - No Fluff Just Stuff

Cost of Delay Due to Indecision, Part 3

Posted by: Johanna Rothman on February 6, 2014

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?

Johanna Rothman

About Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” offers frank advice for your tough problems. She helps leaders and teams learn to see simple and reasonable things that might work. Equipped with that knowledge, they can decide how to adapt their product development.

With her trademark practicality and humor, Johanna is the author of 18 books about many aspects of product development. She’s written these books:

  • Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility
  • Become a Successful Independent Consultant
  • Free Your Inner Nonfiction Writer
  • Modern Management Made Easy series: Practical Ways to Manage Yourself; Practical Ways to Lead and Serve (Manage) Others; Practical Ways to Lead an Innovative Organization
  • Write a Conference Proposal the Conference Wants and Accepts
  • From Chaos to Successful Distributed Agile Teams (with Mark Kilby)
  • Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver
  • Agile and Lean Program Management: Scaling Collaboration Across the Organization
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd edition
  • Project Portfolio Tips: Twelve Ideas for Focusing on the Work You Need to Start & Finish
  • Diving for Hidden Treasures: Finding the Value in Your Project Portfolio (with Jutta Eckstein)
  • Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost
  • Manage Your Job Search
  • Hiring Geeks That Fit
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management (with Esther Derby)

In addition to articles and columns on various sites, Johanna writes the Managing Product Development blog on her website, jrothman.com, as well as a personal blog on createadaptablelife.com.

Why Attend the NFJS Tour?

  • » Cutting-Edge Technologies
  • » Agile Practices
  • » Peer Exchange

Current Topics:

  • Languages on the JVM: Scala, Groovy, Clojure
  • Enterprise Java
  • Core Java, Java 8
  • Agility
  • Testing: Geb, Spock, Easyb
  • REST
  • NoSQL: MongoDB, Cassandra
  • Hadoop
  • Spring 4
  • Cloud
  • Automation Tools: Gradle, Git, Jenkins, Sonar
  • HTML5, CSS3, AngularJS, jQuery, Usability
  • Mobile Apps - iPhone and Android
  • More...
Learn More »