APPENDIX E
INTEGRATING EARNED VALUE MANAGEMENT WITH RISK MANAGEMENT
E.1 Introduction
Earned value management (EVM) is a project management discipline that functions in concert with other disciplines and for which an integrated approach is essential. This appendix examines the relationship between EVM and risk management.
The relationship of risk and risk management with EVM is a complex one. We could even conclude that the reason for using EVM is to mitigate the risk of cost overruns on projects.
A risk is usually contemplated initially as an uncertainty. However, in order to be considered a risk, three elements are required:
(1) A possible risk event
(2) A probability of the event taking place
(3) An assessment of the impact that the risk event will have if it occurs
Without these three characteristics, only an undefined, imprecise uncertainty exists. This will be a crucial concept as we further discuss concepts in this appendix.
It is important to note that while risk and risk management are often thought of in terms of events that can jeopardize the project objectives, they can also be applied to those conditions that present opportunities for the project.
Strategies to deal with risks should be reflected in the performance measurement baseline (PMB). This may seem obvious, particularly in the case of risk management strategies, but past EVM practice and guidelines have often precluded the integration of the risk management. One particularly contentious issue has been budget for contingency plans.
A traditional view of EVM and EVM practice makes no distinction between contingency reserves for realized risks and management reserves, which, by definition, is for “in scope, but unforeseen” work. However, a compelling case can be made for the incorporation of contingency reserves as a component of the PMB in order to produce a creditable and realistic PMB.
E.2 Planning for Risk Management
In the initial phases of the project, organizations often will use statistical analysis to develop an S-curve (see Figure E1 below) that depict the project's range of potential outcomes based primarily on its assessed risks and opportunities. The statistical name for an S-curve is the cumulative probability distribution. S-curves are derived from the project's cost estimate, the cost estimating uncertainty, and the identified risks and opportunities, which are events that can cause the costs incurred to rise above or drop below the cost estimate. Each point on the curve indicates the cumulative probability (y-value) that the cost will be less than or equal to the amount shown on the x axis (x-value).
S-curves are often used to understand the range of potential costs for a program. This understanding enables business decisions. The final proposed, risk-adjusted cost estimate will be one that represents an acceptable business undertaking, given the organization's familiarity with the work, the assessed risk, the organization's risk appetite, and other factors.
E.3 Establishing the Performance Measurement Baseline (PMB) to Include Risk Management Strategies
When creating the PMB, the objective is to represent an executable, credible, and realistic time-phased budget plan and corresponding schedule. This plan, as represented by the PMB, is used to measure the actual project performance in comparison to the plan. Risk management strategies, particularly for risk mitigation, are included in the PMB.
Although, both project threats and opportunities represent risks, similar treatment can be made for those risks that represent opportunities and the strategies used to deal with opportunities. However, only the negative risks or threats will be dealt with in the remainder of this appendix.
The risk management strategies for threats are:
(1) Avoid the risk. Instead of taking a course that may prove risky, we avoid the risk altogether. When the avoidance strategy is used, the time-phased budget for the method or path chosen are inserted when constructing the PMB, and the path “avoided” is not represented in the PMB. The tasks for the path chosen are also reflected in the integrated master schedule (IMS).
(2) Transfer the risk. In this situation, the threat still exists, but the risk is transferred in some way to another party. The time-phased budget associated with the risk transference, if any, is reflected in the PMB and the specific tasks are included in the IMS.
(3) Mitigate the risk. In this situation, the risk still exists, but the impact or probability of the threat is diminished in some way by proactively taking action prior to the risk horizon date. Although the risk is mitigated, residual risk remains. Usually, very few risks can be completely mitigated. Tasks to mitigate risks are reflected in the (IMS) and the time-phased budget for the mitigation is also reflected in the PMB.
(4) Accept the risk. The last remaining risk management strategy is to accept the risk. In some case, the risk poses a threat to the project objectives, but has a lesser risk ranking based on the impact and probability. The project manager and project team may choose to not actively manage this type of risk and thereby accept the risk consequences. The risk consequences are not worth the resources that may be required to mitigate it.
However, in some situations, there may not be a means to use any other risk management strategy, and, at times, this strategy is employed when other risk management strategies may prove too costly or are impractical. In these situations, we plan that should the risk event occur, a contingency plan is invoked. The contingency plan will address the risk if and when it actually occurs or if the horizon date for invoking the plan takes place. Should the risk not materialize, then the contingency plan is not invoked. As funds are needed to address the threat (or to exploit opportunities), the funds are drawn down from the contingency reserve budget. If the risk does not materialize, the funds remain in the contingency reserve budget.
Contingency plans and the funds needed to execute the contingency plans have not been consistently addressed for the most part and in some cases ignored in the EVM literature and practice. In many EVM texts, the budgets for contingency plans and contingency reserves either are not given separate consideration or are dealt with in the same manner as management reserve.
In the remaining sections, we discuss how the contingency budget is treated relative to the PMB.
E.4 Risk Throughout the Project Life Cycle
The integrated process diagram shown below in Figure E2 was developed by the (USA) National Defense Industrial Association Program Management Systems Committee's Risk Management Working Group (RMWG)1, and subsequently published in the NDIA PMSC's EVMS Application Guide.2 This diagram can also be found in Chapter 18 of the (USA) Government Accountability Office (GAO) Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Capital Program Costs. The RMWG was a joint Industry/Customer team established to explore the integration of RM with EVM. The group's charter was to engage customer and supplier communities in the identification, collection, and sharing of requirements and processes necessary to integrate RM and EVM; the group subsequently published a white paper that established a business case for RM/EVM integration. The integrated process diagram depicts the risk management and EVM processes, the process interfaces, and the data that are shared between them to enable better planning, forecasting and decision making throughout a program's life cycle. There are multiple process interfaces and key data elements are shared to enable process integration; the arrows on the diagram depict the direction of the data flow from one process to another.
E.5 Establishing Project Reserves—Contingency Reserves (CR) and Management Reserves (MR)
Project reserves in this practice standard include both CR and MR. The distinction of these two reserves is described herein. An important distinction is that CR resides within the PMB and MR does not.
As a project is planned, both contingency reserves (to deal with identified risks that cannot be avoided, transferred, or mitigated and instead are accepted) and management reserves (to deal with uncertainties that cannot be quantified or specified) are included in the plan. An emerging practice is to include contingency reserves as a component of the PMB. It is suggested that contingency reserves are placed either within undistributed budget (UB) or a separate contingency reserve within the PMB. In order to maintain visibility of the overall risk profile of the project, it is also suggested these contingency reserves, not be allocated immediately to the control accounts, and instead reside in UB.
Management reserve, since its use is set aside for work that was neither foreseen nor defined in advance, is above the PMB. Contrast this with contingency plans that are crafted to deal with specific (and quantified) risks. Since specific plans have been developed, these plans can be incorporated into the appropriate control account. However, the funds to execute the plan are held in UB until either the risk or the risk trigger occurs. If this happens and the contingency plan is invoked, then funds are drawn down from the UB. It would also be acceptable to formulate a separate fund that is above the control account level and a component of the PMB called contingency reserve. For purposes of this appendix, we will only address UB, since UB is a recognized category traditionally included as a component of the PMB.
E.6 Contingency Reserves as a Component of Undistributed Budget
In many cases, particularly for large and very large projects, it is impractical to budget for each and every contingency. By the very nature of risk, it is unknown if the risk event will materialize. It is almost certain that some of the contingency plans will not be invoked and no contingency budget applied. The most common method of planning for contingencies is to sum the risk exposure for each of the risks with a contingency plan.
It is proposed that, for the budget, contingency execution reside in undistributed budget (UB). In this way, if the risk does not materialize, the budget for contingencies remain in UB until a risk does surface that results in a drawdown of the contingency budget. The earned value methodology is applicable because the contingency plan budget and tasks to deal with the prospective risk has been estimated prior to the execution of the contingency plan. Just as we do for any other components of a control account, we assess the planned time-phased estimate for the contingency plan versus the actual costs to execute the plan. Therefore, the integrity of the PMB is maintained. Since UB is a component of the PMB, no modification to the PMB is needed for application of the contingency reserve, unlike MR application, which would cause a revision to the PMB. Since a risk can be anticipated and a contingency plan developed, it is difficult to argue that the contingency was unanticipated, unlike the rationale for a management reserve budget.
When a risk does not materialize, those tasks are removed from the control account and not executed, and the contingency budget that resides in UB is never accessed. The contingency plan is not executed and the budgeted amount for the contingency is not allocated to the control account.
It is entirely foreseeable that at some future point, EVM and risk management will progress so that EVM recognizes a separate category for contingency reserve that is part of the PMB but not yet incorporated into the control accounts, and is sitting at the same level as UB. However, until that occurs, the recommendation put forward is that contingency reserve is similar enough in concept to UB to include the contingency reserve in that category.
Figure E3 represents how the contingency reserve budget can be estimated for a risk. By aggregating the overall risk exposure for the total risks, we develop the contingency budget based on a percent of likely occurrence for any one risk. It would not be realistic to include in the contingency reserve an amount equal to the aggregate cost anticipated for all risks, should all materialize. Since the work associated with the contingency is known and the budget for invoking a contingency plan can be estimated, it would seem to differ drastically from the definition of management reserve, that is, unanticipated work that is within scope.
E.7 Integrated Baseline Review
E.7.1 Goals and Objectives of the Integrated Baseline Review (IBR)
An integrated baseline review (IBR) is an examination of the PMB encompassing the entire technical scope of the project. The IBR validates that the work is realistically and accurately scheduled, and that the proper amount and mix of resources (not the least of which is the budget allocated) have been assigned to accomplish all the project requirements. In this context, the IBR can, in and of itself, be viewed as a risk mitigation tool, mitigating the risks to the project objectives created by an unrealistic baseline that cannot be executed according to plan.
While this alone makes the IBR an indispensible and powerful tool, the IBR process also functions as a forum to identify project risks that may not otherwise have been identified.
The IBR concept and application of the process is a best practice that can be utilized to improve the prospects of achieving successful outcomes for all projects.
E.7.2 Goals of the IBR
The IBR seeks to develop an open and honest dialogue between the parties involved in the project, typically having a customer–vendor relationship.
Through this frank dialogue, both parties are able to examine the baseline and conclude that it is realistic and achievable or identify issues that must be addressed to ensure that the PMB it represents is achievable, provided that the baseline conforms to these stipulations. Because of this, in some circumstances, it may be desirable to conduct an IBR prior to awarding a contract. In assessing the validity of the baseline, control accounts (CA) are examined, along with the basis for estimating budget, resources, and schedule within the various CAs. During the IBR, the proposed earned value methods for determining progress toward completion of the CA will also be reviewed and agreed upon by both parties.
E.7.3 Objectives of the IBR
The IBR usually will encompass the entire project scope, although for certain very large, complex, multi-year projects, it may be decided beforehand to review an arbitrary percentage of the project scope (e.g., 90%). A review of the schedule will examine task sequencing and ensure that milestones and deliverables are organized in a logical and consistent manner. The manner by which progress is determined in the CA will be discussed to ensure that reports will reflect the progress achieved accurately. This focus is on the proper management controls to make the evaluation relative to the baseline.
In the course of conducting the IBR, certain risks will be identified which may impact the project objectives. Sometimes the risk takes the form of an opportunity which may produce a tangible benefit, although most risks will be in the form of obstacles to achieving a successful outcome. Other PMI publications focus on risk and risk management methods, and we will not duplicate those efforts in this practice standard. Technical solutions may also present risks, and the technical approach is also subject to review and discussion. This may result in the identification of risks not previously identified.
E.7.4 IBR Benefits
The IBR is perhaps the one activity that can be undertaken after the project is underway, which can lead to improving the prospects of the successful outcomes of the project, and lays the foundation for enabling a mutual understanding of the project risks. The customer and vendor in a contractual relationship each will benefit by understanding the other's perspective and expectations for the project. A properly conducted IBR will result in all aspects of the project management plan being understood and the PMB assessed for execution and performance. Resource needs are identified and accounted for in the project management plan. This serves to increase the confidence level of both parties in the validity of the PMB.
Known project risks are identified, and plans are reviewed for managing risks. Both parties understand the management approach for the project from their respective roles. The metrics and data that will be provided are agreed upon, and will serve as an early warning mechanism if the project strays off course.
After the IBR is completed, the project can move forward with the management by exception approach advocated by EVM, which provides improved traceability and focus.
E.7.5 The IBR Process
The IBR should be conducted in a cooperative, non-adversarial manner, between the customer and vendor for the purpose of validating the PMB. Where an organization has in-house projects, the IBR occurs between the project sponsor and the project team designated to execute the project.
When validating the PMB, the schedule, resources assigned, budget allocated, and other elements of the project management plan are reviewed. The intent is to determine if the project, as defined by the PMB, is realistic and executable.
The IBR is usually conducted after award of a contract. The IBR should be conducted as soon as the contractor has developed the PMB. At times, it may be advantageous for the customer to conduct an IBR prior to the contract award. In this scenario, the customer would narrow the competitive range to no more than, say, three vendors, using the other selection criteria. Then the IBR would be performed among those vendors remaining to select the best proposal.
E.7.6 Conducting the IBR
When conducting the IBR, the following activities are undertaken:
(1) Define the scope and schedule of the IBR
(2) Identify the appropriate team members to participate in the IBR
(3) Review the appropriate EVMS documentation
(4) Conduct training for the IBR team (both the customer and vendor)
(5) Document results from the IBR
(6) Identify risks and issues
E.7.7 Closeout of the IBR
Upon completion of the IBR, both parties should determine if the purpose of the IBR has been achieved. Has a mutual understanding been attained by both parties? For identified risks, has a risk management strategy been developed? Has the party or individual been designated that takes responsibility for the risk? Have new risks identified during the IBR been added to the risk register?
After the IBR closeout, the focus shifts to monitoring the actual project performance against the PMB. Deviations from the PMB could result in risks that require immediate management attention. Other project management functions such as appropriately updating the schedule, providing estimates to complete, ongoing risk management, need to occur. Failure to perform these and other essential project management functions may in and of themselves create new risks impacting attainment of the project objectives.
E.7.8 Treatment of New Risks Identified During the IBR
When new risks are identified during the IBR, the risk management strategy is identified for each risk. Implementing the risk management strategy can result in a modification of the proposed PMB to account for mitigation, avoidance, and transfer strategies. This may lead to revisions in the proposed budget and the proposed project schedule. When the risk management strategy is to accept the risk and develop a contingency plan, this plan is incorporated into the project schedule. The contingency plan should result in a revision of the contingency reserve identified for the project.
Once all risks that are identified in the IBR are accounted for in the PMB, the parties may then validate the revised PMB.
E.7.9 Risk Areas
In the IBR, the risks associated with cost, schedule, technical approach, resources, and management controls should be examined. More often than not, the IBR will lead to the identification of new risks. These risks would follow the same process of quantification based on probability and impact, adding the risk to the risk register, and determining an appropriate risk management strategy. If this strategy results in new risk management tasks that need to occur, these tasks should be added to the schedule and an appropriate budget associated with the risk management strategy identified.
E.7.10 What the IBR is Not
Sometimes it is helpful in defining an activity to tell you what an activity is not. An IBR is:
(1) Not an audit
(2) Not a process review (not A CMMI assessment)
(3) Not a graded event/test—No pass or fail
(4) Not a chang3e of scope
(5) Not an EVMS compliance review
(6) Not a vendor marketing opportunity for services or presentations
(7) Not a basis for criticism
1 Defense Acquisition University (U.S. Government) web site (https://acc.dau.mil/CommunityBrowser.aspx?id=17609&lang=en-US)
2 NDIA Program Managers’ Guide to the Integrated Baseline Review