Project Risk Management Techniques (DUT) Summaries — Exam Notes for Project Management (DUT) & Related Modules (e.g., Project Risk, Management Accounting & Risk Controls)

Project Risk Management is about identifying uncertainty, assessing impact, and choosing responses so that risks don’t derail schedule, cost, quality, scope, or stakeholder confidence. In a typical Durban University of Technology (DUT) project management module—often aligned with project planning, monitoring, and control—risk management techniques are assessed through case studies, scenario questions, and short essays that test both theory and application. These DUT-focused exam notes summarise key techniques used to manage risks across the project lifecycle, including practical tools such as risk registers, qualitative and quantitative analysis, response planning, and monitoring.

1) Foundations of Project Risk Management Techniques (DUT): Concepts, Roles, and Risk Taxonomies

Risk management is not just a “paper exercise.” In project environments, risks are inevitable because projects involve time pressure, technical novelty, resource constraints, dependency on external parties, and people-related uncertainty. DUT project management assessment frequently expects you to define key concepts correctly, then link them to a structured process and techniques such as risk registers and response strategies.

1.1 Key Definitions and Core Principles (Exam-Ready)

A common question style for DUT modules is: “Differentiate risk vs issue,” “What is risk appetite?” or “Explain probability and impact.” Make sure you can state these clearly:

• Risk: An uncertain event or condition that, if it occurs, will have a positive or negative effect on project objectives.
• Issue: A risk that has already occurred (or a problem that is currently affecting the project).
• Probability: Likelihood that a risk event will occur (qualitative or quantitative).
• Impact: Effect on objectives—typically scope, schedule, cost, quality, and sometimes safety, legal compliance, or reputation.
• Risk owner: The person or team responsible for managing a specific risk.
• Risk appetite / tolerance: The degree of risk the organization is willing to accept.
  • Example: If a university IT project has a low tolerance for downtime during peak semester weeks, risks about outage frequency must be treated more aggressively.
• Residual risk: Risk remaining after response actions are implemented.
• Secondary risks: New risks introduced by implementing a response.

A useful exam approach is to mention both threats and opportunities:

• Threat: Negative event (e.g., supplier delays).
• Opportunity: Positive event (e.g., early delivery enabling earlier commissioning).

1.2 Why Risk Management Is Critical for DUT-Style Projects

DUT projects commonly involve:

• Technology, engineering, construction, or community development components,
• resource and budget limitations,
• stakeholder complexity (lecturers, students, external partners, regulators).

Risk management helps you:

1. Protect the project baseline (schedule/cost/scope).
2. Improve decision-making under uncertainty.
3. Avoid “surprise crises” by anticipating likely failures.
4. Demonstrate governance and accountability during assessment and reviews.
5. Maintain stakeholder trust through transparent controls.

1.3 Risk Management Process (Technique Links)

In many project management syllabi, risk management follows a cycle. You can answer process questions by presenting a logical sequence:

1. Plan risk management
   • Decide how risk will be approached: templates, scoring scales, meeting cadence, responsibilities.
2. Identify risks
   • Use techniques like brainstorming, interviews, document review, checklists, and lessons learned.
3. Perform qualitative risk analysis
   • Prioritise risks by likelihood and impact (often using a risk matrix).
4. Perform quantitative risk analysis
   • Measure numeric effects (expected monetary value, simulation, sensitivity analysis).
5. Plan risk responses
   • Select strategies (avoid, mitigate, transfer, accept; plus exploit/enhance/share for opportunities).
6. Implement risk responses
7. Monitor and control risks
   • Track triggers, update likelihood/impact, check effectiveness, manage emerging risks.

In DUT exam scenarios, you are often asked to connect a technique to a step:

• Risk register → identification + planning + monitoring
• Risk matrix → qualitative analysis
• Contingency reserve → response planning/financial controls
• Change control updates → monitor and control

1.4 Risk Categories and Taxonomies (How to Build a Checklist)

One strong technique is to classify risks into categories. This improves coverage and reduces the chance of missing “hidden” risks.

A common risk taxonomy you can reproduce in exams includes:

• Project management risks
  • poor scheduling, unclear scope, inadequate governance, weak communication
• Technical risks
  • design flaws, technology immaturity, integration issues
• Cost/financial risks
  • inflation, currency volatility, budget cuts, inaccurate estimation
• Schedule risks
  • critical path dependencies, procurement lead time, resource availability
• Resource risks
  • staff shortages, skill gaps, turnover, contractor performance
• Quality risks
  • inadequate testing, rework risk, acceptance criteria failures
• Stakeholder and communication risks
  • resistance, misalignment, unclear requirements, stakeholder engagement gaps
• Legal and compliance risks
  • permitting delays, regulatory noncompliance, contract disputes
• External risks
  • supplier failure, weather, crime/security, infrastructure constraints

Example: DUT IT/Systems Project Risk Categories

Suppose DUT runs a project to implement a learning management system update ahead of a semester start.

• Technical risk: integration issues with existing student data systems.
• Schedule risk: vendor release delays.
• Compliance risk: data privacy requirements not fully met.
• Stakeholder risk: lecturers not trained, leading to adoption failure (still counts as project risk affecting benefits).

1.5 Risk Appetite and Tolerance (Connecting to Response Choice)

Risk appetite/tolerance is what determines whether a risk is:

• accepted (no major action),
• mitigated (reduce probability or impact),
• avoided (change plan),
• transferred (share with insurer/outsourcer),
• or exploited (for opportunity).

Example response logic:

• If risk tolerance for data breaches is extremely low, then “accept” is unlikely.
• Instead, responses might include controls, training, security testing, and vendor assurance clauses.

In exams, don’t just say “we mitigate.” Specify what you would do and why it matches the tolerance.

1.6 Building an Exam-Useful Risk Statement

Risk statements must be clear and measurable. A good risk statement is often written as:

If [cause/condition], then [event], which will lead to [impact] on [objective], by [time].

Example:

• “If the supplier delivers the network switches two weeks late, then installation activities will slip, causing a delay in go-live by at least one month affecting semester registration readiness.”

This structure helps when you later fill a risk register.

1.7 Stakeholder and Governance Roles in Risk Management

Risk management is typically shared:

• Project manager: responsible for risk process, facilitation, and reporting.
• Risk owner: responsible for actions and monitoring for their assigned risk.
• Project team: identify risks, contribute analysis, implement mitigation tasks.
• Sponsor/steering committee: approves escalation and major decisions.
• Procurement/contract managers: handle transfer/contractual protections.
• Quality and compliance: define acceptance criteria and monitoring.

DUT exam questions often ask “who should be accountable?” Avoid vague answers like “everyone.” Use named roles.

2) Risk Identification Techniques (and Building the DUT-Style Risk Register)

This section focuses on techniques for identifying risks and turning them into an actionable risk register. In many DUT exams, you’ll either be asked to identify risks from a scenario or to propose how to capture them correctly for evaluation and response planning.

2.1 Plan Risk Management (Templates and Scoring Scales)

Before identification, you need a plan. Risk identification quality depends on having consistent documentation and criteria.

A strong exam answer includes:

• risk register format,
• risk categories,
• probability/impact scoring scale,
• meeting cadence (e.g., weekly risk review during implementation),
• triggers and escalation thresholds,
• roles and responsibilities.

Example Scoring Scale (Qualitative)

You can create a simple 1–5 scale (as long as it’s consistent):

• Probability: 1 (Rare), 2 (Unlikely), 3 (Possible), 4 (Likely), 5 (Almost certain)
• Impact: 1 (Insignificant), 2 (Minor), 3 (Moderate), 4 (Major), 5 (Severe)

In exams, a common technique is the risk matrix:

• Likelihood (x-axis) vs impact (y-axis),
• priority based on zones (low/medium/high/red).

2.2 Identification Techniques: What to Use and When

2.2.1 Brainstorming and Workshops

• Best for early-stage identification.
• Useful when the team is diverse (technical + schedule + procurement + stakeholder management).

How to make it effective (exam point):

• Use structured prompts based on categories.
• Prevent domination by one person.
• Record every suggestion; don’t evaluate during brainstorming.

2.2.2 Interviews and Expert Judgement

• Interview those close to the work: engineers, lecturers, procurement officers, contractors.
• Use lessons learned from similar projects.

Exam tip: “Expert judgement” must be linked to a technique: it’s not a process by itself. It is used in identification and analysis.

2.2.3 Document Reviews

Review:

• project charter and scope statements,
• work breakdown structure (WBS),
• schedule and procurement plan,
• requirements documents,
• previous audit reports,
• lessons learned database.

This is a technique DUT students can score well on: it’s concrete and realistic.

2.2.4 Checklists (Risk Prompt Lists)

Checklists reduce omissions but can lead to “copy-paste thinking.” Use them as prompts, then tailor to the specific project.

Example checklist items:

• “Are there known vendor reliability issues?”
• “Are requirements stable or frequently changing?”
• “Are there external dependencies like municipalities or utility providers?”

2.2.5 Lessons Learned / Historical Data

• Past project delays, defects, rework, contract disputes.
• Use historical causes, not just historical symptoms.

Example:

• If previous student-facing systems projects had issues with training and adoption, treat “user adoption risk” as a recurring risk category.

2.3 Turning Identified Risks into a Risk Register

A risk register is the living document that records:

• risk ID,
• description,
• category,
• cause,
• event,
• impact,
• probability,
• impact score,
• risk rating,
• owner,
• response strategy,
• contingency/residual risk,
• trigger/early warning indicators,
• status (open/closed).

Recommended Register Fields (Exam-Friendly)

Use a table or list in your answer. For example:

Risk ID	Category	Risk Statement	Probability (1-5)	Impact (1-5)	Score	Owner	Response Strategy	Trigger	Status

In the exam, even if you don’t fill all fields, show you understand what a register contains.

2.4 Example Risk Register (Scenario-Based)

Consider a DUT-related project scenario for an “Academic Support Centre Appointment System” to be deployed before the mid-year academic cycle.

Potential risks:

1. Supplier delivery delay
   • Impact: system cannot be deployed by target date.
2. Data migration errors
   • Impact: incorrect student records; quality/reliability issues.
3. Insufficient user training
   • Impact: low adoption; stakeholder dissatisfaction.
4. Scope creep from stakeholder requests
   • Impact: schedule and cost overruns.
5. Cybersecurity vulnerability
   • Impact: security incident; compliance risk.

Below is a qualitative example to demonstrate how scoring is applied (scores are illustrative and consistent within the table).

Risk ID	Category	Risk Statement	Probability (1-5)	Impact (1-5)	Score	Owner	Response Strategy	Trigger	Status
R1	Schedule/Procurement	If the software deployment environment is delivered late by the vendor, then go-live will be delayed, impacting the academic cycle readiness.	3	4	12	Procurement Lead	Mitigate: add buffer time; track vendor milestones; include SLA penalties.	Vendor missed milestone	Open
R2	Quality/Technical	If data migration scripts produce incorrect student records, then system outputs will fail acceptance criteria and require rework.	2	5	10	Data Analyst Lead	Mitigate: validation checks; parallel run; rollback plan.	Test data mismatch > threshold	Open
R3	Stakeholder/Adoption	If academic staff are not trained before rollout, then adoption will be low and appointment scheduling quality will suffer.	4	3	12	Change Manager	Mitigate: training sessions; user guides; feedback loop.	Staff feedback indicates confusion	Open
R4	Scope/Requirements	If new features are requested without approval, then project scope will expand, causing cost and schedule overrun.	3	4	12	Project Manager	Mitigate: strict change control; prioritisation; backlog management.	Change requests outside process	Open
R5	Security/Compliance	If the system vulnerabilities are not discovered before launch, then a breach could occur, risking legal and reputational damage.	2	5	10	Security Officer	Mitigate: security testing; patch management; least privilege.	Failed security scan	Open

Why these examples matter

• They demonstrate risk statements with clear impacts.
• They show consistent scoring logic.
• They link responses to triggers, which strengthens monitoring later.

2.5 Common Identification Mistakes (and How to Avoid Them)

DUT exams often reward critical thinking. Common mistakes include:

• Confusing issues with risks: if deployment is already delayed, it’s an issue.
• Vague statements: “There is a risk of delay” without cause/event/impact.
• No ownership: response is planned but no owner is assigned.
• Ignoring interdependencies:
  • Example: training delay might also cause additional support tickets, increasing workload and schedule impact.
• Missing external risks: procurement lead times, regulatory approvals, and power outages.

2.6 From Qualitative to Quantitative: When Identification Feeds Both

After identification, the project may use:

• qualitative risk analysis for prioritisation,
• quantitative analysis for high-impact risks.

Exam questions might ask:

• “Why do we not quantify every risk?”
  Answer: because quantification is time-consuming and requires data; only prioritised or high-uncertainty risks get deeper analysis.

2.7 Risk Register Maintenance: “Living Document” Behaviour

Risk register entries must be updated during monitoring:

• likelihood changes (e.g., supplier improved performance),
• impact changes (e.g., security risk becomes more severe due to new regulations),
• new risks appear as the project approaches different phases.

A strong exam line:

• “Risk management is iterative; the register is reviewed regularly and updated through change control and risk review meetings.”

3) Risk Analysis Techniques: Qualitative Matrices and Quantitative Methods (Expected Value, Simulation, Sensitivity)

After identifying risks and capturing them in a register, projects must evaluate them. This section covers qualitative and quantitative risk analysis techniques and how to apply them to exam scenarios.

3.1 Qualitative Risk Analysis: Risk Matrix and Prioritisation

Qualitative analysis converts uncertainty into relative priority. It’s often faster than quantitative analysis and doesn’t require deep numerical data.

3.1.1 Risk Matrix Method

• Determine likelihood and impact ratings (e.g., 1–5).
• Compute a score (often likelihood × impact).
• Use a threshold to define:
  • high risks (require detailed response plans),
  • medium risks (some response),
  • low risks (monitoring).

A risk matrix example zones:

• 1–6: low
• 7–14: medium
• 15–25: high (depending on scaling)

In your answers, show how scoring leads to prioritisation.

3.2 Qualitative Ranking by Severity and Urgency

Not all “high score” risks are equally urgent. Projects sometimes also consider:

• time sensitivity (how soon the risk could affect objectives),
• velocity (how fast probability/impact could worsen),
• detectability (how likely the team is to discover it early).

A useful DUT exam technique: “Severity vs urgency.”

• Severity: probability × impact.
• Urgency: how quickly response actions must be initiated.

3.3 Handling Uncertainty in Qualitative Scores

Qualitative analysis can be subjective. To manage subjectivity:

• use multi-rater scoring (several team members),
• calibrate scoring definitions,
• use evidence (data, past incidents, expert assessments).

Exam-friendly point:

• “Qualitative analysis uses expert judgement but should be anchored in evidence.”

3.4 Quantitative Risk Analysis: When and Why

Quantitative analysis is used when:

• high-impact risks are present,
• management needs numeric forecasts (e.g., expected cost overrun),
• data exists (historical performance, vendor reliability, defect rates),
• you need to choose between competing strategies.

DUT exam problems might ask:

• “What additional benefit does quantitative analysis provide over qualitative analysis?”
  Typical answer:
• It converts uncertainty into measurable outcomes (e.g., expected time/cost, confidence levels).

3.5 Expected Monetary Value (EMV): Classic DUT Exam Method

EMV is a common quantitative technique:

• EMV = Σ (Probability of outcome × Monetary value of outcome)

Example structure:

• identify decision options and possible outcomes,
• assign probabilities,
• compute expected cost or expected benefit.

Example: Vendor Delay Decision

Suppose the procurement team considers two options:

Option A: No additional penalty clause

• Probability of 1-week delay: 0.30
• Probability of 2-week delay: 0.10
• Monetary impact of 1-week delay: R60,000
• Monetary impact of 2-week delay: R120,000
• Otherwise (no delay) impact: R0 with probability 0.60

EMV = (0.30 × 60,000) + (0.10 × 120,000) + (0.60 × 0)
= 18,000 + 12,000 + 0
= R30,000 expected delay cost

Option B: Add SLA + penalty clause

• Additional contract management cost: R15,000
• Probability of 1-week delay: 0.20
• Probability of 2-week delay: 0.05
• Probability of no delay: 0.75

EMV with Option B = R15,000 + (0.20×60,000) + (0.05×120,000) + (0.75×0)
= 15,000 + 12,000 + 6,000 + 0
= R33,000

In this example, Option A has a lower expected cost (R30,000 vs R33,000), so if the decision is purely cost-based, Option A may be chosen. But exam questions often require nuance:

• Option B might still be chosen if the organization has low risk tolerance for schedule failures, or if penalties protect reputational concerns.

This demonstrates how quantitative methods support decision-making, not replace governance judgement.

3.6 Sensitivity Analysis: Testing Which Variables Matter Most

Sensitivity analysis answers:

• “If assumptions change, does the conclusion change?”
• Identify most influential risk drivers.

Example:

• If you compute expected project cost based on defect rate and rework cost, you test:
  • defect rate +20%,
  • labour cost +10%,
  • supplier lead time variation.

If results change dramatically with one variable, that variable is a high-priority monitoring target.

Exam-friendly phrasing:

• “Sensitivity analysis identifies leverage points for response and monitoring.”

3.7 Monte Carlo Simulation: Probabilistic Outcomes (Advanced Exam Bonus)

Monte Carlo simulation is used when:

• project schedule or cost depends on multiple uncertain variables,
• you want probability distributions for completion time or cost.

In exams, you may be asked to “explain” the technique rather than compute huge simulations. Key points to mention:

• represent uncertain inputs as probability distributions (e.g., triangular distributions for task durations),
• run many iterations,
• generate output distributions (e.g., probability of finishing by a due date),
• quantify confidence intervals.

Example Interpretation

If simulation outputs show:

• 60% probability of completion within 12 weeks,
• 85% probability of completion within 14 weeks,

then project management can select contingencies or refine the schedule accordingly.

3.8 Comparing Qualitative and Quantitative Techniques

Use a direct comparison in exam answers:

Technique	Main Output	Data Required	Strength	Limitation
Qualitative (risk matrix)	Rank/prioritise risks	Low	Fast, easy for early planning	Subjective
EMV	Expected cost/benefit per decision	Probabilities + impacts	Supports decision options	Limited to discrete outcomes
Sensitivity	Identify key drivers	Assumptions and models	Shows leverage points	Does not capture full distribution
Simulation	Probability distributions for outcomes	Model + distributions	Handles multiple uncertainties	Needs data and method expertise

3.9 Risk Analysis for Opportunities (Not Just Threats)

Many students focus on threats only. Strong DUT answers include opportunities.

Example:

• Opportunity: supplier offers early delivery if you provide design feedback by a certain date.
• Analysis includes:
  • probability of early delivery,
  • impact on benefits (e.g., earlier adoption),
  • cost of acting (e.g., accelerated design review).

Quantitative analysis can estimate:

• expected benefit = probability × monetary value of benefit.

In exams, mention response strategies for opportunities:

• exploit (make it happen),
• enhance (increase probability/impact),
• share (partner),
• accept (if low value).

3.10 Using Results to Drive Response Planning

Qualitative/quantitative results should trigger:

• updating risk priority,
• assigning risk budgets or contingency,
• selecting appropriate response types.

A common exam question is:

• “Why is response planning difficult if analysis is weak?”
  Because mis-prioritisation wastes effort and ignores high-risk threats.

4) Risk Response Techniques: Avoid, Mitigate, Transfer, Accept (and Opportunity Responses) + Contingency Planning

Once risks are prioritised, you must plan responses. This section provides techniques for different risk categories and includes exam-ready logic to choose response strategies.

4.1 Response Planning Framework (Threats and Opportunities)

Common threat response strategies:

1. Avoid
   • eliminate the risk cause by changing the plan.
2. Mitigate
   • reduce probability and/or impact (prevention or reduction).
3. Transfer
   • shift impact to another party (insurance, contracts).
4. Accept
   • acknowledge risk and prepare contingency if it occurs.

Common opportunity response strategies:

1. Exploit (ensure opportunity happens)
2. Enhance (increase probability/impact)
3. Share (partner to benefit)
4. Accept (take advantage if it occurs)

In exam answers, explicitly label which strategy fits which type of risk.

4.2 Avoidance: When It Makes Sense

Avoidance works when:

• risk is high severity,
• mitigation costs are too high,
• you can change approach without unacceptable loss of value.

Example:

• In a construction project, if a complex material has high failure rates and long lead times, switching to a proven alternative reduces schedule and quality risk.

Exam point:

• avoidance changes the baseline or scope; therefore, it must be assessed through change control.

4.3 Mitigation: Designing Preventive Controls

Mitigation is the most common strategy. It typically uses:

• process controls,
• technical safeguards,
• additional planning,
• training,
• quality assurance.

Example Mitigation Techniques

• For supplier delays
  • track milestones,
  • maintain alternative suppliers,
  • add buffer time,
  • negotiate SLA terms.
• For data migration errors
  • data profiling,
  • validation rules,
  • parallel run,
  • rollback plans.
• For stakeholder adoption risks
  • training and communication,
  • champions in departments,
  • pilot testing,
  • feedback mechanisms.

Exam tip:

• Always link the mitigation to the cause of the risk, not only the impact.

4.4 Transfer: Contracts, Insurance, and Risk Sharing

Transfer does not eliminate risk. It reallocates consequences to another party.

Transfer options:

• Insurance (property, liability).
• Fixed-price contracts for defined scope.
• Performance-based contracts for measurable deliverables.
• Subcontracting specific risky tasks.

Transfer Exam Caution

• If scope is unclear, fixed-price contracts can create disputes and hidden risks (e.g., claims).
• Transfer requires good contract management, not just signing a contract.

A strong exam answer includes:

• “Transfer works best when the contract clearly defines deliverables, acceptance criteria, penalties, and responsibilities.”

4.5 Acceptance: Active vs Passive Acceptance

Acceptance strategies:

• Passive acceptance: do nothing except acknowledge risk.
• Active acceptance: prepare contingency triggers and contingency reserves.

Exam-friendly distinction:

• Active acceptance is preferred for risks that you cannot effectively mitigate/avoid due to cost or feasibility.

4.6 Contingency Planning: Reserves and Triggers

Contingency planning is a financial and operational technique linked to risk responses.

Two important concepts:

• Contingency reserve: budget/time set aside for known risks.
• Management reserve: budget reserved for unknown unknowns.

Trigger-Based Activation

Instead of waiting for failure, define:

• early warning signals,
• decision thresholds,
• who authorises contingency use.

Example triggers:

• “If vendor misses two consecutive milestones, activate expedited shipping alternative.”
• “If security scan fails twice, escalate to penetration testing contractor.”

4.7 Building a Response Plan in a Risk Register

A strong response plan includes:

• response strategy (avoid/mitigate/transfer/accept),
• specific actions (what will be done),
• owner,
• timeline for action,
• contingency reserve/time allocation,
• residual risk estimate (how response changes probability/impact),
• trigger for activation,
• effectiveness measure.

This is where many DUT students lose marks: they list strategy words but not actions.

4.8 Opportunity Responses: Exploit, Enhance, Share, Accept

Opportunities should also have planned responses. Example opportunity categories:

• cost reduction due to bulk purchase discounts,
• earlier completion enabling earlier benefits,
• learning opportunities improving future efficiency.

Opportunity Case Example: Early Training Enables Earlier Go-Live

• Risk/Opportunity statement:
  • “If early training for lecturers is completed by week 2, then adoption will improve and system stabilisation can be completed by week 4, enabling go-live earlier.”
• Probability (opportunity): 0.40
• Benefit: earlier go-live saves R50,000 in support costs and reduces complaints.

Response:

• Exploit: schedule training early, assign training owner, allocate overtime/temporary support.
• Enhance: provide tutorial videos, create Q&A channel.

This demonstrates that opportunity management uses the same discipline as threat management.

4.9 Residual Risk and Secondary Risks

After applying responses, risks may:

• reduce probability,
• reduce impact,
• change in nature.

Also, responses can create secondary risks:

• Example: subcontracting a task to reduce schedule risk may transfer quality and integration risks if subcontractor experience is low.
• Example: hiring additional staff for schedule acceleration increases cost and potential coordination failures.

Exam answer should acknowledge:

• “We review residual and secondary risks and update the register accordingly.”

4.10 Response Strategy Selection: A Decision Logic You Can Reuse

A reusable exam logic:

1. Assess risk rating (qualitative/quantitative).
2. If rating is high and response is feasible:
   • prefer mitigate/avoid, sometimes transfer.
3. If rating is medium:
   • design mitigation + monitoring, define triggers.
4. If rating is low:
   • accept with monitoring (or include in contingency pool).
5. Always consider:
   • risk tolerance,
   • response cost vs benefit,
   • secondary risks and residual risk,
   • feasibility in project schedule.

4.11 Example: Response Planning for the Risk Register (From Section 2)

Using the earlier example risks (R1–R5), demonstrate response planning:

• R1 (supplier delay): Mitigate via milestone tracking + SLA penalties; consider contingency time buffer.
• R2 (data migration errors): Mitigate via parallel run and rollback plan; plan additional QA testing window.
• R3 (insufficient training): Mitigate via training schedule + training materials; measure via readiness surveys.
• R4 (scope creep): Mitigate via change control + backlog prioritisation; define approval thresholds.
• R5 (security vulnerability): Mitigate via security testing + patch management; transfer via cyber insurance only if feasible; include incident response plan.

In an exam, you can show:

• “These actions target causes and include triggers to activate contingency.”

5) Monitoring and Control of Project Risks (DUT Focus): Risk Reviews, KPIs, Audits, and Updating the Risk Register

Risk management continues after response planning. Monitoring and control ensures risks are:

• tracked,
• updated,
• escalated when needed,
• and replaced by lessons learned as the project progresses.

5.1 Why Monitoring and Control Is Often the Difference Between Success and Failure

Projects fail not because risk was unknown, but because:

• risks were not monitored,
• responsibilities were unclear,
• changes were not reflected in risk probability/impact,
• responses weren’t tested for effectiveness.

DUT exam case studies often include “what went wrong” narratives where earlier risks were identified but not controlled.

5.2 Risk Review Cadence and Governance

Typical monitoring activities:

• Regular risk review meetings (weekly or biweekly during active phases).
• Project status reporting includes top risks and status.
• Escalation procedures to sponsor/steering committee.

A strong exam answer includes:

• who attends (project manager, risk owners, quality, procurement),
• the purpose (update probabilities, check triggers, close risks),
• decision-making authority.

5.3 Early Warning Indicators (Triggers) and Trigger Ownership

Triggers are essential in active acceptance and mitigation strategy success.

Types of triggers:

• schedule triggers (milestone missed, late procurement),
• quality triggers (failed test thresholds, defect rates),
• stakeholder triggers (training incomplete, adoption metrics low),
• security triggers (failed scans, abnormal access patterns).

Exam point:

• “Assign ownership for triggers so accountability exists when thresholds are met.”

5.4 Risk Audits and Effectiveness Checks

A risk audit checks:

• whether risks are still valid,
• whether controls are implemented,
• whether response actions were effective,
• whether the risk register is current.

Effectiveness measures:

• Did defect rates reduce after implementing data validation?
• Did training increase adoption or reduce support tickets?
• Did procurement milestones meet SLA targets?

DUT students should emphasise:

• Monitoring includes both risk status and response effectiveness.

5.5 Key Risk Indicators (KRIs) and KPIs for Risk Management

Monitoring should use measurable indicators. Examples:

• Schedule KRI: percent of critical path tasks delayed > X days.
• Cost KRI: burn rate variance > Y% from baseline.
• Quality KRI: defect density above threshold; number of rework cycles.
• Procurement KRI: vendor on-time delivery rate below target.
• Security KRI: vulnerability severity levels found during scans.
• Stakeholder KRI: training completion rate; satisfaction survey score.

In exams, it’s acceptable to use “example thresholds” rather than numeric targets, as long as you show structure and logic. Avoid inventing specific thresholds unless you define them clearly.

5.6 Handling New Risks and Risk Register Updates

New risks appear due to:

• scope changes,
• new information from testing,
• supplier performance,
• regulatory developments,
• staffing changes.

Risk register update practices:

• Add new risks with proper statements and owners.
• Re-score probability/impact based on evidence.
• Update status:
  • Open,
  • Under control/Monitoring,
  • Closed (with rationale).

5.7 Managing Risk During Change Control (Integration with Scope/Time/Cost)

Monitoring intersects with change control:

• if a change is approved (new requirement), it can create new risks or modify existing ones.
• risk owners must reassess probability/impact after changes.

Exam answer structure:

• “Any approved change should trigger a risk reassessment for affected categories.”

5.8 Escalation and Communication of Risk

Effective risk communication includes:

• ranking top risks with brief explanations,
• progress of responses,
• trigger status,
• required decisions from sponsor.

A common DUT exam scenario: “The sponsor asks why the risk materialised.” A good answer should show:

• risk was monitored,
• triggers were defined,
• escalation occurred (or explain why escalation failed).

5.9 Example: Monitoring Plan for the Five Risks (R1–R5)

Using the earlier five risks (R1–R5), demonstrate a monitoring plan:

• R1 Supplier delay

  • Monitor vendor milestones weekly.
  • Trigger: missed two consecutive milestones.
  • Response check: SLA penalties clause active; alternative logistics identified.
  • Update: if performance improves, reduce probability score.

• R2 Data migration errors

  • Monitor test results daily/weekly during migration window.
  • Trigger: validation mismatch above threshold.
  • Response check: rollback plan readiness; backup scripts tested.
  • Update: if rework decreases, lower impact rating.

• R3 Insufficient training

  • Monitor training completion and staff readiness surveys.
  • Trigger: low completion rate or negative feedback in support channels.
  • Response check: training materials updated; additional sessions scheduled.
  • Update: if adoption improves, reduce risk probability.

• R4 Scope creep

  • Monitor change requests and adherence to approval process.
  • Trigger: requests outside change control or repeated additions without prioritisation.
  • Response check: change control approvals logged; backlog managed.
  • Update: if scope stabilises, reduce probability.

• R5 Security vulnerability

  • Monitor security scans and vulnerability remediation status.
  • Trigger: failed scan severity above agreed threshold.
  • Response check: patches installed; incident response plan reviewed.
  • Update: if scans pass, reduce probability; if new vulnerabilities appear due to system updates, re-score.

This monitoring plan shows both tracking and feedback loops.

5.10 Lessons Learned and Continuous Improvement

At the end of the project (or phase closure), capture:

• which risks materialised,
• which responses worked,
• which triggers were useful,
• which assumptions were incorrect.

DUT exam answers should include:

• “Lessons learned update checklists and future risk registers.”
  This makes risk management a learning system rather than a single project tool.

5.11 Risk Closure Criteria

Risks should not be “closed” just because time passed. Closure criteria include:

• evidence that risk no longer applies,
• response actions completed and verified,
• residual risk accepted by sponsor,
• no trigger has been activated for a defined period.

A high-quality exam answer mentions:

• closure requires a rationale and stakeholder acceptance.

5.12 Putting It All Together: A Typical DUT Exam-Style Risk Control Answer

When asked “Explain how you will monitor and control project risks,” an integrated structure is:

1. Define review cadence and roles.
2. Use risk register as the central record.
3. Monitor KRIs and trigger thresholds.
4. Validate response effectiveness via tests/audits.
5. Escalate when thresholds are met.
6. Update probabilities and impacts based on new evidence.
7. Apply change control linkages.
8. Document lessons learned for future projects.

This structure is robust across many DUT-style scenarios.

Concluding Exam Notes (Quick Reference Checklist)

• Identify risks using brainstorming, interviews, document reviews, checklists, and lessons learned.
• Record in a risk register with clear risk statements, scoring, owners, triggers, and response actions.
• Prioritise using qualitative risk matrices; support decisions with quantitative methods such as EMV and, where appropriate, Monte Carlo simulation.
• Respond using avoid, mitigate, transfer, accept (and exploit, enhance, share, accept for opportunities).
• Monitor & control via risk reviews, KRIs/KPIs, audits, trigger-based escalation, risk register updates, and lessons learned.

These are the core Project Risk Management Techniques (DUT) Summaries you can apply directly to exam questions on planning, analysis, response, and control within project management modules and risk-oriented assessments.