Project Management Foundations in Practice (PMFP) is a practical entry point to how project work is actually planned, executed, monitored, and closed—beyond theory. These exam notes translate core project management ideas into tools you can apply on assignments and short-course assessments, with emphasis on planning quality, stakeholder alignment, scope control, and scheduling fundamentals. Throughout, the notes connect PMFP concepts to common South African university study expectations (notably the style and language used across project management–related modules such as MNG 0001, and scheduling/scope content often found in project-facing courses like PDM 310).
Section 1: PMFP Core Concepts and the Project Lifecycle (with USB-style exam framing)
Project management can be defined in many ways, but PMFP focuses on what you can do: set direction, define outcomes, manage trade-offs, and use simple decision-making structures to keep the work aligned with objectives. In a short course context (and especially in a university exam), you are usually expected to demonstrate both understanding (definitions, relationships, terminology) and application (how to use a tool or concept in a scenario).
What “Project” Means in Practice (and why boundaries matter)
A project is temporary and produces a unique outcome. In real organizational settings, many teams confuse “projects” with “ongoing operations.” The exam trick is typically to ask you to identify whether something is a project based on attributes:
- Temporary: Has a start and an end (even if it’s flexible).
- Unique outcome: Produces something different from routine work (new product, implemented system, event delivered).
- Constraints: Time, budget, scope, and quality expectations are negotiated.
- Cross-functional effort: Often requires coordination across departments.
Example scenario:
A hospital improves its quarterly reporting dashboards (routine refresh of existing templates) may be operation work. But redesigning the dashboards to meet new regulatory requirements and integrating them with a new data source within six months is more likely a project.
Why it matters: If you misclassify the work, your governance and measurement will be wrong. Operations typically use recurring performance management; projects use milestones, change control, and closure criteria.
The PMFP lifecycle: from initiation to closure
Even when PMFP is taught as a “foundation,” the lifecycle is still the backbone. A typical lifecycle in practice can be understood as:
- Initiation
- Planning
- Execution
- Monitoring & Controlling
- Closure
A useful exam framing is to describe the purpose of each phase and the key outputs (documents, decisions, approvals).
1) Initiation: “Why” and “whether”
In initiation, you answer:
- Why is this project needed?
- What problem or opportunity will it address?
- Who cares (stakeholders)?
- What high-level solution is plausible?
Outputs commonly expected in exams:
- Project Charter (or equivalent): purpose, objectives, scope boundaries, stakeholders, high-level risk.
- High-level business case: why it is worth doing.
- Initial stakeholder register: who will influence or be impacted.
2) Planning: “What, how, and how much”
Planning is where the project turns from idea into controllable work. It involves translating the objectives into:
- Scope (what’s included/excluded)
- Schedule (activities and sequence)
- Cost (budget and cost baseline)
- Quality (standards and acceptance criteria)
- Resources (people, roles, and capacity)
- Risk management (what could go wrong and how you’ll respond)
- Communication plan (who needs what, when)
Planning output set:
In many universities, you’ll see expectations around a Project Management Plan that bundles subsidiary plans (scope, schedule, cost, quality, communication, risk, procurement).
3) Execution: “Do the work”
Execution focuses on performing planned activities, coordinating people, managing vendor work (if any), and producing deliverables.
Exam-relevant details:
- Execution isn’t “just working.” It includes resource coordination, quality assurance, issue management, and stakeholder engagement.
- If the project has change requests, execution is where you confirm that changes are implemented correctly.
4) Monitoring & Controlling: “Are we still on track?”
This phase runs continuously. It uses comparisons against baselines:
- Scope baseline vs. delivered scope
- Schedule baseline vs. actual progress
- Cost baseline vs. actual spend
- Quality results vs. acceptance criteria
- Risk register updates
Common exam method:
Given a scenario with a delay or cost overrun, ask what monitoring & controlling step should happen first. The typical answer sequence is:
- Identify variance (what is different?)
- Assess impact (scope, time, cost, quality)
- Decide response (corrective action; or recommend change)
- Implement approved change (if needed)
- Communicate outcomes to stakeholders
5) Closure: “Did we deliver and learn?”
Closure includes:
- Final deliverable acceptance
- Documentation completion
- Benefits review (did the project achieve its intended outcome?)
- Lessons learned and process improvement
- Administrative closure of contracts
Exam relevance: Closure is where marks often come from because students forget it. A closure plan shows professionalism and reinforces that project work ends with acceptance, not just completion of tasks.
Stakeholders: who they are and what they influence
A stakeholder is any person or organization that can affect the project or be affected by it. In PMFP, you’ll likely be expected to:
- Identify stakeholders early
- Assess influence and interest
- Plan engagement strategies
- Manage conflicts and expectations
Stakeholder mapping: power vs. interest (practical version)
A simplified stakeholder grid:
- High power / high interest: manage closely
- High power / low interest: keep satisfied
- Low power / high interest: keep informed
- Low power / low interest: monitor with minimal effort
Example scenario:
In a university digital learning platform upgrade, stakeholders include:
- IT security (high power, high interest)
- Lecturers (medium power, high interest)
- Students (medium power, high interest)
- Facilities/Helpdesk (medium power, medium interest)
Exam answers should include how engagement differs: IT security may require formal reviews and documentation; lecturers may need training sessions and workshops; students need clear communication and support channels.
Project objectives and scope boundaries: precision beats buzzwords
PMFP foundations often require describing objectives in a measurable way. A common error is listing vague goals (“improve efficiency”). Better objectives include performance indicators:
- Time: reduce turnaround from 10 days to 7 days (within 3 months)
- Quality: reach 95% defect-free acceptance
- Cost: deliver within a budget of R450,000 excluding VAT
- Scope deliverables: implement module X and integrate with system Y
Scope boundaries help prevent uncontrolled growth. Scope should be expressed as:
- In-scope: what will be delivered
- Out-of-scope: what will not be delivered (or what is deferred)
- Assumptions: what must be true for planning to hold
- Constraints: limitations (budget, staffing, regulatory deadlines)
Mini case (exam-style):
A municipality wants a “community engagement app.” If stakeholders don’t define whether it includes push notifications, moderation workflow, multilingual support, or offline mode, the project will likely experience scope creep. A strong scope statement clarifies which features are in scope and which are excluded.
Section 2: Scope, WBS, and Change Control—Turning Objectives into Work Packages
If Section 1 is about project fundamentals, Section 2 turns them into deliverables you can plan. In most PMFP-focused assessments, the highest marks come from showing that you can convert objectives into structured work, and then manage scope changes without chaos.
Scope management: defining and protecting what you agreed to deliver
Scope management is the set of processes that ensure the project includes all the work required and only the work required to complete the project successfully.
In-scope and out-of-scope lists (how to write them well)
A strong exam response usually includes:
- A brief deliverable summary
- In-scope features
- Out-of-scope exclusions
- Assumptions and constraints
- Acceptance criteria (how you will confirm delivery)
Example scope statement (useful exam template):
For a “Student Support Ticketing System” project:
- In scope: ticket submission form, role-based routing, email notifications, admin dashboard, audit logs
- Out of scope: chat/WhatsApp integration, mobile app (separate phase), predictive analytics dashboard
- Assumptions: email gateway access will be provided by IT within 2 weeks
- Constraints: budget cap of R450,000 excluding VAT; go-live required by 1 August
- Acceptance criteria: system handles at least 1,000 tickets per month with response time under 24 hours, and all admin functions are tested and signed off
Even if your exam doesn’t demand such detail, presenting it consistently increases clarity and reduces mistakes when change requests appear later.
WBS: Work Breakdown Structure as the “bridge” between scope and schedule
A Work Breakdown Structure (WBS) breaks the project scope into manageable parts. It is not just a diagram; it is a planning tool that enables:
- Clear assignment of responsibility
- Estimation of time and cost
- Scheduling of tasks
- Tracking progress against deliverables
WBS structure: levels that make scheduling possible
A typical WBS uses levels like:
- Level 1: Project deliverables (major outputs)
- Level 2: Sub-deliverables
- Level 3+: Work packages (manageable chunks)
Exam-ready WBS principle:
Work packages should be small enough to estimate and assign, but large enough that they are not chaotic.
Example WBS for a short project (used consistently later)
Consider the “Student Support Ticketing System” project with these major deliverables:
- 1. Project Management & Governance
- 2. Requirements & Design
- 3. Build & Configuration
- 4. Testing & Quality Assurance
- 5. Deployment & Training
- 6. Closure & Handover
Now break one deliverable into work packages:
Deliverable 2: Requirements & Design
- 2.1 Stakeholder interviews
- 2.2 Requirements documentation (user stories)
- 2.3 Workflow design (routing rules)
- 2.4 Data model design (ticket fields and audit)
- 2.5 Design review and sign-off
Why this matters: when someone later requests “add WhatsApp integration,” you can check which WBS elements are affected and whether it’s a new deliverable or a change to existing work packages.
Work packages: where estimation and accountability begin
A work package (WP) is the lowest level of WBS where you can estimate cost and duration and assign ownership. In exams, you might not be asked to calculate exact numbers, but you should demonstrate:
- How WPs relate to scope
- Why each WP needs identifiable deliverables
- How WPs feed the schedule and cost baseline
Example WP description (good exam practice):
2.3 Workflow design (routing rules)
- Deliverable: documented routing logic and approval flow
- Owner role: Business Analyst
- Dependencies: stakeholder interview completed
- Acceptance: routing rules signed off by IT and Student Services
- Estimate basis: number of stakeholder sessions (assume 3 sessions)
Change control: managing scope creep like a professional
Scope change happens. The goal isn’t to forbid all change; it is to control it so that time, cost, quality, and risk impacts are visible and decisions are made intentionally.
Typical change control flow (scenario-based)
- Change request submitted (by stakeholder or team)
- Impact assessment
- Scope impact: what deliverables/tasks change?
- Schedule impact: what activities shift?
- Cost impact: labor hours, vendor costs
- Quality impact: new requirements may affect testing
- Risk impact: new dependencies or compliance risks
- Decision / authorization
- Approve, reject, or request rework
- Sometimes approve partially or defer to a later phase
- Update baselines and communicate
- Update scope statement/WBS
- Update schedule and cost forecasts
- Notify stakeholders and re-align expectations
- Implement and track
- Ensure the change is incorporated correctly
- Close the change request
- Confirm acceptance and document outcomes
Case-style example: adding an excluded feature
Assume the “Student Support Ticketing System” scope excludes WhatsApp integration (out of scope). Midway through planning, Students’ Representative Council requests it because “most students use WhatsApp.”
A strong PMFP answer should discuss the decision:
- Is it a change? Yes—because it is out of scope.
- Is it automatically rejected? Not necessarily. It depends on the project constraints.
- Impact assessment questions:
- Does the project have enough time by the go-live date (assume 1 August)?
- Will WhatsApp require compliance checks and vendor tooling?
- Does it require additional training and support processes?
Possible outcomes:
- Reject due to budget cap of R450,000 excluding VAT
- Approve but as a Phase 2 deliverable (defer)
- Approve with reduced scope elsewhere (trade-off: reduce another feature)
How to argue trade-offs (exam-style)
If the project is late and stakeholders want additional work, a trade-off must be explicit. A common “poor answer” is to promise everything without impact. A stronger answer states:
- “Approving WhatsApp integration will likely require re-baselining schedule and/or reducing another scope component.”
- “If the go-live date cannot change, we must reduce scope or increase resources.”
These trade-offs are foundational to PMFP: constraints create the boundaries for decision-making.
Requirements traceability (why it matters for acceptance)
In project environments, acceptance disputes often occur when deliverables were not described clearly. Traceability links:
- Objectives → requirements → WBS deliverables → test cases → acceptance criteria
Simple exam framing:
If a requirement is changed, traceability shows what must also change (design documents, build configuration, testing scripts).
This becomes crucial during monitoring & controlling when you see progress numbers but delivery quality is questioned. For example, you might finish “dashboard creation,” but without correct audit logs, the acceptance criteria fail.
Section 3: Scheduling Foundations—Dependencies, Critical Path Thinking, and Monitoring Progress
Schedule management is where many students lose marks by jumping straight into tools without explaining logic. PMFP scheduling foundations focus on building a schedule that reflects dependencies and realistic constraints, then monitoring progress using meaningful metrics.
From WBS to activities: ensuring the schedule is logically consistent
A project schedule is created from activities derived from the WBS. Each activity should be:
- Clearly defined (what is produced or completed)
- Associated with a work package/deliverable
- Estimated for duration
- Linked via dependencies (why one activity must happen before another)
Activity definition: the “verb + object” rule
Examples of activity statements:
- “Conduct stakeholder interviews”
- “Draft user stories”
- “Design routing workflow”
- “Configure workflow rules in system”
- “Run integration tests”
This style supports consistent estimation and easier monitoring.
Dependencies: types you should be able to describe in exams
Dependencies explain sequencing. Common dependency types:
- Finish-to-Start (FS): Activity B starts after A finishes
- Start-to-Start (SS): B can start after A starts
- Finish-to-Finish (FF): B can finish after A finishes
- Start-to-Finish (rare): used in special cases
In most introductory scheduling questions, FS dependencies dominate.
Example dependencies for the ticketing system (consistent with earlier scope)
- 2.1 Stakeholder interviews (WP) → 2.2 Requirements documentation (FS)
- 2.2 Requirements documentation → 2.3 Workflow design (FS)
- 2.3 Workflow design → Build & configuration activity (FS)
- Build & configuration → Testing & QA (FS)
- Testing & QA → Deployment & training (FS)
Estimation basics: avoiding the two extremes
Scheduling errors commonly come from estimation issues:
- Over-optimism: durations chosen without uncertainty buffers
- Over-caution: so much slack is added that schedule becomes non-actionable and stakeholders stop trusting it
A PMFP foundation approach uses structured estimation:
- Expert judgment and team input
- Historical data (if available)
- Three-point estimation (optional): optimistic, most likely, pessimistic
Even when your exam doesn’t ask for calculations, you should explain why uncertainty is managed.
Critical path thinking: the logic behind “what matters most”
The critical path is the longest path of dependent activities through the schedule, determining the minimum project duration. Activities on the critical path have little to no float (buffer) in a basic CPM (Critical Path Method) model.
In exams, you might be asked:
- Which activities are critical?
- What happens if an activity is delayed?
- Which activity could be delayed without affecting completion date?
How to reason about criticality without advanced math
You can argue criticality by looking for:
- Activities with strict dependencies
- Chain reactions: if activity A affects B, B affects C, and so on
- Activities near the end of the schedule that cannot start until earlier deliverables are complete
Building a simple schedule model (example set with monitoring)
Assume the project has the following key activities (derived from WBS), with durations shown:
| Activity | Description | Duration (days) | Dependency |
|---|---|---|---|
| A | Stakeholder interviews | 5 | — |
| B | Requirements documentation | 7 | A |
| C | Workflow design | 5 | B |
| D | Configure workflow rules | 8 | C |
| E | Configure email notifications | 3 | C |
| F | Testing & QA | 10 | D, E |
| G | Deployment & training | 5 | F |
Now consider the earliest schedule logic:
- A finishes day 5
- B finishes day 12
- C finishes day 17
- D starts day 17 ends day 25
- E starts day 17 ends day 20
- F starts after both D and E: day 25 to day 35
- G starts after F: day 35 to day 40
So the project minimum duration is 40 days (A through G) in this simplified model.
Critical path: A → B → C → D → F → G (because D finishes later than E, making F wait for D).
Float (slack): a concept that prevents confusion
Activities not on the critical path have float. In the example:
- Activity E (email notifications) runs from day 17 to 20
- F cannot start until D completes at day 25
- Therefore E has float of 5 days (difference between E’s finish day 20 and D’s finish day 25)
Exam framing:
Float means E can be delayed up to 5 days without delaying project completion—if dependencies are respected and no other constraints break.
Monitoring progress: beyond “percentage complete”
Monitoring & controlling schedule progress uses baselines. Students often say “measure actual progress.” Exams expect more:
- Compare planned vs actual milestones
- Identify variances
- Forecast completion
- Decide corrective or preventive actions
Common schedule monitoring indicators
- Milestone status: On-track, at-risk, off-track
- Variance analysis: actual start/finish vs planned
- Trend forecasting: if delays continue, what will happen to completion?
- Resource utilization: are teams overloaded?
Practical note: A schedule can look on track by time percentages but be failing on deliverables. That’s why milestone-based and deliverable-based monitoring is emphasized in PMFP.
Case study: a delay and decision options (exam-style)
Suppose during execution:
- Activity D (configure workflow rules) is delayed by 6 days due to complexity in routing rules.
- Activity E finishes on time.
- Activity F cannot start until D is complete.
From the schedule:
- D planned finish: day 25
- D actual finish: day 31
- Therefore F starts day 31 (instead of 25)
- F planned duration: 10 days → finishes day 41
- G planned duration: 5 days → finishes day 46
Result: project duration increases from 40 days to 46 days (6-day slip).
PMFP decision options:
- Corrective action: add resources to D (if feasible), reduce scope within D while preserving acceptance criteria, or remove blockers.
- Preventive action: investigate why routing complexity occurred; improve requirements clarity or design reviews to avoid repeat.
- Re-baseline: if schedule is unavoidable, update baseline and obtain approvals.
- Trade-offs: if go-live date is fixed (e.g., 1 August), consider reducing non-critical scope elements.
A strong exam response will map each action to schedule logic and stakeholder communication.
Risk integration: schedule isn’t separate from risk
Delays often stem from risks that were known but not actively managed. PMFP emphasizes:
- Update risk register after new information
- Track whether risk response actions are working
- Link schedule variance to root causes (technical complexity, dependency failures, approvals)
Example risk: “Workflow design sign-off may be delayed due to stakeholder availability.”
If sign-off is late, C is delayed; that cascades.
Therefore, monitoring is not only about time; it is about assumptions and risk response effectiveness.
Section 4: Cost, Quality, and Communication—Building a Baseline and Running Governance
PMFP foundations in practice are often tested through integrated scenarios: schedule slips, costs change, quality expectations exist, and stakeholders demand updates. This section builds competence in cost estimation fundamentals, quality assurance/control, and communication governance—together.
Cost management fundamentals: from budget to forecast
Cost management ensures the project can be completed within the approved budget. In exam questions, you may face:
- Overruns and under-runs
- Requests to expand scope
- Questions about how to forecast future costs
Budget structure: direct and indirect costs (simple exam language)
- Direct costs: labor hours, materials, vendor fees directly tied to tasks
- Indirect costs: overhead allocation, project management administration (sometimes treated separately)
In PMFP, you often keep it simple: identify cost elements and show that estimates are built from work packages.
Estimating and baselining: why assumptions must be explicit
A budget baseline typically rests on:
- Activity durations
- Resource rates (or cost per role)
- Quantities for procurement (if any)
- Contingency and management reserves (if taught in your course)
Important exam principle:
When you forecast future cost, you need a basis: remaining work estimates, resource constraints, and updated risk likelihood.
A consistent numeric example (with cost baseline and change impact)
Use the ticketing system project introduced earlier, with the constraint:
- Budget cap: R450,000 excluding VAT
- Go-live date constraint: 1 August
- Out-of-scope: WhatsApp integration
Assume you have estimated costs for the planned work packages. Let’s build a simple cost allocation across the deliverables:
| Deliverable | Estimated cost (R) |
|---|---|
| 1. Project Management & Governance | 60,000 |
| 2. Requirements & Design | 120,000 |
| 3. Build & Configuration | 165,000 |
| 4. Testing & Quality Assurance | 55,000 |
| 5. Deployment & Training | 30,000 |
| 6. Closure & Handover | 20,000 |
| Total estimated cost | 450,000 |
This totals exactly R450,000, matching the budget cap.
Now suppose mid-execution (during D: configure workflow rules) you discover that the routing rules need extra stakeholder workshops due to changed approval workflows. That adds additional time in requirements refinement and design, say R18,000 of additional labor.
- New forecast becomes R468,000, exceeding the cap by R18,000.
PMFP expected exam response:
This is not merely “cost overruns happen.” You should ask:
- Is the additional cost due to scope creep (new scope)?
- Or due to inaccurate estimation / risk realization?
- What corrective/preventive actions reduce risk of further increase?
- Do we need change authorization to increase budget, or to offset by reducing other costs?
Example decision outcomes
- Budget approved additional R18,000 (if governance allows)
- Trade-off: reduce scope elsewhere (e.g., delay enhancement not required for acceptance) to bring forecast back to R450,000
- Schedule trade-off: add resources (higher cost) to keep date, but only if within budget
- Deferred work: push non-critical features to post go-live (but ensure acceptance criteria still met)
Quality management: standards, assurance, and control
Quality is about meeting requirements and acceptance criteria. PMFP foundations distinguish:
- Quality assurance (QA): process-focused activities to ensure quality is built in (reviews, standards, training)
- Quality control (QC): product-focused verification (testing, inspections, evidence)
Acceptance criteria: exam-friendly wording
Acceptance criteria should be testable. For the ticketing system:
- Email notifications sent on ticket submission and status changes
- Audit logs record actions with timestamps
- User roles cannot access unauthorized screens
- Testing shows no critical defects and meets performance targets
Testing and quality evidence: connecting schedule to quality
When a project is delayed, quality tasks often get rushed. In exams, you can earn marks by stating:
- Quality control activities must not be removed without decision and risk assessment.
- If schedule compression is considered, quality might require re-planning: risk-based testing, prioritization, additional regression testing.
Risk of skipping QA:
A “go-live at any cost” approach can fail due to hidden defects—leading to more rework and larger costs later.
Communication management: stakeholder needs and information flow
Communication management ensures appropriate information is collected, created, stored, and disseminated. Communication is a governance mechanism in projects.
Communication plan: what it should include
A basic communication plan includes:
- Audience: stakeholders and roles
- Message content: what information they need
- Frequency: how often updates happen
- Medium: email, dashboards, meetings, reports
- Owner: who produces updates
- Decision points: where approvals and escalations occur
Governance: who decides and how issues are escalated
In a university-like project environment (and in many real South African organizations), governance structures matter. Common governance elements:
- Project sponsor: provides authority and supports escalation
- Project manager: coordinates planning and execution
- Steering committee: makes major decisions (scope changes, budget changes)
- Change control board (CCB): evaluates change requests
Even if your specific short course uses different names, the concept is consistent: decisions require authorization.
Issue vs risk: a clear distinction for exams
- Risk: uncertain event that may happen in the future
- Issue: an event that has already happened (or is currently happening)
In exam scenarios:
- “System integration problems might occur” → risk
- “System integration is failing now” → issue
A high-scoring answer explicitly distinguishes the two and references how each is handled.
Integrated case: schedule delay leads to cost pressure and stakeholder escalations
Continue the earlier schedule delay:
- D delayed by 6 days, increasing project duration from 40 to 46 days.
- At the same time, stakeholder feedback increases revision needs, adding cost R18,000 (unplanned labor).
Now stakeholders (e.g., Student Services leadership) demand an explanation and ask whether WhatsApp integration can be added as compensation (“since you already delayed”).
A strong PMFP response should:
- Recognize WhatsApp integration is out of scope.
- Assess impact: more build and testing time; likely increases cost beyond R450,000.
- Recommend options:
- Defer WhatsApp to Phase 2 (best alignment with constraints)
- Approve only if budget and schedule re-baselined by governance
- Reduce other work to keep acceptance criteria stable
- Communicate clearly:
- Provide updated forecast and trade-offs
- Explain why “compensation features” are not feasible without re-planning
This integrates scope, schedule, cost, quality, and communication—exactly the type of integrated thinking expected in foundation practice.
Section 5: PMFP in Practice—Deliverables, Tools, Document Control, and Exam-Ready Scenario Responses (South African course relevance)
This final section consolidates PMFP foundations into “exam performance habits”: how to structure scenario answers, what documents to mention, how to use templates logically, and how to demonstrate practical competence. It also reflects common university expectations in South Africa where students encounter module frameworks that include project planning, scheduling, and governance-style questions—often aligned to introductory project management modules (for example, MNG 0001) and practical project discipline content resembling scheduling and control components found in applied management/IT project modules such as PDM 310.
Exam-ready scenario structure: a disciplined answer framework
When an exam question provides a scenario (delays, budget issues, stakeholder conflict), the best approach is to respond in a structured sequence:
- Identify the project problem clearly
- What is happening? Is it a scope issue, schedule issue, cost issue, or quality issue?
- Link to PMFP concept
- Which process does this relate to (planning, monitoring & controlling, change control, closure)?
- State the next best action
- What should happen first? Impact assessment? Status report? CCB meeting?
- Provide a practical tool/approach
- WBS update, schedule variance analysis, risk update, communication plan update
- Consider trade-offs and constraints
- Budget cap, go-live date, acceptance criteria
- Recommend resolution with rationale
- Approve/reject/defer; corrective actions; re-baseline if necessary
- Close with stakeholder communication and evidence
- What will be communicated, to whom, and when?
This approach prevents “random tool listing” and shows decision-making.
Document control basics: why it appears in real PM work (and exams)
In project management foundations, documents are not bureaucracy; they’re the evidence trail for decisions and acceptance. Typical documents include:
- Project charter / initiation notes
- Scope statement and requirements
- WBS (and WBS dictionary if used)
- Schedule baseline and activity list
- Budget baseline (cost estimates)
- Risk register and risk responses
- Communication plan
- Issue log
- Change request forms and approvals
- Test plans, test results, and acceptance sign-off
- Lessons learned and closure report
In exams, you might not need to produce documents, but you should reference them when explaining your method.
A consistent “PMFP toolkit” table (what to use when)
| Problem type in scenario | Best PMFP tool/process to mention | What you do |
|---|---|---|
| Vague deliverables / scope creep | WBS + scope statement + change control | Clarify in/out of scope; assess impacts; authorize changes |
| Schedule slip | Dependency analysis + critical path thinking + variance forecast | Identify variance; check dependencies; propose corrective actions |
| Budget overrun | Cost baseline + forecast + change authorization | Assess cause; decide trade-off or re-baseline |
| Quality complaints | QA/QC + acceptance criteria + testing evidence | Verify against criteria; adjust testing; avoid “rush QA” |
| Stakeholder confusion | Communication plan + governance meeting cadence | Publish updates; clarify decisions; record actions |
This table is exam-friendly because it maps problems to the expected PMFP answer.
Case study: a mini “PMFP project” from start to finish (end-to-end)
Below is a coherent mini-project narrative that mirrors the style of PMFP assessments. All figures and constraints used remain consistent with earlier assumptions for internal coherence:
- Project: Student Support Ticketing System
- Go-live date constraint: 1 August
- Budget cap: R450,000 excluding VAT
- Excluded feature: WhatsApp integration is out of scope
- Planned total cost: R450,000
- Initial activity schedule duration: 40 days
- Planned key dependencies: A→B→C→D and C→E; F depends on D and E; G depends on F
Phase 1: Initiation outcomes
The project charter defines:
- Purpose: reduce student ticket handling time and improve visibility of status
- Objectives: meet acceptance criteria (email notifications, audit logs, role-based routing)
- Stakeholders: IT security, Student Services, Helpdesk, Lecturers, Students
- High-level risks: approval delays, integration complexity, performance under load
The charter is approved by the sponsor and steering committee.
Phase 2: Planning outcomes
The team produces:
- Scope statement (in-scope vs out-of-scope)
- WBS with deliverables 1 to 6
- Schedule with the activity logic A–G
- Budget baseline totaling R450,000
- Communication plan for weekly status updates and milestone sign-offs
- Risk register including stakeholder availability risk
Phase 3: Execution outcomes
During execution:
- A (stakeholder interviews) completes on time
- B (requirements) completes on time
- C (workflow design) completes on time
- D (configure routing workflow rules) begins
Monitoring & controlling event
D is delayed by 6 days due to complexity and stakeholder approval changes during design confirmation. E (email notifications) completes on time, but F waits for D.
Schedule shifts from 40 days to 46 days unless corrective actions are taken. Cost forecast increases by R18,000 due to additional labor for design refinement.
Change request event (scope pressure)
A stakeholder requests WhatsApp integration “so the delays still bring value.” WhatsApp was explicitly excluded from scope at the planning stage.
The project manager submits a change request to the CCB with an impact assessment:
- Additional scope would require more build and testing time
- Likely increases cost beyond R450,000
- Likely jeopardizes go-live date 1 August unless scope reduction or budget increase occurs
Decision
Steering committee decides:
- Reject WhatsApp integration for Phase 1 (out of scope)
- Approve targeted corrective actions to recover schedule and contain costs:
- Add resource capacity to D (if within budget)
- Prioritize testing activities aligned to acceptance criteria
- Keep communication cadence and stakeholder expectations consistent
Closure
At completion, the project delivers the acceptance criteria components (ticket submission, routing workflow, email notifications, audit logs, dashboards, audit evidence). Closure includes:
- Formal sign-off from Student Services and IT
- Lessons learned about approval cycles and design sign-off timing
- Updates to organizational templates for future projects
An exam grader looking for PMFP foundations would see that the response covers lifecycle stages, scope control, schedule logic, cost constraint awareness, quality acceptance, and communication/governance decision-making.
Common misconceptions and how to avoid losing marks
To score strongly, you must avoid frequent foundation-level errors. Below are common misconceptions:
-
Confusing activities with deliverables
- Activity: “Configure workflow rules”
- Deliverable: “Workflow rules implemented and approved”
-
Treating schedule as independent of scope and quality
- Schedule compression impacts quality/testing. PMFP expects integrated thinking.
-
Responding to scope creep without change control
- You must assess impact and get authorization (CCB/steering committee), even in simplified exam settings.
-
Explaining “monitoring” only as reporting
- Monitoring & controlling includes variance analysis and corrective actions, not only status updates.
-
Assuming critical path is “the longest activity”
- Critical path is the longest path of dependent activities; not necessarily the longest single task.
-
Using vague acceptance language
- “System works” is not acceptance criteria. PMFP answers should specify measurable conditions (e.g., audit logs exist, roles cannot access unauthorized screens).
How these notes align with South African university study styles
In South African university assessments (including the style many learners associate with management and project modules), answers are typically expected to be:
- Structured (headings, bullet points, stepwise responses)
- Terminology-correct (scope, WBS, baselines, change control, QA/QC)
- Scenario-linked (apply concepts to the given story)
- Constraint-aware (budget and timelines are treated as real boundaries)
- Governance-aware (who approves decisions)
This document therefore uses consistent structures, definitions, and exam-friendly reasoning. The named module references (e.g., MNG 0001 and PDM 310) are included to make the study language familiar: introductory content often expects strong conceptual clarity and correct application of foundational project management frameworks.
Rapid exam checklist (final consolidation)
Before you submit an exam answer (or plan your assignment), ensure you included the following PMFP foundations:
- Project definition: clear understanding of what makes it a project
- Lifecycle stage: identify which phase/process the scenario concerns
- Scope: in/out of scope, acceptance criteria
- WBS: show you can convert scope into manageable work packages
- Change control: assess impacts and authorize decisions
- Schedule logic: dependencies and critical path reasoning
- Monitoring & controlling: variance analysis and corrective actions
- Cost baseline: budget cap alignment and forecasting logic
- Quality: QA/QC and acceptance evidence
- Communication & governance: communication plan and escalation decision points
- Closure: acceptance, documentation, lessons learned
When you consistently cover these elements, you demonstrate PMFP competence “in practice,” not only in theory.
End of PMFP Short Course Notes (USB Project Management Programme Guides).
