I have written about project portfolio management extensively. In all my articles I relentlessly repeated the three goals of Project Portfolio Management.
1) Maximizing the value of your portfolio
2) Seeking the right balance of projects
3) Creating a strong link to your strategy
After some thinking and new experiences, I have decided to add a very important goal.
4) Doing the right number of projects
Getting this one wrong makes it very hard, or even impossible, to achieve the other three. And as you probably already have guessed, doing not enough projects is seldom the case.
What Is the Right Number of Projects?
Typically the half of what you are currently doing. Of course the answer to this question is depending on the altitude of your portfolio (i.e. only IT, or your whole company), the size of your projects, and the size of your company. But there are a number of guidelines from the Agile and Lean world that we can use.
PMI project portfolio management is all about value optimization and optimizing resource allocation. Both are designed in such a way, that in my opinion it will result in the opposite. As we have seen in the article about funding, running projects at hundred percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will be even worse because of the time spent on re-planning. And value is only created when it is delivered and not when it is planned. Hence we should focus on delivering value as quickly as possible with our given constraints.
This brings us to lean thinking. Lean is sometimes described as focusing on a smaller batch (project) size, shorter queues, and faster cycle time. Focus on delivering value quickly. Lean is much more than this. The pillars are respect for people and continuous improvement resting on a foundation of manager-teachers in lean thinking. Queue management is just a tool far from the essence of lean thinking. But it is a very helpful tool that can have a very positive impact on your project portfolio management process.
Some example of queues in project and portfolio management?
> products or projects in a portfolio
> new features for one product
> detailed requirements specifications waiting for design
> design documents waiting to be coded
> code waiting to be tested
> the code of a single developer waiting to be integrated with other developers
> large components waiting to be integrated
> large components and systems waiting to be tested
In lean thinking, work in progress (WIP) queues are identified as waste, and hence to be removed or reduced, because:
> WIP queues (as most queues) increase average cycle time and reduce value delivery, and thus may lower lifetime profit.
> WIP queues are partially-done inventory (of projects in this case) with an investment of time and money for which there has been no return on investment.
> As with all inventory, WIP queues hide—and allow replication of—defects because the pile of inventory has not been consumed or tested by a downstream process to reveal hidden problems; for example, a pile of un-integrated code.
On a similar note, we typically have a lot shared resource queues in our portfolio. Especially the main know-how carriers in a business unit are shared by multiple parallel projects. These queues are getting bigger due to project re-planning when one of them is behind schedule.
Also consider project portfolio throughput from a cost of delay point of view. You might, for example, be able to complete a project with perfect resource management (all staff is perfectly busy) in 12 months for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.5 million, but the project would be completed in only 6 months.
What’s that 6 months difference worth? Well, if the project is strategic in nature, it could be worth everything. It could mean being first to market with a new product or possessing a required capability for an upcoming bid which you don’t even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for an external audit. There are many scenarios were the benefits outweigh the cost savings.
Additional to delivering the project faster, when you are done after 6 months instead of 12 months you can use the existing team for a different project delivering even more benefits for your organization. So not only do you get your benefits for your original project sooner and/or longer, you will get those for your next project sooner as well because it starts earlier and is staffed with an experienced team.
What Does This Mean for Your Organization?
For a typical organization this means the following five things:
1) Doing fewer projects in parallel (i.e. limit work in progress)). On average only half of what you are doing now. Focus on limiting the number of concurrent projects in your organizational units.
2) Focus on doing the right projects.
3) Keep your project size small (i.e. limit batch size)
4) Focus on improving your project delivery capability.
5) Implement an agile delivery method for projects where it makes sense (i.e. reduce cycle time because you deliver value during the project, and not only at the end)