There is some excellent advice in this book, in simple form, on how to start getting control of your project portfolio. If you are in the mode of saying “yes” to everything coming in, then this book will show you the steps to take to get out of the mess. And the advice is all based on common understanding of agile approaches - use of cadence, visualization, collaboration, managing WIP / queue length, useful metrics, and the development of plans based on reality.

Some key ideas:

To get started just create a simple project board, a simple matrix with who is doing what looking out a few months (say a quarter). Conceptually this looks like:

This allows you to make visible the decisions that are in place and understand where you are going to. And it helps you to start to deal with “capability debt” (organization cannot improve as it is too busy getting the next feature done).

With this information in place we want to start to better understand when to say yes and, more importantly, when to say no on a project. Idea is to build a simple process for this:

1. Create a force rank (in terms of value) list of projects. Projects are typically
   1. Emergency projects
   2. Status quo projects
   3. Project that will result in growth
   4. Transformative project
2. For each project decide:
   1. Transform the project: Perhaps it is too big, or too small, or has a dependency that cannot be addressed but since we want to do it now (i.e. make a commitment) we need to transform the project in some way so we can commit.
   2. Kill the project: Decide we will not work on this project. To help make sure this decision sticks, set up a “Project Parking Lot” where projects are put on the back-burner. The parking lot would track when it got onto the packing lot, the project name, and information about why it was put there and potentially why you'd think of resurrecting it (eg new technology required to meet requirements).
   3. Commit to the project: Fund it, and get out of the way.

To get to this point you will need rank all the projects that you have. The suggestion in the book is that you use a “buy-a-feature” like mechanism, with all the stakeholders involved.

As we go through this process we will also look at:

1. Establishing a cadence for the portfolio. Idea is that we decided to do, for example, a portfolio review every quarter (at the longest) and update our decisions based on what we are seeing.
2. If we have a cadence, then we might want to also look into delivering based on that cadence. At the end of the cadence we need to have an objective measure of how the projects we have are going. This is best done via a demonstration of what we have. If we are going to have a demonstration, then we perhaps should right-size the items coming into our quarterly review so they can get done in a quarter. This leads to the idea of creating “minimal mandatory features” (MMF), sets of value that we could (if that was a good business decision) deliver to the customer. The thinking here is that if we develop highest priority items first and we get them to completion there is a high chance we satisfy the customer early and can use our people on the next high priority initiative.
3. Over time this moves us away from “project” based planning / approval / etc to feature (value) based planning where, in this case, a feature is defined as somewhere between 2 weeks (a sprint) and 3 months (the quarterly review cycle) of work.
4. We can then start to understand the true capacity of the organization to deliver value. We can use this information to make sure we pull enough stuff into the delivery system to ensure smooth flow. We do this by managing (limiting) work-in-progress (WIP) or queue length (we are working on). We can create a cumulative flow diagram (CFD) as well as other metrics to track what is happening.
5. We can look at generating a kanban board of projects.

All of this is aimed at improving effectiveness of portfolio execution by focusing our capabilities and working to a cadence and limiting our WIP. All of these our powerful ideas. The benefits of limiting WIP include:

• Reduction in multi-tasking
• Ensures projects are fully staffed
• You will actually finish projects
• Allows for more business decisions to be applied
• Cross training just happens (as whole team focusses on one project)
• Implementers / developers are not concerned that there project (and efforts) will suddenly be dropped
• Improved decisions

The book recommends some interesting metrics for portfolios:

1. Velocity of team(s) doing the work
2. Project burn-up (with changes in scope)
3. Technical debt (for example, number of automated tests expected vs generated)
4. Amount in progress work
5. Time to resolve portfolio level obstacles (top 10 list)

The book recommends that, while the benefits are obvious if you have an agile process underneath this, that you can also adopt some of these ideas to good benefit even in waterfall approaches. For example:

• If you have a year long project, figure out what can be delivered and demonstrated after a quarter and use the feedback to adjust based on what you are seeing. Note that this will also improve the risk profile of your project.
• If you set up yearly budgets, internally “release” only the next quarter as a result of decisions and then review every quarter for the next release. Over time you'll find the finance people will like this approach as well as it allows for improved flexibility, but the approach does require that you really “finish” something and can prove it at a demo.

The book is not new, so there are some ideas that I expect could be added to the discussion:

• Inclusion of “buy-a-feature” approach to establish value across multiple stakeholders.
• Use of WSJF for ranking, to combine value, risk and timeliness
• “Sales funnel” approach to the Kanban board with status like “idea / funnel”, “review”, “analysis”, “backlog”, “implementation” and “done” ala SAFe

I understand that there is a new version of this book coming out in September 2016 and suspect that these ideas will be covered then. In the meantime, this is a very good summary of an approach to get the project portfolio under control.

• "Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects"