Meetings, Project Portfolio, and Lean

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.

4 Replies to “Meetings, Project Portfolio, and Lean”

  1. I am a little confused by the above. I am assuming that you are talking about functional managers as opposed to project managers. I do not believe that managers should be making many decisions about projects. The decision about whether to authorize and staff a project belongs to management. The decision about who should manage the project is also a management decision. After those decisions are made, the project manager should have the authority to make virtually all project related decisions. Maybe I need some specific examples from you about project related decisions that managers are making on a weekly basis.

  2. Interesting thoughts. I especially agree with the concept that few decisions are more obvious than many decisions, hence the insecure manager (the one striving to be perfect) would rather make many decisions as hiding poor decisions is easier.

    My current office has about twice as many projects as we should. The managers cannot seem to cancel any despite all the engineers begging them to. Fear is a tough devil at work.

  3. I love these tactical methods like these to highlight what is really happening. Useful tool. My previous indicators were merely how stressed-out or frantic they were.

  4. Regarding your search for a reference regarding quality and quantity of management decisions, I first saw this point made by Ajai Kapoor of Realization Technologies at the 2005 Theory of Constrains International Certification Organization annual conference. His point was that as projects are staggered it reduces the decision making multi-tasking of managers and, hence, people reporting to them spend less time waiting for answers and projects complete faster with higher quality. This, in turn, means fewer rework loops and fewer decisions for managers, leading to even faster projects. It creates a “virtuous circle” in which the benefits reinforce each other. You can see references to the point in the Postscripts from Realization’s past conferences here:

    This has been pseudo-codified within the Critical Chain Project Management community by rules of thumb saying that in a massively multi-tasking project system 25% of all projects should immediately be frozen to provide sufficient time for people (and managers) to get to the tasks that are stacking up-including management decisions. (Some go further and say that first 25% of current projects should be outright canceled since they won’t be completed anyway.)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.