Abstract
Interest in program management has been growing since the initial edition of The Standard for Program Management by the Project Management Institute (PMI) in 2006 (with its second edition due in late 2008), as well as since the 2007 revision of the UK Managing Successful Programs standard. Programs cannot be treated as large projects, but require specific processes, tools, and techniques to ensure their effective management. This includes a clear requirement for management of risk, since programs are obviously risky undertakings. But just as there is a difference between program management and project management, so program risk management is different from project risk management. This paper explores the specific characteristics of program risk management, drawing on current thinking and practice.
Program risk management must be undertaken at two levels. First, it is necessary to manage the overall risk exposure of the program as a whole (“program risk”). Second, proactive management is required for a range of individual “program risks” that arise during execution of the program. This paper outlines how to manage risk at both levels, through implicit and explicit program risk management. Implicit management of overall “program risk” is focused on risk efficiency, allowing risk exposure to be balanced across the program. The elements of an explicit program risk management process are also summarized, addressing “program risks” from three sources: risks that have been escalated or aggregated from constituent projects and other program components, strategic risks delegated from higher in the organization, and specific program-level risks.
Finally, this paper outlines the challenges remaining in developing a robust and effective approach to the management of program risk.
Introduction
Projects are recognized as an effective means of delivering value to a business, which has led to the establishment of project management as a mature discipline (some would say a profession). Project-based organizations are now seeking ways to organize their delivery of projects in the most effective manner, resulting in the emergence of program management and portfolio management. Both of these new disciplines offer frameworks for structuring project work and relating it to the needs of the business. However, neither program management nor portfolio management has yet reached the level of maturity attained by project management. Nonetheless, professional associations and standards bodies have been addressing themselves to defining the new areas. The UK Government Central Computer and Telecommunications Agency (CCTA) published a full suite of guidelines on program management during 1993 through 1995 (The Programme and Project Management Library), which were formalized in 1999 with the first edition of the Managing Successful Programmes guide (Central Computer and Telecommunications Agency, 1999), recently updated to its third edition (Office of Government Commerce, 2007). More recently, the Project Management Institute (PMI) published first editions of their standards for both program management and portfolio management in 2006 (Project Management Institute [PMI], 2006a, 2006b), with second editions due in late 2008. The PMI Guide to the Project Management Body of Knowledge (PMOK® Guide)---Third edition mentions program management only briefly (PMI, 2004, p. 16), whereas the most recent edition of the APM Body of Knowledge from the Association for Project Management includes program management as one of its knowledge areas (Association for Project Management [APM, 2006, pp. 6-7).
There is clear consensus that organizations will reap benefits by managing their projects in a coordinated manner, and that program management offers a framework for doing that. Unfortunately, the precise details of program management are not yet defined in a way that is accepted by all. Everyone agrees, however, that programs are risky undertakings, so risk management must be an integral part of how programs are managed. However, because there is no current consensus on the fundamentals of program management, it is not surprising that program risk management is even less well defined. This paper briefly outlines program management basics, then discusses the elements necessary to ensure effective management of risk at program level.
Program management basics
At the most fundamental level, the immaturity of program management as a discipline is illustrated by the varying definitions of the word “program(me)” (and even its spelling!), and the varying understandings of the purpose of program management. Exhibit 1 presents definitions from leading program management standards and guidelines.
Exhibit 1--Definitions of program(me) and program(me) management
Despite the obvious differences in these definitions, there is wide agreement that programs exist at a higher organizational level than projects, and that their purpose is to deliver strategic benefits (Murray-Webster & Thiry, 2000; Reiss et al., 2006; Thiry, in press). It is also clear that the scope of programs is broader than just the sum of their constituent projects (Pellegrinelli, 2002; Pellegrinelli & Partington, 2006). More significantly, the objectives of a program are not simply the sum of the objectives of the projects within that program, since program objectives relate to the strategic goals of the overall organization. In simple terms, project objectives are tactical and relate to deliverables, whereas program objectives are strategic and relate to benefits.
Much more could be said about the nature of programs and the role of program management. However, the aim of this paper is to consider specifically how risk can and should be managed in the context of programs. It is axiomatic to say that programs are risky, and that risks need to be managed proactively, but how? Perhaps one option is simply to take project risk management and apply the same process at a higher level. But just as programs are not just large projects and program management is not the same as project management, so program risk management is different from project risk management. Program risk management has a different aim and scope, and follows a different process, which requires different techniques. These are addressed in the following sections.
Aim and Scope of Program Risk Management
The aim of program risk management is to manage risks at program level. This is not as simple as it sounds. A risk can be defined generically as “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more <> objectives.” Inserting the word “project” at the point marked <> gives a specific definition of project risk (PMI, 2004, p. 238). It is also possible to define other types of risk by inserting other words, including “strategic,” “technical,” “environmental,” “personal,” and so on. Similarly, a program risk can be defined as “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more program objectives.”
Because programs sit between projects and organizational strategy (Pellegrinelli & Bowman, 1994; Murray-Webster & Thiry, 2000; PMI, 2006a; Thiry, in press), there are three potential sources of risk that could affect a program. Risks could arise at program level from three directions, as illustrated in Exhibit 2---namely, up from the components of the program, down from organizational strategy level, or sideways from the program level itself. The scope of program risk management must include all three sources of risk.
Exhibit 2--Sources of risks at program level
Risks Escalated or Aggregated from Below
We have already seen that the objectives of a program are more than the sum of the objectives of its constituent projects. So program risks are not simply the sum total of project risks. There are four sources of risk at program level that arise from the program components.
- Programs contain projects, and projects are risky, so at least some of the risks that can affect the program will come from within the projects that constitute the program. Of course, not all project risks are relevant at program level, so escalation criteria are required that will define the thresholds at which a project risk should be passed up to program level. These criteria need to include project risks with program-level impact, as well as project risks requiring program-level responses.
- It is also necessary to be able to aggregate project risks, where a number of similar and related risks at project level might combine to create a program-level risk, either by simple summation (ten insignificant project risks may equal one significant program risk), or as a result of synergy (the whole may be greater than the sum of the parts). Suitable risk categorization schemes are required to facilitate such aggregation by identifying commonalities and possible synergies, and a generic program-level risk breakdown structure (RBS) may be used for this purpose.
- There is a distinction at project level between individual “risk events” and overall “project risk.” The Project Risk Analysis & Management Guide from the Association for Project Management defines “project risk” as “the exposure of stakeholders to the consequences of variations in outcome; the overall risk affecting the whole project, defined by components associated with risk events, other sources of uncertainty and associated dependencies, to be managed at a strategic level” (APM, 2004). A similar definition is contained in the forthcoming Practice Standard for Project Risk Management from PMI, which says, “Overall project risk represents the effect of uncertainty on the project as a whole. Overall project risk is more than the sum of individual risks on a project, since it applies to the whole project rather than to individual elements or tasks. It represents the exposure of stakeholders to the implications of variations in project outcome.” (PMI, in press). These definitions make it clear that “project risk” (or the risk of the project, as distinct from the risks in the project) will have an impact at program level, and must therefore be considered within the scope of program risk.
- It is also important to remember that programs can contain nonproject components (see Exhibit 1), so risks may also be escalated and aggregated to program level from these program elements, and not just from projects.
Risks Delegated from Above
Programs exist to deliver benefits that are aligned with the organizational strategy, and there are strategic risks associated with the overall direction of the organization. Although many strategic risks can and should be addressed wholly by the senior leadership of the organization, some will have implications for those programs that are used to deliver the strategy and create the business benefits. Strategic risks that can affect program objectives or that require program-level action will need to be delegated. This requires well-defined delegation criteria and thresholds, as well as clear channels of communication to ensure that management of strategic risks delegated to program level is reported back to senior management. The goal is delegation without abdication.
Risks Arising at Program Level
In addition to risks escalated from below or delegated from above, programs are affected by specific uncertainties at the program level. These include both threats and opportunities across the full range of risk types, including technical, management, commercial, and external risks. Thiry has suggested that opportunities may be more relevant at program level, due to the emerging nature of programs (Thiry, in press). Program-level risks fall into two main categories: those arising from interfaces between program components, and “pure” program risks relating to the execution and management of the program itself.
Managing Program Risk
It is a common misconception to limit the understanding of program risk management to the need for a structured risk process at program level. Although this is one part of the solution to the challenge of program risk, it is not the first, and perhaps not the most important. In the same way that there are two levels of risk affecting projects as discussed above, namely overall project risk (“risk”) and individual risk events (“risks”), program risk management should occur in two main ways: implicitly (addressing overall “program risk”) and explicitly (tackling individual “program risks”).
Implicit Program Risk Management
Overall “risk” can be managed implicitly at program level through the inherent structure of the program itself. This occurs at two levels: component selection and program execution.
- The components of the program should be selected in order to maintain risk exposure at a level that is consistent with organizational risk appetite while offering the required return to the business. This “risk efficiency” approach has been promoted widely within project risk management (e.g., Chapman & Ward, 2003, 2004), based on the pioneering work of Markowitz (1959), and it is clearly also applicable to program management, particularly in relation to selection of program components. This element of the management of program risk must be closely linked to the overall strategic risk process of the organization, which will determine the selection criteria for program components. The level of overall project risk exposure for each constituent project within the program will form a key input to this analysis, and quantitative risk analysis techniques may be useful at this point. Overall program risk should be reviewed and monitored on a regular basis throughout the program life cycle, as part of the routine management of the program, and the composition of the program should be adjusted as necessary in order to maintain an acceptable level of overall risk exposure within the program.
- Programs are usually divided into chunks or tranches, in order to provide incremental delivery of useful packages of benefits. This division of the program parallels agile or lean project development methodologies and is intended to reduce the overall risk exposure of the program. Risk can be reduced by decoupling the tranches, and creating so-called “islands of stability” (first described in Central Computer and Telecommunications Agency, 1994). This allows the program to be executed in cycles, interspersed with periods of stability when benefits can be examined and quantified, and the next chunk can be planned in detail. Programs should be structured with built-in flexibility and resilience in order to allow the content of future tranches to respond to the current level of risk exposure.
Explicit Program Risk Management
In addition to managing “risk” implicitly at program level, explicit management of “risks” that emerge during the execution of the program is required. This necessitates a structured program risk management process analogous to the project risk management approach, which must iteratively identify risks, assess their significance and importance, develop appropriate responses, implement those responses, and monitor subsequent changes.
Many of the program management guides and textbooks limit their descriptions of risk management to this type of explicit risk process, and most simply recommend adopting or adapting the methods of project risk management (examples include Murray-Webster & Thiry, 2000; Thiry, 2004, in press; Project Management Institute, 2006a; Reiss et al., 2006; Office of Government Commerce, 2007). Although the structure of the program risk management process matches that of projects, some important differences exist, as outlined below:
- Initiation/risk management planning. This step launches the risk process for the program and defines the scope of the risk process, within which risks will be identified. Risk thresholds are set against each of the major program objectives, against which risks will be assessed (a benefits breakdown structure may be used for this purpose). Criteria are agreed for risk escalation, aggregation, and delegation, as discussed earlier. Process parameters are defined, including roles and responsibilities, and review and reporting requirements. This is initially performed at program launch, but should be revisited at key points during the program life cycle, to ensure that the program risk process responds to the changing risk profile associated with the evolving and emergent nature of programs. Initiation decisions should be documented in a Program Risk Management Plan.
- Risk identification. Before the program is launched, the level of overall program risk will have been identified and assessed, using the implicit risk management techniques discussed above. Individual program-level risks should also be identified as part of the explicit program risk management process, both on a regular and ad hoc basis, taking into account the three routes by which such risks arise (see Exhibit 2). Risks may be escalated or aggregated from lower component levels or delegated from higher strategic levels, and the program requires clear criteria to determine whether these should be accepted for management at program level. In addition, the usual risk identification techniques can be used to find program-level risks, including brainstorming, checklists, assumptions analysis, Delphi groups, and so on. Risk identification at program level should seek both threats and opportunities and should consider the full range of potential risk sources defined in the program RBS. Risks will be recorded in a program risk register.
- Risk assessment/analysis (qualitative/quantitative). Identified risks should be assessed and prioritized based on their likelihood of occurrence (probability and/or frequency) and their impact on program objectives. Risks escalated/aggregated from component level and risks delegated from strategic level will need to be reassessed against program-level risk thresholds to allow them to be prioritized on a common basis. Quantitative risk analysis techniques can be used to provide an overall assessment of program risk exposure, combining the effects of all types of risk at program level and taking into account risk dependencies, and the results from this analysis should be fed into the implicit management of overall “program risk” discussed above.
- Risk response development. Response to the overall level of program risk exposure is handled through the implicit risk process above, by adjusting the program composition to maintain risk efficiency. Explicit responses are also required for individual program risks, and these match the options available at project level, including avoid/transfer/reduce/accept for threats, and exploit/share/enhance/accept for opportunities. Additional response options available at program level include escalation of a risk to strategic level (where the impact affects strategic objectives and/or senior management action is required) and delegation of a risk to component level (where the primary impact and/or risk ownership is at a lower level); suitable escalation/delegation criteria are required.
- Risk review/risk monitoring and control. Risk is a dynamic challenge within programs, and the program risk process must be iterative in order to maintain an appropriate degree of attention to managing risks. Regular risk reviews must be held at program level, usually as part of the routine program management process, but the scope of these risk reviews must be rigorously controlled to avoid discussing project risks or strategic risks outside the scope of the program.
- Risk lessons learned. When a program is terminated, it is important for the organization to capture knowledge to benefit future programs. A formal lessons learned workshop should be conducted, and risk must be considered as part of this exercise. It would also be useful to hold interim lessons learned workshops at key points during the program life cycle, to identify lessons that might be implemented in later phases of this program as well as might benefit other programs.
Remaining Challenges and Way Ahead
This paper has presented a structured approach to the management of risk on programs, including both implicit management of overall “program risk” through applying a risk-efficient approach to the construction and execution of the program throughout its life cycle, and also implementing an explicit program risk process to address individual “program risks” that arise from a variety of sources. Although the principles described here are clear, a number of challenges exist in ensuring that these are implemented effectively. These challenges are briefly outlined below:
- Implementing risk efficiency. Management of overall “program risk” is an essential responsibility of the program management team, and it depends on an understanding of the role of programs in delivering strategic benefits to the organization. Managing program risk using the implicit techniques described above also requires an ability to turn the theory of risk efficiency into practice. Although the principles of risk efficiency have been known for 50 years (Markowitz, 1959), and their application to financial portfolios is well established, it is not always immediately clear how such an approach should be applied at program level. In particular, there may be challenges in deriving the measures required to build and operate a risk efficiency model and in understanding how to define the risk efficient frontier to reflect the risk appetite of key stakeholders for a particular program.
- Avoiding a project mindset. Many of the existing program management guidelines have been developed by organizations and practitioners who come from a project management background. As a result, their departure point in terms of both thinking and process is the project mindset. This is particularly evident in the PMI approach (Project Management Institute, 2006a), which has a program risk process that mirrors the project risk process precisely (cf. Project Management Institute, 2004), and it is also evident in the Office of Government Commerce recommendations (OCG, 2007). There are many pitfalls associated with taking a project-based view of programs (Pellegrinelli & Partington, 2006), most of which arise from limitations in the underlying thinking. This is likely to remain a challenge for as long as the majority of program management practitioners continue to come from the world of projects, or at least until the concepts and practice of program management become better established.
- Tailoring to different program types. There is no unitary concept of a “program,” and the term covers a variety of different configurations. Early work by Pellegrinelli described several types of programs (Pellegrinelli & Bowman, 1994; Pellegrinelli, 1997), including the portfolio, goal-oriented, and heartbeat configurations, each of which has different characteristics and, consequently, different risks. As a result, one might expect the challenges of program risk management to differ among these various types of programs. This paper has outlined some generic features of risk management at program level, but further work may be required to tailor the generic approach to particular program types.
- Lack of wider consensus on program management. Earlier sections of this paper outlined the ongoing debate about the nature and purpose of programs and program management, indicating the lack of consensus among key players and opinion-formers in the field. Although this wider discussion continues at the level of program management itself, it is unlikely that sufficient attention will be given to lower-level disciplines such as program risk management. However, this paper has shown that one key way to manage program risk is through the implicit construction and execution of the program, and therefore risk management cannot be left until later, when the bigger debate is resolved.
Despite these challenges, there is no doubt that programs are risky undertakings, and that successful program delivery depends on effective program risk management. Although there are similarities and parallels between the process for explicit management of individual program risks and the well-established project risk management process, program risks can arise from above and below the program as well as within it, and the process must tackle all of these sources. In addition, program risk management must encompass the implicit management of overall program risk exposure through application of a risk-efficient approach to the construction and ongoing execution of the program.
