Risk management is one of the most practical competencies you develop in project-based work: it turns uncertainty into structured decisions, supports governance, and improves delivery outcomes. For Stellenbosch Business School (SBS)–style project management and quality management curricula, risk identification and response planning are evaluated not only as “process knowledge,” but as judgment under constraints—time, cost, quality, stakeholder expectations, and compliance. These exam notes explain how to identify, analyse, prioritise, and manage risks across the project lifecycle, with South Africa–relevant examples and decision-ready frameworks you can apply in typical assessment tasks.
Section 1: Risk Foundations and the Project Risk Management Process (SBS / PMBOK-aligned)
At SBS, and broadly across South African business school project management coursework, risk is treated as uncertainty that affects project objectives (scope, schedule, cost, quality, benefits, and stakeholder satisfaction). The key exam skill is to link risk thinking to concrete actions: evidence gathering, ownership assignment, response selection, and continuous monitoring. Risk management is also not an “extra” activity—it is integrated into planning, execution, and governance.
Risk: Definitions, Types, and Why It Matters
Risk is usually defined as the combination of:
- Probability (likelihood that an event will occur)
- Impact (effect on at least one project objective)
In exam answers, explicitly stating that “risk affects objectives” earns marks because it clarifies scope: risk management is not limited to financial threats; it also covers opportunities, quality failures, reputational damage, and stakeholder misalignment.
Common risk types you should mention (with examples):
-
Schedule risks
- Procurement delays due to supplier turnaround times
- Skill availability constraints (e.g., scarce engineering staff)
- Regulatory approval timelines extending beyond planned dates
-
Cost risks
- Budget overruns caused by rework
- Currency fluctuations impacting imported equipment
- Changes in labour rates or contractor pricing
-
Quality risks
- Deliverables not meeting specifications
- Defects discovered late, increasing rework cost
- Inspection/test failures and non-compliance
-
Scope risks
- Requirements not clearly defined, leading to “scope creep”
- Stakeholder requests changing after sign-off
- Misinterpretation of business needs
-
Operational / technical risks
- Technology underperformance compared to expected performance
- Integration failures between systems
- Dependence on external platforms/telecoms
-
Compliance and legal risks
- Failure to meet statutory or industry regulations
- Data protection and information security non-compliance
- Contractual disputes and SLA breaches
-
People and stakeholder risks
- Low engagement from key decision-makers
- Poor change management affecting adoption
- Conflict between teams leading to slowed delivery
-
Reputation risks
- Community concerns or media scrutiny affecting approvals
- Service failures leading to loss of trust
Opportunities are the “positive risk” side of the same coin. In high-scoring exam responses, you explicitly treat opportunities as risks with positive impact: they also need owners, triggers, and response plans.
The Project Risk Management Lifecycle (Core Steps)
A widely taught SBS-compatible structure is:
- Plan Risk Management
- Identify Risks
- Perform Qualitative Risk Analysis
- Perform Quantitative Risk Analysis (optional or when needed)
- Plan Risk Responses
- Implement Risk Responses
- Monitor and Control Risks
In many assessments, marks are awarded for showing that you can move from one step to the next logically. The simplest way to score well is to explain not only what to do, but why that step exists.
Step 1: Plan Risk Management (How You Will Manage Risk)
Planning defines how risk management will run. Typical exam elements:
- Risk methodology: qualitative (scoring) vs quantitative (models)
- Roles and responsibilities:
- Risk owner (responsible for response)
- Risk champion (facilitator, often PMO)
- Stakeholder input sources (finance, legal, QA, engineering)
- Timing:
- risk reviews at each stage gate
- ongoing identification during sprint planning (if Agile)
- Risk thresholds and appetite:
- e.g., “any risk with impact ≥ High triggers a steering committee briefing”
- Reporting frequency and format:
- risk register updates weekly or per milestone
- risk heat map in monthly governance packs
- Tools and data sources:
- historical project data
- expert judgment
- checklists
- templates for probability/impact scoring
Exam-style tip: write a short paragraph that links risk planning to governance. For example: “Planning risk management ensures consistent evaluation and decision-making, preventing ad hoc risk discussion that leads to late escalation.”
Step 2: Identify Risks (Making the Invisible Visible)
Risk identification aims to generate a comprehensive set of uncertainties before they become problems. You should list multiple identification approaches, not just one.
Common risk identification techniques:
- Brainstorming / workshops
- including cross-functional experts (QA, finance, procurement, operations)
- Checklists
- based on lessons learned from similar projects
- Assumption analysis
- identify assumptions that could fail (e.g., “supplier will deliver within 10 working days”)
- Diagramming
- cause-and-effect (fishbone)
- flowcharts to reveal bottlenecks and handover risks
- SWOT for project context
- helps capture internal/external uncertainties
- Documentation review
- business case, SOW, contracts, technical design, compliance requirements
- Interviews and expert judgment
- project managers, senior engineers, legal officers
- Historical data and templates
- prior risk registers and incident reports
High-scoring exam answers often include “identify risks using both top-down and bottom-up inputs.”
Risk Breakdown Structure (RBS): How to Categorise
To avoid missing key risks, you classify risks using a Risk Breakdown Structure (RBS). In practice it can mirror the project’s WBS (Work Breakdown Structure) or management domains.
A sample RBS for a typical construction/IT hybrid project:
- Project management
- Technical delivery
- Procurement and supply chain
- QA and testing
- Operations handover and training
- Stakeholders and change management
- Legal, compliance, and contracts
- Health, safety, environment (HSE)
- Finance and reporting
The RBS becomes the “map” for risk identification. When you later do qualitative scoring, categories help you compare patterns.
Step 3: Qualitative Risk Analysis (Prioritise Fast)
Qualitative analysis ranks risks based on probability and impact without heavy modelling. Typical output:
- a risk register entry for each risk with:
- description
- probability rating
- impact rating
- overall risk score (or risk level)
- category (schedule/cost/quality/etc.)
- a heat map for visual prioritisation
- a list of “top risks” for response planning
A common exam format uses a 5×5 matrix:
- Probability: Very Low (1) to Very High (5)
- Impact: Very Low (1) to Very High (5)
Overall risk score = probability × impact.
Example (numerical):
- Risk A: Supplier lead time longer than contract by >20 days
- Probability: 4
- Impact: 5
- Score: 20 → High/Extreme
If the exam question asks for “prioritisation,” you should show your reasoning with that structure, not just list risks.
Step 4: Quantitative Risk Analysis (Optional but Powerful)
Quantitative analysis uses numerical methods (e.g., expected monetary value, decision trees, Monte Carlo simulation). Not all exams require it, but when you include it, keep it coherent with earlier qualitative results.
Typical quantitative methods you may mention:
- EMV (Expected Monetary Value)
- EMV = Probability of event × Monetary impact
- Decision trees
- evaluate choices under uncertainty
- Monte Carlo simulation
- simulate schedule/cost distributions and provide confidence intervals
In South Africa, exams often appreciate when you connect quantitative analysis to procurement and budget contingency decisions, since finance teams often ask for numerical justification.
Step 5: Plan Risk Responses (Turn Rankings into Decisions)
Response planning is where risk management becomes governance. Responses should be:
- appropriate to threat vs opportunity
- feasible within the project’s constraints
- owned by someone
- supported by triggers and contingency actions
Key response strategies for threats:
- Avoid (eliminate risk cause)
- Transfer (shift to another party—insurance, contract clauses)
- Mitigate (reduce probability or impact)
- Accept (no planned change; monitor and use contingency if it occurs)
For opportunities:
- Exploit (ensure opportunity happens)
- Enhance (increase probability/impact)
- Share (partner to capture benefits)
- Accept (seize if it occurs; limited proactive action)
An exam answer that includes all four threat strategies and all four opportunity strategies typically scores well.
Step 6–7: Implement, Monitor, and Control
Risk management continues after planning. Monitoring and control includes:
- tracking risk indicators
- updating risk probability/impact as conditions change
- verifying that response actions were effective
- re-planning when new risks appear
- ensuring communication to governance structures
A common evaluation criterion is whether students understand that:
- risk is dynamic,
- new information changes risk levels,
- and risk registers require ongoing maintenance.
Example: A Mini Case Study for SBS-style Answers
Consider an SBS-type scenario: a project to implement a student learning portal at a university. Key assumptions:
- vendors will deliver components on schedule,
- user authentication integration will succeed,
- regulatory requirements for data protection are fully met by design.
Risks discovered during planning:
- Integration delays due to legacy system incompatibilities (schedule/technical threat)
- Vendor staff turnover causing slower development (people/vendor threat)
- Data privacy controls not fully aligned to legal requirements (compliance/quality threat)
- Opportunity: early adoption by students leading to increased engagement metrics (benefit opportunity)
Qualitative analysis prioritises #3 and #1 as top risks due to high impact. Response planning then:
- for #3 (compliance threat): mitigate with security review and compliance checklist; avoid by adjusting design choices; assign legal owner
- for #1: mitigate with interface testing early and incremental delivery; transfer small parts through clearer contract milestones (where possible)
This example illustrates how the risk lifecycle links directly to actions and owners.
Section 2: Identifying Project Risks in Practice—Techniques, Sources, and a Risk Register That Examiners Trust
Identification is often where students lose marks: they list risks without evidence, without linking to assumptions, without categorising them, and without demonstrating coverage. Strong SBS-aligned exam responses treat risk identification as disciplined information work.
Create a Risk Identification Environment (Workshops, Inputs, and Evidence)
Risk identification requires the right participants. A typical high-quality workshop includes:
- Project Manager (facilitates scope, timeline, governance)
- Technical Lead (identifies technical unknowns and integration issues)
- QA / Quality Manager (identifies specification and testing risks)
- Procurement / Vendor Manager (identifies supplier risks, lead times, contract issues)
- Finance (identifies budget constraints, currency exposure, payment terms)
- Legal / Compliance (identifies regulatory, contract, data protection requirements)
- Operations / End-user representatives (identify adoption and handover risks)
- HSE (for construction/industrial projects)
Even in non-construction projects, “end-user” and “compliance” participation matters because many risks originate outside engineering.
Sources of Risks: Where They Really Come From
A strong identification section in your exam answer should explicitly reference multiple data sources:
-
Project documents
- business case assumptions
- project charter
- requirements specification and functional design
- contract terms and SLAs
- governance and reporting requirements
- change control procedures
-
Historical lessons learned
- prior project risk registers
- issue logs and incident reports
- post-mortems from similar programmes
-
External environment
- regulatory updates
- market conditions and inflation/currency movement
- labour market constraints
- infrastructure constraints (e.g., power reliability)
-
Stakeholder environment
- stakeholder influence mapping and engagement status
- decision-making capacity and responsiveness
- communication gaps
-
Technical environment
- dependencies on third-party systems
- maturity of technology used
- integration complexity
Assumption Mapping: A Shortcut to High-Quality Risks
Assumptions are hidden risk multipliers. Examiners like to see that you convert assumptions into explicit risks.
Example of a typical assumption:
- “The contractor will submit monthly progress claims by the 25th of every month.”
If that assumption fails, schedule and cash flow risk emerges:
- late claims delay payment and cause downstream contractor cash shortages.
- contractors respond by slowing work or requesting re-prioritisation.
A good risk statement explicitly includes cause and impact:
- Risk: Monthly progress claim submissions slip past the 25th due to contractor administrative constraints.
- Impact: Cash flow delays and potential contractor schedule rescheduling.
- Trigger: invoice claim submission date > 5 business days late for two consecutive months.
- Response owner: Finance liaison / Contract manager.
Risk Statements: How to Write Them for Maximum Marks
A risk statement should be:
- Concise but specific
- includes the event, the cause, and the impact (at least to a degree)
- stated as a future uncertain event, not as a past issue
A common student mistake:
- “The project might be delayed.”
This is too vague.
A stronger version:
- “If vendor delivery is delayed beyond the agreed lead time of 10 working days, then critical integration tasks will be postponed, pushing the go-live milestone by at least 2 weeks.”
Even without detailed probabilities, clarity improves scoring because it makes response planning feasible.
Use Root Cause Thinking (Fishbone and 5 Whys)
Risk identification improves when you look at underlying causes. Two exam-friendly tools:
- Cause-and-effect (fishbone)
Categories like: People, Process, Technology, Materials, Environment, Management. - 5 Whys
Start from a feared outcome (e.g., “rework increases”) and ask “why” repeatedly to reveal actual risk drivers (e.g., unclear specifications, inspection delays).
If you can show one example in an exam answer—like “defects discovered late”—then expand how it leads to multiple risk entries (testing insufficiency, inadequate QA schedule, unclear acceptance criteria), you demonstrate mastery of cause-to-risk translation.
Building the Risk Register (The Examiner’s Favourite Artefact)
A risk register is the central document where risks live. Your exam answer should describe the elements of a risk register and how they are populated and used.
A typical risk register entry includes:
- Risk ID (e.g., R1, R2)
- Risk statement (event + cause + impact)
- Category (schedule/cost/quality/compliance/people/etc.)
- Probability rating
- Impact rating
- Overall score / risk level
- Risk owner
- Response strategy (avoid/transfer/mitigate/accept; exploit/enhance/share/accept)
- Planned response actions
- Triggers / symptoms
- Contingency plan (what happens if risk occurs)
- Status (open, closed, watching)
- Date last updated
- Assumptions / evidence supporting the assessment
Example Risk Register Snippet (Illustrative)
| ID | Risk Category | Risk Statement (Threat) | Prob (1-5) | Impact (1-5) | Score | Risk Level | Owner | Response Strategy |
|---|---|---|---|---|---|---|---|---|
| R3 | Compliance/Quality | Data privacy controls not aligned with legal requirements leading to rework and delivery delay | 4 | 5 | 20 | Extreme | Legal & QA Lead | Mitigate + Avoid Design Choices |
| R1 | Schedule/Technical | Legacy system incompatibility delays integration and impacts go-live | 3 | 5 | 15 | High | Technical Lead | Mitigate |
The above illustrates how to connect identification to scoring and response planning.
Risk Prioritisation: From “Lots of Risks” to “Manageable Top Risks”
Examiners often ask: “Which risks should be addressed first and why?” The correct answer is not “all risks equally.” It’s:
- prioritise by risk score (probability × impact),
- consider proximity to deadlines (near-term risks deserve earlier action),
- consider response cost vs value (do not over-engineer low-value responses),
- factor in risk interdependencies (one risk may trigger another).
Risk Interdependency: A Crucial Exam Theme
Risks rarely exist in isolation. Example:
- Vendor delivery delay (schedule risk)
- leads to rushed integration testing (quality risk)
- increases defect rate (quality risk)
- increases rework and cost overruns (cost risk)
- potentially triggers contractual penalties (legal risk)
A high-scoring response shows that you recognise chains of risk and include those in responses (e.g., you mitigate schedule risk partly by protecting quality time for testing).
Common Pitfalls in Risk Identification (Avoid These)
- Using only one technique
- Examiners expect triangulation: workshops + document review + expert judgment.
- Writing issues as risks
- Issues are already happening; risks are uncertain future events.
- Vague risk statements
- “Quality issues may occur” without specifics.
- No ownership
- Risk must be assigned to someone.
- No triggers
- Without triggers, monitoring becomes generic.
- No link to assumptions
- Missing assumption analysis reduces evidence quality.
Mini Case: University IT Transformation (Evidence-Based Risks)
Imagine a project to modernise a university’s admissions and student portal. Key evidence during identification:
- analytics show high peak loads during registration weeks,
- legacy systems have inconsistent API responses,
- the data privacy officer warns about incomplete consent logging for certain processes.
Risks identified:
- Performance risk: peak load causes system slowdowns; impact: registration delays and reputational harm.
- Integration risk: API inconsistencies disrupt admissions workflows; impact: schedule slip.
- Compliance risk: missing consent logging leads to non-compliance; impact: rework and potential suspension of features.
- Change management risk: staff resist process changes; impact: data entry errors and adoption failure.
This case demonstrates how identification draws from:
- operational data,
- technical documentation,
- compliance feedback,
- stakeholder behaviour.
Section 3: Analysing and Prioritising Risks—Qualitative Scoring, Quantitative Methods, and Decision Logic
Once risks are identified and registered, the next challenge is analysis. Analysis turns a list into a decision framework. In SBS and similar business school settings, examiners look for whether your prioritisation method is consistent and whether you can justify response choices based on analysis results.
Qualitative Risk Analysis: Probability–Impact Scoring (Standard and Defensible)
Qualitative analysis answers:
- Which risks are most important?
- Why do we prioritise these?
A probability–impact matrix is the most common exam method. The scoring model should be consistent with the ratings you define. Provide rating definitions, not just numbers.
Example Rating Scale (You Can Use)
Probability (P):
- 1 = Very unlikely
- 2 = Unlikely
- 3 = Possible
- 4 = Likely
- 5 = Very likely
Impact (I):
- 1 = Negligible (no meaningful effect)
- 2 = Minor (manageable within baseline)
- 3 = Moderate (requires adjustments)
- 4 = Major (baseline threatened; mitigation needed)
- 5 = Severe (could jeopardise objectives; escalation required)
Then risk score:
- Score = P × I
Exam scoring logic: show how a risk with (P=4, I=5) outranks one with (P=2, I=4), even if the impact seems similar, because probability influences expected exposure.
Sensitivity to Scoring Bias (How to Mention It in an Exam)
Students sometimes treat scoring as purely mechanical. A strong response includes brief risk calibration concepts:
- avoid optimistic bias by challenging assumptions,
- use evidence and past data to justify ratings,
- involve cross-functional evaluators,
- perform a “sanity check” workshop after the initial scoring.
You do not need to run advanced workshops in the exam scenario—but mentioning bias controls shows maturity.
Risk Thresholds and Risk Appetite: From Scores to Actions
Risk appetite defines how much uncertainty the organisation accepts. It guides whether a risk needs:
- mitigation plan,
- escalation to steering committee,
- or simply monitoring.
A typical “action threshold” example:
- Score ≥ 15 → require response plan and named owner actions
- Score 8–14 → require monitoring and contingency readiness
- Score ≤ 7 → accept and watch
If a question asks “what do you do with top risks,” you can apply such thresholds.
Quantitative Analysis: When Probability and Impact Need Numbers
Qualitative analysis prioritises. Quantitative analysis refines by:
- calculating expected cost/schedule impact,
- supporting investment decisions on mitigation options.
EMV (Expected Monetary Value) Example
Suppose the cost impact of a compliance failure is R200,000, and the probability is 20% (0.2).
- EMV = 0.2 × 200,000 = R40,000
If an additional mitigation measure costs R25,000 and reduces probability to 10% (0.1):
- New EMV = 0.1 × 200,000 = R20,000
- Expected benefit = R40,000 − R20,000 = R20,000
- Net expected effect = benefit − mitigation cost = R20,000 − R25,000 = −R5,000
In this simplified scenario, mitigation might not be cost-effective on expected value alone—though in real governance you might still mitigate because:
- non-compliance may trigger legal penalties beyond the cost estimate,
- the organisation has low tolerance for compliance failures (risk appetite),
- reputational harm and operational shutdown are not fully captured in the cost number.
Exam angle: show you understand expected value is not the only decision factor.
Decision Trees: Comparing Response Options
A decision tree helps compare multiple response strategies under uncertainty. For example, schedule risk due to vendor delays may lead to:
- Option A: pay for expedited shipping (higher cost, lower probability of delay)
- Option B: accept risk and plan overtime internally if delays occur (moderate cost, moderate probability)
- Option C: transfer risk to vendor with contract penalties (legal cost and enforcement uncertainty)
Even if you do not draw the tree in an exam, describe its logic:
- decision node (choose response)
- chance nodes (probability of delay scenarios)
- outcome costs (schedule penalty, rework, overtime)
- compute expected totals
Monte Carlo Simulation (If the Exam Mentions Schedule Uncertainty)
For schedule, Monte Carlo simulation produces a distribution of completion dates rather than a single estimate. You might mention:
- you model uncertain activity durations,
- you define distributions based on historical data or expert estimation,
- you simulate many runs,
- you report confidence levels:
- “X% chance of completing by date Y.”
If your exam question expects quantitative reasoning, stating:
- “confidence intervals support contingency planning”
is enough.
Risk Interactions and Correlations (Advanced but Useful)
Quantitative methods can go wrong if you assume independence. Example:
- Vendor delay (schedule) increases integration defect probability (quality).
- In that case, risks are correlated.
In an exam answer, you can acknowledge:
- “interdependent risks require integrated responses”
without claiming you ran a correlation model. Examiners appreciate the conceptual maturity.
A Worked Example: Prioritisation with a Consistent Logic
Assume five risks in a project:
| Risk | Category | Prob (1-5) | Impact (1-5) | Score |
|---|---|---|---|---|
| R1 Integration delay due to legacy incompatibility | Schedule/Technical | 3 | 5 | 15 |
| R2 Compliance misalignment causing rework | Compliance/Quality | 4 | 5 | 20 |
| R3 Procurement delay causing cost pressure | Cost/Schedule | 4 | 3 | 12 |
| R4 Stakeholder misalignment causing scope changes | Scope/People | 3 | 3 | 9 |
| R5 Staff turnover slowing delivery | People | 2 | 4 | 8 |
If risk threshold is:
- ≥15: Extreme/High—mandatory response actions
- 8–14: Moderate—monitor and prepare contingency
- ≤7: Low—accept/watch
Then:
- R2 is top priority (score 20)
- R1 next (score 15)
- R3 moderate
- R4 moderate
- R5 moderate-low
This step-by-step explanation is exactly what examiners want: prioritisation based on the scoring system.
Linking Analysis to Response: The “So What?” Requirement
Students often stop at analysis. But management demands response design. Your analysis should directly feed into:
- whether you should avoid, mitigate, transfer, or accept,
- what kind of controls are appropriate (preventive vs detective),
- who owns the response,
- what triggers indicate response escalation.
For example:
- R2 compliance misalignment (high impact) → avoid/mitigate with compliance review, QA gates, legal sign-off
- R1 integration delay (high impact on schedule) → mitigate with early integration testing, interface contract clarity
Opportunity Analysis (Often Overlooked)
If the exam question includes opportunities, treat them similarly:
- opportunities have probability and positive impact
- response strategies: exploit, enhance, share, accept
Example:
- Opportunity: early procurement of a key component due to supplier promotions reduces costs.
- You might enhance by negotiating price locks, or exploit by accelerating procurement.
A complete risk management answer mentions both threats and opportunities, even if the detailed scoring focuses on threats.
Section 4: Risk Response Planning and Implementation—Avoid, Transfer, Mitigate, Accept (and Monitoring Controls)
Response planning is where you demonstrate command of risk management as an operational system. A high-quality SBS-style exam answer includes:
- response strategy selection,
- specific actions,
- contingency planning,
- triggers,
- ownership,
- monitoring controls,
- and clear communication/reporting logic.
Designing Risk Responses: Threat Strategies
For threats, four canonical strategies apply:
-
Avoid
- eliminate the cause of risk or stop the risky activity
- Examples:
- redesign a process to remove a compliance-sensitive data flow
- choose a proven technology stack instead of an untested platform
-
Transfer
- shift impact to another party
- Examples:
- insurance policies
- contract clauses with performance penalties
- outsourcing components with defined acceptance criteria
-
Mitigate
- reduce probability and/or impact
- Examples:
- early testing and integration to reduce late surprises
- redundancy in critical supplier capacity
- training and SOPs to reduce human error
-
Accept
- do nothing proactive, but maintain contingency plans
- Examples:
- allow risk if it is low score
- reserve contingency budget/time and monitor triggers
Exam nuance: accepting a risk is still a decision. You must state how you will monitor it and what contingency you will use if it occurs.
Designing Risk Responses: Opportunity Strategies
For opportunities:
-
Exploit
- take action to ensure opportunity occurs
- Example: commit resources early to lock in a beneficial schedule window
-
Enhance
- increase probability or impact
- Example: invest in additional marketing to increase adoption rates
-
Share
- partner to capture benefits
- Example: revenue-sharing or joint marketing with a strategic partner
-
Accept
- remain ready to take advantage if it occurs
- Example: keep backlog capacity to implement improvements if timing aligns
Response Planning Must Include Actions, Triggers, and Contingency
A frequent exam loss: listing “mitigation” but not specifying what “mitigation” means.
A robust response plan should cover:
- Primary response actions
- preventive and corrective actions
- Contingency response
- actions if the risk occurs (and who decides)
- Triggers
- indicators of risk materialisation (leading indicators)
- Response owner
- individual/team accountable
- Timing
- when actions will happen
- Resources
- cost/time impact of response
- Effectiveness measures
- how you will know response worked (e.g., reduced defect escape rate)
Example Response Plans (Threats)
Below are exam-ready response examples aligned to typical project categories.
Threat Example 1: Compliance misalignment (High impact)
- Risk: Data privacy controls not aligned with legal requirements leading to rework and delivery delay.
- Category: Compliance / Quality
- Strategy: Mitigate + Avoid elements of risky design
- Actions:
- conduct legal and QA compliance review at architecture gate
- implement consent logging and data minimisation controls
- introduce a compliance test checklist for acceptance
- require sign-off from legal/compliance officer before release
- Triggers:
- audit findings show missing consent fields in test environment
- legal review escalates “non-compliance probable”
- Owner: Legal & QA Lead
- Contingency:
- if gaps found after development, pause release and implement required controls before further deployment; adjust schedule with formal change request
Threat Example 2: Integration delay due to legacy incompatibility (Schedule impact)
- Risk: Legacy system incompatibility delays integration and impacts go-live.
- Category: Schedule / Technical
- Strategy: Mitigate (prevent late discovery)
- Actions:
- map interface contracts early
- build a mock integration layer for early testing
- schedule interface testing sprint-by-sprint
- include acceptance criteria and defect severity thresholds
- negotiate vendor support hours in contract for integration issues
- Triggers:
- integration test pass rate < 80% for two consecutive iterations
- repeated failures in same API endpoint patterns
- Owner: Technical Lead
- Contingency:
- if critical interface fails, implement temporary workaround (manual processes or staged cutover) and replan go-live with governance approval
Transfer and Insurance: When It Works (and When It Doesn’t)
Transfer is appealing but must match risk nature.
- Transfer is suitable when:
- counterpart can control the risk
- contracts define performance clearly
- enforcement is realistic
- Transfer is risky when:
- risk is internal (e.g., poor requirements)
- counterpart cannot control it
- regulatory responsibility remains with the organisation
An SBS-quality answer says something like: “Transfer reduces exposure but does not remove accountability; governance still requires monitoring.”
Acceptance: Make It Responsible
Risk acceptance must not mean “ignore it.” A responsible acceptance includes:
- monitoring plan
- contingency reserve (time/cost)
- triggers to reclassify risk
Example:
- Risk score is low (e.g., 8).
- Response: accept and allocate contingency of R15,000 and a small time buffer of 2 days.
- Monitoring: monthly risk review; if probability increases from 2 to 3, re-plan response.
Even if the exam scenario doesn’t provide these exact numbers, it’s good to show you understand how acceptance is managed.
Opportunity Responses: Capture Benefits Without Creating New Threats
Opportunity exploitation can create threats if resources are redirected without controls.
Example:
- Opportunity: supplier offers a discount for early purchase.
- Exploit response:
- place early order to reduce cost
- But you must mitigate:
- ensure delivery lead time and storage conditions are feasible
- avoid mismatch between early procurement and evolving requirements
So an opportunity plan includes:
- actions + triggers + contingency
- and ensures the opportunity response doesn’t generate compliance/quality risks.
Implementing Risk Responses: How to Operationalise
Implementation requires integrating risk actions into the project plan. In exam terms, demonstrate alignment with:
- schedule baseline (activities updated)
- cost baseline (budget for responses)
- quality plan (QA checks)
- procurement plan (contract milestones)
- communication plan (reporting schedule)
A response that is not in the project plan often fails. Examiners appreciate answers that emphasise integration.
Response ownership and governance
- Assign a risk owner who has authority to act.
- Risk owner reports status in risk review meetings.
- For extreme risks, escalate to steering committee when triggers occur.
Monitoring and Control: Prevent Risk Blindness
Monitoring and controlling risks includes:
- risk audits
- periodic review of register quality and changes
- tracking risk indicators
- triggers and leading indicators
- variance monitoring
- schedule variance, defect trend, vendor performance
- reassessment cycles
- re-score probability and impact after key events
- closing risks
- define closure criteria (e.g., “integration passes acceptance tests and vendor provides written confirmation”)
Risk Metrics: What to Track
For a project, risk metrics can include:
- number of new risks identified per month
- percentage of top risks with active responses
- closure rate of risks
- trends in probability/impact scores for top risks
- time-to-mitigate after trigger detection
An exam answer that proposes metrics shows you understand risk management as measurable governance, not just documentation.
Example: Monitoring Triggers in an Exam Scenario
Suppose the integration risk has trigger:
- “Repeated integration test failures on critical API endpoints for two consecutive sprints.”
Monitoring actions:
- QA leads report test failure counts weekly.
- PM checks risk register during weekly stand-ups.
- If trigger occurs:
- risk re-scored (probability increases)
- response actions intensified:
- allocate additional integration support
- pause non-critical development until integration stabilises
This shows cause-effect between monitoring and decisions.
Section 5: Integrated Risk Management with Quality Management—Controls, Governance, and Common Exam Scenarios (South Africa Context)
In many South African business school project management modules—including those aligned to project risk and quality management—risk and quality are treated as tightly coupled. Quality failures are not just “defects”; they are risks to performance, compliance, and stakeholder outcomes. Additionally, governance and stakeholder communication shape risk visibility and response speed.
Risk–Quality Link: The Quality Plan as a Risk Response Tool
A quality management plan is essentially a set of controls that reduce the likelihood that deliverables fail acceptance criteria. Controls can be preventive or detective.
Common quality controls that function as risk responses:
- specification clarity workshops (reduces scope/requirements risk)
- design reviews (reduces technical and quality risk)
- test planning and coverage analysis (reduces defect escape risk)
- inspection and acceptance criteria (detective controls)
- change control gates (prevents uncontrolled scope changes)
- training and SOPs (reduces human error)
In exam answers, explain that:
- risk management identifies uncertainties,
- quality management reduces failure probability and improves early detection.
Governance and Escalation: Who Decides What
Governance ensures decisions happen fast enough to be effective. Key governance structures:
- Project Steering Committee
- approves major budget/time changes
- reviews top risks
- Risk review meetings
- update risk register and action status
- Stage-gate reviews
- allow acceptance or rework based on quality gates
- Change control board
- manages scope changes and risk implications
An SBS-quality response states:
- “Escalate when triggers occur or when risk score crosses threshold.”
Stakeholder Engagement as a Risk Control
Stakeholder misalignment is a frequent root cause of project risk in exam cases. Quality and risk both depend on:
- clarity of requirements,
- timely decisions,
- communication channels,
- and involvement of decision-makers.
Examples of stakeholder-related risk controls:
- define RACI for decision-making
- schedule regular steering committee updates
- maintain stakeholder engagement plan
- use feedback loops (UAT, pilot programmes)
In exams, if you mention stakeholder risks without linking to engagement controls, the answer feels incomplete.
A Comprehensive Exam Scenario: Putting It All Together
Below is a unified scenario you can use as a template in written exams.
Scenario Context (University Project)
A Stellenbosch Business School–style case involves a project to implement a new student portal integrating admissions data, course registration, and personalised support features. The project includes:
- technical integration with legacy systems,
- compliance with data protection requirements,
- and adoption by staff and students.
Project timeline (example for exam logic):
- Planning phase: weeks 1–4
- Build + integration: weeks 5–16
- QA and pilot: weeks 17–20
- Go-live: week 21
Key assumptions:
- legacy system APIs remain stable during weeks 5–16
- vendor support will respond within agreed turnaround times
- legal/compliance sign-off will be granted at architecture gate
Risks Identified (Example Top Set)
-
R2 Compliance misalignment
- cause: consent logging and data minimisation controls missing
- impact: rework and possible feature suspension
- score: 20 (High/Extreme)
-
R1 Integration delay due to legacy incompatibility
- cause: legacy APIs inconsistent responses
- impact: go-live delay and rushed testing
- score: 15 (High)
-
R3 Vendor turnaround risk
- cause: vendor staff turnover reduces responsiveness
- impact: slowed integration and defect resolution
- score: 12 (Moderate)
-
R4 Stakeholder misalignment on acceptance criteria
- cause: end-user definitions of “success” unclear
- impact: UAT rework and scope creep
- score: 9 (Moderate)
-
R5 Performance risk during peak registration week
- cause: system load not fully captured in test environment
- impact: user frustration, reputational harm
- score: 10 (Moderate)
Qualitative Prioritisation
- Top risks requiring immediate response planning: R2 and R1
- Moderate risks require monitoring and contingency readiness: R3, R4, R5
Response Planning (Strategy and Actions)
-
For R2 (Compliance):
- Mitigate + Avoid risky design choices
- architecture gate legal review
- compliance checklist in acceptance criteria
- contingency: pause feature release until controls implemented
-
For R1 (Integration):
- Mitigate
- early interface mocking and incremental integration testing
- interface contract and acceptance thresholds
- contingency: staged cutover and manual workaround for critical workflows
-
For R3 (Vendor turnaround):
- Mitigate
- contract escalation contacts and service level reporting
- knowledge transfer sessions and documentation requirements
- contingency: reassign internal team resources to reduce dependency
-
For R4 (Stakeholders):
- Mitigate
- define acceptance criteria in UAT plan
- conduct requirements validation workshops
- implement change control for scope changes and risk re-scoring
-
For R5 (Performance):
- Mitigate
- performance tests under simulated peak load
- scale testing and monitoring dashboards
- contingency: feature flags and phased rollout
Monitoring and Control
- weekly risk review during build phase
- trigger dashboards:
- compliance test failure counts
- integration pass rate trend
- vendor response time tracking
- UAT issue severity escalation
- performance metrics during test runs
- stage-gate checkpoint:
- after QA and pilot, re-score risks before go-live decision
This integrated scenario demonstrates the full process: identification → analysis → response planning → implementation → monitoring.
Quality Gates as “Risk Controls”: Preventive vs Detective
Examiners like classification:
-
Preventive controls:
- architecture review to prevent compliance defects
- requirement validation to prevent scope misunderstandings
- training to prevent operational errors
-
Detective controls:
- inspections and audits
- UAT and acceptance testing
- compliance checks before release
A strong answer explains that detective controls help detect issues earlier, reducing the cost of rework.
Common Exam Questions and How to Answer Them
Below are typical question styles in business school exams and how to structure answers.
Q1: “List and explain risk identification methods.”
Answer structure:
- mention 4–6 techniques (workshops, checklists, assumption analysis, documentation review, interviews, RBS)
- explain why triangulation increases coverage
- end with how risks are recorded in a risk register
Q2: “Prioritise risks using probability-impact matrix.”
Answer structure:
- define scoring scale (P and I)
- compute scores for at least 3 risks
- rank risks and justify using thresholds
- explicitly link to response planning for top risks
Q3: “Design risk responses for two high priority risks.”
Answer structure:
- state strategy choice (avoid/transfer/mitigate/accept)
- list specific actions
- include triggers and contingency
- assign owners
Q4: “Explain monitoring and control of risks.”
Answer structure:
- mention risk register updates
- tracking indicators vs triggers
- escalation triggers and governance cadence
- closure criteria
Q5: “Discuss the relationship between risk and quality management.”
Answer structure:
- define quality controls as risk responses
- preventive and detective controls
- acceptance criteria and QA gates
- explain feedback loops (UAT, audits)
South Africa Context Clues (Why They Appear in Exam Scenarios)
Many South African case studies implicitly include:
- procurement constraints and supplier variability,
- compliance and regulatory pressures (particularly in data protection, labour, and sector-specific regulation),
- infrastructure variability (e.g., power stability),
- stakeholder complexity in public and academic environments.
In your exam answers, if you add a sentence like:
- “Supplier reliability and compliance enforcement affect risk exposure and response feasibility,”
it makes your answer feel aligned to local reality without adding new invented data.
Closing Consolidation: Exam-Ready Checklist for Identifying and Managing Project Risks (SBS)
Use this as a final revision checklist before writing exams. It is designed to match what examiners reward: completeness, logical flow, and actionable detail.
A. Risk Identification Checklist
- Use multiple sources: documents + workshops + historical data + assumption analysis
- Convert assumptions into risks
- Write risk statements with event + cause + impact
- Categorise risks via an RBS
- Include at least probability/impact ratings (even if qualitative)
- Assign a risk owner
- Record triggers and monitoring approach (not just description)
B. Risk Analysis Checklist
- Use consistent probability and impact scales
- Compute risk scores (P×I) and apply thresholds
- Prioritise top risks and explain why (risk appetite + interdependencies)
- If quantitative is requested, use EMV/decision trees with clear assumptions
- Treat opportunities similarly, if included
C. Risk Response Planning Checklist
- For threats: choose avoid, transfer, mitigate, or accept
- For opportunities: choose exploit, enhance, share, or accept
- Provide specific actions, not generic statements
- Define contingency plans
- Define triggers/symptoms and escalation process
- Integrate actions into project baselines (schedule/cost/quality/procurement)
D. Monitoring & Control Checklist
- Update risk register on a cadence (weekly/monthly or per stage gate)
- Track leading indicators and trigger conditions
- Re-score risks when new information emerges
- Verify response effectiveness and close risks with criteria
- Communicate top risks through governance structures
Quick Reference: Strategy Mapping (Threats vs Opportunities)
| Risk Type | Strategy | Meaning | Typical Exam Phrasing |
|---|---|---|---|
| Threat | Avoid | Eliminate cause | “Change design/process to remove the risk source.” |
| Threat | Transfer | Shift impact | “Allocate risk to vendor/insurer via contract/insurance.” |
| Threat | Mitigate | Reduce probability/impact | “Early testing and control gates to reduce likelihood and damage.” |
| Threat | Accept | Monitor with contingency | “Accept with contingency reserve and monitoring triggers.” |
| Opportunity | Exploit | Ensure it happens | “Secure resources now to guarantee the opportunity.” |
| Opportunity | Enhance | Increase chance/benefit | “Add actions to increase probability or magnitude.” |
| Opportunity | Share | Partner to capture benefit | “Collaborate with a partner under defined terms.” |
| Opportunity | Accept | Remain ready | “Keep capacity and act if opportunity materialises.” |
This mapping helps you write responses quickly and correctly under exam time pressure.
Final Note on Consistency and Use
In an exam, the strongest answers consistently show the chain:
Identify → Analyse → Prioritise → Respond → Implement → Monitor → Update
and they keep response content consistent with risk statements, owners, triggers, and scoring logic. When these elements are aligned, your submission reads like a real project risk management system rather than a set of disconnected theories—exactly what SBS-style project risk and quality management assessments test.
