Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
51 6.1 Introduction This chapter presents guidance for risk management in the programming phase. The programming phase is defined in terms of its relevance to cost estimating and risk manage- ment. Each of the risk management steps is discussed in de- tail, including inputs, outputs, and tools used in the risk man- agement process. Tips for tool application and how project complexity impacts risk management tools and practices are also discussed for each step. 6.1.1 Programming Phase Overview The programming phase focuses on converting the highest priority needs identified in the SHAâs long-range plan into spe- cific projects. This decision point marks the beginning of the project development process as individual projects are identi- fied for definition, design, and construction letting. The time period, from project definition in programming to letting the project for construction, is typically between five and 10 years. This time duration between programming and construction letting is a function of project complexity and criticality. SHA policies and practices also influence this time duration. Programming often marks the beginning of a project spe- cific effort. Federal law requires that the transportation im- provement program (TIP) for a metropolitan area become part of the stateâs transportation improvement program (STIP). It is common for state SHAs and MPOs to work closely identifying the likely costs associated with candidate projects. Programming is often referred to as the project âdefinition or scoping phase.â The primary goal of programming is to create a baseline scope, cost, and schedule for the project. Once this baseline is approved, the project is included in an authorized priority program. The priority program includes projects that are typically within 10 years or less from their anticipated letting date. The first four years of the priority program is usually the STIP. The priority program is the out- put from the programming phase of project development. Once projects are including in a priority program, the SHA must manage project scope, cost, and time as development continues during the design phase. The duration of time be- tween when a project is included in the priority program and finally goes to construction letting varies across SHAs. Some SHAs program projects nine or 10 years before their expected construction letting date. Other SHAs only program a proj- ect when the project is ready to be included in the STIP. In the latter case, the STIP becomes the priority program. During the programming phase, a project baseline cost es- timate is prepared. This cost estimate becomes the basis for managing project costs during the design phase. The risk management process is tied to cost estimating through the risk identification, risk assessment and analysis, and risk mitiga- tion and planning when preparing the baseline cost estimate. 6.1.2 Programming Phase Risk Management Emphasis Risk management practices during the programming phase focus on comprehensive risk identification, detailed risk as- sessment and analysis, and risk mitigation and planning. The key output of the programming phase in terms of cost esti- mating and cost management is the baseline cost estimate. Recalling from Chapters 2 and 3, the baseline cost estimate is comprised of the base estimate and a contingency estimate. As shown by shading in Figure 6.1, these three primary risk management steps serve as the basis for estimating the con- tingency that must be included in the baseline cost estimate. Once risks are comprehensively identified and assessed/ analyzed with regard to their potential impact and probability of occurrence, a justifiable contingency can be estimated. A detailed risk management plan will then be prepared and used C H A P T E R 6 Guide to the Programming Phase
for managing risks related to the baseline scope, cost, and time. This risk management plan is incorporated into the ap- proved project scope, budget and schedule. A risk manage- ment plan becomes the basis for risk mitigation, monitoring, and control during project development. Although risk allocation and risk monitoring and control are not the focuses of the programming phase, they should be considered with a lower level of effort. Higher level risk allo- cation decisions are made during the programming phases. These decisions typically involve the choice of project deliv- ery method (e.g., design-bid-build, design-build, etc.), but do not involve detailed risk allocation (e.g., contract provisions involving time, management of traffic, etc.). Risk monitoring and control approaches are planned, but they are not utilized until after the baseline cost and schedule estimates have been set at the end of the programming phase. The remainder of this Chapter describes tools and manage- ment practices suggested for use during the programming phase of project development. A discussion of how project complexity impacts risk management tools and practices is also provided. 6.2 Programming Phase Risk Identification Risk identification is paramount to successful risk manage- ment and contingency estimation at the programming phase. The objectives of risk identification are: 1) to identify and cat- egorize risks that could affect the project; and 2) to document these risks. The outcome of the risk identification is a list of risks. Ideally, the list of risks should be comprehensive and non-overlapping. This list of risks can be the basis for estimat- ing project contingency and setting the baseline cost estimate. The risk identification process should generally stop short of assessing or analyzing risks so as not to inhibit the identi- fication of minor risks. This identification process should promote creative thinking and leverage team member expe- rience and knowledge. Perhaps the most challenging aspect of risk identification is in defining issues at an appropriate level of detail. Issues de- fined too vaguely or lumped into gross generalizations are hard to assess. Defining too many separate, detailed risks can lead to overlapping among issues or the omission of larger issues (i.e., âmissing the forest for the treesâ problem). To the extent pos- sible, define risks to be independent of each other, thereby eliminating overlap among risks through their descriptions. Risk checklists and lists of risks from similar projects can be helpful, but use them only as a back check at the end of the risk identification process. Review these lists only at the end of the process as a means of ensuring that the list is not ex- cluding any common risks. Avoid beginning the process with the risk checklists or similar project analyses as the team may overlook unique project risks or include too many risks in the analysis, and this will make the process less useful. 6.2.1 Programming Phase Risk Identification Inputs The project scope generated in the programming process and the related base estimate package comprise the key inputs for risk identification. The determination of project risk stems from a review of the design assumptions made by the design team and the estimating assumptions made by the project estimator. The design team must make initial conceptual de- sign assumptions that they will refine as the design progresses. Likewise, the estimator must make estimating assumptions in a programming level estimate because complete design infor- mation is not yet available. Design and estimating assump- tions serve as triggers for risk identification when creating a contingency estimate. The risk identification process should begin with a review of any risks identified during the planning phase. However, the risks identified during planning will likely have changed substantially by the programming phase. Risk identification at the programming phase must be rigorous. It is helpful to go through a new risk identification exercise at the program- ming phase and then use the planning phase risk identifica- tion outputs only as a check at the end of the process to en- sure that no risks were overlooked. 6.2.2 Programming Phase Risk Identification Tools Risk identification tools that can be used in the program- ming phase are listed in Table 6.1. Note that complex projects 52 Risk Management Process Allocate Monitor and Control Identify Assess/ Analyze Mitigate and Plan Figure 6.1. Risk management focus in the programming phase.
can use all risk identification tools. Refer to Appendix A for complete tool descriptions. 6.2.3 Programming Phase Risk Identification Outputs The key risk identification output is a list of risks. Risk identification can be initiated in the planning phase, espe- cially where the plan identifies critical environmental re- sources or sensitive areas. A discussion of environmental mit- igation activities is required in the current metropolitan and statewide planning regulations [see 23 CFR 450.214(j) and 23 CFR 450.322(f)(7)] and as the MPOs and states further re- fine their plans under current requirements, this sort of infor- mation should become more readily available. The planning regulations also require that transportation plans be com- pared against conservation plans and/or maps or inventories of natural resource or historic resources, providing another opportunity for identifying risk in the planning process [see 23 CFR 450.214(i) and 23 CFR 450.322(g)]. On minor projects, the list of risks may take the form of a Red Flag Item list (I2.1). On some minor project, and all mod- erately complex and major projects, the list of risks should form the basis of a Risk Management Plan (R3.1) and Risk Register (R3.12) for later risk management and control. Cat- egorization of the risk list can be extremely helpful to ensure that no risks have been missed. Categorization of risks can be accomplished through a review of Risk Checklists (I2.3). On major projects, categorization can be achieved through the application of Risk Breakdown Structure (R3.11). Ideally, the list of risks should be comprehensive and nonoverlapping. This list of risks can be the basis for estimat- ing project contingency and setting the baseline cost estimate. Comprehensive and nonoverlapping lists of risks are required for detailed risk and contingency modeling in the later steps. 6.2.4 Programming Phase Risk Identification Relationship to Project Complexity On minor projects, the number of inputs to the risk identi- fication step can be small. An estimator or project manager may individually conduct the risk identification or with a small group. Information comes from preliminary estimates, preliminary schedules, the estimatorsâ judgment, scoping doc- uments, design assumptions, and other sources. Minor proj- ect risk identification tools may include only a Red Flag List (I2.1). However, consultation with experts (Expert Interviews, I2.5) can be a good idea if time and budget permits. The use of Risk Checklists (I2.3) is suggested at the end of the identifi- cation process to ensure that no risks have escaped detection. Moderately complex projects will require risk identification from a greater number of sources. Expert Interviews (I2.5) will be a key input on moderately complex projects. Formal Assumptions Analysis (I2.4) is typically warranted. A Risk Register (R3.12) should always be employed and a Risk Man- agement Plan (R3.1) can be warranted on moderately complex projects with a high level of uncertainty. Major projects require the highest level of risk identifica- tion. All risk identification tools are applicable to major proj- ects. The Risk Workshop (R3.6) is the principal tool employed on major projects that is not typically applied to moderately complex or minor projects. Formal Risk Workshops (R3.6) are typically facilitated by a professional risk analysis and can have upwards of 20 experts participating depending upon the specific project needs. The time to plan, conduct, and docu- ment the workshop should not be underestimated. The ben- efits of a workshop include a comprehensive list of risks and a firm basis for risk analysis and planning. 6.2.5 Programming Phase Risk Identification Tips The use of appropriate risk identification techniques must be instituted during programming. â¢ Risk identification should be a creative brainstorming process. It should not attempt to analyze risks or discuss mitigation procedures, which will be completed in the sub- sequent steps. â¢ At a minimum, risk information should include assump- tions, estimate basis uncertainties, and project issues and concerns from the estimator, project team, and any partic- ipating specialty groups. 53 Table 6.1. Programming phase risk identification tools. Tool M in or M od er at el y C om pl ex M ajo r I2.1 Red Flag Items I2.3 Risk Checklists I2.4 Assumption Analysis I2.5 Expert Interviews I2.6 Crawford Slip Method I2.7 SWOT Analysis R3.1 Risk Management Plan R3.6 Risk Workshop R3.11 Risk Breakdown Structure R3.12 Risk Register
â¢ The resultant risk list should be comprehensive and nonoverlapping to be most useful in later risk analyses. Combine like risks. Separate overlapping risks. â¢ Use risk checklists and experience from similar projects only to check for missing risks and to help categorize unique project risks. â¢ Upon completion of the risk list, categorize the risk into logical groupings. Use risk checklists and similar project risk analyses for possible categorizations. 6.3 Programming Phase Risk Assessment and Analysis Because the baseline estimate is set in the programming phase, risk assessment and analysis is generally more compre- hensive and time consuming in programming than in any other project development phase. The primary objective of risk assessment is the systematic consideration of risk events focusing on their probability of occurrence and the conse- quences of such occurrences. Risk assessment and analysis is the process of evaluating the risk events documented in the preceding identification step. Risk assessment and analysis has two aspects. The first determines the probability of a risk oc- curring (risk frequency); risks are classified along a continuum from very unlikely to very likely. The second aspect judges the impact of the risk should it occur (consequence severity). Typically, a projectâs qualitative risk assessment will recog- nize some risks whose occurrence is so likely or whose conse- quences are so serious that further quantitative risk analysis is warranted. A key purpose of quantitative risk analysis is to combine the effects of the various identified and assessed risk events into an overall project risk analysis. The overall risk analysis is used to determine cost and schedule contingency values and to quantify individual impacts of high risk events. Ultimately however, the purpose of quantitative analysis is to not only compute numerical risk values but to provide a basis for controlling project costs through effective risk manage- ment practices. 6.3.1 Programming Phase Risk Assessment and Analysis Inputs The physical input to risk assessment and analysis is the list of risks from the identification step. In the programming phase, this will likely be a long list that must be filtered through the assessment and analysis step to help focus the project team on a subset of the most critical risks. The risk identification step will have identified risks, but the identification step should stop short of assessment or analysis. In the risk assessment and analysis step, risk inputs will be elicited from project managers, functional experts, estimators, and analysts to gain a clear picture of the risks. Managers and functional experts tend toward qualitative as- sessment of risks. They evaluate risks relative to their worst case effects and their relative likelihood of occurrence. Ana- lysts and estimators tend toward quantitative assessment of risks. They evaluate risk impacts in terms of a range of tangi- ble results and they evaluate risk of occurrence in terms of probabilities. The analystâs focus is on the combined tangible effect of all the risks on project scope, cost, and schedule. A comprehensive risk strategy combines both a qualitative as- sessment and a quantitative analysis. Recalling from Chapter 3, the key inputs for risk assess- ment and analysis are the probability of a risk occurring (risk frequency) and the impact of the risk should it occur (conse- quence severity). Knowing the probability and impact, risks can be qualitatively ranked to help managers focus on the most critical risks or quantitatively modeled to determine cost and schedule contingency estimates. 6.3.2 Programming Phase Risk Assessment and Analysis Tools Risk assessment and analysis tools that can be used in the programming phase are listed in Table 6.2. Note that project complexity has a significant impact on the use of risk assess- 54 Table 6.2. Programming phase risk assessment and analysis tools. Tool M in or M od er at el y C om pl ex M ajo r I2.5 Expert Interviews R3.2 ContingencyâPercentage R3.3 ContingencyâIdentified R3.4 Estimate Ranges â Three Point Estimate R3.5 Estimate Ranges â Monte Carlo Analysis R3.6 Risk Workshop R3.7 Risk Priority Ranking R3.8 Probability x Impact Matrix (P x I) R3.9 Risk Comparison Table R3.10 Risk Map R3.13 Risk Management Information System R3.14 Self Modeling Worksheet
ment and analysis tools. Refer to Appendix A for complete tool descriptions. 6.3.3 Programming Phase Risk Assessment and Analysis Outputs Risk assessment and analysis outputs will depend on the type of decision required, the detail in the input analysis, and the level of rigor in the selected tools for assessment or analy- sis. The use of qualitative expert input (I2.5 Expert Inter- views) and the application of a Risk Priority Ranking (R3.7), Probability x Impact Matrix (P x I) (R3.8), or Risk Compar- ison Table (R3.9) tools will yield a ranked set of risks that can help focus management on managing the highest priority risks. The use of quantitative expert inputs and application of a Estimate Ranges â Monte Carlo Analysis (R3.5) tool will yield a definitive contingency estimate and detailed sensitiv- ity analysis of the risks that contribute to the contingency. Recalling Chapter 3, Section 22.214.171.124, the type of outputs that a tool produces is a function of the analytical rigor, na- ture of assumptions, or amount of input data. Results from risk analyses may be divided into three groups according to their primary output: 1) single parameter output measures; 2) multiple parameter output measures; and 3) complete dis- tribution output measures. Please refer to Sections 3.4.3 and 3.4.5 for a full description of risk assessment and analysis outputs. 6.3.4 Programming Phase Risk Assessment and Analysis Relationship to Project Complexity Risk assessment and analysis are directly tied to project com- plexity. This can best be seen in the tie between risk analysis and contingency calculation. The research team has observed numerous methods for analyzing risks and developing con- tingency estimates. These methods fall into three categories (Type I, II, and III Risk Analysis), which directly relate to proj- ect complexity (minor, moderately complex, and major). Type I Risk Analysis â Risk Identification and Percentage Contingency A Type I risk analysis is the simplest form of risk analysis and applies only to minor projects. A Type I risk analysis in- volves the development Red Flag Items (I2.1) and the use of a ContingencyâPercentage (R3.2) tool to estimate the con- tingency. To estimate contingency, the estimator should ex- amine the list of risks and use judgment within percentage contingency range of acceptable standards set by the agency policies or estimating guidance. Type II â Qualitative Risk Analysis and Identified Contingency Items A Type II risk analysis applies to moderately complex proj- ects and involves more rigorous risk assessment and tools [e.g., P x I Matrix (R3.8), Risk Comparison Table (R3.9), etc.] and the estimate of specific contingency items using the ContingencyâIdentified (R3.3) tool that complements the percentage-based contingency in the Type I analysis. A qual- itative ranking of the risks and expected values estimates for contingency on the critical risks are key outputs of this method. When estimating an appropriate contingency in a Type II risk analysis, the range of contingency from the Con- tingencyâPercentage (R3.2) tool is first consulted. The next step is to review approximately the top 20 percent of the pri- oritized risks to ensure that the contingency is adequate. An expected value estimate for estimating the top-ranked risks can be calculated by multiplying the product of the impact should the risk occur by the probability of the occurrence (e.g., $1,000,000 x 0.50 = $500,000). Contingency in addition to the predetermined percentage can be included if warranted by the expected value analysis. Type III â Quantitative Risk Analysis and Contingency Management A Type III risk analysis applies to major projects. This method is generally facilitated by risk analysts who are experts in the area of quantitative risk management practices. The process most often begins with a Risk Workshop (R3.6) and generates a stochastic estimate of cost and schedule through a Estimate Range â Monte Carlo Analysis (R3.5). The result- ing risk-based range estimate is then updated throughout project development. In all cases, the list of risks should be related to the contin- gency amount. In a Type I analysis, the tie between the risks and contingency is loose, but the list of risks can justify the need for the contingency estimate to both internal and exter- nal stakeholders. In the Type III analysis, the tie is direct as the list of risks forms the basis for the stochastic model that drives the contingency estimate. 6.3.5 Programming Phase Risk Assessment and Analysis Tips There must be a clear understanding of risk significance and a description of what the contingency amount (included in a cost estimate) covers in terms of project risks. â¢ The goal of risk assessment is not to eliminate all risk from the project. Rather, the goal is to recognize the sig- nificant risk challenges to the project and to initiate an 55
appropriate management response to their management and mitigation. â¢ All projects, regardless of project size and project complex- ity, will require some form of risk assessment and analysis. The framework of risk assessment and analysis remains the same, but the tools and level of effort vary with project complexity and the decisions that need to be made. â¢ A comparison of each riskâs probability and impact yields a relative ranking of the risks that can be used for risk man- agement or, if warranted by project complexity, a detailed quantitative risk analysis using probabilistic models to generate ranges of possible outcomes. â¢ Recalling from Chapter 3, there are five criteria that can be applied to help select risk assessment and analysis tools. The selected method or tool will involve a trade-off be- tween sophistication of the analysis and its ease of use. â The tool should help determine project cost and sched- ule contingency. â The tool should have the ability to include the explicit knowledge of the project team members concerning the site, the design, the political conditions, and the project approach. â The tool should allow quick response to changing mar- ket factors, price levels, and contractual risk allocation. â The tool should help foster clear communication among the project team members and between the team and higher management about project uncertainties and their impacts. â The tool, or at least its output, should be easy to use and understand. â¢ The risk analysis process can be complex due to the com- plexity of the modeling required and the subjective nature of the data available to conduct the analysis. However, the complexity of the process is not overwhelming and the generated information is extremely valuable. 6.4 Programming Phase Risk Mitigation and Planning Risk mitigation and planning efforts at the programming phase are the foundation for risk management throughout the remainder of the project development. The objectives are to explore risk response strategies for the high-risk items identified in the qualitative risk assessment or quantitative risk analysis. The process identifies and assigns parties to take responsibility for each risk response. It ensures that each risk requiring a response has an owner. The key output is the risk register or risk management plan. 6.4.1 Programming Phase Risk Mitigation and Planning Inputs The ranked list of risks from the first two risk management steps is the key input to the mitigation and planning effort. Risks mitigation and planning begins by developing and doc- umenting a risk management strategy focused on the key risks. Early efforts â¢ Establish the purpose and objective; â¢ Assign responsibilities for specific areas; â¢ Identify additional technical expertise needed; â¢ Describe the assessment process and areas to consider; â¢ Delineate procedures for consideration of mitigation and allocation options; â¢ Dictate the reporting and documentation needs; and â¢ Establish report requirements and monitoring metrics. This planning should address evaluation of the capabilities of potential sources as well as early industry involvement. The list of risks is used as the basis for the solicitation of mitigation and planning options from key managers and ex- perts. The mitigation and planning options will require cost- benefit analyses (e.g., the cost of implementing a mitigation effort versus the reduction in probability or impact to a risk) to assess the viability or impact of the options. Estimators and risk analysts will therefore have key input into the mitigation and planning process. The project management staff will have the final input into the risk mitigation and planning efforts. They will determine who âownsâ the risk and is responsible for ensuring that it is managed effectively. The risk management plan and/or risk register should clearly identify who is responsible for manag- ing and resolving each individual risk. 6.4.2 Programming Phase Risk Mitigation and Planning Tools Risk mitigation and planning tools that can be used in the Programming Phase are listed in Table 6.3. Refer to Appen- dix A for complete tool descriptions. 56 Tool M in or M od er at el y C om pl ex M ajo r I2.1 Red Flag Items R3.1 Risk Management Plan R3.5 Estimate RangesâMonte Carlo Analysis R3.6 Risk Workshops R3.11 Risk Breakdown Structure R3.12 Risk Register R3.13 Risk Management Information System Table 6.3. Programming phase risk mitigation and planning tools.
6.4.3 Programming Phase Risk Mitigation and Planning Outputs The outputs of the risk mitigation and planning step are an organized, comprehensive, and interactive risk management strategy and a plan for adequate resources. The Risk Manage- ment Plan (R3.1) tool in Appendix A provides a good example of this output from Caltrans. The example risk management plan from Caltrans describes a clear approach to the assign- ment of responsibility. It also provides items that require re- source investment and a method for calculating their costs. Risk mitigation and planning is iterative and includes de- scribing and scheduling the activities and processes to assess (identify and analyze), mitigate, monitor, and document the risk associated with a project. For minor or moderately com- plex projects, the result should be a Risk Register (R3.12). For major projects or moderately complex projects with a high degree of uncertainty, the result should be a formal Risk Management Plan (R3.1). 6.4.4 Programming Phase Risk Mitigation and Planning Relationship to Project Complexity The risk mitigation and planning effort should be congruent with project complexity. Each risk plan should be documented, but the degree of documentation will vary with project com- plexity. Not all projects will require a comprehensive and quan- titative risk management process. The simplest minor projects may only require a Red Flag Items (I2.1) tool to manage the most important risks. The list can be reviewed at key project milestones to ensure that the key risks are being managed. The creation of a Risk Register (R3.12) is a more formal identification of risks than the simple Red Flag Items (I2.1). A risk register is highly recommended for all projects; it pro- vides project managers with a listing of significant risks and includes information about the cost and schedule impacts of each risk. It supports the contingency resolution process by tracking changes as a result of actual cost and schedule risk impacts, as the project progresses through the development process and the risks are resolved. The level of detail in the register will vary with project com- plexity. Registers can be applied to minor projects and the ef- fort to create and maintain them can be relatively minimal. All moderately complex projects should use a register; it cre- ates a concise tool to manage the risks and the individuals as- signed to each risk. Major projects or moderately complex projects with high levels of uncertainty will benefit from hav- ing a detailed and formal Risk Management Plan (R3.1) that records all aspects of risk identification; risk assessment; risk analysis; risk planning; risk allocation; and risk information systems, documentation, and reports. Major projects should use a register that is integrated into the formal Risk Manage- ment Plan (R3.1). 6.4.5 Programming Phase Risk Mitigation and Planning Tips Project cost is subject to many variables but actions to mit- igate the impacts of risks can have a significant effect in con- trolling cost. â¢ Begin risk planning efforts early. Formal risk management plans can begin concurrently with risk identification and analysis steps. â¢ Clearly assign responsibility for risk ownership. Individ- uals responsible for managing risks should be informed on the costs of mitigation efforts and which risks must be resolved. â¢ When planning for risk responses, keep in mind the com- mon strategies of avoidance, transference, mitigation, or acceptance. â¢ Risk mitigation and planning efforts may necessitate that agencies set policies, procedures, goals, and responsibility standards. â¢ Document the risk mitigation and planning efforts at a level of detail appropriate for the project complexity and resources available to management. 6.5 Programming Phase Risk Allocation The goal of risk allocation is to minimize the total cost of risk on a project, not necessarily the costs to each party separately. Risk allocation begins in the Programming Phase with the project delivery decision. The identified project risks should align with the selected project delivery method to provide an optimal allocation of risk to minimize the total cost or meet other project objectives. The traditional design-bid-build de- livery system is most commonly used by SHAs and its risk allocation tenets are well understood in the industry. However, alternatives to the traditional delivery method exist. Design- build, construction management at risk, and publicâprivate partnerships are among the alternative delivery options that can benefit from innovative risk allocation opportunities. 6.5.1 Programming Phase Risk Allocation Inputs Risk allocation inputs at the Programming Phase include the outputs from the first three steps in the risk management process plus an examination of the available/allowable proj- ect delivery options for the project. The decision makers who will determine the project delivery method should be aware of the most critical risks that could impact project delivery performance. For example, if the design-build delivery method is being considered to save time, the decision makers should review all identified risks concerning schedule and examine 57
how these risks would be allocated in the design-build proj- ect delivery method. The decision makers will need to know what delivery methods are available under state laws or agency policies and then determine how the risks can be allocated optically under the method. 6.5.2 Programming Phase Risk Allocation Tools Table 6.4 lists Programming Phase tools discussed in this Guidebook for risk allocation. The Delivery Decision Support (D1.2) tool includes descriptions of numerous alternative project delivery methods. 6.5.3 Programming Phase Risk Allocation Outputs The likely output of the risk allocation step at the Program- ming Phase will be a final project delivery decision and plan for developing a contract packaging strategy. However, the output will vary with the nature of the project. At the highest level of detail, a project delivery decision report can be generated that analyzes risk allocation in terms of project characteristics (e.g., cost, schedule, and quality issues); agency characteristics (e.g., available staffing level, staff experience, etc.); market character- istics (e.g., market availability, market experience, etc.); and stakeholder characteristics. Detailed risk allocation decisions may be discussed in this phase, but when the contract method is finalized the allocation will be set in the design phase. 6.5.4 Programming Phase Risk Allocation Relationship to Project Complexity Minor projects tend toward the use of traditional delivery and contract packaging strategies. Typically, risk allocation in minor projects requires only a cursory review of the risks to en- sure that they are allocated properly in the contracts. Moder- ately complex and major projects require careful consideration of both delivery and contract packaging techniques. Alterna- tive delivery methods should be explored on moderately com- plex projects and are becoming common for major projects. 6.5.5 Programming Phase Risk Allocation Tips Risk allocation affects the amount of contingency that must be included in a project estimate. â¢ Explore alternatives to traditional risk allocation tech- niques in both delivery and contract packaging strategies. â¢ Gain industry input concerning risk allocation whenever possible. â¢ Follow the four fundamental tenets of sound risk allocation: â Allocate risks to the party best able manage them. â Allocate the risk in alignment with project goals. â Share risk when appropriate to accomplish project goals. â Ultimately seek to allocate risks to promote team align- ment with customer-oriented performance goals. 6.6 Programming Phase Risk Monitoring and Control The objectives of risk monitoring and control are to 1) sys- tematically track the identified risks; 2) identify any new risks; 3) effectively manage the contingency reserve; and 4) capture lessons learned for future risk assessment and allocation ef- forts. The strategy for risk monitoring and control is devel- oped in the Programming Phase, but it is not implemented in earnest until the Design Phase. Therefore, only a concise de- scription of risk monitoring and control is presented in this section. 6.6.1 Risk Monitoring and Control Inputs The key inputs to risk monitoring and control are the Risk Management Plan (R3.1) and Risk Register (R3.12). These tools provide a framework for managing risks through a for- malized monitoring and control process. On moderately complex and major projects with a high degree of uncer- tainty, an agency may invest in a Risk Management Informa- tion System (R3.13) to better monitor and control impacts. 6.6.2 Programming Phase Risk Monitoring and Control Tools Table 6.5 lists the risk monitoring and control tools sug- gested for the Programming Phase. More information on the tools can be found in Appendix A. 6.6.3 Programming Phase Risk Monitoring and Control Outputs The key output for risk monitoring and control in the Programming Phase is a formal strategy or plan that will 58 Table 6.4. Programming phase risk allocation tools. Tool M in or M od er at el y C om pl ex M ajo r D1.1 Contract Packaging D1.2 Delivery Decision Support
support monitoring and control in the Design Phase. The monitoring and control strategy is typically described in the risk management plan. The monitoring and control strategy should define how the risk management process will be supported by: â¢ Providing consistent and comprehensive reporting proce- dures; â¢ Developing a set of key milestones for risk resolution; â¢ Monitoring changes to risk probabilities or impacts; â¢ Supporting active contingency resolution procedures; and â¢ Providing feedback of analysis and mitigation for future risk assessment and allocation. Perhaps the most important output of the Programming Phase risk monitoring and control step is a list of key mile- stones for when risks will be resolved. This information can be used to create a ârisk resolution scheduleâ to assist in the monitoring and control process. Key milestones will include dates when more information will be known about a given risk or dates when a risk must be resolved or allocated into the contract. 6.6.4 Programming Phase Risk Monitoring and Control Relationship to Project Complexity Only the simplest minor projects will use a Red Flag Item (I2.1) list for risk monitoring and control. A Risk Register (R3.12) is suggested for all projects. Risk registers can be tailored to project size and complexity so that they do not require undue effort for monitoring and control. Risk Management Plans (R3.1) and Risk Management Information Systems (R3.13) can assist in monitoring and control of moderately complex and major projects with a large amount of uncertainty. 6.6.5 Programming Phase Risk Monitoring and Control Tips Risk monitoring and control should be a continuous and repetitive activity during all phases of project development. â¢ For each project, develop a unique risk monitoring and control process that is appropriate for the size and com- plexity of the project. Do not create monitoring and control processes that are burdensome or create undue paperwork. â¢ A successful risk monitoring and updating process will sys- tematically track risks, support the identification of new risks, and effectively manage the contingency reserve. 6.7 Conclusions This chapter discussed guidance for risk management in the Programming Phase. The programming phase focuses efforts on risk identification, risk assessment and analysis, and risk mitigation and planning. Risk allocation and risk monitoring and control in the Programming Phase primarily address planning for these steps in the Design Phase. For each of the risk management steps, a discussion of inputs, outputs, and tools was provided. Tips for application and how project com- plexity impacts risk management tools and practices were dis- cussed for each step. The outcome of this discussion is a map to the risk management tools provided in Appendix A. 59 Table 6.5. Programming phase risk monitoring and control tools. Tool M in or M od er at el y C om pl ex M ajo r I2.1 Red Flag Items R3.1 Risk Management Plan R3.12 Risk Register R3.13 Risk Management Information System