Risk & opportunity management
Randomness, uncertainty, contingency reserves, mitigation plans. Treating risk and opportunity as a balanced portfolio.
The line between risk and opportunity often comes down to a baseline cursor: an optimization absorbed into the reference plan becomes a risk as long as it is not confirmed; kept outside, it remains an opportunity. Many projects see their opportunity portfolio disappear because every upside has been absorbed up front, which mechanically turns potential drift into certain drift. A balanced portfolio, with opportunity margins kept alive, protects the final trajectory better than an "over-absorbed" optimistic baseline.
A project does not drift only because of what it fails to anticipate. It also drifts because of what it has already absorbed into its baseline. Every optimization written into the budget or schedule before it is confirmed becomes a risk as long as it has not materialized. This hub proposes a reading of risk management as portfolio management: what you absorb up front, what you hold in reserve, and what you choose to track separately.
The articles for this pillar are coming soon. The citable answer above is already stable.
Your questions, our anchors
Q.What is the difference between randomness, uncertainty, and risk?
These three notions are often confused in practice, but they are not managed the same way. **Randomness** refers to an event whose individual occurrence cannot be predicted, but whose statistical frequency is known or modelable: a day of frost, a machine breakdown, an occasional supplier delay. It is handled through average reserves and smoothing. **Uncertainty** refers to a domain where even the probability law is unknown: an upcoming regulatory decision, the adoption of an emerging technology, the geopolitical stability of a supplier. It cannot be provisioned through statistical calculation. It is handled through scenarios, monitoring, and open options. **Risk**, in the sense of the ISO 31000 standard and the PMBOK Guide, is an identified event that, should it occur, would have a measurable effect on the project's objectives. It combines an identifiable cause, a probability of occurrence, and an assessable impact. Unlike randomness, it is named; unlike uncertainty, it is measurable. This distinction guides the mode of treatment: randomness is provisioned, uncertainty is monitored, risk is actively managed with a dedicated mitigation plan.
Q.How do you build a mitigation plan that will actually be followed?
Most mitigation plans end up as forgotten Excel registers, reviewed once a quarter during the audit meeting. Three main causes explain this pattern, and each calls for a specific discipline. **First cause: risks are poorly defined.** A real risk names a specific and defined event, with an identifiable cause. "We could run out of resources" is not a risk, it is a concern; "the announced departure of the software work-package lead in June may delay the module delivery by six weeks" is a risk. The discipline consists of rewording each item of the register until it names a precise, situated, measurable event. **Second cause: no one is named as the mitigation owner.** Attributing a risk to "the PMO" or to "the project team" guarantees that no action will be taken. Every risk needs a single, named owner who reports on the progress of mitigation actions at defined intervals. The owner is not necessarily the one who will suffer the impact; it is the one who has the power to act on the causes. **Third cause: the risk timeline is not managed.** A risk has a temporal life cycle: it is mitigable until a deadline, it may occur within a specific event window, it has occurrence triggers tied to other project milestones. Treating a risk without treating its timeline means reacting after the fact. The discipline consists of placing each risk in the schedule the same way as an activity, with its review dates, its mitigation deadline, and its observable triggers. This approach, formalized notably by David Hillson in his work on risk timeline management, holds that the mitigation deadline is as important as probability and impact in the management of a risk: past that date, preventive action is no longer possible and only occurrence management remains. A mitigation plan that applies these three disciplines becomes alive: it is read regularly because its items are concrete, it is acted upon because someone is accountable, and it evolves in synchronization with the project because it has a timeline of its own.
Q.How do you size a contingency reserve?
Sizing a contingency reserve (also called risk provision or contingency budget) is one of the most politically sensitive trade-offs of a project. Too low, it exposes management to having to request budget top-ups mid-project; too high, it makes the project uncompetitive at approval or triggers budget renegotiations. Three methods coexist, and the choice depends on the maturity of the risk analysis. **The flat-rate approach** applies a global percentage to the base budget. For large industrial and engineering projects, a range of 20 to 30% is often defensible; the 5 to 15% threshold sometimes cited by generic references actually corresponds to highly mature and standardized sectors (series automotive for example), not to the average of large projects. Conversely, for projects with a low technology readiness level (low TRL, typically 3 to 4), the reserve may legitimately reach 50% of the base budget. On paper, the principle would call for a reserve approaching the nominal cost when uncertainty equals the total project value, but no financial officer grants this level in practice: the upper bound retained is a compromise between technical lucidity and budget acceptability. Fast, opaque, low arbitration power: this approach is useful in early-phase work when no detailed analysis has been carried out, but it does not survive a demanding audit. **The weighted sum approach** aggregates, for each risk identified in the register, the product *probability × financial impact*. This method is defensible to management, traceable in review, and it enforces the discipline of identification and quantification. Its limit: it assumes risk independence, which is rarely true in a project where several risks may chain together. **The simulation approach** (Monte Carlo typically) models the correlations between risks and produces a probable cost distribution. The reserve is read at the desired confidence level (for example P70 or P85 depending on the acceptable exposure level). Higher entry cost, but it yields a defensible figure for high-stake or highly correlated projects. The real pitfall is not the choice of method: it is the absence of an explicit method. A contingency budget whose calculation no one can explain becomes indefensible at the first budget review, and loses its legitimacy at the moment when it would be most needed.
Q.Contingency reserve and schedule buffer: what is the difference?
These two devices are often confused, or worse, used as if they were interchangeable. They actually protect two different dimensions of the project. The **contingency reserve** protects the cost dimension. It absorbs the extra cost triggered when an identified risk occurs: overrun on a service, remediation of a defective work package, activation of a backup service. Without it, the occurrence of a risk triggers a budget top-up request, with all its political consequences. The **schedule buffer** protects the duration dimension. It absorbs the delay triggered by randomness, a slipping dependency, or a schedule-side risk that occurs. Without it, the occurrence of a delay event forces a shift of the delivery date, with the same political consequences on the schedule side. The two devices are managed with comparable logics: sizing (flat-rate, weighted sum, simulation), tracked consumption (the consumed percentage measures the health of the project), and possible replenishment mid-course if the context allows. But they do not substitute for each other: a project that only has a budget reserve is protected against the cost overrun of a risk but not against the delay it generates; a project that only has a schedule buffer is protected against the slippage but not against the extra cost. In a project, the two devices are managed jointly, with governance rules that articulate them: for example, a 50% consumption of the buffer triggers a review of the risk portfolio and a possible mobilization of the reserve to reinforce a mitigation in progress.