HKSM

Ongoing tracking of risk exposure, checking if responses work, spotting new or changing risks, and keeping stakeholders informed so timely action can be taken.

Purpose & When to Use

Monitor Risks ensures risk responses are carried out, remain effective, and that new risks are captured early. It keeps overall risk exposure visible and aligned with approved risk thresholds.

• Use continuously across the project, with regular risk reviews on a defined cadence.
• Use after major changes, milestones, test results, supplier updates, or lessons learned sessions.
• Use more frequently in high-uncertainty or adaptive environments, integrating with events like stand-ups and reviews.

Mini Flow (How It’s Done)

• Prepare: Review the current risk register/log, risk thresholds, response plans, assumptions, and lessons learned. Confirm risk owners, roles, and key risk indicators (KRIs).
• Gather Data: Collect inputs from status meetings, risk reviews, audits, metrics, trend charts, and stakeholder feedback.
• Analyze: Reassess probability and impact, update priority, evaluate residual and secondary risks, and check overall risk trend or burndown.
• Decide and Act: Trigger planned responses when conditions occur, adapt or add responses as needed, and raise change requests if baselines or reserves must be adjusted.
• Integrate: Align with issue management (for realized risks), change control, performance reporting, procurement, and compliance activities.
• Communicate and Record: Update the risk register/log, status reports, visuals (heat maps, burndown), and lessons learned.

Quality & Acceptance Checklist

• Each high-priority risk has a named owner, clear status, and next action date.
• Triggers and KRIs are defined, measured, and compared to thresholds.
• Planned responses are implemented or queued as actionable tasks in the schedule or backlog.
• Response effectiveness is evaluated; ineffective actions are revised or replaced.
• New, changing, and secondary risks are captured and prioritized promptly.
• Closed risks are retired with rationale; residual risk is documented.
• Cost and schedule reserves are reviewed and adjusted based on current exposure.
• Overall project risk trend is reported (e.g., burndown, heat map) to stakeholders.
• Required change requests are submitted for any baseline or reserve changes.
• Risk information is current, consistent, and accessible in the risk register/log.

Common Mistakes & Exam Traps

• Treating risk monitoring as a one-time event instead of continuous work.
• Focusing only on threats and ignoring opportunities that could be exploited.
• Confusing risks with issues; once a risk occurs, manage it in the issue log while updating the risk record.
• Ignoring secondary risks that arise from executing a response.
• Failing to assess overall project risk trend, not just individual risks.
• Skipping change control when a response affects the approved baselines or reserves.
• Relying only on qualitative ratings and missing trend or reserve-consumption signals.
• Not updating risk owners, triggers, or actions after scope, schedule, or supplier changes.
• Assuming escalation means handing off responsibility; escalate only when thresholds or authority levels are exceeded.
• Mixing up risk reviews (re-prioritize and plan actions) with risk audits (evaluate process and response effectiveness).

PMP Example Question

A project’s key risk indicator exceeds its threshold, and the planned response will add cost and extend the schedule. What should the project manager do next?

1. Implement the response immediately using management reserve.
2. Submit a change request to implement the response and update baselines or reserves.
3. Update the risk register and continue to monitor without action.
4. Escalate to the sponsor to transfer ownership of the risk.

Correct Answer: B — Submit a change request to implement the response and update baselines or reserves.

Explanation: Because the response impacts cost and schedule, follow change control to adjust baselines or reserves. Implementing without approval or only monitoring would not meet governance, and escalation is not needed if it is within the project’s authority.