Chapter 13

Program, Portfolio, and Enterprise Risk Management

“There are risks and costs to a program of action.
But they are far less than the long-range risks
and costs of comfortable inaction.”—JOHN F. KENNEDY

The future, for any organization, requires action and entails risk. The subject of this book, project risk management, is a useful starting point for managing risk, but it will rarely be sufficient. Projects are always part of something larger. Programs are made up of projects, so program risk management relies on project risk management, among other things. Project portfolios are made up of projects and may also include programs, so portfolio risk management also depends on project risk management. Enterprise risk management includes all of these types of risk management, along with additional considerations. This chapter explores the relationship of project risk management to each of these higher-level perspectives.

Project Risk Management in Context

Project success or failure is generally measured against the triple constraint of scope, time, and cost, and the risks listed in the PERIL database reflect these categories. The success of programs and portfolios, not to mention the health of the enterprise as a whole, depends on successful projects—those that meet the objectives that they commit to. However, at each level above the project, the connection with project risk management becomes more abstract. The focus shifts, and these managers are not necessarily measured and evaluated based on the fate of any particular single project. Risk management in these other arenas goes beyond the concerns that keep project leaders awake at night.

The Focus of Program Risk Management

“Program” is a term that means different things in different contexts, but the Project Management Institute defines a program as “a group of related projects managed in a coordinated way.” This chapter explores this type of program, where the main objective for program management is better overall control of interconnected projects than would be possible if they were managed autonomously. Programs include projects that are executed in parallel, in sequence, or both. Projects are time limited, with a specific start and finish. Programs may also have deadlines, but some are open ended—only the component projects have well-defined closure objectives. Programs may contain a few projects, hundreds of projects, or any number in between.

Program risk management closely resembles project risk management. For small programs, there may be no difference at all. Risk management for the program can be little more than aggregation of the risk plans and strategies for the included projects. For larger programs, however, there is an increasing focus on the successful delivery of benefits and value, which may require risk trade-offs among the constituent projects.

The Focus of Portfolio Risk Management

When projects are aggregated into portfolios, the overall focus shifts even further from the results of a particular project or program. Portfolios, whether made up of stocks, junk bonds, subprime mortgages, or projects, are primarily focused on delivering an expected return. For portfolios of projects, risk in the aggregate depends more on the average project performance than on the success or failure of each particular project.

The Focus of Enterprise Risk Management

In the abstract, an enterprise can be thought of as a bundle of projects and other activities that increases in value over time though successful execution of those undertakings. Ideally the appreciation in value will be more attractive to the investors and owners than alternatives such as stuffing money into mattresses. From this perspective, enterprise risk management is little different from portfolio risk management, and again the main objectives tend to be financial. At the enterprise level, though, there are other risks that must be managed. Some relate to the survival and ongoing health of the organization. Laws and regulations must be obeyed, and principles need to be established and followed to ensure the trust of owners, customers, employees, and others in the future. In addition, corporate officers of public corporations in the United States and elsewhere are now faced with significant new personal penalties and potential legal prosecution. The relationship between enterprise risk management and project risk management is bidirectional. The financial success and overall well-being of an enterprise depends on effective project risk management, especially for large and high-visibility projects. In addition, enterprise risk management, particularly since 2000, has been a particularly fertile source of projects.

Program Risk Management

The line between project and program management is not exactly precise. An endeavor with ten people that delivers a result in six months is a project, and an undertaking with hundreds of people working globally in a dozen independently managed teams to deliver periodic deployments over the course of five years is a program. Between these extremes, you will find both very large projects and modest programs, and the difference between the two can be fuzzy. From the perspective of risk, though, program risk management depends heavily on the project risk management principles outlined in the earlier chapters of this book, with a few added considerations.

The main purpose of program management is dealing effectively with the potentially overwhelming detail; work that entails thousands of activities and large numbers of contributors is unwieldy to plan, and it’s impossible to monitor as a single effort. Program managers have daunting responsibilities. They are accountable for the overall program objective, managing the efforts of the individual project leaders, and often a dedicated program staff or a program office as well. Breaking large undertakings into chunks of work that can be effectively delegated and managed as (largely) independent projects is done for the same reason that projects are decomposed using a work breakdown structure—it reduces the complexity by converting the large and complicated into parts that are easier to deal with. Managing risks at the program level begins with ensuring adequate planning and risk management at the component project level. Although doing this is an effective start on program risk management, it is insufficient.

It is never possible to break up a large piece of work into a set of totally disconnected pieces; interrelationships remain that represent program-level risks. At a minimum, program scope connects the included projects, along with the overall business justification for the work. From a scheduling perspective, there are always cross dependencies connecting the projects within the program. None of the interconnections is entirely contained within any of the component projects, so they need to be tracked and managed at the program level. These program interconnections showed up in the PERIL database both as scope defect risks due to integration issues and as schedule dependency risks arising from project timing difficulties. Also, because programs are generally bigger and often longer than projects, they represent larger risk because of their scale.

For all these reasons, programs usually have a risk profile that exceeds the sum of their parts. A collection of modest-risk component projects may well aggregate into a high-risk program because of positive probability correlations for project risks in the interconnected projects. There are also cascade effects. When a risk occurs in one project, it can trigger additional problems in several other projects—quickly spinning things out of control. Managing project risks is necessary but program risk management requires additional work.

Planning Program Risk Management

Chapter 2 discussed the topic of planning for project risk management, observing that for small undertakings informal risk planning is generally sufficient. For a program, informal planning is not good enough. Formal program risk planning is a part of program initiation. To get started, map out how much effort this will require and verify support for the work with your program sponsor (and with your other stakeholders, as appropriate). Program risk management is often integrated with other ongoing responsibilities of the program staff, but if you plan to use a separate staff with a separate budget, secure approvals and funding for this. For the program, document:

• The risk tolerance of your sponsor and key stakeholders

• The owner for program risk management (if not the program leader) and other program staff who will participate, with their roles

• The process you will use for program risk management, including the format for the program risk register

• The planned frequency for program risk reviews

• The location where program risk information will be stored and how you will track and communicate program risks

• Any metrics to be used in monitoring program risks

As an example, for several years I was responsible for planning and risk management for a large program that started at Hewlett-Packard in 2002. This program was responsible for consolidating global oversight for all current fee-for-service projects under a single, consistent set of processes and information technology applications. The program had direct responsibility for a budget of several million dollars per year and had a shifting roster of about 200 contributors working on more than a dozen project teams that were either geographically based or responsible for delivery of key functions. The program implemented roughly four countries per quarter, and by 2006 the system was in operation in more than fifty countries worldwide.

Risk management was an important success factor for the program. The processes used for this were well defined and documented. I used them throughout the program to conduct monthly program risk reviews with the rest of the program staff. In our meetings, we reviewed the risks already listed in the program risk register, retired any that were no longer of concern, and added new risks based on evolving program plans and external changes. During each meeting we reprioritized the significant risks and then outlined risk prevention strategies. Where necessary, we also developed contingency plans for recovery. Following each monthly meeting, I distributed the updated risk register to the project leaders, and I made the current version available to everyone working on the program on the program’s Web-based knowledge management system. By periodically considering the risks and keeping them visible, we avoided quite a few problems and kept the program on track.

Identifying Program Risks

Program risk identification begins with planning each component project and identifying the risks at that level. Across the entire program there may be hundreds or even thousands of identified risks. Nonetheless, the program risk manager should review all of them and provide feedback on the analysis and response strategies, especially where the assessments appear inconsistent or flawed.

Generally, project-level risks are best managed at the project level. However, you do want to add any project-level risks to the program risk register that are:

• Significant enough to be program “showstoppers”

• Associated with technical complexity (architecture, systems engineering, and the like) that could result in integration problems or defects

• Potential conflicts involving individuals or other resources needed by two or more of the projects

• Related to cross-project dependencies

In addition to these risks, you should list program exposures that relate to the overall scale and staffing, especially if project teams are geographically distributed or managed through outsourcing. Also consider risks related to turnover, queuing for key program resources, program communications, and ongoing motivation (particularly for long duration programs).

Build a program risk register similar to that used at the project level, adding program-level risks as appropriate through brainstorming, review of lessons learned from earlier similar programs, and scenario analysis. The risk register for the HP program discussed earlier in this section started with about twenty-five items and averaged roughly thirty throughout the program. (Risks that were managed at the project level were typically about an order of magnitude more numerous.)

Assessing Program Risks

Program risk assessment does not really depart much from the principles of project risk assessment described in Chapter 7. Use qualitative assessment methods based on categories to prioritize program risks. For significant risks, use quantitative analysis to refine your understanding and drive response strategies. Because the information for risk may come from remote or second-hand sources, be especially wary of data-quality issues and skeptical about impact and probability estimates that seem excessively optimistic. If risk consequences are expected to be within a wide range, be conservative and use the worst case for your assessment. For probability, probe connections between the risks, and increase probability assessments for related risks.

Sort the risk list and select the most significant ones, focusing on:

• Interdependencies and interfaces between projects

• Complexity and potential deliverable defects

• Staffing difficulties, motivation issues, and funding commitments

Responses for Program Risks and Interface Management

As with assessment, program risk responses primarily depend on tactics similar to those effective for project risks. For each selected program risk, consider options for avoidance, mitigation, or transfer. If you can find no appropriate response for any of the significant risks, develop contingency plans for recovery. Ensure that the individual project plans include the specifics necessary for managing the important risks, and determine how you plan to monitor for key risk triggers at the program level.

Cross-project dependencies, or interfaces, are one of the biggest sources of program-level risk. An effective process for dealing with these connections is central to managing these interconnections. Although project interdependencies may be identified during basic project planning, it is the program manager who is ultimately responsible for managing these relationships and their related risks. Initial planning for these predecessor/successor relationships is done at the project level; managing them may require trade-offs and decisions that cannot be made by individual project leaders. Even when interfaces appear to be under control at the project level, each still represents potentially significant program risk to be managed.

Responding to these risks involves reliable, well-documented cross-project commitments. The relationship depicted in Figure 13-1 shows a typical interface. Each interface is partly within a project contained in the program, but it is also partly in “no man’s land” where neither of the involved projects has full control.

The terminology of suppliers and customers is useful in analyzing program interconnections. The interface linkages initiate in the supplier project, and they terminate in the customer project.

Within a program, external predecessor dependencies are inevitable, so they will surface as part of project schedule development, as discussed in Chapter 4. Managing these interfaces begins with the planning for the customer project. Each external input for a “customer” project is a risk both for that project and for the program. Project planning processes will also uncover external successor dependencies, where the projects supply deliverables as outputs to other projects within the program.

Figure 13-1. Program interface connecting two related projects.

Once identified, each interface in the program needs a formal written description—documenting all the inputs and outputs identified by the connected projects. At the program level, each input must be sorted out and matched with an equal and opposite output. Program interface management requires that all identified interfaces be resolved and support the overall program plan. To begin the process, the project leader of the customer project documents all inputs required, listing specifications and requested timing. Ideally, each documented input is quickly associated with an output planned by a supplier project, and there is quick agreement by the corresponding project leader to supply it. When there are no issues with requirements or timing, the two project leaders formally agree on the terms of the interface, treating it as a binding contractual commitment.

For many situations, though, it won’t be that simple. There may be required inputs for which there are no planned outputs. For some of these, additional planning by a plausible supplier project may be needed to ensure that the need is met. For others, a change of scope may be necessary, or the customer project may need to plan to meet the need internally. Even when the inputs and outputs align there may be issues. When there are differences between the input specifications needed and the output specifications planned, the program manager may need to participate in negotiations between the project leaders and guide the process to a resolution that serves the program.

Interface timing issues also are common, where inputs are needed earlier than the corresponding outputs are planned. This situation resulted in an average of seven weeks of slip in the PERIL database, one of the largest types of schedule risk and representing an abnormally large number of “black swan” risks. Significant program timing exposure results from these problems, due to the sort of project schedule gaps shown in Figure 13-2. The program manager must coordinate reconciliation and work to resolve these conflicts.

If there are identified program outputs that are unclaimed, it may reveal a planning gap in one or more projects. For necessary outputs, the program manager must locate the project that has corresponding missing inputs and work with the project leader to integrate them into the plans. Some identified outputs may prove to be unnecessary, in which case the program manager will work with the leader of the supplier project to eliminate them, along with their related activities.

All interfaces should be visible at the program level, formally documented, and agreed to in writing by each of the customer and supplier project leaders. Even when interfaces are thoroughly planned and managed, they remain program risks and belong on the program risk register, usually close to the top.

Figure 13-2. Interface timing connections within a program.

The process for managing interfaces also helps with another common source of program risk. Programs regularly get into difficulty because they are quickly chopped up into projects, with little consideration of the project cross-connections that will result. The more autonomous each project is, the easier it will be for the project leader to manage. It also means fewer “white space” issues for the program manager to deal with. Integration problems, a substantial source of scope defect risk in the PERIL database, are often the result of excessive organizational complexity for the program. If there are ten projects in a program and 150 interfaces, there is almost certainly a less complicated decomposition of the program into projects where more of the dependencies lie wholly within the component projects. Excessive interfaces connecting project teams, particularly geographically distributed teams, leads to more program failure modes and higher risk. As project plans evolve and are integrated within the program, monitor the number of interfaces and keep your eyes open for a more straightforward program breakdown.

As with risks in projects, visibility is a powerful program risk mitigation strategy. When the consequences of program risks are apparent, people work to avoid them. Even when risks do occur, response to the ones that people are aware of is faster, minimizing the impact.

One final differentiator for risk response planning at the program level is the need to have an effective and well-established process for rapid escalation for when a significant risk occurs. Quick response also depends on a pre-established program-level budget reserve for use in dealing with contingencies. Where possible, also set up adequate program-level schedule reserve to protect your schedule.

Monitoring and Controlling Program Risks

Because risks at the program level are larger and generally more distant and they tend to become major disasters quickly, disciplined monitoring is essential. Frequent effective communication is central to this, and it’s one of the main responsibilities of the program manager and staff.

For the Hewlett-Packard IT program mentioned earlier, our monthly risk management review meetings were a large part of our communication and risk monitoring. We also discussed major risks regularly at our weekly program staff meetings, and scheduled time during our semi-annual face-to-face program review meetings to plan for risks in the next phases of work with a larger than normal number of participants. In addition, we made discussion of important upcoming risks part of our monthly “all hands” conference calls. These were “virtual” program team meetings where the program leadership team presented current program status. All of the presentation materials to be discussed on these calls were distributed in advance to the roughly 200 program contributors, and the information was also archived on the program Web site for review by those who missed the calls.

The size of the program risk register changed over time. Although it did not drop significantly, the list of program risks we were managing also did not expand, as seen in Figure 13-3. The overall severity profile of our managed risks also remained stable over time.

Program control and effective risk management also depends on strict control of changes. For large, complex programs, any change, regardless of how innocent it appears, can create a major problem. Complexity also requires a hard limit on how late changes can be made; when changes are attempted too late they often are not successful in test and need to be backed out at the last minute. This creates unnecessary work both to attempt the change and then to remove it, effort that could have been applied productively elsewhere in the program and may have been effective in avoiding serious risks.

Figure 13-3. Program risks over time, categorized by severity.

Another control strategy for programs is ongoing commitment to process review and improvement. Doing a “lessons learned” session after a project is complete is useful, but for lengthy programs there are frequent opportunities to find and deal with recurring program problems.

Particularly for lengthy programs, decreasing interest and motivation can be a big risk. Work to keep people engaged by periodic program reviews, frequent implementations and delivery of incremental value, training, and opportunities for advancement (or at least movement into new responsibilities).

Finally, programs with large numbers of contributors rarely achieve the status of a “high-performing” team, because there are just too many people involved for the necessary interpersonal connections to develop. Large programs can, however, build a high-performing program staff or program office team among the smaller number of people who are responsible for planning and managing the work over the long haul.

When I look back on the HP IT program discussed here, our biggest success factor was the investment we made, early and often, in building strong relationships and trust among the program staff. As a group, we all placed the needs of the program well above the specific details of our individual roles. There were never issues of coverage when people were absent from the program. Each individual had broad knowledge of the overall program and could fill in during times of stress (which were frequent). It mattered little what our formal roles were; we all pitched in and got things done. The atmosphere of “one for all and all for one” was our most effective tactic for managing risk and ensuring a successful program.

Portfolio Risk Management

As you move up the food chain in an organization, risk management moves from the “micro” to the “macro,” as discussed in Chapter 1. Where project and program risk management focus on the specific, portfolio risk management focuses more on the aggregate. The details continue to matter, though, because one important objective of portfolio risk management is selecting projects and programs that have risks that are independent. When the risks in population of items offset, the overall risk—the expected variability of the combined outcomes—falls. Portfolio risk management tends to focus primarily on financial returns, and selecting the right mix of projects can substantially lower the variability.

Portfolio Risks: Specific and Overall

Portfolio risk management does not exclusively focus on the aggregate; obtaining the best overall return also requires working to achieve good results in each of the projects and programs that make up the portfolio. Managing projects well depends on the techniques outlined throughout this book. People responsible for managing portfolio risk tend to delegate the risk management for a particular project (or program—for the purposes of this section, the term “project” includes programs) along with all the other management responsibilities.

Managing overall portfolio risk starts with the understanding that there can be safety in numbers. Ideally, if enough projects are in plan and the organization is reasonably competent at managing the work, the few projects that fail will be offset by the small number that achieve success beyond their objectives. The theory of large numbers takes over, and the details become less important. The performance of such a portfolio is equivalent to that of the “average project.” Portfolio risk management primarily depends on this.

Some projects in the project portfolio may be exceptions to the idea that only averages matter, though. These are the projects that could fail with severe consequences to the organization beyond the merely financial. Because this level of exposure could threaten the organization as a whole, managing these risks goes beyond the topic of portfolio risk management. This type of enterprise risk management will be explored in the final section of this chapter.

Planning Portfolio Risk Management

Project portfolio management is primarily concerned with categorizing, prioritizing, and selecting projects. Best-in-class organizations have a well-documented plan for portfolio management, including a strategy for ongoing portfolio process assessment and improvement. Some organizations make portfolio decisions annually and some do it more frequently, but the process is generally periodic, not continuous. During the times when decisions are being made, managing portfolio risk requires a good deal of interaction with project management processes.

Planning for portfolio management begins with a number of project management factors, including the target mix of projects by type for the organization. The portfolio selection and decision criteria also rely heavily on project risk management and planning data that will be used to assess and prioritize each project opportunity. The overall relationship between an effective portfolio management process and project management is depicted in Figure 13-4.

Figure 13-4. Portfolio and project management linkages.

The project portfolio management process relies on feedback from projects at several stages. The list of projects to be considered for the portfolio feeds into project initiation activities, and it depends on information obtained from them. The portfolio selection process relies on project data developed in planning, especially estimates for cost, duration, and risk. As projects execute, their status provides feedback for midcourse portfolio corrections, and it also feeds into the next portfolio decision cycle.

At all stages, project risk analysis is central to a robust portfolio management process. Deciding which projects to initiate (or to continue) relies on project risk assessments to ensure that exposures are within the organization’s risk tolerances. For a start-up company there will be a high tolerance for risky projects, so the portfolio process will permit projects with considerable uncertainty. In contrast, organizations that provide custom solutions for fixed fees will tend to exclude risky projects, to protect their reputation and to avoid financial penalties. Risk information is essential to avoiding inappropriate projects.

For all these reasons, project risk data should always be a key input for portfolio selection decisions. Because these decisions are often made well in advance of any detailed planning, it is a good idea to revisit the portfolio decisions as projects develop realistic plans and can provide better data.

Planning for portfolio management also requires setting decision criteria. Because the primary performance measurement for most portfolios is financial return, some version of return on investment (ROI) estimate is inevitably at or near the top of the list of criteria. Because all types of ROI assessment depend on two estimates—the cost of a project and the worth of a project—accurate data for both is desirable. As discussed in Chapter 9, precision for ROI can be poor; premature estimates of cost are generally unrealistically low and initial estimates of value can be ridiculously optimistic. Using unreliable ROI estimates increases portfolio risk.

Other criteria derived from project management include overall effort, the project risk profile (often based on a survey, such as a shortened version of the example in Chapter 9), information based on planning, and other input collected from the project teams. Portfolio decision criteria also include data unrelated to project management, such as alignment with stated business goals and strategies, assessment of markets and potential competition, and availability of needed expertise. Selecting appropriate criteria and clearly defining how each will be evaluated contributes to minimizing portfolio risk.

Once listed, each criteria needs a weight. How the criteria are weighted also affects portfolio risk, so ensure that sufficient importance is given to risk assessment and credible project information.

Not all decision criteria are created equal. Some project selection criteria tend to bypass the portfolio process altogether. One example is a project’s ability to keep you out of jail. Projects undertaken to meet industry standards or regulatory, environmental, or legal requirements generally do not require portfolio analysis; such projects are selected and funded without much debate. In your process planning, though, limit the projects that can be automatically fast-tracked into plan to those that are legitimately mandatory. Bypassing the process to accept the “pet projects” of executive decision makers without adequate analysis entails a lot of risk. Although saying “no” to such project proposals can be also risky, if you can turn them down based on objective analysis it’s better for the organization, the project team, and, ultimately, even for the sponsor.

Another key consideration for portfolio planning is the mix of projects. In any organization, options vary from mundane, incremental projects to high-risk efforts that may well be impossible. Typical project category types include:

• New basic research and development

• Revolutionary products, processes, or new markets

• Next generation/new platform to replace an old offering

• Evolutionary improvements to an existing product or service

• Maintenance, support, or infrastructure

Viewed from the perspective of financial return, the highest-potential projects are usually found on the bleeding-edge end of the spectrum. If you seek to minimize risk, however, the most desirable projects are found on the end of the list with the more routine projects. For a given set of decision criteria, projects in a rank-ordered list will tend to cluster based on their category. This may result in a portfolio that is skewed, composed mostly of only one type of project. Because the balance of projects also matters, it is useful to define a target mix of project types that best supports the organizational strategy, with percentages for each project category.

These relative proportions will vary over time and from organization to organization, but the target mix should consistently reflect current tactical and strategic plans. The mix should also reflect a balance between projects that achieve results in the short term and longer-range projects that will best serve the organization’s future needs. Managing this requires ongoing discipline. It is all too easy for a portfolio to become overloaded with projects of a given type—for example, too many maintenance projects or an unhealthy number of projects dependent on speculative technology. When the project load deviates from the overall business objectives, it increases business risk for the organization as a whole. Define a portfolio process that strives for a focused portfolio of good projects with risk and benefit profiles consistent with business objectives.

Identifying Portfolio Risks

Project portfolio risk identification relies heavily on the project risk identification processes described in the first half of this book.

For projects that are still embryonic, detailed analysis may not be available. In these cases, at least develop a sense of potential risks by reviewing problems encountered on earlier, similar projects. Brainstorming and scenario analysis involving people with subject matter expertise is also effective, and provides a starting point for subsequent more detailed planning and risk management.

Assessing Portfolio Risks

Although the focus of project risk management is on “loss times likelihood” for an individual project, assessment for a portfolio involves risk in aggregate. Portfolio risk assessment involves both analysis of which projects to include and exclude and an understanding of how the individual projects relate to each other.

Because most organizations always have many more promising project concepts than can be staffed and successfully executed, project portfolio management is a winnowing process. Determining how far down you can go in a sorted list of project opportunities begins with a realistic appraisal of capability. Determining overall capacity available for projects appears to be surprisingly difficult; most organizations have an exaggerated notion of how much they can accomplish. They also make matters worse by failing to account for commitments that must be staffed for support, maintenance, operations, production, and other ongoing required activities. It’s not uncommon in high-tech organizations to initiate double or even triple the number of projects that can realistically be staffed. Skepticism is warranted when reviewing available capacity; the “too many projects” problem is a common and systemic portfolio risk.

The next step in the assessment process involves collecting and evaluating information on the predefined decision criteria applied to each project. As discussed earlier, relying too heavily on just estimates of ROI is problematic. Sorting a list of projects based primarily on ROI is not necessarily much better than arranging it randomly. In fact, it might even be worse, because portfolio analysis contrasts existing, ongoing projects with new project proposals. Both the cost and the value data about current projects are likely to be at least somewhat realistic, putting them at a decided disadvantage against the speculative estimates for the alternatives using data based on optimistic guesswork. Similar standards need to apply for all projects, with clear-eyed examination of potential return. New projects often appear to be straightforward, low risk, and high return prior to any detailed planning. Failure to account for this bias can lead to portfolio thrash, in which projects are regularly replaced in the portfolio by “better” opportunities, and many projects never complete.

ROI assessment for projects should also consider uncertainty. For each project, estimate the upside potential for gain (often this is equivalent to the overall ROI assessment for new projects, since it’s not likely anyone has considered things that might go wrong). Also probe to realistically understand the downside potential for loss for each opportunity. Be skeptical of sales, value, profit, or other benefits assessments, especially those with suspiciously round numbers. Ask about the assumptions used to estimate the benefits, and find out how they were made. Inquire about threats, competition, or other factors that could invalidate the estimates. If there is a wide potential range, make it visible.

Ensure that decision criteria related to risk are included, and that they use input from the project team, or at least from qualified subject matter experts. Include consideration of project risks that are particularly severe, especially the potential for black swan risks. Include an assessment of risk related to the expected scale of the project, and use the project framework or one of the other high-level risk assessment ideas included in Chapter 3.

In determining the evaluations for all of the criteria, confront any known organizational biases (such as a tendency to underestimate the effort on enticing novel projects and to overestimate boring, routine ones). Work to achieve consistent, comparable results for all the projects under consideration.

After collecting and validating the project evaluation information, use it to rank-order the list of opportunities. The first few items listed will be easy to decide on: good opportunities that can be staffed are selected and put into plan. However, the deeper in the list you go, the more complex selection becomes.

One selection strategy creates a provisional list by determining the cumulative cost of projects listed starting from the top of the sorted list and drawing a cut line below the last project that can be staffed and funded using about 90 percent of available capacity. Portfolio risk management requires that some capacity be left uncommitted, primarily to deal with project risk but also to manage organizational emergencies and to provide capacity to exploit unforeseen opportunities. The list resulting from this process is provisional because it is unlikely to conform to the target mix of project types, and it also may involve unnecessary portfolio risk.

Adjusting the relative overall investments dedicated to projects in different categories is straightforward. You exclude the lowest items on the list that lie above the cut line in categories that are oversubscribed, dropping projects until the aggregate investment is in line with your target. Similarly, you include projects that are below the line to your provisional portfolio to raise the cumulative budget represented in the categories that are too small. Further adjustments may be warranted to deal with limitations on expertise, facilities, or other organizational constraints. Additional changes may be required to ensure that related projects are either all in plan or all out of plan; if projects that are cross-dependent are not executed in sync, the value they deliver can be diminished or even evaporate.

One additional factor to consider is size. The relative scale of projects also makes portfolio management challenging. To illustrate, consider this exchange:

In a project portfolio, there will always be some way to accommodate an additional small project. Failing to consider the large, often strategic, projects at the outset of the portfolio process, however, can result in a portfolio filled to capacity with mostly smaller projects. This may leave insufficient resources to properly support the major project opportunities, so consider putting “large rocks” in first.

It may be tempting to allocate 100 percent of your available capacity when accepting projects into the portfolio. This is risky, because putting too many projects in plan can result in problems for all projects.

The final step necessary for managing portfolio risk is to assess overall risk for the proposed portfolio as a whole. This involves estimating risk correlations for the selected projects. One of the main objectives for portfolio management is exploiting negative correlations and using them to lower the overall risk. This is the reason that some people invest in mutual funds instead of individual stocks. Although the possible gains for a mutual fund are always lower than those for a single stock, so are the potential losses. The return for the “basket of stocks” in the mutual fund more is more predictable and has lower risk. This is generally true, though it isn’t always. If all the stocks in a fund are in a single industry and subject to similar exposures and threats, they will positively correlate. When any stock drops they will all probably follow, so the fund losses will mirror the losses of each stock. When project risks are related, the same will happen in a portfolio of projects.

One tactic already discussed helps in managing this—enforcing the proportions of the portfolio that will be devoted to projects in different categories. In addition to this, the portfolio manager needs to consider the projects in the provisional portfolio, examining them for, among other factors:

• Reliance on similar new technologies or applications

• Dependence on the same resources, especially outsourced or specialized staffing

• Significant project risks listed in common by several projects

• Potential failure modes shared by the projects

The portfolio management process seeks to select an optimal, or at least acceptable, mix of projects to undertake. Although risk is only one of the criteria applied to the decision process, it is a central one because the portfolio process is an important tactic for minimizing risks to the organization.

For each newly proposed or continuing project in a proposed portfolio, there are three possible outcomes.

1. The project is accepted into the portfolio, becoming or remaining an active project.

2. The project is accepted, but only after making changes (to scope, schedule, or resources) before accommodating it in the portfolio. Some projects may be lowered to an acceptable level of risk through “transfer,” by purchasing insurance to deal with excessive financial exposure, by converting the project to a joint venture and sharing the risks (and rewards) with a partner organization, or through other adjustments.

3. The project is rejected. Some (perhaps most) project ideas should be turned down or postponed for reconsideration at a later time.

Before finalizing a list of projects as the “in plan” portfolio, ensure that both the individual project risks and the overall cumulative risks have been thoroughly evaluated and the candidate list is consistent with the organization’s risk tolerance. Identify any particularly risky projects that are accepted into the portfolio, and ensure that the executives responsible for the portfolio will have adequate visibility of their progress and will be monitoring them at least monthly.

Portfolio decisions are never permanent; successful portfolio management must periodically revisit the selection process, including risk assessment. Portfolio reviews are typically conducted about once per quarter, and may also be necessary following the completion of a particularly large project. Portfolio reviews revisit the portfolio assumptions and criteria and manage portfolio risk by considering project status information, especially data on troubled projects.

The portfolio review process is essentially the selection process described earlier, but one of the key risk objectives in a review is detecting and weeding out inappropriate projects early. This ensures that the mix of ongoing projects will continue to encompass the best available project opportunities. Best-in-class high-technology companies find and cancel questionable projects early, before too much investment is made.

Other goals for the portfolio review are maintaining a balance of projects and keeping the project portfolio requirements within the capacity limits of the organization. Immediately after a portfolio is determined, additional good project ideas will surface. One reason for maintaining some unused capacity is to permit the organization to exploit new, unexpected opportunities, so adding some of these ideas to the portfolio is not necessarily a problem. However, there is frequently little discipline used in selecting and starting new projects, and the standards used for putting them in plan are not always as rigorous as those used for the initial portfolio decisions. This can quickly lead to a list of in-plan projects that have inadequate resources; progress will falter and stall for many of them. The “if some is good, more must be better” philosophy creates both excessive project and portfolio risk. It is not uncommon for the projects undertaken by high-tech organizations to require resources that are double, or even triple, what is actually available. Resource underestimation is a common project problem, as demonstrated by the data in the PERIL database. Making matters worse, the extra projects crammed into plan are often “urgent,” which tends to shift the mix toward short-term projects. This zero-sum game will result in inadequate resources being devoted to strategic projects that are more important to the organization, increasing future risk. Portfolio reviews manage risk by rectifying inappropriate balance and trimming the project list back to what can be adequately staffed and managed.

Monitoring and Controlling Portfolio Risks

The portfolio management process is not usually something that requires a lot of day-to-day attention. Portfolio risk is mostly managed in the selection and review processes. There are several matters, however, that do need ongoing attention.

Monitor high-level status for all the projects in your portfolio at least monthly. The portfolio monitoring process operates in parallel and depends upon the project execution and control processes, as illustrated in Figure 13-4. For each project, define and track a few diagnostic project metrics such as those described in Chapter 9. There are a number of software tools available for monitoring a collection of projects that can be used to implement a “project dashboard” for the portfolio. Dashboards can be quite useful, and for larger project portfolios may be necessary. For modest project portfolios, though, ongoing oversight using a handful of key measures does not usually need to be quite so complicated—a spreadsheet or a deck of presentation slides for tracking and reporting will likely suffice.

Most project portfolios have a small number of high-risk projects, and these need particular attention. At least monthly, conduct an in-depth review of progress. Work to detect issues early that might develop into major problems. For all projects in the portfolio that are currently in trouble, focus on what is necessary to bring them back under control. Allocate additional resources, revise expectations, or make other changes. Use the available reserved resource capacity to resolve the issues, and deal promptly with any problems that are escalated from the projects needing management attention.

Managing bad news at the portfolio level, as at the project level, requires a single-minded focus on problem solving and resolution. Responding to unfavorable status information with criticism, punishment, or even disapproval can take a situation from bad to worse. Motivation on risky projects is often tenuous, and you need a motivated, enthusiastic project team to solve tough problems. A troubled project staffed by disillusioned, depressed contributors will never recover.

If, after a sincere effort, there appears to be no plausible recovery scenario for a project, cancel it and get it out of the portfolio. A key job of the portfolio manager is to limit the losses when a project is headed irretrievably toward failure.

It is also necessary to monitor overall resource use, and to detect when projects are competing for the same resources. When there are resource contention issues, adjust the portfolio to deal with them, shutting projects down temporarily (or even permanently) when necessary. When projects are delayed while queuing for scarce resources, consider acquiring more capacity, or at least ensure that the queuing is based on project priority, not just “first come, first served.”

One additional wrinkle at the portfolio level comes from the essentially financial basis used to measure success or failure. Assumptions made for projects are often overtaken by events, especially on long duration projects. Also, as projects progress, the estimates for cost and value are likely to change. Changes inside your organization or even outside can significantly alter the overall evaluation for any given project, and some of these changes may substantially decrease a project’s expected value. As new information becomes available, re-evaluate the affected projects to determine whether they still deserve to be in the portfolio.

Overall, managing risk in a project portfolio involves ongoing dedication to ensuring that needed resources are available, risks are anticipated and managed, decisions and other required management actions are timely, barriers to progress are removed, and problems are solved. A portfolio filled with understaffed, poorly funded, trouble-ridden projects represents unacceptable risk in any organization.

Enterprise Risk Management

The final section of this chapter climbs one level higher in the organization. Enterprise risk management encompasses all the project, program, and portfolio risk management concepts, and more. One type of enterprise risk management takes a traditional view of risk, as an uncertainty with a potential for harm, in this case to the organization as a whole. There’s also a more narrowly defined concept for enterprise risk management that has emerged recently, with government regulation and industry standards as its foundation. We explore the relationship between project risk management and both of these types of enterprise risk in the remainder of this chapter, beginning with the more conventional perspective.

Organizational Threats in General

Enterprise risk relates to project risk management because projects both contribute to enterprise risk and are employed to manage it. Projects create organizational risk for all the reasons discussed throughout this book. Managing enterprise risk that arises from individual projects is generally delegated to lower levels of the organization. Risk management of this type relies on the techniques for project risk management outlined in Chapters 8 and 10 for projects, and the ideas for managing program and portfolio risks explored earlier in this chapter. With the exception of the most major black swan risks that could materially damage the entire organization, few risks associated with projects are actively managed at the enterprise level.

Although project risk is not generally a big concern to the enterprise risk manager, the converse is not true. The impact of enterprise risk management on projects is quite substantial. The purpose of enterprise risk management is to ensure the ongoing viability of an organization. There are a number of specific areas where enterprise risk managers focus their attention that may affect projects, including:

• Safety and security

• Fraud and financial liability

• Casualty loss and disaster preparedness

• Organizational reputation and brand protection

• Intellectual property management

This is only a partial list, of course. There may be many other specific concerns representing potential for loss or damage to a given enterprise. One line of defense used to manage enterprise risk is defining and enforcing processes for the organization that are designed to minimize exposure. For example, legal contracts templates and review processes limit financial risks. They also include mandatory provisions intended to limit other types of risk to the organization, such as nondisclosure terms protecting intellectual property. Mandatory training for well-defined, documented standards for business ethics, enterprise controls, and other business processes are also essential to managing enterprise risk. Worker safety is also important to the enterprise. Reflecting the origins of the company manufacturing gunpowder two centuries ago, DuPont still requires stringent processes for safety in all locations and mandates periodic safety meetings for all employees, including people who are based in offices at headquarters where the safety risks tend toward paper cuts.

These and other actions at the enterprise level aimed at managing risk relate to project risk management because they influence the risks faced by each individual project. Conformance to risk-related policies set by the organization is intended to reduce project risk, and they provide leverage for enforcing risk management methods that a project leader may otherwise lack. In addition to the policies and procedures a project is subject to, each deliverable created by a project must also meet the established standards for protection of confidential information, security, reliability, and other organizational mandates. Staying within the bounds of accepted organizational expectations is good risk management.

For some projects, the link to enterprise risk management is even more fundamental. In any given year, some fraction of the projects undertaken in an organization will be primarily to manage enterprise risk. Some of these projects will implement new safety procedures or replace faulty equipment. Others will develop techniques or algorithms that limit threats to security, eliminate fraud, or deal with other sources of potential loss. Enterprise risk management is a fertile source for projects.

The Millennium or Y2K bug is a good example of this from the recent past that affected companies worldwide. As the end of the twentieth century approached, the consequences of decades of software developed and implemented using only the last two digits in dates to represent the year began to loom ominously. Most organizations trace their recognition of this as a real and immanent threat to a 1993 article in ComputerWorld written by Peter de Jager. In his piece titled “Doomsday 2000,” he spelled out in some detail what would occur as the world’s clocks ticked over from December 31, 1999, to January 1, 2000. Despite the title, the article was less about the “end of the world as we know it,” and more about the breadth of the problem and the magnitude of the effort it would require to deal with it. To quote from de Jager’s article:

This article raised a lot of concern, because by the early 1990s computers were incorporated in all conceivable applications, from defense systems and automated factory control to determining the moisture in clothes dryers and the color of toasted bread. The article also provided some good advice for separating the important from the not so important. The main point was to separate the real risks, those that represented significant, permanent potential harm, from the rest. Not all computers were necessarily at risk. What mattered was whether a date function was employed, and how it was used. For some situations the problems were transitory, such as for real-time applications that rely on information for only a few days or hours. For other cases the harm would be only temporary because it could be easily detected and corrected after the fact (often manually and at substantial cost, but without much external publicity). Once the problem was publicized, programmers all over the world began to consider the possible consequences of disregarding a key portion of each stored date in their applications. There was a great deal of attention to financial and payroll systems, to ensure that paychecks would be correct and savings accounts would not be wiped out.

There were, however, situations where the impact would not be temporary or easily fixed, as well as cases where the risks might have enormous consequences that were not easily diagnosed. There were legitimate questions concerning missiles erroneously being launched, critical-care hospital equipment going haywire, and airplanes falling from the sky. Most of the extreme scenarios were low probability propositions, and this was known at the time. In a recent conversation, de Jager recalled responding with incredulity to a prediction that Y2K might result in “losing power in the United States forever.” Again, the point of the article was not that we were facing the end of civilization. As de Jager stated in 1993, “It is very difficult for us to acknowledge that we made a ‘little’ error that will cost companies millions of dollars. . . . We must start addressing the problem today or there won’t be enough time to solve it.”

As with any risk, analysis of Y2K came down to “loss times likelihood.” Overall assessment of the Y2K risk was fairly straightforward. The probability of malfunction of some sort on January 1, 2000, for many software applications was high, essentially certain. Impact was not difficult to estimate for most cases either. For many situations it was also high. Even for situations where the estimated economic impact appeared to be modest, there could be other enterprise-level considerations. Given the publicity, especially near the end of 1999, few organizations were willing to appear unprepared. Having difficulties related to such a highly publicized problem would make companies look incompetent and do damage to their reputations. Even though the measurable impact in such cases might have been hard to estimate with precision, it was nonetheless quite real. As was discussed in Chapter 7, this kind of qualitative risk impact often represents the most significant consequence of a risk, particularly as viewed from the enterprise level.

I saw the evolution of Y2K response at the project level firsthand, as an internal engineering and project management consultant with Hewlett-Packard. At HP, the risks were unquestionably real, and there was universal recognition that timely action was necessary. Hundreds of projects at HP were initiated to deal with Y2K. As at many companies, a lot of legacy software at HP was carefully inspected. Some projects rewrote or replaced applications. Other projects upgraded computer hardware to eliminate the potential for problems.

Estimates for such project work and infrastructure changes for all companies, governments, and other organizations worldwide range into the hundreds of billions of dollars, a massive amount of money invested in risk management.

At the project level, the impact of Y2K was mostly limited to technical projects of this sort. Risk exposure at the enterprise level, though, for some organizations extended well beyond this. Companies involved in providing IT products and services had the additional risk of potential lawsuits and damage to their corporate reputations. The threats went well beyond expense; there was a real potential for loss of customers and a fundamental threat to the business as a whole.

Managing this at HP initiated still more Y2K-related projects and work. In 1998, Ted Slater was involved in managing a business crisis communications program as part of his responsibilities in marketing in the Americas. The program was not initially related to Y2K, but as 2000 approached, it was expanded to cover corporate-level Y2K response for the entire company, worldwide. The focus was dealing effectively with any and all customer problems, especially any that had the potential for generating public relations or legal problems. The primary goal was to “do the right thing for the customer,” and to do it fast. The effort involved:

• Establishing well-defined, rapid escalation processes, particularly for cases where there were any potential safety or health consequences

• Quickly involving all people who would play a role

• Maintaining effective and visible communication with all parties

• Identifying one individual responsible for all external communications and management of a consistent single message for each situation

The primary objective was to protect the reputation and brand identity by acting swiftly to solve problems and “make the customer whole.” Preparations for Y2K involved simulations that tested the processes required. These tests ensured that they would function as planned. The scenarios resulted in improvements to training materials and shifts in preparation in the lead-up to Y2K, for which HP was well prepared.

Slater reports that a small number of HP customer situations arose with the beginning of January 2000, but only a tiny fraction of the worst-case estimates and none that was significant. This particular enterprise risk at HP was well managed.

As at HP, Y2K risk management everywhere proved to be successful. As 1999 ended, there were many problems—mostly small and quickly fixed—but few disasters. Although the consequences of Y2K were apparently minimal, the actual consequences did include a good deal of “cleanup” work that was neither publicly reported nor visible, particularly in areas where the threat was not taken seriously. There were, however, some significant problems that did surface despite all the publicity and preparation, including one case involving an application used in the United Kingdom to screen pregnant women. The software tragically provided faulty reports for months before its date-related defect was diagnosed and could be repaired.

The absence of massive fallout from Y2K is seen as a satisfactory result made possible by skillful application of risk management. Nevertheless, this lack of fallout has also been characterized by some as evidence that Y2K was much ado about nothing. There seems little doubt to me that the risks were real, and that doing nothing would have been ugly.

The very existence of this debate, however, raises a fundamental issue about risk management in general, and not just at the enterprise level. Managing risks is never free, and for Y2K the costs were quite large. For any risk we choose to manage, we must invest real time and money, which are easily measured, right now. We generally make a choice to act when the potential costs and consequences of inaction appear to be even higher, as John F. Kennedy stated in the quote at the start of this chapter.

Choosing to act, however, changes everything. A response that removes or mitigates a risk makes it impossible to know what would have happened without that action. Because of this, it’s rarely possible to “prove” conclusively that managing a risk was worthwhile. If, as was common for Y2K, you mitigate the risk by examining and fixing deficient software or avoid the risk by dumping older systems and applications and replacing them, the cost of inaction can never be determined with certainty. Estimates of the avoided impact will forever remain an uncertain forecast, open to conjecture. You can’t measure something if it doesn’t happen. Particularly in retrospect, there are often people who criticize the expense of managing risk, either because they do not understand (or don’t care about) the potential consequences or because they don’t believe the impact or probability for the risk. Especially in the current climate of short-term organizational thinking, making investments right now to manage risks that may or may not occur in the future is becoming harder and harder to sell.

Enterprise Risk Management Based on Standards

Enterprise risk management has also come to also mean something much more specific, especially in the United States. There are a number of organizations that have codified practices for managing enterprise risk using this label. One of them is the Committee of Sponsoring Organizations of the Treadway Commission, or COSO, a U.S. government–initiated organization. COSO and other groups have defined frameworks and standards for managing enterprise risk that have had substantial influence on organizationwide risk management.

COSO is the current incarnation of a commission initiated by the U.S. Congress in the 1980s that was formed to address issues concerning inaccurate financial reporting, particularly by companies on the brink of failure that nevertheless managed to publish healthy-looking financials. It was led by James Treadway, a former head of the U.S. Securities and Exchange Commission, and comprised five U.S.–based financial standards organizations, each involved with some aspect of financial accounting or auditing. In 1992, COSO published the COSO Internal Control—Internal Framework, which defined tightened standards for financial reporting. The framework addressed enterprise risk assessment, but not in much detail. It called for determining risk significance (impact) and likelihood or frequency, but it did not specify how this was to be carried out. It also outlined the need to determine how to manage the risks and what actions to take, but it left the details on this to the management of each enterprise. In the wake of additional reporting irregularities, including the now well-documented shenanigans of Enron, WorldCom, Tyco, and others, COSO expanded the control framework to include enterprise risk management. COSO initiated this project in 2001, engaging Pricewaterhouse-Coopers. The project culminated in 2004 with the publication of the COSO Enterprise Risk Management—Integrated Framework.

One of the main reasons that this framework has had such wide-ranging influence is its relationship in the United States with the Sarbanes-Oxley Act of 2002 (SOX), and increasingly with regulatory legislation around the world similar to SOX. To meet the requirements set out by SOX and equivalent laws in other countries, companies must establish and follow well-defined and controlled processes for their public reporting, and risk management has become a central aspect of this.

This book is not primarily about enterprise risk management in general or COSO in particular, but the practice and discipline of project risk management has been influenced extensively by COSO and similar standards organizations. It is useful to understand the broad outlines of the COSO enterprise risk management framework to ensure that your projects are aligned and conducted consistently with enterprise requirements.

The COSO enterprise risk management framework includes eight interrelated components that are to be defined consistently at all levels of the organization, from the board of directors all the way down to the trenches where projects are managed:

• Internal environment : Includes standards, processes, codes of ethics and conduct, and much of what was discussed in Chapter 2 regarding risk management planning. Risk tolerance here is referred to as “risk appetite.”

• Objective setting : The “what?” question. At the enterprise level, this starts with setting strategy and includes tactics, goals, and current projects. The process for this overlaps with and includes the project portfolio process explored earlier in this chapter. This is also where measures are defined that will be used throughout the organization.

• Event identification : Risk identification for the enterprise, including (but not limited to) project risk identification as covered in Chapters 3 through 5.

• Risk assessment : Both qualitative and quantitative analysis of overall enterprise risk, using techniques consistent with those discussed in Chapters 7 and 9.

• Risk response : This component defines precisely the same responses as Chapters 8 and 10: avoid, mitigate (here called “reduce”), transfer (here called “share”), and accept.

• Control activities : This and the last two COSO enterprise risk management framework items align with the practices outlined in Chapter 11 on risk monitoring and control. Emphasis is on ownership of the risk responses and on the use of retrospective analysis for feedback (as described in Chapter 12).

• Information and communication : Communication is always fundamental to good management at all levels. Emphasis here is on credible, frequent reporting and retention of information.

• Monitoring : Tightly coupled with control activities, with particular prominence for metrics. Concepts such as Robert Kaplan’s “balanced scorecard” are commonly part of this at the enterprise level.

Overall, the road map outlined by COSO enterprise risk management is highly compatible with what is found in the Project Management Institute Guide to the Project Management Body of Knowledge, in this book, and in most other useful guidance on managing business risk.

COSO is not alone in the field of enterprise risk management standards. The Risk and Insurance Management Society is aligned with the global insurance industry and has a similar defined set of guidelines. The International Organization for Standardization (ISO) is in the process of developing an international risk management standard, ISO 31000. There are others as well, and the future will doubtless bring still more standards for managing risk. Regardless, the basic content is not likely to change materially—the fundamental ideas for risk management that have worked in the past are quite durable. No matter what, though, there will continue to be a stream of new projects created as a direct consequence of enterprise risk management. The program that I was responsible for planning at Hewlett-Packard described in the program risk management section of this chapter was largely a consequence of the regulatory changes in the United States and elsewhere. In particular, the requirements outlined in Section 404 of SOX call for a top-down risk assessment and impose standards for reporting. This has led to a tightening of processes for companies throughout the United States. At HP it also involved replacing disparate tracking and management methods in the fee-for-service project businesses worldwide to ensure consistency. The trend toward better internal controls, more audits, and improved process testing appears here to stay.

Panama Canal: Over the Years

When the project finishes, the project team moves on. The deliverable remains, however, and things are rarely static. The success of the Panama Canal was as predicted, which was both good and bad. The growing traffic through the canal in its first years of operation required increasingly frequent filling and draining of the locks. The locks were filled from above using water from Gatun Lake and drained to the sea, so the water required depended on the volume of traffic. The more ships that passed through the locks, the more water had to be drained out of the lake. Even a tropical rain forest has dry seasons, so it was not uncommon for the water level to drop periodically. When the water was too shallow in the roughly 13-kilometer Gaillard Cut that sliced through the continental divide in central Panama, the canal shut down.

This enterprise risk was increasingly troublesome as the years passed. It interfered with the operation of a two-ocean U.S. Navy, which was one of the main reasons for the U.S. canal project in the first place. After several decades of periodic difficulty keeping the canal operational year-round, a sizable follow-on project was initiated to ensure a more reliable supply of water. This project constructed yet another dam, this one further up Chagres River above Gatun Lake. In 1935, the Madden Dam was completed, creating Alajuela Lake and the supply of additional water that the canal depends upon to this day.