The Postgraduate Diploma in Project Management (PGDip PM) is built around practical project leadership, rigorous planning, and evidence-based decision-making. These study notes focus on what you are most likely to encounter across university modules—especially frameworks and exam-style explanations used in South African business schools and university qualifications (including learning areas that commonly appear under modules such as MNG 0001 in project management streams). Because assessment practices vary by institution, these notes are written to help you answer typical PGDip PM questions: define concepts, apply models to scenarios, calculate key metrics, justify trade-offs, and evaluate risks with professional reasoning.
This guide is aligned to the broader Stellenbosch Business School (USB) Project Management Programme Guides collection and clusters key content around a South African university-style study approach—clear definitions, structured processes, and applied examples.
Stellenbosch Business School (USB) PGDip PM Study Notes: Project Scope, Governance, and the “Business Case” Logic (USB-style)
At PGDip level, the core distinction between “good project thinking” and “professional project management” is that decisions are made with governance, evidence, and measurable outcomes. In the context of a Stellenbosch Business School (USB) Project Management Programme, you’re expected to treat project management as a management discipline—where you connect the project to strategy, justify investment through the business case, plan delivery through scope and schedule logic, and manage stakeholders through governance and communication structures.
1) Project Governance: Why It’s Not Optional
Project governance is the framework that ensures the project is directed, monitored, and controlled so that it delivers value consistent with organisational goals. Governance typically includes:
- Roles and responsibilities (sponsor, project manager, steering committee, functional managers, etc.)
- Decision rights (who approves what, when)
- Reporting lines (performance reporting cadence and formats)
- Stage gates or review points (e.g., approve business case before full build)
- Escalation procedures (how issues and risks move upward)
A frequent exam trap is to describe governance as “meetings.” In professional terms, governance is decision-making and accountability embedded into a system.
Common governance artefacts
To write exam-ready answers, memorise how artefacts relate to governance:
- Business case: justification for why the project should exist
- Project charter: high-level authority and initial objectives
- Project brief / statement of requirements: what outcomes are needed
- Scope statement: what is included and excluded
- WBS (Work Breakdown Structure): how scope is decomposed
- Schedule baseline: planned time performance
- Cost baseline: planned cost performance
- Risk register: risks, owners, probabilities, impacts, responses
- Change control documentation: how scope/time/cost changes are assessed
- Performance measurement plan: how success is measured and reported
USB-style reasoning pattern (use in answers)
When answering a scenario question (e.g., “project is drifting”), structure your reasoning as:
- Identify governance failure (e.g., unclear decision rights, no stage gate approval, weak change control)
- Tie to consequence (schedule slippage, cost overrun, value erosion)
- Propose corrective action (update baselines through formal change control; refresh business case; reconstitute steering committee)
- Define success criteria (what evidence proves improvement)
This approach shows the marker that you can connect management logic to project control outcomes.
2) The Business Case: Making Value Measurable
The business case is the economic and strategic justification for the project. You should be able to explain it as both:
- A document (auditable justification)
- A logic chain (value drivers → outcomes → measurable benefits)
A strong business case usually includes:
- Problem / opportunity statement
- Objectives aligned with business strategy
- Options appraisal (baseline vs alternatives)
- Costs (capex/opex where applicable)
- Benefits (quantified and qualified)
- Risks and assumptions
- Funding and affordability
- Benefit realisation plan (how benefits are tracked after delivery)
Example: Digitisation project business case logic
Imagine a logistics company plans a warehouse digitisation project. The business case could specify:
- Problem: manual inventory counts cause stock-outs and audit delays
- Objective: reduce stock-out rate and improve stock accuracy
- Option A: fully replace WMS with a new system (higher cost)
- Option B: upgrade existing WMS modules (lower cost)
- Benefits:
- Inventory stock accuracy improves from 85% to 96%
- Stock-out incidents reduce from 30 per month to 12 per month
- Audit cycle time reduces from 10 days to 5 days
Even if your exam question doesn’t ask you to compute NPV, it expects you to explain how benefits become measurable and how you validate assumptions (e.g., training effectiveness, supplier lead times).
3) Scope Management: From Requirements to Boundaries
Scope management prevents the project from expanding beyond its intended purpose (“scope creep”). At PGDip level, scope management is not simply writing “scope is included/excluded”—it’s ensuring scope is:
- Defined clearly
- Traceable to objectives
- Controlled through change management
- Verified through acceptance criteria
Scope types you must differentiate
In exams, clarity matters. Typical distinctions include:
- Product scope: characteristics and features of the deliverable
- Project scope: work required to deliver the product
- Functional requirements: what the system or output must do
- Non-functional requirements: performance, security, compliance, usability
- Acceptance criteria: measurable standards used to decide “done”
Practical approach: “Requirements → WBS → Deliverables”
A credible PGDip answer maps:
- Business objectives
- Requirements (functional and non-functional)
- Deliverables (what will be produced)
- WBS (how deliverables are decomposed into work packages)
- Control points (reviews, acceptance testing)
This prevents disconnected planning where a schedule exists but isn’t tied to requirements.
4) Schedule and Cost Baselines: Planning with Control in Mind
Planning is not only about creating a plan; it’s about establishing baselines that enable control. A baseline is an agreed reference point used to compare actual results.
Key baseline concepts:
- Schedule baseline: planned start/finish times (including critical path assumptions)
- Cost baseline: planned expenditure by period or activity
- Performance baseline: integrated plan including scope/time/cost measures
Example: Baseline arithmetic in a mini-scenario
Suppose a project’s approved cost baseline for a phase is R2,400,000, spread across four months:
- Month 1: R600,000
- Month 2: R700,000
- Month 3: R600,000
- Month 4: R500,000
Total = R600,000 + R700,000 + R600,000 + R500,000 = R2,400,000
If actual spending by Month 3 is R1,500,000, control requires comparing against what should have been spent by that time—not against the total budget. Even if you don’t use full earned value in an exam, the logic must be correct.
5) Stakeholder Management: Mapping Power, Interest, Influence
Stakeholder management includes identifying stakeholders, understanding influence levels, planning engagement, and managing communications.
Stakeholder mapping
A common model divides stakeholders by:
- Power (ability to influence outcomes)
- Interest (likelihood of being affected or caring about progress)
Typical strategies:
- High power / high interest: manage closely (frequent updates, participation)
- High power / low interest: keep satisfied (brief, strategic reporting)
- Low power / high interest: keep informed (workshops, channels for feedback)
- Low power / low interest: monitor (periodic communication)
USB-style “exam answer” language
Markers often reward phrasing that shows you understand stakeholder dynamics:
- “Engagement plan should reflect influence and information needs”
- “Communication cadence aligns to decision points and risk exposure”
- “Resistance is treated as information, not just opposition”
6) Change Control: Protecting Baselines Without Blocking Delivery
Change control ensures that changes are:
- logged,
- assessed for impact on scope/time/cost/benefits,
- approved through defined authority,
- implemented with traceable updates.
A mature change control process balances:
- Control (prevent uncontrolled scope creep)
- Responsiveness (avoid bureaucracy that stalls delivery)
Mini-case: Change request mismanagement
A project team delivers a stakeholder-required feature but later receives a request to add extra reporting fields. If this is handled as “just add it,” the WBS and schedule become inaccurate; later the steering committee loses confidence. If handled properly, the request becomes:
- Change log entry
- Impact assessment (e.g., additional development days, testing effort, training changes)
- Decision by authority (steering committee vs sponsor)
- Updated baseline through formal approval
A strong answer emphasises traceability: “this decision changes baselines and triggers updated reporting.”
University-Style PGDip PM Learning Cluster: UP / CUT / Unisa-Influenced Thinking on Risk, Quality, and Delivery Assurance (Project Assurance & Exam Calculations)
South African university modules often blend classic project management concepts with assessment styles that test both analysis and reasoned judgement. Risk, quality, and delivery assurance are where many students lose marks by being too generic. This section strengthens exam performance using structured risk logic, quality planning, and risk-response trade-off reasoning.
1) Risk Management: From Register to Action
Risk management is systematic identification, analysis, response planning, and monitoring of risks. At PGDip level, you must go beyond “list risks” and show:
- risk ownership,
- probability and impact assessment,
- response strategies,
- monitoring triggers (“risk indicators”).
Risk types to recognise
Common categories:
- Schedule risks: supplier delays, dependency failures
- Cost risks: price inflation, labour rate changes
- Scope risks: requirements volatility, unclear acceptance criteria
- Technical risks: integration complexity, performance failure
- External risks: regulatory changes, macroeconomic impacts
- People risks: skills gaps, turnover, training failure
- Governance risks: delayed approvals, poor decision rights
Probability–Impact matrix (how to write exam answers)
A probability–impact matrix classifies risk severity. Even if your exam does not require calculation, markers expect you to explain severity logic.
A useful description:
- probability: Low / Medium / High (or 0–1 scale)
- impact: Low / Medium / High (or monetary/time measures)
- score: probability × impact (if numeric)
Example: Numeric risk scoring (simple and exam-friendly)
Assume a project uses a 1–5 scale:
- Probability (P): 1=Low, 5=High
- Impact (I): 1=Low, 5=High
- Risk score = P × I
Risk A: supplier lead time variability
- P = 4, I = 3 → score = 12
Risk B: data migration errors
- P = 3, I = 5 → score = 15
Then you prioritise Risk B first due to higher score.
Response strategies: exploit, mitigate, transfer, accept, avoid
Your answers must show you understand response intent:
- Avoid: change plan to remove the risk
- Mitigate: reduce probability or impact (e.g., testing, supplier contracts)
- Transfer: shift impact to another party (insurance, fixed-price contract)
- Exploit: if risk has upside (less common but acceptable)
- Accept: no change now, but monitor and create contingency
A common exam issue is confusing mitigate vs transfer. Mitigation reduces the underlying risk; transfer shifts financial or operational responsibility.
2) Contingency Planning: What You Budget for Uncertainty
Contingency is budget reserved for identified risks that may occur. It is not the same as management reserve.
Distinguish:
- Contingency: for specific risks in risk register (part of baseline planning, often linked to probability/impact)
- Management reserve: for unknown unknowns and unforeseen issues (controlled by senior management)
A high-quality exam answer explains how contingency is allocated. For instance, if you estimate:
- Risk A expected cost increase = probability × impact
- then contingency is set accordingly (within governance rules)
Example: Expected monetary value (EMV) for contingency
Risk A expected delay cost impact if it occurs: R300,000
Probability of occurrence: 40% (0.4)
EMV = 0.4 × 300,000 = R120,000
So you might allocate contingency around R120,000 for that risk (subject to how your institution defines baseline vs reserves).
If a later section requires total contingency assumptions, keep them consistent. In this guide, we’ll use this EMV approach for reasoning examples; we do not reuse additional risk numbers elsewhere unless explicitly restated.
3) Quality Management: Planning for “Fitness for Use”
Quality management ensures deliverables meet requirements. At PGDip level, quality is not inspection-only—it’s prevention and assurance.
Key quality concepts:
- Quality planning: define quality standards and criteria
- Quality assurance: systematic activities to ensure process quality
- Quality control: operational activities to verify deliverable quality
Quality planning artefacts
- Quality management plan
- Inspection and test plans (ITPs)
- Acceptance criteria
- Traceability matrix (requirements → tests → acceptance evidence)
Scenario example: Software project with poor quality assurance
If unit testing exists but no integration testing is performed, a common failure appears late: systems fail during integration. This shows process quality was insufficient. A correct answer would propose:
- adding integration test gates,
- ensuring test coverage aligns with non-functional requirements (performance/security),
- requiring defect triage criteria for release readiness.
4) Delivery Assurance: Verification, Validation, and Traceability
A high-scoring exam answer differentiates:
- Verification: “Are we building the deliverable correctly?”
(e.g., testing that matches specified requirements) - Validation: “Are we building the right deliverable?”
(e.g., stakeholder acceptance that outcomes meet business needs) - Traceability: evidence that each requirement has been addressed
Acceptance testing example
Suppose a public sector project delivers a service portal. Acceptance criteria could include:
- login works for all required user roles,
- response time under 2 seconds for typical transactions,
- audit logs generated for each transaction,
- compliance with data protection requirements.
The exam expects you to explain not only testing but governance: who signs acceptance, what evidence is required, what happens if failures occur.
5) Earned Value Management (EVM): Often Tested in Calculations
Many project management assessments include EVM because it integrates scope, schedule, and cost. The key metrics:
- PV (Planned Value): budgeted cost for planned work up to a point
- EV (Earned Value): budgeted cost for the work actually completed
- AC (Actual Cost): actual spending for the work performed
Derived metrics:
- Schedule Variance (SV) = EV − PV
- SV < 0 indicates behind schedule
- Cost Variance (CV) = EV − AC
- CV < 0 indicates over budget
- Cost Performance Index (CPI) = EV / AC
- CPI < 1 means cost inefficiency
- Schedule Performance Index (SPI) = EV / PV
- SPI < 1 means schedule inefficiency
Mini calculation (write clearly)
Assume at the end of Month 2:
- PV = R800,000 (planned to have done work budgeted at R800,000)
- EV = R600,000 (actually completed work worth R600,000)
- AC = R700,000 (spent R700,000)
Then:
- SV = EV − PV = 600,000 − 800,000 = −R200,000 (behind schedule)
- CV = EV − AC = 600,000 − 700,000 = −R100,000 (over budget)
- CPI = EV / AC = 600,000 / 700,000 ≈ 0.86
- SPI = EV / PV = 600,000 / 800,000 = 0.75
A high-quality exam response states what the signs mean and what management actions follow (e.g., investigate root cause, update forecasts, adjust resources, tighten scope controls).
6) Corrective and Preventive Actions (CAPA)
When quality issues or risks materialise, corrective actions fix the problem; preventive actions stop it from recurring.
In exam terms, avoid vague “we will improve quality.” Instead:
- define the root cause (e.g., training gaps, unclear requirements, supplier defects),
- choose action type (corrective vs preventive),
- assign ownership and timelines,
- specify how effectiveness will be verified (e.g., improved defect rates in next release).
University-Style PGDip PM Learning Cluster: WBS, Scheduling Logic, and Critical Path—Applying Theory to South African Project Scenarios (USB + SA Context)
Many PGDip students can describe WBS, but they struggle with converting it into a usable schedule and explaining logic under exam conditions. This section focuses on practical scheduling logic: dependency relationships, critical path reasoning, and how schedule baselines are managed.
1) Work Breakdown Structure (WBS): Making Scope Executable
A WBS decomposes project scope into smaller components called work packages. The goal is to:
- clarify what work must be done,
- enable accurate estimation,
- provide control points,
- support responsibility assignment (RACI mapping to work packages).
WBS structure example: Construction + implementation hybrid
Consider a project: “Implement a smart building access system and associated infrastructure.”
WBS (illustrative):
- Project Management
- 1.1 Governance and reporting
- 1.2 Stakeholder engagement
- 1.3 Change control
- Requirements and Design
- 2.1 Security requirements
- 2.2 System design and architecture
- 2.3 Stakeholder sign-off
- Infrastructure Installation
- 3.1 Cabling and conduit work
- 3.2 Device installation
- System Configuration and Integration
- 4.1 Access policy configuration
- 4.2 Integration with HR system
- Testing and Commissioning
- 5.1 Functional testing
- 5.2 Integration testing
- 5.3 Performance validation
- Training and Handover
- 6.1 User training sessions
- 6.2 Documentation and handover
- 6.3 Final acceptance
In exams, the marker wants to see the logic: each WBS branch ties to deliverables, and work packages are manageable units.
2) Estimation: Time and Cost Using Reasonable Assumptions
Estimation methods include:
- expert judgement,
- analogous estimation,
- parametric estimation,
- bottom-up estimation.
At PGDip level, what matters is not only the method but the assumptions. For example:
- productivity rates depend on skills,
- rework probability depends on requirement stability,
- supplier lead times affect schedule risk.
Example: Bottom-up schedule estimation
Suppose work package “Integrate HR system APIs” includes:
- API discovery: 5 days
- configuration: 8 days
- unit tests: 3 days
- integration tests: 6 days
- rework buffer: assumed 2 days
Total duration = 5 + 8 + 3 + 6 + 2 = 24 days
In an exam scenario, if stakeholders request additional fields, you must state how that changes estimation inputs.
3) Scheduling Techniques: Dependencies and Logic
Schedules rely on relationships among activities:
- FS (Finish-to-Start): successor starts when predecessor finishes (most common)
- SS (Start-to-Start): successor starts when predecessor starts
- FF (Finish-to-Finish): successor finishes when predecessor finishes
- SF (Start-to-Finish): successor finishes when predecessor starts (rare)
Correct exam answers explain why dependencies exist. Dependencies are not arbitrary; they represent real constraints such as:
- physical availability,
- technical prerequisites,
- approval dependencies,
- resource constraints.
4) Critical Path: Understanding the Logic Under Pressure
The critical path is the longest path through the network diagram in terms of duration; delays on critical path activities delay the project completion.
To reason about critical path without a diagram, you can use calculations of earliest start/finish (ES/EF) and latest start/finish (LS/LF) (or narrative equivalents). If you do provide a small activity network in exam answers, clearly label durations and dependencies.
Example critical path reasoning (narrative)
Assume activities:
- A: 4 days (start)
- B: 6 days (FS after A)
- C: 3 days (FS after A)
- D: 5 days (FS after B)
- E: 2 days (FS after C)
- F: 1 day (FS after D and E; i.e., final depends on both)
Path 1 (A→B→D→F):
- 4 + 6 + 5 + 1 = 16 days
Path 2 (A→C→E→F):
- 4 + 3 + 2 + 1 = 10 days
Project duration = max(16, 10) = 16 days, so critical path is A→B→D→F.
A strong answer then says what happens if B delays by 2 days: new duration becomes 18 days unless recovery actions intervene.
5) Schedule Compression: Trade-offs You Must Justify
Schedule compression methods include:
- Crashing: add resources to reduce duration at additional cost
- Fast-tracking: perform activities in parallel that would otherwise be sequential
Exam markers typically expect you to evaluate risks introduced by compression. For example, fast-tracking may increase:
- rework,
- integration defects,
- change control disputes.
Mini-case: Fast-tracking risky integration
A project intends to do system integration after configuration complete, but stakeholder pressure asks to start integration earlier. Correct response:
- document the new dependencies and revised logic,
- update risk register (increase probability of defects),
- define quality gates and testing intensification,
- clarify governance approvals required for parallel work.
6) Updating the Baseline and Forecasting
When actual progress differs from the plan, you should:
- collect progress data (percent complete, milestones achieved),
- compare against baseline (schedule variance),
- update forecast (Estimate at Completion, EAC) if using cost),
- implement recovery plan if variance threatens milestones.
Even without formal EVM calculations, you should use evidence: milestone slips, deliverable acceptance delays, supplier lead time deviations.
University-Style PGDip PM Learning Cluster: Procurement, Contracts, Stakeholders, and Professional Risk Allocation in South African Projects (USB + SA Corporate Realities)
Projects often fail not because planning was impossible, but because contracting and procurement did not align to delivery logic. This section focuses on procurement management, contract types, stakeholder contracting, and how procurement decisions connect to schedule, quality, and risk.
1) Procurement Planning: Buying as Part of Delivery Strategy
Procurement management includes deciding what to buy, how to buy it, and how to manage suppliers during delivery. In PGDip exams, procurement is often assessed through scenarios involving:
- supplier delay,
- contract claims,
- quality failures,
- scope misunderstandings,
- payment disputes.
Your answer should link procurement to:
- scope,
- schedule,
- risk allocation,
- governance reporting.
Procurement planning questions to answer in exams
- What deliverables will be procured?
- What selection criteria will be used (technical capability, price, delivery capability)?
- How are risks divided between buyer and supplier?
- How will contract performance be monitored (SLAs, KPIs, acceptance criteria)?
- What governance approvals are needed for contract changes?
2) Contract Types: Choosing Based on Uncertainty
Common contract structures:
- Fixed-price: supplier bears cost risk; buyer bears scope clarity burden
- Time-and-materials: buyer pays for actual effort; useful when scope uncertain
- Cost-plus: buyer covers costs plus fee; requires strong oversight
- Unit price: payment based on measured quantities
Exam answers should avoid “one-size-fits-all.” Instead, choose based on uncertainty:
- If scope is stable and outputs are clearly defined → fixed-price may work
- If scope is evolving or technical uncertainty is high → time-and-materials or cost-plus may reduce buyer risk of unrealistic bids
Risk allocation logic example
If a buyer chooses fixed-price without clear requirements, suppliers may:
- build contingency into price,
- refuse later changes,
- demand formal variations for delays and defects.
If a buyer uses time-and-materials but lacks controls, suppliers may:
- overrun hours,
- underperform without consequence.
So the “best” contract depends on capability to manage and enforce.
3) Supplier Performance Management: Monitoring and Incentives
Supplier performance should include measurable indicators such as:
- delivery adherence (on-time percentage),
- quality defect rate,
- response time to issues,
- compliance with reporting obligations.
Service Level Agreements (SLAs)
SLAs typically cover:
- service availability,
- turnaround times,
- escalation procedures,
- penalties and remedies.
In exams, it helps to show that SLAs are not just legal text; they influence operational governance.
4) Procurement and Change: Variations and Claims
Contract changes are a major source of disputes. A professional answer must show understanding of:
- variation orders,
- contract interpretation,
- evidence requirements,
- change control aligned to contractual mechanisms.
Mini-case: Variation order without documented baseline
If the buyer requests additional work informally (“can you add extra screens?”) without:
- written variation,
- agreed cost/time impacts,
- updated acceptance criteria,
then later disputes occur when supplier delivers late or expects additional payment.
Correct exam advice:
- use formal change procedures,
- document approvals,
- assess impacts on schedule and budget,
- update baselines and reporting.
5) Stakeholder Governance in Procurement: Sponsor, Project Manager, and Functional Owners
Procurement isn’t just a procurement department activity. Effective PGDip-level practice:
- sponsor ensures strategic fit and funding,
- project manager ensures schedule and risk control,
- functional owners ensure technical acceptance and operational readiness,
- legal/procurement experts ensure contract compliance.
Exam answers should clearly place responsibilities. A vague “procurement will handle it” is insufficient.
6) Example Procurement Scenario (Exam-Style)
A project for a healthcare provider needs a vendor to implement an integrated reporting module. The vendor’s initial estimate assumes access to stable data interfaces. Midway, a system update by the internal IT team changes the APIs without warning.
Impacts:
- integration fails initial tests,
- rework is required,
- schedule slips.
Professional response:
- Activate risk plan: update integration risks and probability/impact
- Use contract mechanisms: clarify whether API changes are within scope of internal changes or vendor assumptions
- Governance escalation: steering committee decision on timeline and cost impacts
- Quality controls: regression testing after API changes
- Change control: document the revised requirements and acceptance criteria
This answer shows procurement is connected to change control, quality assurance, and governance.
Exam-Ready Synthesis: How PGDip PM Questions Are Marked and How to Score High (Models + Applied Writing Skills)
To perform well in PGDip PM assessments, you must combine technical knowledge with structured exam writing. This final cluster synthesises the earlier themes into an exam method you can apply repeatedly. It also helps you avoid common failure modes: generic answers, missing calculations, uncontrolled assumptions, and weak linkage between concepts.
1) The Marking Pattern: Definition → Application → Justification → Recommendation
Most postgraduate project management marking schemes reward:
- Definition or concept explanation (what it is)
- Application to the scenario (how it appears in the case)
- Justification (why this approach is appropriate)
- Recommendation (what action should be taken next)
If you do not apply the concept, you may get partial marks. If you apply but cannot justify, you may lose marks due to lack of reasoning.
2) Risk and Quality: Write as Management, Not as Lists
A common low-score pattern is:
- “Risks: supplier delay, scope creep, cost overrun. Mitigation: plan, communication.”
Instead, write risk actions as management commitments:
- identify the risk,
- assign ownership,
- state response strategy,
- define monitoring triggers,
- link to schedule or quality outcomes.
Example of a higher-scoring risk paragraph:
- “The integration risk is owned by the vendor technical lead with the project manager as sponsor for governance reporting. We mitigate by enforcing an API contract, creating regression test suites, and requiring an integration readiness gate before starting system-wide testing.”
That is specific, assignable, and actionable.
3) EVM/Calculations: Show the Numbers and Interpret the Signs
If your exam includes EVM or similar metrics, you must:
- present PV/EV/AC clearly,
- compute variances and indices correctly,
- interpret results in plain language,
- recommend control actions.
A calculation-only answer often loses marks because interpretation is the “management” part.
4) Stakeholders: Show Engagement Tactics, Not Only Categories
Stakeholder classification is necessary but not sufficient. Add engagement tactics such as:
- workshop sessions for low-power/high-interest groups,
- steering committee reporting for high-power groups,
- targeted communications to reduce misinformation,
- approvals timelines aligned to stage gates.
A strong answer ties engagement tactics to governance and decision points.
5) Change Control: Explain Authority and Evidence
Exams love change-control scenarios. A high-scoring answer includes:
- how changes are logged,
- impact assessment process,
- who approves,
- how baselines are updated,
- what communication follows.
Also mention evidence requirements: without evidence, acceptance and claims become disputes.
6) Mini “Answer Template” You Can Reuse
Use the following structure:
- Identify the issue (governance/scope/schedule/cost/quality/risk)
- Diagnose root cause (what failed in the system)
- Apply the correct concept (risk response, quality gate, baseline update, contract variation)
- Recommend specific actions (with ownership and timeline logic)
- Explain expected outcomes (what improves and how you measure it)
This template keeps your writing coherent and marker-friendly.
Course-Centred Study Strategy (USB PGDip PM Context): How to Prepare for PGDip PM Assessments in a South African University Setting
This section is written to help you convert knowledge into exam readiness. It emphasises a disciplined approach that fits the style of South African postgraduate assessments.
1) Build a “Module Map” from Learning Outcomes
Create a personal map:
- learning outcomes you expect (governance, scope, time, cost, risk, quality, procurement),
- the models and artefacts that match each outcome,
- the calculation types you must be able to perform.
Because assessment requirements can vary by institution, you should ensure your understanding covers:
- scenario application,
- structured writing,
- basic project control calculations,
- risk response planning,
- quality assurance reasoning.
2) Practise with Scenario Questions (Not Only Flashcards)
Flashcards help with definitions. Postgraduate exams require:
- converting definitions into decisions,
- handling constraints (time, budget, resources),
- responding to change and uncertainty.
Use practice prompts like:
- “A stakeholder requests scope expansion after baseline approval—what should happen next?”
- “Supplier delay causes missed milestone—how do you update the schedule and manage risk?”
- “Quality defects increase—how do corrective and preventive actions differ?”
- “EVM metrics show negative CV and SV—what does that mean and what do you do?”
3) Use Consistent Language Across Answers
Markers can spot when students shift between concepts. Maintain consistent terminology:
- “baseline” for agreed reference points,
- “validation vs verification” for deliverables,
- “contingency vs management reserve” for uncertainty budgets,
- “CPI < 1 means inefficient cost performance,” etc.
Consistency demonstrates mastery at postgraduate level.
4) Focus on “Evidence and Governance”
A repeated theme across USB-style project management programme expectations is governance-based evidence. Every recommendation should imply:
- what evidence will be reviewed,
- what approval is required,
- what reporting cadence will be used,
- what success metric proves it worked.
This is why business case logic and stage gating also matter: they create evidence trails that protect value and accountability.
Conclusion: Your PGDip PM Success Toolkit
A PGDip in Project Management demands more than memorising processes. Success comes from using project management concepts as a governance-enabled decision system: connect the project to a measurable business case, define scope with traceability, control time and cost through baselines (and calculations when needed), manage risks with ownership and monitoring triggers, ensure quality through verification and validation, and use procurement/contract logic to allocate risks fairly.
If you can write answers that move from definition to scenario application and then into justified recommendations—while using clear governance language—you will be well prepared for typical USB Project Management Programme style assessments and for aligned postgraduate modules that may appear under university-coded streams (including project management modules commonly referenced in study notes such as MNG 0001 within PG-level planning and control coursework).
