The objective of a well-managed risk management program is to provide a repeatable process for balancing cost, schedule, and performance goals within program funding.  This is especially true on programs with designs that approach or exceed the state-of-the-art or have tightly constrained or optimistic cost, schedule, and performance goals. Without effective risk management the Program Management Office (PMO) may find itself doing crisis management, a resource-intensive process that is typically constrained by a restricted set of available options. Successful risk management depends on the knowledge gleaned from assessments of all aspects of the program coupled with appropriate mitigations applied to the specific root causes and consequences. [1]

A key concept here is that the government shares the risk with the development, production, or support contractor (if commercial support is chosen), and does not transfer all risks to the contractor. The PMO always has a responsibility to the system user to develop a capable and supportable system and cannot absolve itself of that responsibility. Therefore, all program risks, whether primarily managed by the program office or by the development/support contractor, are of concern and must be assessed and managed by the program office. Once the program office has determined which risks and how much of each risk to share with the contractor, it must then assess the total risk assumed by the developing contractor (including subcontractors). The PMO and the developer must work from a common risk management process and database. Successful mitigation requires that government and the contractor communicate all program risks for mutual adjudication. Both parties may not always agree on risk likelihoods, and the government Program Manager (PM) maintains ultimate approval authority for risk definition and assignment. A common risk database available and open to the government and the contractor is an extremely valuable tool. Risk Mitigation involves selection of the option that best provides the balance between performance and cost. Recall that schedule slips generally and directly impact cost. It is also possible that throughout the system life cycle there may be a need for different near-term and long-term mitigation approaches. [1]

An effective risk management process requires a commitment on the part of the PM, the PMO and the contractor to be successful. Many impediments exist to risk management implementation, however, the program team must work together to overcome these obstacles. One good example is the natural reluctance to identify real program risks early for fear of jeopardizing support of the program by decision makers. Another example is the lack of sufficient funds to properly implement the risk mitigation process. However, when properly resourced and implemented, the risk management process supports setting and achieving realistic cost, schedule, and performance objectives and provides early identification of risks for special attention and mitigation. [1]

PMs have a wide range of supporting data and processes to help them integrate and balance programmatic constraints against risk. The Acquisition Program Baseline (APB) for each program defines the top-level cost, schedule, and technical performance parameters for that program. Additionally, acquisition planning documents such as Life-Cycle Cost Estimates (LCCE), Systems Engineering Plans (SEP), Integrated Master Schedule (IMS), Integrated Master Plans (IMP), Test and Evaluation Master Plans (TEMP) and Technology Readiness Assessment (TRA) provide detailed cost, schedule, and technical performance measures for program management efforts. Since effective risk management requires a stable and recognized baseline from which to access, mitigate, and manage program risk it is critical that the program use an IMP/IMS. Processes managed by the contractor, such as the IMP, contractor IMS, and Earned Value Management (EVM), provide the PM with additional insight into balancing program requirements and constraints against cost, schedule, or technical risk. [1]

AcqLinks and References:

Updated: 7/29/2017

Print Friendly, PDF & Email