PGM4813 Project Scope, Time & Cost Management Exam Notes (UNISA)

PGM4813 focuses on how project managers define and control scope, plan and manage schedule (time), and estimate, budget, and control costs. The exam typically tests both conceptual understanding (e.g., what each technique is and why it matters) and practical application (e.g., how to respond when scope/time/cost variance occurs). These study notes consolidate the core ideas, frameworks, and calculation logic you need for exam readiness in the UNISA (College of Economic and Management Sciences) project management pathway.

Section 1: Project Scope Management (PGM4813 Core Concepts, Tools, and Exam-Style Practice)

Project scope management is the discipline of ensuring the project includes all the work required—and only that work—to complete the project successfully. In exams, this commonly appears as questions about requirements, deliverables, scope baseline, WBS, and scope change control.

1.1 What “Scope” Really Means (and What It Does Not Mean)

In scope management, “scope” usually splits into two exam-relevant ideas:

1. Product scope: the features and functions that characterize the deliverable (e.g., a software system with reporting dashboards).
2. Project scope: the work required to produce the product deliverables (e.g., development, testing, training).

A common exam trap is confusing product features with project activities. A good way to remember:

• Product scope = what you are building
• Project scope = how you get it built

If an exam question states: “The client requests additional fields in the database,” that request is typically a change to product scope, which then triggers project scope analysis because it affects time and cost.

1.2 Requirements vs Deliverables: The Scope-Requirements Chain

Most scope management exam questions follow a logic chain:

• Stakeholder needs → requirements → deliverables → scope statement → WBS → scope baseline

A “requirements” mindset is essential. Requirements are often classified as:

• Functional requirements (what the system/product must do)
• Non-functional requirements (performance, security, usability, reliability)
• Constraints (time, budget, regulatory limits)
• Assumptions (what must be true for planning to hold)

In a project environment, failing to capture requirements accurately leads to scope creep and schedule delays. In exam terms, you should link requirements errors to downstream impacts on cost and time control.

Example scenario (typical exam style)

A manufacturing project includes a new assembly line with “on-time delivery reporting.” During execution, the plant manager asks for:

• weekly email reports instead of monthly reports
• an additional dashboard view for “defect rate”

These are requirements additions. They will require updates to:

• the scope statement
• the WBS
• the schedule (more build/test time)
• the cost estimate and budget
• possibly the quality plan if new reporting accuracy standards apply

1.3 Scope Management Processes and Their Exam Meaning

UNISA-style project management content usually aligns with standard project management frameworks. For exam writing, you should be able to describe the purpose of each scope management process:

1. Plan Scope Management
   • Decide how scope will be defined, developed, documented, and verified.
2. Collect Requirements
   • Gather formal inputs from stakeholders (interviews, workshops, surveys).
3. Define Scope
   • Develop the detailed project scope statement.
4. Create WBS (Work Breakdown Structure)
   • Break deliverables into manageable work packages.
5. Validate Scope
   • Formal acceptance of deliverables by stakeholders (often via inspections/testing/approvals).
6. Control Scope
   • Manage changes to scope baseline, prevent uncontrolled scope creep.

A high-scoring exam response usually uses both:

• the process name
• the purpose and outputs

For instance, “Create WBS” is not just “make a WBS”—it’s “decompose deliverables into work packages that support accurate estimation and scheduling.”

1.4 Scope Statement: What It Must Contain (Answer Structure)

When asked “What should a project scope statement include?” you should present a structured response. A scope statement typically includes:

• Project objectives and description
• Project boundaries (in scope / out of scope)
• Deliverables and acceptance criteria
• Assumptions and constraints
• High-level requirements
• High-level project requirements
• Risks that affect scope (sometimes summarized)
• Approval/verification approach (how deliverables will be accepted)

Out-of-scope listing (exam-winning detail)

Many scope disputes happen because out-of-scope items were never explicitly defined. For example:

• In a hospital IT upgrade project, “training for administrative staff” might be in scope, while “redevelopment of legacy data” might be out of scope.

If a question includes a vague statement like “we’ll include all data cleaning,” your answer should ask: “What data sources? How much cleansing? Who defines success?” This demonstrates scope control thinking.

1.5 Work Breakdown Structure (WBS): Decomposition Logic and Correctness

A WBS is the backbone of scope/time/cost integration.

Key properties of a strong WBS

• Deliverable-oriented decomposition (not activity-only)
• Mutually exclusive work packages (avoid double counting)
• Collectively exhaustive (covers all scope)
• Defined work package description
• Clear responsibility and estimable detail level

WBS levels (common exam expectation)

A WBS is typically presented as:

• Level 1: major deliverables (e.g., Project Management, System Development)
• Level 2: components (e.g., Requirements, UI, API)
• Level 3: work packages (e.g., build login module)
• Level 4+: if needed for estimation accuracy

Example: Partial WBS for a “Student Portal” project

• 1.0 Project Initiation
  • 1.1 Project charter & stakeholder mapping
  • 1.2 High-level requirements workshop
• 2.0 System Development
  • 2.1 Requirements specification
  • 2.2 Database schema design
  • 2.3 UI development (login, dashboard)
  • 2.4 API integration & testing
• 3.0 Deployment & Training
  • 3.1 Deployment scripts
  • 3.2 User training sessions
  • 3.3 Post-launch support

A question might ask: “How does WBS help cost estimation?” Your response should link:

• WBS work packages enable bottom-up estimation
• schedule durations for each work package can be calculated
• resource allocation and cost budgeting become more controllable

1.6 Scope Baseline and Change Control: Preventing Scope Creep

The scope baseline is usually made up of:

• approved scope statement
• WBS
• WBS dictionary (sometimes referenced as support detail)

Once the baseline is approved, any change becomes controlled through change requests and evaluation.

Change request flow (write it like a process answer)

1. A stakeholder requests change (documented as a change request)
2. Review by project team (impact analysis)
3. Evaluate alternatives (if needed)
4. Decision by change control board / authority
5. Update documents:
   • scope baseline
   • schedule baseline
   • cost baseline
   • requirements and WBS (if approved)

Exam counter-question: “Why not accept every request?”

Because uncontrolled changes cause:

• delays (work added to schedule)
• increased costs (extra labor/tools)
• quality risks (incomplete testing)
• stakeholder dissatisfaction (replanning overhead)

1.7 Scope Verification (Validate Scope) vs Deliverable Acceptance

A common mistake is mixing validate scope with control quality. They are related but distinct:

• Validate Scope: stakeholders formally accept deliverables
• Control Quality: ensure deliverables meet quality standards

A simple exam-ready line:

• Validation is about acceptance, not merely conformance.
• Quality control is about performance against standards.

Example

A contractor delivers HVAC installation drawings. Quality checks might verify compliance with electrical standards. Validation might be the engineering manager’s formal sign-off that the drawings satisfy contractual acceptance criteria.

1.8 Exam-Style Scope Questions and How to Answer

Typical question types

• “Explain the importance of WBS in scope management.”
• “Differentiate between product scope and project scope.”
• “Describe how scope changes should be controlled.”
• “Provide key components of a project scope statement.”

Recommended exam response strategy

Use the “define → explain → link to time/cost” structure:

1. Define the term/process
2. Explain why it matters
3. Link it to time and cost outcomes

If you only define, you lose marks because the exam expects you to show integrated thinking.

Section 2: Project Time Management (Scheduling Logic, Critical Path, and Schedule Control)

Time management is about planning how project work will be completed and ensuring the project finishes on time. Exams often test your understanding of schedule development techniques and how schedule variance indicators translate into corrective actions.

2.1 Schedule Basics: What You Must Control and Why

A schedule is not just dates—it is an integrated plan that includes:

• activities/work packages
• logical dependencies
• estimated durations
• resource availability assumptions (sometimes indirectly)
• constraints and milestones

The exam may ask: “Why does schedule control matter?” Answer by linking:

• schedule performance affects cost (delays often increase indirect costs and require rework)
• schedule delays change stakeholder expectations
• schedule visibility reduces risk of late discovery

2.2 Activity Definition and Sequence: From WBS to Timeline

In time management, activities are derived from work packages. Your steps usually resemble:

1. Use WBS work packages to define activities.
2. Determine sequence (dependencies):
   • Finish-to-Start (FS): activity B starts after A finishes
   • Start-to-Start (SS): activity B starts after A starts
   • Finish-to-Finish (FF): activity B finishes when A finishes
   • Start-to-Finish (SF) is rare; exams may still mention it as a concept.

Exam emphasis: dependency types

If an exam question includes “testing can only start after development is complete,” that is clearly FS dependency.

2.3 Estimating Activity Durations: Avoiding Unrealistic Planning

Duration estimates depend on:

• available resources
• complexity
• expected productivity rates
• constraints (e.g., “equipment available only 2 days per week”)
• learning curve and ramp-up time

A frequent exam trap: confusing effort with duration.

• Effort = person-days/man-hours (labor workload)
• Duration = calendar time (what stakeholders experience)

If you increase resources, effort may remain similar, but duration may reduce (subject to coordination overhead).

Example: Effort vs duration

Suppose “UI development” effort is 80 person-hours.

• With 1 developer at 8 hours/day → 10 working days (duration 10 days)
• With 2 developers at 16 hours/day → 5 working days (duration 5 days), assuming coordination overhead is not considered.

Exams may not always require math, but they expect you to show conceptual clarity.

2.4 Developing the Schedule: Network Diagrams and Critical Path Method (CPM)

CPM uses:

• a network diagram (activities connected by dependencies)
• earliest and latest start/finish times
• slack/float calculations

Core definitions (write these precisely)

• Early Start (ES): earliest time activity can start without violating dependencies
• Early Finish (EF): ES + duration
• Late Finish (LF): latest time activity can finish without delaying project completion
• Late Start (LS): LF − duration
• Float/Slack: LS − ES (or LF − EF)

Critical path

Activities with zero float form the critical path. Any delay in a critical path activity delays the project completion date (unless mitigated via crashing or fast tracking).

2.5 Manual CPM Calculation Practice (Exam-Ready Framework)

Many exams include small CPM networks. Even if the question is not numerically heavy, the method earns marks.

Step-by-step CPM method

1. Forward pass:
   • ES for start activities = 0 (or project start date)
   • EF = ES + duration
   • For merge nodes, ES = max(EF predecessors)
2. Backward pass:
   • LF for end activities = project finish time (or maximum EF)
   • LS = LF − duration
   • For split nodes, LF = min(LS successors)
3. Slack = LS − ES (or LF − EF)
4. Identify critical path (slack = 0)

Mini numerical example (consistent for later reasoning)

Consider these activities:

Activity	Duration (days)	Predecessor(s)
A	4	—
B	3	A
C	2	A
D	5	B, C
E	3	D

Forward pass:

• A: ES=0, EF=4
• B: ES=4, EF=7
• C: ES=4, EF=6
• D: ES=max(7,6)=7, EF=12
• E: ES=12, EF=15

Backward pass:

• E: LF=15, LS=12
• D: LF=12 (from E’s LS), LS=12−5=7
• B: successor D LS=7 → LF=7, LS=7−3=4
• C: successor D LS=7 → LF=7, LS=7−2=5
• A: successors B and C → LS=min(B LS=4, C LS=5)=4 → LF=LS+4=8? Wait: careful:
  • For backward pass, A’s LF is min(LS of successors) and LS = LF − duration.
  • Successor B LS=4 and C LS=5 → A LF = min(4,5)=4
  • A LS = 4−4=0
    So project duration = 15 days.
    Slack:
• A: LS 0 − ES 0 = 0 (critical)
• B: LS 4 − ES 4 = 0 (critical)
• C: LS 5 − ES 4 = 1 (non-critical)
• D: LS 7 − ES 7 = 0 (critical)
• E: LS 12 − ES 12 = 0 (critical)

Critical path = A → B → D → E (15 days).

This example is not only calculation practice; it teaches you what to say if the exam asks: “Which activities can delay the project if they slip?”

2.6 Schedule Compression Techniques: Crashing vs Fast Tracking

When the project is at risk of late completion:

Fast tracking

• Do phases in parallel that normally occur sequentially.
• Risk: rework if dependencies were not fully resolved.

Crashing

• Increase resource allocation to shorten durations for selected activities.
• Often increases cost due to overtime/extra labor.

A strong exam answer includes:

• the purpose
• impact on time and cost
• risks/conditions

Example using the earlier CPM network

If the project must reduce duration from 15 days to 13 days:

• You need to cut at least 2 days on the critical path.
• Only activities on the critical path have direct impact on completion date.

Critical path activities are A (4d), B (3d), D (5d), E (3d).
If you reduce non-critical C, it won’t shorten the overall duration (still determined by critical path). Exams like to test this principle.

2.7 Milestones and Time Horizons

Milestones are scheduled events that have no duration (or effectively zero duration) but mark completion of a key deliverable. In writing answers:

• Milestones help communication
• They support stakeholder reporting
• They can anchor schedule baselines

Examples:

• “Requirements approved” (milestone)
• “System tested and accepted” (milestone)
• “Go-live completed” (milestone)

2.8 Schedule Baseline and Variance Control

Schedule baseline is the planned schedule against which performance is measured. Control includes:

• tracking actual start/finish dates
• measuring progress (percent complete, earned value, or milestone-based tracking)
• assessing variance (slippage or acceleration)

Exams often ask conceptually:

• What is the difference between a delay and variance?
• What actions can be taken?

2.9 Corrective and Preventive Actions in Schedule Control

If performance deviates from plan:

Corrective actions (fix the problem) could include:

• resequencing tasks
• adding resources (if possible)
• revising estimates and re-baselining if formally approved
• changing scope within approved limits

Preventive actions (stop it happening again):

• better risk monitoring
• tighter dependency verification
• improved estimation techniques
• schedule risk buffers

A top mark response ties actions to root cause (e.g., supplier delay vs internal readiness).

2.10 Exam-Style Time Management Questions

Common questions:

• “Explain CPM and how slack identifies non-critical activities.”
• “Differentiate between fast tracking and crashing.”
• “Why doesn’t reducing non-critical activity always shorten project duration?”
• “Describe schedule baseline and what happens in schedule control.”

Answer framework:

1. Name the technique
2. Define key terms
3. Provide a small application or reasoning
4. Link to cost/scope if relevant (because time and cost are integrated)

Section 3: Project Cost Management (Estimating, Budgeting, and Cost Control Mechanics)

Cost management ensures the project is completed within the approved budget. Exams typically test estimation methods, budgeting logic, cost baseline control, and how to interpret performance indicators.

3.1 Cost Management Life Cycle: Estimate → Budget → Control

A coherent exam explanation should present the cost management “flow”:

1. Estimate Costs: determine costs of resources needed for each activity/work package.
2. Determine Budget: aggregate estimates to establish cost baseline.
3. Control Costs: monitor cost performance and manage changes.

This flow is tightly connected to WBS (scope) and schedule (time). Without WBS and schedule logic, costs can’t be properly traced and controlled.

3.2 Estimation Types: Top-Down vs Bottom-Up

Bottom-up estimating

• Use detailed WBS work packages
• Add costs of each work package
• More accurate if scope is stable

Top-down estimating

• Use overall estimates based on analogy/benchmarks
• Faster but less precise

Exams may include statements like “requirements were unclear and WBS not finalized.” In such cases, top-down approaches may be acceptable early, but then must evolve into bottom-up estimates later.

3.3 Analogous, Parametric, and Bottom-Up Estimation

You should be able to describe these three estimation approaches:

1. Analogous estimation

   • Uses historical data from similar projects
   • Useful for early planning
   • Less accurate if the project is unique

2. Parametric estimation

   • Uses a statistical relationship (cost per unit)
   • More reliable if parameters reflect reality

3. Bottom-up estimation

   • Detailed estimation per work package
   • Highest accuracy when scope and duration are well defined

Example (parametric)

If cost for server setup averages R5,000 per instance and you need 10 instances:

• estimated cost = 10 × R5,000 = R50,000

If the exam question uses different quantities later, keep consistent.

3.4 Cost Components: Direct vs Indirect and Fixed vs Variable

Exams often ask how costs are structured:

Direct costs

• labor directly assigned
• materials directly consumed
• equipment used for project activities

Indirect costs (overheads)

• administrative support
• shared facilities
• corporate overhead allocation

Fixed vs variable (useful for reasoning)

• Fixed: less dependent on activity volume (e.g., licensing subscription regardless of use)
• Variable: increases with usage (e.g., computing charges per workload)

A strong answer clarifies that “fixed” doesn’t mean “unchangeable cost,” because decisions like scope changes can cause new fixed commitments.

3.5 Reserve (Contingency and Management Reserves)

Cost risk management includes reserves:

• Contingency reserve: allocated for identified risks (used if risk occurs)
• Management reserve: for unknown-unknowns (requires special approval)

If an exam asks about reserve control:

• contingency can be used under established risk response rules
• management reserve typically requires formal escalation/approval

3.6 Budgeting: Creating the Cost Baseline

The cost baseline is the time-phased budget used to measure cost performance. It typically includes:

• sum of approved estimates
• escalation (if relevant)
• contingency allocation (often included in baseline depending on framework; exams vary—state assumptions)
• excludes management reserve (commonly handled separately)

Time-phasing means you distribute budget by period (weeks/months), enabling earned value style comparisons.

3.7 Cost Control: Measuring Performance and Managing Variance

The exam often moves into performance measurement. In many syllabi, Earned Value Management (EVM) is emphasized for integrated scope-time-cost assessment.

Basic EVM elements

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

From these, calculate:

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

Interpretation:

• CV < 0 → over budget
• SV < 0 → behind schedule
• CPI < 1 → inefficient cost performance
• SPI < 1 → inefficient schedule performance

Example (consistent numeric exercise)

Assume by the end of Month 2:

• PV = R300,000 (planned work budget)
• EV = R240,000 (earned work budget)
• AC = R270,000 (actual cost)

Compute:

• CV = EV − AC = 240,000 − 270,000 = −R30,000 (over budget)
• SV = EV − PV = 240,000 − 300,000 = −R60,000 (behind schedule)
• CPI = EV / AC = 240,000 / 270,000 = 0.89
• SPI = EV / PV = 240,000 / 300,000 = 0.80

A high-quality exam response links interpretation to likely causes:

• spending occurred faster than earned progress
• schedule dependencies may be broken or execution is slower than planned

3.8 Forecasting: Estimate at Completion (EAC)

If performance indicators are poor, you forecast future costs. Common EVM forecast logic includes:

• EAC = AC + (BAC − EV) / CPI
  where BAC is the Budget at Completion.

Example continuation (optional but typical)

Suppose BAC = R1,000,000. Using the previous CPI = 0.89:

• Remaining work budget = BAC − EV = 1,000,000 − 240,000 = 760,000
• Forecast remaining cost = 760,000 / 0.89 ≈ 853,933
• EAC = AC + remaining forecast = 270,000 + 853,933 ≈ R1,123,933

You should be ready to explain what the number means:

• if current cost inefficiency continues, final cost may exceed baseline.

3.9 Linking Cost Control with Scope and Schedule

Exams love integrated reasoning:

• If schedule slips, costs can rise due to labor extensions, rental fees, idle time, and increased overhead.
• If scope changes without budget updates, cost baseline becomes invalid unless re-baselined.

Corrective actions might include:

• renegotiate scope boundaries (reduce non-critical scope)
• re-plan schedule (sequence optimization)
• adjust resource allocation (but watch cost impacts)

3.10 Exam-Style Cost Questions

Typical prompts:

• “Differentiate between estimation and budgeting.”
• “Explain cost baseline and how it is used in cost control.”
• “Interpret CV, SV, CPI, SPI for given data.”
• “Why do reserves exist and who approves reserve use?”

Answer method:

1. Define term
2. Provide formula if asked
3. Interpret sign and ratio
4. Recommend response actions (at least briefly)

Section 4: Integrated Scope–Time–Cost Management (Change Impact Analysis, Trade-offs, and Practical Decision-Making)

Real projects rarely fail because of one factor alone. Scope affects schedule and cost; schedule affects resources and cost; cost constraints may force scope redefinition. Integrated management is where exams test higher-level thinking.

4.1 Why Integration is Central in PGM4813

Scope, time, and cost are linked via:

• WBS structure (scope)
• activity network and durations (time)
• resource assignments and estimates (cost)

If a scope change occurs, you must:

• update requirements/deliverables
• revise WBS and work packages
• update schedule dependencies and durations
• re-estimate costs and update budget baseline

In an exam, integration questions often ask:

• “Describe impacts”
• “Recommend corrective actions”
• “Explain which baselines must be updated”

4.2 Change Impact Analysis: A Structured Method

When evaluating a scope change, use a stepwise approach:

1. Describe the change precisely
   • what is added/removed/changed?
2. Identify affected work packages
   • locate affected WBS elements
3. Estimate schedule impact
   • affected activities and dependencies
   • how it affects critical path and float
4. Estimate cost impact
   • labor, materials, equipment, subcontractor changes
   • indirect costs and reserve consumption
5. Assess quality and risk impact
   • rework potential
   • regulatory/acceptance implications
6. Consider alternatives
   • do minimum version first?
   • phase the change for later release?
   • redesign approach?
7. Make decision
   • approve/reject/conditionally approve
8. Update baselines and documents (if approved)
   • scope baseline, schedule baseline, cost baseline

This structured approach is exactly the kind of reasoning examiners want.

4.3 Scope Change and Critical Path Logic

A common integrated question:

• “A new feature is requested. How do you determine whether the project completion date changes?”

Answer:

• Identify which activities on the critical path are affected.
• If the change affects only non-critical path activities, completion date may remain unchanged (but risks increase).
• If it affects critical path activities, completion date is directly impacted unless schedule compression is applied.

Use the CPM example from Section 2:

• Critical path = A → B → D → E
• Activity C has slack 1 day and is non-critical.
  Therefore, changes to work mapped to activity C may not immediately change overall completion date, but they might:
• consume reserves
• increase risk of future delays
• potentially shift criticality if durations change beyond slack

4.4 Trade-offs: Cost vs Schedule vs Scope

Trade-offs arise when you have constraints:

• fixed budget forces scope reduction or schedule changes
• fixed deadline forces schedule compression (cost increase)
• quality constraints restrict acceleration options

A typical exam narrative:

• “Client insists on earlier delivery.”
  Your response should mention:
• crashing costs
• fast tracking risks
• feasibility and authority to re-baseline

4.5 Numerical Trade-off Example (Decision Logic with Consistent Numbers)

Assume a project has BAC = R1,000,000. Based on earlier CPM, project duration is 15 days. Suppose at a mid-point check, EVM shows inefficiency: CPI = 0.89 and SPI = 0.80 (from Section 3). This means:

• cost is higher than earned progress (over budget)
• schedule progress is behind

If management proposes adding resources to recover schedule (crashing), it likely reduces durations on critical path but increases direct costs. An integrated decision should evaluate:

• will adding resources increase EV faster than AC?
• will CPI improve or worsen?

If the team can crash only on critical path activities, the schedule may improve (SPI rises). However, increased labor cost may reduce CPI further if cost grows more than earned value.

In a strong exam response, you don’t need exact new calculations unless the question provides productivity/cost slope data. But you should show logic:

• schedule recovery depends on which activities are critical
• cost impact depends on crash rates
• risk impact depends on rework probability

4.6 Baselines and Re-baselining: When and Why

A powerful exam point:

• You generally cannot change baselines casually.
• If changes are approved, baselines must be updated to reflect reality.

Re-baselining might happen when:

• major scope approval is granted
• significant external constraints change (regulatory changes, funding changes)
• initial baseline was unrealistic and formally corrected

In exam responses:

• mention formal approval requirement
• explain that without baselines, variance analysis becomes meaningless

4.7 Corrective Actions Across the Three Domains

Corrective actions may be mapped to scope/time/cost:

• Scope corrective actions

  • remove or postpone non-essential features
  • renegotiate acceptance criteria
  • clarify requirements to reduce rework

• Schedule corrective actions

  • resequence activities
  • fast track
  • crash critical path activities
  • add resource capacity (with coordination plan)

• Cost corrective actions

  • revise estimate and budget allocations
  • control procurement timing
  • reduce overhead or optimize resource utilization
  • adjust reserves per approved risk responses

A high-mark answer often includes at least one action in each domain (unless the question is narrowly scoped).

4.8 Integrated Risk Thinking

Changes and schedule/cost variances often indicate emerging risks:

• procurement delay risk
• dependency risk (waiting on approvals)
• technical complexity risk
• change-control risk (requirements churn)

Integrated management means:

• track risks alongside performance indicators
• update risk register and contingency as needed
• treat repeated variance patterns as risk evidence

4.9 Exam-Style Integration Questions and Answer Templates

Template for “Explain the impact of a scope change”

1. Identify change type (product vs project scope)
2. List affected WBS work packages
3. Predict schedule impact (critical path? float consumed?)
4. Predict cost impact (resources, reserves, indirect costs)
5. Mention validation/acceptance implications
6. Provide decision and corrective plan

Template for “When should you re-baseline?”

1. Explain why baselines matter
2. Describe conditions requiring formal update:
   • scope changes approved
   • major constraint shifts
   • baseline was invalid
3. Emphasize approval governance and document updates

Section 5: Exam Preparation Toolkit—Worked Examples, Common Mistakes, and South African Project Management Exam Strategy

This final section consolidates practical exam preparation: how to write answers clearly, how to avoid common errors, and how to handle calculation questions under time pressure. It also anchors terminology that UNISA and similar South African project management exams expect.

5.1 How to Write High-Scoring Answers in PGM4813

Exams in this domain reward structured reasoning. Use a consistent structure:

1. Definition / identification (what it is)
2. Purpose (why it exists)
3. Key components (what it includes)
4. Process (how it works or steps)
5. Outputs (what document/result is produced)
6. Impacts (how it affects time/cost/scope integration)

For calculations:

1. State the formula
2. Substitute values
3. Compute clearly
4. Interpret results (sign and meaning)
5. Recommend action

5.2 Worked Practice Set 1: Quick Scope/Time Linking

Question

A project team has a WBS with work package “2.4 API integration & testing” planned for 10 days. Stakeholders request an added reporting endpoint requiring modifications to API logic and testing scripts. Which management actions must be performed?

Ideal answer points

• Identify scope change: added reporting endpoint affects product features and project work.
• Update scope artifacts:
  • scope statement (requirements)
  • WBS (affected work package details)
• Time impact:
  • modify schedule activities corresponding to API integration and testing
  • recompute durations and dependencies
  • check whether this activity sits on critical path
• Cost impact:
  • revise estimates for extra development and testing labor
  • adjust cost baseline and reserves if approved
• Change control:
  • submit change request
  • impact analysis
  • approval decision
• Validation/acceptance:
  • ensure acceptance criteria include new endpoint deliverable

This answer scores because it demonstrates integration rather than isolated explanation.

5.3 Worked Practice Set 2: CPM Interpretation with Critical Path

Use the CPM network from Section 2:

• Total duration = 15 days
• Critical path = A → B → D → E

Question

If activity C (duration 2 days) increases by 1 day, does the project duration necessarily increase?

Ideal answer

• C has slack 1 day (non-critical).
• A 1-day increase may consume slack but might keep the project completion date at 15 days if the increase does not exceed float.
• However, if C exceeds its slack (e.g., +2 days total), it will become critical and project completion date will likely increase unless schedule compression is applied.

This is the type of nuance that distinguishes high grades.

5.4 Worked Practice Set 3: EVM Interpretation

Use EVM values from Section 3:

• PV = R300,000
• EV = R240,000
• AC = R270,000
• CPI = 0.89
• SPI = 0.80

Question

Management asks: “Are we over budget and behind schedule—prove it using indicators.”

Ideal answer

• CV = EV − AC = −R30,000 → over budget.
• SV = EV − PV = −R60,000 → behind schedule.
• CPI = 0.89 (<1) → cost inefficiency.
• SPI = 0.80 (<1) → schedule inefficiency.

Then suggest action:

• investigate root cause: is spending ahead of progress? are dependencies blocking? are requirements unstable?
• adjust plan and consider corrective actions.

5.5 Common Mistakes (What Markers Usually Penalize)

Scope mistakes

• Treating validation as quality control only
• Not distinguishing product scope vs project scope
• Listing activities without WBS logic
• Accepting change requests without change control impact analysis

Time mistakes

• Reducing non-critical tasks and assuming it shortens completion date
• Confusing effort with duration
• Not defining ES/EF/LS/LF logic or slack meaning
• Missing that critical path activities have zero float

Cost mistakes

• Confusing PV/EV/AC
• Computing CPI or SPI incorrectly (wrong ratio)
• Interpreting negative variances incorrectly (e.g., forgetting that CV<0 is over budget)
• Not linking cost inefficiency to likely causes and corrective actions

Integrated mistakes

• Updating only one baseline (e.g., schedule) without considering scope/cost baseline effects
• Re-baselining without mentioning governance/approval needs
• Ignoring risk implications of fast tracking or major scope changes

5.6 Time Management for the Exam: A Calculation Discipline

To maximize marks under pressure:

1. Read the question twice
   • Identify whether it’s conceptual, process-based, or numerical
2. Underline command words
   • “Explain”, “Differentiate”, “Calculate”, “Interpret”, “Recommend”
3. For calculations, write the formula first
   • avoid losing time reconstructing it
4. Substitute numbers carefully
   • keep units and currency consistent (e.g., R, days)
5. Interpret results in one line
   • “Since CPI<1, cost performance is inefficient.”
6. Tie to actions
   • a short corrective action recommendation often earns additional marks

5.7 Consistency Checklist (Avoiding Arithmetic Errors That Lose Marks)

Before submitting:

• Do your CV/SV signs make sense?
• Do CPI and SPI ratios align with CV/SV?
  • Example: if CV is negative, CPI must be <1 (because EV < AC)
• Are your PV/EV/AC definitions correct (PV planned, EV earned, AC actual)?
• Do your slack computations align with critical path identification?
• If you claim “critical path,” do you ensure slack is zero?

5.8 UNISA-Style Terminology Emphasis for PGM4813 Readiness

Even when exam questions do not explicitly mention UNISA phrasing, markers tend to reward using standard project management terms. Ensure you can confidently use:

• scope baseline
• WBS and work packages
• scope validation and control scope
• schedule baseline
• critical path, float/slack, ES/EF/LS/LF
• fast tracking vs crashing
• cost baseline
• PV, EV, AC, CV, SV, CPI, SPI
• EAC forecasting concept
• change request and approved baseline updates

5.9 Linking to Practical Contexts Often Found in South African Case Studies

Exams sometimes simulate real environments that resemble local practice:

• public-sector service delivery constraints (procurement processes and approvals)
• infrastructure and construction scheduling (resource and contractor dependencies)
• IT implementation (requirements churn, acceptance criteria)
• community or training projects (stakeholder validation and reporting requirements)

When writing answers for these contexts, the key is not the industry name but the process discipline:

• define scope precisely
• convert scope into WBS
• convert WBS into activities and sequencing
• schedule via CPM logic and dependencies
• cost via bottom-up estimation and time-phased budgets
• control using variance tracking

5.10 Final Rapid-Revision Summary (Use for Last-Minute Revision)

• Scope management
  • define requirements and deliverables
  • create WBS that is mutually exclusive and collectively exhaustive
  • validate deliverables and control scope using change requests
• Time management
  • convert WBS to activities and dependencies
  • estimate durations and compute critical path with CPM
  • slack/float shows which activities can slip without delaying completion
  • crash critical path for schedule recovery; fast tracking increases rework risk
• Cost management
  • estimate using analogous/parametric/bottom-up approaches
  • build cost baseline and time-phased budget
  • control costs using EVM indicators (PV, EV, AC) and interpret CV/CPI
  • forecast future costs with EAC logic if provided
• Integration
  • scope changes → update WBS, schedule, and cost baselines (with formal approval)
  • time variance often affects cost variance and vice versa
  • corrective actions must address root causes and impact across domains

Appendix: One-Page Formula Sheet (Commonly Needed in Calculations)

CPM

• EF = ES + Duration
• LS = LF − Duration
• Slack/Float = LS − ES (or LF − EF)
• Critical path activities have Slack = 0

EVM

• CV = EV − AC
• SV = EV − PV
• CPI = EV / AC
• SPI = EV / PV
• Interpretation:
  • CV < 0 → over budget
  • SV < 0 → behind schedule
  • CPI < 1 → cost inefficiency
  • SPI < 1 → schedule inefficiency

EAC (common version)

• EAC = AC + (BAC − EV) / CPI

End of PGM4813 Exam Notes on Project Scope, Time & Cost Management for UNISA (College of Economic and Management Sciences).