Project control

Risk and Issue Control

Turn uncertainty, problems, decisions, and change pressure into owned actions, visible movement, and timely escalation.

What this helps you do

Risk and issue control helps the PM turn messy project reality into a short list of things that need movement. The aim is not to maintain a beautiful register. The aim is to make uncertainty, current problems, blocked decisions, and change pressure visible early enough to protect stage tolerance and business justification.

Use this when

• Setting up project controls during initiation.
• Running weekly control room reviews and preparing highlight reports.
• Supplier, dependency, quality, acceptance, or funding risk is changing quickly.
• The project has too many open actions and nobody can see what matters most.
• Preparing an exception report, stage boundary pack, or recovery reset plan.
• There is a gap between what the team knows and what the sponsor is being told.

What good looks like

• Risks are written as uncertain future events with cause, event, and effect. Issues are written as current problems that already exist.
• Every important item has one owner, one next action, a due date, and a visible status.
• Top risks and issues connect directly to tolerance, milestones, benefits, decisions, or acceptance evidence.
• Old items are challenged. They are closed, reframed, escalated, or converted into decisions rather than carried forward forever.
• The highlight report reflects the real control position, including blocked decisions and exception risk.
• The sponsor can see what help is needed and what will happen if the item does not move.

Minimum viable version

• A combined RAID log covering risks, assumptions, issues, dependencies, decisions, and change pressure if the project is Lite or early-stage.
• Weekly review of the top items, not every line equally. Focus on items that affect tolerance, decisions, milestones, or benefits.
• Clear escalation rule for items that threaten stage tolerance or require authority outside the PM role.
• Owner, due date, next action, and latest update for every active high-priority item.
• Decision log for sponsor or board choices that are blocking progress.

Stronger version

• Separate risk register, issue log, decision log, and change log where volume or governance requires it.
• Risk scoring using probability, impact, proximity, and response confidence, with trends over time.
• Linked decision log so risks and issues that need authority are not hidden in a RAID note.
• Tolerance impact view showing which items threaten time, cost, scope, quality, risk, benefits, or sustainability.
• Recovery triage board for red projects, separating stabilise now, decide this week, replan, and stop/reframe items.

Step-by-step

1. Capture the item clearly. For risks, write cause, uncertain event, and effect. For issues, state the current problem and impact.
2. Classify the item correctly: risk, issue, assumption, dependency, decision, or change. Reclassify when reality changes.
3. Assess impact on stage tolerance, next milestone, product acceptance, benefits, supplier commitments, and sponsor decisions.
4. Assign a single accountable owner. Avoid shared ownership unless one person is clearly responsible for movement.
5. Define the next action in operational terms: avoid, reduce, transfer, accept, resolve, escalate, decide, or monitor.
6. Set a due date and review cadence based on urgency and proximity, not generic monthly reporting.
7. Escalate when the item needs authority, funding, priority trade-off, or tolerance decision outside the PM role.
8. Close or reframe stale items. If nothing has changed for weeks, the item is probably badly written, wrongly owned, or not important enough.

Inputs needed

• Team check-ins, delivery standups, supplier updates, and operational readiness reviews.
• Milestone forecast, tolerance position, acceptance evidence, and quality findings.
• Stakeholder feedback, decision delays, funding questions, policy constraints, and dependency updates.
• Change requests, scope additions, rework signals, and benefit confidence movement.
• Previous highlight reports, exception reports, lessons, and boundary pack evidence.

Outputs produced

• RAID log or separate registers with current owners, next actions, due dates, and status.
• Top-control-items summary for the weekly control room and highlight report.
• Decision log entries for sponsor choices and governance approvals.
• Exception report when tolerance is forecast to be exceeded.
• Recovery triage view when the project needs stabilisation before replanning.

Common mistakes

• Writing vague risk statements such as stakeholder risk, resourcing risk, or supplier risk without cause and effect.
• Confusing risks and issues, then failing to act because the item is not treated as current reality.
• Letting old items linger without challenge, owner movement, or escalation.
• Treating all RAID items equally instead of focusing governance attention on the few that threaten control.
• Recording decisions inside RAID updates where sponsors cannot see they need to act.
• Reporting green while key decisions, acceptance evidence, or dependencies are blocked.

Tailoring notes

• For Lite projects, use a combined RAID and decision view but keep the owner, action, and due date discipline.
• For Standard projects, separate decisions from RAID so governance asks are visible.
• For Enhanced projects, use scored risk registers, trend views, response confidence, and assurance review.
• For Recovery projects, review risks and issues more frequently and separate stabilisation actions from longer-term replanning.
• For supplier-heavy projects, track dependencies, acceptance evidence, and commercial decisions explicitly.
• For agile or hybrid delivery, connect sprint-level blockers to stage tolerance and sponsor decision routes.

Questions PMs usually ask

Related templates

Related tools

PRINCE2 mapping

Maps to the PRINCE2 risk, issue, change, and progress practices. In day-to-day control, these practices work together: risk shows what might happen, issue shows what has happened, change shows what is being requested, and progress shows whether tolerance still holds.