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 thesetechniques in the Guide's section on Enterprise Engineering, such as loose
couplings, federated architectures, and portfolio managementcan 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 projectsthose 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-systemsone 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.

Risk Management in Enterprise Engineering Programs

Risk management of enterprise systems poses an even greater challenge than risk management in
systems-of-systems programs.

Enterprise environments (e.g., the Internet) offer users ubiquitous, cross-boundary access to wide
varieties of services, applications, and information repositories. Enterprise systems engineering is an
emerging discipline. It encompasses and extends "traditional" systems engineering to create and evolve
"webs" of systems and systems-of-systems that operate in a network-centric way to deliver capabilities
via services, data, and applications through an interconnected network of information and
communications technologies. This is an environment in which systems engineering at its "water's-
edge."

In an enterprise, risk management is viewed as the integration of people, processes, and tools that
together ensure the early and continuous identification and resolution of enterprise risks. The goal is to
provide decision makers an enterprise-wide understanding of risks, their potential consequences,
interdependencies, and rippling effects within and beyond enterprise "boundaries." Ultimately risk
management aims to establish and maintain a holistic view of risks across the enterprise, so capabilities
and performance objectives are achieved via risk-informed resource and investment decisions.

Today we are in the early stage of understanding how systems engineering, engineering management,
and social science methods weave together to create systems that "live" and "evolve" in enterprise
environments.

Requirements for Getting Risk Management Started

Senior leadership commitment and participation is required.
Stakeholder commitment and participation is required.
Risk management is made a program-wide priority and "enforced" as such throughout the
program's life-cycle.
Technical and program management disciplines are represented and engaged. Both program
management and engineering specialties need to be communicating risk information and
progress toward mitigation. Program management needs to identify contracting, funding
concerns, SEs need to engage across the team and identify risks, costs, and potential
ramifications, if the risk were to occur, as well as mitigation plans (actions to reduce the risk,
and cost/resources needed to execute successfully).
Risk management integrated into the program's business processes and systems engineering
plans. Examples include risk status included in management meetings and/or program reviews,
risk mitigation plan actions tracked in schedules, and cost estimates reflective of risk exposure.
The Risk Management Plan

The Risk Management Plan describes a process, such as the fundamental steps shown in Figure 1, that
are intended to enable the engineering of a system that is accomplished within cost, delivered on time,
and meets user needs.

Figure 1. Fundamental Steps of Risk Management

Best Practices and Lessons Learned
In supporting both Department of Defense (DoD) and civilian agency projects and programs, MITRE SEs
have found the following minimum conditions needed to initiate and continuously execute risk
management successfully. With these, the program increases its chance of identifying risks early so the
goals and objectives are achieved [5].

Twenty-One "Musts"

1. Risk management must be a priority for leadership and throughout the program's management
levels. Maintain leadership priority and open communication. Teams will not identify risks if
they do not perceive an open environment to share risk information (messenger not shot) or
management priority on wanting to know risk information (requested at program reviews and
meetings), or if they do not feel the information will be used to support management decisions
(lip service, information not informative, team members will not waste their time if the
information is not used).
2. Risk management must never be delegated to staff that lack authority.
3. A formal and repeatable risk management process must be presentone that is balanced in
complexity and data needs, such that meaningful and actionable insights are produced with
minimum burden.
4. The management culture must encourage and reward identifying risk by staff at all levels of
program contribution.
5. Program leadership must have the ability to regularly and quickly engage subject matter
experts.
6. Risk management must be formally integrated into program management
7. Participants must be trained in the program's specific risk management practices and
procedures.
8. A risk management plan must be written with its practices and procedures consistent with
process training.
9. Risk management execution must be shared among all stakeholders.
10. Risks must be identified, assessed, and reviewed continuouslynot just prior to major reviews.
11. Risk considerations must be a central focus of program reviews.
12. Risk management working groups and review boards must be rescheduled when conflicts arise
with other program needs.
13. Risk mitigation plans must be developed, success criteria defined, and their implementation
monitored relative to achieving success criteria outcomes.
14. Risks must be assigned only to staff with authority to implement mitigation actions and obligate
resources.
15. Risk management must never be outsourced.
16. Risks that extend beyond traditional impact dimensions of cost, schedule, and technical
performance must be considered (e.g., programmatic, enterprise, cross-program/cross-
portfolio, and social, political, economic impacts).
17. Technology maturity and its future readiness must be understood.
18. The adaptability of a program's technology to change in operational environments must be
understood.
19. Risks must be written clearly using the Condition-If-Then protocol.
20. The nature and needs of the program must drive the design of the risk management process
within which a risk management tool/database conforms.
21. Risk management tool/database must be maintained with current risk status information;
preferably, employ a tool/database that rapidly produces "dashboard-like" status reports for
management.

It is important for MITRE SEs as well as project and program leaders to keep these minimum conditions
in mind with each taking action appropriate for their roles. In particular, the SE should provide effective
support as follows:

Get top-level buy-in. MITRE SEs can help gain senior leadership support for risk management by
highlighting some of the engineering as well as programmatic risks. MITRE SEs should prepare
assessments of the impact that risks could manifest and back them by facts and data (e.g.,
increased schedule due to more development, increased costs, increased user training for
unique, technology edge capabilities, and potential of risk that capabilities will not be used
because they do not interoperate with legacy systems). MITRE SEs can highlight the various risk
areas, present the pros and cons of alternative courses of mitigation actions (and their impacts),
and help the decision makers determine the actual discriminators and residual impact to taking
one action or another. In addition to data-driven technical assessments, success in getting top-
level buy-in requires consideration of political, organizational/operational, and economic factors
as seen through the eyes of the senior leadership. Refer to [6] for foundational information on
the art of persuasion.
Get stakeholder trust. Gain the trust of stakeholders by clearly basing risk reduction or
acceptance recommendations on getting mission capabilities to users.
Leverage your peers. Someone at MITRE generally knows a lot about every risk management
topic imaginable. This includes technical, operational, programmatic dimensions of risks and
mitigations. Bringing the company to bear is more that a sloganit is a technique to use, as risks
are determined, particularly in system-of-systems and enterprise. In all likelihood, MITRE is
working other parts of these large problems.
Think horizontal. Emphasize cross-program or cross-organization participation in risk
identification, assessment, and management. Cross-team coordination and communication can
be particularly useful in risk management. All 'ilities' (e.g., information assurance, security,
logistics, software) should be represented in the risk reviews. Communication of risk
information helps illuminate risks that have impact across organizations and amplifies the
benefits of mitigations that are shared.
Stay savvy in risk management processes and tools. Become the knowledgeable advisor in
available risk management processes and tools. Many government organizations have program
management offices that have defined risk management processes, templates, and tools. These
should be used as a starting point to develop the specific approach and plan for an individual
project or program. Make sure the government sponsors or customers have the current
information about the risk management approach and plan required by their organizations, and
assist them in complying with it. Assist the sponsors or customers in determining the minimum
set of activities for their particular program that will produce an effective risk management
approach and plan.