Risk and Issue Management
Risk versus issue
A risk is an uncertain event that, if it occurs, will affect objectives - it has not happened yet, and it has a probability. An issue has already happened and must be managed now. Both should sit in a single log (often a RAID log covering risks, assumptions, issues, dependencies).
The risk process
Identify (workshops, checklists, risk breakdown structure, lessons learned) → assess (probability, impact, proximity, using a probability–impact matrix) → plan responses → implement → review and communicate. Record a risk owner (accountable for managing the risk) and separate action owners. Risk appetite is the willingness to take risk; tolerance is the measurable limit before escalation.
Threat responses: avoid (change the plan to remove the risk), reduce/mitigate (lower probability or impact), transfer (insurance, fixed-price contract - note the risk is transferred, not removed), accept (with contingency), and escalate. Opportunity responses: exploit, enhance, share, accept. Be alert to secondary risks created by a response and to residual risk left after it.
Traps
Calling a current problem a risk; assuming transfer removes liability entirely; assigning every risk to the project manager by default; treating the register as a document rather than a live tool.
Rule of thumb
A risk should be owned by the person best placed to influence it - often a technical lead or business owner, not the PM - and should be reviewed at every progress meeting, not only at gate reviews.