Solving the problems caused by project-by-project decision-making requires shifting focus from the project to the project portfolio. Unlike project management, which is concerned with applying knowledge, techniques and tools to help ensure that individual projects succeed, project portfolio management (PPM) is concerned with applying knowledge, techniques and tools to ensure that the entire collection of related projects is as successful as it can be. With PPM, the quality of information and understanding is improved, and the common decision-making errors that reduce the value derived from projects are avoided.
Building an effective project prioritization and portfolio management capability takes effort, but it doesn't have to be an expensive or daunting task. And, it can be done without software. Also as described by Johana Rothman in her book, Manage Your Project Portfolio , you don't even need to wait until your organization adopts PPM to start. Because PPM can be practiced at any level, you can begin experiencing the benefits of PPM by managing as a portfolio the work at your personal level of influence within the organization. The enabling step is to place information about projects into a portfolio.
Create a Portfolio of Projects
Rothman suggests you begin PPM by finding out what people are working on now, and what they expect to be working on over the next few weeks or months, or for whatever time horizon commitments are reasonably knowable. The scope should include business initiatives, discretionary spending, and work viewed as mandatory, including compliance, and contractual obligations. Focus on project work; that is, unique undertakings that have specified deliverables and projected start and termination dates. Determine who, what and when —who is doing or will be doing the work, what the project is, and over what time period the work is expected to proceed.
The work being undertaken will include large and small projects that result in specific, valuable deliverables that by themselves would be useful. There may also be chunks of work that are essential to achieving some larger deliverable, but that have limited utility by themselves. Any piece of work that has a deliverable that by itself is valuable, whether large or small, should be regarded for the purposes of the portfolio as a project. If there are collections or series of small pieces of work that individually don't add up to significant value, but do together create value, combine them into a single project.
Once you've identified all ongoing and planned work, organize the work into a portfolio. The most common format for displaying the project portfolio is a matrix where projects are listed in rows with information about the projects arrayed in columns. Figure 9 provides an example.
Figure 9: A project portfolio.
The project portfolio shows the project inventory. It provides a birds-eye view of work requested and performed. Having this information in one spot and tagged with key information helps you, the team, and executives to better understand and assess what the organization is doing.
Explore Resource Demands and Scheduling
If project timing and resource demands are added to the matrix, the portfolio display becomes a useful device for supporting sourcing and scheduling decisions. Sourcing defines how we secure and allocate resources, while scheduling determines when we allocate those resources based on needs and planned availability.
The usual approach is to add columns to the project matrix indicating units of time moving left to right. The columns could represent weeks and/or months, whatever is most useful depending on the duration of projects and nature of the staffing commitments. You can do this in an Excel spreadsheet (see the next section), or you can start without any sort of formal tool. For example, Rothman  recommends creating the initial project schedule as a group exercise, by drawing a template on a whiteboard and having participants write project information onto sticky notes. Projects that extend over multiple time periods can have a sticky for each period. Participants then post the stickies onto the appropriate locations on the template, producing a result something like that shown in Figure 10. As illustrated, you can arrange the projects such that any unstaffed projects are placed at the bottom of the list.
Figure 10: A rolling project portfolio.
This view of the portfolio shows the pipeline of upcoming project work. This sample portfolio provides weekly detail for the next four weeks and a high-level perspective for another three months. It identifies unstaffed projects, making it easy to spot projects that are at risk for being delayed due to constraints on people's time.
Figures 9 and 10 represent only one of a number of possible ways of displaying projects, people, and timing. They show a high-level view of what people are working on and expect to be working on while highlighting those projects that still require staffing. Such high-level views are most useful for conveying a big-picture understanding. They help participants understand how work will progress and aid management of the interaction among projects. A big picture view helps reveal patterns and provides a sense of the project collection as a whole.
Another common way of displaying the portfolio shows the details about who is doing what and when. Figure 11 provides a low-level view of a portfolio, where you can see who is assigned to which projects and, in this case, the phases of the projects.
Figure 11: A more detailed view of the project portfolio.
Low-level portfolio views can be useful for highlighting work that cannot start until specific people finish what they are already doing. A portfolio view that shows all the demands on project personnel helps staff from becoming over committed. A manager may want someone to work on another activity, but if the portfolio makes it clear that the individual is already 100% committed, it is readily apparent that work on other projects will slow if the person takes on another demand.
A high-level view of your portfolio gives you a feel for all the projects you have underway, while a low-level view shows you more of the details but less of the overall pattern. Both views can be useful for tweaking sourcing and scheduling choices. The delta between total available resources and what's in use at any given time represents available resources to assign to new initiatives. Non-discretionary projects can be staffed first, with resources for discretionary projects scheduled during the timeframes in which they occur and necessary resources become available. If resources are insufficient to serve every project, projects may be prioritized to ensure the best use of limited resources.
As explained previously, it is common for organizations to propose and then try to do too many projects. Available resources are insufficient to allow all desired projects to be undertaken, and it may not be possible to start important new projects unless some existing projects are killed or placed on hold. What really makes the project portfolio useful is that it can serve as an aid for making project decisions. The key, as suggested in Figure 12, is to prioritize projects in the portfolio.
Figure 12: A prioritized project portfolio supports project decisions.
New projects will compete for resources with existing, ongoing projects, so you should work with a portfolio that includes ongoing projects together with newly proposed projects. The complete project portfolio should consist of ongoing staffed projects, projects that have been approved but not yet staffed, and new projects that are under consideration but not yet approved. Even if you don't want to consider killing or slowing ongoing work, you need to account for all project demands on organizational resources
The Project Ranking Theorem
The goal is to select the portfolio of projects that collectively will contribute the most value. As explained in the paper on mathematical theory, this means that you should rank projects based on value created per unit of cost ("bang-for-the-buck"), with cost being the total cost of the project (all costs yet to be paid), including labor costs.
Be aware that many authors incorrectly advise you to rank projects based on project value alone. For example, the number one webpage from a Google search on "methods for ranking projects" advices "ranking by point...assigning more points to more valuable projects"  There is no mention of the need to divide the project value estimate by cost prior to ranking. As shown by Figure 13, unless every project has the same cost, this common error produces a project portfolio that is far from optimal.
Figure 13: Prioritizing by value rather than by the ratio of value to cost selects the wrong projects.
The figure compares the value delivered by projects as a function of total cost depending on whether projects are prioritized based on the ratio of value to cost or based on project value alone. Each rectangle represents a candidate project. The width of the project rectangle indicates project cost and the height indicates project value. When projects are ordered by the ratio of value to cost, higher portfolio value is obtained for the available budget. As shown, ranking projects by value alone results in a large loss in total portfolio value, especially if the costs of projects differ significantly and the budget is highly constrained. It may at first seem counterintuitive that a low-value project could rank higher than a high-value project. Smaller projects will naturally tend to generate less-impressive, less-valuable outcomes, but if a project consumes a relatively small portion of the scarce resources, it could contribute sufficient bang-for-the-buck to warrant including it in the list of approved projects. Thus, the correct consideration for ranking projects is the worth of the project outcomes relative to the project costs. Ranking based on estimates of project value alone gives the wrong result.
Manually Ranking Projects
Part 3 of this paper explains how to construct models and tools for prioritizing projects. If you don't have such a tool, you can prioritize projects manually using forced ranking—force the projects into a strict priority order based on your judgments regarding value delivered for the cost spent. Can this be done? Since estimating the value of a project relative to its costs is difficult, you may question whether projects could be ranked in this way. In my experience, though, people can and do successfully rank projects. Think about projects with which you are familiar. Regardless of your level within your organization, you will almost certainly be able to separate the best projects from the mediocre. If you are a first-level manager, you have intimate knowledge of your projects and the deliverables they will create. So, you'll have some idea of the relative importance of your projects. If you are a middle manager, you'll have a feel for how the projects being conducted by your project managers relate to the various business needs being addressed and the relative importance and urgency of those needs. If you're a senior manager, you'll have an understanding of your organization's strategic direction and have a sense for how the various projects contribute to organizational success. Thus, so long as you have understanding of projects and what they are intended to accomplish, you have a basis for judging project value. You can then compare your assessment of the value of each project with its cost, and reach a judgment regarding the effectiveness with which it utilizes scarce resources. By such reasoning you can assign rough priorities to projects and, thereby, rank them.
Figure 14: A prioritized project portfolio.
Publish your priority list so that everyone will know in what order you will choose to allocate resources. The prioritized list lets everyone know what work is viewed most useful. They'll see what's in the pipeline and understand the tradeoffs that would be necessary to accommodate changes in priorities.
Involve Stakeholders in Project Ranking
Even though you could specify priorities on your own, without discussion, it is far better to get help from others. Ranking projects is best done as a group exercise. If you do it yourself, you'll likely be wrong about something. If you collaborate with your peers, you'll benefit from their knowledge about the projects, and it will be easier to make choices from the perspective of what's good for the business as a whole. Even if you are the CEO, you should involve your senior management. This has the added advantage of allowing others to understand why you rank projects the way you do.
If there are lots of projects, group ranking can take a while. One way to speed a collaborative ranking is to bring in a draft ranking that you've developed on your own. It will allow other people to see what you are thinking and why you think certain projects delver more bang-for-the-buck than others. Just don't become too attached to your draft; engage others in discussing it and change it if what they think makes sense to you. The first time you try group ranking, it will be difficult for people to reach consensus, but as participants learn to work together, and project work is moving through the pipeline toward completion, the process will become quicker and easier. For additional methods to facilitate the judgmental ranking of projects, see the subsection below entitled Improve the Prioritization Process. The use of models to prioritize projects is discussed in Part 3 of this paper.
Decide whether to Accept, Kill, Postpone, or Revamp Projects
The proper logic for choosing projects based on a priority list, assuming the projects are defined in such a way that they are independent of one another and that they are ranked based on the ratio of value to cost, is to select them from top down until you've exhausted the available project budget. Projects higher on the list make the cut, lower projects don't. In practice, though, deciding what to do with each project is more complicated than that. There may be multiple constraints limiting the projects that you can do at any one time (e.g., people with skill sets that are in high demand). Thus, you will likely need to stagger high-priority projects or adjust schedules to accommodate resource availability. Also, urgency (How soon do you need the project deliverables?) may be relevant for determining the sequence for doing projects.
Despite these complexities, having a correctly prioritized project list will aid the decision of what actions to take with regard to each project in the portfolio. Typically, you'll want to staff the highest priority projects first. If certain resource constraints mean that some projects making the budget cut can't be undertaken, consideration can be given to acquiring additional resources through hiring, consulting organizations, or staff augmentation firms. If easing critical resource constraints isn't feasible, then you made need to postpone some lower-priority, resource intensive, and less urgent projects into the next budget cycle. In that case, and if the budget can accommodate them, a few less resource-intensive projects close to the budget line might then be conducted in place of the projects that because of specific resource constraints need to be delayed.
The available options for each project are, in general, accept, kill, postpone, and revamp. If the project is ranked very high in priority, the appropriate decision is likely to be to commit to doing it. Committing to a project means a commitment to funding the project and assigning the necessary people plus whatever other resources (e.g., space, capital equipment, desks, etc) are required for the effort. A commitment to a project cannot be a partial commitment. If you can't fully commit the necessary people and money, you are guaranteeing the project will not provide the value assumed when it was assigned high priority. On the other hand, a commitment to a project is not a permanent guarantee the resources will continue to be provided through the entire life of the project. If the need for the project goes away, the project turns out to be more expensive to conduct, or it becomes apparent that the anticipated value simply won't materialize, the usually approved, ongoing project may need to be terminated at some point in the future.
Another option is to kill the project. Killing a proposed project means rejecting the project proposal. A project that has already started may need to be killed if the current, best estimate of the value of the completed project is small compared to the remaining, yet-to-be-paid, project costs. Before terminating an ongoing project, consideration should be given to whether project risks and/or cost escalation can be managed by reorganizing, creating work-arounds, or redoing the work. Note that killing an ongoing project can produce project termination costs (e.g., contract termination costs), so avoiding those costs is a component of the value of continuing the project. Thus, the priority assigned to completing an ongoing project is the current, best-estimate of the value of the project deliverables, plus any avoided project termination costs, divided by the remaining project costs. Since the remaining costs decline as the project progresses, the ratio of value to cost for projects generally increases as the project proceeds. For this reason, unless there is a major decline in estimated project value or escalation in project costs, the priority for completing ongoing projects increases over time.
A third option for the project is to place it on hold. A project may be attractive, yet not have sufficient priority to make the cutoff. Such projects can be deferred for consideration again in a later decision cycle. If in that later cycle budget constraints become less severe or if competing projects are less attractive, the deferred project may appear relatively more attractive and, therefore, be initiated.
A last option is to transform or revamp the project. If a project isn't assigned sufficient priority to make the cut, it may be possible to change the project in such as way as to decrease its cost while increasing its delivered value. Transforming a project can be as small as clearing up misconceptions about the project, or as drastic as replacing the project team or changing the project design and goals. When projects are prioritized based on comparing project value with cost, project proponents know what they must do if they are to obtain positive funding decisions.
The Portfolio is a Means, Not an End
A project portfolio is not a static document. As you discover additional work, add it to the portfolio. As things change, reprioritize the projects. A prioritized portfolio helps people to see which projects to spend time on now and what they might do in the future. Most important, people know where not to spend their time. It can serve as a visual tool that helps you negotiate which projects to do when. The managers use the portfolio to make sure the organization is working on what's most important—work that will create the most value for the organization.
Looking at projects from the perspective of the portfolio makes projects look less like discrete efforts and more like a connected suite. Information and understanding is improved. Interdependencies among projects can be noted. New requirements can be evaluated against current commitments. Portfolio analysis allows investigating questions like, "How are resources for Project A impacted if Project B is delayed?" The portfolio extends the focus beyond individual project management and highlights objectives and goals that serve value creation.
As shown here, even if you don't have buy-in or support from above, you can benefit from creating and managing a project portfolio for the work that you or your team is responsible for doing. It will provide support and stability your team needs. Your portfolio will help you answer your managers' questions more quickly and completely—even if they don't yet buy into the notion of a portfolio. It will help you make the best decisions in your sphere of influence.
The next section describes how software magnifies the benefits of project portfolio management.