Risk Management

A risk is “uncertainty that, if it occurs, will affect achievement of objectives” [1]. Not every uncertainty is a risk: the test is whether you can name the objective it would affect. If you cannot, it does not belong in the register. Two components follow, the same in every standard: a probability that it occurs and a loss if it does [2].

Three nested rings: all uncertainty, the part that could affect an objective, and the part that would breach your threshold Risk is the subset of uncertainty that matters. [1]

1. Risk, issue, cause

Three things routinely get filed as risks and are not.

Where a cause becomes a risk and a risk becomes an issue No uncertainty left: an issue. [1]

  • An issue has already happened, or is certain to. With no probability left to reduce, an issue is resolved rather than mitigated: a 100-percent-probable risk is a constraint [3].
  • A cause is not a risk. “Inadequate staffing” may produce several risks — reduced quality, delays, turnover — and only those can be mitigated [4].
  • The meteor is not a risk either. Uncertainty that could not breach your threshold of success is just an event.

The SEI adopted the dictionary definition — risk is the possibility of suffering loss — after printing two scholarly alternatives beside it [5]: a documented choice.

2. Risk is not bad. Unmanaged risk is

“Risk in itself is not bad; risk is essential to progress, and failure is often a key part of learning” [2]. The manager balances a risk’s consequences against the opportunity attached to it — which is why the SEI’s continuous practice manages opportunities as well as threats [6].

Five levels of risk-handling maturity, from crisis management to elimination Risk is not bad. Unmanaged risk is. [2]

The failure mode has a name: the “Indiana Jones school of risk management” — never worry about a problem until it happens, then react heroically [3]. The ladder out runs crisis management → fix on failure → mitigation → prevention → elimination of root causes; at the first three levels the schedule battle is already lost [7].

3. The paradigm

Five steps in a loop, with communication running through all of them: identify → analyse → plan → track → control [2]. Communication sits at the centre rather than as a sixth step; without it the approach fails.

Five steps round a wheel, with communication through the hub Communicate is the hub, not a step. [5]

Three named practices sit on that loop [6]: a Software Risk Evaluation is an event, Continuous Risk Management is a habit, Team Risk Management adds the customer. The frameworks a student will meet — SEI, ISO 31000, PMI, NASA, DoD, NIST’s AI framework — are that same loop with different governance; NIST adopts ISO’s definition [8]. And risk management “cannot be an audit, a check mark on a standard, or something done only during ‘risk management season.’”

4. What the pages cover

Page The question it answers
Identification How do you find risks nobody has said out loud?
Capturing, owning and mitigating How do you write one, own it and track it?
Analysis and prioritisation Which few do you act on?
Why we misjudge risk Why is the estimate optimistic, and what do you do?
Risk management in agile What does this look like inside a two-week cycle?

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [9] on software project management.

References

  1. D. Hillson,
    Managing Risk in Projects. in Fundamentals of Project Management. Gower, 2009.
  2. R. L. Van Scoy,
    “Software Development Risk: Opportunity, Not Problem,” Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-92-TR-30, Sept. 1992.
  3. R. S. Pressman,
    Software Engineering: A Practitioner’s Approach, 7th ed. McGraw-Hill, 2010.
  4. J. Thompson and S. Stump,
    “How to Write a Good Risk Statement,” Defense AT&L, Nov. 2017, [Online]. Available: https://www.dau.edu/library/damag/november-december2017/how-write-good-risk-statement
  5. A. J. Dorofee, J. A. Walker, C. J. Alberts, R. P. Higuera, R. L. Murphy, and R. C. Williams,
    Continuous Risk Management Guidebook, no. CMU/SEI-96-HB-002. Software Engineering Institute, Carnegie Mellon University, 1996.
  6. R. P. Higuera and Y. Y. Haimes,
    “Software Risk Management,” Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-96-TR-012, June 1996.
  7. S. McConnell,
    Rapid development: taming wild software schedules. Pearson Education, 1996.
  8. National Institute of Standards and Technology,
    “Artificial Intelligence Risk Management Framework (AI RMF 1.0),” U.S. Department of Commerce, NIST AI 100-1, Jan. 2023. doi: 10.6028/NIST.AI.100-1.
  9. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

Table of contents

This site uses Just the Docs, a documentation theme for Jekyll.