This is the sixth article in our agile project portfolio management series. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods. The following articles discussed demand management, categorization, evaluation, and funding. This article is about portfolio alignment.
Portfolio alignment is the combination of selection, prioritization, and balancing. As seen in the previous articles there is not much difference between PMI project portfolio management and Agile project portfolio management. At this stage in the process it is different. It is time to put the «Agile» in Agile project portfolio management.
Based on what we have learned from the previous articles we start with the following:
1. Project execution can be managed with any method you choose. It does not have to be an agile method.
2. A Portfolio Owner. In an upcoming article we will give a detailed description of this role.
3. A Project Backlog that contains a number of projects that are currently being executed and a number of project proposals. This list will be continuously updated by the Portfolio Owner based on decisions made in the portfolio alignment process.
4. A strategy that we have converted into strategic goals.
5. Categorized the backlog items on the Project Backlog based on the categories we have defined.
6. Have a set of evaluation methods implemented that we can use during the alignment process.
7. Have funding on an initiative and/or strategic goal level, so we are flexible in our decisions regarding starting and stopping projects.
The next step is creating the Portfolio Backlog.
The Portfolio Backlog
We already defined our Project Backlog and now we define our Portfolio Backlog. It contains the set of projects that are currently being executed and the ones that are selected to be executed. You can compare our two backlogs with the product backlog and the sprint backlog in a Scrum project. The project backlog is containing all ideas, proposals and unfinished projects, that can be prioritized at will based on the implemented evaluation process. The Portfolio Backlog contains only the set of projects that are currently being executed or are selected to be executed.
Both backlogs are owned by the Portfolio Owner. When he/she has a team supporting him/her you could give the ownership of the Portfolio Backlog also to the team. Similar to a Sprint Backlog.
Before we start discussing how we are going to select our projects for our Portfolio Backlog we should have a look at how many we are going to select.
How big should a Portfolio Backlog be?
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 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 of 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.
Looking at all the above we can learn three important things for our alignment process.
1. Keep your Portfolio Backlog size small (i.e. limit work in progress). Focus on limiting the number of concurrent projects in your organizational units.
2. Keep your project size small (i.e. limit batch size).
3. 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)
Portfolio alignment iterations
A core element of Agile is delivering in small iterations. As we have stated before we want to accommodate Agile and non-Agile projects in our process. One way to leverage the use of Agile projects in the portfolio management process is by using a monthly cadence to review the Portfolio Backlog. When you use Scrum as a delivery method you can give guidance that each project should have 1, 2 or 4-week sprints. This makes alignment very easy. When continuous delivery models are used alignment is also given, and when waterfall models are used you will have alignment as well. So for the rest of the article I assume you have monthly Portfolio Backlog review Meetings.
Goals of these monthly review meeting are portfolio evaluation, selection, prioritization, and balancing. The demand collection and categorization is something the Portfolio Owner should do before this meeting. This work can be compared with backlog refinement in the Scrum process.
Aligning projects and portfolio
The whole Project Backlog needs to be reviewed. Proposals can be selected for the portfolio, more information could be requested, or just left on the project backlog with a remark. Already selected projects can be stopped, re-prioritized or accelerated.
The big difference between project proposals and already selected projects is that selected projects are part of the monitoring process. This process will be discussed in detail in a later article. In general, the monitoring process will provide you with information in order to help you decide on what to do with this project. Typical information areas are people, risk, costs, time, planned value (scope) and delivered value. These inputs can then be used in your evaluation strategy.
The selection (including balancing) itself is easy. Just execute your evaluation strategy on your Project Backlog. Since your evaluation strategy includes costs, risks and people information you do not separately have to look at these constraints. Based on the resulting information from the evaluation (like ranked lists, bubble charts, strategic buckets, etc) you decide on your portfolio for this alignment iteration with the three portfolio goals in mind:
1. Maximize the value of the portfolio;
2. Seek the right balance of projects, thus achieving a balanced portfolio;
3. Create a strong link to strategy, thus: the need to build strategy into the portfolio;
After this selecting and balancing you should prioritize your Portfolio Backlog. Similar to the product backlog in Scrum all your items on the Portfolio Backlog should be ordered according to priority. When we could do only one project from this list, what project would that be? Then answer the same question for the remaining list. This prioritization will help with future portfolio review meetings and helps with the evaluation when it comes to the allocation of money and people, planning, and solving conflicting interests.
Focus on early validation
Instead of selecting a whole project at once you should start each large project (whatever large would mean for your organization) with a PoC and Business Case validation phase. Rather fail early and learn than having massive sunk costs for something that does not live up to their promise. Proof of concepts is essential for high technology risk projects. There are many techniques for business case validation but the simplest one is talking to potential and existing customers.
Visualize your Portfolio Backlog
An ideal way to represent the existing Portfolio Backlog in such a meeting is using a Kanban board. A Kanban board is a work and workflow visualization tool that enables you to optimize the flow of your work. Physical Kanban boards typically use sticky notes on a whiteboard to communicate status, progress, and issues. Online Kanban boards draw upon the whiteboard metaphor in a software setting.
For an agile portfolio as described in this article you could use the following swimlanes:
1. More information needed
2. New (selected, but not yet started)
3. Validation (PoC and/or business case validation)
4. In progress
5. Done
6. Stopped
The next article will be about authorization and roles. In order to be flexible with your project portfolio, you should be able to decide on changes in a quick, easy and formalized way. In other words, not go through a month-long delicate political dance to get approval for each small portfolio change. This has big implications for who has authority and responsibility for portfolio and strategy decisions.
Other articles in this series
1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion
