Project Management Principles and Practice I (PMPP101) – Study Guide (DUT)

Project Management Principles and Practice I (PMPP101) focuses on the fundamentals of planning, organising, leading, and controlling projects from initiation through closure. This study guide is written in a DUT-friendly exam-prep style, with clear explanations, structured steps, and practical examples aligned to how South African universities typically assess project management concepts. You will also find worked mini-scenarios to help you apply theory to exam questions rather than only memorising definitions.

Section 1: Understanding Projects, Project Management, and PMMPS101 Core Concepts (DUT)

Project Management is sometimes treated as “just scheduling,” but the essence of project management is the deliberate management of uncertainty to deliver a defined outcome within constraints (scope, time, cost, quality, and risk). In PMPP101 (DUT), the emphasis is usually on foundational concepts: what a project is, what makes projects unique, what project management aims to achieve, and how practitioners structure project work to reach objectives.

What Is a Project? (Characteristics You Must Know for Exams)

A project is a temporary endeavour undertaken to create a unique product, service, or result. The word temporary means it has a definite start and end—unlike ongoing operations. The word unique means that even if similar work has been done before, this specific project has its own requirements, context, and deliverables.

Key characteristics commonly tested:

Defined objectives
- A project exists to deliver a specific set of outcomes (e.g., build a community hall, implement a payroll system, run a marketing campaign with specified KPIs).
Temporary nature
- Projects end when deliverables are accepted, when goals are achieved, or when the project is terminated.
Unique outputs
- Even repeated projects differ due to location, stakeholders, constraints, compliance requirements, technology, or timing.
Constraints and trade-offs
- Time, budget, scope, and quality are linked. Changing one usually affects others.
Uncertainty and risk
- Projects deal with unknowns: requirements may change, suppliers may delay, hazards may occur, or assumptions may fail.

Example: Project vs Operation

Operation: A municipal water plant runs continuously to provide water daily.
Project: Upgrading the water plant’s filtration system from an old model to a new one by December 2026.

In exams, you often need to justify why something is a project. A useful answer structure is: temporary + unique output + constrained objectives.

What Is Project Management? (And What It Is Not)

Project Management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. In practical terms, PM requires managing the work and the people involved to deliver within constraints.

A common exam trap is to confuse project management with:

Administration only (paperwork without leadership and decision-making),
Scheduling only (Gantt charts without risk and scope control),
Management of daily operations (ongoing process improvement rather than a single defined deliverable).

Project management includes, but is broader than, scheduling. It includes:

planning and organising,
risk assessment and response,
stakeholder engagement,
quality assurance and control,
progress monitoring and corrective action,
procurement and resource management (where applicable).

The PMPP101 “Core Triangle”: Scope, Time, Cost (Plus Quality and Risk)

Many curricula use a “triple constraint” or “iron triangle.” In PMPP101-style exam answers, you should show you understand that project success depends on managing the trade-offs among:

Scope: what you will deliver (features, deliverables, acceptance criteria).
Time: how long it takes (milestones, deadlines).
Cost: how much money is available/spent.
Quality: how well the deliverables meet requirements (performance, reliability, compliance).
Risk: uncertainty that could affect scope, time, or cost.

A strong exam statement:

If scope increases without increasing time or cost, the project must either reduce quality, increase risk, or renegotiate constraints.
If time is shortened but scope stays the same, cost likely increases (e.g., overtime, extra resources, expedited procurement).
If cost is reduced, scope may need to be reduced or timelines extended.

Mini-Scenario (Trade-off Reasoning)

A school library refurbishment originally scheduled for 10 weeks at R200,000 now faces budget reduction to R160,000 with the same 10-week deadline. The project manager should consider:

reducing non-critical elements of scope,
replacing materials to meet minimum quality standards,
adjusting procurement plans (e.g., phased purchases),
increasing risk monitoring because cuts often raise execution uncertainty.

Project Life Cycle (From Initiation to Closure)

A project life cycle divides project work into phases. While specific models differ, common phases in PMPP101 include:

Initiation
- Identify the need and feasibility.
- Appoint the project manager (if not already appointed).
- Develop a high-level business case and project charter.
Planning
- Break down the work (WBS).
- Plan schedule, budget, resources.
- Define quality plans, risk management plans, and communication plans.
Execution (Implementation)
- Carry out the plan.
- Coordinate people and resources.
- Procure materials where needed.
- Manage stakeholder expectations as work progresses.
Monitoring and Controlling
- Track actual performance.
- Compare plan vs actual.
- Manage changes and implement corrective actions.
Closure
- Finalise deliverables.
- Obtain formal acceptance.
- Conduct post-project evaluation.
- Release resources and archive records.

Example: Community CCTV Installation Project

Initiation: City approves need for CCTV to improve safety; project charter created.
Planning: Site survey, vendor selection plan, risk assessment (electrical hazards, permits).
Execution: Installation of cameras, network cabling, testing.
Monitoring/Controlling: Track installation progress; manage delays due to permit processing.
Closure: Training on system operation, handover documents to municipality.

In exams, a good answer includes both phases and what happens in each phase—especially deliverables like charter, plans, acceptance, and lessons learned.

Stakeholders and Their Influence (Who Matters and Why)

A stakeholder is any person, group, or organisation that can affect or is affected by the project. Stakeholders are not only “customers.” In a project, they may include:

project sponsor,
project manager,
project team,
clients/users,
procurement/vendor teams,
regulatory bodies,
community representatives,
internal departments affected by the project.

Stakeholder Analysis (High-Value Exam Skill)

A stakeholder analysis typically considers:

Power: how much influence the stakeholder has.
Interest: how concerned they are with project outcomes.
Impact: what effect they can cause on scope/time/cost.
Engagement strategy: how you will communicate and manage them.

A typical exam response includes:

identify stakeholders,
categorise their interest and power,
propose communication methods and frequency.

Example: Housing Development Project

Stakeholders:

Department of Human Settlements (high power, high interest due to compliance),
Local municipality (high power, medium-high interest due to permits and infrastructure),
Community leaders (medium power but potentially high interest due to local disruption),
Home buyers (high interest, medium power through acceptance),
Construction contractor (high influence on cost/time delivery).

Organisational Structures and Project Management Governance

Projects occur within organisations, and organisational structure shapes how projects are authorised and controlled. You should understand basic forms:

Functional structure
- Staff work in departments (e.g., finance, engineering, HR).
- Projects may borrow resources; project authority is often limited.
Matrix structure
- Employees may report both to a functional manager and a project manager.
- Could be weak, balanced, or strong matrix.
Projectised structure
- Most people work within the project team; project manager authority is high.

In PMPP101 exams, governance is sometimes assessed through:

project authority and reporting lines,
roles and responsibilities,
decision-making bodies (steering committees).

Example: Matrix vs Functional in Scheduling

In a functional structure, the project manager may struggle to schedule because engineers are prioritised by their functional department. In a balanced matrix, the project manager has more scheduling power but still negotiates resources.

Project Success Criteria (Beyond “Finished on Time”)

Project success is often misunderstood as simply completing deliverables. In exam answers, define success using multiple criteria, such as:

delivering the agreed scope (features and deliverables),
meeting quality standards (fitness for purpose, compliance),
delivering within time and budget constraints,
achieving stakeholder satisfaction,
ensuring benefits are realised (where applicable).

A useful differentiation:

Project success: meeting project objectives (scope/time/cost/quality).
Product success: whether the deliverable achieves ongoing benefits (e.g., increased customer satisfaction).
Both matter in a well-managed project.

Common PMPP101 Exam Keywords to Master

You will likely encounter these terms repeatedly. Understand them clearly so you can define and apply them:

Business case (why the project exists; value justification)
Project charter (authorises the project; high-level scope and roles)
Scope (what is included/excluded)
Deliverables (tangible outcomes)
Milestones (significant points in schedule)
Assumptions (factors considered true for planning)
Constraints (factors limiting options)
Risks (uncertainty that could affect objectives)
Change control (manage scope/time/cost changes formally)

Section 2: Project Planning Fundamentals — WBS, Scheduling, Budgeting, and Resource Planning (DUT)

Planning converts project goals into an actionable roadmap. In PMPP101, exam questions frequently test whether you can take a project description and create logical planning outputs: a work breakdown structure (WBS), a schedule rationale, a budget outline, and a resource plan. The key is not just definitions; it is applying processes consistently.

Work Breakdown Structure (WBS): The Backbone of Planning

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total project scope into manageable components. It answers: What work must be done to produce the deliverables?

In exams, you should be able to:

explain what a WBS is and why it matters,
describe typical WBS levels,
create a WBS for a scenario,
link WBS elements to schedule and costs.

Why WBS Matters

A WBS improves control by:

clarifying scope (reducing ambiguity),
enabling accurate estimation of time and cost,
allowing assignment of responsibilities,
supporting quality control (deliverables are defined),
supporting risk identification (each component can have risks).

WBS Levels (Common Exam Pattern)

A basic WBS might look like:

Level 1: Entire project
Level 2: Major deliverable areas
Level 3+: Work packages (small enough to estimate and manage)

Example: “Develop an Online Registration System” Project WBS

Level 1: Online Registration System

Level 2A: Requirements and design
- Level 3: User requirement workshops
- Level 3: UI/UX design
- Level 3: Technical design specification
Level 2B: Development
- Level 3: Front-end implementation
- Level 3: Back-end implementation
- Level 3: Database setup
Level 2C: Testing and security
- Level 3: Test plan and cases
- Level 3: Security vulnerability checks
- Level 3: Performance testing
Level 2D: Deployment and handover
- Level 3: Hosting configuration
- Level 3: User training sessions
- Level 3: System handover documentation

A strong exam answer adds that each work package should have:

clear deliverable/acceptance criteria,
estimated duration and cost,
owner/responsible party,
risks and assumptions.

Estimating Duration: From Activities to a Schedule

Scheduling turns the WBS into a timeline. A schedule consists of:

activities (work units),
dependencies (relationships),
durations,
start/end dates,
milestones.

In PMPP101, you might be expected to understand or construct:

activity lists,
dependency types (finish-to-start, start-to-start, etc.),
critical path concept (sometimes introduced as foundational logic),
Gantt chart reasoning.

Activity Dependencies (Common Exam Types)

Finish-to-Start (FS)
- Task B can start only after Task A finishes.
- Most common.
Start-to-Start (SS)
- Task B starts when Task A starts.
Finish-to-Finish (FF)
- Task B finishes when Task A finishes.
Start-to-Finish (rare and usually not used)
- Task B cannot finish until Task A starts.

Example: Library Renovation Schedule Logic

“Demolition” must finish before “Floor leveling” starts (FS).
“Architectural design” must be approved before “Building materials procurement” starts (FS).
“Electrical rough-in” may begin once “Walls partially built” are ready (FS with partial completion).

Gantt Charts: What They Communicate

A Gantt chart visually represents:

tasks on the y-axis,
time periods on the x-axis,
bars representing planned durations and sometimes progress.

In exams, Gantt charts are often used to:

show sequencing,
highlight overlaps,
identify when milestones happen.

A typical exam interpretation question:

If “Procurement” runs from Week 3–5 and “Installation” runs Week 6–8, what does that imply about dependency?
Answer: installation depends on procurement completion.

Budgeting and Cost Planning

Budget planning answers: How much money is required to deliver the WBS components? Costs generally include:

labour,
materials,
equipment,
subcontractors,
permits and compliance,
contingency and risk allowance.

Bottom-Up vs Top-Down Estimation

Bottom-up: estimate cost for each work package and sum them.
- Usually more accurate when WBS is detailed.
Top-down: allocate an overall budget estimate to major components.
- Faster but less precise.

In PMPP101, you may be assessed on whether you can justify estimation method choices. A strong justification includes:

project complexity,
availability of historical data,
maturity of scope.

Mini Budget Example (Consistency Check)

Suppose a project has these work package costs:

Requirements workshops: R12,000
UI/UX design: R18,000
Front-end development: R25,000
Back-end development: R30,000
Testing and security: R20,000
Deployment and training: R10,000

Total direct costs = 12,000 + 18,000 + 25,000 + 30,000 + 20,000 + 10,000
= R115,000.

If contingency is 10% to cover risks:

Contingency = 10% of R115,000 = R11,500
Total project budget = R115,000 + R11,500 = R126,500

In exam practice, use arithmetic carefully; many marking guides reward correct calculation and consistent logic.

Resource Planning: People, Skills, and Allocation

Resource planning determines what resources are needed and when. Resources include:

labour hours,
specialist equipment,
materials,
internal staff and external vendors.

Skills-Based Resource Planning

Not all team members can do all tasks. Resource planning must consider:

required competencies (e.g., software developer, QA tester),
availability (leave schedules, workload),
capacity constraints (one person can handle only certain workload).

Example: Project Team Allocation (Scenario-Based)

A small project may have:

1 project manager,
2 developers,
1 QA tester,
1 designer,
support from procurement.

The schedule might require QA availability during testing phases, not during early requirements workshops. If the QA tester is over-allocated, testing may delay, causing scope/time slippage.

Quality Planning Interacts with Schedule and Budget

Quality is not something you “check at the end.” Quality planning includes:

quality standards,
inspection and acceptance criteria,
quality assurance activities,
defect management approach.

Example: Online System Quality Criteria

Acceptance criteria might include:

page load time under a specified threshold,
zero critical security vulnerabilities,
user registration flow works for test user roles.

Quality requirements affect:

testing time (schedule),
cost for tools (budget),
rework cycles (schedule and risk).

In PMPP101, exam answers should show quality is planned, not improvised.

Communicating Plans: Communication Planning Basics

A plan is only useful if stakeholders receive timely updates. Communication planning includes:

what information is shared,
who receives it,
frequency and format,
escalation routes for problems.

Common communication formats:

weekly project status meetings,
milestone reports to sponsor,
risk registers updates,
stakeholder newsletters or community meetings (for community-impact projects).

Section 3: Implementing Project Work — Execution, Stakeholder Engagement, Risk Management, and Change Control (DUT)

Planning sets direction; execution delivers. In this section, you focus on what happens once work starts: how teams coordinate, how stakeholders influence outcomes, how risks are managed actively, and how changes are controlled so the project remains viable.

Execution Management: Turning Plans into Delivered Outcomes

Project execution involves:

coordinating people and resources,
managing deliverable production,
implementing procurement plans,
ensuring compliance with quality requirements,
maintaining communication and team alignment.

In exam answers, demonstrate that execution is not only “doing tasks.” It includes:

resolving issues,
managing dependencies,
addressing stakeholder feedback,
tracking progress against the plan.

Example: Execution in a Vehicle Fleet Maintenance Project

Deliverables:

maintenance schedule set up,
workshop readiness,
parts procurement,
maintenance execution across the fleet.

During execution:

if parts arrive late, maintenance activities must be rescheduled,
if a vehicle requires unexpected repairs, scope and cost may change,
if downtime affects operations, stakeholder communication must be proactive.

Stakeholder Engagement: Managing Expectations and Reducing Resistance

Stakeholder engagement is about ensuring stakeholders understand:

what is happening,
why decisions were made,
what impact the project has on them,
how they can contribute or respond.

A useful engagement framework:

Identify stakeholder needs and concerns.
Choose communication methods (meetings, reports, workshops).
Manage expectations with transparency.
Escalate conflicts through governance structures.

Managing Resistance: A Practical Approach

Resistance often comes from:

unclear scope (“will this affect my workflow?”),
fear of disruption (“will my area be closed?”),
lack of involvement (“why wasn’t I consulted?”),
distrust (“are budgets being used properly?”).

A project manager can reduce resistance by:

involving stakeholders early in requirements,
showing phased timelines and impacts,
confirming acceptance criteria and boundaries,
providing a clear change-control process.

Risk Management: Identifying, Analysing, Responding

Risk management is essential because projects operate under uncertainty. PMPP101 typically tests:

what a risk is,
differences between risk and issue,
how to identify and analyse risks,
planning responses.

Risk vs Issue (Exam-Friendly Distinction)

Risk: a potential event that has not happened yet (uncertainty).
Issue: something that has happened or is currently occurring.

Example:

Risk: “If supplier delays occur, installation will slip.”
Issue: “Supplier delayed materials and installation has stopped.”

Treating an issue like a risk delays response; treating a risk like an issue can create unnecessary panic or cost.

Risk Identification Techniques

Common techniques include:

brainstorming with team members,
expert judgement,
checklists based on historical project data,
analysis of assumptions and constraints,
stakeholder interviews.

Example: CCTV Installation Risks

Permits delayed by regulatory body
Electrical system compatibility issues
Weather hazards delaying cabling work
Community concerns about privacy

Each risk should include:

cause,
event/trigger,
potential impact (time/cost/scope/quality),
probability and impact rating.

Risk Analysis and Prioritisation (Probability x Impact)

A common exam method is to assess risks using:

Probability (likelihood of occurrence),
Impact (severity of outcome if it happens).

You can then calculate a risk score:

Risk Score = Probability × Impact

If you use a 1–5 scale:

Probability 1 = very unlikely, 5 = almost certain
Impact 1 = negligible, 5 = major

Example Risk Table (Consistent Calculations)

Assume:

Permit delays: Probability 4, Impact 5 → Score 20
Electrical compatibility: Probability 3, Impact 4 → Score 12
Weather delays: Probability 2, Impact 3 → Score 6
Privacy concerns: Probability 3, Impact 3 → Score 9

Prioritisation is based on score; permit delays are most urgent due to high time impact.

Risk Response Planning

Main response strategies:

Avoid
- change plan to eliminate risk.
- Example: Use an alternative supplier with proven permit turnaround times.
Mitigate
- reduce probability or impact.
- Example: Start permit application early; provide complete documentation to reduce rework.
Transfer
- shift impact to a third party.
- Example: Use insurance or contract clauses with suppliers.
Accept
- keep risk without active changes; create a contingency reserve.
- Example: If weather risk is low, accept and schedule buffer.

In exam answers, you should match response type to risk nature. Avoidance is often costly; mitigation is usually more balanced.

Issue Management (When Risks Become Reality)

When a risk triggers, it becomes an issue requiring:

immediate action to contain impact,
root cause analysis,
corrective actions,
documentation and communication.

A mature approach includes:

log the issue,
define owner and due date,
assess impact on schedule/budget,
recommend change requests if needed.

Change Control: Managing Scope, Time, and Cost Changes

Projects rarely run exactly as planned. Changes may be requested by:

sponsor,
client/users,
regulatory bodies,
technical discoveries during execution.

Change control ensures changes are:

documented,
evaluated for impact,
approved through governance,
implemented with updated plans and stakeholder communications.

Change Control Process (Typical PMPP101 Sequence)

Change request submitted
- description of change, rationale.
Impact assessment
- cost, time, scope, quality, risk.
Decision/approval
- accept, reject, or request modifications.
Update project documents
- schedule, budget, WBS, risk register.
Communicate decision
- stakeholders informed, team action aligned.

Example: Change Request in Renovation Project

Original scope includes ceramic tiles in main rooms. During procurement, the client requests a different type of floor finishing costing additional materials and increasing installation time by 2 weeks.

Impact assessment must show:

cost increase = difference in materials + extra labour,
schedule impact = installation delay,
quality impact = possibly improved durability (but verify acceptance criteria).

If the client wants the change but time cannot increase, change-control decisions may require:

reducing other scope items,
reallocating resources (overtime or extra installer),
negotiating a new milestone date.

Documentation: Why PM Systems Matter

Even in small projects, record-keeping supports:

auditability,
consistent decisions,
reduced misunderstandings,
continuity when team members change.

Common project documents include:

charter and plans,
WBS,
schedule and cost estimates,
risk register,
issue log,
change request forms,
meeting minutes and stakeholder communication records.

In exam contexts, answers that mention “documentation ensures accountability and traceability” typically score well.

Section 4: Monitoring and Controlling — Performance Measurement, Quality Control, and Project Reporting (DUT)

Monitoring and controlling ensure the project stays on track. Execution creates deliverables; monitoring provides visibility into what is happening and whether corrective action is required. In PMPP101, exam questions often evaluate your ability to interpret project performance information, explain control processes, and justify corrective actions.

Monitoring vs Controlling (A Distinction Worth Defending)

Monitoring: observing and collecting performance information (what is happening).
Controlling: taking actions based on comparison between planned and actual performance (what to do next).

A good exam phrasing:

Monitoring collects data (progress, cost status, quality findings).
Controlling analyses variances and implements corrective measures or change requests.

Performance Measurement: Variance and Trend Thinking

A fundamental control approach involves comparing:

Plan vs Actual,
Actual progress vs scheduled progress,
Budgeted cost vs actual cost.

Common variance reasoning (conceptual):

If a task is behind schedule and will remain behind, downstream tasks may become delayed unless recovery actions are applied.
If costs exceed budget due to rework, quality control and root cause analysis become urgent.

Example: Interpreting a Schedule Variance

Planned milestone: “Testing complete” by 30 July. Actual completion is 6 August. That is a delay of 7 days. Now consider downstream tasks:

deployment must occur after testing is finished,
if deployment cannot shift, rework or additional testing capacity may be required.

Quality Control: Ensuring Deliverables Meet Standards

Quality control is the process of monitoring specific project results to determine whether they comply with relevant standards. Quality control activities may include:

inspections,
tests,
measurements and verification,
defect logging and remediation.

Example: Software System Quality Control

Quality control might involve:

running test scripts,
checking security scan results,
verifying user acceptance criteria.

Quality control outputs include:

pass/fail assessments,
defect reports,
rework instructions,
updates to quality metrics.

Earned Value (EV) Awareness (If Included in PMPP101)

Some versions of project management courses introduce Earned Value Management (EVM) as a performance measurement approach, even at introductory level. If EVM is part of your learning outcomes, you should know the core logic:

Planned Value (PV): value of work scheduled.
Earned Value (EV): value of work actually completed (in terms of budget).
Actual Cost (AC): actual money spent.

From these:

Schedule Variance (SV) = EV − PV
Cost Variance (CV) = EV − AC

A positive SV means you are ahead of schedule; a negative means behind. A positive CV means under budget; negative means over budget.

Worked Example (Simple EVM Logic)

Assume by a reporting date:

PV = R50,000 (planned work value)
EV = R40,000 (actual completed work value)
AC = R45,000 (actual cost)

Then:

SV = EV − PV = 40,000 − 50,000 = −R10,000 → behind schedule
CV = EV − AC = 40,000 − 45,000 = −R5,000 → over budget relative to earned work

In exam questions, you often need to interpret what these variances mean and propose corrective actions.

Corrective Action vs Preventive Action

Corrective action: addresses negative deviations from plan (fix what is wrong).
Preventive action: reduces probability of future issues/negative deviations (prevent recurrence).

Example:

If defects are appearing during testing, corrective action may be immediate rework.
Preventive action may be improving coding standards or adding earlier peer reviews.

Many exam scripts reward candidates who distinguish these clearly.

Reporting: Status, Progress, and Risk Communication

Project reporting communicates progress and status to stakeholders. Key reporting types:

Status reports: overall project health, progress against schedule and budget.
Milestone reports: achievements and next milestones.
Risk and issue reports: what changed in risk profile, which issues need escalation.
Change reports: approved changes and their impacts.

A good reporting structure includes:

Executive summary (RAG status: Red/Amber/Green).
Progress against plan (what completed, what remains).
Variances and causes (why different from plan).
Risks and issues (what is likely to affect outcomes).
Actions needed and decisions required.

RAG Status Example

If:

budget is within limits (Green),
schedule is delayed with credible recovery plan (Amber),
risk is rising due to supplier issues but mitigations are active (Amber),
overall might be Amber because time risk is critical.

Documentation and Traceability in Control

Controls depend on reliable documentation:

changes must be recorded,
quality findings must be logged,
variance explanations must be kept,
meeting decisions must be documented.

This supports:

audits,
accountability,
continuity,
learning.

Stakeholder Management During Monitoring

Monitoring increases transparency. Stakeholders should receive:

updates on progress,
clarity on delays and their impacts,
clarity on change decisions,
information about how they may participate in decisions.

If stakeholders learn about problems late, trust decreases and recovery is harder. Therefore, proactive reporting is a control strategy.

Section 5: Project Closure, Evaluation, and Learning — Benefits Realisation, Lessons Learned, and Exam-Ready Problem Solving (DUT)

Closure is not the “end of work only.” It includes ensuring that deliverables are accepted, documenting outcomes, transferring responsibilities, and capturing learning for future projects. PMPP101 typically tests whether students understand closure activities and how to evaluate performance.

Closure Phases: Administrative and Technical Closeout

Project closure often includes two interrelated components:

Administrative closure
- finishing paperwork,
- final approvals,
- contract closure (if applicable),
- archiving project records.
Technical closure
- ensuring deliverables meet acceptance criteria,
- conducting final inspections and tests,
- handing over operational documentation.

Example: Closure in a Skills Training Project

Administrative:

confirm participant completion certificates issued,
close venue booking contracts,
final financial reconciliation.

Technical:

ensure training material is ready for use,
collect feedback forms,
hand over training reports to sponsor.

Formal Acceptance and Handover

Formal acceptance ensures the client/sponsor acknowledges that deliverables meet requirements. Acceptance often includes:

sign-off documents,
verification of deliverables,
user training (where needed),
warranty or support commitments.

In exam answers, emphasise that without acceptance:

project scope might remain disputed,
closure may fail legally or financially,
benefits realisation becomes uncertain.

Post-Project Review (PPR) and Lessons Learned

A post-project review is a structured evaluation of performance. It typically covers:

what went well,
what did not go well,
why outcomes differed from plans,
what to improve for next projects.

Common categories:

scope management,
schedule performance,
cost control,
quality,
risk management effectiveness,
stakeholder engagement,
communication clarity,
team performance.

A strong exam answer also suggests actions:

update organisational templates,
improve estimation techniques,
adjust procurement processes,
strengthen risk response readiness.

Benefits Realisation (Project vs Product Success)

Project closure can occur even if benefits are not yet realised. Benefits realisation focuses on whether the deliverable creates value. In PMPP101 exams, you may be asked to distinguish:

completion: deliverables delivered,
success: benefits delivered/used.

Example: New IT System

A system may be completed on time, but if users do not adopt it due to poor training or lack of support, benefits may not be achieved. Therefore benefits realisation requires:

user adoption measurement,
post-implementation support,
monitoring performance after handover.

Closing Contracts and Resources

Closure includes:

releasing team resources,
closing supplier contracts,
finalising payments,
resolving outstanding disputes.

This ensures:

no unpaid liabilities remain (where applicable),
organisational accounting is correct,
resources are not trapped in limbo.

Handling Project Termination (Not All Projects End Successfully)

Sometimes projects end prematurely due to:

failure to meet business needs,
funding withdrawal,
irreconcilable technical constraints,
major risks becoming threats.

In such cases, closure must still include:

documentation of reasons,
salvage of partial deliverables where possible,
stakeholder communication,
lessons learned to avoid repeating failures.

Exams sometimes ask you to explain closure under termination conditions, so ensure you understand that closure is about proper end-of-project governance, not only success outcomes.

Exam-Ready Integrated Scenario: Apply Concepts from Start to Finish

To consolidate PMPP101 principles, use this integrated scenario and practice building structured answers.

Scenario: Build a Community Health Outreach Mobile Unit

A municipal department launches a project to provide mobile health outreach for community clinics. The expected deliverables include:

vehicle equipped for basic health checks,
outreach scheduling plan,
staff training and operating procedures,
compliance documentation,
launch communications.

Constraints:

Total budget: R1,200,000
Deadline: 31 October 2026
Minimum quality: vehicle compliance with local health and safety regulations
Stakeholders: municipal sponsor, health department, clinic representatives, procurement office, and community leaders.

Assume the project is planned to start 1 July 2026 and must be closed by 31 October 2026.

Step 1: Initiation Outputs (What to Write in an Exam)

Your initiation answer should include:

Project charter: purpose, objectives, constraints, high-level risks, stakeholder roles.
Business case: how mobile outreach improves health access and service coverage.
High-level scope: what is included (vehicle readiness, training, compliance documents) and what is excluded (e.g., not establishing permanent clinics).
Stakeholders list and sponsor authority.

Example Exam Points

Sponsor: municipal health department
Project manager authority defined for scheduling, procurement coordination, and reporting
Stakeholder engagement plan required due to community disruption concerns

Step 2: Planning Outputs (WBS, Schedule Logic, Budget Allocation)

WBS Draft (Simplified but Exam-Useful)

Level 1: Mobile Health Outreach Unit Project

Level 2A: Vehicle selection and procurement
Level 2B: Vehicle equipping and installation
Level 2C: Compliance and documentation
Level 2D: Staffing training and procedures
Level 2E: Outreach scheduling and launch communication

Budget Allocation (Total Must Match)

Let’s allocate the R1,200,000 budget across categories:

Vehicle procurement and transport: R450,000
Equipment and installation labour/materials: R380,000
Compliance documents and inspections: R130,000
Training, procedures, and training materials: R120,000
Communication and community engagement: R70,000

Sum check:
450,000 + 380,000 + 130,000 + 120,000 + 70,000
= 450,000 + 380,000 = 830,000
830,000 + 130,000 = 960,000
960,000 + 120,000 = 1,080,000
1,080,000 + 70,000 = R1,150,000

We still need R50,000 to reach R1,200,000. That remaining amount becomes contingency (risk reserve).

Contingency reserve: R50,000

Final total:
1,150,000 + 50,000 = R1,200,000 (consistent)

In exams, consistency is crucial. If your totals don’t add up, marks may be lost even if individual reasoning is good.

Schedule Outline

From 1 July 2026 to 31 October 2026 is about 4 months. Use milestones:

Milestone 1 (late July): vehicle procured
Milestone 2 (mid-August): equipping completed
Milestone 3 (late September): compliance approved
Milestone 4 (early October): staff training completed
Milestone 5 (31 October): launch readiness and handover

This schedule aligns with the logic:

Compliance approval requires equipping completed.
Training can occur once procedures are drafted and vehicle readiness is assured.

Step 3: Execution and Stakeholder Engagement

Execution tasks:

coordinate supplier deliveries,
manage installation,
conduct inspections,
deliver training,
run community engagement sessions.

Stakeholder approach:

clinic representatives review operational scheduling plan,
community leaders receive updates about launch day and service access rules.

Step 4: Monitoring and Controlling with RAG Reporting

Create a basic control view:

Schedule: track key milestones.
Cost: track spending vs budget categories.
Quality: compliance inspection pass/fail and training assessment outcomes.
Risks: supplier delays, inspection turnaround times, equipment failure.

If, for example, compliance approval slips by 2 weeks due to inspection scheduling, then:

adjust subsequent activities (training and launch),
communicate impacts to sponsor and clinic representatives,
consider escalation or additional inspection scheduling actions.

Step 5: Risk Management in the Scenario

Identify major risks:

Supplier delay for vehicle equipping parts
Compliance inspection delay
Staff training attendance issues
Community mistrust due to privacy concerns about health data handling

Response examples:

mitigation: start procurement early, use backup suppliers, schedule inspections immediately after equipping.
transfer: include supplier delivery penalties where feasible (procurement clauses).
accept: allocate contingency budget for minor delays.

In exams, you must not only list risks; you must show the response strategy and its impact on time/cost.

Step 6: Change Control During Execution

Suppose compliance requirements change mid-way:

additional documentation required,
new safety standard check.

This is a change request and must go through:

describe change,
assess cost/time impact,
decide approve/reject,
update schedule, budget, and documentation plans,
communicate to stakeholders.

In exam answers, emphasise traceability: approved changes must reflect in updated versions of plans.

Step 7: Closure and Lessons Learned

On 31 October 2026:

deliver vehicle and operational materials,
obtain final compliance sign-off,
conduct handover meeting,
archive records,
capture lessons learned (e.g., compliance inspection scheduling process improvement).

If the project achieved scope and compliance but experienced delays, lessons learned might focus on:

earlier inspection booking,
more robust supplier contingency planning.

Common PMP/PMPP101 Exam Question Patterns (How to Structure Answers)

In South African university exams, markers often reward structured responses. Common question patterns:

“Define and explain”
- Provide definition + purpose + example.
“Differentiate between two concepts”
- Use comparison bullets (risk vs issue; monitoring vs controlling).
“Apply to a scenario”
- Use steps: identify → plan → implement → control → close.
“Draw or create a WBS / schedule logic”
- Use hierarchical structure and show dependency reasoning.
“Explain why something matters”
- Provide cause-effect: how it impacts time, cost, quality, and stakeholder satisfaction.

A high-scoring style uses:

headings (even if not requested),
numbered steps for processes,
bullet points for lists,
short consistent examples.

Section 6: DUT-Focused Exam Toolkit — Templates, Checklists, and Fast Mark Strategies (DUT)

To make this study guide exam-useful, this section provides ready-to-use templates and checklists you can practise in your own writing. The goal is to help you generate high-scoring exam answers quickly and consistently.

Template: Project Charter “Must Include” Checklist

A typical project charter should include:

Project purpose (business need)
Objectives (scope/time/quality aligned)
High-level scope (what is included)
High-level schedule (milestones)
Budget at a summary level
Key stakeholders and roles (sponsor, PM, team)
Assumptions and constraints
High-level risks (top risks)
Authority and governance (how decisions are made)

In a short-answer exam question, you can write:

one sentence per bullet, keeping it concise and correct.

Template: WBS Creation Checklist

When creating a WBS from a scenario, ensure:

deliverables are clear at Level 2,
work packages are manageable and estimable,
each work package has a clear verb-noun description (e.g., “Develop test plan,” “Procure equipment”),
the WBS covers all major deliverables without duplication.

A helpful mental test:

If you could assign each work package to someone and estimate time/cost, your WBS is probably at a workable level.

Template: Risk Register “Column Ideas”

A risk register typically includes:

Risk ID
Risk description (event)
Cause/trigger
Probability rating
Impact rating
Risk score
Response strategy (avoid/mitigate/transfer/accept)
Owner
Status (open/monitoring/closed)
Review date

Even if the exam doesn’t require full numbers, showing the logic of probability and impact helps.

Checklist: Change Control Answer Structure

For a change control question, include:

Who requests the change?
What is changed (scope/time/cost/quality)?
Why is the change needed (rationale)?
What are the impacts (cost difference, schedule delay, quality effect)?
What decision is made and by whom?
How will plans be updated?

Markers like answers that show governance and traceability.

“Mark Strategy” for Common Short-Answer Questions

Example: “Differentiate between project success and product success.”

High-scoring answer:

Project success: meeting project objectives (scope/time/cost/quality)
Product success: deliverable achieves intended benefits after use
Both contribute; a project can be completed but product adoption can fail.

Example: “Explain monitoring and controlling.”

High-scoring answer:

Monitoring collects performance data.
Controlling compares actual to plan and takes corrective/preventive actions.
Reporting links to stakeholders and escalations.

Worked Mini-Answers (Practice Excerpts)

Mini-Answer 1: Risk vs Issue

A risk is an uncertain event that may occur in the future and affects project objectives if it happens. An issue is an event that has occurred or is actively happening now and therefore requires immediate action. Managing risks aims to reduce likelihood or impact, while managing issues focuses on containment, corrective actions, and resolution.

Mini-Answer 2: Why a WBS Is Needed

A WBS decomposes the project scope into manageable components, making it easier to estimate time and cost, assign responsibilities, define quality expectations, and control scope changes. Without a WBS, the project manager may miss required work packages, leading to schedule delays, budget overruns, and scope disputes.

Consistency Practice: Arithmetic and Totals

Because your exam may include calculation elements (budget totals, contingency, simple schedule impacts), practise:

summing line items correctly,
ensuring percentages match totals,
checking variance signs (positive/negative).

A quick habit:

Always re-add final totals before writing your final answer.

Section 7: Frequently Tested Topics Recap — PMPP101 One-Page Revision Guide (DUT)

This final revision section summarises high-likelihood PMPP101 exam topics with concise cues. Use it as a last-minute memorisation and recall guide.

Core Definitions You Should Be Able to State Clearly

Project: temporary endeavour creating a unique product/service/result.
Project management: applying knowledge, skills, tools, and techniques to meet project requirements.
WBS: hierarchical decomposition of scope into manageable components.
Milestone: significant point on the schedule.
Stakeholder: person/group affected by or able to affect project outcomes.
Risk: potential uncertain event with impact if it occurs.
Issue: problem currently happening.
Change control: formal process to evaluate and manage changes.
Closure: finalisation of deliverables, acceptance, contract close, and lessons learned.

Process Flow You Should Explain in the Correct Order

Initiation
Planning
Execution
Monitoring and Controlling
Closure

Control Logic (Plan vs Actual)

Collect progress data (monitoring).
Compare with plan (variance).
Take corrective/preventive actions (controlling).
Update stakeholders and plans when approved changes occur.

Quality and Stakeholder Connection

Quality must be planned, not only inspected later.
Stakeholder engagement affects acceptance, adoption, and conflict resolution.
Communication reduces surprises and improves governance effectiveness.

Conclusion: How to Prepare for PMPP101

PMPP101 rewards structured understanding and application. Strong exam performance comes from consistently linking every concept to how it affects scope, time, cost, quality, risk, and stakeholder satisfaction. Practise answering using templates: define key concepts, apply them to scenarios with WBS logic, show how to manage risk and change, and close with lessons learned and acceptance. With disciplined revision of these core principles, you can produce clear, high-mark responses aligned to DUT project management expectations.