The Project Portfolio Management Life Cycle

,

No matter how you slice and dice it, the Project Portfolio Management life cycle consists of the following five phases:

1. Establish
2. Evaluate
3. Prioritize
4. Select
5. Manage

These phases are delineated with shaded boxes in Figure 14-1. In this diagram, I have embedded a generic project in the phases to illustrate the principles involved and the possible courses of action that a project may take over the course of its life. All of the discussions that follow in the remaining sections of this chapter are based on this diagram.

Figure 14-1: Project portfolio life cycle

Also shown in Figure 14-1 is the changing status of a project as it moves through this life cycle. Note that there are eight different stages that a project may be in during this life cycle. These stages are as follows:

A project may find itself in any one of these eight stages as it proceeds through the five phases of the Project Portfolio Management life cycle. The following sections of this chapter cover each one of the five phases in more detail.

ESTABLISH a Portfolio Strategy

The first step in portfolio management is deciding the strategy for the portfolio. That strategy is an investment strategy. That is, how will the enterprise's funding be spread across the portfolio? Once this investment strategy is in place, the enterprise will have a structure for selecting the investment opportunities that will be presented in the form of project proposals. This is really a type of strategic planning phase in which the portfolio manager or the portfolio management team decides how it will allocate its project budget to various general categories of project investment.

Several models are easily adapted to this phase. In this chapter, I examine the following five popular models:

• Strategic Alignment Model
• Boston Consulting Group (BCG) Products/Services Matrix
• Project Distribution Matrix
• Growth versus Survival Model
• Project Investment Categories Model

Each model has desirable characteristics that meet the organization's need for good investment strategies. The strategy itself is determined by the dollar or resource investment (people, machines, facilities, and so on) that the company is willing to make in each of the funding categories defined by the various models. Once this strategy is in place, a final question must be answered: Which projects will be funded in each of these categories? The answer to that question is found in the next three phases of the model.

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

• Will projects be partially funded in order to include more projects in the portfolio, or will projects be funded only at the level of their request?
• If an investment category has excess resources after project funding 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.

Strategic Alignment Model

The first model is the Strategic Alignment Model. This model makes good sense because it attempts to align projects with the direction the enterprise has decided to follow. In other words, it aligns projects with the things that are important to the enterprise. Figure 14-2 graphically depicts this model.

Value/Mission

The value/mission is a very brief statement of why the enterprise exists. This could define an end state that the enterprise hopes to achieve or simply be a statement of how the enterprise views the business it is in. Whichever form is used, this statement is unlikely to change, at least not in the foreseeable future.

Figure 14-2: Strategic Alignment Model

Goals

To achieve its end state or accomplish its mission, the enterprise has to engage in certain major efforts. These are likely to be multiperiod or multiyear efforts designed to accomplish major results. They might never be attainable (eliminating world hunger, for example), or they might be achievable over long periods of time (finding a cure for cancer or a preventative for the common cold, for example). Any of these are good examples of goal statements. The important thing to remember is that they must be stated in a fashion that links them directly to one or more of the corporate objectives.

Objectives

There will be many approaches to the realization of each goal. Each approach is called an objective, which might be a one-year effort or span several years. Again, take the example of the preventative for the common cold. Objectives might include investigating possible food additives, modifying the immune system, or finding a drug that establishes immunity to the cold. All three of these objectives can launch a number of tactics.

Tactics

Tactics are the short-term efforts, usually less than one year in duration, designed to meet one or more objectives. These are the projects that will be proposed for the portfolio. A project that relates to only one objective will be less attractive to the portfolio manager than a project that relates to several objectives. Similarly, a project that relates to a lower priority objective will be less attractive than a project that relates to a higher priority objective. You will see how this works in the “SELECT a Balanced Portfolio Using the Prioritized List” section later in this chapter.

How Are You Going to Allocate Your Resources?

The application of this model is quite straightforward. The enterprise must decide what resources will be allocated to each goal and to the objectives that support that goal. With that decision made, the enterprise accepts project proposals from its various departments regarding what projects they wish to undertake and how those projects relate to the goals and objectives of the enterprise. Obviously, there won't be much interest in supporting projects that do not further the goals of the enterprise.

Boston Consulting Group Products/Services Matrix

The BCG Matrix is a well-known model that has been used for several years. It defines four categories of products/services based on their growth rate and competitive position, as shown in Figure 14-3.

Figure 14-3: BCG Products/Services Matrix

Cash Cows

These are well-established products/services that have a strong market share but limited growth potential. They are stable and profitable. Projects that relate to cash cows are important to the organization because the company will want to protect that investment for as long as it maintains that market position.

Dogs

Because these products/services are not competitive and have little or no growth potential, any projects related to them should not be undertaken. The best thing an organization can do with dogs is phase them out as quickly and painlessly as possible. Don't throw good money after bad!

Stars

These are products/services that have strong market positions and clearly strong growth potential. Projects related to stars are good investment opportunities. Stars are the future cash cows.

?

The question mark represents the starting point of the model. Products/services that are untested in the market but appear to have strong growth potential are worthy of spending research and development (R & D) dollars. Projects linked to those efforts are good investment opportunities. The objective is to turn them into stars and then cash cows.

How Are You Going to Allocate Your Resources?

The answer to this question depends on the current market position of the enterprise, the business outlook, and a variety of other considerations. Except for the dogs, the other three categories will have some level of investment. If the industry is stable, such as cement manufacturing, more resources might be spent on the cash cows to ensure that they maintain their market position, fewer resources will be allocated to the stars because the enterprise will always want to keep some growth opportunities in the pipeline, and even fewer on the ? category because the industry isn't in the R & D mode. In a volatile, high-growth, high-tech industry, the allocations might be very different. More resources will be spent on the stars and ? projects and fewer on the cash cows. Cash cows have a very short useful life, and any investments in them are risky.

Project Distribution Matrix

Simple, yet elegant in its simplicity, the Project Distribution Matrix, shown in Figure 14-4, says that there must be a mix of projects in the portfolio. This mix will be dictated by the skills inventory of those who work on the projects, as well as the needs of the organization to attain and sustain market share. It can be used in conjunction with the models shown previously to ensure that a healthy mix is present in the project portfolio. The Project Distribution Matrix is similar to the Strategic Alignment Model in that it defines a rule for classifying projects. The rule is a two-way classification, as shown in the figure.

Figure 14-4: Project Distribution Matrix

New, Enhancement, or Maintenance

The columns of the matrix classify projects according to whether they are New, Enhancement, or Maintenance, as follows:

Strategic, Tactical, or Operational

The rows of the matrix classify projects based on their role in the enterprise, as follows:

How Are You Going to Allocate Your Resources?

The application of this model is quite straightforward. The enterprise that has defined a project classification rule must now decide what resources will be allocated to each of the nine categories shown in Figure 14-4. With that decision made, the enterprise accepts project proposals from its various departments as to what projects they wish to undertake. A feature of this model is that it can be tied to the resource pool of skilled employees. The required skills across each of these nine categories shown in Figure 14-4 are different. To some extent, that may dictate how much emphasis is placed on each category. The enterprise will want to use its available skills, so the relative priority of each category can help or hinder that effort.

Growth versus Survival Model

This way of categorizing projects is the simplest of all presented here. Projects are either focused on growth or survival. Growth projects are those that propose to make something better in some way. Obviously, these are discretionary projects. Survival projects are the “must-do” projects. These projects must be done or the enterprise will suffer irreparable damage. In short, survival projects are projects that must be done, and all other projects are growth projects.

If the budget is in a contracting phase, you will probably allocate most of your resources to the survival category. Conversely, if you are in an expansion phase, you will allocate most of your resources to the growth category.

Project Investment Categories Model

The Project Investment Categories Model is a close kin of the financial investment portfolio. It identifies categories of investments. These categories define types of projects, just as a financial portfolio defines types of investment instruments. In the case of projects, you define the following categories:

Each type of project will receive some percentage of the resource pool.

This model operates just like the BCG Products/Services Matrix discussed earlier in the chapter. Both models require the portfolio manager to establish a distribution across existing and new products and services. The distribution will most likely be directly related to whether the enterprise is in a growth or maintenance posture with respect to its upcoming investment strategy.

Choosing Where to Apply these Models

Depending on the particular application that you have in mind, you will want to choose the most appropriate model. This section helps you consider some of the possibilities.

Corporate Level

If your organization has an enterprise-wide project management office that has management responsibility for the project portfolio, then your choice of model is limited to the BCG Products/Services Matrix or the Strategic Alignment Model. Both of these are good candidates, because they focus on the strategic goals of the organization at the highest levels and can directly relate a single project to how well it aligns with defined strategies. That provides a basis for prioritizing a project.

Functional Level

At the corporate level, dollars are allocated to strategic initiatives that affect the entire organization, whereas at the functional level — the IT department, for example — the situation can be quite different. Resources are allocated to operational- or tactical-level projects. Rather than allocate dollars, it is more likely that the resource to be allocated is professional staff. In that case, the Project Distribution Matrix, Growth versus Survival Model, or Project Investment Categories Model will do the job.

EVALUATE Project Alignment to the Portfolio Strategy

This evaluation is a very simple intake task that places a proposed project into one of several funding categories as defined in the model being used. The beginning of the project intake process involves determining whether the project is in alignment with the portfolio strategy, and placing it in the appropriate “bucket.” These buckets are defined by the strategy that is used, and each bucket contains a planned dollar or resource amount. After all of the projects have been placed in buckets, each bucket is passed to the next phase, where the projects that make up a bucket are prioritized.

This intake process can take place in one of the following ways:

• The person proposing the project does the evaluation.
• The intake person does the evaluation.

It can work well either way. If the person proposing the project does the evaluation, he or she needs a clear definition of each funding category in the portfolio strategy. The project proposal may be returned to the proposer for clarification or revision before being placed in a funding category. Some procedures may ask the proposer to classify the project, in which case this intake process is nothing more than an administrative function. This places the burden on the proposer and not on the portfolio manager. However, there is the possibility of biasing the evaluation in favor of the proposer. The bias arises when the proposer, having such intimate familiarity with the proposal, evaluates it subjectively, rather than objectively. There is also the strong likelihood that these types of evaluations will not be consistent across all projects. Having an intake person conduct the evaluations ensures that all proposals are evaluated using a consistent and objective criteria.

In other cases the process is more formal, and the project proposal is screened to specific criteria. This formal evaluation is now a more significant process and may involve the portfolio manager or a portfolio committee. Projects that do not match any funding category are returned to the proposer and rejected with no further action specified or requested. If the portfolio manager does the evaluation, the problem of bias largely disappears. In this scenario, the proposer must follow a standard procedure for documenting the proposed project. This topic is revisited in the “Preparing Your Project for Submission to the Portfolio Management Process” section later in this chapter.

The deliverable from this phase of the process is a simple categorization of projects into funding categories.

PRIORITIZE Projects and Hold Pending Funding Authorization

The first tactical step in every portfolio management model involves prioritizing the projects that have been shown to be aligned with the portfolio strategy. Recall that the alignment places the project in a single funding category. It is those projects in a funding category that you prioritize. When you are finished, each funding category will have a list of prioritized projects. Dozens of approaches could be used to establish that prioritization. Some are nonnumeric; others are numeric. Some are very simple; others can be quite complex and involve multivariate analysis, goal programming, and other complex computer-based algorithms. My approach here is to identify methods that can easily be implemented in the public sector and do not require a computer system for support, although sometimes a simple spreadsheet application can reduce the labor intensity of the process. This section describes the following six models:

• Forced Ranking
• Q-Sort
• Must-Do, Should-Do, Postpone
• Criteria Weighting
• Paired Comparisons
• Risk/Benefit

Forced Ranking

Forced Ranking was introduced in Chapters 3 and 11. A further example is shown here. This approach is best explained by way of an example. Suppose 10 projects have been proposed. Number them 1, 2, … 10 so that you can refer to them later. Suppose that the portfolio management team has six members (A, B, … F), and they are each asked to rank the 10 projects from most important (1) to least important (10). They can use any criteria they wish, and they do not have to describe the criteria they used. The results of their rankings are shown in Table 14-1.

Table 14-1: Forced Ranking of 10 Projects

The individual rankings from each of the six members for a specific project are added to produce the rank sum for each project. Low values for the rank sum are indicative of projects that have been given high priority by the members. For example, Project 7 has the lowest rank sum and is therefore the highest priority project. Ties are possible. In fact, the preceding example has two ties (1 and 4, 6 and 9). Ties can be broken in a number of ways. For example, I prefer to use the existing rankings to break ties. In this example, a tie is broken by taking the tied project with the lowest rank score and moving it to the next lowest forced rank. For example, the lowest rank for Project 1 is 6, and the lowest rank for Project 4 is 8. Therefore, the tie is broken by giving Project 1 a rank of 2 and Project 4 a rank of 3.

Forced Ranking works well for small numbers of projects, but it does not scale very well.

Q-Sort

In the Q-Sort model (see Figure 14-5), projects are first divided into two groups: high priority and low priority. The high-priority group is then divided into two groups: high priority and medium priority. The low-priority group is also divided into two groups: low priority and medium priority. The next step is to divide the high-priority group into two groups: very high priority and high priority. The same is done for the low-priority group. The decomposition continues until all groups have eight or fewer members. As a last step, you could distribute the medium-priority projects to the other final groups.

Figure 14-5: An example of the Q-Sort model

The Q-Sort method is simple and quick. It works well for large numbers of projects. It also works well when used as a small group exercise using a consensus approach.

Must-Do, Should-Do, Postpone

This approach (and variations of it such as MoSCoW) is probably the most commonly used way of ranking. As opposed to the forced rank, in which each individual project is ranked, this approach creates a few categories, such as Must-Do, Should Do, and Postpone. The person doing the ranking only has to decide which category the project belongs in. The agony of having to decide relative rankings between pairs of projects is eliminated with this approach. The number of categories is arbitrary, as are the names of the categories.

This method is even simpler than Q-Sort. If the number of projects is large, you may need to prioritize the projects within each of the three groups in order to make funding decisions.

Criteria Weighting

There are literally hundreds of criteria-weighting models. They are all quite similar, differing only in the minor details. I give one example of criteria weighting, but several others apply the same principles. A number of characteristics are identified, and a numeric weighting is applied to each characteristic. Each characteristic has a scale attached to it. The scales usually range from 1 to 10. Each project is evaluated on each characteristic, and a scale value is given to the project. Each scale value is multiplied by the characteristic weight, and these weighted scale values are added. The highest result is associated with the highest-priority project.

Figure 14-6 shows a sample calculation for one of the proposed projects for the portfolio. The first column lists the criteria against which all proposed projects for this portfolio will be evaluated. The second column lists the weight of that criterion (higher weight indicates more importance to the scoring algorithm). Columns 3 through 7 evaluate the project against the given criteria. Note that the evaluation can be given to more than one level. The only restriction is that the evaluation must be totally spread across the levels. Note that the sum of each criteria is one. Using the Contribute to Goal B row as an example, multiply the rating (0.2) times the value of “Very Good (8)” to get a score of 1.6, and then multiply the rating of (0.8) times the value of “Good (6)” to get a value of 4.8. Add the values 1.6 and 4.8 to calculate the total rating of Contribute to Goal B as 6.4, shown in column 8. So the eighth column is the sum of the levels multiplied by the score for that level. This process is totally adaptable to the nature of the portfolio. The criteria and criteria weight columns can be defined to address the needs of the portfolio. All other columns are fixed. The last two columns are calculated based on the values in columns 2 through 7.

Figure 14-6: Criteria weighting

Paired Comparisons Model

The next scoring model is called the Paired Comparisons Model. In this model, every pair of projects is compared. The evaluator chooses which project in the pair is the higher priority. The matrix in Figure 14-7 is the commonly used method for conducting and recording the results of a paired comparisons exercise.

First note that all 10 projects are defined across the 10 columns and down the 10 rows. For 10 projects, you have to make 45 comparisons. The 45 cells above the diagonal contain the comparisons you make. First, Project 1 is compared to Project 2. If Project 1 is given a higher priority than Project 2, then a “1” is placed in cell (1, 2) and a “0” is placed in cell (2, 1). If Project 2 had been given a higher priority than Project 1, then you would place a “0” in cell (1, 2) and a “1” in cell (2, 1). Next, Project 1 is compared to Project 3, and so on, until Project 1 has been compared to all other nine projects. Then Project 2 is compared to Project 3, and so on. Continuing in this fashion, the remaining cells are completed. The final step is to add all the entries in each of the 10 rows, producing the rank for each project: the higher the score, the higher the rank. The rightmost column reflects the results of those calculations. Note that Project 7 had the highest overall priority.

Figure 14-7: An example of paired comparisons

Risk/Benefit

The final scoring model is the Risk/Benefit Matrix. There are many ways to do risk analysis, from subjective methods to very sophisticated mathematical models. The one I am introducing is a very simple quasi-mathematical model. Risk is divided into five levels (1, 2, … 5). Level 1 has a very low risk (or high probability of success), and level 5 has a very high risk (or very low probability of success). Actually, any number of levels will do the job. Defining three levels is also quite common. In this model, you assess two risks: the risk of technical success and the risk of business success. These are arranged as shown in Figure 14-8.

Each project is assessed in terms of the probability of technical success and the probability of business success. The probability of project success is estimated as the product of the two separate probabilities. To simplify the calculation, the graph shows the results of the computation by placing projects in one of the following three shaded areas:

• Lightly shaded — These projects should be funded.
• No shading — These projects should be considered.
• Darkly shaded — These projects should be referred back to the proposing agency unless there is some compelling reason to fund them.

Figure 14-8: Risk/Benefit Matrix

When you have a large number of projects, you need to prioritize those that fall in the lightly shaded cells. A good way to do this would be to prioritize the cells starting in the upper-left corner and working toward the center of the matrix.

SELECT a Balanced Portfolio Using the Prioritized List

You might think that because you have a prioritized list in each funding 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, and the need to balance the portfolio with respect to one or more variables. These two notions are often in conflict. As a further complication, should partial funding of projects be allowed? You will examine this conflict in the “Balancing the Portfolio” section later in this chapter.

There are several approaches to picking the project portfolio. As you have already seen, this chapter deals with five portfolio strategies and six prioritization approaches. That gives you 30 possible combinations for selection approaches, and many more could have been covered. From among the 30 that I could examine, I have focused on the following three:

• Strategic Alignment Model and Weighted Criteria
• Project Distribution Matrix and Forced Ranking
• Graham-Englund Selection Model with the Project Investment Categories and the Risk/Benefit Matrix

This section shows the results of combining the previous sections into an approach for selecting projects for the portfolio. Based on your choice of model, you make a statement about how your resources will be allocated. Each one of these models generates “buckets” into which resources are distributed. The buckets that contain more resources have a higher business value than those with fewer resources. These buckets represent the supply of resources available to the projects that are demanding those resources. It would be foolish to expect a balance between the supply of resources and the demand for them. Some buckets will have more resources than have been requested, whereas others will not have enough resources to meet demand. This section explains how to resolve those differences to build a balanced portfolio.

Balancing the Portfolio

Unfortunately, there isn't a perfect or best way to build a balanced portfolio. There are basically the following two approaches, and neither one ensures an optimal solution:

• The first approach is to make one master list of prioritized projects. However, if you simply use that prioritized list of projects with any of the models presented so far, you may end up with less than satisfactory results. For example, you could end up funding a number of short-term, low-risk projects with low organizational value. Alternatively, you could end up funding all long-term, high-risk projects with high organizational value. In either case, the resulting portfolio would not be representative of the organization's strategy. In other words, you could end up with a portfolio that is not at all in line with the corporate strategy.
• The second approach, and the one that I have taken here, is to separate projects into buckets, and then prioritize the projects that have been placed in each bucket. Although this certainly gives you a balanced portfolio, it may not give you the best portfolio. Some buckets may have been very popular choices for proposed projects, and a very good project may not have reached high enough on the priority list to be funded. Yet that project may be a much better alternative than some project in another bucket that did receive funding. It's basically the luck of the draw.

Which approach should you take? I recommend the second, for the following two reasons:

• Prioritizing a single list, which may be long, is far more difficult than working with several shorter lists. The work can be divided among several persons or groups in the second case, but not in the first case. Furthermore, when you first align projects with funding categories and then prioritize within funding categories, you are working not only with a smaller number of projects, but with a group of projects that are more homogeneous.
• Once the projects have been aligned within funding categories, the portfolio manager may then allocate the resources across the funding categories. That avoids situations in which there could be a wide variance between the resources that are being requested and those that are being offered in each category. The caution here is that the portfolio manager may try to honor the requests and abandon any portfolio strategy. You can't have it both ways.

The examples given in the sections that follow illustrate some of these ideas. These are but a few of the many examples I could give, but they are sufficient to illustrate some of the ways to mitigate against such outcomes and ensure a balanced portfolio that reflects the organization's investment strategy.

Strategic Alignment Model and Weighted Criteria

In this section, I use the Strategic Alignment Model to select projects for the portfolio. Figure 14-9 shows one variation that you might use.

Each objective is weighted with a number between 0 and 1. Note that the sum of the weights is 1. These weights show the relative importance of each objective compared against the others. Below each objective is the budget allocated to that objective. The total budget is $20M. Ten projects are being considered for this portfolio. The proposed budget for each is shown with the project number. The total request is for $25M. In this example, a project may be associated with more than one objective. You can do that by assigning to each project objective pair a weight that measures the strength of the relationship of that project to that objective. This weight is the result of evaluating the alignment of the projects to the objectives. The sum of the weights for any project is 1.0. To establish the priority order of the 10 projects, multiply the objective weight by the project weight and add the numbers. The result of that calculation is shown in the Score column for all 10 projects in the example. The higher the project's score, the higher the project should be on your list of projects to fund. In this example, Project 7 is the top-priority project, with a score of 0.300. Project 10 is the tenth priority, with a score of 0.120.

Figure 14-9: Achieving balance with the Strategic Alignment Model

The awards to the projects are made by starting with the highest-priority project, which in the example is Project 7. The request is for $3M. Of that amount, 80 percent will come from the budget for Strategy 2 and 20 percent will come from Strategy 4. That reduces the budget for Strategy 2 from $5M to $2.6M and for Strategy 4 from $4M to $3.4M. The process continues with the next highest-priority project and continues until the budget for each strategy is allocated or there are no more requests for resources. In some cases, a project may receive only partial funding from a funding category. For example, Project 10 should have received $1.6M from Strategy 1, but when it came up for funding, there was only $0.3M left in that budget. Following the example to its completion results in the allocations shown in Figure 14-9. The requests total $25M, the budget totals $20M, and the allocations total $19.4M. The remaining $0.6M should not be redistributed to projects that did not receive their requested support. These resources are held pending performance of the portfolio and the possible need to reallocate resources at some later date.

This section gives you but one example of applying an adaptation of criteria weighting to the Strategic Alignment Model to produce a portfolio selection approach. This model is probably the best of those discussed in this chapter because it enables the portfolio manager to express the enterprise strategy in a direct and clear fashion through the weights chosen for each objective. It also shows how the proposed projects relate to that prioritization through the weighted scores on each objective. The model provides management with a tool that can easily adapt to changing priorities and that can be shared with the organization.

Project Distribution Matrix and Forced Ranking Model

To further illustrate the process of creating a portfolio selection approach, next I combine the Project Distribution Matrix and the Forced Ranking Model. Assume that the total dollars available for Major IT Projects is $20M and that the dollars have been allocated as shown in Figure 14-10. I'll use the same 10 projects from the previous section with the same funding requests. The projects are listed in the order of their ranking within each funding category.

Figure 14-10: Project Distribution Matrix with budget and funding requests

The first thing to note in this example is that the investment decisions do not line up very well with the funding requests from the 10 projects. There is a total of $9M in four funding categories, with no projects aligned in those categories. Your priorities as portfolio manager were expressed by your allocation of funds to the various funding categories. However, the project proposals do not line up with that strategy. Are you willing to make any budget changes to better accommodate the requests? You should, but with the stipulation that you do not compromise your investment strategy. Legitimate changes would be to move resources to the left but in the same row, or up but in the same column. If you agree that that is acceptable, then you end up with the allocations shown in Figure 14-11. $3M was moved from the Strategic/Maintenance category to the Strategic/Enhancement category, and $1M was moved from the Operational/New category to the Tactical/New category. Any other movement of monies would compromise the investment strategy.

Figure 14-11: Project Distribution Matrix with adjusted budget and funding requests

After the allocations have been made, you are left with the matrix shown in Figure 14-12. The balances remaining are also shown in Figure 14-12. These monies are to be held pending changes to project status as project work is undertaken.

Figure 14-12: Project Distribution Matrix showing budget balances and funding decisions

Graham-Englund Selection Model and the Risk/Benefit Matrix

In the examples shown thus far, the only resource I have been working with is money. However, one of the most important resources, at least for IT projects, is people. Staff resources are composed of professionals of varying skills and experience. As you consider the portfolio of projects, you need to take into account the ability of the staff to deliver that portfolio. For example, if the portfolio were largely new or enhanced strategic applications, you would draw heavily on your most experienced and skilled professionals. What would you do with those who have fewer skills or experience? That is an important consideration, and the Graham-Englund Selection Model approaches project selection with that concern in mind. Basically, it works from a prioritized list of selected projects, and staffs them until certain sets of skilled and/or experienced professionals have been fully allocated. In other words, people, not money, become the constraint on the project portfolio. Several related challenges arise as a result. I will briefly discuss some of the issues and staffing concerns that this approach raises.

The Graham-Englund Selection Model is a close parallel to the models previously discussed, but it has some interesting differences. I added it here because of its simplicity and the fact that it has received some attention in practice. Figure 14-13 illustrates an adaptation of the portfolio project life cycle to the Graham-Englund Selection Model.

Figure 14-13: An adaptation of the Graham-Englund Selection Model

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 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 IT's role 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 investment categories (infrastructure, maintenance, new products, and research) 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.

Figure 14-14 shows a list of the 10 projects and the skilled positions needed to staff them. The second column gives the number of staff members in each position that are available for these 10 projects. Again, I have kept the data simple for the sake of the example.

Figure 14-14: Project staffing requirements

A variation that might be incorporated is to replace the Xs in the figure with the percent (%) allocation required. That can be somewhat helpful. But schedule constraints add to the complexity, and %s may not be much better than Xs in the long run.

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, because the organization must look at available capacity rather than just total capacity.

Think of answering “What can we do?” as the supply side of the equation. Figure 14-14 lists the projects that can be done with the staff resources available. Under each project number is the type of project (I = infrastructure, M = maintenance, N = new product, and R = research). However, it does not say which projects will be done. Not all of them can be done simultaneously with the available staff resources, so the question as to which ones will be done is a fair question.

What Will We Do?

The list of projects given in Figure 14-14 is longer than the list of projects you will do. The creation of the “will-do” list implies that some prioritization has taken place. Various criteria such as Return On Investment (ROI), break-even analysis, internal rate of return, and cost/benefit analysis might be used to create this prioritized list. In this example, I use the list that results from the Risk/Benefit Matrix, as shown in Figure 14-15.

Figure 14-15: Projects prioritized using the Risk/Benefit Matrix

The priority ordering of the projects based on the probabilities of success is P#1, P#4, P#5, P#2, P#7, P#3, P#6, P#8, P#9, and P#10. If you staff the projects in that order, you will be able to staff Projects 1, 4, 5, 2, and 7. At that point, you will have assigned all resources except one senior project manager. Projects 3, 6, and 8 did fall in the acceptable risk categories, but no resources are left to staff them.

However, this example is oversimplified. You have assumed that a person is staffed 100 percent to the project. That is unlikely. In reality, a scarce resource would be scheduled to work on projects concurrently to enable more projects to be active. In practice, you would sequence the projects, rather than start them all at the same time. Projects have differing durations, and this difference frees up resources to be reassigned. In any case, the example has shown you how the process works.

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. The critical chain approach to project management offers considerable detail on scheduling scarce resources across multiple projects. The interested reader should refer back to Chapter 10 of this book, which covers Critical Chain Project Management (CCPM) in more detail, and consult the book Critical Chain Project Management, Second Edition by Lawrence P. Leach (Artech House, 2005).

Balancing Using Partial Funding or Staffing of Projects

Earlier in the chapter, I asked whether partial funding would be allowed. The tentative answer to the question of partial funding or partial staffing is yes, because it yields a couple of key benefits: It puts more projects into active status, and it gives you a better chance to control the risk in the portfolio. If a partially funded project doesn't meet minimum expectations, it can be postponed or canceled and the remaining resources reallocated to other partially funded projects that do meet expectations. There is one major drawback that the portfolio manager must contend with: The delivery date of the partially funded projects will be extended into the next budget cycle. That may mean a delay in getting products or services into the market, thereby delaying the revenue stream. That has obvious business implications that must be taken into account.

MANAGE the 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. 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. The following two come to mind:

• Earned value
• Milestone trend charts

These performance measures are discussed in more detail later in this section.

To bring closure to the final phase, projects can be postponed, canceled, or, believe it or not, completed, and you will see exactly how each of these endings affects the portfolio going forward.

At this point, the project is under way. Regardless of the effort that was expended to put a very precise and complete plan in place, something will happen to thwart those efforts. In the 35 years that I have been managing projects, not a single project went according to plan. That wasn't due to any shortcomings on my part — it is simply a fact of life that unforeseen things will happen that will have an impact on the project. Corrective actions will have to be taken. This section introduces two reporting tools that enable an apples-to-apples comparison of the status of projects in the portfolio. The first tool is applied at the portfolio management level, and the second tool is applied at the project level.

Project Status

As mentioned, there are three categories for the status of active projects: on plan, off plan, or in trouble. The following sections take a look at each of these states and how that status might be determined.

On Plan

Even the best of plans will not result in a project that stays exactly on schedule. A certain amount of variance from the plan is expected and is not indicative of a project in jeopardy. The threshold between on plan and off plan is a subjective call. I offer some guidelines for this variance in the “SPI and CPI Trend Charts” section later in this chapter.

Off Plan

Once a project crosses that threshold value, it moves from on plan to off plan. For a project to be off plan is not unexpected, but getting that project back on plan is expected. If the project manager cannot show the corrective action that will be taken to get the project back on plan and when that event is likely to occur, there is a problem, and the project has now moved to in-trouble status. The project can also move to in-trouble status if it passes a second threshold value that separates off plan from in trouble.

In Trouble

Regardless of the way in which a project reaches the in-trouble condition, the implications are very serious. To be in trouble means that there is little chance the project can be restored. Serious intervention is required, because the problem is out of control and out of the range of the project manager's abilities to correct it. However, just because a project is in trouble doesn't necessarily mean that the project manager is at fault. There may be cases where freak occurrences and random acts of nature have put the project in this category, and the project manager is unable to put a get-well plan in place and is asking for help that goes beyond his or her range of authority. The portfolio manager is considering canceling the project unless there is some compelling reason why that action should not be taken. A new project manager will not necessarily rectify the problem.

The Role of the Project Manager

Obviously, one of the project manager's key responsibilities is the status of the project. While there are many reasons why a project may drift out of plan, it is the responsibility of the project manager to institute corrective measures to restore the project to an on-plan status. The extent to which the project manager meets that responsibility will be obvious from the future status of an off-plan project.

The project manager can also be a cause of an off-plan status. That can happen in a number of ways. In my experience, one of the major contributing factors is the failure of the project manager to have a good system of cross-checking and validating the integrity of the task status being reported by the team. If the project manager does not have a visible process for validating task status, then that is a good indication that scheduling problems are sure to occur.

The second behavioral problem that you see is the failure of the project manager to establish a repeatable and effective communications process. The first place to look for that is in constant questioning from the team members about some aspect of the project that affects their work for which they have little or no knowledge. There should be full disclosure by the project manager to the team. That process begins at planning time and extends through to the closure of the project.

Reporting Portfolio Performance

Two well-known reporting tools can be used to compare the projects across a portfolio and assess the general performance of the portfolio as a whole: earned value and milestone trend charts. Both of these were discussed in detail in Chapter 7, and that discussion is not repeated here. What I will do is take those two reporting tools and show how they can be applied to measuring the performance of the portfolio.

Schedule Performance Index and Cost Performance Index

The schedule performance index (SPI) and cost performance index (CPI) measure earned value as follows:

These two indices are intuitive and provide good yardsticks for comparing the projects in a portfolio. Any value less than 1 is undesirable; any value over 1 is good. These indices are displayed graphically as trends compared against the baseline value of 1.

SPI and CPI Trend Charts

The milestone trend charts introduced in Chapter 7 are adapted here to fit the SPI and CPI trends. This section tracks the SPI and CPI over time using the criteria established in Chapter 7. At the risk of repetition, I want to impress upon you the flexibility and power of the integration of SPI and CPI with the milestone trend charts.

Some examples will help. Consider the milestone trend chart for the hypothetical project shown in Figure 14-16. The trend chart plots the SPI and CPI for a single project at weekly reporting intervals. The heavy horizontal line has the value 1. That is the boundary value for each index. Values above 1 indicate an ahead-of-schedule or under-budget situation for that reporting period. Values below 1 indicate a behind-schedule or over-budget situation for that reporting period. Over time these indices tell an interesting story about how the project is progressing or not progressing.

Figure 14-16: Example SPI and CPI trend chart

Figure 14-16 shows that beginning with Week 5, the schedule for Project ALPHA began to slip. The slight improvement in the budget may be explained by work not being done, and hence the cost of work that was scheduled but not done was not logged to the project. This type of relationship between schedule and cost is not unusual.

Spotting Out-of-Control Situations

Certain patterns signal an out-of-control situation. Some examples of this sort of situation are shown in Figures 14-17 through 14-20 and are described in this section.

Figure 14-17 depicts a project schedule slowly slipping out of control. Each report period shows additional slippage since the last report period. Four such successive occurrences, however minor they may seem, require special corrective action on the part of the project manager.

Figure 14-17: A run up or down of four or more successive SPI or CPI values

Figure 14-18 shows a minor over-budget situation. While this may not be significant by itself, that situation has persisted for the last seven report periods. The portfolio manager can fairly ask the project manager why he or she hasn't corrected the situation. The situation isn't serious, but it should have been fixed by now. There may be extenuating circumstances that occurred in the first few weeks of the project that have persisted without any possibility of correction. The CPI and SPI are fairly stable despite their negative performance.

Figure 14-18: Seven or more successive SPI or CPI values above or below 1

Figure 14-19 shows both the SPI and CPI trending in the same direction. The fact that the trend is negative is very serious. Not only is the schedule slipping, there are consistent cost overruns at the same time. If the situation were reversed and the trend were positive, you would obviously have a much better situation. In that case, not only would the project be ahead of schedule, but it would also be running under budget. Figure 14-20 illustrates that scenario.

Figure 14-19: SPI and CPI trending in the same negative direction

Figure 14-20: SPI and CPI trending in the same positive direction

Whether a project is trending to the good or trending to the bad, a good portfolio manager investigates to find out what has happened.

These same data plots can be used to show how the portfolio is performing with respect to both schedule and cost. Figure 14-21 illustrates the hypothetical data for the BETA Program Portfolio. It consists of five projects that all began at the same time. The solid lines are the SPI values for the five projects over the seven-week reporting period. The heavy dotted line is the portfolio average. Although the portfolio has been behind schedule for the entire seven weeks, it is trending upward and has nearly reached an on-schedule situation. The same type of plot can show budget performance for the portfolio as well.

Figure 14-21: SPI values for a hypothetical portfolio

Closing Projects in the 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. This acceptance criteria usually takes 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 call a post-implementation audit. This section examines the activities and contents of a post-implementation audit and discusses why it is so important that one be done.

Attainment of Explicit Business Value

Each project was proposed based on the value it would return to the enterprise if it were funded and completed successfully. Was that value achieved? This is a question that may not be answerable until some time after the project is complete, but it is a question that deserves an answer. This proposed value was the justification for the project and a major factor in placing the project in the portfolio in the first place.

Lessons Learned

Following are several questions that might be asked about a project just completed:

• Were the project goals and objectives achieved?
• Was the project work done on time?
• Was the client satisfied with the project results?
• Was the explicit business value (as defined in the success criteria) realized?
• What modules were learned about your project management methodology? What worked? What didn't work?
• How well did the team follow the methodology?

All of these questions are important and should be answered. In some cases, the particular nature of the project may render some questions more important than others, but that does not excuse the project team from answering all of them. Some of the most important information about the project management process can be found in these answers, so they should be shared with all other project teams.