6 PROJECT MANAGEMENT: risk

Risk (definition)

An uncertain event or condition that could affect project objectives — time, cost, quality, scope, safety, benefits, or stakeholder satisfaction. Exam-safe definition: "A risk is an uncertain event that may affect project objectives."

Risk vs Issue vs Dependency vs Assumption

• Risk — something uncertain that MIGHT happen (e.g. "supplier may deliver late").

• Issue — something that HAS already happened and needs action (e.g. "supplier has delivered late").

• Dependency — something the project relies on (e.g. "frontend depends on backend API").

• Assumption — something believed true for planning purposes (e.g. "users will have smartphones"). Exam phrase: "A risk is uncertain and needs mitigation or monitoring, while an issue has already occurred and needs action."

Risk planning cycle

Identify (find possible risks) → Assess (estimate likelihood and impact) → Plan response (decide avoid/reduce/transfer/accept) → Implement (carry out mitigation or contingency) → Monitor/review (track changes and update the risk register).

Exam phrase: "Risk management should be continuous. The risk register should be reviewed throughout the project because likelihood, impact and responses can change."

Risk in PRINCE2

Managed formally via: the Risk theme, the Risk Register, stage boundary reviews, Business Case reviews, and Manage by Exception.

Exam phrase: "PRINCE2 is strong for risk governance because risks are documented, owned and reviewed at stage boundaries. Significant risks can be escalated if they threaten tolerances."

Risk in Agile

Reduced through: short iterations, MVPs, early feedback, retrospectives, and incremental delivery — risk is reduced by learning fast rather than by documentation. Exam phrase: "Agile reduces product uncertainty by delivering increments and collecting feedback early, but high-risk projects may still require formal risk governance."

Risk in Waterfall

Waterfall uses upfront planning and documentation, but risks can appear late because testing and feedback happen at the end. Exam phrase: "Waterfall may suit stable projects, but it can increase risk in uncertain software projects because testing and feedback may occur late."

Risk in Lean

Reduces process risks by addressing: Muda (waste), Muri (overburden), Mura (unevenness), Kaizen (continuous improvement), and Jidoka (built-in quality, stopping on defects before they compound).

Inherent software project risks (and typical responses)

• Unclear requirements → wrong product built; addressed via Agile feedback, MVP, user stories.

• Scope creep → time/cost increases; addressed via MoSCoW, change control.

• Technical uncertainty → solution may not work; addressed via prototypes/spikes.

• Poor estimation → unrealistic budget/schedule; addressed via 3-point estimation, reserves.

• Dependency delay → blocks progress; addressed via dependency tracking.

• Low user adoption → benefits not achieved; addressed via user testing/stakeholder engagement.

• Poor communication → misalignment/rework; addressed via RACI, reporting.

• Quality defects → rework/failure; addressed via testing, FMEA, Jidoka.

• Security/privacy → legal/reputational harm; addressed via compliance checks, risk controls.

Exam phrase: "Requirements uncertainty is a major software risk because users often discover what they need after seeing a product. Agile can reduce this risk through iteration and feedback."

Risks to tech innovation/adoption

• Users may reject the technology;

• benefits may be unclear;

• integration may fail;

• technical performance may not meet expectations;

• regulation may change;

• market demand may be overestimated;

• staff may lack skills;

• trust/privacy concerns may reduce adoption.

Exam phrase: "Adoption risk matters because a technically successful product can still fail if users do not trust it, understand it or see enough value in using it."

RACI

Clarifies responsibility:

• Responsible (does the work),

• Accountable (owns the result/decision),

• Consulted (gives input), Informed (kept updated).

• Important: Responsible does the work;

• Accountable owns the outcome — and usually each task should have only ONE accountable person.

Exam phrase: "RACI reduces project risk by clarifying ownership and preventing tasks being duplicated, ignored or delayed due to unclear responsibility."

SWOT

A simple strategic analysis tool: Strengths (internal positives), Weaknesses (internal negatives), Opportunities (external positives), Threats (external negatives). Example (student revision app): Strength = skilled dev team; Weakness = limited time before launch; Opportunity = high student demand; Threat = competing apps. Exam phrase: "SWOT helps identify internal weaknesses and external threats that may become project risks, while also recognising strengths and opportunities that can support success."

Delphi

A structured expert judgement method: experts give views anonymously → responses are summarised → experts revise their views → repeat until consensus.

Useful when: uncertainty is high, data is limited, expert judgement matters, or one dominant person might otherwise bias the discussion.

Exam phrase: "Delphi is useful for risk identification or estimation when data is limited because it gathers expert judgement while reducing dominance bias."

EMV (Expected Monetary Value) and Decision Trees

EMV = probability × impact (summed across outcomes: Total EMV = Σ(probability × outcome)). Example: Option A has 70% chance of £100,000 profit and 30% chance of £20,000 loss → EMV = 0.7(100,000) + 0.3(-20,000) = £64,000. Balanced interpretation: "Although Option A has the higher EMV, it may still be unsuitable for a risk-averse organisation if the downside would threaten project viability" — don't just pick the highest EMV without discussing risk appetite.

Ishikawa / Fishbone diagram

Used for root cause analysis — asks "why is this problem happening?" across categories: people, process, technology, management, resources, environment. Example (project delayed): People = skills gap; Process = slow approvals; Technology = unstable build system; Management = unclear priorities; Resources = hardware unavailable. Exam phrase: "Ishikawa is useful because it helps identify root causes rather than only treating the visible symptom."

Sensitivity analysis

Asks: which variable has the biggest effect on the outcome? (e.g. development cost, user adoption, subscription price, hosting cost). Only need a high-level understanding. Exam phrase: "Sensitivity analysis helps the project manager focus on the assumptions that most affect project success."

Risk matrix

Ranks risks by Likelihood × Impact = Risk score (e.g. scale 1=very low to 5=very high). Responses: Avoid (remove the risk, e.g. choose proven technology), Reduce/Mitigate (lower likelihood or impact, e.g. add testing), Transfer (shift the risk, e.g. insurance/fixed-price contract), Accept (monitor/tolerate a minor low-impact risk). Exam phrase: "A risk matrix helps prioritise attention. High-likelihood, high-impact risks should normally be mitigated or avoided, while low-impact risks may be accepted and monitored."

FMEA (Failure Mode and Effects Analysis)

Identifies how something could fail, its effect, its cause, and how Severe/likely to Occur/hard to Detect it is. RPN (Risk Priority Number) = Severity × Occurrence × Detection. IMPORTANT: higher S, O and D scores always mean WORSE outcomes (severe consequence, likely failure, hard to detect). The highest-priority failure mode is the one with the highest RPN. Exam phrase: "The mitigation should aim to reduce occurrence and/or improve detection. Severity may remain high if the consequence would still be serious if the failure happened."

E-FMEA

Evaluates PROPOSED mitigations, after FMEA has identified and prioritised failures. Approach: 1) start with the highest FMEA risks, 2) propose solutions, 3) rescore S/O/D after mitigation, 4) explain whether the solution reduces risk, 5) remember severity may not reduce even after a good mitigation. Exam phrase: "The mitigation reduces occurrence because the failure is less likely, and improves detection because testing is more likely to catch it. Severity may remain unchanged because the consequence would still be serious if the failure occurred."

FMEA vs Risk Matrix

• Risk Matrix: broad project-level risks, scored via Likelihood × Impact — fast and simple, good for things like supplier delay.

• FMEA: detailed failure modes, scored via Severity × Occurrence × Detection — more detailed/systematic, good for technical or process failure analysis. Exam phrase: "A risk matrix is suitable for broad project risks such as supplier delay, while FMEA is more suitable for analysing detailed technical or process failure modes."

Risk register

Records and tracks risks with fields:

• Risk ID,

• Description (what might happen),

• Cause (why it might happen),

• Impact (effect on project), Likelihood (chance of happening),

• Owner (person responsible),

• Response (avoid/reduce/transfer/accept),

• Status (open/closed/monitoring).

Exam phrase: "A risk register ensures risks are owned, monitored and reviewed rather than only identified once."

Know the four general response categories

• Reduce/Mitigate — lower the likelihood or impact (e.g. add testing, add redundancy)

• Avoid — remove the risk entirely (e.g. choose proven technology instead of experimental)

• Accept — monitor and tolerate it (fine for low-impact, low-likelihood risks)

• Transfer — shift the risk elsewhere (e.g. insurance, fixed-price contract)

Explain “FMEA is an inductive reasoning single point of failure analysis"

FMEA is inductive because it reasons bottom-up — starting from a specific cause/failure and working out its effects — rather than deductive top-down analysis (like a Fault Tree, which starts from a system failure and works backward to find causes).

It's a single point of failure analysis because each failure mode is assessed in isolation, assuming it's the only thing going wrong — it doesn't model combinations of multiple simultaneous failures interacting together.

Criticality vs Risk Priority

Criticality = Severity × Occurrence only.

RPN = Severity × Occurrence × Detection.

The difference is Detection: Criticality is used when you care purely about how bad and how likely a failure is regardless of whether you'd catch it in advance (common in safety-critical analysis, where "we'd have spotted it anyway" isn't good enough). RPN is used for general prioritisation, where a failure that's hard to detect deserves more urgent attention than an equally severe one you'd catch immediately.