Essentials of Business Project Management (Wits Enterprise) Study Material — Wits Plus (Wits University)

Business Project Management is the set of practices used to plan, execute, monitor, and close projects that create outcomes for an organisation—often under constraints of time, cost, quality, and stakeholder expectations. In the South African context, these skills are tested and applied in university coursework and professional short courses aligned to project management bodies of knowledge (such as PMBOK® concepts). This study material focuses on Business Project Management as delivered through Wits Enterprise / Wits Plus-type training and aligns with the kind of applied thinking demanded in programmes like Wits Business School short learning, as well as related UNISA and CUT project-management modules and assessments.

You will find structured notes, templates, examples, and exam-style guidance that reflect what you typically need to understand and be able to apply: governance, scope, risk, procurement, scheduling, budgeting, stakeholder management, and project close-out.

Section 1: Foundations of Business Project Management (Wits Enterprise & Wits Plus)

Business project management differs from “general” project management in emphasis: in business projects, the project must create measurable value (customer impact, cost reduction, revenue growth, process improvement, compliance outcomes, or strategic alignment). In practice, examiners look for candidates who can connect project mechanics (scope, schedule, cost, risk) to business logic (benefits, assumptions, governance, and sustainability).

The Business Case: Why the Project Exists

At the start of any business project, the foundation is the business case—a justification for the investment. A strong business case answers questions such as:

What problem or opportunity is being addressed?
What benefits will occur (and when)?
How will we measure benefits?
What are the costs (and funding sources)?
What risks could prevent success?
What alternatives were considered?

A business case should be more than a narrative; it should include at least:

Costs (CAPEX/OPEX or project budget)
Benefits (financial and non-financial)
Time horizon (when benefits are expected)
Assumptions (e.g., market demand remains stable, systems integration is feasible)
Decision triggers (e.g., stop/go/adjust gates)

Example: Retail Process Improvement Project

Consider a project to reduce queue times at store locations by implementing a queue management system and training staff.

Problem: Average queue time is 12 minutes; customer complaints are rising.
Business benefit: Improved customer satisfaction and reduced lost sales due to long waits.
Project approach: Pilot in 5 stores, then scale based on results.
Assumptions: Stores have stable internet connectivity and staff can be trained within business hours.

In an exam context, the examiner wants to see that you link the project outputs (system installed, training delivered) to the outcomes (queue time reduced, complaints decrease).

Project Governance: Roles, Authority, and Decision-Making

Business projects typically involve layered governance:

Steering committee / Project sponsor: provides strategic direction and approvals
Project manager: responsible for planning, execution, monitoring, reporting
Functional managers: provide staff and subject matter expertise
Project team: performs work packages
Project governance forums: e.g., stage gate reviews

A Wits Enterprise / Wits Plus style approach often expects you to understand that governance is not paperwork—it is the control mechanism that ensures:

correct decisions at the right time
accountability for outcomes
escalation paths when risks materialise or scope changes

Key governance terms you should know

Sponsor: accountable for benefits and funding
Project manager: accountable for delivery against baselines (scope/schedule/cost)
Change control: formal process for scope/cost/schedule changes
Stage gates: checkpoints for approval to proceed to the next phase

Project Lifecycle for Business Projects

While lifecycles vary, business project management commonly uses:

Initiation
Planning
Execution
Monitoring & Controlling
Closing

In business projects, planning and monitoring are not “optional” because stakeholders demand evidence. For example, a sponsor will want periodic reports showing progress against:

budget baseline
schedule baseline
risk register
deliverables completion and quality

How a stage-gate lifecycle supports business value

Stage gates help avoid building the wrong thing too far into the project. They also enable:

budget reallocation if assumptions change
redesign if stakeholder needs shift
early identification of technical feasibility risks

A common exam pitfall is treating project management phases as strictly sequential. In reality, many activities overlap (e.g., procurement planning begins during planning while execution begins for early work packages).

Business Requirements vs. Project Scope

A frequent confusion: requirements are what the business needs; scope is the total work required to deliver the outputs that satisfy those requirements.

Business requirements: “The system must process 1,000 transactions per hour.”
Project scope: “Develop interfaces, configure database, test performance, train users.”

In exam answers, you should explain scope in terms of:

deliverables (what will be produced)
acceptance criteria (how you prove it works)
boundaries/exclusions (what is not included)

The Value Management Mindset: Outputs, Outcomes, Benefits

Business project management is judged on outcomes, not just outputs. A useful way to structure this:

Outputs: tangible deliverables (new system, renovated building, policy issued)
Outcomes: measurable changes enabled by outputs (faster processing, improved compliance, reduced costs)
Benefits: monetised or strategic advantage outcomes create

Example: HR Policy Implementation

Output: New HR policy and training completed
Outcome: Improved compliance with labour standards
Benefit: Reduced legal risk and fewer disciplinary costs

In exam-style responses, state that benefits may materialise after project closure (e.g., after adoption stabilises). Therefore, projects must define:

benefit owners
measurement methods
measurement timing
data sources

Section 2: Scope, Schedule, and Budget Planning for Business Projects

Planning is where project control is earned. In many university assessments (and short-course exams), marks are allocated for the ability to produce coherent baselines and explain how plans translate to control.

Scope Management: From WBS to Acceptance Criteria

Scope management ensures the project delivers the intended work and avoids “scope creep.” Core steps include:

Collect requirements
Define scope
Create work breakdown structure (WBS)
Validate scope
Control scope changes

Work Breakdown Structure (WBS)

A WBS breaks deliverables into manageable work packages. A typical structure is:

Level 1: Project deliverables
Level 2: Major components
Level 3: Work packages
Work package level: tasks with owners and estimated effort

Example WBS (simplified): “Student Portal Upgrade”

1. Project Management
- 1.1 Project planning
- 1.2 Reporting and steering
1. Requirements & Design
- 2.1 User interviews
- 2.2 System design documentation
1. Development
- 3.1 Front-end implementation
- 3.2 Back-end integration
1. Testing & QA
- 4.1 Test case development
- 4.2 UAT sessions
1. Deployment & Training
- 5.1 Go-live activities
- 5.2 Training workshops

In exam answers, the examiner expects you to describe the purpose of the WBS: clarity of deliverables, traceability from requirements to work, and improved estimation.

Acceptance Criteria and Definition of Done

Business projects often fail because “done” is ambiguous. Define acceptance criteria for each major deliverable.

For instance, for a procurement module:

“System can record purchase orders with fields: supplier ID, item codes, quantity, unit price, VAT and approval workflow.”
“UAT pass rate ≥ 95% with no critical defects.”
“Performance: handles 500 concurrent users with response time ≤ 2 seconds under load test.”

Schedule Management: Estimation, Sequencing, and Critical Path Logic

A project schedule translates scope into time. Key steps include:

Estimate activity durations
Identify dependencies
Develop schedule
Resource plan and sequencing
Critical path analysis (conceptual understanding)

Dependencies and sequencing types

Finish-to-Start (FS): activity B begins after A finishes
Start-to-Start (SS): activity B starts when A starts
Finish-to-Finish (FF): activity B finishes when A finishes
Start-to-Finish (rare)

Exam questions often test your ability to reason about realistic sequencing. Example: you cannot deploy a system before you complete testing and user training, unless you deploy a minimal “phase 1” with clear exclusions.

Resource and labour constraints

Business environments (including universities and public-sector agencies) frequently impose constraints:

staff are shared across departments
subject matter experts (SMEs) are available only certain weeks
procurement lead times may exceed expectations
holidays and exam periods reduce capacity

So schedule planning must include realistic resource calendars and procurement timelines.

Budgeting: Cost Baselines and Cost Types

Budgeting involves identifying costs and creating a cost baseline. In business projects, budgets include:

labour costs (internal staff time)
external consultant fees
technology costs (licences, hosting, equipment)
procurement costs (vendor deliverables)
training and change management
contingency reserves

Direct vs indirect costs (simple exam framing)

Direct costs: directly attributable to the project work packages (e.g., contractor for development)
Indirect costs: organisational overhead or shared services (e.g., office utilities)

Examiners may also look for understanding of contingency and management reserve:

Contingency: funds reserved for identified risks that may materialise
Management reserve: funds for unknown/undefined work within governance limits

Integrating Scope, Schedule, and Budget: The Baseline Concept

A baseline is a reference point. Your project control compares performance to the baseline.

A coherent planning approach includes:

Scope baseline: defined deliverables and boundaries
Schedule baseline: planned timing of deliverables
Cost baseline: planned spending per period and for work packages

If you change scope, you must update schedule and budget or formally manage the change through governance.

Worked Example: Building a Simple Project Cost Plan

Suppose a project has three main work packages with the following planned costs:

Work Package	Planned Cost (ZAR)
Requirements & Design	180,000
Development & Testing	360,000
Deployment & Training	160,000
Total Direct Cost	700,000

Now include contingency (identified risks) of 10%:

Contingency = 700,000 × 0.10 = 70,000
Total budget = 700,000 + 70,000 = 770,000

In this example, any schedule slippage caused by a risk (e.g., testing environment delay) should draw from contingency if the risk was identified and approved in the risk register. Otherwise, it may require change control.

Common Exam Mistakes (and how to avoid them)

Mistake: Defining scope as a list of activities rather than deliverables
- Fix: deliverables + acceptance criteria + exclusions
Mistake: Schedule dates without logic or dependency reasoning
- Fix: include dependencies and constraints narrative
Mistake: Budget numbers without contingency logic
- Fix: show cost types and contingency assumptions

Section 3: Risk, Quality, Procurement, and Stakeholder Management

Business project management is not only about “doing tasks.” It is about managing uncertainty, meeting quality expectations, procuring effectively, and aligning many parties around outcomes.

Risk Management: Identifying, Analysing, and Responding

Risk management is often assessed through:

risk register quality (not only listing risks)
risk response strategy (avoid, mitigate, transfer, accept)
monitoring triggers and escalation
linking risks to schedule and cost impact

Risk register structure

A strong risk register typically includes:

Risk ID and description
Cause and event
Impact (schedule, cost, quality, scope)
Probability and impact rating
Risk score (qualitative or quantitative)
Proposed response
Owner
Trigger / early warning sign
Status (open/closed)
Review frequency

Response strategies (exam-ready)

Avoid: eliminate risk cause
Mitigate: reduce probability and/or impact
Transfer: shift risk to third party (insurance, contracts)
Accept: acknowledge risk; possibly with contingency

Example risk: “Vendor delivery delay”

Probability: medium
Impact: high on schedule and downstream testing
Response:
- Mitigate: include delivery milestones and penalties in contract
- Transfer: use service level agreement (SLA)
- Contingency: plan parallel work (requirements finalised early)

In an exam, “response” should not only state “mitigate.” It should specify what action will be taken and who will take it.

Quality Management: Preventing Rework

Quality in project management is about fulfilling requirements and meeting acceptance criteria, not just inspection at the end.

Common quality planning steps:

Plan quality: define standards and quality objectives
Perform quality assurance: ensure process compliance
Perform quality control: verify deliverables meet criteria

Quality tools and techniques (commonly tested)

checklists
peer reviews
test plans and acceptance testing
sampling strategies
root cause analysis (e.g., “5 Whys”)

Example: UAT as quality gate

User Acceptance Testing (UAT) is often a business-critical quality step. It should include:

test scenarios based on requirements
roles/responsibilities (business users, IT team)
defect severity definitions
pass/fail criteria

If UAT fails, the schedule must include rework loops and change control if it becomes scope-related.

Procurement and Contracting: Buying Work without Losing Control

Procurement is the mechanism for obtaining goods and services. Procurement risk can derail business projects if contracts are weak or procurement timing is poor.

Procurement planning essentials

specify what to buy (scope clarity reduces procurement disputes)
decide procurement method (tendering, quotations, framework agreements)
define evaluation criteria (price, quality, capability, track record)
set contract terms (delivery schedule, acceptance, warranties, penalties)

Simple evaluation scoring example

Assume three bidders evaluated on price and technical capability, scored out of 100:

Bidder	Price Score (out of 40)	Technical Score (out of 60)	Total
Vendor A	30	50	80
Vendor B	34	42	76
Vendor C	25	58	83

If technical capability is weighted strongly, the winner may not be the cheapest. In exam answers, justify why evaluation weights match business priorities.

Stakeholder Management: Mapping Power, Interest, and Influence

Stakeholders include anyone impacted by the project or influencing it: sponsors, end-users, unions, regulators, suppliers, and internal management.

A practical stakeholder management plan includes:

Identify stakeholders
Analyse influence and interest
Plan engagement strategies
Manage communication
Track changes in stakeholder needs
Escalate issues

Power/interest grid (how to apply in answers)

High power, high interest: manage closely; frequent engagement
High power, low interest: keep satisfied; concise updates
Low power, high interest: keep informed; provide details
Low power, low interest: monitor; minimal communication

Communication plan essentials

A communication plan states:

information type (status, risks, decisions)
audience (steering committee, project team, end-users)
frequency (weekly, monthly, stage gate)
format (report, meeting, dashboard)
owner (project manager, sponsor representative)

Example: Weekly status vs stage gate governance

Weekly: detailed progress and risks for project team
Bi-weekly: operational issues for functional managers
Monthly: sponsor-level metrics and decisions needed
Stage gate: gate approval including updated business case and scope confirmation

Integrated Approach: How Risk, Quality, Procurement, and Stakeholders Connect

Business project success depends on integration:

Risks affect schedule, costs, and quality outcomes
Quality issues create risk (rework) and contract disputes (procurement)
Procurement delays influence testing and stakeholder acceptance
Stakeholder resistance can be a “risk” that requires engagement and change management

An exam marker rewards candidates who present examples of these connections rather than treating each knowledge area separately.

Case Scenario: Project Failure Diagnosis (Exam-Style)

Imagine a project to implement a campus timetable system.

Symptoms at month 4:

critical defects found in UAT
vendor delivery delayed by 3 weeks
end-users complain about usability
sponsor threatens to stop the project

Root causes might include:

scope ambiguity: user requirements not finalised before development
poor risk response: vendor delivery delay risk not mitigated with contract SLAs
quality planning missing usability standards
stakeholder engagement too late (training and prototypes not delivered early)

A strong answer identifies:

what went wrong in each knowledge area
corrective actions (replanning, change control, revised acceptance criteria)
governance actions (sponsor decision, stage gate restart or pivot)

Section 4: Monitoring, Controlling, Reporting, and Change Management in Business Projects

Monitoring and controlling translate planning into performance management. Examiners frequently assess whether you understand:

what to measure
how to compare against baselines
how to act when variances occur
how change control protects value

Project Performance Measurement: What You Track

Typical business-project performance metrics include:

schedule performance (progress against milestones)
cost performance (actuals vs planned spending)
deliverables status (work package completion)
risk status (new risks, closed risks, open risks with ratings)
quality status (defects, test pass/fail)
stakeholder sentiment or engagement milestones

In business projects, reporting must be decision-oriented. That means reports should highlight:

progress achieved since last reporting period
key risks and issues requiring action
decisions needed from the sponsor or steering committee
next period plan and dependencies

Variance Analysis: Interpreting Deviations

Variance is the difference between planned and actual performance. Variance analysis should not be purely descriptive. It should include:

Why the variance occurred
Impact on objectives (scope, time, cost, quality)
Recommended action (corrective action or change request)
Update to baseline if approved

Example: Schedule variance from vendor delay

If a vendor delivers 3 weeks late:

identify which tasks are impacted
update schedule forecast for downstream activities
estimate cost impact (overtime, extension costs)
identify quality risks (compressed testing may lead to defects)

Change Management: Controlling Scope and Baseline Drift

Change is inevitable in business projects. The key is controlling it through formal mechanisms.

A change control process usually includes:

Change request submission
Impact assessment (scope/schedule/cost/quality/risk)
Approval or rejection by governance
Implementation plan if approved
Update baselines and communicate changes
Post-implementation review

Types of changes to explicitly distinguish

Scope change: new or altered requirements/deliverables
Schedule change: shift in dates due to constraints or dependencies
Cost change: budget adjustments due to new work or inflation
Quality change: altered acceptance criteria or defect tolerances
Change in assumptions: business case assumptions no longer valid

Forecasting: Using Current Data to Predict Outcomes

Business stakeholders do not only want past performance—they want future forecasts:

Expected finish date
Expected final cost
Probability of meeting acceptance criteria
Likely benefits realisation timeline

Forecasting should be based on updated estimates, not optimism. In exam responses, mention that:

forecasting must include impacts of unresolved risks
forecasts should be updated during control cycles (e.g., weekly or bi-weekly)

Status Reporting: Steering Committee Style

A typical sponsor/steering committee report includes:

Executive summary (progress, key risks, decisions needed)
Milestone achievements and upcoming milestones
Cost summary (budget vs actual vs forecast)
Schedule summary (planned vs actual vs forecast)
Risks (top 5) and mitigations
Issues log (with owners and actions)
Changes approved since last report
Next steps

Example: Reporting structure (template)

Project status: On track / At risk / Off track
Progress: % deliverables completed; completed milestones
Top risks:
- Risk 1: description, probability/impact, mitigation status
- Risk 2: description, mitigation status
Decisions required:
- Approval of revised testing scope (if needed)
- Approval to use contingency for vendor acceleration
Next period plan: key activities and dependencies

Earned Value Management (EVM): Conceptual Exam Preparation

Many project management courses include EVM concepts. If your Wits Enterprise module includes it, be prepared to explain the basic logic:

Planned Value (PV): budgeted cost of work planned by a time
Earned Value (EV): budgeted cost of work actually completed
Actual Cost (AC): actual cost of work completed

Common EVM indicators:

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

If SV is negative, the project is behind schedule (in value terms). If CV is negative, costs are higher than planned for the earned work.

In business exams, even if you are not required to calculate EVM, you should understand what it means and why it is useful: it connects time and cost performance to actual progress.

Corrective Actions: Getting Back on Track

Corrective actions can include:

re-sequencing tasks
adding resources (if feasible and cost-approved)
negotiating revised vendor timelines
adjusting testing strategy (within quality acceptance constraints)
implementing additional change-control governance

A strong answer shows that corrective actions are not random; they are based on analysis and approved within governance authority.

Case Example: “Off Track” Status Meeting

Assume that by month 3, the project is behind schedule due to requirement changes. In a steering meeting, the sponsor asks:

“Are we still delivering the original outcomes?”
“What is the impact on budget?”
“Can we continue, or should we stop and redesign?”

A strong response includes:

explanation of variance sources (e.g., late stakeholder input)
proposed remedy with cost and schedule forecast
decision request: approve scope clarification stage or adjust baseline
mention how benefits tracking will continue if the business case changes

Section 5: Project Closure, Benefits Realisation, and Exam-Style Preparation (Wits Enterprise Orientation)

Closure is where business projects either prove value or waste investment. Many candidates focus on delivery but underperform on closure and benefits realisation, yet those are crucial for business evaluation and often tested directly in exams.

Project Closure: Administrative and Practical Closure

Project closure includes:

deliverable completion and acceptance
documentation and lessons learned
resource release and contract closure
final reporting to sponsor and stakeholders
transition to operations (handover)

Two closure concepts that show strong exam understanding:

Contract closure: ensures vendor/contractual obligations are complete
Project closure: ensures business requirements and acceptance criteria are met and operations can sustain outcomes

Handover / transition planning

Transition planning ensures that operational teams:

understand system/process operation
have support arrangements (helpdesk, maintenance schedules)
have training records and user guides
accept ownership for ongoing monitoring

Lessons Learned: Capturing Knowledge for Future Projects

Lessons learned should be recorded with enough detail to be actionable:

what went well and why
what did not go well and why
what could be done differently
specific recommendations for next projects

A high-quality lesson learned links directly to:

scope decisions
planning assumptions
stakeholder engagement timing
procurement strategy
risk response effectiveness

Benefits Realisation Management (BRM)

Business projects should define benefits tracking from the beginning, not only at the end. Benefits realisation should include:

benefits owner
baseline measures (pre-project)
KPIs and measurement frequency
reporting timeline after project closure
dependency on adoption and operating model readiness

Example: Benefits tracking metrics

Project: Implement new procurement workflow.

Possible benefits:

reduce purchase cycle time from 15 days to 10 days
increase compliance with approval workflows from 70% to 95%
reduce rework from 20 cases/month to 10 cases/month

In an exam answer, specify:

pre-project baseline values
the measurement method (system logs, audits)
when benefits should be measured (e.g., 3 months after go-live)

Managing Post-Implementation Realities

Even when deliverables are complete, outcomes may lag due to:

user adoption issues
process resistance
incomplete training
operational constraints (support teams overloaded)

Therefore, closure should include:

post-go-live support plan
monitoring period and success criteria
escalation process for operational defects

Closing Contracts and Managing Procurement Lessons

Procurement closure often includes:

final acceptance of vendor deliverables
verification of warranties and service credits
release of retention funds (where applicable)
documentation for audit and compliance
capturing vendor performance lessons

Business relevance: contract closure prevents unresolved disputes and ensures sustainability of acquired capabilities (e.g., software support renewals).

Exam Preparation: How to Answer Common Question Types

Many university and short-course exams in South Africa test a mixture of:

concept definitions
scenario-based problem solving
process ordering
calculation or justification
short essays using project management terminology

Below are common question formats and how to approach them.

1) “Discuss” questions (e.g., Discuss scope management in business projects)

A structured approach:

define the concept
explain steps in a business context
use an example (2–3 sentences)
mention common failure points and how to avoid them

2) Scenario questions (e.g., A project is off track due to stakeholder changes—what do you do?)

A structured approach:

identify what is wrong (scope/schedule/cost/quality/risk/stakeholders)
classify the issue (is it scope change? risk realisation? quality defect?)
propose corrective actions (change control, re-planning, mitigation)
state governance decisions required (sponsor approval, stage gate)

3) Process ordering questions

Use a logical sequence:

Initiation → Planning → Execution → Monitoring/Controlling → Closing
Within that, sub-steps for scope, schedule, cost, and risks follow their own logical order.

Wits Enterprise / Wits Plus Study Focus: Applied Understanding

Wits Enterprise and Wits Plus short learning often emphasises practical competence. That means your exam answers should include applied statements like:

“The acceptance criteria are verified through UAT against defined performance requirements.”
“A change request requires impact assessment on schedule, cost, quality, and risks before approval.”
“Risk responses must include triggers and owners, and contingency should be used only for approved identified risks.”

Avoid generic statements like “monitor the project” without explaining what you monitor and how you act.

South African University Alignment (UNISA / CUT style keywords in project management)

South African project management modules often test themes such as:

project planning and control
governance
risk and quality
monitoring and evaluation
stakeholder engagement
procurement and contract management
implementation and reporting

Even if your exact module code differs, these themes commonly appear in exam rubrics for programmes such as:

UNISA project-related qualifications and study guides (commonly focusing on planning, budgeting, risk, and evaluation)
Central University of Technology (CUT) business and management programmes where project execution, governance, and stakeholder management are frequently assessed in practical case studies

To make your answers “fit” these exam styles, use language that signals process clarity and governance thinking.

Full Scenario Walkthrough (Integrated Example for Exam Practice)

Here is an integrated business project scenario you can use as an exam practice model:

Scenario: A university enterprise department initiates a project to implement a new internal workflow system for approvals and reporting. Stakeholders include department heads (high power, high interest), end-users (high interest, low power), IT support (high power, medium interest), and a vendor providing the system.

Business need:

reduce approval turnaround time
improve compliance with governance approval steps
create reliable monthly reporting data

Planning decisions:

define requirements through workshops and document acceptance criteria (performance and functional requirements)
develop WBS for requirements, configuration, integration, testing, training
plan schedule with dependencies (cannot deploy before testing and training completion)
build budget with contingency of 10% for identified risks such as vendor delivery delay

Risk planning:

vendor delivery delay: mitigate via contract milestones and SLA penalties; plan contingency options
user adoption risk: mitigate by early demos, training, and phased rollout
data migration risk: mitigate via test migration and validation checks

Procurement:

procure vendor services using evaluation criteria with weighted scoring (price + technical capability)

Monitoring & controlling:

weekly status for project team; monthly sponsor report
track top risks and issues; update schedule forecast when variances occur
use change control to prevent unapproved scope drift

Quality:

implement UAT with defined pass/fail criteria and defect severity handling
conduct performance testing aligned with acceptance criteria

Closure:

handover to operations with training records and support procedures
close vendor contracts and confirm warranties/service terms
start benefits realisation tracking (approval cycle time reduction and compliance improvement) for at least 3 months post go-live

If an exam question asks you to “outline steps” and “justify actions,” this scenario provides all the components you can adapt without inventing new facts.

Final Exam Checklist for Business Project Management Answers

When writing your exam response, ensure your answer includes:

Business logic: why the project matters and how success is measured
Governance: who approves, who owns benefits, escalation paths
Scope clarity: deliverables, acceptance criteria, exclusions
Schedule realism: dependencies and constraints
Budget coherence: cost baseline with contingency logic
Risk discipline: response strategies with owners and triggers
Quality evidence: how you verify deliverables meet requirements
Procurement control: contract terms aligned to acceptance and delivery
Stakeholder engagement: communication plan aligned to power/interest
Change control: impact assessment before approval
Closure and benefits realisation: transition to operations and post-project measurement

Quick Reference: Key Terms (for fast recall during revision)

Business case: justification linking costs to benefits and assumptions
Baseline: reference plan for scope, schedule, and cost
WBS: work breakdown structure converting deliverables into manageable work packages
Acceptance criteria: measurable conditions for deliverable approval
Contingency: funds for identified risks
Management reserve: funds for unknowns under governance limits
Risk response: avoid, mitigate, transfer, or accept
UAT: user acceptance testing proving business requirements are met
Change control: formal process for approving scope/schedule/cost changes
Benefits realisation: tracking outcomes/benefits after delivery
Project closure: acceptance, documentation, handover, and contract closure

This study material is tailored for exam readiness in Business Project Management with an orientation consistent with Wits Enterprise / Wits Plus applied learning—covering planning, execution, monitoring, risk, quality, procurement, stakeholder engagement, and closure with business value at the centre.