Risk Management

Risk management is integral to effective program management and systems engineering in both Agile development and traditional programs. Programs adopting Agile software development practices generally manage risk in the same way as traditional DoD programs, but face different levels and sources of risk. They still require a rigorous process to regularly identify, assess, mitigate, and track risks. Programs must actively manage risks by integrating mitigation strategies into acquisition strategies and key program processes throughout the program lifecycle. Agile enables some unique risk management aspects and mitigations.

Programs should establish a risk management process during the Materiel Solution Analysis phase and include the process in their acquisition strategy. Risks are identified as a critical element of the AoA and related technical analysis. The program office, functional sponsors, and other key stakeholders should collaboratively identify, assess, and develop mitigation strategies for program risks. A diverse set of contributors will ensure identification of risks across all functional areas, support a common understanding/assessment, and garner support for selected mitigation strategies. Risk assessments aid in the selection of an alternative, acquisition and contract strategies, and are presented at Milestone A. Successful programs designate a risk lead(s) who is accountable for continually identifying, assessing, managing, and communicating risks to program stakeholders while establishing risk management processes.

Within an Agile environment, managing risk is an integral part of release and sprint planning and development. The Agile process itself has built many features into the development process to manage risk; for example, decomposing development into small releases and sprints usually reduces performance expectation risk and may reduce overall program cost and schedule risks. Estimates for smaller efforts (e.g., 6-month releases) tend to have a higher fidelity than those for entire programs or increments (e.g., 5–10 years), and over time the estimates improve as sprints and releases generate valuable data. Frequent software deliveries of high-priority user capabilities and responsiveness to changes often mitigate the risk of user dissatisfaction. Incorporating mature technology and designs in shorter releases and sprints helps to manage technical risks. Program failures in releases and sprints are smaller and therefore have less overall impact; they also provide valuable lessons for future developments.

Agile development reduces overall program risk because the program regularly delivers some degree of useful capability in each release. Thus, even if a program’s budget is cut or eliminated along, in most cases deployed releases provide users with some level of fielded capability. Furthermore, Agile development focuses on users’ highest priority capabilities first; thus users need not wait 5–10 years to receive critical capabilities. Capability demonstrations to users at the end of each sprint reduce the risk that the final product will fail to meet users’ expectations, since users can provide ongoing feedback on deployed capabilities to inform and shape future releases. Lastly, short development timelines provide a steady pipeline to infuse mature technologies effectively into the system and enterprise.

An Agile environment does not reduce all risks, as coordinating and integrating many smaller developments involves increased complexity. Similarly, as more development teams are involved, possibly including multiple contractors, integration risks increase. Success depends on an effective program manager and chief engineer, working with enterprise architects and stakeholders, who can effectively design and implement solutions.

Programs also run risks when transitioning and adapting to an Agile culture. During the early adoption period, it is especially critical that the program office and contractor teams have personnel with Agile experience. Agile coaches can also provide guidance to assist programs in tailoring and executing Agile roles, processes, and environments.

A key development risk can occur if requirements are continuously deferred to future sprints or releases, commonly referred to as technical debt. Often the developers find that they cannot meet all of the requirements in a sprint; thus requirements continue to shift to the right, creating a bow wave effect. One way to help mitigate the requirements shift risk is to make the last sprint in each release a “catch-up” sprint involving no new requirements. This helps to keep the overall program schedule and cost on-track.

A final key risk to consider is the user community’s ability to handle the planned releases. When defining the release schedule, a program must consider the users’ ability to integrate releases into their operational environment. This is dictated in part by the amount of change visible to the user community and the extent to which users must change their way of doing business. Training and documentation are often highlighted as constraints, but strategies exist for smoother integration. Experience may have identified some established periods where the operational community cannot integrate new releases.

References:

• DoD Risk, Issue, and Opportunity Management Guide, DASD/SE, Jan 2017
• Agile Risk Management (Disciplined Agile Delivery)
• Risk Management, MITRE Systems Engineering Guide
• AFI 17-101 Risk Management Framework (RMF) for Air Force IT, Feb 2017