Diploma in Operations Management – Project Management Notes (Vaal University of Technology, VUT)

Project management is the backbone of operational excellence: it connects strategy to execution, transforms resources into deliverables, and ensures work is completed within scope, time, and cost constraints. In an Operations Management context, projects also improve process reliability, reduce waste, and build capacity in a measurable way. These notes are tailored for Vaal University of Technology (VUT) students and align with the kinds of content expected in Project Management Engineering modules—including how project planning, scheduling, risk, and controls translate into operational outcomes.

1. Foundations of Project Management for Operations Management (VUT-aligned)

1.1 What “project management” means in operations contexts

A project is a temporary endeavor with a defined beginning and end, producing a specific deliverable. In Operations Management, projects typically aim to improve or redesign processes, implement new systems, expand production capacity, reduce downtime, or comply with standards.

Common operations-linked project examples:

• Implementing a new inventory control system (e.g., moving from manual stock cards to an ERP module).
• Upgrading a production line to reduce defect rate and increase throughput.
• Introducing lean improvements in a warehousing environment to reduce picking time.
• Building a small facility expansion to manage seasonal demand spikes.
• Meeting quality or safety compliance requirements through new equipment or procedures.

Unlike routine operations, projects are unique. This uniqueness drives the need for structured project management: clarifying goals, defining scope, identifying dependencies, managing change, and tracking performance.

Key triangle: Scope–Time–Cost

Most project performance problems can be traced back to imbalance in the project management triangle:

• Scope: what must be delivered
• Time: when it must be delivered
• Cost: how much resources are allocated

For operations management, scope creep can increase waste (extra work, extra approvals, extra material handling). Time overruns can cause production delays. Cost overruns can reduce maintenance budgets and harm operational stability later.

1.2 Project life cycle: from initiation to closure

A typical project life cycle includes:

1. Initiation
2. Planning
3. Execution/Implementation
4. Monitoring & Controlling
5. Closing

Although project management bodies may describe different “phases,” exam questions often ask you to:

• explain what happens in each phase,
• identify outputs/documents,
• describe roles and approvals.

Initiation phase outputs

• Project charter (high-level definition, objectives, authority)
• Business case (why the project is needed)
• High-level scope statement
• High-level risks and feasibility considerations

Planning phase outputs (core exam focus)

• Work Breakdown Structure (WBS)
• Schedule (activity list, sequencing, estimates)
• Resource plan
• Cost estimate and budget
• Risk register
• Quality plan
• Communication plan
• Procurement plan (if needed)

Execution phase outputs

• work performance data (actuals)
• completed deliverables
• change requests and updates
• procurement progress

Monitoring & controlling

• compare planned vs actual schedule and cost
• handle issues and risks
• manage change requests
• ensure quality and compliance

Closing

• acceptance of deliverables
• project closure report
• lessons learned
• final financial reconciliation
• transition to operations (hand over)

1.3 Roles and responsibilities (who does what)

In operations projects, exam questions frequently test understanding of responsibilities across:

• Project Sponsor: funds and authorizes the project; ensures strategic alignment.
• Project Manager (PM): owns planning, coordination, and performance reporting.
• Functional Managers (operations, maintenance, procurement, quality): provide resources and expertise.
• Team Members: execute tasks; report progress.
• Customers/Stakeholders: define requirements and accept deliverables.
• Project Steering Committee: governance; approves major changes.

A useful way to answer questions:

• If asked “who approves the budget?”, your answer should emphasize sponsor/steering committee rather than the PM alone.
• If asked “who produces the WBS?”, emphasize PM with team input, because WBS depends on detailed know-how.

1.4 Triple constraint and the operational consequences

Examiners often want not just the definition, but the implications.

Scope

If scope expands:

• extra activities appear in WBS
• more materials and labor are required
• quality standards may change
• the schedule may slip

In operations, additional scope can also create process instability later. For instance, implementing “quick fixes” during a production line upgrade might meet immediate output goals but reduce long-term maintainability.

Time

If time slips:

• procurement lead times can expire
• subcontractors may charge time extension costs
• training might start late, affecting productivity ramp-up

Cost

If costs rise:

• project budget may consume funds needed for operational maintenance
• cost-cutting could reduce test/inspection coverage, creating hidden defects

1.5 A mini case: warehouse process improvement project

Consider a warehouse with rising order lead times due to slow picking. A project is proposed to improve operations by redesigning the layout and implementing barcode scanning.

Project objective (example):

• Reduce average order picking time from 18 minutes to 12 minutes within 10 weeks of project start.

Deliverables (example):

• New warehouse layout (approved plan)
• Barcode scanning process and labels
• Updated SOPs and training
• Go-live support for two weeks

This case is useful because it connects project management tools directly to operations results: schedule drives when scanning can be operational, budget drives equipment procurement and training costs, and scope drives what exactly is delivered (layout only? process only? both?).

2. Planning, WBS, Scheduling, and Budgeting for Operations Projects (VUT-style exam readiness)

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

A Work Breakdown Structure decomposes the total project scope into manageable components. The WBS is not merely a diagram; it is the foundation for accurate:

• scheduling,
• cost estimation,
• resource planning,
• responsibility assignment,
• risk identification.

Why WBS matters for Operations Management

Operational projects fail when teams cannot convert project goals into measurable tasks. WBS converts “upgrade the line” into:

• equipment acquisition,
• installation,
• calibration,
• testing,
• training,
• documentation,
• commissioning,
• handover.

Each component can then be planned and controlled.

2.2 WBS construction steps (practical, step-by-step)

A robust WBS is built through a controlled method:

1. Define the major deliverables (outputs)
2. Break deliverables into work packages
3. Ensure work packages are “manageable”
4. Assign identifiers/codes
5. Validate with stakeholders (scope correctness)
6. Link WBS to scheduling and costing

Levels and “work packages”

• Level 1 might represent major deliverables (e.g., “Installation”).
• Level 2 might represent sub-deliverables (e.g., “Conveyor installation”).
• Level 3 might represent work packages (e.g., “Install conveyor frame”).

A common exam point: work packages should be:

• clear enough to estimate,
• schedulable,
• measurable for progress tracking.

2.3 Example WBS: production line upgrade

Suppose a manufacturing plant needs to reduce downtime by replacing a failing packaging station. A simplified WBS might look like:

WBS Level	Code	Component	Work package examples
Level 1	1.0	Project Management	planning, reporting, approvals
Level 1	2.0	Procurement	vendor selection, ordering, shipping
Level 1	3.0	Installation	site preparation, equipment mounting
Level 1	4.0	Commissioning & Testing	calibration, trial runs, acceptance testing
Level 1	5.0	Training & Handover	operator training, SOP updates, final sign-off

Each Level 1 element is further decomposed into tasks with measurable outputs. The exact formatting will vary by course, but the logic must remain.

2.4 Activity definition and sequencing

After building WBS, you define activities (tasks) required to complete work packages.

Activity definition principles

• Activity is action-oriented (e.g., “Install conveyor motor”)
• Activity has a clear start and end event
• Activity uses specific inputs (equipment, labor, approvals)

Sequencing and dependencies

Activities often have dependencies:

• Finish-to-start (FS): Task B starts only after A finishes
• Start-to-start (SS): B starts when A starts (rarely used but sometimes valid)
• Finish-to-finish (FF): B ends when A ends
• Start-to-finish (SF): uncommon in most practical scheduling

Exam questions may ask you to describe effects of dependency types on schedule risk.

2.5 Estimating time: deterministic vs probabilistic thinking

Many curricula cover basic duration estimation and sometimes introduce probability. In exam terms:

• Deterministic estimates: assign one duration per activity (best for stable environments).
• Three-point estimates: optimistic (O), most likely (M), pessimistic (P), often used in risk-based scheduling.

Three-point estimate formula (common)

A frequently taught method is PERT:

• Expected time ( t_e = \frac{O + 4M + P}{6} )

If you introduce this, ensure the arithmetic is consistent within any example you compute.

2.6 Critical Path Method (CPM): how schedule risk concentrates

The Critical Path is the longest sequence of dependent activities determining project duration. Activities on the critical path have zero (or minimal) slack.

What is “slack”?

Slack (float) is the time an activity can slip without affecting overall project completion.

• Zero slack → critical activity
• Positive slack → non-critical activity (can be delayed temporarily)

Exam-style interpretation questions

If asked: “What happens if a non-critical activity slips by 3 days?”
Answer:

• If its slack is > 3 days, project finish may not change.
• If slack is < 3 days, it becomes critical and may shift the critical path.

2.7 Gantt charts vs network diagrams

Common tools:

• Gantt chart: calendar-based timeline with bars; good for visibility.
• Network diagram: shows logical dependencies; required for critical path analysis.

A high-quality exam answer:

• explain the purpose and strengths of each tool,
• mention which one is used for dependency logic (network),
• mention which one is used for communication with stakeholders (Gantt).

2.8 Budgeting and cost estimation

Operations projects require cost estimates that can withstand procurement and approval scrutiny. Budgeting often includes:

• Direct labor (hours × rate)
• Materials/equipment
• Subcontractors
• Travel and logistics
• Training and documentation
• Contingency (for uncertainty)
• Overheads (sometimes allocated)

Direct labor example

If installing equipment requires 160 labor-hours and the blended rate is R250 per hour, direct labor cost is:

• 160 × 250 = R40,000

If a budget is mentioned elsewhere, ensure it matches. Therefore, in exam practice, it’s safer to use clear, self-contained numbers and keep consistent.

2.9 Budget allocation across the project life cycle

In operations engineering modules, budgets are often shown as:

• Planning costs (PM effort, feasibility, drawings)
• Implementation costs (procurement, installation)
• Commissioning costs (testing, calibration)
• Training & handover costs
• Contingency

Relationship between schedule and cost

Schedule changes affect costs:

• overtime increases labor cost,
• early procurement may increase vendor premiums,
• delays may trigger escalation clauses.

In exam scenarios, you may need to recommend cost-time tradeoffs.

2.10 Integrated planning example: a “10-week” operational improvement project

To make the scheduling and budgeting tangible, consider the warehouse project earlier:

Project start date: Week 1
Target duration: 10 weeks

A simplified activity set might include:

1. Layout finalization and approvals (Weeks 1–2)
2. Procurement of shelving and labels (Weeks 2–5)
3. Installation of layout changes (Weeks 4–7)
4. Implement barcode scanning SOPs (Weeks 3–6)
5. Training operators (Weeks 7–8)
6. Pilot and adjustment (Weeks 8–10)

A Gantt chart would show overlapping bars to reduce total duration, while a network diagram would show dependencies, such as:

• installation cannot start before shelving arrives (FS dependency),
• training may depend on SOP completion and pilot readiness.

Budgeting for this project would allocate costs to procurement, installation labour, scanning equipment, and training. In practice, you would also include contingency for delays in delivery and additional operator coaching.

3. Cost Control, Risk Management, Quality Management, and Change Control (Operationally grounded)

3.1 Monitoring and controlling: why it’s different from planning

Planning sets the baseline. Monitoring & controlling answers:

• Are we meeting the baseline?
• If not, how big is the variance, and why?
• What corrective action is needed?

In operations-focused projects, control is crucial because operational interruptions have immediate production and service impacts.

3.2 Earned Value Management (EVM): schedule and cost performance metrics

Many exam syllabi include EVM because it integrates scope, schedule, and cost.

Core EVM terms:

• Planned Value (PV): budgeted cost of work planned by a specific time
• Earned Value (EV): budgeted cost of work actually completed by that time
• Actual Cost (AC): actual cost incurred for the work performed

From these, performance indices are derived:

• Schedule Variance (SV) = EV − PV
• Cost Variance (CV) = EV − AC
• Cost Performance Index (CPI) = EV / AC
• Schedule Performance Index (SPI) = EV / PV

Interpreting EVM results

• EV < PV → behind schedule (SV negative)
• EV < AC → over budget (CV negative)
• CPI < 1 → costs are inefficient
• SPI < 1 → schedule is inefficient

Example (self-contained) to illustrate logic

Suppose by end of Week 4:

• PV = R120,000
• EV = R100,000
• AC = R130,000

Then:

• SV = EV − PV = 100,000 − 120,000 = −R20,000 (behind schedule)
• CV = EV − AC = 100,000 − 130,000 = −R30,000 (over budget)
• CPI = EV / AC = 100,000 / 130,000 ≈ 0.77
• SPI = EV / PV = 100,000 / 120,000 ≈ 0.83

An exam-grade answer would explicitly interpret each result and propose follow-up actions (e.g., investigate cause of delays, adjust procurement workflow, review resource allocation).

3.3 Risk management lifecycle: from identification to response

Risk management reduces uncertainty that threatens time, cost, quality, and stakeholder acceptance.

Risk management steps

1. Identify risks
2. Assess and prioritize (likelihood and impact)
3. Plan responses
4. Implement responses
5. Monitor and review throughout the project

3.4 Common risk categories in operations projects

Typical categories:

• Technical risks: design errors, equipment compatibility issues
• Schedule risks: vendor delays, permitting delays
• Cost risks: price escalation, labor shortages
• Operational risks: production stoppage, unsafe work conditions
• Quality risks: failing acceptance tests, insufficient training
• Regulatory risks: compliance delays
• People/organizational risks: resistance to change, skill gaps

3.5 Risk response strategies

For each risk you propose a response. Common response types:

• Avoid: change plan to eliminate risk source
• Mitigate: reduce probability or impact
• Transfer: shift impact to another party (insurance, fixed-price contracts)
• Accept: acknowledge risk, plan contingency if it occurs
• Exploit: for positive risks (opportunities), enhance probability or impact

Example: vendor delivery delay

• Risk: shelving delivery delayed by 2 weeks
• Likelihood: medium
• Impact: high
• Mitigation: place order earlier, choose backup vendor, expedite logistics
• Contingency: schedule installation work after delivery; pre-stage site readiness

3.6 Risk register and scoring (how exams expect you to structure it)

A risk register often includes:

• Risk description
• Category
• Cause
• Event/impact
• Likelihood rating
• Impact rating
• Risk score
• Response strategy
• Owner
• Status

A common scoring method uses a matrix:

• Likelihood (1–5)
• Impact (1–5)
• Score = Likelihood × Impact

If you introduce scores in examples, keep them consistent and ensure the interpretation matches the score.

3.7 Quality management: planning quality into operations projects

Quality management ensures deliverables meet requirements. For operations projects, quality failure can manifest as:

• defects in installed equipment,
• unreliable process outputs,
• safety incidents,
• noncompliance with standards.

Quality planning elements

• Quality standards/specifications
• Quality assurance approach (how to verify compliance)
• Quality control activities (testing, inspection, acceptance checks)
• Documentation requirements (SOPs, calibration records)

3.8 Inspection, testing, and acceptance criteria

An exam-ready approach:

• distinguish inspection (checking conformance) from testing (evaluating performance)
• specify acceptance criteria

Example acceptance criteria for a barcode scanning rollout:

• scanning success rate ≥ 98% in a 1-week pilot
• average scan time ≤ 3 seconds
• correct label application rate ≥ 99%
• operators pass training assessment (e.g., ≥ 80% test score)

If you use these thresholds, they must remain consistent wherever referenced.

3.9 Change control: managing scope, schedule, and cost impacts

In projects, change is inevitable. The key is structured handling.

Change control process (typical)

1. Change request submitted
2. Impact assessment (scope, time, cost, quality)
3. Review/approval by appropriate authority
4. Update project baselines if approved
5. Communicate changes
6. Track implementation

In operations projects, change control is critical because changes often affect:

• process design,
• training materials,
• user acceptance,
• safety compliance,
• procurement specifications.

Change request example: adding extra shelves

• Request: add an extra shelving bay
• Impact: increases materials cost by R25,000
• Schedule: shifts installation start by 1 week due to foundation work
• Quality: additional inspection steps needed

An exam answer should recommend whether to accept or reject, and propose alternatives (e.g., phased installation after go-live).

3.10 Integrated controls: linking EVM, risk, quality, and changes

A high-scoring exam response explains that project management tools are interconnected:

• If EVM indicates schedule slippage, risk monitoring may reveal vendor delivery delays.
• If quality tests fail during commissioning, schedule and cost variances may increase due to rework.
• Change requests can reset baselines, which affects future EVM interpretation and forecast.

4. Project Execution, Procurement, Communication, and Stakeholder Management (Operations engineering delivery)

4.1 Execution discipline: making the plan real

Execution is where the project produces the deliverables through:

• staffing and resource allocation,
• work authorization,
• procurement,
• managing contractors,
• implementing work packages,
• documenting progress,
• resolving issues.

A key exam idea: execution must align with the project management plan and quality plan.

4.2 Resource management: staffing and capacity constraints

Operations projects often compete for limited resources:

• maintenance technicians
• procurement officers
• specialized engineers
• workshop time
• downtime windows

A strong planning section includes:

• resource histogram (if taught) to show peak demand,
• justification for overtime or additional shifts,
• sequencing to prevent bottlenecks.

4.3 Procurement management: buying what you need, when you need it

Procurement is essential in operations projects because specialized equipment and materials drive implementation.

Procurement planning outputs

• procurement scope
• contract strategy (fixed price, cost-plus, etc.)
• vendor evaluation criteria
• delivery schedules and milestones
• quality and warranty requirements

Procurement process (typical sequence)

1. request for quotation/proposal
2. vendor selection
3. contract negotiation and award
4. follow-up on delivery and compliance
5. receiving and inspection
6. installation support and warranties
7. closure of procurement

Example procurement decision

If a plant needs a packaging station and two vendors exist:

• Vendor A offers faster delivery but higher price.
• Vendor B offers lower price but longer lead time.

An operations-oriented recommendation may consider:

• production downtime cost during delay,
• risk of installation compatibility issues,
• warranty terms and spares availability.

4.4 Stakeholder management: mapping influence and expectations

Stakeholders include anyone affected by or able to affect the project:

• internal leadership (operations director, finance)
• workers (operators, maintenance crew)
• external parties (vendors, regulators)
• customers (in service operations)

Stakeholder analysis methods

Common exam expectations:

• identify stakeholders
• determine power/interest or influence/impact
• tailor communication and engagement strategy

4.5 Communication management: reducing project “noise”

Communication in projects is not just sending messages; it is ensuring timely, correct information reaches decision-makers and implementers.

Communication plan components

• audience (sponsor, team, stakeholders)
• frequency (weekly, monthly)
• format (meeting, report, dashboard)
• information type (progress, cost, risks, change requests)
• owner (PM, project coordinator, procurement lead)

Example communication rhythm for a 10-week operational project

• Weekly steering meeting (sponsor + PM + key managers)
  • status vs baseline
  • top risks and mitigation progress
  • approvals needed
• Weekly team stand-up
  • progress on work packages
  • obstacles and resource needs
• Mid-project checkpoint (Week 5)
  • schedule forecast update
  • procurement delivery confirmation
• Go-live readiness meeting (Week 8)
  • training completion, SOP sign-off, pilot results

4.6 Issue management: handling blockers quickly

An issue is a current problem affecting execution. Distinguish issue vs risk:

• Risk = potential future event
• Issue = already happening now

Issue management process:

1. identify and log issue
2. analyze impact (time/cost/quality)
3. assign owner
4. decide corrective action
5. track until resolved

A well-run project demonstrates that issues are not ignored; they are controlled similarly to changes (with documentation and accountability).

4.7 Team management and operational safety

Operations projects involve physical work or operational process changes; safety management is therefore central.

In exam answers, include:

• safety induction for contractors
• permit-to-work procedures
• lockout/tagout where applicable
• risk assessments before intrusive work
• protective equipment requirements

You should connect safety to quality and schedule:

• safety delays can change schedule,
• safety failures can stop the project and create huge cost impacts.

4.8 A delivery case: commissioning after installation

Returning to the warehouse example: after shelving installation and barcode scanning process development, the project enters pilot.

Commissioning/pilot tasks often include:

• verifying that labels are applied correctly,
• checking scanning accuracy,
• validating that the system updates inventory counts correctly,
• training and monitoring operators during real picking tasks,
• adjusting layouts, signage, and SOP steps.

A high-scoring answer explains:

• how pilot results feed back into change requests,
• how pilot performance is measured against acceptance criteria,
• how the project transitions from pilot to go-live.

5. Exam Practice: Integrating Tools with Scenario Questions (VUT Project Management Engineering Modules)

5.1 How to approach typical exam questions in project management

VUT-style project management papers often test your ability to apply concepts, not only define them. A reliable approach:

1. Read the scenario carefully and identify:
   • project type
   • objective and deliverables
   • constraints (time, cost)
   • stakeholders affected
2. Select the relevant tool:
   • WBS for scope decomposition
   • CPM/Gantt for scheduling
   • EVM for cost/schedule performance
   • risk register for uncertainty
   • quality plan for acceptance
   • change control for deviations
3. Show your logic:
   • state assumptions explicitly if allowed
   • perform required calculations
   • interpret results
4. Propose corrective actions:
   • mitigation, re-planning, replanning baselines
   • communication and approval steps

5.2 Integrated scenario: “Production downtime reduction” project

Consider a medium-size manufacturing plant running a packaging station that fails repeatedly. Management authorizes a project to reduce downtime.

Project objective:

• Reduce average downtime from 6 hours/week to 3 hours/week within 12 weeks.

Deliverables:

• new packaging station installed
• calibration completed
• operator training completed
• acceptance testing passed
• updated maintenance SOPs and spares list

WBS sketch

A simplified WBS might include:

• 1. Project management
• 2. Procurement (station, sensors, spares)
• 3. Installation (site preparation, mounting, electrical connection)
• 4. Commissioning & testing (dry run, production trial)
• 5. Training & handover (operators, maintenance team)

Scheduling logic (CPM style)

Dependencies:

• procurement must finish before installation starts (FS)
• commissioning cannot start before installation completes (FS)
• training depends on successful acceptance testing (FS)

From this logic, installation and commissioning likely sit on the critical path because delays in equipment lead directly to missed trial and training windows.

5.3 Risk analysis scenario: three major risks and responses

Assume the following risks are identified:

1. Vendor delay for station delivery

   • likelihood: medium
   • impact: high
   • mitigation: backup vendor quotation; expedite shipment where possible; plan site readiness tasks in parallel

2. Compatibility issue (sensor interface mismatch)

   • likelihood: low to medium
   • impact: high
   • mitigation: require interface specification confirmation before order finalization; test sample components early

3. Training delay due to operator shift availability

   • likelihood: medium
   • impact: medium
   • mitigation: schedule training sessions across shifts; provide recorded material; confirm attendance plan early

An exam answer should connect each risk to:

• specific response actions,
• responsible owner (vendor manager, technical lead, HR/training coordinator),
• monitoring triggers (delivery milestone slip > 3 days, failed interface test, training attendance < target).

5.4 Quality plan scenario: acceptance criteria and control activities

To pass acceptance testing, the project must meet operational performance criteria.

Example acceptance criteria:

• packaging defect rate ≤ 2% during the production trial
• average downtime during trial ≤ 1.5 hours/week
• maintenance SOPs approved and version-controlled
• operators achieve ≥ 80% score in training assessment

Quality control activities:

• inspection of installed components
• functional test of sensors
• trial-run data capture
• calibration certificates review
• audit of SOP documents and training records

A strong exam answer states:

• how evidence is captured (test logs, calibration certificates, sign-off forms),
• who approves acceptance (sponsor + operations manager).

5.5 Change control scenario: scope expansion and re-baselining

Suppose during installation, a change request is raised:

• Add an additional sensor to improve fault detection.

Change request analysis:

• scope increase: additional installation + wiring work packages
• time impact: +2 days installation and +1 day testing
• cost impact: sensor price + labor + calibration

Response:

1. confirm whether sensor is required for meeting acceptance criteria or is an enhancement
2. assess whether schedule slippage affects training and acceptance
3. if approved, update schedule and budget baselines
4. communicate changes to stakeholders and update risk register

An exam answer should demonstrate the difference between:

• rejecting a “nice-to-have” change if it endangers critical acceptance milestones, and
• accepting changes that reduce operational risk and improve quality performance.

5.6 EVM calculation practice: interpreting performance and forecasting

Create a consistent mini dataset for an 12-week project. Assume by Week 6:

• PV (planned to be spent) = R240,000
• EV (earned for completed work) = R210,000
• AC (actual spent) = R260,000

Compute:

• SV = EV − PV = 210,000 − 240,000 = −R30,000 (behind schedule)
• CV = EV − AC = 210,000 − 260,000 = −R50,000 (over budget)
• CPI = EV / AC = 210,000 / 260,000 ≈ 0.81
• SPI = EV / PV = 210,000 / 240,000 = 0.875

Interpretation:

• costs are inefficient (CPI < 1),
• progress is slower than planned (SPI < 1).

Forecasting (conceptual in many exam syllabi):

• If CPI remains 0.81, further cost increases are likely.
• If SPI remains 0.875, schedule slippage risk grows.
• corrective actions include: resource reallocation to critical path, vendor follow-ups, rework reduction, and more frequent risk reviews.

5.7 Linking EVM results to risk and quality

In real project problems, EVM variances typically have root causes. For example:

• Over budget (CV negative) might be due to rework after quality failures.
• Behind schedule (SV negative) might be due to procurement delays or equipment installation issues.

A top exam answer ties these together:

• “Because CV is negative and EV is lower than PV, it suggests incomplete scope delivered by Week 6, likely due to rework and/or delays. Investigate quality test failures and confirm whether sensor calibration or interface issues are causing the rework.”

5.8 Full “short answer” sample responses (exam technique)

Below are sample structures you can imitate.

Question type: Define WBS and explain why it is important

Sample structure:

• Definition: WBS decomposes project scope into smaller components.
• Purpose: enables detailed planning for time and cost, improves estimating accuracy, clarifies responsibilities.
• Link to operations: reduces ambiguity in operational deliverables and supports measurable progress.

Question type: Explain Critical Path and slack

Sample structure:

• Critical path = longest dependency chain determining duration.
• Slack/float = how long an activity can slip without affecting project finish.
• Critical activities have zero slack; non-critical have some slack and can be delayed within limits.

Question type: Interpret CPI and SPI

Sample structure:

• CPI = EV/AC; <1 indicates cost overrun.
• SPI = EV/PV; <1 indicates schedule behind.
• Use interpretation to recommend actions: review resource utilization, address bottlenecks, update schedule forecasts.

5.9 Building a “complete” mini project plan answer (what examiners love)

Some exam questions ask you to outline a plan. A full answer typically includes:

1. Project charter summary
   • objective, deliverables, sponsor, constraints
2. WBS
   • major deliverables decomposed into work packages
3. Schedule
   • activity sequencing and dependency logic
   • Gantt or network and critical path explanation
4. Budget
   • cost categories and contingency logic
5. Risk management
   • top risks and responses
   • risk register format summary
6. Quality management
   • acceptance criteria and testing/inspection plan
7. Change control
   • how changes are requested, assessed, approved, and recorded
8. Communication
   • reporting rhythm and stakeholder engagement plan
9. Monitoring and control
   • EVM or variance analysis approach
   • issue and corrective action tracking
10. Closure

• handover to operations, lessons learned, final documentation

Writing these as headings and bullet points usually matches marking schemes because it shows comprehensive coverage and structure.

5.10 Common pitfalls (and how to avoid them in exams)

Pitfall 1: treating definitions as full answers

• Fix: always add “why it matters” and “how it’s used.”

Pitfall 2: calculating schedule without considering dependencies

• Fix: explicitly state FS dependencies or constraints from the scenario.

Pitfall 3: confusing risk with issue

• Fix: risk = potential future event; issue = happening now.

Pitfall 4: ignoring quality/acceptance criteria

• Fix: include at least one measurable acceptance indicator and describe evidence required.

Pitfall 5: not linking EVM interpretation to corrective actions

• Fix: after computing CPI/SPI, propose actions tied to root causes.

University Study Relevance: VUT Project Management Engineering Modules Focus (South Africa exam alignment)

6.1 Why these notes match the kind of content assessed at VUT

VUT’s Project Management Engineering Modules commonly emphasize:

• integrated project planning tools (WBS, scheduling, budgeting),
• operational delivery constraints (production continuity, resource availability),
• governance and control (monitoring, risk, quality, change),
• applied problem-solving using scenarios rather than memorization alone.

These notes therefore prioritize:

• structured steps and decision points,
• operationally meaningful examples,
• consistent logic connecting planning to performance monitoring.

6.2 How to prepare for exam questions practically

A practical revision workflow:

1. Build a “toolbox” summary sheet:
   • WBS basics
   • CPM/critical path definition
   • risk register headings
   • quality acceptance criteria format
   • change control steps
   • EVM definitions and interpretations
2. Practice scenario responses:
   • take one scenario and write an integrated plan in 1 page
   • calculate EVM for one dataset
   • draw/describe critical path reasoning
3. Drill “interpretation”:
   • don’t stop at calculations; interpret and recommend.

6.3 Final consolidation: one-page checklist (for exams)

Use this checklist during revision and in the exam to avoid omissions:

• Scope defined (deliverables + boundaries)
• WBS created (work packages measurable)
• Schedule built (dependencies + critical path logic)
• Budget estimated (labor/materials + contingency)
• Risks identified (risk register + owners + responses)
• Quality planned (acceptance criteria + inspection/test evidence)
• Changes controlled (request → impact → approval → baseline update)
• Communication scheduled (stakeholders + frequency)
• Control used (variance/EVM interpretation + corrective actions)
• Closure completed (handover + lessons learned)

End of Document