Agile Project Portfolio Management

As maturing organizations begin to implement Agile Project Management (APM), they need to consider how their current portfolio management process needs to be revised in order to accommodate APM, xPM, and MPx projects. At the time I was writing this edition of the book, there wasn't very much literature on Agile Project Portfolio Management. Agile Portfolio Management by Jochen Krebs (Microsoft Press, 2008) was the only book that I could find in print that deals with this topic.

Agile Project Portfolio Management is a logical consequence of the agile movement. Agile projects are those that are continuously redirected to take advantage of the learning and discovery about the solution that arises from the work of the project. Extend that same concept to the portfolio. At regular intervals the contents of the portfolio are changed and redirected to take advantage of the learning and discovery that arises from the performance of projects in the portfolio and from new project initiatives.

Agile Project Portfolio Management includes establishing the investment strategy of the portfolio, determining what types of projects/programs can be incorporated in the portfolio, evaluating alignment of the proposed projects to the strategy, prioritizing proposed projects/programs, constructing a balanced portfolio that will achieve the investment objectives, monitoring the performance of the portfolio, and at regular intervals adjusting the contents of the portfolio in order to maintain alignment to the strategy and achievement of the desired results.

Just as an APM or Extreme Project Management (xPM) project is continuously adjusted to deliver maximum business value, so should the agile project portfolio be adjusted. This means that at periodic review points, every project in the portfolio is evaluated to ensure that the contents of the portfolio are always aligned with the objectives of the portfolio. This also means that project priorities can change from review to review. Projects in the portfolio might be re-scoped, put on hold, delayed, stretched out over a longer time horizon, or outright canceled. New projects might be brought into the portfolio at these review points, too. The objective at these project review points is to adjust the projects in the portfolio that will be active for the next period and that produce the greatest expected business value of any combination of active projects. The portfolio will then contain new projects, projects postponed at some previous review point, as well as continued and continuing projects from the previous review for the next period.

Projects can change their status at any time. For example, if an active project becomes distressed, it may make no business sense to continue the project. So, it is canceled or postponed. In either case, the unused resources for that project now become available for projects being considered for the next portfolio review.

The agile project portfolio life cycle looks very similar to the project portfolio life cycle previously depicted in Figure 14-1. Figure 14-23 is the agile project portfolio life cycle.

Figure 14-23: Agile project portfolio life cycle

The only difference between Figure 14-1 and Figure 14-23 is the two-way arrow linking “MANAGE active projects” to “SELECT a balanced portfolio using the prioritized and active projects.” The agile project portfolio life cycle inputs the active projects to the SELECT activity. This means that the active projects must contend with the new projects for priority in the next portfolio. Creating a single prioritized list containing active projects from the just-completed portfolio cycle with new projects is a complex decision. New projects do not have a performance or business value history. Active projects do. One criterion that might be used is expected business value in the next portfolio cycle. For active and new projects, business value is a subjective estimate. Active projects do have a history of estimated versus actual business value, which may be used to adjust estimated business value for the next portfolio cycle.

Integrating a PMLC Model into the Agile Project Portfolio Management Process

In order to accommodate the Agile Project Portfolio Management (APPM) process you will need to define a very high-level PMLC that embraces the projects in all four quadrants. Whatever form your portfolio management process takes, it will have to be modified to align with some type of cyclical pattern. The cycles can be monthly, quarterly, semi-annual, or even annual. Either a quarterly or semi-annual portfolio cycle length will probably fit your organization's needs. Arguments can be put forth for longer as well as shorter cycles. This Executive Report assumes a quarterly portfolio cycle length. APM projects will have shorter duration iterations, but those projects can be planned so that several iterations can fit into a single cycle.

Figure 14-24 is a high-level PMLC model that can be adapted to any type of project and is one that fits a cyclical APPM process.

Figure 14-24: A PMLC model for the APPM process

This high-level PMLC model accommodates all four major project types (TPM, APM, xPM, and MPx) and will integrate directly into the APPM shown in Figure 14-23. There are some minor adjustments, however. First, the APPM process is cyclical, so to be compatible with it all projects in the portfolio must follow some type of cyclical model. That is true for all APM, xPM, and MPx projects, but not for all TPM projects. Within TPM approaches the Linear PMLC model does not fit but the Incremental PMLC model does. Any project that would otherwise use a Linear PMLC model will have to be planned using an Incremental PMLC model. The only other consideration is to have the completion of iterations of the project PMLC model align with the completion of the portfolio cycles of the APPM process. That has implications to PMLC iteration planning and is not a major obstacle.

The APPM life cycle consists of the following five phases and shown by the shaded boxes in Figure 14-23:

• ESTABLISH
• EVALUATE
• PRIORITIZE
• SELECT
• MANAGE

Prior to releasing the human resource investment plan, two questions should be answered by the portfolio manager:

• Will projects be partially staffed in order to include more projects in the portfolio, or will projects be staffed only at the level of their request?
• If an investment category has excess resources after project staffing decisions have been made, can those resources be reallocated to other investment categories without compromising the portfolio strategy, and if so, how will they be reallocated?

If possible, it is good to make these decisions before the situations arise. The rules need to be clear so that all parties are informed ahead of time.

This approach puts both new and active projects on the same metric for prioritization decisions, but the decision to be made is still not obvious. There is some value in having a team stay together on an active project rather than splitting the team up to staff a new project. That suggests building a tentative list of projects to be included in the coming portfolio and then staffing all active projects in the coming portfolio first. Staffing can then move to the new projects until the next project on the prioritized list cannot be staffed. Figure 14-25 graphically portrays how that staffing model might work.

Once the active projects that have been tentatively placed in the portfolio for the next portfolio cycle have been staffed, the prioritized list of new projects will be staffed as shown in Figure 14-25. This approach avoids the complications of trying to create an unbiased metric that can be used fairly on both new and active projects to create a single prioritized list of new and active projects.

Figure 14-25: Portfolio staffing model

Challenges of Managing Agile Portfolios

The contents of the agile portfolio are at risk at the end of every portfolio cycle. That raises a number of challenges for portfolio managers and those who submit project proposals for consideration. Among those challenges are:

• Choosing between continuing a project for another cycle or postponing it and replacing it with a new or previously postponed project
• Postponing projects risks losing team members if the project should later be returned to active status
• Changing portfolio contents from one cycle to another may lead to a higher probability of project failure due to increased thrashing and missed windows of opportunity
• Comparing the expected business value of a traditional project against an agile project is like comparing apples to oranges

Handling High Change and High Speed

Change is constant in the contemporary business world. Most would agree that change is changing at an increasing rate. Factor into that the constant technology changes and market changes, and most organizations will have a very difficult time keeping up and maintaining their competitive position. If they don't leverage the technology quickly or at all, someone else will, and they will lose market share and market position. That translates to having a portfolio management process that can adapt and respond intelligently and quickly to unexpected change. That is the purpose of an agile approach to project portfolio management.

Managing Complexity and Uncertainty

High change and high speed are positively correlated with increasing complexity and uncertainty. The contents of the portfolio at any point in time represent the portfolio manager's best guess at how to leverage projects to exploit the near-term future. No one knows the future so there is the accompanying risk to the portfolio that you have decided on the wrong course of action. If you had had perfect knowledge of the future, the portfolio would have been properly constructed to return maximum business value for the investment. No one has that knowledge, so all you can do is make best guesses and make the appropriate decisions as to the contents of the portfolio. Those decisions will be made on a regular basis, say quarterly. On a quarterly basis the contents of the portfolio may be changed for the coming quarter and that process repeated without end.

Nurturing Creativity

Because the contents of an agile portfolio can change at regular intervals, that change will affect the creative environment needed to support the projects. On the one hand agile and extreme project teams may not be fully committed to a complex and uncertain project if the threat of postponement or cancelation looms on the horizon. Conversely, the agile or extreme project team may be even more committed to success and exemplary performance in order to protect the continuation of their project as much as they can. Both scenarios impact creativity and the project manager will need to pay particular attention to evidence of the impact.

SELECT a Balanced Portfolio

You might think that because you have a prioritized list in each support category and you know the resources available for those projects, the selection process would be simple and straightforward, but it isn't. Selection is a very challenging task for any portfolio management team. The problem stems from the apparent conflict between the results of evaluation, the ranking of projects from most valuable to least valuable, the need to balance the portfolio with respect to one or more variables, and the availability of skilled professionals. These factors are often in conflict with one another. As a further complication, you may decide that partial staffing of projects makes sense. Partial staffing extends the total duration of the project and can increase the risk of project postponement or failure.

There are several approaches to picking the project portfolio. I've chosen to focus on the Graham-Englund Selection Model (Figure 14-26).

Figure 14-26: Agile version of the Graham-Englund Selection Model: Adapted from Graham, Robert and Randall Englund. 1997. Creating an Environment for Successful Projects. San Francisco, CA: Jossey Bass, ISBN 0-7879-0359-0.

Very few organizations use a complete project selection process for their portfolio. Many are based on dollars available in the portfolio and ignore staffing. Once the projects have been allocated to the Risk versus Business Value Project Distribution Matrix and you have generated Table 14-1, you will have a prioritized list of projects. Then the Graham-Englund Model can be used to determine how many of the projects, starting at the top of the list, can be staffed. Staffing constraints may affect priorities when lower priority projects can be staffed when higher priority projects may not have the available staffing.

What Should We Do?

The answer to this question is equivalent to establishing the portfolio strategy. In the case of the Graham-Englund Selection Model, you are probably referring to the IT strategy of the organization. The answer can be found in the organization's values, mission, and objectives; it is the general direction in which they should be headed consistent with who they are and what they want to be. It is the role of IT to support those goals and values. IT will do that by crafting a portfolio of projects consistent with those goals and values. Think of answering “What should we do?” as the demand side of the equation. You will use the project class (new, enhancement, maintenance) and the project type (strategic, tactical, and operational) to identify the projects you should undertake. These categories loosely align with the skill sets of the technical staff and will give you a basis for assigning resources to projects. In fact, any categorization that allows a mapping of skills to projects will do the job. I have kept it simple for the sake of the example, but this approach can get very complex. One complexity arises when the full-time equivalent (FTE) schedule commitments of a staff member are plotted against the project requirements and schedule for those skills.

What Can We Do?

The answer to this question is found by comparing project requirements to the organization's resource capacity. Current commitments come into play here, as the organization must look at available capacity, rather than just total capacity.

Dealing with the issue of what your organization can do raises the important issue of having a good human resource staffing model in place — one that considers future growth of the enterprise, current and projected skills inventories, training programs, career development programs, recruiting and hiring policies and plans, turnover, retirements, and so on.

Think of answering “What can we do?” as the supply side of the equation in Figure 14-26.

What Will We Do?

There are adjustments that can be made to allow more projects to be done. For example, if the bottleneck is the programmer staff, an adjustment of required programmers by level might be relaxed to allow lower-level programmers to fill project requirements.

How Will We Do It?

Answering this question is roughly equivalent to the selection phase in the portfolio project life cycle. In the case of resource management, “How will we do it?” is just a big staffing and scheduling problem. By scheduling scarce resources across the prioritized list, you are placing more projects on active status; that is, they will be placed in the portfolio. Detailed project plans are put in place, and the scheduling of scarce resources across the projects is coordinated. Performance against those plans is carefully monitored because the resource schedule has created a dependency between the projects. A critical chain approach could be used here. Consult the book Critical Chain Project Management by Lawrence Leach (Artech House, 2000).

MANAGE Active Projects

In this last phase, you continuously compare the performance of the projects in the portfolio against your plan. Projects can be in one of three statuses: on plan, off plan, or in trouble. These were discussed earlier in this chapter. You will see how that status is determined and what action you can take as a result. Here, the challenge is to find performance measures that can be applied equitably across all the projects. Two come to mind:

• Earned value
• Milestone trend charts

A detailed discussion of these was given earlier in this chapter.

Available Human Resources

If you increase the task variety assigned to an individual, you increase the risk of failure of all the tasks assigned to them. That applies to changing project assignments, too. To the extent possible you should try to keep a team intact. If the project is continued to the next cycle, that should not be a problem unless the project has moved further down in the prioritized list. The model may assign some or all of the team members to the higher priority projects, leaving less-skilled staff for the continuing project. Despite the simplicity of the expected business value approach, there will be subjective decisions regarding staff assignments.

Closing Projects in the Agile Portfolio

Best practices include acceptance criteria, agreed upon by the client and the project manager during project planning, that clearly state when the project is considered finished. These acceptance criteria usually take the form of a checklist of scope items or requirements. When all items on the checklist have been checked off as completed, the project is deemed finished. The work of the project, however, is not yet complete. What remains is what I have called a post-implementation audit. See Chapter 8.

Because the agile portfolio can contain any type of project, there are some added considerations. Those projects that are APM, xPM, or MPx deal with varying degrees of uncertainty. That means that the cycle-to-cycle expected business value may or may not be realized. In judging the short-term delivered value the portfolio manager cannot ignore the long-term expectations. They will change as a function of short-term delivered value. How to prioritize such projects is difficult and usually reduces to subjective decisions. That is the nature of uncertainty, and the portfolio manager just has to deal with it.