In most modern organisations, risk management is a mature process. The procedures exist, often documented and certified. The registers are filled in. Risk and opportunity matrices circulate at steering committee level, their cells shaded green, amber and red. At first glance, the subject looks under control.
Yet when you look at what actually happens on the ground, a gap appears. A gap between what the quality manual prescribes, what executives see during monthly reviews, and what the operational teams experience. The risk register becomes one deliverable among many, to be updated periodically, rather than a management tool. Risk reviews turn into a formal walk-through, and mitigation actions, where they exist, struggle to move beyond good intentions.
This gap is compounded by another phenomenon, less visible but more structural: risk management is today largely driven by project reporting and by the question of provisions. Yet risks and margins are closely linked. Recognising a risk usually means booking a provision against it. Booking a provision degrades the reported margin. That mechanism, perfectly legitimate in accounting terms, creates a quiet temptation: to record the risk only at the last moment, often too late, rather than acting early at the cost of a precautionary (and usually smaller) hit to the margin.
The contract manager’s role in this landscape is not merely to handle these tools or to add entries to the registers. It is to give them meaning, to translate them into concrete actions, and to impose, inside the project, an analytical discipline that withstands reporting pressure.
Understanding risk before managing it
Before turning to the tools, it is worth going back to the notion of risk itself. Risk, in its broadest sense, is the direct consequence of uncertainty. Every project, by its very nature, carries uncertainty over its schedule, its costs, its technology, its interfaces and its environment. That uncertainty produces an exposure, which has to be understood, calibrated and arbitrated.
What we then call “risk management” is nothing exotic. We all practise it daily. I always illustrate this with a simple case: when I buy a car, I can choose third-party or comprehensive cover. I do not settle that trade-off by reading a quality process or a risk management manual. I work it out intuitively from several parameters: is my vehicle new or old? What is it worth? Could my budget absorb the additional premium? What would the real consequences of an accident tomorrow morning be? Do I need this car to get to work, or is it for occasional use? The list can be long, but the final decision is always the product of a combined reading of probability, impact, risk aversion, the cost of mitigation and the availability of fallback plans. Once you have analysed those variables to make your choice, you have, in a sense, done risk management!
This parallel has one virtue: it is a reminder that risk management is not a defensive posture, nor (as one sometimes sees) a kind of counterweight to a commercial view judged too optimistic. It cannot be reduced to a stand-off between the cautious camp and the optimistic one. It is a realistic, objective approach to making better decisions. The purpose of risk management is not to say “we should not go there”, but rather to show what a given choice implies in terms of risks and opportunities, and the most sensible way of handling them.
On substance, the reference frameworks are stable and convergent. The PMI’s PMBOK, the APM’s PRAM and the ISO 31000 standard all describe a similar cycle: identify, analyse, treat, monitor. All of them distinguish the downside dimension, that is the threats liable to damage the project, from the upside dimension, that is the opportunities liable to improve it. This second dimension, structurally important in theory, is rarely exploited in practice. How many registers really contain a seriously worked “opportunities” column? Risk management tends to confine itself to defence, at the expense of a fuller reading.
As for the types of risk, they are classically distributed between technical, financial, contractual, schedule, organisational, external and reputational risks. This typology, useful for structuring thinking, must not obscure the fact that risks combine: an untreated technical risk becomes a schedule risk, which becomes a financial risk, which becomes a contractual risk.
Assessing risk: rigour in the qualitative, caution in the quantitative
Risk analysis classically unfolds across two complementary registers: qualitative and quantitative.
Qualitative analysis rests on expert judgement, structured around the probability/impact matrix. Each identified risk is scored on two axes, then positioned in a grid that reveals its relative criticality. Done well, this analysis provides most of what is needed to manage. It has one weakness nonetheless: its reliability depends entirely on the quality of the group conducting it. A rushed brainstorm, a matrix filled in single-handedly by a hard-pressed project manager, and the exercise loses all value. That is why cross-checking perspectives (project management, procurement, engineering, operations, legal and of course contract management) is not an option, but the very condition of robustness.
Quantitative analysis goes further. It models statistically the effect of risks on costs or schedule; one can use the “Monte Carlo” simulation method, or decision-tree and sensitivity analysis methods. On megaprojects (heavy CAPEX investments), these methods bring valuable insight. On the majority of projects, however, their use remains theoretical. It impresses in a presentation and gives the decision-maker the illusion of precision, but it rests on assumptions that are themselves fragile. Calculating a P50 and a P80 from uncertain input data is sophisticating uncertainty without reducing it.
The trade-off between the two is not a methodological debate, it is a question of proportionality. On a twelve-month organisational transformation project, bringing in a Monte Carlo consultant often makes no sense. On an offshore EPC project, the absence of quantitative analysis would be incomprehensible. The skill lies in calibrating, not in picking a side.
Treating risk: four options, one decision
Once identified and assessed, risks call for a response. The reference frameworks converge on four broad options for treating a risk: avoid, mitigate, transfer, accept.
Avoiding means changing the project so that the risk disappears. Giving up a scope element, excluding a supply, refusing a client requirement. It is the most radical strategy, and the least frequently used, because it presupposes room for manoeuvre that is rarely available once the project has started (although in the pre-signature phase, avoidance can be a genuine response strategy).
Reducing means lowering the probability of occurrence, the impact, or both. Multiplying design reviews, dual-sourcing a supply chain, tightening quality control, doubling teams, working two-shift or three-shift patterns, allocating schedule float, and so on. Any action that makes the risk less likely and/or less costly falls under this strategy.
Transferring means placing the risk with a third party better equipped to absorb it. Subcontracting a critical activity, taking out insurance, negotiating a guarantee from a supplier. Transfer does not make the risk disappear, it moves it. And this is where the most frequent error lies: transferring a risk without a suitable contract clause is not transferring it at all. The risk is still there, simply disguised as an intention.
Accepting, finally, means bearing the risk as it stands, with no further mitigation action. This strategy is legitimate where the cost of mitigation exceeds the cost of the residual risk. It does, however, presuppose a dedicated provision, whether financial, schedule-related or held as management reserve. Accepting a risk without a provision is ignoring it.. and, as you will have noticed, ignoring is not one of the four options listed above!
At this stage the obvious emerges: none of these four options can genuinely be deployed without thinking through the cost/quality/schedule impacts, and the consistency of the option with the provisions of the contract. Here again, the contract manager has an important part to play.
From document to action: making the difference through contract management
Where risk management fails on projects, it is almost never for want of tools. It is for want of active management. The register exists, the matrix exists, the process exists. Nobody keeps them alive.
The first symptom is the absence of ownership. Where the matrix has no single owner, everyone feels superficially concerned and no one is deeply so. Risks are identified at the start of the project, then the table freezes. Estimates age and are not updated, mitigation actions lose their owner and their momentum, reviews become obligatory rituals with no real content. Without an owner, the matrix dies.
The contract manager is, by construction, the natural candidate for that ownership role. They sit at the interface between operations, sales, procurement, engineering and legal. They have the standing to call on each of these functions and to confront their readings. Above all, they bring a culture of traceability and formalisation that matches precisely what the discipline demands.
Their contribution is not limited to maintaining the document. It consists first in orchestrating the cross-checking of perspectives. A score set by a single function is almost always biased. The project manager often underestimates the contractual impact, procurement may underestimate the effect of a supplier on the project as a whole, engineering may overlook cost or schedule impacts. Bringing these readings into dialogue makes it possible to refine, to challenge and to stabilise a shared view.
The contract manager also contributes to impartial quantification. The contract manager must be able to challenge the costing of a risk for what it is, independently of the reporting constraints of the moment. If the matrix faithfully reflects reality, some risks will justify provisions that weigh on the reported margin. That is uncomfortable, sometimes contentious, but it is precisely by this impartiality that the value of genuine risk management is measured. A matrix that aligns itself with the target margin is a matrix of convenience, not a management tool.
Finally, the CM ensures the proportionality of the treatment measures. Not all mitigations are equal. Some cost more than the risk they cover. Others treat a symptom without tackling the cause. The contract manager’s role is to work through that calibration, to prioritise, and to make sure the actions retained match the stakes, neither oversized nor cosmetic.
Making the matrix speak: from register to active management
This is where the contract manager stands apart from a mere keeper of the register. Keeping the matrix alive requires a management mechanism that goes beyond periodic updating. That mechanism rests first on regular review rituals, distinct from the project steering committee. A useful risk review is short, but it examines in depth the changes in scoring, the overdue actions, the newly identified risks and the emerging opportunities. It does not validate, it questions.
It rests next on trigger indicators, or early warnings. An identified risk does not turn abruptly into a loss. It sends weak signals, provided one has taken the trouble to define those signals in advance and to monitor them. A schedule slippage beyond a threshold, a late supplier delivery, an unresolved technical reservation, an announced regulatory change are all markers that should trigger an ad hoc review.
Above all, it rests on the link between the matrix and the contractual life of the project. A risk that materialises very often generates a claim, a contract amendment, an extension of time request, a price revision. The contract manager who owns the matrix knows these correspondences and anticipates the associated contractual reflexes. Their reading of the register feeds their reading of the contract, and vice versa. It is this circulation that turns a quality deliverable into an operational tool.
Conclusion
Project risk management rarely suffers from a lack of tools. It suffers from the mechanical application of those tools (and sometimes from unsuitable ones), disconnected from the context and from the decisions they are supposed to inform. Processes, matrices and registers have real value, but they are only supports. Their worth depends entirely on how the person in charge reads them, and on the trade-offs they make possible.
The contract manager’s role is therefore not merely to fill in the table. It is to bring a critical, demanding, sometimes iconoclastic eye to these tools. It is to know when to step away from them when the context demands it, without betraying their spirit. An exhaustive register with no owner is worth less than a shorter matrix that has genuinely been debated. A Monte Carlo calculation means nothing if no qualitative analysis has been carried out beforehand.
It is by this discipline, made of methodological rigour and field common sense, that you recognise contract management that raises the project, rather than contract management that documents it.