Resources - The Preeminent Agile Criteria

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.

Figure 11-13: Top-down, portfolio-level, resource estimation table for a specific period.

Agile Strategy

Monitor your monthly (periodic) resource estimates at the portfolio level, and only revisit resources at the project level when a gross mismatch is identified between the two.

Resource Estimates and Multiple Pathways

Since the future pathways of individual projects, as well as the overall portfolio, are not fully predictable, it is often valuable to do a resource analysis based on various potential scenarios. (For example, the test phase of project 1 will only take one pass, the sales group will close the deal for project 2 next month, etc.). I've found that the most valuable analysis is to create a resource-by-resource (or role-by-role) trend over time in the form of a bar chart (see Figure 11-14). This will let you quickly see the loading of any specific resource, should a particular scenario come to fruition.

Figure 11-14: Portfolio-level Gantt chart showing rough resource usage over time.

Resources:

Provide an estimate of the time to be spent on the various projects for the next period. Resources should be estimated using FTE months.

Period: Month