Risks, Issues and Assumptions

Definitions

• Risk — an uncertain event which, if it occurs, will affect the project's objectives. It has not happened yet, and it may not.
• Issue — something that has happened and is affecting the project now. Issues are managed, not assessed for probability.
• Assumption — something taken to be true for planning purposes. Every assumption is a risk that it is wrong, and the most dangerous assumptions are the unstated ones.
• Constraint — a limitation that is certain: a fixed date, a budget ceiling, a mandated approach.
• Dependency — a reliance on something outside the project's control, which is a common source of risk.

Confusing risks and issues is the most common failure in practice: registers fill with things that have already happened, which are then discussed as though a mitigation might prevent them.

Threats and opportunities

Risk includes both negative and positive uncertainty. Opportunities — an earlier supplier delivery, a cheaper technology becoming available, a favourable regulatory change — are managed with the same process and are almost always ignored, which means the project captures none of the upside available to it.

Writing a risk properly

A badly written risk cannot be assessed or managed. "Resource risk" and "delays" are not risks; they are categories. The useful structure states cause, event and effect:

Because [cause], [uncertain event] may occur, which would result in [effect on objectives].

For example: "Because the specialist welding contractor has only two qualified people, they may be unavailable in the fabrication window, which would delay mechanical completion by four to six weeks."

Written this way, the cause suggests preventive action, the event can be assessed for probability, and the effect can be quantified.

Risk appetite and tolerance

Appetite is how much risk the organisation is willing to accept in pursuit of an objective; tolerance is the acceptable variation around a target. They differ enormously by context: a research project properly accepts high uncertainty; a safety-critical system does not.

Appetite must be established explicitly, because in its absence the project manager applies their own — which may be considerably more or less cautious than the organisation intends.

Uncertainty that is not risk

Estimating uncertainty — the range around a duration or cost — is a different thing from a discrete risk event, and it is usually handled separately through ranges and contingency rather than as entries in a register. Mixing them causes double counting, where the same uncertainty is allowed for twice.