Making sense out of a tangled web of projects is hard work, but you need to do it. You’ll learn a lot about what your organization is working on, what it thinks is important, and how it works. You will probably even revisit some of your high-level strategies. This is all good. Additionally, once you’ve worked through this process, you will have created your Portfolio View, which provides an excellent, one-page, big-picture view of your business (for a more detailed example of a Portfolio View, see Appendix D). This, in turn, enables your portfolio management process to be integrated into your day-to-day operational project management processes for maintenance and reporting purposes.
Maintaining Alignment Through Review and Prioritization
Completing the initial creation of your business project portfolio is a solid milestone; however, maintaining the portfolio will require considerable effort. There are two basic mechanisms for keeping the elements of your portfolio in alignment as the various projects and the business move forward:
Ongoing project reviews
Periodic portfolio prioritization
Project reviews involve the ongoing monitoring of project status, milestones, and issues. When you are managing several agile projects simultaneously, you may find yourself addressing major project decision points almost constantly. As these significant events take place, you should not only be assessing their impact on the individual project, but also on the overall portfolio that is external to the project in question. If impacts on other projects are identified, then the project managers for those projects should be notified and apprised of the situation. The solution will likely involve some kind of joint effort or give-and-take between the two project teams. No matter what form the remediation takes, the key point is that the impact is identified and communicated in a timely manner. In this way, any ripple effect caused by a single project will quickly propagate through the portfolio and then settle out, hopefully before the next impact event.
Agile Strategy When conducting individual project reviews or status reporting, include a portfolio element to ensure that the project manager assesses how her project may affect others, and how they might affect hers.
Portfolio prioritization usually takes the form of a periodic review meeting chaired by a program manager and attended by the executive and/or functional management team. The goal of these review meetings is to reassess the priorities of the business objectives, programs, and projects, based on any changes driven by internal or external events since the last prioritization. This is a top-down process that gives a quick overview of the various elements of the portfolio, based on a few predetermined evaluation criteria. So, while this is largely a qualitative process, there is a quantitative dimension to it that helps keep emotions and pet projects in check. The evaluation criteria should be selected to reflect the business goals, as well as the realities of project management, most notably resources and progress to plan. An example of a workflow and template for a project prioritization process in provided in Appendix D.
The results of the reprioritization may have their own impacts and ripple effects on the project portfolio. Likely project adjustments coming out of a reprioritization include schedule and resource shifts, as well as project cancellation or postponement.
Agile Strategy Conduct periodic portfolio prioritizations based on the top-down approach of systematically looking at high-level business goals and organizational resources, to ensure that the organization continues to efficiently advance its highest-priority projects.
In an agile environment, you cannot afford the inefficiencies of working on things that do not contribute to the business objectives. By employing the bottom-up, project review–driven approach to portfolio adjustments, combined with the top-down prioritization process, you will have a much better chance of keeping your high-level objectives aligned with your tactical projects.
Resources—The Preeminent Agile Criteria
There are many different criteria used in the construction and prioritization of a project portfolio. Some notable ones include resources, strategic fit, competition, pipeline value, return on investment (ROI), and risk. Of all of these criteria, resources have a unique impact in the agile environment. There are two reasons. First, agile portfolios tend to be made up of many small projects, as opposed to fewer larger projects in the classic paradigm. Second, the high uncertainty in the agile environment may cause projects to change, be canceled, expand, or be newly initiated. These changes happen on a continual basis. Both of these dynamics intersect with the allocation of resources.
Agile portfolios tend to be made up of many small yet related projects.
Since resources are limited, the rapid change of projects in the agile portfolio requires that resources be efficiently shifted between projects, as needed, to advance the overall portfolio (see Figure 11-9). To effectively manage resources across the agile portfolio, you must know where resources are currently allocated and anticipate where they may be needed in the future.
Figure 11-9: Portfolio resource allocation in an agile versus classic environment.
When trying to anticipate how resources may need to be reallocated, you should consider another distinction between the agile and classic environments. In the agile environment, project timelines are often pulled in, giving little time for the team to adjust; whereas in the classic environment, timeline shifts are almost always pushed out, giving the team time to react to the change. A typical driver for a rapid portfolio shift is the signing of a new sales deal. The instant energy generated by a potentially lucrative deal propagates a “drop everything and start working on this new project” reaction. This approach is only partially correct. You probably do want to start working on this new project as soon as possible, but you don’t want to just drop everything. You want to cancel or postpone and, subsequently, shift resources from other projects where it makes sense and where there is the least impact on the overall business objectives.
You are much more likely to see unexpected timeline shifts to the left in an agile environment versus a classic one.
In essence, you want to be creating a portfolio plan that shows where your resources are being allocated at a macro level over the course of some time period. Once you have this information, you can determine funding needs and project plans based on various “what if” scenarios. I prefer to have a visual representation of this resource allocation. A portfolio-level Gantt chart, depicting each individual project as a single-line item, is a good way to gain a high-level view of your resource plan. It gives you a rough idea of project-to-resource density over time. The resource allocation to individual projects can be depicted as a color spectrum (e.g., light equals fewer resources, dark equals more resources) for a ballpark feel (see Figure 11-10), or exact percentages can be annotated in for more detail (see Figure 11-11).
Figure 11-10: Portfolio-level Gantt chart showing roughly estimated project/resource density over time.
Figure 11-11: Portfolio-level Gantt chart showing rough resource usage over time.
Agile Strategy Create a portfolio-level Gantt chart to get a high-level view of your resource allocations across the entire organization.
By making the assumption that work level is constant, on average, for each resource for the duration of the project in question (which is an acceptable top-down estimation technique for agile environments), then you can create the portfolio-level Gantt chart, modified with the addition of resources to get a more detailed pictorial view of resource usage across the portfolio. Figure 11-11 is an example of the annotated format.
Let’s examine how you might approach this task. Resource allocation is traditionally a detailed, bottom-up exercise starting at the task level and rolling up to the project and program levels. However, in agile PM, a top-down resource estimation is more appropriate. Spending inordinate time creating minute detail may be a wasted effort, if some external event creates a sudden change in the project plan.
The benefit of top-down estimation is that it is fast and doesn’t require grinding out the task-level details. The downside is that it just isn’t as accurate as bottom-up estimation. To compensate for this deficiency, we will look at a top-down estimate separately from both the project and portfolio perspectives, then compare results. If there are large discrepancies, we can revisit the estimate and make the necessary adjustments. If they are in agreement, then we have effectively increased our confidence level in the estimate by coming at it from two different angles.
Agile Strategy Increase the confidence level of your top-down resource estimates by examining them from both the project level and portfolio level, then comparing results.
Project-Level Resource Estimation
You will recall that in our previous discussion of the Project Data Sheet (see Chapter 7), we used a top-down, project-level, resource estimation technique (see Figure 11-12). By aggregating all of the Project Data Sheets, the portfolio manager can get a roll-up estimate of resources at the portfolio level for a specific time period.
Figure 11-12: Top-down, project-level, resource estimation table from Project Data Sheet template.
Portfolio-Level Resource Estimation
The primary difference in approaching resources from the portfolio level is in how and when you obtain the estimates. The project-level resource estimates were captured in the Project Data Sheet at the initiation of the project, and they may (or may not) have been updated since. If there are many projects, it could be a nuisance to regularly update resource estimates on multiple Project Data Sheets. You only want to have to go back to the PDS if you have reason to suspect that the original estimate is out of date. It is much more palatable to regularly review resources at the portfolio-level. Figure 11-13 is an example of a format that can be used with team members to capture top-down resource estimates at the portfolio-level. This data can be displayed as a pie chart or bar graph, but its primary value is for comparison against the resource data from the project-level PDS roll-up in order to identify the need for revisiting a particular area.