Table Of Content

Acquisition Review Quarterly — Spring 2003 124 Report Documentation Page Form Approved OMB No. 0704-0188 Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 2. REPORT TYPE 3. DATES COVERED 2003 N/A - 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER Managing Risk in A Program Office Environment 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER Bill /Shepherd 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION Defense Acquisition University Alumni Association 2550 Huntington Ave, REPORT NUMBER Suite 202 Alexandria, VA 22303 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) 11. SPONSOR/MONITOR’S REPORT NUMBER(S) 12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release, distribution unlimited 13. SUPPLEMENTARY NOTES 14. ABSTRACT 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF ABSTRACT OF PAGES RESPONSIBLE PERSON a. REPORT b. ABSTRACT c. THIS PAGE UU 16 unclassified unclassified unclassified Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18 Managing Risk in aT UPTroOgRraImAL Office Environment MANAGING RISK IN A PROGRAM OFFICE ENVIRONMENT Bill Shepherd, PMP People in program offices make decisions every day. Sometimes the alternatives are clear with unambiguous outcomes, but more often the options are less certain and have far-reaching, unintended consequences. An effective risk management program can provide program managers with the information they need to make smart decisions in the face of this uncertainty. Although the techniques for risk management are well documented and not technically difficult, a variety of factors make them hard to implement effectively. This article describes what risk management is, identifies some of the typical challenges, and provides specific examples and recommendations on how to implement an effective risk management program. T he techniques for risk management 1. It seldom seems urgent. It deals — are well documented and not tech- or should deal — with events far nically difficult. Reference material enough in the future that there is suf- is readily available and can be found in ficient time to influence the situa- the Defense Acquisition University tion or develop alternatives. Unfor- (DAU) Risk Management Guide, Project tunately, less important daily pres- Management Institute’s Guide to the sures often get more attention. Project Management Body of Knowl- edge®, and the DAU Acquisition Reform 2. It does require careful thought. Office Risk Management Community of People have to understand the dis- Practice. The Defense Acquisition Uni- tinction between risks, which have versity has taught risk management and a degree of uncertainty associated published training material on the sub- with them, and issues, which are ject for years. If it is not difficult and realities to be managed. The devil widely documented, then why is it so is in the details and these details hard? must be clearly communicated to Three things make effective risk man- isolate the uncertainty and under- agement hard. stand its impact. Understanding the true situation will allow teams to 125 Acquisition Review Quarterly — Spring 2003 focus on solving the right problem available in the workforce and those and develop far more effective miti- needed to support fielded technology are gation plans. always moving out of alignment. 3. It requires common understanding Threats, which drive requirements, are and commitment from everyone on constantly changing. The end item may the team. This means that risk man- be obsolete by the time it is fielded unless agement must be part of the organi- legacy migration and technology insertion zational culture, with strong support are built into the program. from senior management and in- Statutory and regulatory requirements formed participation by the entire and their implementing instructions are team. Creating that common vision constantly changing. Industry standards and institutionalizing the processes and best practices are constantly evolving. takes training, an investment in re- The use of new technology means his- sources, and occasional reinforce- torical experience is less accurate in pre- ment. dicting areas in which problems may occur. Training and experience may be- come dated as new technology becomes WHY ARE ACQUISITION PROJECTS available. “RISKY”? Legacy systems often require skills that are part of the tacit knowledge gained over Acquisition programs are risky because the years by a maturing workforce. As they occur in an environment of constant these workers retire or move on to sec- change. As illustrated in Figure 1, the skills ond careers, this knowledge needs to be Figure 1. Aligning Personnel Skills to Technology Requirements 126 Managing Risk in a Program Office Environment passed on. Workforce planning is a stra- terminology used in this article. The la- tegic mitigation factor for risk. bels selected are not critical and even the Interfaces with other efforts upon which references listed above are not consis- the project depends can have a critical tent in their terminology. What is impor- impact on the project’s ability to deliver tant is that the team understands the pro- successfully. There is always the risk that cess so they can implement it effectively. a funding reduction in one program will have unintended consequences in another. The addition of interoperability as a Key DEFINITIONS Performance Parameter (KPP) in the Op- erational Requirements Document (ORD) Definitions make clear communication and the requirement for a Command, Con- and common understanding possible. To trol, Communications, Computers, and In- identify the risks that require the most telligence Support Plan (C4ISP) at mile- attention, the team needs an objective stone decision points are two efforts standard against which to subjectively targeted at mitigating this risk. assess both probability and impact. In the absence of an objective standard, indi- viduals will make their own value judg- THE RISK MANAGEMENT PROCESS ments, which are tough to defend and can lead to misunderstandings. The tasks required to perform risk There is no single correct set of defini- management can be grouped and labeled tions, but the ones below are targeted in a variety of ways. Figure 2 shows the directly toward the problem of managing Define Identify Monitor and Control Mitigate Analyze Figure 2. Risk Management Tasks 127 Acquisition Review Quarterly — Spring 2003 risk in a program office and therefore PROBABILITY worth considering. People can usually agree on a subjec- tive probability within the bands shown RISK in Figure 3. The break points used are Risk exists when, in a given situation, one-half, one-third, and one-tenth; prob- there is both an event with a chance of abilities to which most people can relate occurring and one or more possible out- to based on experience with coins, dice, comes of that occurrence that will have or playing cards. A key point to note is an impact on the program. There are sev- that the assessment is made using “ex- eral key words in this definition that will isting processes, infrastructure, and gov- be addressed later. ernance.” Changes in those areas can be used to mitigate the risk. RISK MANAGEMENT Risk management is an organized, IMPACT systematic process that efficiently iden- Impact. If a risk event actually occurs, tifies risks, prioritizes them, develops and the result may affect cost, schedule, tech- documents contingency plans and miti- nical performance, or a combination of gation strategies, and provides decision- the three. These are the typical areas of makers with the necessary information risk impact but there may be others such at the appropriate time to make sound as security or political concerns. decisions. Existing Processes, Infrastructure Probabilty and Governance Very High …will not avoid the risk event and there is no Near (>90%) 5 known alternative. (Less than 10% chance it Certainty will not happen.) High …will not avoid the risk event, but an alternative Highly (67%-90%) 4 may be available. (Less than 1/3 chance it will not Likely happen.) Medium 3 …may avoid this risk and an alternative may be Likely (34%-66%) available. (About a 50% chance it will happen.) Low 2 …typically avoid this type of risk with minimal Unlikely (11%-33%) oversight in similar cases. (Less than 1/3 chance it will happen.) Very Low 1 … will effectively avoid or mitigate this risk. Remote (<10%) (Less than 10% chance it will happen.) Figure 3. Assessing Risk Probability 128 Managing Risk in a Program Office Environment Once the areas of impact have been relationship between the minimum accept- identified, the different levels of impact able, desired, and allocated or planned result. have to be quantified in each of these areas. This quantification should be linked to COMMUNICATING THE PROCESS objective criteria whenever possible, es- The entire team has to understand and pecially if specific thresholds and participate in the risk management process objectives are provided. This can be for it to be effective. This requires both initial accomplished using KPP thresholds and training and periodic reinforcement especially objectives contained in the ORD, and key when changes in personnel occur. Manag- milestone dates. Figure 4 shows an ex- ing risk in different phases of the program ample of how this linkage can occur. The may require different skills and focus. De- figure also demonstrates how program risk pictions of the process, definitions, and stan- tolerance can be considered in setting the dards for assessing probability and impact, impact levels. should be kept simple and provided to each Risk tolerance is a measure of the level member of the team. Since most people usu- of risk a program is willing to accept. Fig- ally only think about the details of risk man- ure 5 shows the result for a program with agement when they decide to nominate a Low risk tolerance. A similar approach can risk, this guidance should be something that be applied to cost, schedule, or any other is easily referenced. Figure 6 shows a impact area in which there is a “three-tier” Risk Impact Risk Tolerance: Low High Allocation – Meets objective with satisfactory margin, but short of allocation or design goal 1 – Meets objective with small margin, but well below allocation or design goal 1 2 Objective – Meets threshold with satisfactory margin, but just short of objective 2 3 – Meets threshold with small margin, but well below objective 3 4 Threshold – Just short of threshold 4 5 – Significantly below threshold 5 Threshold – Minimal acceptable performance the user will accept. Will not use system if it does not meet this performance level. Objective – Level of performance desired by the user. Allocation – Performance assigned to a component or end item as part of the system engineering process. Usually supports achievement of objective performance criteria. Figure 4. Linking Impact Assessments to Objective Criteria 129 Acquisition Review Quarterly — Spring 2003 Security/ Functional Political/ Severity Cost Schedule Performance Programmatic Unacceptable 5 >20% deviation from Cannot meet APB Significant shortfall to planned budget milestone or key threshold requirement program milestone Critical 4 15%-20% deviation Major slip (over 4 Nearly meets threshold from planned budget months) or within requirement 2 months of APB milestone Significant 3 10%-15% deviation Slip less than 4 Meets threshold with from planned budget months in key small margin, but is milestones well short of objective Marginal 2 <10% deviation from Slip from planned Meets threshold with planned budget schedule of less significant margin, but than 1 month is just short of objective Minimal 1 Minimal deviation from Minimal schedule Will not cause a failure planned budget impact to meet objective, but short of design allocation Threshold – Minimal acceptable performance the user will accept. Will not use system if it does not meet this performance level. Objective – Level of performance desired by the user. Allocation – Performance assigned to a component or end item as part of the system engineering process. Usually supports achievement of objective performance criteria. Figure 5. Assessing Risk Impact simple risk management process de- made by the team, and consider the impact scription. This can be combined with the to the program if the assumptions prove to probability and impact descriptions in be false. If the combination of probability Figure 3 and Figure 5 to provide a ready and impact exceeds the level of comfort reference for the team. Many programs for the leadership, then it warrants being create laminated handouts as bookmarks tracked as a risk. or that are sized for binders or wallets. WORK AND ORGANIZATIONAL BREAKDOWN STRUCTURE (WBS AND OBS) IDENTIFYING RISKS — WHERE TO LOOK The project Work Breakdown and Organizational Breakdown Structures ASSUMPTIONS (WBS and OBS) are useful guides for iden- The first place to look for risk is in the tifying risk. assumptions. Any formal program brief The WBS should include all activities should identify the key assumptions being and deliverables within scope of the project, 130 Managing Risk in a Program Office Environment DEFINITIONS: (cid:127) Risk: An uncertain (usually future) event with a definable impact on Define the program. (cid:127) Standard definitions (cid:127) Risk Management: A systematic, organized process to efficiently (cid:127) Processes identify, analyze, mitigate, and track risks. It includes both minimizing (cid:127) Team Training the impact of unfavorable events and maximizing the benefit of favorable events. (cid:127) Mitigation Options: Reduce the probability that the risk event may occur, reduce the impact if it does, or increase the probability of more Identify acceptable outcomes. (cid:127) Situation (cid:127) Contingency: Accept that the risk event may occur and prepare to (cid:127) Uncertainty absorb the impact if it does. (cid:127) Impact (cid:127) Tasks RISK NOMINATION: (cid:127) Situation – Describe the facts that create the situation in which the risk event may occur. (cid:127) Uncertainty – What is the uncertain event of concern? If it is a single Analyze event, when will it occur? If it is an ongoing activity, how will we know it (cid:127) Probability happened? How likely is it to occur? (cid:127) Impact (cid:127) Impact – If the risk event occurs, how will that impact the program? If (cid:127) Outcomes there is more than one possible outcome, assess the probability and impact for each case. (cid:127) Tasks to Mitigate – What actions should be taken to mitigate the risk or to develop contingency plans? Mitigate RISK MANAGEMENT BOARD DECISIONS: (cid:127) Absorb (cid:127) Accept – Formally track and assign action to develop mitigation plan. (cid:127) Deflect (cid:127) Defer (cid:127) Accept and Escalate – Formally track, assign action to develop (cid:127) Alternatives mitigation strategy, and refer to senior management due to scope of impact or potential mitigation costs. (cid:127) Reject (Handle as Issue) – No uncertainty exists or there is insufficient time to mitigate. Refer the issue to appropriate level of Monitor management for action. (cid:127) Maintain history (cid:127) Reject (Need more Information) – Unable to determine if risk exists (cid:127) Monitor plans or requires formal monitoring. Assign action to develop more (cid:127) Monthly updates information. (cid:127) Reject – Does not require formal Risk Management Board attention. Figure 6. Risk Management Process so it is a good tool to ensure that all Meetings are a good time to ask “What portions of the program are considered. is going to keep us from being success- The OBS defines the functional dis- ful on the project?” ciplines involved. This represents a significant corporate knowledge base that RISK BREAKDOWN STRUCTURE (RBS) can identify where the problems typically The concept of using a Risk Break- occur in a given area of expertise. Team down Structure (RBS) has been proposed meetings or Technical Interchange by David Hillson (2002) to provide a 131 Acquisition Review Quarterly — Spring 2003 hierarchical breakdown of the sources of RISK CLASSIFICATION risk. He cites several potential uses for an A nominal classification of Low, Med- RBS, including using it to provide a struc- ium, or High may be useful for a snapshot ture for conducting risk assessments. The of risk status on a program, but it does not top two levels of the RBS can serve as a provide enough information to allocate prompt list to structure a risk brainstorming resources. Placing risks in a risk matrix session, while lower levels can be used as a based on the assessment of probability and checklist to help ensure that all areas of risk impact shows their relative importance (or- are addressed. This is similar in concept to dinal ranking), but this still does not quan- using an Ishikawa or Fishbone diagram as tify the dollarized impact to the program a brainstorming tool to classify and charac- or justify a level of risk funding. Figure 7 terize risks. Any tool or construct that can shows a sample risk matrix. To fully un- help the team conduct a complete assess- derstand the risk exposure of a program, ment of program risk is helpful. the cost of both the impact and the mitigation options needs to be assessed. How- ever, these assessments cost time and RISK ANALYSIS money and should be reserved for those risks with the greatest perceived combina- Risks need to be analyzed to verify tion of probability and impact. the assessment of probability and impact, and determine their relative priority. Pro- WHAT IS EXPECTED VALUE AND gram managers need to know where to apply limited resources to mitigate the WHY SHOULD I CARE? most risk, and the cost of implementing A useful concept is the “Expected mitigation strategies can be considerable. Value” of a risk, which is the product of <Date> foe ycn tlibaerru bc oc rPO Impact Figure 7. Sample Risk Matrix 132