Monitoring Risks: What Changes After the Risk Register Is Written?

Most project teams can produce a risk register on request. Fewer can say what has changed in it over the last month, and fewer still can point to a decision that changed because of it. The register is built with energy in a planning workshop, then settles into a monthly routine: each row is read aloud, the owner confirms it is still open, and the scores stay exactly where they were in week three. That routine looks like monitoring. Usually it is not.

Risks should be monitored by watching the conditions that would make them more or less likely, checking that agreed responses are actually happening and working, keeping sight of overall exposure rather than only individual entries, and making sure that what the team learns reaches someone who can act on it. The register is the record of that work, not the work itself. The question for every review is easy to ask and harder to answer honestly: what has changed since we last looked, and does it change anything we are doing?

Why a risk register goes stale while the project keeps moving

A risk register describes what the team believed on the day each entry was written: how likely something seemed, how much it would matter, who was best placed to watch it and what response looked proportionate. Every one of those judgements rests on conditions that keep shifting once delivery starts. Dates slip and bring risks closer. Scope changes create exposure nobody assessed. Suppliers change staff, owners move to other work, and assumptions that looked safe in planning are quietly tested.

This is why a score that has not moved for several months deserves suspicion rather than reassurance. Some risks genuinely are stable, but on an active project most are not. A risk whose window has passed should be closed. A risk whose warning signs are appearing should move up the agenda, whether or not anyone has formally rescored it.

Consider a fictional data centre migration run by an IT services provider for a public-sector client. During planning, the team logged a risk that the ageing storage array would fail, or lose vendor support, before the final migration wave was complete. Vendor support ran to the end of September and the final wave was planned for June, so the probability was scored low. The response was sensible: obtain a quotation for extended support and hold it as a fallback. The infrastructure manager took ownership.

By May, the second wave had slipped five weeks because application owners were not available for testing, and the final wave now sat in mid-August. The infrastructure manager had moved to another programme, although the register still named her. The extended support quotation had a ninety-day validity period and had lapsed. Over the same six weeks, the storage team had swapped out more failed drives on the old array than in the whole of the previous year. At the monthly review, the row was read out, the vendor's date was confirmed as unchanged, and the score stayed low.

Nothing in that account was hidden. The schedule variance was in the status report, the drive replacements were in the service desk records and the owner's move had been announced. What was missing was any habit that connected information to the risk it affected. The vendor's date had not moved; the project's own dates had.

What risk monitoring should actually be watching

Monitor Risks appears as a process within the Risk Performance Domain at Section 2.7.2 of the PMBOK® Guide Eighth Edition. Like the other processes in the Eighth Edition, it is nonprescriptive: it describes work that needs to happen throughout delivery rather than a meeting format or a particular template. In practice, that work tends to concentrate on four things.

The first is trigger conditions and early warning signs. A well-written risk entry says what would indicate that the risk is becoming more likely, and monitoring means someone is looking for that evidence in the places it would appear: defect trends, supplier correspondence, resource forecasts, test results, service records. Lagging signs tell you a risk has arrived, while leading signs give you time to act. In the migration example, the drive replacement rate was exactly that kind of signal, sitting in a system the risk review never looked at.

The second is whether responses are being carried out and whether they are working. An action marked "in progress" for two months is an intention rather than a response. Even implemented responses need checking, because a mitigation can reduce one risk while introducing another, or leave more residual exposure than anyone expected. The lapsed quotation shows how easily a response can stop existing without anyone deciding to abandon it.

The third is overall exposure. Individual rows can each look manageable while the project as a whole becomes considerably riskier, particularly when several risks share a cause such as a stretched specialist team or a single supplier. Useful questions at this level include whether exposure is rising or falling, whether remaining contingency still looks proportionate to what could go wrong, and whether the pattern is serious enough that a sponsor or steering group should see it before the next scheduled report.

The fourth is new risk arriving through change. Approved changes, re-sequenced work, new suppliers, staff turnover and developments outside the project all create exposure that did not exist when the register was written. A change request assessed only for cost and schedule has been assessed incompletely, and so has a re-baselined plan that nobody checked for the risks it brought closer.

The rhythm differs by approach, but the purpose does not

On predictive projects, monitoring is usually tied to a planned governance cadence of phase gates, performance reviews and reporting cycles. That structure is valuable, especially where contractual or regulatory commitments require evidence that risk was actively managed. Its weakness is the interval between reviews, because a fast-developing risk can travel a long way in a month. The strongest predictive teams connect risk to the performance information they already produce, so that schedule variance, cost trends and earned value measures each prompt a direct question about which risks have just become more or less likely.

Adaptive teams tend to meet risk through shorter feedback loops. Impediments surface in daily coordination, iteration reviews show whether assumptions about users or technology are holding, and retrospectives expose working patterns that could threaten later delivery. Some risks are reduced by deliberately pulling uncertain work forward in the backlog so it is tested early. That frequency is a real strength, but it can hide risks sitting beyond a single team's horizon, such as an external dependency, a funding decision or a release window controlled elsewhere in the organisation.

Hybrid delivery raises the most demanding monitoring question: whether risk information crosses between rhythms. A team working in two-week iterations may see a warning sign weeks before a quarterly board does, while the board may know about an organisational change the team has never heard of. Monitoring in hybrid settings depends less on either cadence than on agreeing where risk information goes, who passes it on, and what degree of change justifies raising it between reviews.

Making a risk review change something

The most useful improvement many teams can make is to reverse the direction of the review. Instead of starting at row one and asking whether each risk is still open, start with what has changed on the project since the last review: schedule movement, approved changes, staffing, supplier performance, test results and developments in the wider environment. Then ask which risks those changes touch. The meeting takes no longer, and it surfaces the connections that row-by-row reading misses.

A handful of questions keeps the conversation grounded. What evidence, rather than feeling, tells us whether this risk is more or less likely? Is the named owner still in a position to watch it? Has the response been carried out, and what did it achieve? Which risks have passed their window? What should someone outside this room know before the next report? Each answer should end in a recorded action or decision, even if the decision is to keep watching with a clearer indicator.

Closing risks deserves more attention than it usually receives. A register that only grows becomes harder to use, and risks that have genuinely passed can tie up reserves needed elsewhere, so retiring an entry with a short note of why is as much a monitoring outcome as escalating one. Equally, when the evidence shows a risk has materialised, the work shifts from preparing for uncertainty to managing something that is now happening, and the team should recognise that shift quickly rather than carry on debating probability.

For a PMP® candidate, the same habit carries across. The current PMP Examination Content Outline places risk within the Business Environment domain, in a task that covers identifying, analysing, monitoring and controlling risks and communicating their impact, alongside a separate task on impediments and issues that includes recognising when a risk has become an issue. Because the exam is built around applying practice to realistic scenarios, knowing where a risk is recorded is rarely enough on its own. The stronger preparation habit is reading a situation for what has changed (a trigger appearing, a response failing, a change introducing new exposure) and choosing an action that fits that condition. Practising that kind of reading, where a scenario hands you a slipped date and a lapsed action rather than a convenient label, sits at the centre of our PMP® Exam Preparation, because it is also the habit that makes a real risk review worth attending.

On a live project the payoff is easy to picture. Had the migration team opened its May review with the slipped wave dates, the storage risk would have been rescored within minutes, the quotation renewed, and the drive failure trend added as a named indicator with an owner who was still on the programme. None of that needed a new template. It needed the register to be treated as a set of expectations the project keeps testing against what is actually happening.

Andre Malowney

Interested in going further?

Much of the skill in monitoring risk lies in noticing the slipped date, the departed owner or the lapsed action before anyone has labelled it a risk problem. Structured PMP® preparation gives you deliberate, repeated practice at reading project situations that way.

For the full context of Monitor Risks within the Risk Performance Domain, the PMBOK® Guide Eighth Edition is the reference worth keeping beside your register.

Ad · Amazon affiliate link.

References

A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
A153: Risk vs Issue: The Difference That Changes What You Do Next
A154: When Does a Risk Become an Issue?
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A157: Do Agile and Hybrid Projects Still Use Risk Registers?

PMP and PMBOK are registered marks of the Project Management Institute, Inc.