I wrote Unearthing Your Project’s Delays a couple of years ago. I told the story of Cliff, a manager who wanted to understand why the projects were so late.
I gave several talks about that article. One eagle-eyed fellow asked me this question, “How long was the time from T0 to T1?”
I said, “Managers might spend as little as a quarter and as much as a year or two. During that time, they kept asking the teams for forecasts of projects. So, much longer than T2-T5.”
He got that sad grin on his face. “Yeah, I thought so.”
In my experience, when organizations want to use agile approaches or transform in some way, the managers start with the teams.
The more I work with people on teams, with teams, and with managers, the more I am convinced starting with the teams is the “wrong” end to start. Agile approaches can help teams improve, and many teams do release value faster.
Teams can manage their delays if they measure their cycle time. They will encounter systemic problems and delays, and the teams and their managers are often smart enough to work those issues.
However, the teams cannot manage their managers’ delays.
What Causes Delays in Manager Decisions?
If you’ve always planned your project portfolio for a year, you might gain a ton of value from moving to quarterly planning. And, if the teams can deliver fast enough, you could move to monthly portfolio planning.
Under one condition: How much information do you ask the teams to deliver so you can decide?
I still see so many teams spend weeks at a time estimating projects they won’t start for years. Or, that someone is supposed to estimate ROI when no one has done any small experiments to see if anyone would buy/use this product/feature.
I do find value in forecasts for order-of-magnitude or ranges of dates. (I always estimate how long my books take. I’m always off. When I reviewed my estimates and actuals for the various parts of writing and publication, I realized how I could change my writing process. I’m still experimenting with my book writing to make it faster.)
However, substantial estimation does not add value to the project portfolio discussion. I’ve said before that I find asking, “How much do you want to invest” is a more useful question than “how much will it cost” or “When will it be done?”
Impact of Management Decision Delays
Let me show the impact management decision delays had on one team:
The managers started their portfolio decision meeting. They adjourned the meeting to get forecasts from the teams. The teams spent about a day of forecasting work, but the managers didn’t take the time to meet again for three weeks.
Then, the managers wanted detailed estimates for several feature sets. Those detailed estimates took the teams a week to create. However, the managers didn’t meet for another three weeks.
The managers created 6 weeks of delays.
Then, the managers decided on the portfolio for the next quarter. Those decisions took a total of 2 hours. The managers spent 6 hours of work time and 1008 hours of wait time. The cycle time for that decision was 1014 hours.
Two weeks into the quarter and the portfolio changed.
The problem? External market forces created the need for the managers to change their minds.
Here are the costs of that time:
- The time teams spent forecasting the gross estimates as opposed to finishing value on their current projects.
- The time teams spent creating detailed estimates as opposed to finishing value on their current projects.
- The context switching for the managers and the teams to dip into this decision, back out again, dip back in, back out, and finally decide.
Did the forecasts and estimates make a difference in the managers’ decisions?
One senior manager sighed and said, “No. We had the top three projects at that first meeting. We could have decided then and there. To be honest, we could have put more teams on those three projects and finished them faster. We didn’t need any of that forecasting or estimation data to make good decisions.” He paused for a moment. “We needed to work together and that was hard.”
Why Management Decision Time Matters
Management decision time matters because:
- Every request for more information interrupts the team’s current work.
- More importantly, the team starts to explore future work, not finish the current work.
- The managers lose their context to make a decision quickly.
I’m all for looking ahead, so you don’t prematurely remove options. The question is who looks ahead for what?
- On this project, the team looks ahead for the product strategy.
- For future work, the management team considers the strategy for the organization.
Different contexts, different lookaheads, different decisions.
The faster the management team decides—especially if they don’t change the portfolio, the fewer interruptions the team has to their current work. They can finish faster. (It’s fine to have a project portfolio meeting and say, “Carry on. No changes for now.”)
When managers reduce the T0 to T1 time, the teams don’t feel whiplash. The teams focus on their work.
What Prevents Short Management Decision Time?
Every time I see management chaos for the project portfolio, the organization’s reward system is the root cause.
It doesn’t matter what the reward system is (MBO or OKR). When the managers have individual rewards that create competition: for teams, for marketing time, for product management, anything that the product needs, the managers compete with each other. The managers don’t work together.
The more competition among managers, the longer the management decision time. (See Modern Management Made Easy Book 3 for specific ways to deal with individual manager goals.)
If you reward the managers as a team, you’ll get shorter decision times (management cycle time) and shorter team cycle times. All because everyone optimizes for a superior goal.
If you want to create an agile culture, start with the managers. When managers work in flow efficiency, they reduce their decision time. And, the teams benefit.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Why Minimize Management Decision Time Opinions expressed by Java Code Geeks contributors are their own. |
