Do you have more projects than time?
If you have any of these problems, this book is for you:
- 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 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.
Want a peek?
Here’s part of the preface: (Copyright 2009 Johanna Rothman)
…Why am I so passionate that you should manage your project portfolio and you shouldn’t multitask? I fell into managing the project portfolio when I was working at a company that made complex hardware/software systems. I had first been hired as the director of SQA and continuing engineering. Then they decided they needed a program manager to manage the largest program the engineering organization had attempted. I stopped being the director and ran that program. About four months before our planned release, we had a customer cancel a contract. Management decided to lay off about half the engineering staff. They assigned someone else to manage the program and asked me to be the director of software engineering.
We were down to about thirty to forty people in development. 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 doing 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. 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 and discussed what we would staff and not staff, keeping people to just two projects in any given week. We made sure people had team members they could work with to finish the work. 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 rebutted with, “No, you have to do it all.”
I said, “Well, then I’ll choose.”
“You’d better be right.”[…]
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. Development (and the test group) used two-week timeboxes, working in features, so we could finish chunks of work.
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. But 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 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 specialties cycle in and out of the project. One group might need to work in one-week or two-week timeboxes, while another might find three-week timeboxes
easier to manage.
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).
You can also buy the book from Amazon in print and now, the Kindle version.
Update: The folks at getabstract like the book. They gave it a thumbs up!