Fundamentals of Project Management (UFS Online Short Course) Notes — UFS/PMBOK & Practice for MNG/PMM Exam Success

Fundamentals of Project Management is one of the most “exam-friendly” modules because it links theory (process groups, knowledge areas, constraints) to practical decision-making (planning, scheduling, cost control, risk, quality, stakeholder communication). For South African students—especially those taking UFS Online Short Course style modules and similar content assessed alongside MNG (Management) or project-focused courses—marks often come from structuring answers using recognized frameworks (e.g., PMBOK®-style ideas) and applying them to realistic scenarios. These notes are written to support both conceptual understanding and exam performance: clear definitions, step-by-step processes, and concrete mini case studies that mirror the types of questions commonly set in South African university assessments.

1. Project Management Foundations (UFS Online Short Course): Projects, Operations, Constraints, and the Project Life Cycle

1.1 Projects vs. Operations (Exam Differentiator)

A frequent exam question asks you to distinguish a project from operations. The distinction matters because it affects how work is planned, measured, and controlled.

Operations are ongoing, repetitive activities that maintain an organisation’s day-to-day functioning. For example:

Running a university cafeteria every day
Processing payroll monthly
Maintaining network uptime

Projects are temporary and created to deliver a unique outcome. They have:

A defined start and end (even if phases extend)
A unique deliverable (a new system, a new building, a new service)
Uncertainty (because the outcome is not purely repetitive)

Example (University setting):

Operations: Marking assignments for current semesters continuously.
Project: Developing and launching a new e-learning module for 2026 registration, including content creation, testing, and release.

How examiners want you to answer:
Use a crisp comparison:

Time-bound: projects end; operations continue.
Uniqueness: projects produce something new.
Progressive elaboration: project detail increases as you learn more.

1.2 The Triple Constraint: Scope, Time, Cost (and the Hidden Fourth: Quality)

Traditional “triple constraint” thinking is: Scope, Schedule/Time, and Cost. You can often add Quality as a central constraint because quality requirements strongly influence scope, time, and cost.

Scope: what deliverables are included and what requirements must be met.
Time/Schedule: when deliverables must be produced (milestones, deadlines).
Cost: budget allocations for labour, materials, tools, and overhead.
Quality: meeting specified standards (fitness for use, conformance to requirements).

Mini scenario:
A project to upgrade laboratory computers has:

Scope: replace 40 computers with 40 new units
Time: install before Semester begins
Cost: budget cap of R600,000
Quality: must support specific software versions for coursework

If the university wants “better computers” (increased scope/quality), you may need:

more budget, or
less ambitious timeline, or
reduced scope elsewhere (e.g., fewer peripherals)

Exam tip: show cause-and-effect. For instance:

“Increasing CPU requirements impacts both cost (higher unit price) and time (longer procurement) unless mitigations are applied.”

1.3 Stakeholders and Why Project Management Exists

A project often involves multiple stakeholder groups who care about different outcomes:

Project sponsor: wants value and benefits
Customer/end-user: wants usability and acceptance
Project manager: wants plan feasibility and controllability
Team members: want clear tasks and manageable workload
Regulators/assessors: want compliance and evidence
Suppliers/contractors: want delivery reliability and payment clarity

Projects fail not only because plans are wrong but because stakeholder needs are misunderstood or ignored.

Example stakeholder conflict:

End-users want many features (expanded scope).
Sponsor wants cost control (tight cost baseline).
Regulator wants documented testing (quality evidence and time).

1.4 Project Life Cycle: Initiation → Planning → Execution → Monitoring & Controlling → Closing

Many South African exams adopt a PMBOK-like structure through the five process groups. Even if the module doesn’t use the PMBOK textbook word-for-word, these process groups are typically the backbone of structured answers.

Initiation
- Define the project at a high level
- Identify stakeholders
- Develop a project charter or equivalent authorisation
Planning
- Turn goals into workable plans
- Define scope, schedule, cost estimates, risk responses
Execution
- Coordinate people and resources
- Do the work required to deliver products and services
Monitoring & Controlling
- Track performance and manage changes
- Compare actuals vs baseline plan
Closing
- Finalise deliverables
- Obtain formal acceptance
- Close contracts and document lessons learned

Why it matters for exams:
Examiners reward answers that show:

the right process group for the action described
the outputs produced (e.g., schedule baseline, risk register, acceptance criteria)

1.5 Progressive Elaboration and Learning Over Time

Projects often start with incomplete information. Progressive elaboration means you plan in more detail as you learn.

Example: construction vs design phase

During initiation, you may define “build a small access road.”
During planning, you refine it into:
- exact length and materials,
- environmental compliance steps,
- traffic management plan.

1.6 Common Types of Projects (and How They Shape Planning)

Projects vary widely:

Construction and infrastructure (high regulatory and schedule complexity)
IT and systems (high stakeholder and change control complexity)
Research and development (high uncertainty and iterative learning)
Event and change-management projects (stakeholder communication emphasis)

A useful exam practice is to state how project type affects:

risk profile
communication needs
procurement strategy
schedule approach (predictive vs adaptive)

Mini classification exercise:
If a project requires:

strict compliance documentation → emphasise monitoring & quality evidence
rapid stakeholder approvals → emphasise communication and governance
prototype testing → emphasise risk and iterative planning

2. Project Integration & Scope Management (UFS Online Short Course): Charters, Plans, Deliverables, and Work Breakdown Structures

2.1 Project Integration Management: The “Glue” of Project Management

Integration management ensures all parts of the project work together coherently. Integration is why you can’t treat cost, scope, and schedule as separate islands.

In an exam answer, integration management is typically demonstrated by referencing:

project charter (authorisation)
project management plan (how you will execute and control)
directing & managing project work (coordinating activities)
monitoring & controlling (integrated tracking)
performing integrated change control

2.2 The Project Charter: What It Must Contain

A project charter is a formal document that authorises the project. While different universities phrase it differently, the charter usually includes:

Project purpose and justification (why do it?)
Objectives (measurable goals)
High-level requirements
High-level risks
Budget and milestone targets (often at high level)
Assigned roles (sponsor, PM, key stakeholders)
Authority for the project manager (what they can decide)

Exam-style example objective (good vs vague):

Vague: “Improve lab efficiency.”
Better: “Reduce average student computer login time from 3 minutes to 60 seconds by end of Semester.”

2.3 Developing the Project Management Plan (What “Planning” Really Means)

The project management plan is not just a schedule; it is a structured set of plans describing how the project is executed, monitored, and controlled.

Typical components include:

Scope management plan
Schedule management plan
Cost management plan
Quality management plan
Resource management plan
Communications management plan
Risk management plan
Procurement management plan
Change management process (integrated change control procedures)

Why this is exam-critical:
A common mistake students make is writing “we will create a schedule” without specifying how. Examiners often want:

who creates the plan
what approvals are needed
how changes are handled
what baseline is used

2.4 Integrated Change Control: Managing Change Without Losing Control

Change is inevitable. Integrated change control is the discipline of:

recognising changes,
assessing their impact,
approving/rejecting them,
documenting them.

Impact assessment categories:

Scope impact: what deliverables change?
Schedule impact: what milestones shift?
Cost impact: what budget changes?
Quality impact: what standards change?
Risk impact: does uncertainty increase or decrease?

Mini scenario (IT project):
A university requests: “Add offline mode to the student portal.”

Scope increases (new requirement).
Testing increases (time/cost).
Risk may increase (additional complexity).

An integrated change control answer should mention:

change request submitted
impact analysis performed
decision by change control board / sponsor
update baselines (scope baseline, schedule baseline, cost baseline) if approved

2.5 Scope Management: Collecting Requirements, Defining Scope, and Creating a Baseline

Scope management aims to ensure the project includes only the work required to deliver the agreed deliverables.

Key steps:

Collect requirements
Define scope
Create WBS
Validate scope
Control scope

2.6 Requirements: Stakeholder Needs vs Requirements Specifications

It helps to separate:

Stakeholder needs: what people care about (e.g., “students must access materials reliably”)
Requirements: measurable or testable statements that can be verified (e.g., “portal must load within 3 seconds on 5 Mbps connectivity”)

Example of measurable requirement:

Need: “Make the system secure.”
Requirement: “All user logins require MFA; password policy meets minimum length and lockout rules; security testing results must be documented.”

2.7 Defining Scope and the Scope Statement

A scope statement is central for controlling changes. It typically includes:

deliverables
boundaries/exclusions
assumptions and constraints
acceptance criteria (or links to acceptance criteria)

Why exclusions matter:
If the scope statement doesn’t explicitly exclude something, stakeholders can later argue it was “implicitly included.”

2.8 Work Breakdown Structure (WBS): Turning Scope into Manageable Work

A WBS decomposes the project scope into smaller components. Exam questions often ask you to:

explain what WBS is
list typical decomposition rules
create a WBS for a small scenario
explain how WBS supports scheduling and cost estimating

Decomposition principles:

Each descending level should be more detailed.
WBS elements should be deliverable-oriented.
Work packages are small enough to estimate and assign to responsible owners.

2.9 WBS and Work Packages: Estimating and Scheduling Link

A work package is a part of the work identified at the level where cost and duration can be estimated and managed.

How it connects to planning:

Build the WBS → define work packages
For each work package:
- estimate resources,
- estimate duration,
- estimate cost,
- define acceptance criteria,
- identify risks.

2.10 WBS Example (University Infrastructure)

Project: Renovate a small teaching lab for accessibility compliance and modern equipment.

Level 1 (Project): Lab Renovation
Level 2:

Accessibility upgrades
Electrical and lighting improvements
Equipment installation
Testing and handover

Level 3 (illustrative):
1.1 Install ramps and adjust door clearances
1.2 Upgrade restroom accessibility
2.1 Replace lighting fixtures and add task lighting
2.2 Verify wiring safety compliance
3.1 Install computers and peripheral network
3.2 Configure software imaging
4.1 Conduct safety inspection
4.2 Conduct equipment performance verification
4.3 Handover documentation and training

Exam bonus: mention that WBS helps:

clarify scope boundaries
identify missing work
create a structured schedule
support cost baseline and tracking

2.11 Scope Validation and Acceptance

Validation means formalising acceptance of deliverables. Even if “work is done,” it may not be accepted unless it meets defined requirements.

Common acceptance artifacts:

sign-off forms
test reports
user acceptance testing (UAT) evidence
compliance certificates
training completion logs

2.12 Scope Control: Preventing Scope Creep

Scope creep occurs when extra work is added without adjustments to time/cost. Scope control ensures changes are:

requested properly,
assessed,
authorised before being performed.

Exam-style explanation:
Scope control compares actual deliverables and performance against the scope baseline. It also updates documentation when approved changes occur.

3. Schedule, Cost, and Quality Management (UFS Online Short Course): From Estimating to Baselines and Control

3.1 Schedule Management Basics: Build a Timeline You Can Defend

Schedule management ensures the project has a schedule that reflects realistic dependencies and resources. In exam settings, students often get partial credit if they:

mention a network approach (even conceptually),
identify critical activities,
explain baselines and updates.

Typical outputs:

Schedule baseline (approved plan for comparing performance)
Schedule management plan
updated schedules after changes

3.2 Estimating: Analogous, Parametric, and Bottom-Up (Know When Each Applies)

Projects use several estimation techniques:

Analogous estimating
- Uses the cost/duration of similar past projects
- Pros: fast
- Cons: less accurate if projects differ
Parametric estimating
- Uses statistical relationships (e.g., “cost per square meter”)
- Pros: more data-driven
- Cons: needs reliable historical parameters
Bottom-up estimating
- Estimates each work package then aggregates
- Pros: most accurate when work packages are well-defined
- Cons: time-consuming

Exam practice:
If a question describes limited historical data and urgent deadlines, students should justify an analogous approach or a top-down estimate, then explain how uncertainty is handled.

3.3 Dependencies: Why Some Activities Must Wait

Schedule accuracy depends heavily on understanding dependencies:

Finish-to-start (FS): predecessor must finish before next starts
Start-to-start (SS): start together with lag/lead
Finish-to-finish (FF): finish together
Start-to-finish (SF): least common; predecessor must start before successor finishes

Simple example:
In a lab renovation:

Electrical wiring safety inspection cannot be completed before wiring work is done.
Equipment installation can’t start until electrical improvements are ready.

3.4 Critical Path Concept (Common Exam Item)

The critical path is the sequence of tasks that determines the earliest project completion time. Delays on critical path tasks delay the whole project unless schedule compression or recovery actions are used.

To answer well in exams:

define critical path in simple terms
describe its purpose (to identify where delays matter most)
mention that non-critical tasks have float (time buffer)

3.5 Scheduling Approaches: Predictive vs Adaptive (Exam-Friendly Distinctions)

Some South African course materials discuss predictive planning as:

schedule and requirements are planned in advance

Adaptive (iterative) planning is appropriate when:

requirements evolve,
prototypes are needed,
feedback loops reduce uncertainty

Example:

Predictive: building renovation with known specifications.
Adaptive: developing a new learning app where user feedback shapes features.

Even when modules focus on fundamental predictive methods, exam answers can earn marks by stating when a different approach fits.

3.6 Cost Management: Estimating, Budgeting, and Cost Baselines

Cost management includes:

estimating costs for work packages,
determining budgets,
controlling costs.

Budgeting turns estimates into an approved cost baseline, often organised:

by time period (e.g., monthly budgets),
by work package,
by cost category.

3.7 Cost Control and Change: The Relationship Between Baseline and Reality

Cost control compares actual spending to the cost baseline. If performance deviates:

analyse variance causes (e.g., resource inefficiency, procurement delays),
implement corrective actions,
apply change control when scope changes cause cost shifts.

3.8 Quality Management: Quality Planning, Assurance, Control

Quality management ensures deliverables meet requirements. Often three concepts are contrasted:

Quality planning: define standards and how to meet them (process and product standards)
Quality assurance: planned activities to provide confidence that quality requirements will be met (audits, process reviews)
Quality control: inspect or test deliverables to identify defects and ensure conformance (testing, measurement)

3.9 Quality Standards and Acceptance Criteria

Quality in exams is not “gold plating”—quality is conformance to agreed standards and fitness for purpose.

Example acceptance criteria (equipment installation):

40 computers must successfully run the required software suite during performance testing.
Setup documentation must be delivered to support staff.
Any failing unit must be replaced within 48 hours.

3.10 Concrete Cost-Control Mini Case Study (With Numbers)

To make cost control tangible, consider the following exam-style scenario.

Scenario:
A university project budget for “Student Portal Improvements” is R800,000. It covers four work packages:

Work Package	Planned Cost (R)	Planned Duration
Requirements & UX design	200,000	4 weeks
Back-end development	300,000	6 weeks
Front-end integration	200,000	4 weeks
Testing & deployment	100,000	2 weeks
Total	800,000	—

At week 6, the project is reported as:

Requirements & UX design: completed as planned (200,000)
Back-end development: completed but over budget by R30,000 (actual 330,000)
Front-end integration: started, with actual costs of R120,000 so far (planned cost for that phase was R100,000)
Testing & deployment: not started

Question type (common): “What cost issues exist and what must the PM do next?”

Good exam response elements:

Identify variance:
- Back-end variance: +30,000 against plan for that work package.
- Front-end variance to date: +20,000.
Investigate causes:
- changed requirements?
- inefficiency or technical blockers?
- subcontractor overruns?
Apply appropriate control actions:
- if scope is unchanged: corrective action to improve productivity
- if scope has changed: submit change request and update cost baseline
Update forecasts:
- re-estimate remaining costs based on actual progress
Document decisions:
- traceability for future audits and acceptance

Why this matters:
Examiners want to see that cost control is not just “noting overrun.” It’s analysis + corrective actions + governance.

3.11 Quality Control: Defect Detection vs Prevention

Students sometimes treat quality as only testing at the end. A strong answer explains prevention:

include reviews during development,
define coding standards,
conduct peer reviews and unit tests,
track defect types and their root causes.

Example:
If during testing many defects relate to missing requirement handling, you might:

revise requirement interpretation,
increase design walkthroughs,
improve developer checklists.

3.12 Risk Interaction: Schedule and Cost Risks

Schedule delays can cause cost increases:

overtime labour,
extended supplier lead times,
additional testing cycles.

This is why schedule and cost control must consider risk status:

Are key risks still active?
Did risk response fail, causing overruns?
Did new risks emerge due to delays?

4. Risk, Stakeholder, and Communications Management (UFS Online Short Course): Identifying Risks, Planning Responses, and Running Stakeholder Systems

4.1 Risk Management Overview: From Uncertainty to Action

Risk management turns uncertainty into structured action. A strong exam answer distinguishes:

Risk: uncertainty that can have positive or negative effects
Opportunity: positive risk effect
Threat: negative risk effect

Core risk activities typically include:

Plan risk management
Identify risks
Perform qualitative and quantitative risk analysis
Plan risk responses
Implement responses
Monitor and control risks

4.2 Risk Identification: Sources Students Should Mention

Common sources of risks:

technology uncertainties (e.g., integration difficulties)
stakeholder dependencies (delays in approvals)
procurement lead times
regulatory and compliance uncertainties
resource constraints (skills shortages)
environmental factors (site access delays, weather)

Exam-friendly technique:
Use a risk breakdown approach (by category) and include both internal and external risks.

4.3 Qualitative Risk Analysis: Risk Scoring Logic

Qualitative analysis prioritises risks using:

Likelihood (probability)
Impact (severity on objectives)

Often the exam expects something like a risk matrix:

likelihood levels (Low, Medium, High)
impact levels (Low, Medium, High)
resulting priority ranking

Example scale (illustrative):

Likelihood: 1–3
Impact: 1–3
Risk score = likelihood × impact

If:

Likelihood = 3 and Impact = 2 → score = 6 (high priority)
Likelihood = 2 and Impact = 1 → score = 2 (lower priority)

4.4 Risk Register: What It Must Contain

A risk register is a living document that tracks:

risk ID and description
category
cause (why it might happen)
event (what could occur)
impact areas (scope, schedule, cost, quality)
probability and impact ratings
risk owner (who monitors)
response strategy
triggers (what signals the risk is happening)
contingency reserves or response budget (if used)

Exam tip: including a risk owner and triggers earns credibility because it shows operational control, not only theory.

4.5 Risk Response Strategies (Know the Names and Use Cases)

Common strategies:

For threats (negative risks):

Avoid: eliminate the cause (change approach)
Mitigate: reduce probability or impact
Transfer: shift impact (insurance, contracts)
Accept: no active response, but monitor; sometimes contingency exists

For opportunities (positive risks):

Exploit: ensure it happens (remove barriers)
Enhance: increase probability or impact
Share: partner to gain benefit
Accept: take advantage if it occurs

4.6 Mini Case Study: Procurement Delays and Mitigation

Scenario:
In a “learning device refresh” project, the project depends on receiving 40 units by a deadline. A supplier in Bloemfontein (for example, local delivery channel) signals potential delay if customs clearance happens late.

Risk (threat):

Description: Supplier delivery delayed beyond milestone date.
Probability: Medium
Impact: High (schedule slip; possible need for temporary devices)
Category: external/procurement

Response plan:

Mitigate: place order early; require expedited shipping contract clause.
Transfer: include penalty clauses in procurement contract for late delivery.
Contingency: identify backup supplier or rental devices for a “shortfall period.”

Exam answer structure:

Identify risk
classify as threat or opportunity
choose response strategy aligned with severity
name triggers (e.g., “if delivery date changes by more than 7 days”)
allocate contingency resources

4.7 Stakeholder Management: Identifying, Analysing, and Engaging

Stakeholder management ensures the people affected by the project can support successful outcomes.

Typical steps:

Identify stakeholders
Determine stakeholder influence/interest
Plan engagement strategies
Manage engagement and communications
Monitor changes in stakeholder positions over time

4.8 Stakeholder Power vs Interest Grid

An exam-friendly model splits stakeholders into categories:

High power / high interest: manage closely
High power / low interest: keep satisfied
Low power / high interest: keep informed
Low power / low interest: monitor

Example:

Project sponsor: high power, high interest
End-users (students): moderate/high interest, power moderate
Suppliers: moderate power, lower interest (unless contract penalties/quality issues)

4.9 Communications Management: What to Send, to Whom, When, and How

Communications management includes:

communication planning (what, when, who)
information distribution (actually send it)
performance reporting
stakeholder communications management

Core principle: Communication should be tailored to stakeholder needs.

Example communications plan (simplified):

Stakeholder Group	Frequency	Main Message
Sponsor	Weekly	progress vs milestone; major risks; decisions needed
Team leads	Weekly	task progress; blockers; next-week schedule
End-users	Bi-weekly	upcoming changes; training sessions; feedback channels
Quality/compliance	As required	testing evidence; compliance reports

4.10 Common Communications Failures (and How Exams Test Them)

Common mistakes:

too much detail for executives (communication overload)
too little detail for implementers (execution confusion)
no escalation pathway (issues remain hidden until late)
inconsistent messages between PM and sponsor

High-mark exam answer:
Mention escalation and governance:

define who approves changes,
define what issues must be escalated,
define timeframe for responses.

4.11 Managing Stakeholder Expectations: Handling “Scope by Conversation”

Stakeholder expectations often change through informal conversations. The project should:

document baseline scope and requirements
treat informal requests as potential changes
use change control for approved modifications

Example:
During weekly feedback, a student group asks for additional accessibility features. If not documented and analysed, it may become “scope creep.” Correct approach:

log request as change
assess impact on schedule/cost/quality
decide whether to approve, defer, or reject

4.12 Integrating Risk and Stakeholders: Risk Communication

Risks are not only internal project documents. Stakeholders need risk visibility proportional to their influence and the severity of impacts.

Example:

Sponsor needs high-level top risks and recommended actions.
Team needs risk triggers and response responsibilities.
Procurement needs supplier-related risk monitoring.

5. Project Execution, Monitoring & Controlling, Procurement, and Closing (UFS Online Short Course): Governance, Performance Tracking, Lessons Learned, and Exam-Ready Wrap-Up

5.1 Execution Management: Turning Plans into Deliverables

Execution is where the project produces outcomes. It includes:

directing and managing project work,
managing team performance,
acquiring resources,
implementing risk responses,
implementing quality activities.

Even if you don’t focus on advanced human resource topics in a short course, execution answers should mention:

coordinating work
managing deliverables
ensuring the team follows defined processes

5.2 Team and Resource Management (Fundamentals That Show Up in Exams)

Resource constraints frequently drive schedule and cost issues. Basic execution competence includes:

assigning tasks aligned to skill sets
confirming availability
managing workload and task handovers
tracking progress against planned work packages

Example execution failure pattern:

the schedule assumes a developer is available full-time
actual workload conflicts with another project
tasks slip
cost increases due to overtime or delays

Corrective action:

adjust schedule baseline (if justified with change control) or
reallocate resources or
redesign scope to match available capacity

5.3 Monitoring & Controlling: Performance Measurement vs Baseline

Monitoring & controlling involves comparing actual project performance against baselines and targets, and taking corrective or preventive actions.

In many fundamental modules, the exam focus is on:

tracking progress
reporting status
managing changes
controlling scope, schedule, and costs

Key idea: Monitoring is “observe and measure,” controlling is “decide and adjust.”

5.4 Status Reporting: What Makes a Report “Good” for Marks

A strong status report typically includes:

progress summary
milestone status
what completed since last report
what is planned next
issues and blockers
risks requiring decisions
changes requested/approved

Exam tip:
Avoid narrative-only reporting. Use:

factual progress comparisons
clear issue/risk descriptions
explicit next steps and decision requests

5.5 Forecasting: Predicting Future Performance from Current Trends

A common exam theme is forecasting:

If behind schedule, what is expected finish date?
If spending is above plan, what is projected total cost?

Forecasting requires assumptions based on:

current productivity
dependency status
probability of risk triggers
remaining work complexity

Mini scenario:

If a work package is running 20% slower than planned and it has 2 weeks remaining out of a 10-week schedule, a naive approach might miscalculate. Instead:
- estimate remaining effort based on actual performance,
- confirm whether dependencies will amplify delay.

5.6 Corrective vs Preventive Actions (Not the Same)

Students often confuse terms. For exams:

Corrective action: happens to bring performance in line with the plan (reactive)
Preventive action: happens to reduce probability of future negative performance (proactive)

Example:

Corrective: fix a bug discovered during testing that blocks acceptance.
Preventive: add additional code reviews to reduce recurring defect types.

5.7 Governance and Change Control Boards (CCB)

In larger projects, changes are reviewed by a group often described as a change control board (CCB). The governance ensures:

the right people approve scope/time/cost changes
decisions are documented
baselines remain controlled

Exam answer structure:

identify who has approval authority (sponsor, CCB, PM with limits)
explain change documentation (form, log, impact assessment)
describe how approvals update baselines

5.8 Procurement Management Fundamentals: Buying What the Project Needs

Procurement management includes:

deciding what to buy or outsource,
selecting vendors,
managing contracts,
receiving and verifying delivered goods/services,
closing procurement contracts.

Even in short courses, it is common to see procurement appear in scenarios.

5.9 Make-or-Buy Decision: Why Procurement Starts Earlier Than Buying

A project must decide whether to:

make internally (own team develops)
buy externally (supplier provides product/service)
mix approach (some internal development, some outsourced components)

This decision affects:

schedule (lead time)
cost (supplier pricing vs internal labour)
risks (supplier performance risk)
quality (specifications and inspection process)

5.10 Vendor Selection Basics (Sourcing and Evaluation)

Even at a fundamentals level, students should know that selection involves:

defining procurement requirements
using evaluation criteria (price, quality, delivery timeline, technical capability)
contract negotiation

Exam question possibility:
“Describe how you would select a contractor to supply and install laboratory equipment.”

A high-mark answer mentions:

requirement definition
evaluation criteria
risk considerations in contract terms (delivery penalties, warranty, service level agreements)

5.11 Contract Types (Basic Concepts)

Common contract types (conceptual):

Fixed-price: set price; risk transfers more to supplier.
Time and materials: pays based on time/materials; risk remains more with customer.
Unit price: based on units delivered (common in construction).

Exams often ask you to match contract type with uncertainty level:

high uncertainty → time/materials or unit pricing can handle variability
stable requirements → fixed-price may be efficient

5.12 Closing: Formal Acceptance, Contract Closure, and Lessons Learned

Closing ensures the project is completed formally and learning is captured.

Closing activities include:

obtaining final deliverable acceptance
completing documentation
releasing resources
closing contracts and claims
conducting lessons learned reviews

Why lessons learned matter for exams:
Because examiners look for evidence that the PM will improve future projects.

5.13 Lessons Learned: How to Write Them So They Are Useful

A good lessons learned entry includes:

what happened
why it happened (root cause where possible)
impact on objectives
what to do next time (actionable recommendation)

Example lesson learned (schedule & risk):

Event: procurement delay caused schedule slip.
Cause: late confirmation of delivery lead time.
Impact: installation delayed by 3 weeks.
Recommendation: earlier supplier verification and contract lead-time guarantees.

5.14 Putting It All Together: End-to-End Exam Scenario (Integrated Walkthrough)

To consolidate the fundamentals and demonstrate integrated thinking, consider a full scenario.

Scenario:
The University is running a project to launch a “UFS Student Support Helpdesk Upgrade” before the start of the academic year.

Project goals (scope objectives):

Launch a helpdesk portal with ticket submission, tracking, and knowledge base.
Provide training for support staff.
Ensure accessibility and performance requirements.

Constraints:

Budget: R1,200,000
Target launch date: 8 weeks
Quality: must meet specified accessibility and performance test outcomes.

Step 1: Initiation outputs

Project charter: includes purpose, high-level objectives, assigned PM, sponsor, and high-level risks.
Stakeholder register: identifies sponsor, end-users (students), support staff, IT team, suppliers.

Step 2: Planning outputs

Scope statement with boundaries (e.g., portal upgrade does not replace student portal login systems).
WBS decomposes work into:
- requirements and UX,
- back-end configuration,
- front-end integration,
- knowledge base content migration,
- testing and accessibility verification,
- training and handover
Schedule baseline created with dependencies:
- content migration cannot start until taxonomy and templates are approved.
Cost baseline built using work package estimates that sum to R1,200,000.
Risk register created with top risks:
- supplier delivery delays for support system components,
- data migration errors,
- stakeholder approval delays for UX and accessibility sign-off.
Communications plan specifies:
- weekly sponsor reports
- bi-weekly end-user feedback updates
- daily standups for IT during integration weeks

Step 3: Execution

IT team works through work packages; support staff participate in usability sessions.
Training sessions scheduled during the last 2 weeks.
Risk responses implemented (e.g., data migration trial runs).

Step 4: Monitoring & Controlling

Compare actual progress to baseline.
Track key milestones:
- UX sign-off date
- accessibility test completion
- user training completion
If delays occur, determine corrective actions:
- reallocating resources to testing,
- tightening defect triage,
- submitting change requests if scope changes are introduced by stakeholders.

Step 5: Closing

Validate deliverables and obtain formal acceptance from sponsor and support leadership.
Close suppliers’ contracts.
Conduct lessons learned:
- effectiveness of stakeholder engagement schedule
- whether risk triggers were detected early enough
- what to improve in future portal upgrades

What examiners reward:
Answers that show linkages:

charter → plan → execute → measure → control → close,
mention baselines,
mention change control,
connect risk, quality, schedule, and cost.

5.15 Quick Exam Revision Checklists (Use in Tests)

Integration & governance checklist

Charter authorises project
Project management plan includes baselines and governance
Change control is documented and enforced
Approvals are traceable

Scope checklist

Requirements are measurable/testable
Scope statement includes boundaries and exclusions
WBS decomposes scope into manageable work packages
Acceptance criteria enable validation

Schedule & cost checklist

Schedule includes dependencies and milestones
Cost baseline is derived from work package estimates
Variances are analysed with corrective/preventive actions
Forecasts consider risks and remaining work

Quality checklist

Quality planning defines standards
Quality assurance provides confidence (audits/reviews)
Quality control tests/inspects deliverables
Acceptance is evidence-based

Risk & stakeholders checklist

Risk register includes owners and triggers
Risk responses match threat/opportunity type
Stakeholders are analysed by power/interest
Communications are tailored and scheduled
Risks and issues are escalated appropriately

Closing Reflection (Exam-Ready Mindset)

The fundamentals of project management are best mastered through structured thinking: start with authorisation (charter), map scope into work (WBS), plan time and money into baselines, execute while meeting quality standards, control deviations using governance and change control, and close formally with lessons learned. In a South African university exam context, these steps become your scoring framework. When you can describe processes and connect them to realistic scenarios—especially around scope control, cost/schedule variance, risk triggers, and stakeholder communication—you convert “theory” into “exam answers” that demonstrate competence.