Have you seen these problems in your organization:
- You or your staff are having trouble with multitasking
- You have many emergency projects
- It’s difficult for people to agree on goals or priorities or make strategic decisions
- You’d like to make decisions, but somehow, as a group, you don’t have the ability to do so
If you want to organize your projects and evaluate them without getting buried under a mountain of statistics, this book is for you. And, if you are successfully using agile and lean approaches to your product development, but are stuck with how to decide which project to work on first, this book is for you.
This book will help you collect all your work, decide which projects you should do 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. You’ll get a better view of the work you have, and learn how to make those difficult decisions, ensuring that all your strength is focused where it needs to be.
In the second edition, I added these chunks:
- How to use Cost of Delay to evaluate projects. You don’t need estimation.
- Many possibilities to visualize your project portfolio. Do you need kanban and calendar views? Do you need a board for “Advanced R&D Projects”? Maybe you need some other possibilities.
- Updated metrics for you to consider.
- How to scale from one group to an organization (and a little about strategy to help you articulate your project portfolio).
Want a peek?
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
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
Here’s the secret of project portfolio management: you can do it all. Just not all at the same time.
You can buy the book from the Pragmatic Bookshelf both in print or in DRM-free electronic copy (which includes pdf, mobi and kindle versions). The Prags have a deal if you buy both the ebook and the print book.
You can also buy the book from Amazon in print. (Buy the ebook from the Prags.)
The folks at getabstract like the book. They gave it a thumbs up!