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