What are risks?
Risks are potential future events or conditions that may have a negative effect on achieving program objectives for cost, schedule, and performance. They are defined by:
The undesired event and/or condition The probability of an undesired event or condition occurring The consequences, or impact, of the undesired event, should it occur
Program Risk Management
The most important decisions to control risk are made early in a program life cycle. During the early phases, the program works with the requirements community to help shape the product concept and requirements. PMs and teams should understand the capabilities under development and perform a detailed analysis to identify the key risks. Where necessary, prioritizing requirements and making trade-offs should be accomplished to meet affordability objectives. Once the concept and requirements are in place, the team determines the basic program structure, the acquisition strategy and which acquisition phase to enter, based on the type and level of key risks.
You are watching: To minimize software development risk select a contractor who
Defense programs encounter risks and issues that should be anticipated and addressed on a continuing basis. Risk and issue management are closely related and use similar processes. Opportunity management is complementary to risk management and helps achieve should-cost objectives. Risks, Issues and Opportunities may be in areas including, but not limited to, technology, integration, quality, manufacturing, logistics, requirements, software, test and reliability. DoDI 5000.85, 3C.3.d. Risk Management requires the Program Manager (PM) to present top program risks and associated risk mitigation plans at all relevant decision points and milestones. DoDI 5000.85, 3C.3.d. Risk Management also specifies risk management techniques the PM is required to consider when developing the acquisition strategy. Technical risk management is addressed in DoDI 5000.88, 3.4.f. Risk, Issue and Opportunity Management
Technical, programmatic and business events can develop into risks, issues or opportunities, each with cost, schedule or performance consequences as shown below.
Statute requires PMs to document a comprehensive approach for managing and mitigating risk (including technical, cost and schedule risk) in the Acquisition Strategy (AS) for major defense acquisition programs and major systems. Per statute, the approach for major defense acquisition programs and major systems must identify the major sources of risk for each phase and must include consideration of risk mitigation techniques such as prototyping, modeling and simulation, technology demonstration and decision points, multiple design approaches and other considerations (P.L. 114-92 (SEC. 822 paras (a) and (b))).
In support of 10 U.S.C. 2448a, in 2017 Congress required the Department to conduct Independent Technical Risk Assessments (ITRAs) on Major Defense Acquisition Programs in advance of milestone and production decisions. ITRAs provide senior leaders with an independent view of program technical risk, including the maturity of critical technologies and manufacturing processes.
The Deputy Director, Engineering, team conducts ITRAs on Acquisition Category (ACAT) ID programs for USD(R&E) approval and maintains the policy and guidance for ITRAs. The Services or Agencies will conduct ITRAs on ACAT IB/IC programs with the approval authority determined by USD(R&E). When USD(R&E) determines it should approve an ACAT IB/IC program ITRA, the Engineering team works with the Service to process that assessment for USD(R&E) approval.
DoD ITRA policy is contained in DoDI 5000.88, 3.5.b. ITRA. For more on planning, conducting, and reporting the results of ITRAs, please visit the DD, Engineering, ITRA web site.
The program’s risk profile is the dominant consideration in deciding which contract type to pursue. The type of contract, cost-plus or fixed-price, fundamentally will affect the roles and actions of the government and industry in managing risk. Cost-plus contracts are best suited to situations in which the inherent technical risks are greater (typically during development). Fixed-price development is most appropriate when the requirements are stable and expected to remain unchanged, where technical and technology risks are understood and minimal and the contractor has demonstrated a capability to perform work of the type required.
Role of the Systems Engineer
Systems engineers support the PM in executing a risk management program. The systems engineer’s primary concern is with technical risks, issues and opportunities. Programs are required to summarize the risk management approach and planning activities in the Systems Engineering Plan. The systems engineer should assess and describe cost and schedule implications of risks, issues and opportunities at technical reviews. Risk mitigation activities should be reflected in the program’s Integrated Master Schedule and Integrated Master Plan.
Role of the Program Manager
The PM establishes and typically chairs the government Risk Management Board (RMB) as a senior group supporting risk management. The RMB usually includes the individuals who represent the various functionalities of the program office, such as program control, the chief engineer, logistics, test, systems engineering, contracting officer as warranted, a user representative and others depending on the agenda.
The PM may document the risk management process in more detail in a Program Risk Process (PRP), formerly known as Risk Management Plan (RMP) — a best practice. While the processes support risk management, the risk mitigation plans, which focus on risk reduction for individual risks (i.e., the output of the processes), are significantly more important. As a best practice, the programs may combine their Risk, Issue and Opportunity plans in a combined (RIO) document. A good PRP should:
Explain the risk management working structure. Define an approach to identify, analyze, mitigate, and monitor risks, issues and opportunities across the program. Document the process to request and allocate resources (personnel, schedule and budget) to mitigate risks and issues. Define the means to monitor the effectiveness of the risk management process. Document the processes as they apply to contractors, subcontractors and teammates.
Separate from the PRP, as a best practice, the government and contractor should utilize a common or electronically compatible tool(s) to collectively identify, analyze, mitigate and monitor the program’s risks, issues and opportunities. An example of a tool is the Risk Register. Other context for risk identification and management can be found in DAG CH 3–4.3. Design Considerations. Two specific examples of risk context are Environment, Safety and Occupational Health (ESOH) and cybersecurity. DAG CH 3–4.3.9 addresses ESOH and contains information regarding ESOH-related risk management. DAG CH 3–4.3.24 addresses System Security Engineering and contains information on the Risk Management Framework for DoD Information Technology. The associated DoDI 8510.01 establishes processes for ensuring confidentiality, integrity and availability for DoD Information Technology programs. Programs should consider these specialized risk processes when creating their program risk process.
For additional information on managing risks, issues and opportunities, see the Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs available on the DD, Engineering web site.
Risk Management Process
The Risk Management process encompasses five significant activities: planning, identification, analysis, mitigation and monitoring. PMs are encouraged to apply the fundamentals of the activities presented here to improve the management of their programs.