Project Management I (PJM105X) Exam Study Guide (TUT) — TUT Project Management Course Notes

Project Management I (PJM105X) is typically assessed around core planning, executing, controlling, and closing activities—plus the fundamentals of project scope, time, cost, risk, procurement, and quality. This study guide is designed to help you interpret exam-style questions, apply standard terminology, and work through typical calculations and scenarios you’re likely to see in PJM105X at Tshwane University of Technology (TUT). Use it as a structured revision pack: focus on the exam workflows, master the “what to do and why,” and practise converting theory into answers.

1) Project Fundamentals and the Project Life Cycle (PJM105X Core Concepts)

Project management is not just “making a plan.” In PJM105X, you’re expected to understand how projects are defined, how they differ from operations, how stakeholders shape outcomes, and how the project life cycle provides structure from start to finish. Many exam papers test whether you can correctly identify: project vs. business-as-usual, phase vs. process, and deliverables vs. activities.

1.1 What Is a Project? (and What It Is Not)

A project is a temporary endeavour undertaken to create a unique product, service, or result. “Temporary” does not mean “short”—it means it has a definite start and finish. “Unique” is the key: even if you’ve done similar work before, the project outcome is not identical to previous outcomes.

In contrast, operations are ongoing and repetitive. Operations aim at maintaining and running an organisation (e.g., daily customer support, routine manufacturing). Exam questions often phrase a scenario and ask you whether it’s a project. A quick test:

Has a defined start and end?
Does it produce something unique?
Is it constrained by time, cost, and scope?
Does it require coordination of multiple activities and resources?

If you answered “yes” to these, it’s likely a project.

Example scenario (exam-style):
“Tshwane University of Technology upgrades a computer lab from 50 PCs to 80 PCs and introduces new software within 6 months.”
This is a project because:

it has a start (approval to upgrade) and end (lab upgrade completion),
it creates a unique outcome (upgraded lab capacity and installed software),
it is constrained by a deadline and budget.

1.2 Projects vs Programmes vs Portfolios

Exams sometimes include definitions:

Project: Temporary, unique deliverable.
Programme: A group of related projects managed in a coordinated way to obtain benefits not achievable from managing projects individually. A programme focuses on outcomes and benefits.
Portfolio: A set of projects and programmes grouped to meet strategic objectives.

A typical confusion: students may call everything a “project.” PJM105X expects correct differentiation.

Illustration:

Project: “Install fibre internet in Building A.”
Programme: “Improve digital learning infrastructure across multiple campuses.”
Portfolio: “All technology transformation initiatives across TUT.”

1.3 Stakeholders and Their Role in Projects

A stakeholder is any person, group, or organisation that can affect or be affected by the project. PJM105X commonly tests:

stakeholder identification,
stakeholder expectations,
how stakeholder engagement changes across phases.

Common stakeholder categories include:

Project sponsor: provides funding, ensures alignment with strategy.
Project manager: plans, coordinates, manages execution and controls.
Customer / end user: defines requirements, accepts deliverables.
Functional managers: supply resources (and may compete for capacity).
Project team: performs work packages.
Contractors / suppliers: deliver goods/services.
Regulators / authorities: ensure compliance.
Community / public: affected by impacts (noise, traffic, safety).

Exam tip: When asked “Who should be involved?” you answer by referencing stakeholders and their interest/impact, not just job titles.

1.4 Project Life Cycle: Phases from Initiation to Closure

Most project life cycles have similar elements:

Initiation / Concept
Planning
Execution / Implementation
Monitoring & Controlling
Closing

Note the distinction:

Processes describe management activities (planning, controlling, executing).
Phases divide a project into segments, usually with deliverables and decisions.

A life cycle often includes a phase gate: decisions at the end of each phase to proceed, modify, or stop.

Typical exam deliverables by phase:

Initiation: project charter, business case, high-level scope
Planning: baseline plan (scope, schedule, cost), risk plan, quality plan
Execution: approved work packages done, progress reporting
Monitoring & controlling: variance tracking, change control, risk updates
Closing: acceptance, final documentation, lessons learned

1.5 Project Success: Triple Constraint + Beyond

A classic success measure is the triple constraint:

Scope
Time
Cost

Exams sometimes ask for “other factors.” These include:

quality,
stakeholder satisfaction,
compliance and safety,
benefits realisation (did it achieve the purpose?).

Counter-argument to triple constraint:
Projects can “finish on time and budget” but still fail if they deliver the wrong outcome or unacceptable quality. Hence, PJM105X may emphasise both efficiency (time/cost) and effectiveness (meeting requirements and benefits).

1.6 The Project Charter: Why It Matters

A project charter authorises the project and provides high-level direction. It typically includes:

project purpose / justification,
measurable objectives (sometimes high-level),
high-level requirements,
high-level risks,
summary milestones,
stakeholder list (sometimes),
authority of the project manager (or governance structure).

Exam-style explanation: If you’re asked why charter exists, answer:

it gives legitimacy,
aligns sponsor expectations,
sets a starting point for detailed planning,
helps prevent “scope drift” by anchoring goals.

2) Scope, Work Breakdown Structure (WBS), Scheduling, and Estimation

A large portion of PJM105X exams revolves around translating project intent into structured planning outputs. If you can build a clear scope definition, create a WBS, estimate duration/cost realistically, and create a logical schedule, you can answer many question types.

2.1 Scope Management: Scope, Requirements, and Deliverables

Scope management ensures the project includes all the work required and only the work required to complete deliverables.

Key terms you may be tested on:

Project scope: work included in the project.
Product scope: features and functions of the final deliverable.
Requirements: what must be met (e.g., performance, usability, standards).
Deliverables: tangible outputs produced by the project (e.g., “approved design document,” “installed network,” “training completed”).

A common exam question asks: “What is scope creep?”
Scope creep is the uncontrolled expansion of scope without adjustments to time, cost, or resources. It often happens due to:

unclear requirements,
stakeholder changes without formal change control,
poor communication.

2.2 Defining Scope: From High-Level Objectives to Detailed Requirements

A strong scope definition typically uses:

stakeholder input (customer needs),
analysis of requirements,
constraints (budget, deadline, policy),
assumptions (what you believe to be true),
exclusions (what is explicitly not included).

Example (scope statement logic):
If TUT is upgrading a lab:

included: hardware purchase, installation, configuration, basic user training
excluded: redesign of curriculum content (handled by academic department)

When exams ask “Why should you write exclusions?”: to reduce ambiguity and prevent scope creep.

2.3 Work Breakdown Structure (WBS): Turning Scope into Work Packages

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope into smaller components until you reach work packages that can be estimated, scheduled, and monitored.

WBS purpose in exams:

clarifies scope,
provides a structure for estimating,
supports cost and schedule control,
improves accountability.

WBS is typically organised by a numbering system, such as:

1.0 Project Management
2.0 Planning
3.0 Installation
4.0 Training
5.0 Close-out

Then each level is broken down further. At the lowest level, you get work packages, which usually have:

defined deliverables,
start/end dates (or planned period),
cost estimates,
assigned responsibility.

2.4 Building a WBS from a Scenario: Practical Method

When you encounter a scenario in an exam, use a repeatable approach:

Identify deliverables (what must be produced).
Group deliverables logically (by phase, by discipline, or by major output).
Decompose each deliverable into activities/work packages.
Check completeness: does everything in the scope statement appear?
Check “no overlaps / no gaps”: work packages should not duplicate or omit.

Illustration scenario:
“Upgrade campus Wi-Fi in Building C. Deliverables include: (a) procurement of access points, (b) installation, (c) configuration/testing, (d) documentation, (e) staff training.”

A WBS could look like:

1.0 Project Management
- 1.1 Project governance meetings
- 1.2 Reporting and stakeholder updates
2.0 Procurement
- 2.1 Access point sourcing and ordering
- 2.2 Cable/ancillary items procurement
3.0 Installation
- 3.1 Site survey
- 3.2 Mounting access points
- 3.3 Cabling and power setup
4.0 Configuration & Testing
- 4.1 Network configuration
- 4.2 Security settings and password rollout
- 4.3 Performance tests (signal coverage, throughput)
5.0 Documentation & Training
- 5.1 Technical documentation
- 5.2 Staff training sessions
6.0 Close-out
- 6.1 Handover/acceptance
- 6.2 Lessons learned report

Exams sometimes ask: “What is the benefit of a WBS numbering system?”
Answer: it provides a clear reference, supports tracking, and enables accurate roll-up of costs and schedules.

2.5 Estimation Techniques: From Expert Judgment to Ranges

PJM105X may include estimation methods such as:

Analogous estimation: using past similar projects to estimate cost/duration.
Parametric estimation: using statistical relationships (e.g., cost per access point).
Bottom-up estimation: estimate each work package then sum.
Three-point estimation: often associated with uncertainty ranges.

You should be able to explain when to use each and why.

Analogous estimation example:
If a previous lab upgrade installed 50 devices in 4 weeks and cost a certain amount, you may estimate 80 devices by scaling with a factor—though you adjust for differences in complexity.

Bottom-up estimation example:
Estimate time for each work package:

site survey: 2 days
mounting: 5 days
cabling: 4 days
configuration: 3 days
Total duration depends on dependencies (see scheduling below).

2.6 Scheduling Basics: Dependencies and Critical Path Thinking

Scheduling converts work packages into a timeline. Exams often test:

dependencies: finish-to-start, start-to-start, finish-to-finish, start-to-finish
critical path concept: the longest path determining project duration
float/slack: time flexibility without delaying completion

Even if the course doesn’t require advanced CPM calculations, exam questions may use critical path reasoning in simplified form.

2.7 Gantt Charts and Network Diagrams

A Gantt chart is a visual schedule showing activities along a time axis. Benefits:

easy to communicate,
shows start and finish dates.

A network diagram (activity-on-node or activity-on-arrow) shows dependencies and can be used to find critical path.

Exam-style question:
You may be asked to choose between a Gantt chart and network logic, especially when dependencies exist. If tasks can’t start until another finishes, network logic is more precise.

2.8 A Worked Scheduling Example (Exam Calculation Style)

Suppose you have these activities (duration in days):

Activity	Description	Predecessor(s)	Duration (days)
A	Procurement	None	4
B	Installation	A	6
C	Configuration	B	3
D	Testing	B	2
E	Training	C	2
F	Documentation	C	2
G	Close-out	D, F	1

Step 1: Determine earliest start/finish (simplified).

A: start 0, finish 4
B: start 4, finish 10
C: start 10, finish 13
D: start 10, finish 12
E: start 13, finish 15
F: start 13, finish 15
G: depends on D and F → start max(12,15)=15, finish 16

Step 2: Project duration = 16 days.
The critical path here is A → B → C → F/G (or A → B → C → G depending on which branch drives the final step). Since G waits for F (15) and D (12), F is critical.

Why this matters for exams:
Questions often ask which activity has the greatest impact on completion date. The activity(s) on the critical path have the highest impact: delaying them delays the project.

2.9 Estimation vs Scheduling: Avoiding Two Common Mistakes

Mixing up effort with duration.
- Effort (person-days) isn’t always equal to calendar duration if you have multiple people working in parallel.
Ignoring dependencies.
- Two tasks may have short individual durations but still produce a long project due to waiting constraints.

3) Time, Cost, Quality, Risk, and Resource Management

This section connects planning to control. Exams frequently test your ability to:

relate schedule to cost,
manage quality systematically,
identify and respond to risks,
allocate resources realistically and avoid overloading.

3.1 Time Management: Baselines, Monitoring, and Variance

A schedule baseline is a time plan approved at a point in time. During execution, you track:

planned start/finish vs actual start/finish,
progress percentages,
milestones reached.

Variance occurs when actual progress deviates from plan. Common reasons include:

scope changes,
contractor delays,
procurement lead time differences,
poor estimation.

Exam-style explanation:
If a milestone slips, it can have cascading impacts:

additional labour costs,
penalty clauses (if any),
stakeholder dissatisfaction,
downstream tasks needing re-planning.

3.2 Cost Management: Budgeting and Cost Control

Typical cost categories in project management:

direct labour,
materials,
equipment,
subcontractor costs,
travel and expenses,
overheads (sometimes allocated).

Cost control involves:

tracking actual costs,
forecasting final costs,
managing changes and approved variations.

Even when PJM105X doesn’t require advanced Earned Value Management (EVM), you should understand the logic of comparing planned vs actual vs budgeted progress.

3.3 A Practical Mini-Scenario: Budgeting and Forecasting

Assume a Wi-Fi upgrade has an approved budget breakdown:

Procurement: R120,000
Installation labour: R80,000
Configuration/testing: R45,000
Training & documentation: R30,000
Project management contingency: R25,000

Total budget = R300,000.

If after the first 40% of the project:

actual spending is R130,000,
but only 30% of deliverables are completed (based on milestone progress),

then your implied burn rate and schedule efficiency require attention. Exams might ask: “What should the project manager do first?”
Your answer should include:

check whether scope drift occurred,
verify measurement of progress (is progress assessment accurate?),
review procurement lead time and installation productivity,
propose corrective actions (e.g., re-sequence tasks, add temporary resources, request schedule adjustment with sponsor).

3.4 Resource Management: People, Skills, and Constraints

Resource management addresses the reality that resources are limited. In university project management scenarios, common resources include:

engineers/technicians,
project manager and support staff,
procurement/administration,
IT security staff,
trainers.

Typical exam themes:

availability: when staff can work,
skills: who can do which tasks,
capacity: how many tasks can be done concurrently,
allocation: assigning resources to work packages.

Common problem:
A schedule plan may assume unlimited labour. When a real team has constraints, you may:

use parallel work only when dependencies allow,
reassign team members,
adjust deadlines (in negotiation with stakeholders),
reduce scope (only through formal scope change).

3.5 Quality Management: Quality Planning, Assurance, and Control

Quality in project management is about meeting requirements and expectations. You may be asked to distinguish:

Quality planning: define standards and how you will achieve them.
Quality assurance: systematic activities to provide confidence that quality requirements will be met.
Quality control: operational techniques to check deliverables meet standards.

Example:
For Wi-Fi:

Quality standards could include minimum signal coverage, latency targets, and security configuration checks.
Quality assurance could include documented procedures, peer reviews, and audit of installation steps.
Quality control could involve performance testing and acceptance checklists.

3.6 Acceptance Criteria and Compliance

Exams often test “acceptance.” Acceptance criteria specify what must be true for stakeholders to accept deliverables. It may include:

performance thresholds,
documentation completeness,
compliance with policies (safety, IT governance, licensing),
training completion (e.g., attendance and competency checks).

A deliverable that is “done” by the contractor may still be rejected if it fails acceptance criteria.

3.7 Risk Management: Identify, Analyse, Plan Responses, Monitor

Risk is the effect of uncertainty on objectives. A risk has:

a cause (uncertainty source),
an event (what might happen),
an impact (effect on time/cost/scope/quality),
a probability and consequence.

Risk management process:

Identify risks
Analyse risks (qualitative or quantitative)
Plan responses
Implement responses
Monitor risks and update register

3.8 Qualitative Risk Analysis: Probability–Impact Matrix

A common exam method is a probability-impact matrix. For each risk you rate:

Probability (low/medium/high)
Impact (low/medium/high)

Then you get risk priority.

Example risk register snippet:

Risk	Probability	Impact	Priority	Potential Response
Access points delayed	Medium	High	High	Use alternative supplier, expedite shipping, adjust schedule
Network configuration fails security tests	Low	High	Medium/High	Test in staging environment, involve security team early
Training attendance low	Medium	Medium	Medium	Schedule multiple sessions, communicate early

Even if the course uses simplified scoring, the logic remains: high probability + high impact = high priority.

3.9 Risk Responses: Avoid, Mitigate, Transfer, Accept

Exam questions may ask which response matches a given risk:

Avoid: change plan to eliminate risk (e.g., choose already-available components to avoid lead-time risk).
Mitigate: reduce probability or impact (e.g., contingency buffer, early procurement).
Transfer: shift impact to another party (e.g., insurance, fixed-price contract, SLA penalties).
Accept: acknowledge risk and prepare contingency if it happens.

Counter-example:
“Accept” doesn’t mean “do nothing.” It means you track it and have contingency triggers.

3.10 Risk Triggers and Contingency Planning

Good risk planning includes:

trigger conditions (what indicates risk is materialising),
contingency actions,
contingency reserves (time and cost).

Example:
Risk: “Supplier delivery delay.”
Trigger: “Supplier confirms shipping moved by 2 weeks.”
Contingency: “Switch to alternate supplier for part of the order and re-baseline installation start date.”

3.11 Integrating Risk with Schedule and Cost Baselines

A key exam skill is explaining why risk planning affects baselines. If you plan:

mitigation tasks (like early testing) you add schedule elements,
contingency reserves you add cost/time buffers.

If you do not integrate, you may discover too late that the original baseline cannot hold.

4) Procurement, Contract Management, Change Control, and Communication

Project success depends heavily on managing external inputs (procurement and contractors), controlling changes, and communicating with stakeholders. PJM105X commonly assesses these managerial behaviours through scenario questions.

4.1 Procurement Planning: What to Buy and How

Procurement planning decides:

what items/services to acquire externally,
how to acquire them (tender, quotes, negotiated contract),
contract type,
evaluation criteria,
timeline and lead time assumptions.

Procurement is often constrained by:

vendor availability,
delivery lead times,
compliance requirements,
budgeting rules.

Exam-style logic:
If an item is critical path (e.g., access points), then procurement lead time is a major schedule driver.

4.2 Contract Types: Understanding Trade-offs

Common contract types include:

Fixed-price contract: contractor delivers for a fixed amount; contractor bears most cost risk.
Cost-reimbursable contract: you reimburse contractor for allowable costs; client bears more risk.
Time-and-materials: pay for time and materials; risk is shared and must be controlled with rates and limits.
Unit-price contract: pay per unit; good when quantities can vary but unit costs are stable.

Exams may ask: “Which contract type is suitable when scope is unclear?”
Often, fixed price can be risky for contractor if scope changes significantly; you may choose contracts that reflect uncertainty. Your answer should tie back to risk allocation.

4.3 Procurement Documents: The Big Picture

Procurement typically uses documents such as:

specifications (what you need),
terms of reference or scope of work (what contractor will do),
SLA (if applicable),
evaluation criteria,
contract conditions (payment terms, warranties, delivery schedule, penalties).

A recurring exam theme: unclear specifications lead to disputes, rework, and schedule delays.

4.4 Contract Management: Monitoring Contractor Performance

Once a contractor is appointed, you manage performance via:

milestones and deliverables,
progress reports,
quality checks,
invoice verification,
compliance audits,
issue resolution.

A well-managed contract includes:

clear acceptance criteria,
reporting frequency,
escalation paths.

4.5 Change Control: Managing Scope, Time, Cost Changes

Change control ensures modifications are evaluated and approved before they disrupt the project. Steps usually include:

Request change (change request form)
Analyse impact (scope/time/cost/quality/risk)
Decide (approve, reject, or request further info)
Implement if approved
Update baselines and documents

Exam-style answer requirement:
If asked “What is the first step?”: the process begins with a formal change request, not with informal “go ahead.” Informal changes are how scope creep happens.

4.6 Change Impact Analysis: What You Must Consider

When analysing change, consider:

Schedule impact: which activities change, delays in critical path, new milestones
Cost impact: additional labour/materials/contractor variation orders
Quality impact: does it meet acceptance criteria?
Risk impact: does uncertainty increase?
Stakeholder impact: who is affected, are expectations updated?

Example:
Customer requests adding extra access points beyond original plan.

Schedule: procurement of additional units can take time.
Cost: additional hardware and installation labour required.
Quality: potential improvement in coverage but must pass security/performance tests.
Risk: more components increases failure points.

4.7 Communication Management: Planning for Information Flow

Communication management determines:

who needs what information,
how frequently,
through which channels (meetings, reports, email, dashboards),
how issues and decisions are documented.

Common communication types:

status reports (progress vs plan),
milestone reports (achieved/forecast),
risk reports,
change logs,
meeting minutes and decision registers.

Exam-style scenario:
If stakeholders complain they “didn’t know,” your answer should include:

deficiencies in communication plan,
lack of stakeholder engagement,
missing reporting cadence,
unclear decision escalation.

4.8 Stakeholder Engagement: Tailoring Messages

Not all stakeholders need the same details:

Sponsor: budget and milestone alignment, benefits, major risks
End users: usability, training schedule, acceptance readiness
Team members: task breakdown, dependencies, priorities
Contractors: deliverables, quality requirements, payment milestones

Good stakeholder communication supports:

timely decisions,
reduced misunderstandings,
improved acceptance of deliverables.

4.9 Issue Management vs Change Control

Students sometimes confuse issues and changes:

Issue: a current problem that must be resolved (e.g., contractor missed a deadline).
Change: a modification to baseline scope/schedule/cost requirements.

In practice, an issue can sometimes lead to a change request (e.g., rework due to a design error).

Exam approach:
When asked what to do, first identify whether it’s an issue to resolve immediately, or a change needing formal approval.

5) Exam Practicals: Applying PJM105X Knowledge to Scenarios, Questions, and Common Calculations

This section synthesises the previous concepts into exam-ready practice. The emphasis is on how to structure answers: identify key variables, use correct terminology, show steps in calculations, and provide “why” reasoning.

5.1 How PJM105X Exam Questions Are Usually Structured

While each paper differs, PJM105X problems commonly fall into patterns:

Definitions and short theory answers
- project vs operations
- stakeholder roles
- WBS purpose
- risk definition and response types
Scenario interpretation
- identify scope creep risks
- decide what should happen in change control
- identify procurement risks and quality impacts
Planning and breakdown questions
- build a mini-WBS from a deliverables list
- select appropriate estimation method
Scheduling and dependency questions
- compute earliest finish times in a simplified network
- identify critical path reasoning
Cost and budgeting questions
- compute totals and explain what budgets include
- forecast based on progress measurement (qualitative logic)
Risk management questions
- fill a risk register with probability/impact and responses

5.2 Writing High-Scoring Answers: A Repeatable Structure

For theory/scenario questions, use a structure aligned to marking guides:

Define the key term (1–2 sentences)
Apply it to the scenario (2–4 sentences)
Justify with a reason (why it matters)
Provide an actionable recommendation (steps)

Example (risk definition question):

Definition: “A risk is uncertainty affecting objectives.”
Scenario: “In the procurement scenario, supplier delays are uncertainty impacting schedule.”
Why it matters: “Schedule slippage increases costs and affects downstream tasks.”
Action: “Mitigate by alternative supplier and early ordering.”

This method avoids vague answers and signals understanding.

5.3 Mini-WBS Construction Exam Practice

Scenario:
TUT needs to organise a short professional training programme for staff. Scope includes:

develop training materials,
book a venue and equipment,
deliver two training sessions,
conduct evaluation surveys,
produce a completion report.

Task: Build a WBS with at least 4 main branches and 2 work packages under each.

A strong WBS response:

1.0 Project Management
- 1.1 Project planning and scheduling
- 1.2 Reporting and stakeholder management
2.0 Training Material Development
- 2.1 Develop slides and handouts
- 2.2 Review content and finalise
3.0 Venue, Equipment, and Logistics
- 3.1 Book venue and arrange equipment
- 3.2 Prepare room layout and tech checks
4.0 Training Delivery
- 4.1 Deliver Session 1
- 4.2 Deliver Session 2
5.0 Evaluation and Reporting
- 5.1 Conduct evaluation surveys and compile results
- 5.2 Produce completion report and handover

Why this scores well:
It converts deliverables into manageable work packages that can be estimated and scheduled.

5.4 Scheduling Questions: Dependency Reasoning and Critical Path

Scenario:
You must complete a small IT security rollout with activities:

A: Security policy review (2 days)
B: Configure devices (4 days) depends on A
C: User training (3 days) depends on B
D: Post-deployment testing (2 days) depends on B
E: Final sign-off (1 day) depends on C and D

Task: Determine total project duration.

Solution logic:

A runs first: finishes at day 2.
B runs next: finishes at day 2 + 4 = day 6.
C finishes at day 6 + 3 = day 9.
D finishes at day 6 + 2 = day 8.
E depends on both C and D, so start after max(day 9, day 8) = day 9; finish at day 10.

Total duration = 10 days.

Exam writing tip:
Show the dependency chain and the max() reasoning for the final activity.

5.5 Cost Questions: Totals, Budgets, and Simple Variance Logic

Scenario:
A project budget is planned as:

Labour: R60,000
Materials: R25,000
Subcontractor: R40,000
Travel/expenses: R5,000

Task 1: Calculate the total budget.
Total = 60,000 + 25,000 + 40,000 + 5,000 = R130,000

Task 2 (variance logic):
After spending R78,000, only two of five major deliverables are completed. What does this suggest?
Two of five = 40% completed (if progress is truly proportionate). Spending R78,000 out of R130,000 = 60% spent. That suggests potential inefficiency or schedule slippage, or that progress measurement may be inaccurate.

Actionable recommendation:

verify progress measurement and deliverable completion,
compare schedule baseline vs actual,
identify root cause (labour productivity, procurement delay, rework).

5.6 Risk Register Practice with Coherent Responses

Scenario:
For a procurement-heavy project, identify and manage risks. Provide at least 3 risks with probability, impact, and response.

A sample high-quality answer:

Risk: Supplier delivery delayed
- Probability: Medium
- Impact: High
- Response: Mitigate (early ordering, alternative suppliers), add contingency time buffer
Risk: Deliverables fail quality tests (e.g., missing configuration requirements)
- Probability: Low
- Impact: High
- Response: Mitigate (test in staging, involve quality lead early), ensure acceptance criteria checked before handover
Risk: Stakeholders request scope changes during execution
- Probability: Medium
- Impact: Medium/High
- Response: Avoid/Mitigate (clear scope statement, stakeholder engagement, formal change control)

Why coherence matters:
Your response should match the risk. If you choose “avoid,” explain what plan change eliminates the risk rather than merely acknowledging it.

5.7 Change Control Scenario: Choosing Correct Steps

Scenario:
Midway through a project, the sponsor requests additional features that were not in the original scope. The team wants to “just implement it quickly.”

Task: Explain the correct change control steps and the key analysis elements.

Answer structure:

Submit change request detailing the requested features.
Assess impact on scope, time, cost, quality, and risk:
- schedule: which tasks are affected, dependency impacts
- cost: additional labour/materials/contractor cost
- quality: whether new features meet acceptance criteria
- risk: increased complexity, procurement lead time changes
Decision by authorised authority (sponsor/steering committee).
If approved, update baselines and communicate changes.
If rejected, document rationale and manage expectations.

Exam insight:
If the team starts implementing without approval, they risk scope creep and “orphan work” that can’t be funded or scheduled properly.

5.8 Quality and Acceptance Scenario: Avoiding Wrong “Done” Assumptions

Scenario:
A contractor claims the lab upgrade is complete, but key components are missing documentation and performance testing hasn’t been performed.

Task: Explain why the deliverable may not be accepted.

Answer reasoning:

Acceptance criteria include documentation completeness and performance verification.
Quality control ensures operational checks and compliance with standards.
Without testing and complete documentation, the deliverable does not meet requirements and should be rejected or require rework.

This demonstrates understanding of quality planning, assurance, and control.

5.9 Procurement Scenario: Identifying Lead-Time and Compliance Risks

Scenario:
Procurement is delayed due to compliance checks for imported equipment. The team didn’t account for the clearance time in the schedule.

Task: Identify risks and suggest improvements.

Answer:

Risk: import compliance delay (probability medium, impact high)
Mitigation:
- include lead time and compliance steps in the schedule (integrate procurement tasks)
- start clearance early
- use approved vendors and maintain documentation
- consider contract terms addressing delivery timelines

This connects procurement planning directly to schedule realism.

5.10 Comprehensive Example: Putting It All Together (One Coherent Project)

To practise integration—often tested implicitly—consider a coherent mini-project: “Building C Wi-Fi Upgrade” with the following planned cost categories (consistent with earlier examples):

Procurement: R120,000
Installation labour: R80,000
Configuration/testing: R45,000
Training & documentation: R30,000
Project management contingency: R25,000

Total budget = R300,000.

Assume the high-level plan includes:

Initiation: charter and approval gate
Planning: WBS, schedule, procurement plan, risk register, quality plan
Execution: procurement, installation, configuration, testing, training
Monitoring & controlling: progress tracking, risk updates, change control
Closing: acceptance and lessons learned

Now answer common exam sub-questions:

(a) Identify the most likely source of scope creep

Scope creep likely comes from stakeholder requests for additional coverage areas or extra configuration features without formal change control. If acceptance criteria were unclear initially, changes become harder to evaluate.

(b) Explain how quality is controlled

Quality control includes performance tests (coverage and throughput), security checks, and an acceptance checklist signed by customer representatives. Quality assurance includes documented procedures and peer reviews of configuration steps.

(c) Recommend a risk response for supplier delays

Mitigate by early procurement, alternative suppliers, and contingency time buffers. If delays are significant, re-plan schedule baselines after change control approval.

(d) Show how a change request affects baselines

If the sponsor requests additional access points:

scope increases (new deliverables),
schedule may shift procurement and installation tasks,
costs increase beyond R300,000 unless contingency is used or budget is reapproved,
risk may increase due to extra complexity and testing requirements.

This example shows that PJM105X is about system thinking: project management processes connect.

Summary of Key PJM105X Exam Themes (Revision Checklist)

Use this checklist to guide last-minute revision and exam readiness:

Project vs operations: defined start/end and unique deliverable
Stakeholders: map who influences and who is affected; tailor communication
Life cycle: initiation → planning → execution → monitoring/control → closing
Scope management: define included/excluded work; prevent scope creep via change control
WBS: break down scope into work packages for estimation, scheduling, and control
Estimation: analogous, parametric, bottom-up; choose based on uncertainty and available data
Scheduling: dependencies matter; use earliest start/finish reasoning and critical path logic
Cost management: budgets by categories; track spending vs progress; forecast impacts
Quality: planning vs assurance vs control; rely on acceptance criteria
Risk: identify → analyse → respond → monitor; use probability/impact logic
Procurement: specify clearly; manage lead times and contractor performance
Change control: request → analyse impact → decide → update baselines → communicate

Quick Notes on How to Practise for PJM105X (Aligned to TUT Exam Style)

To improve marks efficiently, practise with a mix of:

definition questions (short and precise),
scenario-based “what should the project manager do?” questions,
WBS building tasks from deliverables,
simplified network/scheduling exercises,
risk register entries (probability, impact, response),
change control walkthroughs.

A high-performing student approach is to write structured answers consistently, using the same logic chain every time:

define, 2) apply to scenario, 3) justify, 4) propose actions with steps.

This is the fastest route to converting knowledge into exam marks for Project Management I (PJM105X) at Tshwane University of Technology (TUT).