What Counts as a Risk: Issues, Opportunities and Risk Attitude

AA risk is a problem that hasn't happened yet. The PMBOK Guide defines project risk as "an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives"¹, and Boehm's earlier software-specific account reduces the same idea to two quantities: the probability of an unsatisfactory outcome, and the loss to the people affected if it happens². Both definitions leave room for things a project team can do something about. That is the point of the concept.

This page sets out the vocabulary the rest of the risk material relies on: how a risk differs from an issue, why some risks are worth pursuing rather than avoiding, where risks sit (in the process, in the product, or in the business around both), the four questions that drive every later step, and how the attitudes of the people involved shape what gets noticed at all.cf. finding-risks: how to spot them

Three Properties of a Risk FoundationalKnowledge that endures for decades — core principles

Risks and Issues FoundationalKnowledge that endures for decades — core principles

OnceOnce a risk happens, it becomes an issue. The distinction sounds pedantic until a team mixes the two in one list, at which point the list stops being useful for either purpose: risks need anticipation and options, issues need someone working on them today.issues demand action, risks demand options

A register that keeps filling up with things that have already happened is telling you something about the process: identification is running behind events. The cure is earlier and more frequent identification (see Finding Risks), not a bigger register.

Not Every Risk Is a Threat FoundationalKnowledge that endures for decades — core principles

TheThe PMBOK definition says "positive or negative" on purpose. An uncertain event that would help the project is an opportunity, and it deserves the same identification, analysis and response planning as a threat. Hillson argued that most applications of the risk process still concentrate on threats, and set out how the standard process extends to cover opportunities explicitly³.

Software projects meet opportunities constantly and tend to treat them as luck rather than as something to plan for:

• A framework release lands early with a feature that would remove a whole component from the plan.
• A client offers access to anonymised production data that would make evaluation far stronger.
• Another team is building a component you need, and could share it if timelines line up.
• A prototype turns out simpler than expected, freeing time for a feature that was cut.

The responses differ from threat responses (exploit, enhance, share rather than avoid, mitigate, transfer). They are covered in Responding to Risk.cf. Responding to Risk: exploit, enhance, share

Where a Risk Lives: Process, Product and Business FoundationalKnowledge that endures for decades — core principles

SommervilleSommerville classifies risks by what they affect: project risks affect the schedule or resources, product risks affect the quality or performance of the software being developed, and business risks affect the organisation developing or procuring it⁴. On this site we read the first category more broadly, as process risk: anything about how the work is done (estimation, staffing, communication, method, tooling) that could go wrong. Treating project risk as process risk is our framing, not Sommerville's, and it's useful because it makes one causal direction visible.

Most product failures start as process failures. A schedule squeeze leads to skipped reviews; skipped reviews leave defects in the code; defects reach users. The error, fault and failure distinction describes the same chain from the testing side. A process risk realised today is often a product risk realised months later.

The reverse doesn't hold, and that asymmetry matters. A project can run on time and on budget, every process risk retired, and still deliver a product nobody needs or one that harms the people it touches. Product and Ethical Risk takes up that case. Equally, a project can slip badly and still deliver the right thing. Keeping the two kinds of risk in separate columns stops a healthy schedule from hiding a weak product, or the other way round.on-time delivery can still be a failure

There is a second reason to care about process risk specifically. The record of how a project handled its risks (what was foreseen, what was done, what happened) outlasts the product itself; it's the part that transfers to the next project. Process Over Product develops that argument for project work in general.

Four Questions FoundationalKnowledge that endures for decades — core principles

EveryEvery technique in the rest of this material is a structured way of answering one of four questions:

1. What can go wrong, or go right? Identification: Finding Risks.
2. How likely is it? Probability estimation: Measuring Risk.
3. How bad, or how good, would it be? Impact estimation: Measuring Risk.
4. What can we do about it? Response planning: Responding to Risk, then Keeping Risk Management Alive to check that what you planned is still working.

Risk Attitude Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

TwoTwo teams looking at the same risk will not respond to it in the same way, and the difference often has more to do with the people than the risk. Hillson and Murray-Webster treat risk attitude as a chosen response to uncertainty, shaped by perception and by the heuristics individuals and groups use when judging it⁵. Three positions are commonly distinguished:

None of these is wrong in every setting. A start-up exploring a market can sensibly run risk-seeking; a team building a medical device should not. What matters is that the attitude is chosen deliberately and stated, because unstated attitude leaks into identification itself. DeMarco and Lister argue that ignoring the threat of negative outcomes in the name of positive thinking or a can-do attitude is what drives software organisations into trouble⁶: a team that treats raising a risk as defeatism will under-report risks, and the register will look healthier than the project is.attitude shapes the response strategy you pick later

Two related terms help when writing this down. Risk appetite is how much uncertainty an organisation is willing to pursue in general; risk tolerance is how much variation it can accept on a particular objective (for instance, "a delay of up to two weeks is acceptable; a data breach is not"). The risk management plan is where both belong.

Proactive and Reactive FoundationalKnowledge that endures for decades — core principles

Boehm'sBoehm's study of successful project managers found that they were good risk managers, even when they didn't use the vocabulary, and that they used the idea of potential loss times probability of loss to guide their priorities². The aim, in his terms, is to deal with risk items before they turn into threats to successful operation or major sources of rework.

The last row is the one to remember. Options shrink as a project proceeds because each decision constrains the next; the cone of uncertainty describes the same narrowing from the estimation side. Proactive risk management is mostly the work of making the important decisions while they are still cheap to change.

Related Topics

• Risk Management & Mitigation: the overview and the full cycle.
• Finding Risks: techniques for answering "what can go wrong?"
• Product and Ethical Risk: when the process succeeds and the product still fails.
• Process Over Product: why the process record is worth keeping.
• Risk Analysis for a Project: the same ideas, scaled to an individual project.

References