Wouldn’t it be nice if you could tell your managers, "A lack of planning on your part does not constitute an emergency on my part"? And this is why managing product portfolios is so important.
Usually, when managers say their teams are having trouble with estimation, these are the reasons:
When the managers can’t decide, they do end up making a decision—to not decide. 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.
How do you discuss this cost of delay?
You ask, "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.
Then you ask, "When did we actually start working on this project?"
You want to see how long it takes to consider projects. It’s OK 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 from when you started discussing a potential project to the time you finished it. Project cycle time is the time from when you began a project to 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 the lead time, the more it will take.
The worst part is figuring out how much value the project has if the project lead time is “too long.”
Here are some things you can do:
This won't necessarily be easy, but it will be healthier for your organization.