FIT2002 Chap.9 Project Risk and Response Planning
Project Risk and Response Planning
Project risk is uncertainty that may affect objectives; an issue has already occurred or currently exists. Risk management turns uncertainty into an owned decision by describing cause, uncertain event and effect, then analysing probability, impact and urgency. A risk register supports action only when entries are specific enough to monitor and update.
A colour alone is not analysis.
Responses should match the direction and significance of the risk. Threat choices include avoiding, mitigating, transferring or accepting, while opportunities can be exploited, enhanced, shared or accepted. Each active response needs an owner, action, trigger, timing and residual-risk judgement. Indicators should reveal movement early enough to act.
Assessment answers are strongest when they distinguish preventive action from contingency and state what evidence will cause escalation.
What this chapter covers
- 01
Risk as uncertain effect contrasted with an issue already present
- 02
Cause-event-effect statements that make uncertainty actionable
- 03
Probability, impact, proximity and urgency in qualitative analysis
- 04
Threat and opportunity responses matched to project context
- 05
Risk owners, action owners and explicit decision responsibilities
- 06
Triggers and indicators that support timely escalation or contingency
- 07
Residual and secondary risk after a planned response is applied
Worked example · free
Convert a vague supplier concern into a response plan
- +2Write cause-event-effect: because certification evidence is incomplete, approval may not arrive before integration, causing the pilot milestone to move.
- +2Assess probability and schedule impact using defined scales and record the six-week proximity rather than relying on the word high alone.
- +2Mitigate by agreeing weekly evidence checkpoints and providing early review support for missing certification items.
- +2Prepare a contingency such as a limited sandbox integration or approved alternate vendor path if the trigger is crossed.
- +2Assign the integration lead as risk owner and trigger escalation if required evidence remains incomplete three weeks before integration.
Key terms
- Project Risk
- An uncertain event or condition that, if it occurs, can affect one or more project objectives positively or negatively. Risk wording should expose the uncertainty and consequence.
- Project Issue
- A condition or event that already exists and requires present action or decision. Treating an issue as a future risk can delay the response that is already needed.
- Risk Owner
- The person accountable for monitoring a particular risk, ensuring responses remain appropriate and escalating according to agreed thresholds. The owner may coordinate several action owners.
- Risk Trigger
- An observable condition that signals a response, escalation or contingency decision. An effective trigger is early enough to preserve meaningful choice.
- Residual Risk
- The uncertainty remaining after the planned response has been considered or implemented. It should be consciously accepted, further treated or escalated rather than assumed away.
- Contingency Reserve
- Time or budget held for identified uncertainty within the plan. Its basis and authority should be explicit so it is released for the intended exposure.
Project Risk and Response Planning FAQ
How can I tell whether something is a risk or an issue?
Ask whether the uncertain event has already happened. If a supplier might miss a date, it remains a risk; if the contracted date has passed without delivery, the project has an issue. The same subject can move from risk to issue over time, so update the register and action process rather than keeping obsolete wording.
What makes a risk statement useful?
Use a cause-event-effect structure. State the existing condition, the uncertain event that may occur, and the objective consequence. This separates what can be influenced from what must be monitored and what matters to the project. Vague entries such as “technology risk” provide no basis for estimating exposure, choosing a response or defining a trigger.
Is a red rating enough to justify escalation?
A rating summarises an agreed analysis but should not replace it. Define the probability and impact scales, include proximity or urgency where relevant, and connect escalation to a threshold or trigger. A moderate risk close to a decision deadline may need faster attention than a nominally red risk whose consequence is distant and already well controlled.
Assessment move
Rewrite weak risk labels into cause-event-effect sentences until the pattern is automatic. Build a compact register with probability, impact, proximity, owner, preventive response, contingency, trigger and residual rating. Use defined scales and explain why each rating fits the evidence instead of selecting colours intuitively.
Practise distinguishing an action that reduces probability or impact from a fallback used after a trigger. Include opportunity risks so response vocabulary does not become threat-only. Change a fact in each scenario, such as the deadline moving closer, and reconsider priority rather than preserving an old score.
End every response with monitoring evidence and an escalation decision; this demonstrates that risk management is continuous governance, not a document prepared once at project start.
Working through Project Risk and Response Planning in FIT2002? Sia is AskSia’s AI Project Management tutor — ask any FIT2002 Project Risk and Response Planning question and get a clear, step-by-step explanation grounded in how FIT2002 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
