I'm writing from the frozen northeast USA, where we've had more than the usual amount of snow packed into two weeks.
The CIO's Guide to Breakthrough Project Portfolio Performance: Applying the Best of Critical Chain, Agile, and Lean by Michael Hannan, Wolfram Muller, and Hilbert Robinson is a good, short description of how to take ideas from several disciplines and apply them to an overall portfolio management approach. (Disclaimer I know two of the authors, though I did buy the book.)
The authors start out describing the three most important objectives of portfolio management:
- Selecting the right projects
- Maximizing the portfolio's throughput of project completions
- Optimizing the portfolio's reliability of project completions
And the rest of the book clarifies what they mean by each of these objectives.
How to help selecting the right project? The authors discuss the TOC Throughput Accounting idea of "throughput per constraint unit" - basically reviewing how much time projects consume on the system's constraint compared to the value of the project. They also add in a consideration of the investment required to deliver the project, which they calculate as an "effective ROI". Interestingly, there is a similar concept in the Factory Physics approach (I'm reading Factory Physics for Managers).
I also like that they talk about analyzing potential projects from the TOC perspective of how the project will impact the constraint of the overall system. There might be a project portfolio constraint - the resource that limits the ability of the portfolio to flow more and more projects. And there will be a constraint at the business system level - these are not always the same thing. When they are the same resource, care must be taken in deciding on projects: will the operational needs of the finished project reduce or increase the demand on the system constraint? Are projects that require significant capacity from such a resource the best projects to run? If it is unavoidable that the constraint must also be on projects, there are a few strategies: make sure those resources in particular are focused (no multitasking!); make sure all other resources do what they can to support the constraint; and finally, if necessary, develop more of that constraint resource (training, hiring, etc).
So once you have selected the right projects, the focus becomes on ensuring they complete quickly and reliably. The more of the right projects that finish, the more value the portfolio will deliver to the organization. The focus here is has to be on ensuring projects are released to take advantage of the capacity of the constraint of the whole portfolio of projects: don't release more work than the resource can safely handle. Don't force your most precious resource into the situation where they are forced to switch from project to project to project without finishing the work of the moment. (This doesn't mean that they should have only one project - they should have only one TASK at a time.)
The authors describe a series of changes in planning and execution of projects that will create more and more benefit to the flow of work. In the conversation, they suggest an original portfolio that finishes just three projects in 17 weeks could be rethought into finishing sixteen projects in those same 17 weeks. People familiar with CCPM will find the discussion quite familiar: staggered release based on the constraint; reduce multitasking; elimination of internal task promise dates (change to finish as quickly as possible). There are also ideas in the Agile community that can help speed the throughput of projects.
Not only do they use familiar CCPM methods, but they also suggest bringing in the idea of Value Stream Analysis to the project design: particularly for information technology projects, it is often the case that the IT organization is asked to automate an existing business process. Rather than strictly automate it, a VSA would suggest places where the process could be improved to eliminate or reduce the number of steps. Not only does this make the business process better, but the resulting technical component is often simpler and much more in alignment with the needs of the business. And the project can be faster.
Finally, many of these concepts have to do with planning. Execution is just as critical. CCPM project execution techniques and tools help people focus on the key work required to bring projects in on time. In addition, one of the authors of the book, Wolfram Muller, also wrote Taming the Flow, which talks a lot about how to turn these ideas into "ultimate Scrum" to maximize the flow in software development.
And it is in execution where the third objective comes into play: reliable project completion. Again, from CCPM comes the idea of project buffers and using buffer status as a primary mechanism for providing status and focus. There are also scope buffers (backlog management) and budget buffers to help direct money to the places that need it.
And these buffers and the resulting information help at another level. Collecting information over time as to what most often causes significant buffer consumption is a great way to look for longer-term improvement opportunities.
The book isn't going to answer all the questions on how to make this happen, but it is a great introduction to the concepts and gives a good starting path. I particularly like that it shifts the conversation away from project management - implications on managing projects. In a portfolio, it is just as important to be flowing the right work in the right way for overall success.
Finally, they have a nice analogy in talking about "local efficiencies" and task-level promises. They extend the familiar (to me) idea of a project as a relay race. Everyone wants to do their best in the environment they are in. But what does that mean for the leg that the individual runner is on?
No runners are asked to commit to a specific time or speed - and if you did ask them, they would likely look at you like you're nuts, because all athletes know that performance will vary from one race to the next.
Just like in knowledge work. And most project work is knowledge work these days.