Project Management Case Studies (TUT) Exam Prep: TUT MNG311 / MNG 0001 Style Case Study Practice for Project Planning, Scheduling, Risk & Stakeholder Management

Project Management Case Studies are a core way exams test whether you can apply theory to messy, realistic project situations. At Tshwane University of Technology (TUT), case-study questions for project planning, scheduling, risk, stakeholder management, and reporting typically mirror workplace decision-making under constraints like time, budget, quality, and scope. This study guide focuses on the type of reasoning you need to produce strong, exam-ready answers—especially for modules in the TUT Project Management cluster such as MNG311 (and commonly paired project management/case-study modules like MNG 0001-style applied management practice).

Section 1: How TUT Project Management Case Studies Are Marked (and How to Build a Winning Answer)

TUT-style project management case studies usually reward candidates who (1) identify the right problem, (2) structure their answer using standard project-management logic, and (3) show calculations where needed (time/cost impacts, schedule delays, risk scoring, cost estimates, and stakeholder impact). The best answers are not “storytelling”; they are structured decision documents. Even when the question is narrative, your response should be analytic.

Understanding the exam “case-study pattern”

Most case-study questions follow a pattern:

1. Background & context: the project charter summary, organisational environment, or business need.
2. Constraints: deadlines, budget limits, resource availability, procurement rules.
3. Stakeholders: clients, project sponsor, contractors/vendors, internal departments, end-users.
4. Current status: progress to date, what is working/what is failing, key incidents.
5. A new development: scope change, quality defects, contractor delay, budget pressure, stakeholder conflict, risk materialisation.
6. Your task: propose actions, diagnose causes, build a plan, justify trade-offs, or recommend a decision.

TUT examiners typically want you to demonstrate project management “process thinking”: you should connect the situation to a process (planning, execution, monitoring & controlling, risk management, change control) and state what to do next.

Building a high-scoring answer structure

A reliable exam answer structure (that still adapts to different questions):

• Step 1: Extract facts from the case (date/timeline cues, budget numbers, deliverables, constraints).
• Step 2: Identify the problem(s) (schedule risk? scope creep? stakeholder misalignment? procurement bottleneck? quality management failure?).
• Step 3: Diagnose root causes (why it happened, based on project logic).
• Step 4: Propose options (at least 2 options if trade-offs exist).
• Step 5: Evaluate options using criteria (time, cost, quality, risk, feasibility).
• Step 6: Recommend one option and justify with reasoning.
• Step 7: Provide implementation detail (who does what, when, and how you monitor).
• Step 8: Mention controls (how you detect early signals and manage change).

Even if the question only asks for a plan, the marker often assesses whether you used project management fundamentals. A short “lucky” answer without structure may look incomplete; a structured answer that clearly maps to known practices gains points.

Common marking criteria for case studies

In project management papers, marks often align to these competencies:

• Concept application: Do you use correct terms like scope baseline, WBS, schedule baseline, risk register, change control, stakeholder engagement plan?
• Quantitative reasoning: Can you compute or estimate impacts? (e.g., delay days, cost variance, risk expected value, earned value interpretation)?
• Decision quality: Is your recommendation logical and defensible?
• Feasibility: Does your plan fit the constraints stated (budget, resource limitations, procurement timelines)?
• Professional communication: Is your answer easy to follow and written in decision-making language?

Exam language that signals “correct approach”

Use phrases that demonstrate mastery (without overusing them):

• “We should update the schedule baseline” (when change affects critical path).
• “A change request must be logged and assessed via the change control process” (when scope is modified).
• “Update risk register and review risk response effectiveness” (when risks materialise).
• “Implement a stakeholder engagement plan to manage expectations and communication cadence” (when conflict arises).
• “Create a work breakdown structure (WBS) to clarify deliverables and responsibilities” (when scope is unclear).
• “Develop a monitoring & controlling dashboard with KPIs” (when progress tracking is needed).

Markers recognize these as exam-ready project management outputs.

A mini case study (practice): “The IT Rollout That Missed Its Go-Live”

Case facts (simplified example consistent with typical exam style):
A small enterprise system rollout is planned for 12 weeks with a budget that is already approved. Week 1-3 went smoothly. At the end of Week 3, the contractor reports that a key software module will only be delivered after an extra 2 weeks due to vendor testing delays. Meanwhile, the client’s internal team has scheduled training sessions that cannot shift easily.

Typical question: “Recommend actions to recover the schedule and manage stakeholder impacts.”

Winning answer ingredients:

1. Problem: schedule disruption risk has materialised (contractor/vendor delay).
2. Diagnosis: likely weak vendor risk assessment, unclear acceptance criteria, or dependencies not managed early.
3. Options:
   • Option A: Crashing (add resources to parallel tasks) starting Week 4.
   • Option B: Fast-tracking (overlap testing and training preparation) where feasible.
   • Option C: Scope/schedule trade-off: reduce training content or postpone non-critical features.
4. Evaluation criteria:
   • Cost increase vs budget ceiling.
   • Quality risk of fast-tracking.
   • Training impact on end-user readiness.
5. Recommendation: choose Option A and B for critical components; implement change control for any scope reduction.
6. Controls:
   • update schedule baseline,
   • re-baseline critical path,
   • weekly stakeholder comms cadence,
   • track KPIs: % tasks completed, defect leakage rate, training readiness.

The key is that your response demonstrates structured project management actions, not just “work harder.”

Why examiners reward “process + justification”

In TUT-type project management modules, students often know definitions but struggle to apply them. Examiners reward you when you link application to logic:

• If schedule is threatened, you don’t just say “make a new schedule”; you say update the schedule baseline, identify critical path impact, and implement recovery actions while managing constraints.
• If scope changes, you don’t just say “tell the client”; you say log a change request, assess impact, and adjust baselines if approved.

This is how you translate theory into a decision under uncertainty.

Quick checklist you can use during revision

When you read any case, ask:

• What is the deliverable and is it clearly defined?
• What is the schedule baseline and does the case mention milestones?
• What is the budget baseline?
• Who are the stakeholders and what are their interests/impacts?
• Are there dependencies (Task A must finish before Task B)?
• Are there risks and did they occur?
• Is there evidence of change control failure?
• What KPIs could track success?

This checklist keeps you from missing points and helps you write answers that match expected marking categories.

Section 2: Planning & Scheduling in Case Studies (WBS, Critical Path, Baselines, and Recovery Plans)

Many case-study marks come from planning and scheduling logic. Even when the case is about risk or stakeholder conflict, the underlying symptoms often show up as schedule slippage, unclear deliverables, or poorly controlled dependencies. This section focuses on the planning tools you must use in TUT exam answers: WBS, activity definition, sequencing, schedule estimation, baselines, critical path reasoning, and schedule recovery.

Work Breakdown Structure (WBS): the exam “scope clarity engine”

A WBS is how you show examiners that you understand deliverables. In case studies, scope is often vague: “deliver a system,” “build a facility,” “run a campaign,” “install equipment.” The exam expects you to break the work into manageable components and thereby clarify what “done” means.

Exam-ready WBS guidance:

• Use deliverable-based decomposition (what must be produced), not task-only decomposition.
• Include management and integration activities if they are necessary (e.g., project management, reporting, risk reviews).
• Make sure the WBS supports responsibility assignment (even if you can only reference roles generally).

Example: WBS for a “Library Wi-Fi Upgrade” project

A case says: “Upgrade library Wi-Fi in time for semester start.”

A WBS exam-style breakdown might look like:

1. Project Management
   • Project planning and baselining
   • Reporting and governance meetings
   • Procurement coordination
2. Site Survey & Requirements
   • Building layout assessment
   • Coverage requirements validation
   • Performance target definition
3. Procurement & Logistics
   • Access point procurement
   • Cable and mounting procurement
   • Delivery scheduling
4. Installation
   • Hardware installation
   • Cable routing and termination
   • Network configuration
5. Testing & Acceptance
   • Coverage testing
   • Bandwidth testing
   • Security configuration review
   • Formal handover/acceptance
6. Training & Documentation
   • Staff training sessions
   • User guides and admin documentation

If your case includes delays in a contractor’s tasks, the WBS helps you identify affected components and which deliverables are impacted.

Activities, sequencing, and dependencies: showing you understand “why” the schedule breaks

Case studies often mention statements like:

• “We cannot start installation until the cable is delivered.”
• “Training must occur after system configuration is complete.”
• “Approval cannot be obtained until documentation is submitted.”

In your answer, label these as dependencies:

• Finish-to-Start (FS): predecessor finishes before successor starts.
• Start-to-Start (SS) or Finish-to-Finish (FF), if overlaps exist (in fast-tracking contexts).

Even if the exam doesn’t demand network diagrams, you can demonstrate dependency thinking in text:

“Because installation is FS dependent on cable delivery and configuration, the vendor delay propagates directly into installation start, making those tasks critical.”

This kind of reasoning gets marks.

Schedule estimation: three durations and the “point” of uncertainty

Real schedule estimation is uncertain. Exams sometimes present a single duration, but you may be tested on awareness of estimation approaches. If a case provides optimistic/pessimistic/most likely durations, you should consider expected duration logic (commonly referenced in PM practice).

Even if the case doesn’t require the exact formula, your answer should show that you consider variability:

• Use conservative estimates for high-risk dependencies.
• Add contingency for uncertain tasks.
• Tighten estimation for tasks with reliable data.

Schedule baselines and baselining logic

A baseline is the planned reference for measuring progress. In case studies, you may be asked what to do when delays occur.

Correct baseline reasoning:

• If change is approved (scope increase, new dates, added resources), update the schedule baseline.
• If change is not approved, you still track progress but highlight variances.
• Don’t “hide” delays by revising baselines informally.

In exam terms, markers want to see that you understand baselining as a control mechanism, not paperwork.

Critical Path reasoning: focus on “which tasks control completion”

Case studies often provide a small network of tasks with durations and ask how a delay affects the end date. You may not always need a full formal Critical Path Method (CPM) table, but you should be able to do essential reasoning.

Example practice scenario: delay on a critical dependency

Assume the project ends when the final acceptance activity finishes. The network includes:

• A: Requirements (3 days) → B: Design (4 days) → C: Development (5 days) → D: Testing (3 days) → E: Acceptance (2 days)
• Parallel supportive activities occur but do not extend final acceptance time.

Total duration = 3 + 4 + 5 + 3 + 2 = 17 days.

If the case states that Development (C) is delayed by 2 days, and Development is on the critical chain leading to Acceptance, then end date moves by 2 days: new total = 19 days.

Your exam answer should explicitly say:

• “Development is on the critical path because testing and acceptance cannot start until development is complete.”
• “Therefore, delay transfers to project completion unless recovery actions change dependencies.”

Schedule recovery options: crashing, fast-tracking, and scope trade-offs

When schedule slippage occurs, the exam expects you to propose recovery actions that respect constraints.

Crashing (adding resources)

• Add more people or subcontract capacity to reduce task duration.
• Risk: higher cost, possible coordination overhead, reduced quality if rushed.

Fast-tracking (overlapping phases)

• Start a successor activity earlier than planned.
• Risk: rework if the upstream work changes; quality risks.

Scope/schedule trade-off (change control)

• Reduce deliverables, move non-critical features, or change acceptance criteria.
• Risk: dissatisfaction with stakeholders; may require formal approvals.

A longer mini case: “Health Clinic Renovation—Materials Delayed, Milestones at Risk”

Case facts:

• Renovation project planned to complete in 10 weeks.
• Milestone: M1 (Week 4): walls installed.
• Milestone: M2 (Week 7): electrical wiring tested.
• Milestone: M3 (Week 10): final inspection and handover.
• Contractor reports that electrical materials are delayed by 1.5 weeks (can’t be partially delivered until shipment arrives).
• Budget has a hard ceiling; additional subcontracting is possible but requires approvals.

Question: “Propose a schedule recovery plan and explain stakeholder management implications.”

Diagnosis

• Electrical materials delay directly affects electrical wiring testing (M2).
• If wiring cannot be tested, final inspection and handover (M3) likely slip.
• However, some tasks might proceed in parallel: drywall finishing, plumbing checks, painting preparation.

Option A: Fast-tracking adjacent work (low cost)

• Prioritise tasks that do not depend on electrical materials.
• Overlap painting preparation with areas not requiring wiring completion.

Option B: Crashing with selective resources (moderate cost)

• Allocate additional labour to finish wall installation (already scheduled for M1) and accelerate non-electrical installation tasks.
• Focus on tasks with no dependency on delayed materials.

Option C: Scope adjustment through change control (high stakeholder risk)

• If deadline is immovable, propose temporary acceptance criteria: allow partial commissioning earlier and complete remaining fixtures after handover.

Recommendation (exam-ready)

• Use Option A + selective parts of Option B to protect M1 and minimise downstream delay.
• If M2 and M3 are still threatened, prepare a formal change request for scope adjustment (Option C) rather than informal concessions.
• Communicate clearly with stakeholders: explain the dependency, the recovery actions, and expected impact with confidence ranges (e.g., “likely 0.5–1.0 week slippage unless additional materials arrive earlier”).

Monitoring & controlling actions

• Update the schedule baseline after agreed changes.
• Create weekly milestone tracking: % completion for wall installation, readiness of electrical zones, testing backlog.
• Track leading indicators: procurement receipt date, installation readiness status, quality defect counts.

This is how you turn schedule theory into a realistic exam answer that contains diagnosis, options, evaluation, and controls.

Where students lose marks in scheduling questions

Common errors:

• Treating all tasks as equal rather than identifying dependencies.
• Writing a new schedule without discussing baselines and variance tracking.
• Proposing fast-tracking without addressing rework/quality risks.
• Ignoring that approvals might be required for crashing or scope change.

In short: examiners want decision logic, not just “do more tasks.”

Section 3: Risk, Uncertainty, and Change Control in Case Studies (Risk Register, Probability-Impact, Contingency Plans)

Risk management and change control are frequently tested because they reveal whether you can handle uncertainty and maintain governance. In TUT case studies, risks often “turn into” schedule and cost problems, and change control failures often become stakeholder conflict. This section covers how to identify, analyse, respond to risks, and manage changes using exam-appropriate structure.

Risk management in case studies: what examiners expect

A good risk response answer includes:

1. Risk identification: what could happen?
2. Risk description: who/what is affected, and how?
3. Risk analysis: probability and impact (often qualitative or semi-quantitative).
4. Risk response plan: avoid/mitigate/transfer/accept; identify actions.
5. Owner and triggers: who monitors and when to act.
6. Residual risk and contingency: what remains and what you do if it happens.

In exam conditions, even if they don’t ask for a full risk register, your narrative should cover these components.

Risk scoring: probability-impact matrix logic

TUT exams often provide a qualitative matrix:

• Probability levels: Low/Medium/High
• Impact levels: Low/Medium/High (time, cost, quality, safety)

When the case includes numbers (e.g., “probability 0.3” and “cost impact R50 000”), you can calculate expected monetary value (EMV). But even without numbers, qualitative ranking is crucial.

Exam-ready risk statement format:

“The vendor testing delay is a risk that can cause a schedule slippage of the development task by 2 weeks. Probability: Medium (because similar delays have occurred before). Impact: High (critical path dependency on testing and acceptance). Response: Mitigation by tightening vendor acceptance criteria and implementing a backup testing plan; contingency: reserve 3 days buffer and pre-prepare training materials with assumed configuration.”

Contingency reserves vs management reserves

Students often mix these. A consistent approach:

• Contingency reserve: for identified risks (time/cost allowances tied to specific risks).
• Management reserve: for unknown-unknowns and unforeseen issues not yet identified.

In case questions, if you propose “extra budget” for the delay, you should phrase it as contingency or management reserve depending on whether the risk was identified and quantified.

Example risk scenario (practice): Construction Materials Disruption

Case facts:
A road maintenance contract is underway. There is frequent disruption in supply chains. The project has a milestone completion target. A supplier warns that asphalt delivery may be delayed due to a national transport strike. Delay would affect “asphalt laying,” which is on the critical path.

Risk identification:

• Risk: “Asphalt delivery delay due to transport strike.”
• Cause: “National transport strike.”
• Effect: “Delay in asphalt laying, impacts milestone and completion.”

Analysis:

• Probability: Medium (strikes are periodic).
• Impact: High (critical path).

Response:

• Mitigate: source alternate supplier, arrange storage/transport, adjust work sequences (start preparatory tasks).
• Transfer: potentially include penalty clauses with supplier or negotiate supply guarantee (exam answers may mention contractual risk transfer).
• Contingency: allocate buffer time of a defined length for asphalt delivery uncertainty.

Change control: why it matters (and how it shows up in exam questions)

Change control is the process used to manage scope, schedule, and cost changes formally. In case studies, the exam often shows “scope creep” or “client asks for extra features” that disrupts the project.

A strong change control answer includes:

• Logging the change request (what is requested, who submitted it).
• Impact assessment:
  • Schedule: which activities affected?
  • Cost: labour/materials/contract adjustments
  • Quality: acceptance criteria changes?
  • Risk: new risks introduced or existing risks worsened?
• Review/approval: who decides (project sponsor, change control board).
• Implementation planning: update baselines and communicate changes.
• Documenting decisions.

Change control vs “informal approvals”

A typical exam scenario:
The client instructs the project manager to add features immediately (“just do it; we’ll figure it out later”). The project manager proceeds without formal approval.

In your answer, you should critique this:

• It bypasses governance.
• It prevents accurate cost/schedule baselining.
• It can lead to disputes later (“you promised X by date Y”).

Examiners want you to show that governance protects both the project and stakeholders.

A longer mini case: “University Lab Upgrade—New Requirements Arrive Mid-Sprint”

Case facts:
A lab upgrade project is planned with iterative delivery. Early phases are completed. Midway through, the end-user department requests new equipment specs:

• Additional sensors are required.
• Software configuration must support an added reporting feature.
• These changes are requested verbally and “must be ready by next month.”

Budget is tight and procurement lead times are long.

Question: “Identify risks and propose change control actions.”

Risk identification

1. Procurement risk: new sensors may require longer lead time.
2. Integration risk: additional reporting feature may cause system configuration delays.
3. Quality risk: rush to meet “next month” could increase defects.
4. Stakeholder risk: end-user expectations may change again without governance.

Risk analysis (qualitative)

• Probability: High for procurement lead time issues (since lead times are long).
• Impact: High because equipment readiness depends on procurement and integration.
• Quality impact: Medium-to-High.

Response plan

• Mitigate:
  • request written change proposal with clear requirements and acceptance criteria,
  • perform impact assessment on schedule and cost,
  • check integration complexity with technical leads.
• Contingency:
  • prepare alternative configurations or phased delivery approach.

Change control actions (exam-ready)

1. Log the change request.
2. Conduct impact assessment:
   • which WBS components change?
   • which schedule activities become dependent?
   • what is the cost delta and where is it sourced?
3. Convene review:
   • sponsor approval required for any schedule/cost impact.
4. If approved:
   • update scope baseline and schedule baseline,
   • communicate to procurement team and end-users,
   • update risk register with new risks.

Stakeholder communication plan

• Provide a realistic revised timeline with options:
  • Option A: fully implement by “next month” but trade off non-critical features.
  • Option B: keep quality intact, deliver in the next cycle with more thorough integration.
• Clarify “what is included” and “what is excluded” to prevent further scope creep.

Expected value thinking (optional but powerful if numbers exist)

If a case provides probability and cost/time impacts, you can calculate expected values to rank risks. Even when exam questions don’t require EMV, showing a simple expected impact calculation often earns marks because it demonstrates structured decision-making.

But ensure consistency:

• If you compute using provided probabilities and costs once, do not contradict yourself later.

Common pitfalls in risk and change control questions

• Listing risks without triggers, owners, or response actions.
• Proposing “do it faster” without addressing quality and rework risks.
• Treating change control as optional administrative work rather than governance.
• Ignoring dependency impacts on critical path and milestone dates.

Risk and change control answers are where examiners look for maturity and professional judgement.

Section 4: Stakeholder Management & Communication in Case Studies (Power–Interest, Engagement Plans, Conflict Resolution)

Stakeholders are often the hidden driver of project failure. In many case studies, schedule slips and quality problems occur because stakeholders don’t align on expectations, communication cadence is missing, or authority boundaries are unclear. This section equips you to answer stakeholder-focused questions using structured tools: stakeholder identification, power-interest mapping, engagement strategies, communication planning, and conflict resolution through governance.

Stakeholder identification: map everyone who can influence outcomes

A stakeholder is any person or group affected by the project or able to influence it. In TUT exam contexts, stakeholders typically include:

• Project sponsor (provides funding/authority)
• Client/customer (acceptance and requirements)
• Project manager (coordination and reporting)
• Functional managers (resource allocation)
• Contractors/vendors (execution and delivery)
• End-users (quality and usability requirements)
• Regulatory bodies (compliance and approvals)
• Internal committees/finance/procurement teams

Exam strategy

List stakeholders relevant to the case and relate each one to:

• their interest (what they care about),
• their influence/power (ability to impact),
• their likely stance (supportive, neutral, resistant),
• and communication needs.

Power–Interest grid: exam-friendly stakeholder classification

A classic approach: classify into four quadrants:

• High power / High interest: manage closely.
• High power / Low interest: keep satisfied.
• Low power / High interest: keep informed.
• Low power / Low interest: monitor.

In case answers, you don’t need to draw the grid, but you should describe the strategy.

Example: “Wi-Fi Upgrade in a Public Library”

• Sponsor (municipality IT director): high power, high interest → manage closely.
• Library manager: high power, high interest → manage closely.
• End-user librarians: low power, high interest → keep informed with training sessions.
• Contractor: medium/high power, medium interest → manage closely enough for delivery.
• Community oversight committee: medium power, medium interest → keep satisfied and informed.

Engagement strategies: what you do differently per quadrant

Your response should include actions:

• Manage closely: weekly steering updates, sign-off meetings, detailed reporting.
• Keep satisfied: periodic progress reports, escalation path, quick issue resolution.
• Keep informed: training schedules, user bulletins, open feedback channels.
• Monitor: minimal but regular updates, ensure no surprises.

Communication plan: cadence and content

Stakeholder communication is not just “inform people.” It’s a plan.

A typical communication plan includes:

• frequency (daily/weekly/biweekly/monthly),
• channel (email, meeting, dashboards),
• audience (who receives what),
• content (status, risks, changes, milestones),
• escalation thresholds (when issues go to sponsor),
• documentation (minutes, reports, logs).

In exams, you can propose a simple but structured plan such as:

• Weekly internal project stand-up: progress, blockers, next 7 days.
• Weekly sponsor update: milestone status, budget variance, top 3 risks.
• Biweekly stakeholder engagement: feedback collection and issue resolution.
• Change control committee meeting: as needed when scope or schedule changes occur.

Conflict resolution: stakeholder conflict is often a symptom of unclear baselines

Case studies often show conflict like:

• “Client complains quality is poor.”
• “Contractor blames missing approvals.”
• “Internal departments refuse to release staff.”
• “End-users protest training schedule.”

The correct exam move is to connect conflict to governance:

• Are baselines clear (scope acceptance criteria)?
• Are responsibilities clear (RACI or role ownership concepts)?
• Is there a documented change process?
• Is communication too infrequent or too late?

Exam-ready conflict resolution steps

1. Clarify facts: what exactly is the disagreement?
2. Reference baselines: compare current work against agreed scope/schedule/quality criteria.
3. Assess impact: determine schedule/cost/quality effects.
4. Align on decision: resolve via sponsor/change control if scope changes.
5. Document outcome: update logs, baselines if approved, and communicate to all stakeholders.
6. Prevent recurrence: improve requirements capture, sign-offs, acceptance tests.

A longer mini case: “E-government Services—Stakeholder Escalation and Approval Bottlenecks”

Case facts:
An e-government services project is delayed. The client department keeps escalating because:

• Requirements are changing every few weeks.
• The approvals for user acceptance testing (UAT) are slow.
• A contractor claims it cannot proceed without sign-offs.
• Meanwhile, the project sponsor complains the project manager is not providing “decision-ready information.”

Question: “Design a stakeholder engagement and communication approach to reduce escalations.”

Stakeholder analysis

• Client department: high interest, high power → manage closely.
• Project sponsor: high power, medium interest → keep satisfied with decision-ready reporting.
• Contractor: medium power, high interest → manage through clear acceptance criteria and timely approvals.
• UAT testers/end-users: medium interest, low power → keep informed and schedule training/feedback sessions.
• Internal approval committees: medium power, medium interest → keep satisfied; provide templates and pre-approval documentation.

Engagement plan

• Establish a Requirements Change Control:
  • all new requirements must go through change request logging.
• Introduce a UAT approval workflow:
  • define acceptance criteria up front,
  • provide test evidence packs,
  • set service-level timing (e.g., approvals within a defined timeframe).
• Create escalation thresholds:
  • if a UAT sign-off is not granted within a specified window, escalate with evidence and options (reschedule, partial acceptance, mitigation).

Communication approach

• Sponsor dashboard focusing on:
  • milestone variance,
  • budget variance,
  • risks requiring sponsor action,
  • decisions needed and options.
• Client weekly session:
  • review backlog of changes,
  • confirm acceptance criteria and priority,
  • agree on next milestone deliverables.

What to do if stakeholders resist

In exams, resistance often occurs when stakeholders fear loss (budget, control, political risk) or uncertainty. Your response should include:

• involvement in planning,
• transparency (what is changing and why),
• negotiation (trade-offs explicitly stated),
• and governance (decisions documented).

A strong answer frames stakeholder resistance as:

• “information gap,” “expectation mismatch,” or “governance failure,”
  and then proposes actions aligned to those root causes.

Common stakeholder answer weaknesses

• Listing stakeholders but not describing their power/interest or engagement approach.
• Proposing communication without frequency, content, or escalation logic.
• Treating conflict as emotional rather than governance and baselines.

Stakeholder marks come from showing that communication and governance are tools for controlling project outcomes.

Section 5: Integrated Case Study Practice—Applying Earned Value, Budgeting Logic, Quality Acceptance, and Final Decision-Making

To perform well in a full TUT case study exam, you must integrate multiple knowledge areas: planning, scheduling, risk, stakeholder engagement, budgeting, and quality management. This final section provides an exam-style integrated case with calculations and structured decision-making, plus guidance on how to write a complete final answer under time constraints.

Why integrated practice matters

Real projects rarely fail due to one cause. A schedule slip may result from risk materialisation, which triggers change requests, which creates stakeholder conflict, which then increases quality defects and cost variances. Exams test whether you can see the chain of cause and effect.

Core concepts to integrate (quick refresher)

1. Scope and deliverables: what “done” means.
2. Schedule baseline: planned timeline for milestones.
3. Budget baseline: planned cost, often broken into cost accounts.
4. Monitoring & controlling: measuring progress and variance.
5. Risk register update: new risks from change or new information.
6. Stakeholder communications: decision-ready updates and approval workflows.
7. Quality acceptance: criteria and evidence.
8. Change control: formally log and assess impacts.

Earned Value Management (EVM): what you should compute and how to interpret

EVM uses three key metrics:

• Planned Value (PV): budgeted cost of work scheduled by a certain date.
• Earned Value (EV): budgeted cost of work actually performed by that date.
• Actual Cost (AC): actual cost incurred by that date.

Then:

• Schedule Variance (SV) = EV − PV
• Cost Variance (CV) = EV − AC

Often derived indicators:

• Schedule Performance Index (SPI) = EV / PV
• Cost Performance Index (CPI) = EV / AC

Interpretation:

• If EV < PV → behind schedule (negative SV, SPI < 1).
• If EV < AC → over budget (negative CV, CPI < 1).

In many TUT exams, you may not need full EAC (Estimate at Completion), but if numbers are provided, you should compute at least SV and CV and interpret.

Integrated mini case with EVM and quality acceptance

Case facts (use consistently throughout this section):
A project called Campus Smart Lighting Upgrade is scheduled for 20 weeks with a total budget of ZAR 2,000,000. At the end of Week 12, the project manager reports the following:

• PV (Planned Value) at Week 12: ZAR 1,200,000
• EV (Earned Value) at Week 12: ZAR 1,050,000
• AC (Actual Cost) at Week 12: ZAR 1,180,000

Milestones:

• M2 at Week 10: cable installation and rough-in complete (passed).
• M3 at Week 14: sensor calibration and commissioning (not yet complete).
  Quality evidence:
• Two inspection reports show issues: sensor calibration defects in 3 out of 30 zones tested (10%).
  Change governance:
• The client requested new sensor firmware settings after Week 10; the request was not fully documented in the change log, though the contractor started implementing it.

Question (multi-part):

1. Compute SV and CV for Week 12 and interpret schedule and cost performance.
2. Identify likely causes of the variances based on the case facts.
3. Recommend actions for the next 8 weeks (Week 13–20) including risk updates, change control, stakeholder communication, and quality measures.

Part 1: EVM calculations

• SV = EV − PV = ZAR 1,050,000 − 1,200,000 = −ZAR 150,000

  • Interpretation: behind schedule (negative SV).
  • SPI would be EV/PV = 1,050,000 / 1,200,000 = 0.875 (optional but helpful).

• CV = EV − AC = ZAR 1,050,000 − 1,180,000 = −ZAR 130,000

  • Interpretation: over budget (negative CV).
  • CPI = EV/AC = 1,050,000 / 1,180,000 ≈ 0.898 (optional).

So by Week 12, the project is both behind schedule and over budget.

Part 2: Likely causes (root-cause linking)

Based on case facts:

1. Change governance failure:

   • Client requested firmware settings after Week 10, and the request was not fully documented in the change log.
   • This likely caused rework or integration delays, increasing AC and lowering EV (less earned progress relative to plan).

2. Risk materialisation / technical uncertainty:

   • Sensor calibration defects occurred in 3 out of 30 zones tested.
   • Calibration defects suggest that the firmware settings changes or commissioning procedure changes introduced quality instability.

3. Dependency and schedule impact:

   • Sensor calibration and commissioning (M3 at Week 14) is not complete.
   • Delays in calibration imply downstream schedule slippage.

Therefore, the variances connect plausibly to:

• scope/change control issues → rework and schedule delays,
• quality control gaps → defects discovered during testing,
• stakeholder expectation mismatch → implementation without full sign-off.

Part 3: Recommended actions for Week 13–20

Your answer should integrate:

A) Change control correction (must be formal)

1. Immediately log the firmware setting changes as a change request.
2. Conduct an impact assessment:
   • schedule impact on Week 14 commissioning,
   • cost impact on AC variance (additional labour, retesting).
3. If changes are approved:
   • update scope baseline and relevant acceptance criteria.
4. If changes are not approved:
   • decide whether to roll back or keep the partially implemented configuration under a controlled variance.

This addresses the governance failure noted in the case.

B) Risk register update with response plans

Add or update risks:

• Risk: “Calibration defects persist after firmware changes.”
  • Probability: Medium (defects already observed).
  • Impact: High (affects commissioning milestone).
  • Response: implement revised calibration procedure and require vendor support on firmware compatibility.
• Risk: “Further undocumented requirement changes occur.”
  • Probability: Medium-to-High until approvals and sign-offs improve.
  • Response: enforce change control and set a requirements freeze window by a specific date (e.g., before Week 16).

Even if the exam doesn’t ask you to quantify probability and impact numerically, you should describe responses and triggers.

C) Quality measures (defect prevention and acceptance alignment)

Given the defect evidence (3 out of 30 zones = 10% defect rate in tested zones), recommend:

1. Root cause analysis for calibration defects:
   • confirm firmware version mapping per zone,
   • validate sensor calibration procedure and settings,
   • verify whether vendor or integration steps are misconfigured.
2. Corrective action plan:
   • re-calibrate and retest affected zones,
   • implement sampling-based testing for remaining zones with predefined acceptance criteria.
3. Quality acceptance criteria alignment:
   • define what “pass commissioning” means (e.g., acceptable calibration variance thresholds).
4. Vendor escalation:
   • request technical support for firmware compatibility and provide evidence to justify escalation.

D) Schedule recovery actions (since EV < PV)

Because the project is behind schedule (SV = −150,000), schedule recovery should be realistic:

1. Replan the remaining work for Week 13–20 using dependencies:
   • calibration must finish before commissioning readiness.
2. Protect the critical tasks leading to M3 at Week 14:
   • allocate priority resources to calibration tasks likely to unblock commissioning.
3. Consider selective fast-tracking:
   • while awaiting resolution of calibration defects, prepare commissioning readiness tasks for zones likely to pass.
4. If schedule pressure is extreme:
   • consider crashing for calibration teams, but link to budget implications and approval thresholds.

E) Stakeholder communication (decision-ready, not vague)

Because variances exist, stakeholder communication must support decisions:

• Weekly sponsor update (Week 13 onwards):

  • status: behind schedule, over budget,
  • decisions needed: approval of change request and additional corrective actions,
  • top risks: calibration defects and future changes,
  • quality evidence: current defect rate and mitigation progress.

• Client engagement:

  • confirm firmware settings as the approved baseline for the remainder,
  • agree on acceptance criteria and sign-off process to avoid additional rework.

F) Monitoring & controlling KPIs (what you track weekly)

To show exam mastery, state KPIs:

• Schedule KPI: % of calibration tasks completed vs planned for Week 14 milestone readiness.
• Cost KPI: forecasted spending trend relative to budget (at least qualitative “spend rate is higher than planned”).
• Quality KPI: number of defective zones / total zones tested (track defect count progression, not only a single snapshot).
• Change KPI: number of changes logged and approved vs implemented without approvals (should move toward 100% controlled).

How to present a “final recommendation” in exam style

End your integrated answer with a concise, decision-focused statement:

• Confirm performance: “At Week 12, SV is −ZAR 150,000 and CV is −ZAR 130,000; the project is behind schedule and over budget.”
• Explain why: “Likely driven by undocumented firmware changes causing calibration defects and rework.”
• Recommend: “From Week 13–20, enforce formal change control, update risk responses, strengthen quality acceptance and calibration procedures, and re-baseline schedule with focus on commissioning readiness.”
• Provide governance: “Communicate weekly in decision-ready format to sponsor and client; monitor KPIs for schedule, cost, quality, and controlled changes.”

This closing pattern tends to score well because it ties back to calculations and case facts.

Additional integrated practice cues (what to write even if not asked directly)

If the question includes time pressure and you’re asked for recommendations:

• mention updating baselines,
• mention change log governance,
• mention risk register updates,
• mention quality evidence and acceptance criteria,
• mention stakeholder communication cadence and escalation.

Even if not every element is explicitly requested, they demonstrate comprehensive project management competence.

Common integrated case errors (watch for these)

• Correctly calculating SV/CV but giving unrelated recommendations (e.g., only “communicate better” with no change control or quality measures).
• Proposing schedule recovery without considering cost performance (if CV is negative, crashing may worsen budget unless approved).
• Ignoring the defect evidence (3 out of 30 zones) while talking only about schedule.
• Not connecting undocumented change requests to increased rework and cost variance.

Final Exam Strategy: Turning Case Studies into Repeatable Scores (TUT Project Management Course Notes Focus)

To finish strong in the TUT Project Management case-study exam, the goal is not memorizing definitions—it’s building a repeatable “case-to-answer pipeline” that you can apply under time pressure.

A repeatable 10-minute case analysis workflow

When you receive a case, do:

1. 2 minutes: Fact extraction
   • timeline, budget totals, milestones, quality evidence, change notes.
2. 3 minutes: Diagnose
   • schedule problem, cost problem, quality issue, stakeholder conflict, change governance failure.
3. 3 minutes: Choose tools
   • WBS/scope clarity (if deliverables unclear),
   • critical path reasoning (if delay impact matters),
   • risk register actions (if uncertainty shown),
   • change control steps (if new requirements occur),
   • stakeholder engagement and comms (if conflict/escalations occur),
   • EVM interpretations (if PV/EV/AC provided).
4. 2 minutes: Draft answer skeleton
   • headings or bullet structure matching your course learning outcomes.

How to write faster without losing marks

• Use consistent headings in your answer: “Problem,” “Options,” “Recommendation,” “Implementation & Monitoring.”
• Use numbers when provided (like SV/CV) and interpret them.
• Tie every recommendation to a cause mentioned in the case.

What “good” looks like in marking language

A good TUT case-study answer reads like:

• a diagnosis memo,
• a decision document,
• a monitoring plan.

Not like:

• a generic essay,
• a list of unrelated theory definitions,
• or a purely narrative summary.

Final consistency reminder for your revision

Practice with consistent assumptions:

• If you compute a defect rate or EVM figures, don’t restate different values later.
• If you recommend a baseline update, mention it in the implementation and monitoring parts.
• If you propose change control, show how it affects baselines and stakeholder approvals.

This guide’s core method—structured reasoning anchored to project management processes—is what turns case-study exams into predictable outcomes.

(End of TUT Project Management Case Studies Exam Prep Study Guide)