Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed

Do you have more projects & work than time?

Is this the current state of work in your organization?

• Everyone's multitasking on “everything.” (Even if the teams are using agile and lean approaches.)
• Emergency projects pop up and surprise everyone.
• It's difficult for people to agree on goals or priorities or make strategic decisions. That means the decisions do not stick for long enough for people to finish the work.
• No one knows the most important work, which means too few people focus on generating the business outcomes your organization needs.

The result? A ton of unfinished work, frantic busyness, and not enough outcomes for the business.

It's time to manage your project portfolio.

Contrary to spreadsheet-driven management, you do not need a lot of statistics or complex math. However, you do need a cohort of people who are willing to make these difficult decisions. They can do so with the approaches here. As long as they are willing to define their mission, purpose, and visualize their work, they can decide and manage the project portfolio. They can decide which projects to staff and fund first, second—and never. You’ll see how to tie your work to your organization’s mission and show your board, your managers, and your staff what you can accomplish and when.

When you rank projects instead of prioritizing them; fund by value instead of cost; and fund teams, you will be pleasantly surprised at how fast the work flows through your organization. Managing the portfolio helps you finish more projects and increase your overall organization's capacity for more work. (And we all have more work than we have people to do the work.)

Here's part of Chapter 1: (Copyright 2016 Johanna Rothman)

How I Started to Manage My Project Portfolio

I’d been managing testing and continuing engineering groups at a company that made complex hardware/software systems. Then the company started a large program and asked me to be the program manager. I stopped being the director and ran that program.

About four months before our planned release, a customer canceled a contract. We could not sustain the number of people in the organization. Management decided to lay off about half the engineering staff (software, hardware, mechanical, you name it). They assigned someone else to manage the program and asked me to be the software director. And they canned my boss, the VP.

We were down to about forty people in development, half the number of people before the layoff. We had to finish the development work on the program and continue to respond to problems in the field. Each field problem was a crisis and required several weeks of work. So here I am, a director, with an interim VP, people who’d been working crazy hours for months, and a release we had to get out. And huge problems we had to fix. We had to do it all. We had no choice.

I made a spreadsheet of what everyone was working on so I could understand where the time was going. I’d made spreadsheets like that before when I’d managed testers and developers who were matrixed into projects, but I had never had to staff quite so many simultaneous projects. Everyone worked on everything.

After two weeks of people working the way they’d been assigned, I realized no one was making progress on anything. I sat down with my management team, the people who helped me organize the software department. We discussed what work we would staff and not staff. We assigned people to no more than two projects in any given week. Instead of everyone working on everything, everyone worked on no more than two projects in one week.

I took the heat from senior management—and there was plenty of it. “You have to do this project and that one and that other one and that other one over there. This week.”

I said, “Sorry, we can’t do that much in one week. You have to choose.”

And, of course, they responded with “No, you have to do it all.”

I said, “Well, then I’ll choose.”

“You’d better be right.”

After another two weeks, we started to make progress, but it still wasn’t fast enough. I had a team meeting with my managers and asked, “What will it take to finish this project? Just this one here?”

One of the managers said, “If Tom and Harry and Jane can concentrate on just that project for a week, we can finish it.”

I said, “OK, have them do that. Now, what about that crisis over there?”

“Well, we need Harry…”

“Sorry, you can’t have him. Who else can you use, and how long will it take?”

We asked these questions for all the outstanding work. At the end, we had small teams assigned to one problem each. As they completed one problem, we had a ranked list of problems to provide them. Each team knew what problems to work on in rank order. We knew if we could fix the problems, we could give ourselves time to work on the program.

In about two weeks, we were half-staffed on the program. The developers were thrilled to finish something—especially fixing problems that bugged them as much as the customers. The managers were happy about not having to move people around. I was happy that we finally got some things done. My senior managers were still unhappy with my progress.

Over the next few weeks, we discovered new problems. We continued to ask teams, not specific people, to fix problems. After two months of this, we finally had the problems under control. The developers could focus on the program, because the continuing engineering department was able to address and fix the field problems. That’s when we started to make huge progress on the release, because we worked by feature and assessed our progress biweekly.

We used a combination of approaches: continuing engineering used a kanban approach because the problems were smaller than the features for a release. They could limit their work in progress and work on one problem at a time until it was fixed. The developers and testers worked together on features, using two-week timeboxes. They finished chunks of work, already integrated. By the end of the four months, we had a release, although we didn’t have all the features our senior management wanted. We had the field problems under control. We hadn’t added a ton of technical debt.

And the people who remained learned that they could work on one project at a time, one task at a time, until it was done. They could make more progress doing one thing (a problem or a feature) at a time than splitting their time among several pieces of work, even if the work was related.

If I could manage the project portfolio with an organization reeling from a layoff, where we had an unstated strategic plan, where the senior managers had trouble deciding what to do on any given day, you can do this for your work. You may need different approaches for different groups. One group might need to limit the work in progress, especially if you’re in a serial life cycle and people with different expertise cycle in and out of the project. You might decide to work in one-week timeboxes instead of two weeks.

When you finish features regardless of your life cycle, you have more flexibility to manage what the teams do. You can manage the project portfolio because the teams finish work. The teams don’t multitask between several pieces of work.

Here’s the secret of project portfolio management: you can do it all. Just not all at the same time.

Here's the workbook I referred to in the Preface: Reader Resources for Manage Your Project Portfolio.

Table of Contents

1. Meet Your Project Portfolio
   • How I Started to Manage My Project Portfolio
   • The Project Portfolio Flows Work Through Teams
   • What a Project Portfolio Is
   • See the High- and Low-Level Views
   • Now Try This
2. See Your Future
   • Managing with a Project Portfolio
   • Signs You Need to Manage the Project Portfolio
   • Managing Without a Project Portfolio
   • What Are Your Emergency Projects?
   • Lean Approaches to the Project Portfolio
   • Why You Should Care About the Project Portfolio
   • Now Try This
3. Create the First Draft of Your Portfolio
   • Know What Work to Collect
   • Is the Work a Project or a Program?
   • Organize Your Projects into Programs As Necessary
   • Organize the Portfolio
   • Using Tools to Manage a Portfolio
   • Now Try This
4. Evaluate Your Projects
   • Should We Do This Project at All?
   • Decide to Commit, Kill, or Transform the Project
   • Commit to a Project
   • Kill a Project
   • How to Kill a Project and Keep It Dead
   • Killing a Senior Manager’s Pet Project
   • Kill Doomed Projects
   • Transform a Project
   • Now Try This
5. Rank the Portfolio
   • Never Rank Alone
   • Rank with Cost of Delay
   • Rank with Business Value Points
   • Remaining Points Provide Metadata
   • Rank the Projects by Risk
   • Use Your Organization’s Context to Rank Projects
   • Who’s Waiting for Your Projects to Be Completed?
   • Rank the Work by Your Products’ Position in the Marketplace
   • Use Other Comparison Methods to Rank Your Projects
   • Beware of Ranking Traps
   • Your Project Portfolio Is an Indicator of Your Organization’s Overall Health
   • Publish the Portfolio Ranking
   • Now Try This
6. Collaborate on the Portfolio
   • Organize to Commit
   • Build Trust
   • Define Your Principle so You Can Collaborate
   • Articulate Your Mission to Prepare for Collaboration
   • Facilitate the Portfolio Evaluation Meeting
   • How to Say No to More Work
   • Fund Projects Incrementally
   • Never Make a Big Commitment
   • Discover Barriers to Collaboration
   • Who Needs to Collaborate on the Portfolio?
   • Now Try This
7. Iterate on the Portfolio
   • Decide When to Review the Portfolio
   • Select an Iteration Length for Your Review Cycles
   • Defend the Portfolio from Attack
   • How to Decide If You Can’t Change Life Cycles, Road Maps, or Budgets
   • Make Decisions as Late as Possible
   • Now Try This
8. Make Portfolio Decisions
   • Keep a Parking Lot of Projects
   • Decide How Often to Review the Parking Lot
   • Decide How to Manage Advanced Projects
   • Conduct a Portfolio Evaluation Meeting
   • Conduct a Portfolio Evaluation Meeting at Least Quarterly to Start
   • Review Your Decisions
   • Now Try This
9. Visualize Your Project Portfolio
   • Who Needs to See What?
   • See the Calendar View
   • See the Variety of WorkSee the Work in Progress for Many Projects
   • Now Try This
10. Scaling Portfolio Management to an Enterprise
    • Understand How You Work Together Now
    • Does Your Organization Suffer from Resource Efficiency Thinking?
    • Create a Holistic Perspective of All the Work
    • Define Strategy at Your Level
    • Ask These Questions for Each Business Unit
    • Beware of the Sunk Cost Fallacy
    • Start with Strategy and Paper
    • Start Here with an Agenda for a Corporate Project Portfolio Meeting
    • Scale With Care
    • Now Do This
11. Evolve Your Portfolio
    • Lean Helps You Evolve Your Portfolio Approach
    • Choose What to Stabilize
    • Stabilize the Timebox
    • Stabilize the Number of Work Items in Progress
    • Fix the Queue Length for a Team
    • When You Need to Fix Cost
    • Management Changes When You Stabilize Something About Your Projects
    • Now Try This
12. Measure the Essentials
    • Measure Value
    • What You Need to Measure About Your Projects
    • Measure Project Velocity: Current and Historical
    • Measure Project Cycle and Lead Time
    • Measure Cumulative Flow for the Project
    • Measure Obstacles Preventing the Team’s Progress
    • Measure the Product Backlog Burnup Chart
    • Measure Run Rate and Other Cost Data, if Necessary
    • Don’t Even Try to Measure Individual Productivity
    • What You Need to Measure About the Portfolio
    • Measure Capacity by Team, Not by Individual
    • People Finish More with Lean and Agile
    • Now Try This
13. Define Your Mission
    • Define the Business You Are In
    • What Good Is a Mission, Anyway?
    • Define an Actionable Mission for the Organization
    • Managers: Do Management Work
    • Draft a Mission from Scratch
    • Brainstorm the Essentials of a Mission
    • Refine the Mission
    • Derive Your Mission from Your Work
    • How to Define a Mission When No One Else Will
    • Beware of the Mission Statement Traps
    • Test Your Mission
    • Make the Mission Real for Everyone
    • Now Try This
14. Start Somewhere…But Start
    • You’re the Only One Managing the Project Portfolio
    • Can I Really Do This?

---

Buy Manage Your Project Portf0lio Now

The Pragmatic Bookshelf often has the best prices for both the DRM-free ebook or the print book. If you're the kind of person who often likes both versions, they sometimes offer a deal for both the print and the ebook versions.

You can also buy the book from Amazon and wherever books are sold.

Here's a Universal Book Link: https://books2read.com/mypp. That link brings you to “all” of the stores. (With any luck!)

Podcasts, Videos, and Other Content about Manage Your Project Portfolio

With Transparent Choice:

• #1: Managing Your Project Portfolio
• #2: How to Value the Projects in Your Project Portfolio
• #2: Visualizing All the Work in Your Project Portfolio

At Agile Vancouver (the sound is unreliable): Lean and Agile Project Portfolio Management.

Kudos from Others

The folks at getabstract like the book. They gave it a thumbs up!