Keeping Risk Management Alive: Monitoring, Control and Closing Risks

RisksRisks change. A probability rated low in week one rises when a supplier goes quiet; a risk rated high falls when a prototype works; new risks appear as the team learns what it's building. A register written once at the start and filed records what the team was worried about in week one, nothing more. Monitoring and control is the phase that keeps the register describing the project as it is now.

The work has four parts: watching known risks for change, finding new ones, starting response plans when their triggers fire, and checking whether the responses are working. This page covers the techniques for each, the difference between signals that warn early and signals that confirm late, how to close a risk, the principles behind continuous risk management, how organisations mature in it, and the pitfalls that stop it working.finding-risks.html covers how to spot new threats

Monitoring Techniques Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

Technique	What it involves	Cadence
Top-ten risk list	The highest-priority risks, reviewed at the start of every project meeting	Weekly or at every review
Miniature milestones	Small, binary checkpoints that show slippage early	Every few days
Risk as a standing agenda item	New risks, changed risks, closed risks, triggers fired	Every team meeting or stand-up
Reassessment	Re-rate probability, impact and priority	At milestones, and whenever scope, schedule or staffing changes
Risk audit	An independent look at whether the risk process itself is working	Once or twice per project, and at its end
Workarounds	Unplanned responses to risks nobody foresaw, recorded afterwards	As needed

The top-ten risk list

BoehmBoehm describes top-ten risk-item tracking as the easiest and cheapest place to start with risk management¹. Rank the project's most significant risk items; begin every project review with a summary of progress on them, giving each item's current rank, its rank at the previous review, how often it has appeared on the list, and what has been done since; then spend the meeting on whichever items are stuck. He notes that the number could be seven or twelve without losing the point. What matters is that the list is short enough to discuss and is reviewed at a fixed rhythm. McConnell gives the same technique a chapter of its own in his book on rapid development².

The "times on the list" column is the one worth watching. A risk that has sat in the top ten for six reviews in a row with no change is either being handled badly or rated wrongly.

Miniature milestones

McConnell also advocates miniature milestones: checkpoints small enough that each one is either done or not, a few days apart². "API design document complete" can be checked with a yes or a no; "API design 60% done" can't. Binary checkpoints make slippage visible within days, while a percentage-complete report can say 90% for weeks.binary states prevent the illusion of progress

Leading and Lagging Signals Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

SomeSome signals warn before harm arrives; others confirm it after the fact. Our observation is that the early-warning signals are mostly about the process, while the confirming signals are mostly about the product, which follows from the chain on What Counts as a Risk: process problems usually turn into product problems after a delay.

Leading signal (process)	What it may be warning of	Lagging signal (product)
Miniature milestones missed two in a row	Schedule slip; scope that was underestimated	Release date missed
Review queue growing; reviews being waived	Defects entering the code unchecked	Defects found in acceptance testing or by users
Flaky tests being re-run until they pass	Faults hidden as noise	Production incident in the "flaky" area
One person answering every question on a component	Single point of knowledge	Work stalls when they're away
Requirements changes per sprint rising	Unstable scope; rework	Features delivered that don't match need

Watch the left-hand column. By the time the right-hand column shows something, the response options have narrowed.

Tracking Reserves and Exposure Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

TrackTrack how much contingency reserve has been used against how many risks have been retired. Spending half the reserve with most of the high-exposure risks still open means the reserve was too small or the responses aren't working. The risk burn-down chart plots total open exposure over time; drawing reserve consumption on the same axis shows whether the two are moving together.

Closing Risks Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

CloseClose a risk when it has happened and been dealt with, when the context has changed so it no longer applies, or when its probability or impact has fallen to a negligible level. Closing has three steps:

1. Record the outcome: what happened, whether the response worked, and what it cost.
2. Update the register status, and keep the row; a closed row is evidence.
3. Tell the people who were tracking it.

A register that only ever grows becomes too long to read. Closing risks keeps the active list short and gives the project a record of decisions and outcomes that's valuable afterwards, both in a project report and at the start of the next project. Process Over Product argues for keeping that kind of record in general.a living log, not a museum of dead risks

Seven Principles FoundationalKnowledge that endures for decades — core principles

HigueraHiguera and Haimes set out seven principles underlying the Software Engineering Institute's approach to software risk management³. The right-hand column describes what each looks like on a software team today.

Principle	On a software team
Global perspective	Risks are judged against the whole system and its users, not one component or one team's objectives
Forward-looking view	Reviews ask "what could happen next?", not only "what went wrong?"
Open communication	Anyone can raise a risk without being treated as negative; bad news travels fast
Integrated management	Risk is part of sprint planning, design review and release decisions, not a separate document
Continuous process	Identification and review recur throughout the project, not once at the start
Shared product vision	Everyone agrees what the product is for, so everyone can recognise a risk to it
Teamwork	Risks are found and handled collaboratively, drawing on every role's view

"Shared product vision" links the process discipline back to the product. Without a shared idea of what the product is meant to achieve, team members can't recognise product risks, because they don't agree on what success looks like.ambiguity breeds risk blind spots

Risk Management Maturity FoundationalKnowledge that endures for decades — core principles

Hillson'sHillson's risk maturity model describes four levels of organisational capability, assessed across culture, process, experience and application⁴:levels 1 to 4: ad hoc to optimising

Level	Description	What it looks like in software
1. Naïve	Unaware of the need to manage risk; no structured approach	Firefighting; problems are met as surprises
2. Novice	Experimenting with risk management through a few individuals; no formal generic process	One lead keeps a list; it lapses when they're busy
3. Normalised	Risk management built into routine processes and applied to most projects	Every project has a register, a review cadence and owners
4. Natural	A risk-aware culture; threats and opportunities both managed proactively across the organisation	Risk thinking shapes architecture and planning decisions without being prompted; data from past projects feeds estimates

The same idea, that capability is a property of process and can be improved and measured separately from any single product, underlies the Capability Maturity Model and its successor; see CMMI and Process Over Product. The practical aim is to move from reacting to events towards anticipating them, using the project's own history as data.

Common Pitfalls Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

Pitfall	Symptom	Remedy
Ignoring early warnings	Triggers fire and nobody acts	Named owners for every trigger; frequent short reviews
Poor communication	Risks known to developers never reach decision-makers	Escalation route written into the plan; risks on the agenda of every meeting
No accountability	Owner column says "team" or is empty	One owner per risk, by role, with a deputy (see the register template)
One-time exercise	Register untouched since week one	Review cadence in the plan; a "last reviewed" date on every row
Analysis paralysis	Weeks spent rating risks; no responses started	Qualitative triage first; quantitative analysis for the top few only
A suspiciously clean picture	Exposure falls steadily and no new risks are ever added	Run a fresh identification session; treat a clean result as a question

A Fifteen-Minute Weekly Review Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

ForFor a small team, the whole of monitoring and control can fit in a quarter of an hour a week:

1. Triggers (3 minutes). Has any trigger fired? If so, start its contingency plan and assign the work.
2. Top ten (5 minutes). For each item: what changed, what was done, is it stuck?
3. New risks (4 minutes). What do we know now that we didn't last week? Add and rate anything new.
4. Close (2 minutes). What can be closed? Record the outcome.
5. Record (1 minute). Update the burn-down total and the "last reviewed" dates.

At the end of each phase, add one more question: what would we do differently next time? Write the answer somewhere the next project will find it.

Related Topics

• Risk Management & Mitigation: the overview and full cycle.
• Risk Register Template and Risk Burn-down Chart Template: the two artefacts this phase keeps current.
• Responding to Risk: the plans and triggers being monitored.
• Estimating Effort and Time: retrospectives as the feedback loop for estimates.
• CMMI: process maturity more broadly.

References

Graduate Attributes

Directly developed

• Critical Thinker: Readers distinguish between early process signals and late product confirmations to decide when intervention is still possible.
• Self-Directed Learner: Readers plan to record lessons learned at the end of each phase for future projects.

Modelled on this page

• Subject Specialist: Discipline-specific techniques such as top-ten risk lists and miniature milestones are applied to keep risk registers current.
• Reflective: The text prompts examination of assumptions by asking what would be done differently next time.

University of Reading Graduate Attributes framework.