Dyman Associates Risk Management Approach and Plan

Dyman Associates Risk Management – As a management process, risk management is used to identify and avoid the potential cost, schedule, and performance/technical risks to a system, take a proactive and structured approach to manage negative outcomes, respond to them if they occur, and identify potential opportunities that may be hidden in the situation [4]. The risk management approach and plan operationalize these management goals.

Because no two projects are exactly alike, the risk management approach and plan should be tailored to the scope and complexity of individual projects. Other considerations include the roles, responsibilities, and size of the project team, the risk management processes required or recommended by the government organization, and the risk management tools available to the project.

Risk occurs across the spectrum of government and its various enterprises, systems-of-systems, and individual systems. At the system level, the risk focus typically centers on development. Risk exists in operations, requirements, design, development, integration, testing, training, fielding, etc. (see the SE Life-Cycle Building Blocks section of this Guide). For systems-of-systems, the dependency risks rise to the top. Working consistency across the system-of-systems, synchronizing capability development and fielding, considering whether to interface, interoperate, or integrate, and the risks associated with these paths all come to the forefront in the system-of-systems environment. At the enterprise level, governance and complexity risks become more prominent. Governance risk of different guidance across the enterprise for the benefit of the enterprise will trickle down into the system-of-systems and individual systems, resulting in potentially unanticipated demands and perhaps suboptimal solutions at the low level that may be beneficial at the enterprise level. Dealing with the unknowns increases and the risks associated with these——techniques in the Guide's section on Enterprise Engineering, such as loose couplings, federated architectures, and portfolio management——can help the MITRE SE alleviate these risks.

Risk Management in System-Level Programs

System-level risk management is predominantly the responsibility of the team working to provide capabilities for a particular development effort. Within a system-level risk area, the primary responsibility falls to the system program manager and SE for working risk management, and the developers and integrators for helping identify and create approaches to reduce risk. In addition, a key responsibility is with the user community's decision maker onwhen to accept residual risk after it and its consequences have been identified. The articles in the Risk Management topic area provide guidance for identifying risk (Risk Identification), mitigating risks at the system level with options like control, transfer, and watch (Risk Mitigation Planning, Implementation, and Progress Monitoring), and a program risk assessment scale and matrix (Risk Impact Assessment and Prioritization). These guidelines, together with MITRE SEs using tools such as those identified in the Risk Management Tools article, will help the program team deal with risk management and provide realism to the development and implementation of capabilities for the users.

Risk Management in System-of-Systems Programs

Today, the body of literature on engineering risk management is largely aimed at addressing traditional engineering system projects—those systems designed and engineered against a set of well-defined user requirements, specifications, and technical standards. In contrast, little exists on how risk management principles apply to a system whose functionality and performance is governed by the interaction of a set of highly interconnected, yet independent, cooperating systems. Such systems may be referred to as systems-of-systems.

A system-of-systems can be thought of as a set or arrangement of systems that are related or interconnected to provide a given capability that, otherwise, would not be possible. The loss of any part of the supporting systems degrades or, in some cases, eliminates the performance or capabilities of the whole.

What makes risk management in the engineering of systems-of-systems more challenging than managing risk in a traditional system engineering project? The basic risk management process steps are the same. The challenge comes from implementing and managing the process steps across a large-scale, complex, system-of-systems—one whose subordinate systems, managers, and stakeholders may be geographically dispersed, organizationally distributed, and may not have fully intersecting user needs.

How does the delivery of capability over time affect how risks are managed in a system-of-systems? The difficulty is in aligning or mapping identified risks to capabilities planned to be delivered within a specified build by a specified time. Here, it is critically important that risk impact assessments are made as a function of which capabilities are affected, when these effects occur, and their impacts on users and stakeholders.

Lack of clearly defined system boundaries, management lines of responsibility, and accountability further challenge the management of risk in the engineering of systems-of-systems. User and stakeholder acceptance of risk management, and their participation in the process, is essential for success.

Given the above, a program needs to establish an environment where the reporting of risks and their potential consequences is encouraged and rewarded. Without this, there will be an incomplete picture of risk. Risks that threaten the successful engineering of a system-of-systems may become evident only when it is too late to effectively manage or mitigate them.

Frequently a system-of-systems is planned and engineered to deliver capabilities through a series of evolutionary builds. Risks can originate from different sources and threaten the system-of-systems at different times during their evolution. These risks and their sources should be mapped to the capabilities they potentially affect, according to their planned delivery date. Assessments should be made of each risk's potential impacts to planned capabilities, and whether they have collateral effects on dependent capabilities or technologies.

In most cases, the overall system-of-systems risk is not just a linear "roll-up" of its subordinate system-level risks. Rather, it is a combination of specific lower level individual system risks that, when put together, have the potential to adversely impact the system-of-systems in ways that do not equate to a simple roll-up of the system-level risks. The result is that some risks will be important to the individual systems and be managed at that level, while others will warrant the attention of system-of-systems engineering and management.

Read full Article