TUT Short Course in Practical Project Management Study Pack (TUT Project Management Course Notes)

The TUT Short Course in Practical Project Management is designed for learners who need more than theory: it focuses on applying core project management practices to realistic scenarios, aligning stakeholders, controlling scope/time/cost, and making disciplined decisions under uncertainty. This study pack consolidates exam-relevant concepts and practical tools into a structured set of notes, including process flows, templates, examples, and “how to answer” guidance. It is written to support learners registered for Tshwane University of Technology (TUT) project management-related learning outcomes, particularly within the practical emphasis found in project modules and short courses.

Throughout the pack, the same fictional case project is used repeatedly to make the learning coherent and exam-ready. The case is a realistic campus renovation delivery scenario, which mirrors the kinds of constraints learners typically discuss in project management assessments—stakeholder pressure, scope changes, procurement lead times, risk exposure, and reporting requirements.

Section 1: Foundations of Practical Project Management at TUT (and How They Appear in Assessments)

Practical project management is about making progress predictable. While “project management” can sound abstract, a practical orientation turns concepts such as planning, scheduling, budgeting, monitoring, and risk management into repeatable habits. At TUT, learners are expected to understand both the logic of project processes and the discipline of execution—showing how decisions are made using evidence, not assumptions.

The Project Lifecycle (Exam-Style: What to Describe, Not Just Definitions)

Most TUT assessments that reference practical project delivery expect you to explain the project lifecycle in a way that shows cause-and-effect. A lifecycle is not only a sequence of phases; it is how you control governance, risks, and resources across time.

A commonly used lifecycle structure (which you may see mirrored in TUT course frameworks) is:

Initiation
Planning
Execution / Delivery
Monitoring & Controlling
Closing / Handover

Key exam points:

Initiation is about authorising and clarifying purpose.
Planning is about turning purpose into baselines (scope baseline, schedule baseline, cost baseline).
Execution is about delivering work according to plans.
Monitoring & Controlling is about comparing actuals to baselines and taking corrective action.
Closing is about formal acceptance, documentation, lessons learned, and release of resources.

In practical project management, learners often lose marks by giving only the phase names without linking them to outcomes. When you answer, always include at least one concrete deliverable or decision typical for that phase.

Common exam deliverables by lifecycle phase

Initiation deliverables
- Project Charter (or equivalent authority document)
- High-level scope statement
- Stakeholder register (initial version)
- High-level risks (initial risk register)
Planning deliverables
- Work Breakdown Structure (WBS)
- Schedule (often in Gantt format)
- Budget / cost estimates and cost breakdown
- Resource plan (roles, capacity assumptions)
- Risk register with probability/impact and response strategies
- Communication plan
- Procurement plan (if relevant)
Execution deliverables
- Task completion records
- Change requests submitted and approved/declined
- Quality checks performed
- Progress reports to stakeholders
Monitoring & Controlling deliverables
- Status reports comparing baseline vs actual
- Variance analysis
- Updated forecasts
- Corrective action logs
- Updated risk register
Closing deliverables
- Handover certificates / acceptance sign-off
- Final report
- Lessons learned workshop outputs
- Archiving of documents and metrics

Case Project Used Throughout the Pack: Tshwane Library Upgrade (TUT Campus)

To keep concepts consistent across sections, this pack uses a single running case: Case Project A: Tshwane Library Upgrade. The scenario is set on a fictional Tshwane University of Technology campus building (using “Tshwane” as a location name as commonly referenced in South African contexts). The project involves renovating study areas, upgrading electrical fittings, and installing Wi-Fi access points.

Case Project A details (fixed for consistency):

Objective: Upgrade learning spaces to improve student study capacity and connectivity.
Deliverables:
1. Renovated study rooms (paint, flooring, seating arrangement)
2. Improved electrical points and lighting
3. Wi-Fi access point installation and basic configuration
4. Safety compliance checks and sign-off
5. Project handover package (as-built drawings, warranties, lessons learned)
Time target: 12 weeks from project start to handover.
Budget target (baseline): ZAR 1,200,000 (cost baseline).
Team roles:
- Project Manager: Nomsa Mokoena
- Technical Lead (Electrical/Wi-Fi): Sibusiso Dlamini
- Procurement Officer: Zanele Ndlovu
- Site Supervisor: Thabo Maseko
- Quality Officer: Martha Khumalo
Key stakeholders:
- Campus Facilities Manager: Dr Kgomotso Phiri
- Student Representative Council (SRC) Liaison: Thandeka Ncube
- Procurement Committee Chair: Mr Mkhize
- End-user group: Students (represented in consultations by Thandeka Ncube)

This case will be used to illustrate scheduling, cost control, risk response, procurement, stakeholder communication, and reporting.

Practical Planning Mindset: Baselines and Control

A central exam concept in practical project management is baselining. Baselines are the reference points used to measure performance. Without baselines, variance analysis becomes guesswork.

For Case Project A:

Scope baseline: Work defined in deliverables and WBS
Schedule baseline: 12-week timeline with agreed start/end dates for major work packages
Cost baseline: ZAR 1,200,000 distributed across categories (labor, materials, subcontractors, compliance, contingency)

When answers are evaluated, examiners look for evidence that the learner understands:

What was agreed (scope baseline)
When it should happen (schedule baseline)
How much it should cost (cost baseline)
How to measure deviation (monitoring & controlling)

Stakeholder Management in Practical Delivery (and Common South African Realities)

Stakeholder management is not optional in practical projects, especially in campus environments where decisions can be influenced by compliance, procurement rules, and student concerns.

For Case Project A, stakeholders have different needs:

Dr Kgomotso Phiri (Facilities Manager): wants compliance, smooth campus operations, and minimal disruption.
Thandeka Ncube (SRC Liaison): focuses on student experience, noise and access scheduling, transparency about delays.
Mr Mkhize (Procurement Committee Chair): emphasises approved procurement process, correct documentation, and vendor compliance.
Students (end-users): want reliable Wi-Fi and study spaces available on schedule, with safety assurance.

Practical project management includes:

Identifying stakeholders
Understanding their influence and interest
Planning engagement strategies (communication frequency and format)
Handling issues and change requests transparently

Quality and Practical Controls

In many project management assessments, learners are expected to connect quality management to project success. Quality is not “end testing only”; it is built into planning and controlled during execution.

Quality in Case Project A includes:

Approved checklists for renovation works
Electrical safety compliance checks
Wi-Fi performance verification against agreed standards
Safety sign-off procedures before handover

To score well, explicitly explain that quality controls reduce rework—which directly affects schedule and cost. Examiners often reward answers that link quality to the “triple constraint” (scope/time/cost) instead of treating quality as separate.

Section 2: Scope, WBS, Scheduling, and Costing—Turning Plans into Measurable Baselines

Practical project management becomes tangible when scope is broken down into controllable work packages, when time is scheduled realistically, and when cost is estimated with assumptions that can be defended. This section focuses on the mechanics of WBS development, schedule building, and cost baselining, all of which frequently appear in TUT-related practical assessment tasks.

Scope Definition: From “What We Want” to “What We Will Deliver”

Scope definition is not a single activity—it includes planning how scope will be created, validated, and controlled.

For Case Project A, the scope statement should align to deliverables. In exam answers, it is helpful to list:

In-scope items (explicit inclusions)
Out-of-scope items (explicit exclusions)
Assumptions
Constraints
Acceptance criteria

Example for Case Project A (illustrative of what learners should write):

In scope

Renovation of designated study rooms (identified in WBS)
Installation of additional electrical points and improved lighting
Wi-Fi access point installation and basic configuration
Safety compliance checks and sign-off
Formal handover package documentation

Out of scope

Full building-wide architectural redesign (only designated rooms)
Upgrade of the entire campus network backbone (Wi-Fi access points only within project boundary)
Replacement of all existing seating across all floors

Assumptions

Renovation area availability during working windows agreed with facilities
Suitable vendor lead time for Wi-Fi hardware and electrical fittings

Constraints

Total project duration must fit within 12 weeks
Budget baseline is ZAR 1,200,000
Compliance checks require scheduled inspections

Acceptance criteria

Safety compliance sign-off completed before handover
Renovated rooms usable for student study at handover date
Wi-Fi connectivity test results meet agreed minimum performance

This structure is useful for exams because it makes scope verifiable and reduces ambiguity—exactly what practical project managers are assessed on.

WBS (Work Breakdown Structure): The Backbone of Practical Control

The WBS is the tool that converts scope into manageable units. In practical project management, WBS is where cost and schedule planning become feasible.

How WBS is typically examined

Examiners often ask you to:

Explain what a WBS is
Demonstrate how a deliverable becomes work packages
Show how work packages support scheduling and costing
Provide an example WBS breakdown

A sample WBS for Case Project A (illustrative)

Level 1: 1.0 Project Tshwane Library Upgrade

Level 2 and Level 3 (representing deliverables and work packages):

1.1 Renovated Study Rooms
- 1.1.1 Room preparation (clearance, protection, site setup)
- 1.1.2 Flooring replacement
- 1.1.3 Painting and finishing
- 1.1.4 Seating arrangement and furniture placement
- 1.1.5 Cleaning and punch-list closure
1.2 Electrical Improvements
- 1.2.1 Electrical point upgrades
- 1.2.2 Lighting installation
- 1.2.3 Electrical testing and safety checks
1.3 Wi-Fi Installation
- 1.3.1 Access point procurement coordination
- 1.3.2 Access point mounting and wiring
- 1.3.3 Basic configuration and connectivity tests
- 1.3.4 Documentation of configuration (handover-ready)
1.4 Safety and Compliance
- 1.4.1 Safety compliance inspection scheduling
- 1.4.2 Compliance tests and certificates
- 1.4.3 Handover readiness audit
1.5 Project Management and Closure
- 1.5.1 Project planning baseline finalisation
- 1.5.2 Progress reporting and meeting cadence
- 1.5.3 Risk and change control activities
- 1.5.4 Final handover package compilation
- 1.5.5 Lessons learned workshop and close-out

This WBS is designed so each work package can be assigned a resource, estimated duration, and associated cost category.

Why WBS matters for exam performance

You earn marks when you connect WBS to control:

Work packages become schedule activities
Work packages become cost elements
Work packages become monitorable units
Work packages allow accurate progress measurement (percent complete, completed milestones, or earned value approximations depending on course emphasis)

Scheduling: Sequencing, Dependencies, and Realistic Timelines

In practical scheduling, time is not just “dates”—it is the logic of dependencies.

Common dependency types

Finish-to-Start (FS): Activity B cannot start until A finishes.
Start-to-Start (SS): Activity B can start when A starts.
Finish-to-Finish (FF): Activity B must finish when A finishes.
Start-to-Finish (SF): Rare; used in specialised cases.

For Case Project A, key scheduling dependencies include:

Room preparation (1.1.1) must finish before flooring replacement (1.1.2).
Electrical point upgrades (1.2.1) should precede lighting installation (1.2.2).
Access point procurement coordination (1.3.1) must precede mounting and wiring (1.3.2).
Wi-Fi configuration (1.3.3) depends on successful installation (1.3.2).
Safety compliance inspection depends on completion of renovation, electrical, and Wi-Fi testing (1.1, 1.2, 1.3).

Building a Schedule Baseline for a 12-Week Project

A typical schedule plan for a 12-week project must align major work packages so that procurement lead times and compliance inspections do not compress reality.

One practical approach is to schedule in phases:

Weeks 1–2: planning baseline finalisation, site prep, procurement coordination, early electrical works
Weeks 3–7: bulk renovation and electrical works, installation activities begin when materials arrive
Weeks 8–10: finishing, configuration, integration tests, compliance prep
Weeks 11–12: compliance sign-off, handover documentation, closure activities

Example schedule table (simplified but exam-friendly)

Work Package	Duration (weeks)	Planned Start (week)	Planned Finish (week)	Primary Dependencies
1.1.1 Room preparation	1.0	1	1	Project kickoff
1.1.2 Flooring replacement	2.0	2	3	1.1.1
1.1.3 Painting and finishing	2.0	3	4	1.1.2
1.1.4 Seating arrangement	1.0	5	5	1.1.3
1.2.1 Electrical point upgrades	2.0	1	2	Site access
1.2.2 Lighting installation	2.0	3	4	1.2.1
1.3.1 Procurement coordination	1.0	1	1	Kickoff + approvals
1.3.2 Access point mounting and wiring	2.0	3	4	1.3.1
1.3.3 Basic configuration and tests	1.0	5	5	1.3.2
1.4.1 Compliance inspection scheduling	0.5	8	8	Completion readiness
1.4.2 Compliance tests and certificates	0.5	9	9	1.4.1 + completed technical works
1.5.4 Final handover package compilation	1.5	10	11	Close to readiness
1.5.5 Lessons learned and close-out	1.0	12	12	Handover draft complete

This table is simplified; real schedules usually break down further and reflect overlap. But in exam tasks, a clear mapping from work package to time window and dependency is what matters.

Costing: From Estimate to Baseline (with Consistent Totals)

Cost estimates should be tied to the WBS so that variances can be traced to root causes. For Case Project A, the baseline budget is ZAR 1,200,000.

A practical cost baseline can be presented as a breakdown by category:

Cost Category	Planned Amount (ZAR)	Percentage of Total
Renovation works (labor + materials)	520,000	43.33%
Electrical improvements (labor + materials + testing)	260,000	21.67%
Wi-Fi installation (hardware + labor + configuration)	230,000	19.17%
Safety and compliance (inspection, certificates, audits)	70,000	5.83%
Project management and closure (planning, reporting, documentation)	60,000	5.00%
Contingency (risk response reserve)	60,000	5.00%
Total Cost Baseline	1,200,000	100%

This table is used later in reporting and variance examples. Consistency is crucial: any future “spent amount” or “remaining budget” must be computed from these baseline numbers.

Cost Control Logic: How Variances Become Management Actions

In practical terms, cost control means:

measuring actual costs,
comparing them to budgeted costs for the work completed,
and deciding whether to replan, request change approval, or execute corrective actions.

Examiners often reward answers that include why cost overruns happen, such as:

scope creep without change approval,
procurement delays increasing labour hours,
rework due to quality failures,
underestimated contingency use.

In Case Project A, a likely risk is delayed Wi-Fi hardware procurement (longer lead time). This can cause:

extended labour time for wiring without hardware to finish configuration,
schedule impact leading to overtime (cost impact),
or change requests to adjust implementation sequence (scope/schedule trade-offs).

In later sections, these ideas will become concrete through risk planning and response strategies.

Section 3: Monitoring, Controlling, Risk, and Change Management (Practical Decision-Making)

Monitoring and controlling are where practical project management differs from academic “planning-only” thinking. Plans rarely survive contact with reality. The skill is not avoiding change; it is managing it systematically while protecting the baseline.

This section covers performance measurement concepts, risk management in practical form, and change control procedures, all anchored in Case Project A.

Monitoring & Controlling: Measuring Progress in a Way That Stakeholders Trust

A practical progress system has to be:

timely,
evidence-based,
understandable to stakeholders.

In campus and public-institution contexts, stakeholders require transparency: why something changed, what the impact is, and what mitigation has been agreed.

Types of progress information in practical reporting

Schedule progress: milestones achieved, activity completion percentages
Cost progress: actual spend vs planned spend, forecast at completion
Quality progress: inspection results, punch-list status, compliance readiness
Risk progress: risk events occurring or near-misses, risk mitigation status
Issue log: blockers, decisions needed, resolution status

Example progress milestone set for Case Project A

Milestone M1 (Week 2): Room preparation complete; procurement approvals for Wi-Fi in place
Milestone M2 (Week 4): Flooring replaced; lighting installation completed
Milestone M3 (Week 5): Seating arranged; Wi-Fi basic configuration completed and connectivity tests passed
Milestone M4 (Week 9): Compliance certificates issued
Milestone M5 (Week 11): Handover package draft completed
Milestone M6 (Week 12): Formal handover and close-out completed

In exam scenarios, if you can show how monitoring relates to these milestones, you demonstrate applied understanding.

Variance Analysis: From Numbers to Actions

Variance is not merely “negative or positive.” It indicates what to do next.

Two key variance types:

Schedule variance: activities behind or ahead of baseline
Cost variance: actual spend different from budget allocated for the planned work

In many project management short-course assessments, learners are expected to at least:

describe variance concepts,
explain likely causes,
and propose corrective or preventive actions.

Practical example: Schedule variance due to procurement delay

Assume that for Case Project A, Wi-Fi access point procurement approved in Week 1 takes longer than expected because a vendor confirms delivery late.

Planned: access points available for installation in Week 3
Actual: access points arrive in Week 4

Impact pathway:

1.3.2 (mounting and wiring) shifts by one week
1.3.3 (configuration and tests) shifts by one week
Compliance readiness (1.4.2 certificates) shifts if Wi-Fi testing is part of sign-off checks
Handover baseline at Week 12 becomes threatened

Corrective actions might include:

accelerating other parallel tasks (e.g., renovation finishing and punch-list closure)
redeploying teams to tasks that are not dependent on Wi-Fi arrival (e.g., 1.1.3 painting and finishing if not already complete)
requesting approval for overtime or additional resources (if within contingency or change control allowances)
updating the schedule baseline after approval (or creating a forecast and management plan)

Risk Management: Identify, Analyse, Plan Responses, Monitor

Practical risk management should be written as a process plus evidence of thoughtful responses.

Risk identification in practical settings

Risk identification should consider:

technical complexity (Wi-Fi configuration),
procurement lead times (vendors),
stakeholder constraints (student access, facilities approvals),
safety and compliance dependencies.

Example risk register entries for Case Project A

Below is a simplified representation focusing on the risks that will be used later.

Risk ID	Risk Description	Probability	Impact	Response Strategy	Owner
R1	Wi-Fi hardware delivery delayed by vendor	Medium	High	Mitigate via alternate vendor inquiry and buffer stock; update schedule forecast; use contingency	Zanele Ndlovu
R2	Electrical testing fails first attempt, causing rework	Low	High	Prevent via pre-checks; have qualified technician on standby	Sibusiso Dlamini
R3	Renovation activities disrupted by facilities access constraints	Medium	Medium	Mitigate via revised work windows; early coordination meetings with Dr Kgomotso Phiri	Thabo Maseko
R4	Safety compliance inspection rescheduled due to inspector availability	Low	Medium	Mitigate by booking inspections early; prepare documentation pack	Martha Khumalo
R5	Scope creep: additional seating rooms requested by students	Medium	Medium	Control via formal change request; validate feasibility and approvals through procurement governance	Nomsa Mokoena

The values (Probability/Impact) represent qualitative categories used in many short-course contexts. The important exam skill is explaining how these responses are designed and how they will be monitored.

Risk Response Planning: Mitigation, Contingency, and Fallback

A practical response often includes:

Preventive actions (reduce probability)
Contingency plans (reduce impact if the risk occurs)
Fallback actions (secondary plan if contingency fails)

For R1 (Wi-Fi delivery delayed), a practical mitigation package could include:

contacting a second supplier early (Zanele Ndlovu)
confirming lead times and delivery schedule in writing
preparing “installation staging” so wiring can be done when hardware arrives
creating a schedule buffer in non-critical tasks

For exam responses, avoid vague phrases like “we will manage risk.” Instead, include:

specific actions,
specific triggers (e.g., “if delivery not confirmed by Week 1 + 2 working days”),
owners with named responsibilities,
and evidence of follow-through (updated risk register entries).

Change Management: Scope Control and the Discipline of Approvals

Change control is where projects often fail. Practical project management requires learners to understand that changes affect:

scope,
time,
cost,
quality,
risk profile.

In Case Project A, consider a realistic change:

Change request CR1: Thandeka Ncube (SRC Liaison) requests adding additional study furniture fittings in two extra rooms to improve accessibility.

Is this automatically approved? No. Practical management requires:

Determine whether it is in scope
Assess impact on schedule and cost
Propose alternatives (e.g., furniture within existing renovation schedule or defer)
Submit to governance for approval (Procurement Committee Chair involvement if procurement impacts)
Update baselines if approved

Impact assessment (structure expected in exams)

A good change assessment includes:

Change description: what exactly changes
Reason for change: stakeholder need, problem statement
Affected WBS elements: which work packages are impacted
Schedule impact: how tasks move
Cost impact: incremental cost and effect on contingency
Quality impact: does it affect compliance requirements
Risk impact: new risks introduced or risk levels increased
Recommended decision: approve/decline/defer with justification

Example cost impact logic for CR1 (kept consistent for total budget discipline)

Suppose:

additional furniture fittings and installation require ZAR 80,000 additional cost
schedule impact requires 1 extra week of labour with additional ZAR 40,000 from labour budget
total incremental cost = ZAR 120,000

Where does this come from?

If baseline contingency is ZAR 60,000, CR1 cannot be absorbed fully without either:
- reducing other scope,
- requesting budget increase (change approval),
- or deferring part of the added work.

This is exactly the type of exam arithmetic that distinguishes strong answers: you connect the incremental cost to the baseline budget structure.

Later sections will explore how reporting and governance support these decisions.

Section 4: Stakeholder Communication, Procurement, Team Coordination, and Risk Reporting

Practical project management is social as well as technical. At TUT—and especially in campus projects—success depends on coordinating people, aligning expectations, managing procurement rules, and reporting progress in a way that decision-makers can act on.

This section focuses on communication planning, procurement workflows, team coordination, and how to report risks and progress.

Communication Planning: Turning Stakeholders into Actionable Recipients

A communication plan is a practical tool that prevents confusion. It specifies:

who needs what information,
when they need it,
in what format,
and who is responsible for sending it.

For Case Project A, a communication plan can be structured as follows:

Communication Type	Audience	Frequency	Format	Owner
Weekly progress meeting	Nomsa Mokoena, Thabo Maseko, Martha Khumalo, Sibusiso Dlamini	Weekly	30–45 min meeting	Nomsa Mokoena
Facilities updates	Dr Kgomotso Phiri	Bi-weekly or as needed	email + short written status	Thabo Maseko
SRC liaison update	Thandeka Ncube	Weekly	short written summary + Q&A window	Nomsa Mokoena
Procurement status	Zanele Ndlovu + Mr Mkhize (as required)	Weekly (until approvals) then bi-weekly	procurement dashboard	Zanele Ndlovu
Risk review	Core team + representatives	Bi-weekly	risk register update	Nomsa Mokoena
Compliance readiness updates	Martha Khumalo + Dr Kgomotso Phiri	Weekly during compliance build-up	checklist status	Martha Khumalo

This plan demonstrates practical thinking: communication is tailored to stakeholder needs and timing.

What makes communication “practical” in exams

Examiners often expect you to:

link communication to project risks (e.g., procurement delays),
show that you adjust frequency when risk levels change,
and define escalation paths for issues.

Escalation and Issue Management

An issue differs from a risk:

A risk may happen; you prepare.
An issue is happening now; you act.

In Case Project A, an issue could be:

“Access to room area is restricted due to an unexpected event,” affecting renovation schedule.

A practical escalation process includes:

Log issue (with description and impact)
Propose immediate mitigation
Determine whether it requires decision/approval
Escalate to appropriate authority (e.g., facilities manager)
Record outcome and update schedule

Example issue log entry (CRITICAL for applied answers)

Issue: Delayed room access window approved by facilities after inspection
Reported by: Thabo Maseko
Impact: Flooring replacement delayed by 2 days
Proposed mitigation: shift painting tasks forward where access is available; reschedule inspection checklists
Escalation required: yes—approval from Dr Kgomotso Phiri
Resolution: update schedule baseline after approval

Procurement Management: Vendor Lead Times and Documentation Discipline

Procurement in practical project management is often a scoring area because it involves process plus governance.

For Case Project A, procurement includes:

Wi-Fi access points and related installation components
renovation materials (flooring, paint, finishing)
electrical components for lighting and points
subcontractors for specialised work (if applicable)

Zanele Ndlovu leads procurement coordination.

Procurement steps learners should be able to describe in exams

Even if your course doesn’t require deep procurement policy memorisation, you should know the practical sequence:

Identify procurement needs from WBS work packages
Prepare procurement documentation (specifications, quantity, timelines)
Obtain approvals required by governance (e.g., Mr Mkhize / procurement committee)
Source and evaluate vendors (price, lead time, compliance)
Place orders with contract terms and delivery dates
Track delivery and manage receipt
Verify quality on receipt and document conformity
Support installation with correct component availability

Practical procurement scenario tied to Case Project A

For R1 (Wi-Fi hardware delivery delayed), procurement must have:

backup supplier options,
documented lead times,
and escalation triggers.

For example:

if supplier confirmation is not received by a certain date,
immediately initiate alternate procurement path (if allowed by governance),
update schedule forecast and stakeholder communication.

Team Coordination: Roles, Dependencies, and Work Packaging

Practical project execution depends on how teams coordinate around dependencies.

Key coordination patterns in Case Project A:

Sibusiso Dlamini’s electrical testing must coordinate with Thabo Maseko’s renovation areas.
Martha Khumalo’s compliance preparation depends on completion of technical testing (electrical tests and Wi-Fi tests).
Nomsa Mokoena coordinates overall schedule and approves change requests and baseline updates.

Resource loading and capacity reality

A common exam expectation is to explain that:

resources have limited capacity,
tasks cannot be compressed infinitely,
and schedule slippage occurs when dependencies and capacity are underestimated.

In practical answers, you can demonstrate understanding by describing:

which tasks can be parallelised safely,
which tasks must be sequential,
and how you reassign work when one activity is blocked.

Risk Reporting: Making Risk Visible to Decision Makers

Risk reporting is part of communication but has its own practical focus:

What changed since last report?
Which risks are material now?
What actions are underway and whether they are working?

In Case Project A, risk reporting should include:

current probability/impact status for each key risk,
mitigation progress for R1–R5,
triggers indicating whether mitigation should escalate,
and any new risks arising from changes.

Example risk update snippet for R1 (Wi-Fi delivery delayed)

Status: Probability increased from Medium to High due to vendor delay confirmation
Impact: schedule risk increased for Week 3–5 installation and compliance readiness
Actions in progress: alternate vendor inquiry initiated; staging works for wiring started using accessible pathways
Decision needed: approval on overtime budget or schedule compression options (if timeline threatened)

This style of reporting earns marks because it shows a cycle:

observe → update risk → decide action → inform stakeholders.

Section 5: Governance, Reporting Artifacts, Exam Answer Strategy, and Integrated Practical Scenarios

Exams often test not only knowledge, but how well you structure your reasoning. This section strengthens the integrated application of concepts—how governance, baselines, documentation, reporting artifacts, and exam answer strategies come together. It also provides a set of integrated scenarios that mirror the type of multi-part questions found in project management short-course assessments.

Governance and Approval Pathways (Why Process Matters)

Governance determines who decides and how decisions are made. In practical environments, governance protects accountability and ensures compliance with institutional rules.

For Case Project A:

Nomsa Mokoena (Project Manager) manages day-to-day decisions within authority.
Mr Mkhize (Procurement Committee Chair) becomes critical when procurement approvals or vendor changes are needed.
Dr Kgomotso Phiri (Facilities Manager) is central for access approvals and operational disruption decisions.
Martha Khumalo (Quality Officer) influences compliance sign-off decisions and inspection scheduling.
Thandeka Ncube (SRC Liaison) ensures stakeholder consultation and escalation of student concerns.

Typical governance activities in practical project management

Approving project charter and baselines (or confirming final acceptance)
Approving change requests with cost/time impact
Reviewing risk register updates
Approving procurement decisions
Confirming handover readiness and acceptance

If you’re writing exam answers, the governance pathway is often what differentiates a “good” answer from a “complete” answer: a complete answer says who must approve what and why.

Reporting Artifacts: What You Must Be Able to Produce in an Assessment

Most practical project management exams expect you to demonstrate understanding of artifacts such as:

status reports,
change requests,
risk register entries,
meeting minutes,
and closure documentation.

Status report structure (practical template)

A practical weekly status report for Case Project A can be structured:

Executive summary
Progress against schedule
Progress against cost baseline
Quality/compliance status
Key risks and issues
Next week plan
Decisions required / escalations

Example: “Executive summary” line items should be specific:

“Renovation rooms are on track for Week 5 seating arrangement.”
“Wi-Fi procurement delay is causing Week 4 installation shift.”
“Compliance inspection booking confirmed for Week 9.”

Change request artifact (what you must include)

For CR1 (additional study furniture fittings in two extra rooms), a change request artifact should include:

requestor and date,
description of change,
reason,
impacted WBS work packages,
cost/time impact,
recommended decision and alternatives,
approvals needed.

Integrated Practical Scenario 1: Procurement Delay and Schedule Forecast

Assume the following event occurs during Case Project A:

In Week 1, Wi-Fi access point procurement approval occurs.
In Week 1 + 2 working days, the vendor confirms delivery is delayed by one week.
This affects planned install start in Week 3; actual available in Week 4.

What an exam question may ask

Identify impacted work packages
Determine schedule impacts (which milestones shift)
Suggest mitigation actions
Explain reporting requirements

Impacts on Case Project A (using fixed milestones)

Work package 1.3.2 shifts from planned Week 3–4 to Week 4–5
Work package 1.3.3 shifts from Week 5 to Week 6
Milestone M3 (Wi-Fi configuration completed and connectivity tests passed) shifts from Week 5 to Week 6
Compliance certificate milestone M4 (Week 9) may remain if compliance can be scheduled independently; however, if compliance sign-off depends on Wi-Fi tests, M4 shifts to Week 10

If compliance sign-off depends on Wi-Fi tests for readiness audit and Martha Khumalo confirms that:

compliance inspection (1.4.2) needs Wi-Fi testing completion,

then M4 shifts by one week to Week 10. That cascades:

M5 (handover package draft) shifts from Week 11 to Week 12
M6 (handover) risks exceeding 12 weeks baseline

Mitigation actions to keep the 12-week target

A practical project manager would consider:

Fast-tracking non-dependent tasks: continue renovation finishing and seating arrangement without waiting for Wi-Fi.
Overlapping tasks where allowed: if wiring staging can proceed in Week 3 (pre-install preparations), keep 1.3.2 partly overlapping.
Resource reallocation: move some team members from blocked tasks to tasks needing labour (e.g., 1.1.3 painting where possible).
Contingency use: if overtime is used, confirm whether contingency is available.
Change control: if the timeline cannot be recovered without significant cost, submit schedule/cost adjustment to governance.

Integrated Practical Scenario 2: Change Request Cost Control Using Baseline and Contingency

CR1 is raised by Thandeka Ncube:

Add additional seating/furniture fittings in two extra rooms.
Incremental cost is ZAR 120,000 as previously defined.
Baseline contingency is ZAR 60,000.

What the arithmetic means

If the project uses contingency (ZAR 60,000), the remaining incremental cost is:
- ZAR 120,000 – ZAR 60,000 = ZAR 60,000
Since the contingency is fully consumed, additional funds must come from:
- reallocation from other cost categories (scope reduction elsewhere), or
- approved budget increase (change approval), or
- deferring part of the change to a later phase (scope adjustment)

What to write in an exam answer

A strong answer should include:

acknowledgement of baseline and contingency constraints,
identification of decision options,
recommendation based on likely governance feasibility.

If the procurement committee and facilities management require evidence of affordability and schedule feasibility, you can recommend:

approve furniture for only one extra room immediately,
defer the second room to Phase 2 (if allowed),
and update the WBS and schedule accordingly.

Integrated Practical Scenario 3: Risk Escalation Trigger and Updated Risk Register

Consider risk R1 (Wi-Fi hardware delivery delayed). A trigger might be:

“If delivery confirmation is not received by the end of Week 1, escalate probability from Medium to High and initiate alternative vendor inquiry.”

At Week 1 + 2 working days:

probability becomes High.

An exam question may ask:

how the risk response changes,
what reporting should occur,
who must approve any extra actions (e.g., expediting procurement might require Mr Mkhize’s approval).

A practical answer:

Update probability/impact in risk register
Execute mitigation: alternate vendor inquiry (if policy allows)
Notify stakeholders: update SRC and Facilities on likely installation shift
Update schedule forecast and baselines if needed
Record decisions and actions in the risk/issue logs

How to Answer TUT-Style Practical Project Management Exam Questions

TUT learners are often assessed through applied problems: scenario-based tasks with marks allocated to each part. To maximise marks, use a consistent structure in responses.

A high-scoring exam answer template (use where appropriate)

State the relevant concept (1–2 lines)
Apply to the scenario (named work packages, roles, stakeholders)
Use correct tools (WBS, risk register, change request, schedule baseline)
Provide impacts with numbers (cost/time) if asked
Recommend actions and approvals (who decides, what changes)
Conclude with next steps (what happens next week)

Common marking patterns and how to beat them

Marking pattern: definition-only answers
- Fix: always connect definition to deliverables, baselines, or decisions.
Marking pattern: no stakeholder or governance pathway
- Fix: explicitly name which stakeholder must approve or be informed.
Marking pattern: no arithmetic where costs/time are requested
- Fix: show computation using baseline numbers (e.g., contingency, ZAR 1,200,000 total).
Marking pattern: no “why” behind recommendations
- Fix: explain how recommendation protects schedule/cost/quality.

Consolidated Key Numbers and Baseline Data (For Exam Quick Recall)

To make exam revision efficient, here are the fixed Case Project A numbers and targets used consistently in these notes:

Total project duration target: 12 weeks
Cost baseline (total): ZAR 1,200,000
Contingency reserve: ZAR 60,000 (part of the baseline)
Key milestones:
- M1 Week 2
- M2 Week 4
- M3 Week 5 (or shifts to Week 6 if Wi-Fi delay persists)
- M4 Week 9 (or shifts to Week 10 if Wi-Fi testing required for compliance)
- M5 Week 11 (or shifts correspondingly)
- M6 Week 12 (handover)

Using these numbers consistently in your exam answer demonstrates disciplined understanding.

University Course Keyword Alignment (South African Project Management Learning Context)

South African learners often search for project management practical study material under course codes and module names such as those aligned to TUT and peer institutions. While this study pack is tailored to TUT Short Course in Practical Project Management Study Pack learning emphasis, it is also consistent with the knowledge learners typically need in modules like:

TUT project management and operations modules focused on scheduling, budgeting, monitoring, and risk/control.
University-aligned project management courses at South African institutions that use scenario-based assessments requiring:
- WBS breakdowns,
- schedule and dependency reasoning,
- cost baseline and variance control,
- risk register updates,
- and change request governance.

When preparing for exams, learners commonly need to connect their studying to the same core skill categories regardless of the institution’s exact course code naming.

Checklist: What to Practise Before the Exam

Use this checklist to guide your last-week revision on practical project management:

Can you produce a WBS breakdown from deliverables into work packages?
Can you explain dependencies and build a schedule logic for a 12-week target?
Can you create a cost baseline and show category totals that sum to the correct total (ZAR 1,200,000)?
Can you demonstrate variance reasoning (what happens when procurement delays occur)?
Can you write a risk register entry with owner, response strategy, and monitoring trigger?
Can you create a change request with WBS impact, cost/time impact, and approval decision logic?
Can you outline a communication plan with stakeholder-specific frequency and format?
Can you explain how governance and approvals change your recommended action?

Final Integrated Revision Practice (Mini-Case Answers You Should Be Able to Draft)

To ensure you can transfer this learning to exam settings, practise drafting short answers for each mini-case in Case Project A:

Draft a change request impact section for CR1 (ZAR 120,000 incremental cost) explaining what happens given contingency of ZAR 60,000.
Draft a mitigation plan for R1 explaining what actions are taken if Wi-Fi delivery shifts from Week 3 to Week 4.
Draft a weekly status report executive summary mentioning progress, key risks (R1), quality/compliance status, and next week priorities.
Draft a risk escalation rationale showing trigger logic and updated risk register probability/impact.
Draft a governance recommendation: approve/decline/defer a scope change and justify based on schedule/cost constraints.

These drafts are where practical understanding becomes exam performance.

Summary

This study pack provided an exam-focused, practical framework for the TUT Short Course in Practical Project Management, grounded in a consistent running case (Tshwane Library Upgrade) and using fixed numerical baselines (12-week duration and ZAR 1,200,000 total budget) throughout. You learned how to translate scope into a measurable WBS, build schedule logic with dependencies, baseline costs with contingency discipline, and apply monitoring, risk management, and change control as decision-making systems. Finally, you strengthened stakeholder communication, procurement coordination, governance pathways, and exam answer strategies that help convert knowledge into marks.

If you revise using the checklist and practise drafting mini-case artifacts (WBS, schedule impacts, risk updates, change requests, and status summaries), you will be positioned to answer both calculation-and-logic questions and scenario-based practical project management questions with confidence.