UCT Project Management Foundations Online Short Course (GetSmarter) Notes

Project management is often described as “common sense,” but in practice it is a structured discipline: it applies tools, templates, governance, and risk thinking to ensure that work delivers the intended outcomes within agreed time, cost, and quality constraints. These exam notes focus on the University of Cape Town (UCT) Project Management Foundations Online Short Course offered via GetSmarter, consolidating the core concepts that typically appear in assessments—especially definitions, process logic, planning artifacts, stakeholder management, and risk/control frameworks. The aim is to equip you with a clear mental model of how projects move from initiation to closure, and how project managers justify decisions using measurable evidence.

The notes are written to align with study approaches commonly used for South African university modules such as UNISA MNG 0001 (Introduction to Project Management / Project Management Principles) and UCT-related project management learning outcomes; while you may not have the exact same module codes, the foundations are consistent across project management qualification curricula. Treat these notes as a “single source” for key terms and practical thinking, supported by realistic scenarios.

1) Project Management Foundations: Concepts, Roles, and Why Projects Fail

What is a project (and what isn’t)?

A project is a temporary endeavour undertaken to create a unique product, service, or result. “Temporary” means it has a start and end; “unique” means you are not simply repeating the same routine work without change. In university terms (and in many South African curricula), the most testable distinction is that projects are constrained by scope, time, and cost, and they require coordination of multiple activities.

Examples of projects (typical in South African public and private sector contexts):

Implementing a new student information system at a campus.
Building a classroom block or upgrading laboratories.
Designing and rolling out an online short course platform for a cohort.
Launching a new marketing campaign with a defined deliverable date.

Not projects (commonly confused):

Ongoing operations (e.g., running a bookstore’s weekly sales).
Routine maintenance where the output is repetitive and continuous.
Business-as-usual processes with no defined end deliverable.

A frequent exam-style question asks you to identify whether a scenario is a project. Use this quick test:

Does it have a deadline or completion criteria?
Is the outcome unique (even if improvements are incremental)?
Is it constrained (resources, budget, quality)?
If yes to all three, it’s likely a project.

Project management: definition and purpose

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet stakeholder requirements. The purpose is not merely “planning”—it is achieving outcomes through:

Clear objectives (what success looks like)
Structured planning (what must be done, by whom, when)
Execution control (monitoring progress and adjusting)
Risk and stakeholder governance (preventing surprises)
Closing and learning (capturing lessons and verifying deliverables)

Many learners make a mistake: they equate project management with scheduling (Gantt charts). A scheduling-focused view is incomplete. A strong project manager manages trade-offs and ensures alignment with business strategy.

Key project constraints and trade-offs

Traditional constraint triangle: scope–time–cost. Quality is often added as a separate constraint or a function of the other three.

When a change occurs (e.g., stakeholders request additional functionality), a project manager typically must trade off:

Increase cost (hire more staff, extend hours, buy tools)
Extend schedule (add time, re-sequence work)
Reduce scope (remove less critical features)
Adjust quality (e.g., relax acceptance criteria—often unacceptable without agreement)

In assessments, you may be asked: “What happens when scope increases?” The expected answer is: the project manager must renegotiate constraints and document approvals.

Stakeholders and roles: who influences the project?

A project usually involves:

Sponsor: provides funding, endorses decisions, champions the project.
Project Manager (PM): responsible for coordinating tasks, controls, risk management, and reporting.
Team members: perform the work and contribute expertise.
Customers/users: define requirements and acceptance criteria.
Steering committee / governance body: provides oversight and approves major decisions.
Suppliers/contractors: deliver components and services.
Regulators / compliance stakeholders: ensure legal and policy alignment.

A common exam pitfall is forgetting that stakeholders have different power and interest levels. A stakeholder register and mapping helps prioritize engagement:

High power / high interest: manage closely, frequent communication.
High power / low interest: keep satisfied, concise updates.
Low power / high interest: keep informed, allow input.
Low power / low interest: monitor with minimal effort.

Typical reasons projects fail (and how foundations address them)

Projects fail for predictable reasons. While each project differs, patterns repeat:

Unclear objectives or scope creep: “We want everything.”
Insufficient stakeholder alignment: decisions made without affected parties.
Weak planning and unrealistic assumptions: schedules built on optimism.
Poor risk management: unknown risks remain untracked until they explode.
Inadequate governance: approvals don’t happen; decisions stall.
Communication failures: people don’t know what has changed or why.
Overconfidence in tools: Gantt charts without control mechanisms.

UCT/GetSmarter foundations courses typically emphasize that success depends on fundamentals: a clear project charter, structured planning, documented assumptions, risk registers, and disciplined change control.

The project lifecycle: a high-level mental model

A project lifecycle is a set of phases that represent the project’s work over time. While different frameworks name phases differently, a common approach is:

Initiation: define the why and authorization to start.
Planning: define what and how (deliverables, schedule, budget, risk, quality).
Execution: produce deliverables.
Monitoring & Control: track progress, manage changes and risks.
Closure: hand over deliverables, confirm acceptance, capture lessons learned.

In practice, these phases aren’t isolated. Planning continues during execution (“progressive elaboration”), and monitoring occurs throughout.

Exam framing tip: When asked “what should be done first,” learners often jump to scheduling. The expected sequence usually starts with the business need and project charter, then defines scope and deliverables before detailed schedules.

2) Initiation and Planning: From Project Charter to Scope, Schedule, and Budget

Initiation: project charter and business case logic

Initiation answers: Should we do this project? Who authorizes it? What problem are we solving?

Core initiation artifacts typically include:

Business case: why the project exists, what benefits it delivers, and what it costs.
Project charter: formal authorization; outlines objectives, high-level scope, roles, and success criteria.
Stakeholder identification: who is impacted or who can affect outcomes.

A strong project charter communicates:

Problem / opportunity statement
High-level objectives
High-level scope boundaries
High-level timeline and milestones
Roles (sponsor, PM, key stakeholders)
Risks at a high level (initial assumptions)
Success criteria (measurable, not vague)

Success criteria: measurable, testable outcomes

“Improve student experience” is vague. Better success criteria might be:

Reduce time to complete course registration from 30 minutes to 10 minutes.
Achieve 95% user satisfaction in post-launch surveys.
Complete system implementation by 15 September 20XX.
Maintain uptime of 99.5% in the first month post go-live.

If you see an exam prompt asking you to evaluate whether a statement is a “good success criterion,” test for measurability, relevance, and time-bound definition.

Planning: progressive elaboration and baseline thinking

Planning is not one activity; it is an integrated set of decisions that produces a set of plans. A key concept is baseline: the approved version of scope, schedule, and cost against which performance is measured.

A typical baseline set includes:

Scope baseline (WBS + scope statement)
Schedule baseline (activities, sequencing, dates)
Cost baseline (budget by category or work package)
Performance baseline (sometimes integrated with earned value systems)

Progressive elaboration means that as the project learns more, plans become more detailed. In early stages you may estimate durations; later you refine them using actual learning from early deliverables.

Scope management: defining deliverables clearly

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

Core scope tools:

Scope statement: what is included and excluded.
Work Breakdown Structure (WBS): decomposes deliverables into manageable work packages.
Requirements: what must be true for acceptance.

WBS: how to break down work effectively

A WBS should follow the logic of delivering outcomes, not listing every possible task in chaos. The typical WBS features:

Levels that reflect increasing detail.
Work packages that can be assigned to a responsible person/team.
Clear deliverable outputs for each package (not only “work,” but “work that produces something”).

Example WBS (online course development project):
1.0 Project Management
2.0 Course Content Development
  2.1 Learning outcomes & structure
  2.2 Module writing
  2.3 Subject matter review
3.0 Learning Design & Multimedia
  3.1 Instructional design
  3.2 Video production
  3.3 Interactive activities
4.0 Platform Setup & Deployment
  4.1 LMS configuration
  4.2 Quality assurance testing
  4.3 Go-live training

Notice how the WBS uses deliverable logic. If an exam question asks what’s wrong with a WBS, look for categories that:

Are not deliverables (e.g., “do marketing” without output definition).
Are not measurable/assignable.
Overlap or duplicate.

Schedule planning: estimating, sequencing, and critical thinking

In the planning phase, project managers typically:

Identify activities (what needs doing).
Sequence activities (dependencies).
Estimate durations (how long each activity takes).
Develop schedule (dates, milestones).
Verify schedule feasibility (resource constraints, risks).

Dependencies and sequencing (testable concepts)

Common dependency types:

Finish-to-start (FS): B starts after A finishes.
Start-to-start (SS): B starts when A starts (with lag possible).
Finish-to-finish (FF): B finishes when A finishes.
Start-to-finish (rare in practice).

Also consider constraints:

Mandatory dependencies (can’t be changed)
Discretionary dependencies (could be changed if reworked)
External constraints (supplier timelines, regulatory approvals)

Estimation approaches

Foundations courses often distinguish:

Analogous estimation: using similar historical projects.
Parametric estimation: using statistical relationships (e.g., “X hours per 1 module page”).
Bottom-up estimation: summing estimates for work packages.
Three-point estimation (sometimes): optimistic, most likely, pessimistic to calculate a weighted expected duration.

In a short course foundations setting, exam questions typically expect you to explain the value of estimation uncertainty:

Early phases: more uncertainty → use broader ranges.
Later phases: refine using data → narrow ranges.

Budgeting: cost categories and what “budget” really means

Budgeting translates the scope and schedule into cost. Costs may include:

Labour (PM, developers, reviewers)
Materials/software licences
Contractor fees
Travel and training
Contingency reserves (for identified risks or uncertainty)

A useful budget model for exams is to separate:

Direct costs: directly tied to producing deliverables.
Indirect costs: overhead (sometimes funded separately).
Contingency: an amount reserved for risks or unknowns.

Simple budgeting example (for exam reasoning)

Assume a project budget is built like this:

Labour: R600,000
Software licences & tools: R120,000
Contractors: R180,000
Contingency (10% of direct costs): direct costs = 600,000 + 120,000 + 180,000 = R900,000 → 10% = R90,000

Total budget = 600,000 + 120,000 + 180,000 + 90,000 = R990,000.

If an exam question later asks “what is the contingency amount,” the expected approach is to calculate 10% of direct costs. Consistency matters: once a number appears, it must align everywhere.

Planning outputs: baselines and the project plan package

At the end of planning, the project manager produces an integrated Project Management Plan that includes (commonly):

Scope statement and WBS
Schedule and milestones
Budget and cost estimates
Quality plan (how quality will be ensured)
Resource plan (who does what)
Communications plan (how information flows)
Risk management plan (how risks are identified/assessed/treated)
Change control process (how scope/time/cost changes get approved)

Quality and acceptance criteria: planning for “done”

Quality management is not only about preventing defects. It’s about ensuring deliverables meet requirements and acceptance criteria. A quality plan may include:

Review and approval gates (e.g., content review sign-off)
Testing cycles (functional, usability)
Standards to follow
Roles responsible for verification

Acceptance criteria make closure credible. Without them, stakeholders argue during sign-off, and “closure” becomes a never-ending cycle.

3) Execution, Monitoring & Control: Risk, Change Control, Communication, and Performance

Execution: turning plans into deliverables

Execution is where planned work is performed. But execution also involves managing people, ensuring resources are available, resolving blockers, and maintaining momentum.

Core execution activities:

Confirming resource availability and staffing
Conducting work according to procedures
Managing team performance (coaching, resolving conflicts)
Producing deliverables and submitting them for reviews
Implementing quality assurance activities
Capturing lessons during work (inputs for continuous improvement)

Execution is not passive. A PM must monitor emerging issues. Even if the plan is strong, reality introduces friction: suppliers delay, stakeholders give new input, requirements shift.

Monitoring & control: performance evidence over opinions

Monitoring & control answers: Are we on track? What must we correct?

Typical monitoring outputs:

Progress updates vs milestones
Variance analysis (schedule variance, cost variance)
Risk updates
Change requests and decisions
Quality status reports
Issue logs

A common exam skill is identifying what constitutes a “trend.” For example:

If two deliverables slip by one day, that might be noise.
If the remaining deliverables show consistent slip patterns, the PM should reforecast completion and consider schedule compression strategies or scope adjustments.

Change control: managing scope drift and stakeholder requests

Change is inevitable. The project manager’s job is to prevent unmanaged change from destroying time and budget.

Change control typically includes:

Change identification (who requests and what changed)
Change impact assessment (scope/time/cost/quality)
Decision/approval by the relevant authority (sponsor, steering committee)
Update baselines or forecasts if approved
Communicate the change to affected stakeholders
Track implementation and confirm outcomes

A strong exam answer describes both process and discipline. It’s not enough to say “approve changes.” You must show impact assessment and baseline update logic.

Change impact assessment: example scenario

Suppose stakeholders request additional video chapters. The change might affect:

Scope: added deliverables (new chapters)
Schedule: increased production and review time
Cost: additional labour (video editing, voiceover)
Quality: may require additional QC rounds

A structured impact assessment uses assumptions. For example:

Each new chapter requires 10 hours production and 5 hours review.
Labour cost rate is R500 per hour.
If 3 chapters are requested: additional labour hours = (10 + 5) × 3 = 45 hours.
Additional cost = 45 × 500 = R22,500.

Then adjust schedule estimates:

If editing and review are sequential, add total duration based on team capacity.
If parallel work is possible, sequencing may reduce added timeline.

In exam questions, you’re often expected to compute basic impact arithmetic and explain how the PM justifies the change.

Risk management: identify, analyze, respond, and monitor

Risks are uncertain events that, if they occur, could affect project objectives. A risk management process commonly includes:

Risk identification
Qualitative analysis (probability and impact scoring)
Quantitative analysis (sometimes, for high-impact risks)
Risk response planning
Implementation of responses
Monitoring and review

Probability–impact matrix (the typical exam framework)

A simple scoring method:

Probability (P): Low/Medium/High (e.g., 1–3)
Impact (I): Low/Medium/High (e.g., 1–3)
Risk score = P × I

Example:

Risk: “Key reviewer unavailable during critical content finalization.”
- Probability: Medium (2)
- Impact: High (3)
- Score = 2 × 3 = 6 (often triggers action)

Risks with the highest scores become priorities for response planning and frequent monitoring.

Risk response strategies

Common strategies:

Avoid (change plan to eliminate risk)
Mitigate (reduce probability or impact)
Transfer (shift impact—e.g., insurance or contract terms)
Accept (no active response; monitor and hold contingency)
Exploit (for opportunities, not threats)

A sophisticated exam answer distinguishes threats and opportunities. Even foundations-level courses sometimes highlight opportunities:

“Extra capacity becomes available” is an opportunity that can improve schedule or reduce cost.

Issue management vs risk management

Students sometimes confuse issues with risks.

A risk is uncertain; it may or may not happen.
An issue has occurred; it is currently affecting the project.

For exam answers:

If the problem is happening now, it’s an issue requiring immediate mitigation.
If it might happen later, it’s a risk requiring planning.

Communications management: reporting, meetings, and stakeholder engagement

Communication is a project management function—not a side activity. A communications plan defines:

What information is sent
To whom
Frequency
Format (email, dashboard, meeting)
Owner of the communication
Escalation triggers

Typical communication channels:

Weekly team stand-up or progress meeting
Steering committee updates (monthly/bi-monthly)
Sponsor dashboards
Change request summaries

Communication effectiveness: what to include

High-quality reports include:

Milestones achieved since last update
Work completed vs planned
Upcoming milestones and expected completion dates
Risks updated (especially high-scoring)
Issues requiring stakeholder decisions
Decisions needed and action items

Avoid “status theatre.” For example, “All good” is not useful. Examiners reward concrete evidence: dates, metrics, and decisions.

Performance measurement: basic metrics you should know

Depending on the course depth, foundations may not require full earned value management (EVM) calculations, but it usually emphasizes performance tracking. Common performance indicators:

Schedule variance (planned progress vs actual)
Cost variance (budgeted vs actual)
Milestone completion rates
Quality metrics (defect rates, acceptance pass rates)

If you learn a particular formula in an assessment context, use it exactly. If not, use directional reasoning:

If costs are increasing faster than progress, it indicates a performance problem.
If defects increase while schedule slips, it suggests quality rework and schedule impact.

4) Closing a Project: Acceptance, Handover, Documentation, and Lessons Learned

Closure: what “done” means in project management terms

Closure is the final phase and often the most neglected. Yet without formal closure, deliverables remain disputed and benefits fail to materialize.

Project closure involves:

Verifying deliverables are completed according to scope and acceptance criteria
Obtaining formal sign-off from customers/users
Transitioning deliverables to operations (or maintaining teams)
Closing contracts and administrative processes
Capturing lessons learned
Final project reporting (performance vs baselines, outcomes vs benefits)

Distinguish project closure from termination

Project closure: normal end when deliverables are accepted.
Project termination: end before deliverables are complete due to cancellation, failure to justify investment, or external change.

An exam question might ask: “What differs between closure and termination?” You should mention:

Termination may require additional risk and contract cleanup
Closure emphasises benefits realization and transfer readiness
Termination might include rescue plans or documentation of why objectives could not be met

Acceptance and handover: making sign-off real

Acceptance procedures ensure that stakeholders agree the deliverables meet requirements. Components often include:

Acceptance checklist (objective evidence)
Review meetings and demonstration sessions
Defect correction process (within agreed tolerances)
Formal acceptance documentation

Handover includes:

Training users/admins (as per transition plan)
Documentation transfer (user guides, technical manuals)
Operational readiness (support processes, escalation paths)
Maintenance planning (who maintains, how issues are reported)

A common problem is incomplete handover documentation. This leads to “soft failure,” where deliverables exist but cannot be used effectively.

Lessons learned: turning experience into better future projects

Lessons learned should be:

Specific (what happened and why)
Actionable (what should be done next time)
Verified (not just opinions)
Logged in a format that future projects can use

Common lesson categories:

Scope and requirements clarity
Estimation accuracy
Stakeholder engagement effectiveness
Quality assurance processes
Communication quality
Risk identification timing (too late vs early)
Change control discipline

A good lessons-learned response in an exam mentions both positive and negative outcomes:

“What went well and should be repeated”
“What didn’t and should be improved”

Final reports and performance evaluation

A final project report typically includes:

Summary of objectives and whether they were achieved
Comparison of actual performance vs baselines (scope, schedule, cost)
Quality metrics and acceptance results
Major changes during the project and why they were approved
Risk outcomes (which risks materialized, which mitigations worked)
Remaining work or follow-up actions (if any)

To avoid contradictions, the report should align with:

Approved changes
Version-controlled scope and schedule baselines
Documented decisions

Benefits realization: linking deliverables to outcomes

Some courses introduce the idea that a project delivers outputs, while the organization realizes outcomes/benefits after deployment. Closure should include an understanding of:

Who owns benefits after go-live
What KPIs will be monitored post-implementation
When benefits are expected to materialize

A simple way to remember this:

Project end = deliverables delivered and accepted.
Benefits realization = measured improvements in the business.

Case-style closure scenario (typical exam application)

Imagine a project to launch an online support portal for students.

At closure:

The portal is functional and accepted (acceptance criteria met).
The support team receives training and documentation.
Contracts are closed (e.g., vendor for hosting or content services).
A final report records that:
- Schedule slipped by a defined number of days due to content review delays (issue identified early enough? mitigations applied?).
- Budget remained within contingency because change control was enforced.

Lessons learned could be:

Engage content reviewers earlier; lock review windows in the first project month.
Create acceptance checklists that include accessibility and usability testing.
Use a risk register starting from initiation to prevent unplanned rework.

This type of scenario rewards your ability to tie closure activities to earlier planning controls and governance.

5) Integrating the Foundations: Governance, Tools/Artifacts, Exam-Ready Method Answers, and South African University Study Alignment

Project governance: steering, oversight, and decision rights

Governance ensures that projects are aligned to organizational goals and decisions happen at the right time. Governance commonly includes:

Sponsor oversight and resourcing
Steering committee approvals at key gates
Escalation paths for unresolved issues
Review of business case validity (especially for larger initiatives)

A decision gate is a point at which approval is required to continue. Examples:

Approve charter and business case.
Approve baseline scope/schedule.
Approve major change requests.
Approve go-live plan.
Approve final acceptance.

Exams often test your understanding of what should be escalated and when. A strong rule:

Escalate when decisions affect scope, schedule, budget, or compliance.
Keep routine execution decisions within the team/PM authority.

Artifacts map: what you should be able to list and explain

An exam-ready approach is to memorize not only “names” of artifacts but what each artifact answers.

Common artifacts and what they answer:

Project charter → Why, what, who authorizes.
Business case → Benefits vs costs, justification.
WBS → How deliverables are broken down into manageable work.
Schedule → When activities happen; dependency logic.
Budget → How much money is needed; cost categories.
Quality plan → How quality will be ensured; acceptance readiness.
Risk register → What could go wrong (and responses).
Issue log → What is currently wrong and needs action.
Change log / change requests → What changed and approvals.
Communications plan → Who needs what info, when.
Lessons learned & final report → What happened and what to improve next time.

A frequent exam question asks: “Which document would you consult to determine whether a proposed change is approved?” The expected answer is the change log / change control records, not the project schedule alone.

Building a coherent project narrative: the “chronology” method

When answering exam questions, especially scenario-based, use the chronology:

Initiation: define the need, objectives, and authorization.
Planning: define scope, WBS, schedule, budget, quality, risk, communications, and change control.
Execution: deliver work products and implement quality assurance.
Monitoring & control: track performance, manage risks, handle issues, approve changes.
Closure: acceptance, handover, final reports, lessons learned.

If you follow this sequence, even if you’re unsure of a detail, your structure remains coherent, and examiners generally reward the logic.

Exam-style reasoning: how to answer without guessing

Here are common question patterns and how to respond systematically.

Pattern A: “Identify whether this is a risk or issue”

Use the rule:

If it has already happened → issue.
If it might happen → risk.

Then mention:

For a risk: add to risk register and plan a response.
For an issue: add to issue log and implement corrective action.

Pattern B: “Explain why change control matters”

A correct response includes:

Prevents scope creep and unapproved increases in cost/time.
Ensures impact assessment and formal approvals.
Maintains integrity of baselines.
Improves stakeholder trust and reduces conflict.

Pattern C: “Which artifact supports stakeholder engagement?”

A typical answer:

Communications plan + stakeholder register/mapping (depending on course wording).

Pattern D: “What does closure include?”

Include:

Acceptance and sign-off
Handover/training
Contract and administrative closure
Final report and lessons learned

Applying fundamentals: a full mini case (end-to-end)

Consider a South African university department launching an online module update.

Project goal: update an existing course’s learning content and assessments for the new academic year, with improved usability and faster marking turnaround.

Initiation (Month 1)

Sponsor approves charter based on business need: maintain student satisfaction and compliance with updated curriculum guidelines.
Success criteria defined:
- Average course navigation time reduced by 20% after go-live.
- Marking turnaround reduced from 7 days to 5 days for the first assessment cycle.
- 95% learner satisfaction in end-of-module survey.
Stakeholders identified: course coordinator (customer/user), academic reviewer, IT operations team, and assessment moderation panel.

Planning (Months 1–2)

Scope statement:
- Included: learning material updates, rubrics alignment, updated quizzes.
- Excluded: redesign of entire program structure.
WBS created:
- Content updates
- Assessment rubric updates
- Platform changes
- Quality assurance and moderation
Schedule baseline:
- Content drafts by end of Month 2
- Moderation by mid Month 3
- Go-live at start of Month 4
Budget allocated:
- Labour: R600,000
- Tools/licences: R120,000
- Contractors: R180,000
- Contingency: 10% of direct costs = R90,000
- Total = R990,000
Risk register drafted:
- Risk: moderation panel availability delay (P=Medium, I=High → score 6)
- Risk: platform testing reveals accessibility issues (P=Low, I=High → score maybe 3)
Communications plan:
- Weekly team updates
- Bi-weekly sponsor dashboard
- Monthly steering review gate

Execution (Months 2–3)

Content team produces drafts; academic reviewer begins review cycles.
IT operations supports platform configuration and accessibility testing.
Quality assurance checks align to acceptance criteria (rubric completeness, quiz logic).

Monitoring & control (during execution)

Progress tracked weekly against milestones.
When moderation availability shifts, the risk response triggers:
- Re-sequence some deliverables so platform testing proceeds while moderation is pending for earlier sections.
A stakeholder requests adding extra practice tests.
- Change request submitted.
- Impact assessment calculates additional effort and cost.
- Sponsor approves baseline update only if schedule remains feasible.
Issue logs updated immediately if a defect blocks testing.

Closure (start of Month 4)

Acceptance sign-off obtained from course coordinator and moderation panel.
Handover to operations includes training for lecturers on marking workflows.
Final report compares actual vs baseline:
- If schedule holds but some quality rework occurred, it’s documented with causes and mitigation lessons.
Lessons learned logged:
- Start rubric alignment earlier next cycle.
- Lock moderation windows during initiation.

This mini case demonstrates the integrated logic foundations emphasize: initiation clarity, planning structure, execution delivery, control discipline, and closure governance.

South African university alignment: how foundations map to common study expectations

In South Africa, students often encounter project management content across multiple qualification pathways. While the exact naming differs, the foundations are typically assessed similarly to UNISA project management foundational modules (e.g., MNG 0001-style intro project management principles) and UCT-informed learning outcomes where the emphasis is on applied reasoning rather than rote memorization.

When preparing for assessments, it helps to use a “university exam answer” style:

Define key term in your own words.
Apply it to the scenario.
Reference the relevant process artifact.
State the expected control outcome (baseline update, sign-off, documented decision, etc.).

Common mistakes that lose marks (and how to avoid them)

Answering only with a definition (without application).
- Fix: add “and therefore in this scenario, the PM would…”
Mixing risk and issue terminology.
- Fix: classify based on “uncertain vs already happening.”
Forgetting change control logic during scenario-based questions.
- Fix: mention impact assessment + approval + baseline update.
Confusing closure with go-live.
- Fix: closure includes acceptance, handover, documentation, lessons learned.
Using vague success criteria.
- Fix: require measurable indicators and time frames.

A compact “exam checklist” you can use under pressure

When you see a scenario question, check:

What phase is it in? initiation/planning/execution/control/closure.
What is the key decision? define objectives, approve changes, manage risks, accept deliverables.
Which artifact supports your answer? charter, WBS, schedule, risk register, communications plan, change log.
What control action is required? baseline update, escalation, response implementation, sign-off.
What evidence supports the claim? metrics, dates, acceptance criteria, documented approvals.

This checklist aligns with how foundations courses test understanding: not by tricking you, but by rewarding structured reasoning.

Summary of the Foundations (Key Takeaways)

A project is temporary and unique; project management applies structured methods to meet stakeholder requirements.
Initiation produces the business case and project charter, clarifying objectives and authorization.
Planning integrates scope (WBS), schedule, budget, quality, risk, communications, and change control into baselines.
Execution delivers work; monitoring & control uses evidence, risk tracking, and change governance to maintain performance.
Closure confirms acceptance, performs handover, closes contracts, and captures lessons learned and final performance reporting.
In exams, strong answers link each scenario to the correct phase, artifact, and control action—with measurable success criteria and clear distinction between risks and issues.