The new project manager is three weeks into the role. On her fourth day, someone sent her the company’s risk register template: twenty-two columns, a five-by-five heat map, drop-down lists for category, proximity and response strategy. She had been told that managing project risk was part of the job, so she did it by the book. She ran a workshop, and the team produced sixty-one risks in ninety minutes. They scored every one and coloured a third of the cells red.
Five weeks later, nobody has opened the file. Three of the sixty-one risks have already happened, and two of them were never on the list. The steering committee has not seen the register. Nobody has asked for it.
Her method was not the problem. A project manager handling risk for the first time needs a working rhythm more than a method, and that rhythm takes four things: one short list, a weekly slot to look at it, thresholds that tell her what to escalate, and a forum that acts when she does. She can build the first two herself. Only her manager and her sponsor can give her the other two. This post is written for her, and even more for them.
The field offers a dozen methods, and a first-time project manager needs three
Risk management has a crowded toolbox, and most of the literature presents it as one flat menu. It is easier to think of it in three tiers.
The first tier is what a project needs from its first week. A risk register, or its wider cousin the RAID log, which tracks risks, assumptions, issues and dependencies in one place. A simple rating of likelihood and impact, so the team can rank the list. And a pre-mortem: Gary Klein’s technique of asking the team to imagine that the project has already failed, then to explain why. Klein’s pre-mortem surfaces risks that a normal workshop misses, because people find it easier to explain a failure than to predict one.
The second tier earns its place once money and dates carry real exposure. Expected monetary value helps size a contingency reserve. Monte Carlo simulation tests a long schedule or a large budget against its uncertainties. Bow-tie analysis and failure mode and effects analysis belong in engineering and safety-critical work. All of them are useful when someone will make a decision on the number they produce. Without that decision, they produce precision nobody reads.
Organisational risk frameworks are not project tools
The third tier is organisational, not project-level: ISO 31000, enterprise risk management, and the Institute of Internal Auditors’ Three Lines Model. They matter, but they were not built for running a project. The Three Lines Model, for instance, is a map that shows a board who owns risk, who monitors it and who independently assures it. Your organisation’s risk function may ask to see your register. It does not manage your risks for you.
The standards point the same way. The eighth edition of the PMBOK Guide treats risk as one of seven performance domains. It expects each project to tailor its approach rather than run a fixed sequence of processes. In other words, the method is a choice. The rhythm is not.
Risk management is a rhythm with a list attached
A minimum practice fits on one page. The register needs six fields, and none of them is optional:
- Risk statement: one sentence that names a cause, an event and a consequence. “Because the supplier’s tooling is late, first articles may slip, which would delay validation by a month.” A word such as “resources” is a topic, not a risk.
- Owner: a named person who will act, not a department, and not the project manager by default.
- Rating: high, medium or low, for likelihood and for impact. Three steps are enough to rank a list. Five steps invite debates about whether something is a three or a four.
- Response and date: one action, one date.
- Trigger: the observable signal that the risk is turning into an issue.
- Status: open, watching, closed, or happened, in which case it moves to the issue log.
Four rules keep the list alive. Hold no more than about fifteen active risks; a longer list is an inventory, so park the rest and revisit it monthly. Review the list for fifteen minutes every week, inside a meeting the team already holds. Cover only the top items and what changed since last week. Put opportunities in the same register, because a supplier who could deliver early is also uncertainty worth managing. Finally, run a fresh pre-mortem at each stage boundary, when the project knows enough to see risks it could not see at the start.
The response you choose matters less than the date next to it
The standard menu of responses is short. For threats, you can avoid the risk by changing the plan, reduce it, transfer it through a contract or insurance, accept it, or escalate it. For opportunities, the mirror terms are exploit, enhance and share. Note that transfer usually moves the financial impact, rarely the consequence itself. A late supplier with a penalty clause is still late.
New project managers often agonise over the category. The category seldom changes what happens next. What changes it is whether the action has an owner and a date. A mitigation without a date is a wish.
Acceptance deserves particular care, because it is the response most often chosen by default. Accepting a risk is a decision: someone with the authority to carry the exposure decides to carry it, and the register records who. Without that, acceptance is neglect written down politely. This raises the question a first-time project manager cannot answer alone: who is allowed to accept what?
Escalation thresholds are the sponsor’s decision, not the project manager’s
Without written thresholds, a new project manager has two bad options. She can escalate everything and look as though she cannot cope. Or she can escalate nothing and be blamed when a risk lands. Accidental project managers tend to choose the second. They were picked because they are good at their day jobs, and escalation feels like admitting failure.
The answer sits above the project. PMI’s portfolio standard expects an organisation to state its risk appetite before it makes decisions, not to discover it during them. The sponsor’s job is to translate that appetite into limits for one project. Take one example. Any risk that could move the end date by more than two weeks goes to the sponsor within a week. So does any risk that could add more than five per cent to the budget, or touch safety or regulatory compliance. Any risk that threatens the business case goes to the steering committee. The exact limits depend on the project; the point is that someone with authority writes them down.
That takes half a page. It also does more for a new project manager than any template. It turns escalation from a judgement call about her own competence into a rule she simply follows.
What a manager can hand over in the first week
If you are the line manager, the PMO lead or the sponsor who put a first-time project manager in place, four things are yours to give.
The first is the half page of thresholds described above, agreed before the first risk review rather than after the first surprise.
The second is a forum that acts. An escalated risk should reach a steering committee that actually steers, where it produces a decision, an owner and a date. If escalations land in a status meeting where nobody can decide anything, the project manager learns that escalation is pointless, and she stops.
The third is a safe first escalation. The first time a new project manager raises a red risk, your reaction teaches the whole team what the register is for. Thank her first. Ask your questions second.
The fourth is fifteen minutes a month. Sit with her, read the top five risks together, and ask two questions: which of these would you bet money on, and what would make you escalate it? That is coaching no template provides. It also tells you, faster than any report, whether the rhythm is holding.
What you should not hand over is a heavier template. Twenty-two columns were never the missing piece.
Hand a new project manager a method and you get a register; hand her a rhythm, thresholds and a forum, and you get risk management.