One Quick Way to Start to Manage Your Project Portfolio

A project portfolio manager contacted me via LinkedIn. The question: How can this portfolio team start to manage the project portfolio when the organization has 600 projects? Right now, the portfolio team is supposed to read the status decks for each of those 600, to understand each project's status. How to start?

That's an impossible task. A project portfolio team cannot decide when they're supposed to evaluate 600 projects. That amount of WIP (Work in Progress) is overwhelming. No team can evaluate that many projects in a week, never mind in a day.

Instead, ask the people who want the work to decide on a gross first cut at the most important work.

Yes, the people who want the work start to bucket the work themselves. Start with what will make a difference for the short term: this next month or so.

What Will Make a Difference for You In the Next 1-3 Months?

When I consult with a client with this problem, I ask this question of all the department heads:

What one to three projects currently in flight will make the most difference for your department this in the next one to three months?

Here are the “rules” for these decisions:

  1. The department heads must choose within 24 hours. Why? A senior manager's first job is to reduce organizational WIP (Work in Progress). Those decisions allow everyone to deliver outcomes.
  2. If they can't “possibly choose” in that time, I choose.  I always choose zero. In my experience, people have little trouble deciding on the first or second most important projects to benefit their department. If they can't decide now, none of their projects are that important.
  3. Do not worry about how the project is organized to deliver. Only explain how this project will benefit this department in the next one to three months.

The department heads can choose:

  • Zero projects, if none of the current projects will make a difference for them in the next 1-3 months.
  • One to three projects. In addition, add a sentence or two about how these projects will make a difference to this department. Who benefits from which features?
  • Several projects, if and only if, the head sees all this work as related. The department head can then write a sentence or two about what this program is and how it will make a difference for their department.

When the managers complain to me, I explain that yes, we need short-term decisions to free the people from multitasking. That freedom will create more slack in the organization, which will allow the managers to choose more projects later. But Management Decision Time matters. So does WIP.

If the managers want more time, I explain they have another option: They can take all the time they want. However, the technology group will stop working on all the managers' projects. The technology group will get at least two weeks to work on projects that will make their work lives easier or better. The technology group has a long list, too.

I can do this as a consultant, and you might not if you work on the inside. However, stopping work on all the projects has a great side effect: the managers start to unite against me, not each other.

That often nudges the other managers.

Bucket as a First Cut

In Manage Your Project Portfolio, I recommended several ways to organize the work to be able to decide:

  • Are various projects related, so we need to assess them as a program? Instead of evaluating them separately, group them together and create a program.
  • Are some projects so important they dwarf others? List them.
  • Are there projects that create organizational risk if we don't do them?

None of those will work yet if a portfolio team is trying to make sense of 600 projects.

When organizations have that many projects, they often do not have a strategy. That is, they have no corporate strategy, and probably no product strategy for any of the products. I see this most often in organizations that think of technology as a cost center. That is, the technology group gets allocated across the organization—often to the people who yell the loudest.

Those organizations often do have a core product or service—often, several. However, they don't have a corporate strategy. They have not yet decided on which customers they want to serve and which problems the organization wants to solve for those customers.

So, these organizations can't use a strategy to manage the project portfolio. However, they can decide what will make a difference for them, in the short term.

Outcomes of the 24-Hour Decisions

When managers have to decide, they often realize they have just one or two really important projects. The rest will not make a difference this month to quarter.

Why such a short-term focus? Because I can pretty much guarantee that nothing is getting through their system. If they reduce the overall WIP and allow the technology group to focus on just a few projects, they can:

  • Create teams of people who can collaborate, especially if the managers have an overarching goal.
  • Reduce their cycle time and release useful work that matters.
  • The combination of WIP reduction, cycle time decrease, and valuable outcomes allow the portfolio team to start making sense of all the other work.

Once we exit from the overload, some managers ask how many projects they could have.

A side benefit of the short-term focus: In every case I've tried this, regardless of the lifecycle, the technology teams were able to release the key features that would make a difference to the managers. Every time. That's because the managers—and therefore, the teams—moved to “how little” thinking.

How Many Projects Should You Have in Flight?

After the managers realize they can plan for just a month to a quarter at a time, and ask teams (not individuals) to solve problems, they often ask me this question: Is there a “right” number of projects for their organization?

Maybe. And it's all about managing WIP at the team and organizational levels.

Every project requires at least four people: two developers, a tester, and a product leader of some sort. (Two developers because everyone needs someone to talk to when they're stuck.) I prefer a team of six-seven people, with 4 developers, two testers, and a product leader. But I can live with smaller teams. I let the teams decide how big they want to be.

That product leader knows what the customer needs, with any luck. The longer this team stays together, the more they learn this product and what the customers expect. Then, if a different product is more important, the team can move to a different set of problems. (See Product Roles, Part 4: Product Orientation and the Role of Projects for more information.)

How many product leaders do you have? That's the number of simultaneous projects you can have. That's it. What if you have six product leader people? Yes, six projects. Even if you have 2500 technical people, you only have six product leaders. How can teams know what to do if someone isn't shepherding the business value of the problems to solve for which customers?

(There's another failure mode: If you have three product leaders and six technical people, you can't have three simultaneous projects. You can have one project and the product leaders can do something else. You have overhired product leaders and underhired technical people.)

Many organizations have other bottlenecks, not just in the product leader role. See Unearthing Your Project's Delays for how a separate UI team changes the capacity of an organization.

Or, you might actually have a program that requires several teams. That's fine. (See Agile and Lean Program Management for more details.) But the portfolio team does not assess each of the projects separately. Instead, the portfolio team reviews this program against all the other projects and programs.

Make sure that you don't have more projects in flight than you have teams with sufficient skills (or time to learn) to fulfill that project's outcomes.

Your capacity is not about the number of people you have. Your capacity is about the number of fully-staffed teams who can do the work. That's why we need managers to think in flow efficiency.

How Do Organizations Have 600 (or More) Projects in Flight?

You might not have 600 projects. You might have 200 or 1000. I've seen this before in IT organizations that “support” the business of the organization with their work.

Some factors that lead to very large numbers of simultaneous projects:

  • Each person on the senior leadership team has their own individual objectives. They do not share an overarching goal. The managers work in resource efficiency.
  • Often, each person has a substantial bonus based on that person achieving their goals. Yes, their income is at stake for their individual goals. Too often, the rewards pit managers against each other. The managers have little incentive to collaborate to achieve one or two organization-wide goals.
  • All of this work does offer some value to the organization. However, the sum of all the outcomes is much less than what the organization needs. So the organization starts more projects.
  • The managers have no idea what everyone's multitasking costs them. (See the Cost of Delay posts or Diving for Hidden Treasures.)

Start with a short-term view of the project portfolio. Reduce your WIP and create cross-functional collaborative teams who can finish one project before they start another.

Watch Your WIP

If you work as a portfolio team member, the best thing you can do is to watch the organizational WIP. You are much better off with slack in the system than for each person to be overloaded. (Actually, everyone should watch their WIP because high personal WIP might be an early warning signal that the portfolio is getting out of control.)

Ask this question: What's the most valuable thing for you right now? Fund that. Stop all the other work. That will help teams finish. And you, as a senior leader or member of the portfolio team, can take the time to create your organizational and various product strategies.

Once you do that, you can manage the project portfolio in non-emergency mode. And have many fewer than 600 simultaneous projects.

To understand more, read Practical Ways to Lead an Innovative Organization, and Manage Your Project Portfolio.

2 thoughts on “One Quick Way to Start to Manage Your Project Portfolio”

  1. Always love conversations about reducing WIP, instead of “stopping multitasking” – you can’t do the latter, really. If your organization keeps throwing new things at you before you finish the current stuff, you will feel the inexorable need to multitask. Yes, as an individual, there are mechanisms to reduce that, but we need help!

    The elements you mention in the reasons that we have such high WIP are right on. Especially the “we aren’t confident we will hit our numbers, so we release even more work just in case” which creates a wonderful vicious cycle that makes those projects take longer and longer (high WIP, variations on Little’s Law), so we feel the need to release even more.

Leave a Comment

Your email address will not be published. Required fields are marked *

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