I've been writing pieces of the project portfolio book, and was wondering how to explain how managers get caught in the trap of having too many projects. Then I read Joe Ely's Minimizing Work-in-Process for Knowledge Workers, and had an “aha” moment. (Well, I think I did. You let me know.)
For many managers (and senior technical leads), meetings are their work-in-process (in addition to their email). But what happens at these meetings? Too many senior people are doing something else at these meetings. Even assuming the meetings are well-run (not needing buckets to keep people focused, as in Why Does a Meeting Need Buckets?), sometimes the senior people are still not paying attention. One cause of that lack of attention is too many projects needing some sort of management attention.
I suggested a card technique similar to Joe's to one of my clients. He could list all the projects down the side of the card, and the number of meetings he had each week for each of those projects–just making a tick mark. He had to count the number of hallway conversations, email threads, and formal meetings. At the end of the week, he had learned several facts:
- He had more projects than he thought he had.
- He had two projects where one asked him anything.
- He had several projects where people interrupted him almost constantly.
What's fascinating is the conclusions he drew from this data. He thought the two projects that didn't ask him to make any decisions were not successful–but the opposite was true. Those were the only two projects making progress out of the 30-something projects. The projects that asked him the most questions made the least progress, in terms of finished features per unit time. (These conclusions may not be yours–this is context dependent.)
So, one of the issues in managing the portfolio is that some managers avoid actively managing the portfolio, because they would have to commit their time to fewer projects. If they have to commit their decision-making to fewer projects, the goodness/usefulness of their decisions becomes more obvious. For many managers, that is a Bad Thing–because they don't have ways to gauge how good their decisions are.
But a funny thing happens when managers have fewer decisions to make. In my experience, the quality of their decisions go up, because they are not so distracted by all the decisions, and by getting confused about which decision is which. (I need to find a reference for this–does anyone have one?) Not only are their decisions better, they can see feedback on their decisions, which improves their next similar decision. This effect is similar to technical staff estimating fewer tasks and becoming better estimators because they get much more immediate feedback on their estimates.
Managers will still be wrong sometimes. Managers don't have crystal balls. And those times might hurt a lot. But having more output in the form of more finished work can save a manager who makes a wrong decision. The more finished work, the more flexibility the organization has in releasing a product.
So, if you're a manager, get an index card. Write all the projects down one side (you might have to turn the card to portrait orientation). Write a tick mark next to all the projects you need to make decisions for in a week. At the end of the week ask yourself these questions:
- Should this project be in the current portfolio of staffed work?
- If so, should it have the same relative priority?
- If not, what do I need to do, to remove it from the current portfolio or raise/lower its priority?
Then do that. Yeah, easier said than done. The more decisions you have, the more fractured they are, and the less context you have to make good decisions. A more lean approach will help.