Project Management Principles, Practices and Scheduling (PPM Module 1) — UP Programme Notes (UPPM 1A / PPM Module 1)

Project management fundamentals sit at the core of every successful delivery: defining the right work, planning it realistically, coordinating stakeholders, and scheduling activities to meet constraints. This study guide focuses on Project Management Principles, Practices and Scheduling as typically covered in University of Pretoria (UP) project management modules within the UP Programme in Project Management (PPM) Notes context—aligning with the style and depth expected in first-module examinations such as those reflected in UPM and adjacent South African project management modules (including material commonly assessed in modules like PRJ 311 / PMN-style scheduling components and similar Unisa/CUT-aligned competency outcomes).

You will learn how to apply key project management principles (governance, scope, cost, time, risk, quality, procurement, communications, stakeholder management) and how to translate them into practical scheduling (WBS, precedence, estimating, critical path, buffers, and baseline control). The guide also builds exam-ready reasoning: not only what to do, but why those steps matter and what to do when reality deviates from the plan.

Principles and Practices of Project Management in Scheduling (UP PPM Module 1 Context)

Scheduling is not just a timeline; it is the structured output of project principles translated into time-based decisions. In exam settings, many candidates list tools (like CPM or Gantt charts) without linking them to principles (like scope control, risk response, and baseline governance). This section makes those links explicit and exam-relevant.

What “Project” Means for Scheduling Decisions

A project is typically defined by three features that directly affect scheduling:

1. Uniqueness: Because deliverables differ, schedule assumptions must be validated by estimates and contingency—not copied blindly from past work.
2. Temporary nature with a defined end: The schedule is designed to meet a completion objective within constraints (time, cost, quality, risk tolerance).
3. Defined outputs/deliverables: Work must be decomposed into deliverable-related activities (not vague “do work” tasks).

In scheduling, uniqueness influences:

• Estimation (historical data may not apply directly)
• Risk (unknowns are more likely)
• Dependencies (interfaces between unique deliverables create waiting time)
• Acceptance criteria (quality gates must be scheduled)

A typical scheduling mistake in exams: creating a plan with tasks that are “activity-based” rather than deliverable/requirement-based. When acceptance criteria are not tied to schedule tasks, progress can look good while the project fails at the end (often called “schedule for output vs. schedule for outcomes”).

Core Project Management Knowledge Areas and How They Drive the Schedule

The schedule is the time expression of multiple management areas. Consider how each affects time planning:

• Scope Management: If scope is unclear, tasks become unstable. Scope creep usually appears first as “schedule creep” (late start/late finish) because activities expand or new activities must be added.
• Cost Management: Time and money interact. Overtime or additional resources may shorten durations but increases costs.
• Quality Management: Quality assurance and control activities need explicit scheduling; otherwise rework extends the critical path.
• Risk Management: Uncertainty must be reflected in buffers, contingencies, or schedule risk analysis.
• Resource Management: Limited skilled resources create constraints; scheduling must account for availability and skill match.
• Procurement Management: Material lead times and vendor delivery windows are schedule-critical. Procurement tasks include tendering, ordering, delivery, and inspection.
• Stakeholder Engagement: Stakeholders influence review/approval timelines. If approvals are delayed, even perfect execution becomes late.

Exam angle: When asked “How does scheduling support project management principles?” you should answer with these links—showing you understand scheduling is not separate from governance.

Governance, Baselines, and Why Schedules Must Be Controlled

A schedule becomes credible when it is governed through baselines and change control.

Key concepts:

• Project baseline: Approved plan for scope, time, and cost.
• Schedule baseline: Approved target dates and activity durations used to measure performance.
• Change control: Any schedule change must be evaluated (impact on cost, scope, risk, and overall feasibility).
• Performance measurement: Earned value approaches (where used) compare planned vs actual progress. Even without full earned value, performance metrics rely on baseline logic.

Why this matters:

• A plan that can be edited without control becomes a narrative, not a control tool.
• Baseline discipline supports credible reporting (“we are 10 days behind as per baseline change-controlled logic”).

Example scenario (common exam style):
A construction project in Tshwane plans “foundation concrete” to start on 15 June. During the month, procurement delays occur; someone updates the date informally without recording the change. When the client asks why the schedule slipped, the project cannot prove whether the delay came from:

• bad estimating,
• failure to manage procurement,
• or unauthorized scope expansion.
  Therefore, baseline governance is essential for both accountability and learning.

Scheduling as a Structured Process: From Requirements to Dates

A good schedule is built in layers:

1. Requirements and deliverables define the scope.
2. Work Breakdown Structure (WBS) breaks scope into manageable components.
3. Activity definition identifies the work needed to produce outputs.
4. Sequencing determines which activities must precede others.
5. Estimating predicts activity durations (and sometimes costs).
6. Resource planning assigns people/equipment and checks feasibility.
7. Schedule development integrates logic and constraints into a time model.
8. Baseline approval locks in the plan.
9. Monitoring and control tracks progress, manages variance, and handles changes.

Exam candidates often focus only on steps 4–7 (CPM, Gantt, etc.). High marks usually come from showing the end-to-end chain and knowing where poor input causes downstream schedule failure.

Constraints, Assumptions, and Interfaces: The Hidden Scheduling Drivers

Schedules fail most often due to unmanaged constraints and unclear assumptions.

Constraints are schedule-limiting factors such as:

• Legal or regulatory inspection dates
• Building access windows (e.g., security restrictions)
• Funding release dates
• Vendor delivery windows
• Workforce availability due to seasonal constraints

Assumptions are “we believe this will be true” statements, such as:

• “Material will arrive within 5 business days”
• “The client will provide drawings by 1 July”
• “All approvals take 48 hours under current SLA”

A strong exam response includes how to handle them:

• Make constraints explicit in the schedule documentation.
• Track assumptions as risk indicators (if the assumption fails, schedule impacts).
• During control, validate assumptions early rather than waiting for late-stage failure.

Interface logic is also crucial. Interfaces are where one deliverable depends on another, e.g.:

• Electrical installation depends on completed structural works.
• Software testing depends on stable code delivery.
• Training delivery depends on finalized user manuals.

Interface delays often show up as “mysterious slippage” unless precedence relationships and review/approval gates are modelled.

Work Breakdown Structure, Sequencing, and Estimating for Exam-Grade Schedules

To schedule confidently, you must create accurate activity structures and realistic duration estimates. This section provides the exam-grade building blocks: WBS-to-activities mapping, sequencing logic, and estimation methods—including uncertainty handling.

Building an Effective WBS (from Deliverables to Work Packages)

A WBS (Work Breakdown Structure) decomposes the project into smaller components down to work packages.

A WBS should meet these exam expectations:

• Deliverable-oriented: Each WBS element should correspond to a deliverable component.
• Hierarchical: Clear parent-child structure.
• Comprehensive: Covers 100% of the work within scope (no missing major deliverables).
• Level of detail appropriate to control needs: Too high-level reduces control; too detailed increases admin burden.

A typical WBS level breakdown in a practical project might look like:

• 1.0 Project Management
  • 1.1 Project initiation
  • 1.2 Reporting and controls
• 2.0 Engineering / Design
  • 2.1 Requirements gathering
  • 2.2 Concept design
  • 2.3 Detailed design
• 3.0 Procurement
  • 3.1 Vendor selection
  • 3.2 Ordering and delivery
• 4.0 Implementation
  • 4.1 Installation / construction
  • 4.2 Integration
• 5.0 Testing and Commissioning
  • 5.1 Testing
  • 5.2 Commissioning
• 6.0 Handover and Training
  • 6.1 Documentation
  • 6.2 Training sessions

Exam hint: If asked “What level should the schedule be detailed to?” answer: detailed enough to monitor progress meaningfully (e.g., work packages or activities that produce measurable outputs). Use time- and reporting practicality.

Mapping WBS to Activities: The Step Candidates Miss

A common mistake: writing a WBS but skipping the conversion to activities. Activities are the time-based units to schedule.

Good mapping rules:

• Activities should be directly traceable to WBS work packages.
• Activities should be assignable (someone accountable).
• Activities should have measurable completion criteria (what counts as done?).
• Activities should allow realistic estimation (duration based on scope and method).

Example mapping (small dataset):
WBS Work Package: 2.3 Detailed design
Possible activities:

1. 2.3.1 Draft detailed design (2 weeks)
2. 2.3.2 Review detailed design with stakeholders (3 days)
3. 2.3.3 Revise and finalize detailed design (4 days)

Each activity is linked to deliverable outputs (draft, reviewed package, finalized design).

Sequencing Activities: Logic, Precedence, and Leads/Lags

Sequencing defines the order activities must occur. Exam questions often test your ability to identify correct dependencies.

Common dependency types:

• Finish-to-Start (FS): Activity B starts after A finishes (most common).
• Start-to-Start (SS): B starts after A starts.
• Finish-to-Finish (FF): B finishes after A finishes.
• Start-to-Finish (SF): rare in practice, typically avoided in classic scheduling.

Also use:

• Leads (negative lag): allow successor to start earlier than finish.
• Lags (positive delay): force waiting time between activities.

Exam-style precedence reasoning example:

• Construction of walls (Activity C) requires completed foundation curing (Activity B finish). This is typically FS.
• Electrical conduit installation (Activity E) can start once some walls are completed—this could be a partial release scenario, sometimes modelled using lags or multiple segments. In simpler exam contexts, you might model E as FS to “wall completion” milestone.

Avoiding logic loops: A professional schedule avoids cycles (A depends on B, B depends on A). In exams, if they ask about precedence errors, mention that cycles create an unschedulable model.

Estimating Activity Durations: Deterministic vs Probabilistic Thinking

Estimating can be:

• Analogous (based on similar past projects)
• Parametric (using formulas, e.g., m²/day productivity)
• Bottom-up (estimate each component then aggregate)
• Three-point estimating (probabilistic): optimistic (a), most likely (m), pessimistic (b)

For exam-grade analysis, understand the three-point method and expected duration.

The expected duration using a common PERT approximation:

• te = (a + 4m + b) / 6

This gives a weighted average with most-likely value dominating.

Example:

• a = 4 days (optimistic)
• m = 7 days (most likely)
• b = 10 days (pessimistic)
  te = (4 + 4*7 + 10) / 6 = (4 + 28 + 10) / 6 = 42/6 = 7 days.

Exam connection to risk: If uncertainty is high, expected duration alone is not enough. You need variability:

• Variance = ((b – a) / 6)²
• Standard deviation = (b – a) / 6

Using above: (10-4)/6 = 6/6 = 1 day std dev. This allows risk-aware buffer planning.

Resource Constraints and Estimating Realism

A deterministic CPM schedule assumes resources can support activity durations. In reality, resources are constrained. You must check:

• Can the required team be available for the whole duration?
• Do specialists exist in limited quantity?
• Are equipment idle times likely?
• Are multiple activities competing for the same resource?

In exam language, mention:

• Leveling (delay non-critical activities to match resource limits)
• Allocation rules (preemptive vs non-preemptive)
• Trade-offs: shorten duration via overtime or add resources (cost increases)

A credible schedule often documents the difference between:

• a theoretical schedule (unconstrained resources)
• and a resource-feasible schedule (constraints applied)

Documentation and Assumptions for Estimating

Examiners reward candidates who explain that estimates must be supported by:

• Work method (how work will be executed)
• Assumptions (availability, approvals)
• Constraints (access windows, inspection dates)
• Productivity basis (crew size, output rates)
• Basis for schedule risk (what could change)

Example (basis for productivity):
If estimating installation duration using a productivity of 20 square meters per day, the estimate must clarify:

• daily work hours (8 hours/day?)
• expected productivity variations (weather, access, stoppages)
• quality rework risk

Without this, the schedule looks like guesswork.

Critical Path Scheduling, Gantt Charts, Milestones, and Schedule Control

Now that activities, logic, and durations are set, you build the schedule model, find the critical path, and control progress against the baseline. This section equips you for typical exam calculations and interpretation questions.

Creating a Network Diagram and Identifying the Critical Path

A network diagram visualizes activities and dependencies. In traditional approaches, you compute:

• Forward pass (earliest start/finish): assumes activities occur as early as possible.
• Backward pass (latest start/finish): computes the latest times activities can occur without delaying project completion.

Key results:

• ES (Earliest Start)
• EF (Earliest Finish)
• LS (Latest Start)
• LF (Latest Finish)
• Float/Slack: LS − ES or LF − EF

An activity is critical if:

• float = 0 (LS = ES)
• any delay directly delays the project completion.

Example mini-network (calculation-ready):
Suppose we have activities:

• A (2 days) → B (3 days) → D (4 days)
• A also → C (5 days) → D

Assume A starts at day 0.

• A: ES 0 EF 2
• B: ES 2 EF 5
• C: ES 2 EF 7
• D depends on both B and C completion, so:
  • D ES = max(EF_B, EF_C) = max(5, 7) = 7
  • D EF = 7 + 4 = 11

Project duration = 11 days.

Now compute float for B and C:

• For backward pass, project finish is at 11, and D lasts 4:
  • D LF = 11, LS = 7 (since 4 days)
• B precedes D, so B must finish by D LS = 7:
  • B LF = 7, LS = 4 (because B duration 3)
• For C:
  • C also must finish by 7:
  • C duration 5 → LS = 2, EF already 7 which matches.
    Thus:
• B float = LS − ES = 4 − 2 = 2 days
• C float = 2 − 2 = 0 days (critical)
  Therefore C and D are critical path activities: A → C → D.

Exam interpretation: Delaying B by 2 days may still keep project finish at day 11; delaying C by 1 day delays the finish to day 12 (unless schedule re-optimization occurs).

Gantt Charts: How to Use Them Without Overtrusting Them

A Gantt chart shows activities over time visually. In exams, the expected value is not just “draw a Gantt chart,” but:

• show how it corresponds to network logic
• identify critical activities (often via shading or a critical path indicator)
• include milestones (milestone markers)
• include baseline comparison (optional but powerful)

Gantt charts can mislead if:

• dependencies are not represented accurately
• durations are adjusted without updating logic
• critical path is not recalculated after changes

Exam advice: If a question asks about shortcomings, mention that Gantt charts alone do not ensure logic correctness unless linked to a network and critical path computations.

Milestones: Planning for Gate Reviews and Acceptance

A milestone is a significant event. In project management scheduling, milestones represent:

• deliverable approvals
• inspection pass/fail events
• readiness gates for downstream work

Examples of milestone types:

• Design complete
• Tender awarded
• Materials received
• First system test complete
• Commissioning sign-off
• Training completed
• Project closure acceptance

Why milestones matter:

• They create decision points for stakeholder engagement.
• They reduce the risk of “silent failure” where work completes but is not accepted.
• They help manage procurement and review cycles.

In exam responses, emphasize milestones as the backbone of governance and communications.

Schedule Baseline and Variance: Monitoring and Control Mechanisms

Schedule control requires measurement, forecasting, and corrective action.

Core elements:

• Planned value at each time period (based on baseline)
• Actual progress (time and completion measures)
• Variance analysis (schedule variance)
• Forecasting (estimate when completion will occur)

Typical variance types:

• Slippage: tasks taking longer than planned
• Acceleration: tasks finishing earlier than planned (rare; can reduce uncertainty)
• Front-loading or back-loading: completion distribution changes

Exam-quality explanation:
If a project is behind schedule, the response is not “work harder.” Corrective action options include:

1. Fast tracking (overlap phases where possible)
2. Crashing (add resources to shorten duration, with cost increase)
3. Re-planning logic (resequence activities if constraints allow)
4. Redefining scope if feasible
5. Negotiating schedule changes through governance

However, these must align with project constraints and scope boundaries. In many exams, “crashing” is incorrectly applied without discussing cost or quality impacts.

Float Management and Buffering

Float (slack) protects schedule against uncertainty. But float is not infinite protection; it can be consumed by delays and rework.

Exam expectations:

• Critical path activities have zero total float
• Non-critical activities can delay but must not exceed their float
• Free float and total float distinctions can appear in advanced problems

Even when not calculating every float subtype, explain:

• Total float protects project completion date.
• Free float protects successor early start.

Buffer concept:
In high-risk environments, schedules may include buffer:

• project buffer at critical path
• feeding buffers for near-critical activities
• contingency pools for known risk categories

When asked, “How do you schedule for risk?” you can discuss buffering and contingency:

• explicit contingency activities
• probabilistic schedule analysis (PERT-based)
• resource contingency planning

Updating the Schedule: Rolling Wave Planning and Re-baselining

Schedules must be updated as information changes.

• Rolling wave planning: plan near-term in detail; plan farther-term at higher level.
• Regular schedule reviews: update durations, remaining work, and logic.
• Re-baselining: only under controlled change, usually after major scope changes or external shocks.

Exams may ask why re-baselining is controversial:

• Frequent re-baselining can hide poor performance.
• But sometimes it’s necessary to reset after legitimate changes.

A high-mark answer states:

• re-baselining is justified when changes affect the fundamentals (scope, major constraints, contractual changes)
• re-baselines must be documented and approved

Scheduling Tools, Resource Allocation, and Risk Integration (Practical Exam Scenarios for UP PPM)

This section brings everything together: scheduling tools, resource feasibility, and risk integration into a coherent approach. It includes scenario-style reasoning that matches typical South African exam tasks—especially those that combine “explain” with “calculate” or “compare options.”

Types of Scheduling Models: Deterministic vs Constraint-Based

In exam settings, scheduling approaches are sometimes categorized as:

1. Deterministic CPM schedules
   • fixed durations
   • dependency logic
   • critical path computed based on expected durations
2. Resource-constrained scheduling
   • accounts for limited manpower/equipment
   • may shift non-critical tasks
3. Risk-informed scheduling
   • uses probabilistic durations or scenario-based analysis
   • adds buffers based on likelihood of delay

A mature project schedule may include more than one:

• Start with CPM to establish the logic backbone
• Apply resource constraints to ensure feasibility
• Add risk contingency to protect completion

Resource Loading and Leveling: When the Schedule Looks “Right” but Fails

Resource loading means assigning labor/equipment to activities. Resource leveling adjusts the schedule to remove overloads.

In exam responses:

• Leveling delays activities with available float to reduce resource peaks.
• It may change the critical path (some previously non-critical activities become critical after leveling).

Example logic:
An activity with float 5 days might appear safe, but if it uses a scarce technician who is overloaded elsewhere, resource leveling can push it into a window that eliminates float. Thus, critical path can shift.

Key exam-ready points:

• After any leveling or constraint adjustment, recompute the critical path.
• Document trade-offs: delays vs costs (e.g., reduced overtime, increased duration).

Hiring, Procurement, and Third-Party Dependencies

Procurement and third-party dependencies are classic reasons for schedule slippage. Scheduling must include:

• procurement lead times (tendering, evaluation, award)
• supplier production time
• delivery and receiving inspection
• customs or regulatory if relevant (more common in import-heavy projects)

Even in a generic exam, you should demonstrate:

• how procurement tasks connect to implementation tasks via precedence
• how vendor delays become schedule risk

Scenario example (exam-like):
A software integration project in Pretoria requires a vendor to deliver a hardware module by a specific date. The integration task cannot start until delivery and verification completes.

Modeling in scheduling:

• Add an activity: “Vendor delivers hardware” with duration equal to lead time.
• Add “Hardware inspection and acceptance” before “Integration begins.”
• Connect dependencies with FS logic.

Then link risk:

• if vendor delivery has high variance, add contingency or alternative supplier logic.
• consider procurement acceleration (pay premium or expedite) as a “crashing” option.

Schedule Risk Management: From Identification to Response

Risk management is not only for writing a risk register; it must affect the schedule.

Schedule risk integration approaches:

• Explicit contingency tasks: “Rework allowance” or “Second review cycle”
• Probabilistic durations: PERT and scenario analysis
• Buffering: time buffers near the critical path
• Contingent plans: if vendor delivery is late, switch to alternative supplier or adjust scope sequence

Exam questions often ask for:

• “How do you respond to risk?”
  Common answer structure:

1. Avoid (change plan to remove risk cause)
2. Mitigate (reduce probability/impact)
3. Transfer (contractual shifting; e.g., warranties/penalties)
4. Accept (budget contingency; monitor)
5. Escalate (early warning triggers to stakeholders)

In scheduling:

• Avoid/migrate might change sequencing (fast tracking).
• Transfer affects procurement logic and acceptance criteria.
• Accept requires time buffers and monitoring thresholds.

Trade-offs: Fast Tracking vs Crashing (and Their Impact on Risk and Cost)

Fast tracking: overlap activities that are normally sequential. Example:

• start detailed design review while still finalizing upstream requirements.
  Risks:
• rework if upstream changes occur
• coordination complexity

Crashing: add resources to shorten duration. Example:

• add additional reviewers, more labor shifts, parallel testing teams.
  Impacts:
• cost increase
• potential quality risks if overload reduces effectiveness
• coordination overhead may offset time gains

In an exam, an excellent answer compares:

• which option reduces duration more efficiently,
• how it affects critical path and float,
• and what governance approvals are required due to cost or scope impacts.

Interpreting Earned Schedule Concepts (When Progress Is Measured by Work Completed)

Some exam questions use schedule performance concepts like:

• planned vs actual progress
• earned progress
• schedule performance index (in earned value contexts)

Even if the course emphasizes scheduling fundamentals rather than full earned value, examiners may expect basic earned-progress reasoning:

• Completing a task halfway does not equal finishing it; the schedule model must align with measurable completion criteria.
• If progress measurement is based on activity time elapsed (“we worked for 10 days”), schedule control becomes distorted.

Practical progress measurement examples:

• In construction: completion measured by inspection-ready milestones.
• In design: completion measured by reviewed deliverable submission.
• In software: completion measured by test pass and code freeze, not “coding started.”

Practical Scheduling Example: A Mini Case You Can Reuse in Exams

Consider a simplified project with the following WBS elements and activities:

1.0 Project Management
1.1 Weekly reporting (2 weeks)
1.2 Steering committee approvals (runs weekly; gate at week 3)

2.0 Design
2.1 Draft design (1 week)
2.2 Stakeholder review (3 days)
2.3 Final design (4 days)

3.0 Build
3.1 Build component A (5 days)
3.2 Build component B (5 days)
3.3 Integrate (3 days)

4.0 Test and Handover
4.1 Testing (4 days)
4.2 Handover documentation (2 days)
4.3 Final acceptance (1 day)

Assume:

• Week 1 starts on Day 0.
  Convert durations to days:
• 1 week = 5 days (standard working days)
• 2 weeks = 10 days

Duration mapping:

• 1.1: 10 days
• 2.1: 5 days
• 2.2: 3 days
• 2.3: 4 days
• 3.1: 5 days
• 3.2: 5 days
• 3.3: 3 days
• 4.1: 4 days
• 4.2: 2 days
• 4.3: 1 day

Dependencies (typical FS):

• 2.2 starts after 2.1 finishes (2.2 FS 2.1)
• 2.3 starts after 2.2 finishes
• 3.1 and 3.2 depend on final design (2.3 finish)
• 3.3 depends on both 3.1 and 3.2 completion
• 4.1 depends on integration completion
• 4.2 depends on testing completion readiness
• 4.3 depends on documentation completion

Now compute:

• 2.1: Day 0–5
• 2.2: Day 5–8
• 2.3: Day 8–12
• 3.1: Day 12–17
• 3.2: Day 12–17
• 3.3: Day 17–20
• 4.1: Day 20–24
• 4.2: Day 24–26
• 4.3: Day 26–27

Project duration = 27 days.

Critical path activities are those with no slack; in this network, the path is essentially:

• 2.1 → 2.2 → 2.3 → (3.1 & 3.2 merge) → 3.3 → 4.1 → 4.2 → 4.3

Now introduce a realistic risk:

• Stakeholder review (2.2) may take 5 days instead of 3 due to late feedback.
  If 2.2 becomes 5 days:
• 2.2: Day 5–10
• 2.3: Day 10–14
• 3.1 and 3.2: Day 14–19
• 3.3: Day 19–22
• 4.1: Day 22–26
• 4.2: Day 26–28
• 4.3: Day 28–29
  Finish becomes 29 days, 2 days late.

Exam take-away:

• Stakeholder review gates are often on the critical path.
• That means stakeholder management and scheduling are inseparable: the schedule must schedule stakeholder review and decision-making realistically (and include buffers if necessary).

Exam-Ready Checklist: Writing Answers, Avoiding Common Errors, and Applying Scheduling Logic

This section focuses on how to present your understanding in a way that scores well in written and calculation-based exams. It includes structured answer templates and common pitfalls, plus a final integrated approach that reflects what PPM Module 1 typically assesses.

How to Structure “Explain” Answers for High Marks

A strong exam explanation typically follows a repeatable logic structure:

1. Define the concept (one or two sentences).
2. Describe the process (step-by-step).
3. Link to scheduling impact (why it matters for time performance).
4. Give an example (small scenario).
5. Mention risks/controls (governance, baseline, change control).

Example prompt: “Explain how risk management influences schedule development.”
A high-quality answer should mention:

• uncertainty affects duration estimates,
• risk response can create contingency activities or buffers,
• schedule control needs risk monitoring triggers,
• and failing to integrate risk causes schedule surprises.

Common Errors That Reduce Marks

Below are typical errors found in student scripts:

• Treating scheduling as separate from scope: building activities without traceability to WBS deliverables.
• Confusing activities with milestones: milestones are events; activities consume time and produce outputs.
• Ignoring review/approval gates: schedules often forget stakeholder approval cycles.
• Not recalculating the critical path after changes: once durations or constraints change, logic must be re-evaluated.
• Updating dates informally: without baseline governance, reporting becomes unreliable.
• Measuring progress incorrectly: time-based progress without deliverable completion.
• Ignoring resource constraints: planning durations assume unlimited availability.
• Overusing float: assuming non-critical tasks can always be delayed; float is conditional and can disappear after leveling.

Answering Calculation Questions: What Examiners Look For

For network and critical path problems, examiners typically reward:

• correct ES/EF and LS/LF calculations
• correct identification of critical path activities
• correct float calculation and interpretation
• correct reasoning when logic leads to a merge (max of predecessors)

Presentation tips:

• Use a table for ES/EF/LS/LF (even if the exam does not demand it).
• Show the forward and backward pass.
• Clearly state which path is critical and why.

Buffer, Contingency, and “Schedule Risk” in Written Form

When asked “How do you include contingency in scheduling?” students often answer vaguely. A better approach is to connect contingency to schedule risk sources:

• Duration uncertainty: add buffer or probabilistic analysis
• Rework risk: schedule quality reviews and rework cycles
• Vendor uncertainty: use procurement buffers and alternative procurement options
• Approval delays: schedule stakeholder reviews and specify SLAs

You do not need to use complex PERT tables in every exam—but you should know the difference between:

• expected duration vs variability
• contingency as management reserve vs schedule buffer as time protection

Integrated Framework: A One-Page Mental Model for PPM Module 1

In exams, the best answers show integrated thinking. Use this mental model:

1. Scope & deliverables → define what must be built.
2. WBS → organize deliverables into manageable components.
3. Activities → convert work packages into schedulable tasks with measurable completion.
4. Logic (dependencies) → establish precedence using FS/SS/FF logic and lags/leads where needed.
5. Estimates → durations using analogous/parametric/bottom-up/three-point methods with assumptions.
6. Resources → assign and check feasibility; apply resource leveling.
7. Schedule model → compute earliest/latest times; identify critical path.
8. Baseline & governance → approve, monitor, measure variance, control changes.
9. Risk integration → buffer, contingency, and response planning tied to schedule gates.
10. Monitoring & forecast → update based on actual deliverable completion; re-optimize only with controlled logic.

If you can articulate this sequence coherently, you demonstrate mastery consistent with PPM Module 1 scheduling expectations.

A Short Case-Study Style Answer Template You Can Adapt

When a case question provides a scenario with delays, missing approvals, and procurement constraints, adapt this template:

1. Identify schedule drivers
   • which deliverables are delayed
   • which activities caused the delay
   • whether delays are on or off the critical path
2. Analyse root cause
   • estimate accuracy
   • resource constraint
   • procurement lead time
   • stakeholder review/approval cycle
   • risk not included or poorly mitigated
3. Quantify schedule impact
   • compute days late using updated durations and logic
4. Propose corrective actions
   • fast track / crash / resequence / scope negotiation
   • include cost/quality/risk impacts
5. Update schedule baseline and control plan
   • document changes
   • update reporting metrics
   • define monitoring triggers

This approach typically matches the marking rubric in South African university examinations for project management scheduling modules.

Final Exam Checklist for “Schedule That Scores”

Use the checklist below as a final review before submitting an answer:

• WBS-to-activities mapping shown (activities produce deliverables)
• Dependencies are logical and consistent (no loops)
• Durations are estimated with stated assumptions or method
• Critical path identified with clear reasoning
• Float interpreted correctly (and not overstated)
• Milestones include stakeholder approvals/acceptance gates
• Resource feasibility considered (or explicitly stated as unconstrained)
• Risk integration included (buffers/contingency or probabilistic approach)
• Baseline control and change governance referenced when scenario requires it
• Monitoring approach described (how progress is measured and schedule updated)

This guide’s emphasis—linking principles to practices and translating both into schedule logic and control—reflects what PPM Module 1 assessments typically test: whether you can produce and manage a schedule that is credible, traceable, risk-aware, and governable under real-world constraints.