Wits Business School (WBS) Project Management (8-Week Online) Notes

Wits Business School (WBS) offers structured, practice-oriented project management learning in an 8-week online format, ideal for learners who need a disciplined approach without pausing their work. These notes are written for exam-style revision and real-world application: they connect classic project management concepts (scope, schedule, cost, risk, quality) to how teams actually plan, execute, control, and close projects in organisational settings. They also align with common South African university project management study language—useful alongside modules such as Wits Business School’s project management short course content, and comparable formal course frameworks you may see in Unisa and CUT modules (e.g., project planning, risk management, and management of projects).

1) Project Management Foundations (WBS) — From PMBOK Logic to Practical Delivery

Project management is often misunderstood as “making a plan.” In a WBS short course context, the emphasis is usually on managing uncertainty through structured decisions: defining outcomes clearly, planning deliverables realistically, coordinating people and resources, and controlling performance against baselines. The same logic appears across many university frameworks—whether your module is phrased as Project Management, Operations and Project Controls, or Planning and Scheduling—because the core mechanics are universal.

1.1 What a “Project” Means in Study and Assessment Context

A project is a temporary endeavour undertaken to create a unique product, service, or result. In exams, it’s common to distinguish projects from routine operations:

• Operations (business-as-usual): ongoing, repetitive work (e.g., daily billing processing).
• Projects: time-bound, goal-driven change (e.g., launching a new customer onboarding system).

A common exam pitfall is using “initiative” language without specifying constraints (time, cost, scope) and without defining deliverables. A WBS project management course typically expects you to demonstrate that you can:

1. state the objective,
2. identify key stakeholders,
3. translate outcomes into deliverables,
4. manage trade-offs explicitly.

1.2 Key Knowledge Areas You Must Be Able to Explain

While the course may not require memorising the full PMBOK® structure, WBS-style assessments often test whether you can reason through core knowledge areas:

1. Integration Management
   • Unifying planning documents (scope, schedule, cost, risk) into a coherent plan.
   • Managing changes through a defined process rather than ad hoc edits.
2. Scope Management
   • Defining what is included/excluded.
   • Building a work breakdown structure (WBS) and controlling scope.
3. Schedule Management
   • Sequencing activities, estimating durations, and creating a realistic schedule.
4. Cost Management
   • Estimating budgets, controlling spending, and understanding cost baselines.
5. Quality Management
   • Ensuring deliverables meet requirements (not just “finishing tasks”).
6. Resource Management
   • Planning and coordinating people, equipment, and materials.
7. Communications Management
   • Deciding what information goes to whom, when, and how.
8. Risk Management
   • Identifying uncertainties, analysing likelihood/impact, and planning responses.
9. Procurement Management (sometimes simplified)
   • Managing vendor/contractor aspects and procurement decisions.
10. Stakeholder Management

• Handling expectations, influence, and engagement.

In South African university contexts (including Unisa-style and CUT-style phrasing), you may see these described as project planning, organising, directing, and controlling. The WBS approach generally encourages mapping these functions to tangible project artefacts: charters, baselines, registers, schedules, and dashboards.

1.3 Project Lifecycle and Phase Thinking (Why It Matters for Control)

Most project lifecycle models share a common idea: projects have phases, and each phase has decision points. Typical high-level phases include:

• Initiation: define need/problem, identify stakeholders, authorise the project.
• Planning: build the plan for scope, schedule, costs, quality, risks, communications.
• Execution: do the work; manage people and deliverables.
• Monitoring & Controlling: track performance, manage changes, keep the project on course.
• Closing: confirm deliverables, transition to operations, close contracts and documentation.

In exams, phase thinking is critical because control is not the same throughout the project. For example:

• Early phases have high uncertainty and higher cost of incorrect decisions.
• Later phases have reduced uncertainty but increased commitment (harder to change).

1.4 Example: Translating a Business Need into a Project Objective

Scenario: A mid-sized Johannesburg retailer wants to reduce abandoned online carts by launching a “smart reminders” feature.

A weak project definition might be: “We will build reminders.”

A stronger WBS-aligned objective should include:

• Deliverable direction: “Create and integrate automated reminder emails/SMS within the online checkout workflow.”
• Outcome direction: “Reduce abandoned cart rate by a defined target.”
• Constraints: “Within 10 weeks, using the existing CRM platform, under a budget of R180,000.”
• Quality expectations: “Reminder messages must meet brand guidelines and deliverability requirements.”
• Stakeholders: marketing, IT, customer service, compliance/legal.

Notice how this makes planning measurable. Without measurable outcomes and constraints, schedule and cost baselines become guesswork.

1.5 Integration: The Project Management “Glue” (Make It Coherent)

Integration management is often the difference between a project that looks organised and one that is actually controlled.

Key practices you should be able to describe:

• Develop the project charter
  • Problem/opportunity statement
  • High-level objectives and success criteria
  • High-level budget and timeline assumptions
  • Assigned project manager authority
• Develop the project management plan
  • Scope baseline: what is included
  • Schedule baseline: approved dates and milestones
  • Cost baseline: approved budget
  • Risk/quality/communication approaches
• Direct and manage project work
  • Ensure team performs planned activities
  • Resolve issues and coordinate work streams
• Monitor and control
  • Compare planned vs actual
  • Capture performance metrics
  • Manage change requests
• Close
  • Validate deliverables
  • Formal acceptance and documentation

In an 8-week course assessment, if the question asks “Explain integration,” a good answer is to use the above functions and illustrate with a miniature example (e.g., how scope changes affect schedule and cost).

2) Scope, Work Breakdown Structure, Scheduling, and Baselines

Once objectives are defined, project managers need to convert them into work that can be planned, estimated, and monitored. This section covers the chain of logic: scope → WBS → activities → schedule → baselines. In many South African exam settings (including Unisa-style written tasks and CUT-style problem-solving questions), marks often depend on showing the relationships between these elements.

2.1 Scope Management: Define, Verify, Control

Scope management includes:

• Collect requirements
  Identify what stakeholders need, and document requirements.
• Define scope
  Produce a clear scope statement with boundaries.
• Create WBS
  Break down the scope into manageable work packages.
• Validate scope
  Confirm deliverables meet requirements.
• Control scope
  Manage changes formally.

A useful exam tip: use the phrases “included vs excluded” and “boundaries”. Many students can list scope components but cannot explain boundaries. Boundaries might include:

• excluded departments,
• excluded technologies,
• excluded locations,
• excluded features.

2.2 Work Breakdown Structure (WBS): The Most Exam-Tested Tool

A WBS is a hierarchical breakdown of the total scope into deliverables and work packages. It becomes the foundation for schedule and cost estimates.

2.2.1 WBS Structure Example (Mini Case)

Project: Deploy a customer feedback form system for a retail chain.

High-level deliverables might be:

• D1: Requirements and design
• D2: Build and configuration
• D3: Integration with website/app
• D4: Testing and training
• D5: Go-live and support handover

Then each deliverable breaks down further. For example:

• D2 Build and configuration
  • 2.1 Set up form templates
  • 2.2 Configure question logic
  • 2.3 Configure data storage
  • 2.4 Configure notification rules

Each work package should be:

• specific,
• small enough to estimate,
• assignable to a resource group (or person),
• verifiable.

2.2.2 WBS Coding and Consistency

WBS coding helps traceability. For instance:

• D1
• D1.1
• D1.2
• D1.2.1

Consistency is essential because schedule and cost reports often use the WBS identifiers. In assignment answers, if you propose a WBS and then later refer to an activity using a different code, it signals poor planning discipline.

2.3 From WBS to Activity List

After WBS, you create an activity list (or activity definition). Key points:

• Activities are actions performed to produce work package outputs.
• You identify dependencies (what must happen before what).
• You estimate durations and required resources.

A strong response shows you understand the difference:

• Work package = scope unit (deliverable chunk)
• Activity = specific work step to implement the chunk

2.4 Scheduling Basics: Sequencing, Estimation, Milestones

Scheduling usually includes:

1. Sequence activities
   • Use dependency logic: Finish-to-start (FS), start-to-start (SS), etc.
2. Estimate durations
   • Expert judgement, historical data, or parametric estimation
3. Develop the schedule
   • Use a network diagram or scheduling tool logic (critical path)
4. Set milestones
   • Milestones are key points that mark progress.

2.4.1 Example Schedule Logic with Critical Path Insight

Assumption scenario:
A small IT rollout in a retail environment requires:

• Requirements sign-off (A)
• Build (B)
• Integration (C)
• User acceptance testing (D)
• Go-live (E)

Dependencies:

• A → B
• B → C
• C → D
• D → E

If A slips, B, C, D, and E all shift. This is “critical path” logic. Even if the course is short, this concept is central to explaining why schedule control matters.

2.5 Baselines: Scope Baseline, Schedule Baseline, Cost Baseline

A baseline is an approved plan used as the reference point for performance measurement.

• Scope baseline: approved scope statement and WBS
• Schedule baseline: approved schedule with milestones
• Cost baseline: approved budget allocation by period/WBS

In exams, baselines often link to change control:

• If scope changes, baseline may change (after approval).
• If schedule slips, you report variances; you may not “edit reality” without a change process.

2.6 Change Control: Prevent Scope Creep

Scope creep is an uncontrolled expansion of scope. It often happens when:

• requirements evolve without governance,
• stakeholders request “small extras,”
• no formal assessment exists for time/cost impact.

A WBS course typically expects that a project manager can describe a basic change control workflow:

1. Receive change request
2. Assess impact (scope/schedule/cost/quality)
3. Decide approve/reject/defer
4. Update baselines (if approved)
5. Communicate decision to stakeholders

2.6.1 Quantitative Impact Example (Budget & Schedule)

Scenario:
Budget for a marketing campaign project is R240,000 with a planned duration of 8 weeks. You add a new deliverable: a redesigned landing page requiring additional development and testing. This adds R30,000 and 2 weeks.

• Original budget: R240,000

• Change cost: +R30,000

• New budget (if approved): R270,000

• Original duration: 8 weeks

• Added time: +2 weeks

• New target duration: 10 weeks

If the change is approved, you update baselines and adjust stakeholder expectations. If not approved, you either:

• drop the deliverable,
• negotiate scope reduction,
• or defer to a later phase.

2.7 Quality and Scope Link (Deliverables Must Meet Requirements)

Quality management is not only a testing step at the end. Scope definitions should include quality criteria:

• performance requirements,
• compliance requirements,
• acceptance criteria.

For example, in a project to install CCTV:

• Scope includes installation and configuration
• Quality includes image quality requirements, coverage constraints, and retention settings

Without quality criteria, scope validation becomes subjective, and disputes during acceptance become likely.

3) Cost, Risk, Communication, and Stakeholders for WBS-Style Projects

Project management success depends on more than schedule and scope. In a typical Wits Business School (WBS) short course, the assessments often reward candidates who can integrate cost control, risk thinking, and stakeholder communications into coherent practice.

3.1 Cost Management: Estimating, Budgeting, Controlling

Cost management usually includes:

• Estimate costs
  • Use historical data, vendor quotes, or parametric methods
• Determine budget
  • Set approved cost baseline
• Control costs
  • Track actual spending vs baseline
  • Manage variances and change requests

3.1.1 Example Cost Breakdown (Mini Budget Model)

Consider a consulting project:

• Personnel: R120,000
• Tools and licenses: R35,000
• Travel and accommodation: R20,000
• Contingency: R15,000
• Total budget: R190,000

If actual spending is:

• Personnel: R125,000
• Tools: R33,000
• Travel: R22,000
• Total actual so far: R180,000

You assess:

• which line items deviate,
• whether deviations are due to planned variance vs uncontrolled change,
• whether corrective action or change requests are required.

Even in a short course, “control” is more than reporting; it includes interpreting variance and deciding the next management action.

3.2 Earned Value Concepts (If Covered): Planned vs Earned vs Actual

Some WBS-aligned assessments may mention Earned Value Management (EVM) concepts at a simplified level. The key idea:

• Planned Value (PV): what you planned to accomplish by a date
• Earned Value (EV): what work you actually accomplished (in value terms)
• Actual Cost (AC): what you actually spent

From these, you can infer:

• schedule performance,
• cost performance.

If a course doesn’t go deep into formulas, you should still be able to use PV/EV/AC logic to explain whether the project is:

• ahead/behind schedule,
• under/over budget.

3.3 Risk Management: Identify, Analyse, Respond, Monitor

Risk management is about uncertainty with a disciplined approach.

A standard structure:

1. Risk identification
2. Qualitative analysis
   • likelihood and impact ratings
3. Quantitative analysis (sometimes simplified)
4. Risk response planning
5. Risk monitoring and control

3.3.1 Risk Register: What It Should Contain

A good risk register typically includes:

• Risk ID
• Description
• Category (technical, schedule, cost, external, compliance, etc.)
• Likelihood rating
• Impact rating
• Score (if used)
• Owner
• Response strategy
• Trigger/early warning indicator
• Contingency plan

In exams, a common marker-friendly approach is to present a risk register table and explain how response strategy links to likely impact.

3.4 Response Strategies: Avoid, Mitigate, Transfer, Accept

You should understand each response:

• Avoid: change plan to eliminate risk
• Mitigate: reduce likelihood or impact
• Transfer: shift responsibility (e.g., insurance, vendor contracts)
• Accept: acknowledge risk; prepare contingency

3.4.1 Counter-Argument Example: When “Mitigate” Is Not Enough

Students often recommend mitigation without checking feasibility. In a scheduling context:

• If a key vendor lead time is risky,
• mitigation might be “order early,”
• but if the vendor lead time is non-negotiable,
• mitigation may still fail unless you also have alternative suppliers or design flexibility.

Therefore, a better answer could combine:

• mitigate (order early),
• transfer (contract clauses),
• accept (contingency schedule options).

3.5 Example Risk Scenario with a Coherent Response Plan

Project scenario: Implement a payroll reporting tool for a company.

Risks:

1. Data quality risk
   • Likelihood: Medium
   • Impact: High
   • Response:
     • Mitigate: run data cleansing scripts, add validation rules
     • Contingency: if validation fails, fall back to manual reconciliation for first cycle
2. Regulatory compliance risk
   • Likelihood: Low
   • Impact: High
   • Response:
     • Avoid/Mitigate: review requirements with compliance officer
     • Transfer: use signed compliance check from vendor (if applicable)
3. Resource availability risk
   • Likelihood: Medium
   • Impact: Medium
   • Response:
     • Mitigate: secure backup resources, confirm sprint capacity
     • Accept: define a cut-off scope for late-stage changes

A strong WBS-style response does not stop at identifying risk—it also explains:

• who owns it,
• what triggers action,
• what “next step” occurs if the risk materialises.

3.6 Communications Management: Who Needs What, When, and How

Communication is not “sending updates.” It is structured information flow based on stakeholder needs.

A communications plan typically defines:

• stakeholder groups,
• communication objectives,
• channels (email, meetings, dashboards),
• frequency,
• message content types (status, risk alerts, decisions needed).

3.6.1 Example Communications Plan for an 8-Week Project

Assume a project with:

• Project Manager (PM)
• Steering Committee
• Technical Team Lead
• Finance Controller
• End-User Representatives

Communications:

• Weekly status report from PM to Steering Committee
• Daily stand-up for technical team (15 minutes)
• Bi-weekly finance review for budget tracking
• User feedback sessions at week 3 and week 6
• Decision meeting when change requests exceed thresholds (e.g., >R10,000 cost impact)

Even if the course doesn’t specify exact frequencies, exam answers are expected to show you know the principle: different stakeholders need different information.

3.7 Stakeholder Management: Power/Interest and Engagement Strategies

Stakeholders include anyone affected by or influencing the project. They can be:

• internal (employees, managers),
• external (regulators, vendors, communities).

A common analysis is power vs interest:

• 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

3.7.1 Example Stakeholder Map (Text-Based)

For a school infrastructure project (hypothetical):

• Principal (high power, high interest) → manage closely
• Teachers (low power, high interest) → keep informed, gather feedback
• Local municipality (high power, low interest) → keep satisfied with compliance documentation
• Suppliers (medium power, medium interest) → manage through vendor governance

Your exam response earns more marks when you tie engagement strategies to likely behavioural outcomes (e.g., teachers may raise adoption concerns if engaged late).

3.8 Integrating Risk and Communication

Risk communication should be planned. If risk owners only identify risks but never escalate triggers:

• the project misses opportunities for early correction.

A WBS-style integration is:

• Risk owners send alerts when triggers occur,
• PM assesses impact on baselines,
• Steering Committee approves changes if necessary.

This links stakeholder management with risk governance.

4) Planning Execution: Resource Management, Quality, Monitoring & Controlling, and Closing

In many learners’ notes, execution is treated as “doing tasks.” In a WBS context, execution is guided by planned methods and controlled through monitoring. This section focuses on how to run the project, keep quality consistent, measure performance, and close properly.

4.1 Resource Management: People, Roles, Availability

Resource management includes identifying and assigning:

• roles and responsibilities,
• skills requirements,
• availability,
• work allocation.

4.1.1 Responsibility Assignment Matrix (RACI)

A common exam and course tool is RACI:

• R = Responsible (does the work)
• A = Accountable (final decision/ownership)
• C = Consulted (input)
• I = Informed (awareness)

Example: Approval for a project deliverable (e.g., final report)

• PM: R (ensures completion)
• Finance Controller: A (approves budget alignment)
• Compliance Officer: C (checks compliance)
• Steering Committee: I (receives summary updates)

RACI prevents confusion, especially in cross-functional projects common in South African organisations where multiple departments must coordinate.

4.2 Quality Management: Planning, Assurance, Control

Quality management ensures deliverables meet requirements. Key terms:

• Quality planning: decide what quality standards apply and how to measure them.
• Quality assurance: systematic activities that build confidence in quality.
• Quality control: operational checks to detect defects.

4.2.1 Acceptance Criteria: The Bridge Between Scope and Quality

Acceptance criteria specify:

• what “done” means,
• what tests/reviews prove completion.

Example (website feature):

• Feature meets performance threshold (e.g., page load within acceptable time)
• Functionality works for test scenarios
• Content meets brand compliance rules

In exam answers, acceptance criteria are the strongest way to show you understand quality is not only about “effort,” but about “evidence.”

4.3 Monitoring & Controlling: Performance Measurement and Change

Monitoring and controlling includes:

• performance reporting,
• variance analysis,
• issue management,
• change control.

4.3.1 Metrics: What to Track

A project typically tracks:

• schedule progress (milestones hit/missed),
• cost spending vs budget baseline,
• scope progress (deliverables completed vs planned),
• quality outcomes (defects, rework),
• risk status (active vs closed, new risks),
• stakeholder engagement (feedback and approvals).

In an exam question, listing metrics is often not enough; you must explain how metrics trigger actions:

• If milestones are missed, investigate root causes (resource, scope creep, unrealistic durations).
• If cost overruns occur, check whether due to change requests or estimation errors.
• If quality defects rise, reassess testing strategy or training.

4.4 Issue Management: Separate Issues from Risks

A risk is uncertain and may happen.
An issue has occurred and needs immediate resolution.

A good project manager:

• monitors risk triggers,
• responds quickly when risks materialise into issues,
• updates the project plan accordingly.

4.4.1 Example: Risk Becomes an Issue

Risk: “Vendor may delay delivery due to stock constraints.”
Trigger: “Vendor informs of delayed shipment.”
Outcome: Delivery is late → this becomes an issue that requires mitigation:

• adjust internal schedule,
• activate contingency resources,
• renegotiate vendor timeline.

4.5 Work Performance Reporting: Making Information Actionable

A WBS-style deliverable usually includes:

• status summary,
• milestone progress,
• top risks/issues,
• decisions required,
• changes requested.

4.5.1 Example Status Report Structure

• Executive summary: overall project health (e.g., on track/off track)
• Schedule:
  • milestones completed
  • milestones upcoming
• Cost:
  • budget spent to date vs baseline (and variance)
• Scope:
  • deliverables completed vs planned
• Risks/issues:
  • top 3 risks with status and mitigation actions
  • top 3 issues with resolution plan
• Decisions:
  • list any stakeholder decisions required before next reporting period

This structure helps exam respondents show “monitor and control” capability rather than generic storytelling.

4.6 Closing: Transition, Documentation, and Lessons Learned

Closing is sometimes ignored by students, but WBS-style course content usually values closure discipline.

Key closing activities:

• confirm deliverables have met acceptance criteria,
• obtain formal sign-off,
• transition outputs to operations (handover documentation, training),
• close procurement contracts (if relevant),
• archive project documents,
• conduct lessons learned review.

4.6.1 Lessons Learned: Turn Experience into Repeatable Knowledge

Lessons learned should include:

• what went well,
• what didn’t,
• root causes,
• actionable improvements for future projects.

In exams, a good closing answer includes both:

• closure tasks (administrative and technical),
• and knowledge capture (lessons learned).

5) Exam-Ready Application: Integrated Case Study, Common Questions, and Revision Checklists

This final section turns the concepts into exam-ready practice. It includes an integrated mini case, demonstrates how answers can be structured, and provides revision checklists reflecting what South African learners often encounter in university short-question formats.

5.1 Integrated Mini Case (8-Week Online Project Management Style)

5.1.1 Case Overview

Project: Launch an internal “Helpdesk Portal” for employees to submit and track IT issues.
Client/Steering Committee: HR Director and IT Head.
Project duration: 8 weeks.
Budget: R200,000.
Primary objective: Improve issue resolution speed by enabling employees to submit detailed requests and track status.

The portal must include:

• a form-based ticket submission,
• ticket categorisation (e.g., access, hardware, software),
• dashboard for IT staff,
• basic reporting and analytics,
• user training for employees.

5.1.2 Stakeholders

• Project Manager (PM)
• IT Head (Accountable/approver)
• IT Technical Lead (Responsible for build)
• HR Director (Steering Committee)
• Finance Controller (Budget oversight)
• End-user representatives (employee group)

5.2 Planning the Scope: Requirements and WBS

5.2.1 Scope Statement (Exam-Style)

In scope:

• design and build a ticket submission form,
• implement ticket categorisation,
• implement IT dashboard and basic reporting,
• configure workflows for assignment and status updates,
• train end-users on portal usage,
• pilot and obtain acceptance sign-off.

Out of scope:

• full HR document management integration,
• complex SLA automation for all departments,
• replacing the entire IT systems architecture.

This boundaries approach prevents scope creep and provides a clear line for scope validation.

5.2.2 WBS (Example Deliverables)

D1: Project planning and requirements

• 1.1 stakeholder interviews
• 1.2 requirements documentation

D2: Portal design and build

• 2.1 form design and workflow logic
• 2.2 ticket categorisation configuration
• 2.3 IT dashboard development

D3: Reporting and analytics

• 3.1 basic reports
• 3.2 permissions and access rules for staff

D4: Testing and training

• 4.1 functional testing
• 4.2 pilot with employees
• 4.3 user training sessions

D5: Go-live and closure

• 5.1 go-live support
• 5.2 handover documentation
• 5.3 lessons learned

5.3 Scheduling: Milestones, Dependencies, and a Simple Logic Chain

A milestone list (for a WBS exam answer) could include:

• Week 1: Requirements sign-off
• Week 3: Build completed (internal testing)
• Week 5: Pilot-ready release
• Week 7: Training complete
• Week 8: Go-live and acceptance sign-off

Dependencies:

• Requirements sign-off → build tasks
• Build → functional testing
• Functional testing → pilot
• Pilot feedback → final adjustments (if approved)
• Final adjustments → training and go-live readiness

Critical insight: if requirements sign-off is delayed, the entire schedule is impacted. This is exactly the kind of reasoning examiners look for.

5.4 Cost Plan: Budget Allocation and Control Logic

Assume budget allocation:

• Personnel (PM + technical + support): R110,000
• Software/tools/licenses: R35,000
• Training materials and sessions: R20,000
• Infrastructure/hosting and configuration: R25,000
• Contingency: R10,000
• Total budget: R200,000

Control logic:

• track spending weekly,
• compare to budget baseline by WBS area,
• require change requests if any scope change affects cost beyond a defined threshold (e.g., additional R10,000).

In exam answers, the key is to show you can connect cost control to scope change control and stakeholder approval.

5.5 Risk Register: Identify and Plan Responses

Top risks (examples with response plans):

1. Requirements volatility
   • Likelihood: Medium
   • Impact: High
   • Response: mitigate via requirements workshop and approval gate at Week 1
2. Technical integration delays
   • Likelihood: Low to Medium
   • Impact: High
   • Response: transfer via vendor support agreement; accept with contingency if delay is minor
3. Low pilot adoption
   • Likelihood: Medium
   • Impact: Medium
   • Response: mitigate via training emphasis and collect feedback quickly
4. Data privacy concerns
   • Likelihood: Low
   • Impact: High
   • Response: avoid by aligning with access control and confidentiality rules; consult compliance if needed

In a WBS-style answer, you must include triggers:

• for requirements volatility: “new requirement request submitted after Week 1 approval gate”
• for integration delays: “vendor reports delivery risk before Week 3”
• for pilot adoption: “pilot feedback indicates confusion in >20% of pilot user interactions”

5.6 Communications Plan: Weekly Cadence with Decision Gates

Communications:

• Weekly status meeting (PM + IT Lead + Finance Controller) for internal alignment
• Weekly report (PM to Steering Committee: HR Director + IT Head)
• Bi-weekly user feedback session for pilot group starting Week 4

Decisions needed:

• accept scope at Week 1
• approve final go-live adjustments at Week 7
• approve any change requests impacting budget

5.7 Execution, Monitoring, and Control

Execution activities mapped to WBS:

• D2 build portal features,
• D3 implement reporting,
• D4 test and training.

Monitoring:

• check milestone completion weekly,
• review risk status and triggers,
• track cost spending.

Control actions:

• if a risk triggers, activate response and update schedule,
• if scope change requested, assess impact and route through change control.

5.8 Closing: Acceptance, Handover, and Lessons Learned

At Week 8:

• validate deliverables meet acceptance criteria,
• obtain sign-off from IT Head and HR Director (Steering Committee),
• handover portal documentation to IT operations,
• archive build/testing records,
• lessons learned session focused on:
  • requirements gate effectiveness,
  • schedule realism,
  • stakeholder communication quality,
  • risk management performance.

5.9 How to Answer Common Exam Questions (WBS-Style) — With Templates

5.9.1 “Explain the difference between risk and issue”

A model answer includes:

• definition difference (uncertainty vs occurrence),
• examples,
• how each changes the management response (risk plan vs issue resolution),
• how monitoring affects both.

5.9.2 “What is a WBS and why is it used?”

A model answer includes:

• definition,
• hierarchy purpose (deliverables → work packages),
• link to activity planning and estimating,
• role in traceability and controlling scope.

5.9.3 “Describe change control and scope creep”

A model answer includes:

• definition of scope creep,
• steps in change control workflow,
• impact assessment across scope/schedule/cost,
• approval and baseline update.

5.9.4 “How do you manage stakeholders?”

A model answer includes:

• stakeholder identification,
• power/interest classification or equivalent,
• engagement strategy,
• communication plan,
• handling resistance with evidence-based responses.

5.10 Revision Checklists (Use for Last-Minute Study)

5.10.1 Scope & WBS Checklist

• Scope statement has clear in scope / out of scope boundaries
• WBS is hierarchical and uses consistent coding
• Each work package is specific and verifiable
• Deliverables connect to acceptance criteria

5.10.2 Schedule Checklist

• Activity list derived from WBS work packages
• Dependencies are stated and logical
• Milestones mark meaningful progress
• Critical path reasoning is understood (at least at conceptual level)

5.10.3 Cost Checklist

• Budget totals correctly and includes contingency where appropriate
• Cost control links to baselines and change approvals
• Variance interpretation includes likely causes and next actions

5.10.4 Risk Checklist

• Risk register includes owner, likelihood/impact, response, triggers
• Response strategies match the nature of the risk
• Risks are monitored and updated, not forgotten

5.10.5 Communications & Stakeholders Checklist

• Different stakeholders have different info needs
• Channels and frequencies are specified
• Decisions required are clearly communicated
• Engagement strategy exists for high-power/high-interest groups

South African University Relevance (Wits + Unisa/CUT-Style Alignment)

Because many South African learners use short-course content alongside formal university modules, it’s helpful to relate the WBS project management logic to common study patterns you may encounter in Unisa and CUT coursework—especially topics like planning, project evaluation, risk assessment, and stakeholder management.

6.1 How WBS Short-Course Topics Mirror University Exam Skills

Across South African universities, project management questions often test:

• definitions and distinctions (project vs operations; risk vs issue),
• tool-based explanations (WBS, RACI, risk register),
• problem solving (scenario scheduling logic; budget variance interpretation),
• written structuring (using steps or frameworks rather than narrative only).

WBS learning methods usually develop exactly these exam strengths:

• you build artefacts (scope statements, registers, schedules),
• you justify decisions with implications (cost/schedule/quality impacts),
• you show governance (change control, acceptance, closing).

6.2 Keyword Alignment for Studying and Writing Answers

If you’re preparing for written assessments, incorporate terminology that matches university rubrics:

• scope baseline, schedule baseline, cost baseline
• work breakdown structure (WBS)
• acceptance criteria and scope validation
• risk register, likelihood, impact, risk owner
• change request, impact assessment
• stakeholder engagement, RACI
• monitoring and controlling, performance measurement
• lessons learned, project closure

Using these phrases consistently helps you appear “method-literate” in exam marking criteria.

Final Summary: What You Must Remember for an 8-Week WBS Project Management Exam

Wits Business School (WBS) Project Management (8-Week Online) requires a practical grasp of how planning and control work together. Strong answers connect scope (with clear boundaries and a WBS) to schedule (dependencies, milestones, baselines), and to cost (budgeting and variance interpretation). They also demonstrate disciplined risk management (register, response, triggers), structured communications and stakeholder engagement (who needs what and when), and governance through change control. Finally, the best responses close the loop with quality acceptance and lessons learned, showing that the project ends properly—not just that the work is completed.