NWU Potchefstroom Business School Short Course in Project Management Notes (Study Guide)

The North-West University (NWU) Potchefstroom Business School short course in Project Management is designed to build practical competence in planning, executing, and controlling projects—while also giving learners the managerial language to communicate with stakeholders, manage risks, and make decisions under uncertainty. These exam notes consolidate the core project management processes, tools, and typical assessment themes used in South African business education settings. You’ll find frameworks (e.g., scope–time–cost control, risk registers, stakeholder maps), worked mini-scenarios, and exam-style explanations aligned to how project management is commonly tested in tertiary courses (including formats similar to UNISA/CUT business and management modules such as BUL/BUS/MPM-type project modules and project management foundations).

1) Project Management Foundations for NWU Short Course: Scope, Time, Cost, Quality, and Governance

Project management is often described as “managing a temporary endeavour to produce a unique product, service, or result.” In an NWU Potchefstroom Business School short course context, the emphasis typically falls on being able to explain and apply the main knowledge areas, and to justify choices using structured reasoning (e.g., why a risk response is appropriate, why a certain planning artefact is needed, or why governance matters).

A useful way to understand the subject—especially for exam questions—is to treat project management as a set of interlocking control systems:

Scope control ensures you deliver the right work.
Time control ensures you deliver it when required.
Cost control ensures you can afford it.
Quality control ensures it works and meets requirements.
Risk and stakeholder management prevent surprises and build support.
Governance ensures decisions are made with accountability and documentation.

1.1 What Makes Projects Different from Operations?

A common exam prompt asks you to differentiate projects from operations. The key contrasts are:

Time frame:
- Projects are temporary.
- Operations are ongoing.
Uniqueness:
- Projects deliver a unique outcome (e.g., a new system, a refurbishment).
- Operations deliver routine output.
Complexity and coordination:
- Projects require cross-functional coordination (procurement, HR, engineering, finance).
Uncertainty:
- Projects typically have greater uncertainty in costs, timelines, and requirements.

Mini-case example (South African context):
A municipality upgrades a billing system. This is a project: it has a defined start and end date, unique deliverables, and coordination across IT, finance, and vendor contracting. The ongoing operation is running billing after the upgrade—this becomes operations once the system is live.

1.2 The Project Management Triple Constraint (and Why It’s Not Enough)

Many learners learn the “triple constraint” (scope–time–cost). Exams often expect you to extend it with additional constraints:

Scope (what you must deliver)
Time (when you must deliver it)
Cost (what it must cost)
Quality (how well it must perform)
Sometimes also resources and risk as practical constraints

A strong exam answer explains that changes in one constraint affect the others. For example, if scope increases, either time must increase, cost must increase, quality trade-offs must occur, or resources must expand.

Counter-argument worth noting (for higher marks):
Some modern approaches suggest that the “iron triangle” can be misleading because quality and risk are central, and stakeholder satisfaction can be a higher-level constraint than time or cost alone. In practice, governance and stakeholder expectations often drive “success” more than the narrow triangle.

1.3 Governance: Why It Shows Up in Short Courses

Even though short courses are not deep governance law modules, governance appears because it determines:

Who approves scope changes?
Who can stop the project if risk thresholds are exceeded?
How are decisions documented and communicated?
How are accountability and authority structured?

A governance structure typically includes:

Project sponsor (provides resources and strategic alignment)
Project manager (plans, coordinates, controls)
Steering committee / management committee (oversight and key decisions)
Project team (execution)
Stakeholders (influence requirements and acceptance)

Exam-style explanation:
When a stakeholder requests a change, it is not automatically implemented. The change goes through a change control process (impact assessment on scope, time, cost, quality, risk), then approval is obtained from the appropriate authority.

1.4 Project Life Cycle and Phase Gates

A life cycle divides work into phases (e.g., initiation, planning, execution, monitoring/controlling, closure). Many exam questions ask you to identify “what happens in each phase” and what outputs you produce.

A typical phase-gated view:

Initiation
- Define problem/need
- Identify stakeholders
- Produce a project charter
Planning
- Define scope and deliverables
- Build WBS (work breakdown structure)
- Create schedule and budget
- Develop risk plan, quality plan, stakeholder plan
Execution
- Perform work, coordinate resources, manage communications
Monitoring & Controlling
- Track progress, manage change, perform risk reviews
Closing
- Obtain acceptance, document lessons learned, formal closure

Phase gate concept:
A phase gate is a checkpoint where leadership decides whether to proceed based on readiness, budget availability, and risk.

Worked mini-example:
If the project charter is approved but the project team cannot confirm key resources, the next phase should be delayed or re-scoped. This is a governance outcome rather than a “project manager error.”

2) Planning Core: WBS, Schedules, Budgets, Stakeholder and Communication Plans

In exams, learners often lose marks by describing tools without showing how they are used. This section focuses on planning outputs and how to connect planning artefacts to control.

2.1 Defining Scope: Requirements vs Deliverables

A common high-mark answer distinguishes:

Requirements: what the client/stakeholders need (functional needs, constraints)
Deliverables: tangible outputs produced by the project (documents, systems, training sessions, physical work packages)

A strong approach uses:

Scope statement (boundaries and acceptance criteria)
Work Breakdown Structure (WBS) to translate deliverables into manageable work packages
Requirements traceability concept (even if simplified) to link requirements to WBS elements

Example scenario:
A retailer implements a customer relationship management (CRM) system.

Requirements might include:
- user login and roles
- reporting dashboards
- data migration from legacy spreadsheet(s)
Deliverables might include:
- configured CRM instance
- data migration script
- user training handbook
- user acceptance test (UAT) completion sign-off

2.2 Work Breakdown Structure (WBS): How to Build It for Marks

Examiners love WBS diagrams and structured tables. Even without drawing a full network, you should show you understand:

Decomposition: break deliverables into smaller components
Levels: project → phases/major deliverables → work packages
Work package size: small enough to estimate cost and time

Simple WBS example (CRM project, simplified):

WBS Level	Component	Description
1	CRM Implementation	Whole project deliverable
1.1	Requirements & Design	workshops, solution design
1.2	Build & Configure	configure modules, roles
1.3	Data Migration	map fields, migrate and verify
1.4	Testing & Training	UAT, training sessions, manuals
1.5	Go-Live & Closure	deployment, handover, lessons learned

For exam writing, you should add a second layer where it becomes “work packages” (e.g., 1.2.1 configure roles and permissions; 1.2.2 configure dashboards; etc.). While your short course may not require complex WBS formalism, showing WBS thinking is essential.

2.3 Estimating: Bottom-Up vs Top-Down (and Why It Matters)

Two common estimation strategies:

Bottom-up estimating: add estimates of detailed work packages
- Typically more accurate when the WBS is well-developed.
Top-down estimating: allocate from a high-level total
- Useful when details are missing early, but less accurate.

Exam-quality justification:
If the project has already been decomposed into work packages and resources have been identified, bottom-up estimating is more reliable. If it’s early initiation and no WBS exists, top-down may be the only option.

2.4 Scheduling: Activity Sequencing and Critical Path Logic

A short course in project management typically expects you to explain core schedule concepts:

Activities (tasks)
Dependencies:
- Finish-to-Start (most common)
- Start-to-Start
- Finish-to-Finish
- Start-to-Finish
Critical Path: the chain of activities that determine the project duration

2.4.1 Dependency Example (to demonstrate reasoning)

Assume a training project:

Activity A: Develop training content (3 days)
Activity B: Design facilitator slides (2 days)
Activity C: Schedule training sessions (1 day)
Activity D: Deliver training (4 days)

Dependencies:

B depends on A (B cannot start until A is complete)
C depends on B (training sessions scheduled after slides designed)
D depends on C (training cannot deliver until scheduled)

A exam-friendly way to write it:

A finishes in 3 days
B finishes in 3 + 2 = 5 days
C completes in 5 + 1 = 6 days
D completes in 6 + 4 = 10 days
So the total duration is 10 days, and the chain A→B→C→D is critical.

2.5 Budgeting: Linking Schedule to Cost

Budgeting is not just numbers; it is a translation of workload and time into cost assumptions.

Common cost elements:

labour (hours × rate)
materials (quantities × unit cost)
subcontractors
equipment rental
travel and accommodation
contingency and reserves

A useful exam habit:
When you show budgets, include assumptions:

Do you assume full-time work?
Do you include overtime?
Are contractor costs fixed per job or hourly?
What is the contingency basis (percentage of estimated cost, risk-based, or both)?

2.6 Stakeholder Identification and Power–Interest Mapping

Stakeholders include anyone impacted by the project or who can influence it. Exams often ask:

categorize stakeholders
propose engagement strategies

2.6.1 Power–Interest Matrix

Four categories:

High power, high interest: manage closely
High power, low interest: keep satisfied
Low power, high interest: keep informed
Low power, low interest: monitor with minimal effort

Example:
CRM implementation stakeholders:

Project sponsor (high power, high interest)
IT vendor (high power, low interest—depends on contract; can be transactional)
End users in departments (low power individually, high interest in usability)
General customers (very low power, low interest until impacts occur—e.g., minor changes to customer communication)

2.7 Communication Plan: What to Communicate, to Whom, and How Often

A communication plan helps avoid confusion and ensures timely escalation. Typical components:

audience (stakeholder group)
message purpose (status update, approval request, risk escalation)
format (email, meeting, dashboard, report)
frequency (weekly, bi-weekly, monthly)
owner (who sends it)
escalation path (who receives if unresolved)

Exam answer quality tip:
If your communication plan is generic (“send updates weekly”), it may score lower than a plan that specifies:

meeting frequency
approval thresholds
channels for urgent issues
reporting artefacts (e.g., progress report, risk register snapshot)

2.8 Stakeholder Engagement: Handling Resistance and Misaligned Expectations

High marks are often earned by showing you can manage interpersonal and political realities.

Common sources of resistance:

fear of change and job redesign
perceived cost burden
unclear benefits
past project failures

A strong engagement approach includes:

clear explanation of benefits (e.g., faster customer service, better reporting)
early involvement for high-interest stakeholders
training and support where new processes are introduced
clear acceptance criteria to avoid “scope creep disguised as quality expectations”

3) Executing and Controlling: Quality Management, Risk Management, Change Control, and Performance Monitoring

Planning alone does not guarantee success. Examiners typically want evidence that you can control the project in motion—especially through risk monitoring, quality assurance, change control, and performance measurement.

3.1 Quality Management: Assurance vs Control

Learners often mix up quality assurance and quality control:

Quality assurance (QA): process-focused activities ensuring work is done correctly (e.g., audits, standards compliance).
Quality control (QC): product-focused activities checking outputs (e.g., testing results, inspection outcomes).

A short course may not require advanced ISO standards knowledge, but you should clearly describe:

quality standards or acceptance criteria
verification and validation logic
metrics used to assess quality

Example:
In a building refurbishment project:

QA could include ensuring contractor follows a method statement for safe installation procedures.
QC could include verifying wall paint thickness meets specification, and checking that finish quality is consistent across rooms.

3.2 Quality Metrics and Acceptance Criteria (Exam-ready examples)

Possible quality metrics:

defect rate per deliverable
inspection pass rate
test case pass percentage
rework hours as percentage of planned effort
customer satisfaction ratings (if post-delivery survey exists)

Acceptance criteria examples:

“UAT pass rate must be at least 90% before sign-off”
“Training must cover all modules; attendance list and post-training assessment required”
“Deliverable document must be reviewed by project sponsor and compliance officer”

3.3 Monitoring & Controlling: The Logic of Tracking Progress

Monitoring involves collecting performance data; controlling involves comparing performance against baselines and taking corrective action.

Key artefacts/baselines:

scope baseline
schedule baseline
cost baseline

A strong exam answer explains:

how deviations are detected
how they are analysed (root cause)
what corrective actions are considered
how changes are formally processed

3.4 Change Control: Preventing Scope Creep

Change control is one of the most testable areas because it connects governance, planning, and stakeholder management.

A typical change process includes:

Change request submitted (what changed and why)
Impact assessment
- scope impact
- time impact
- cost impact
- quality impact
- risk impact
Review and approval decision
- steering committee/sponsor (as defined)
Implementation plan if approved
- update WBS, schedule, budget, documentation
Communication of change

Exam scenario example (CRM again):
A department requests a new report dashboard. You must assess:

additional design and configuration time
additional testing and training changes
possible licensing or performance impacts
whether it affects go-live date

If the project schedule cannot absorb it, the sponsor might approve:

extending deadline
increasing budget
or deferring the feature to a later phase

A high-mark answer shows you don’t reject the request outright—you handle it via impact assessment and governance.

3.5 Risk Management: From Risk Register to Risk Response

Risk management is commonly tested using a risk register and response strategies. Learners should differentiate types:

Threats: events that would harm the project (e.g., vendor delays)
Opportunities: events that would benefit the project (e.g., additional funding or improved performance outcomes)

3.5.1 Risk Likelihood and Impact

Often a risk is assessed by:

likelihood (e.g., Low/Medium/High)
impact (e.g., Low/Medium/High)
risk rating (e.g., matrix score)

While scales vary by institution, your exam answers should remain internally consistent. A typical approach:

High likelihood + high impact = critical risks
High likelihood + low impact = frequent issues
Low likelihood + high impact = watch and plan contingencies

3.5.2 Risk Response Planning

Common response strategies:

Avoid (eliminate risk cause)
Mitigate (reduce probability or impact)
Transfer (shift impact to a third party—e.g., insurance, contract clauses)
Accept (no active response; monitor, budget contingency)

For opportunities:

Exploit (ensure it happens)
Enhance (increase probability/impact)
Share (partner to benefit)
Accept (if you don’t want to invest actively)

Example risk register entries (table format):

Risk	Type	Likelihood	Impact	Response	Owner
Vendor delivery delayed	Threat	High	High	Mitigate: require milestone-based delivery contract; weekly status calls; maintain buffer in schedule	Vendor Manager
Key users refuse to attend training	Threat	Medium	Medium	Mitigate: schedule sessions at convenient times; get management support; offer recorded sessions	Change & Training Lead
Data migration issues due to poor data quality	Threat	Medium	High	Avoid/Mitigate: data cleansing plan before migration; trial migration runs; allocate extra testing time	Data Lead

3.6 Performance Monitoring: Earned Value Concepts (If Covered)

Some course material introduces Earned Value Management (EVM) at a conceptual level. If your short course includes performance indices, the core logic is:

compare planned work vs actual progress in terms of value earned
compute schedule and cost variance

Even if EVM isn’t fully assessed, the exam-friendly concept is:

measure performance against baseline, don’t only report activity completion

Exam phrasing that scores well:
“Progress reporting should be based on deliverables completed and value earned, not merely on time spent.”

3.7 Corrective Actions and Preventive Actions

Distinguish:

Corrective action: fix what has already gone wrong
Preventive action: reduce probability of similar issues recurring

A refurbishment example:

corrective: replace a defective component after inspection
preventive: revise supplier evaluation process after repeated quality failures

4) Integrated Project Management: Leadership, Procurement, Contract Management, Documentation, and Project Closure

Short courses frequently include integration themes: how multiple processes connect, how procurement decisions affect schedules, and how closure depends on proper documentation and acceptance.

4.1 Integration Management: The “Whole Project” View

Integration management means you coordinate:

scope, schedule, cost
quality and risk
stakeholder engagement and communications
approvals and change control

A common exam question asks you to “explain why integration matters.” A top answer uses an example:

If you update schedule due to a time-saving idea but don’t adjust the budget assumptions, cost overrun emerges.
If you approve scope changes without quality acceptance criteria, deliverables may not be accepted at end.

4.2 Project Leadership and Team Management

While project management is not identical to HR management, leadership is crucial:

motivate team members
clarify roles and responsibilities
manage conflicts
ensure effective communication

Exam-ready elements often include:

RACI chart (Responsible, Accountable, Consulted, Informed)
escalation procedures for unresolved issues
conflict resolution approaches (negotiation, mediation, prioritization)

Mini-scenario:
Two departments disagree on reporting requirements (CRM dashboards). The project manager should:

bring stakeholders to a structured requirement workshop,
document decisions as part of scope baseline,
confirm sign-off by the sponsor/steering committee where authority is defined.

4.3 Procurement and Supplier Management

Procurement affects risk and schedule. Typical procurement considerations in project management include:

make-or-buy decisions
tendering/quotation process (if relevant)
vendor selection criteria
contract terms affecting schedule and quality

Risks in procurement:

vendor delivery delays
quality non-conformance
cost increases due to change orders
payment disputes

Contract management exam expectations:

define acceptance criteria and inspection rights
link payment to milestones/deliverables
include service level commitments where possible
define change order process for vendor scope changes

Example:
If a subcontractor is responsible for installing ceiling boards, the contract should specify:

materials compliance requirements
inspection procedure
timeline for completion per phase
penalties or remedies for delay (where legally appropriate)

4.4 Documentation: What You Must Keep (and Why)

In many assessments, marks are awarded for knowing which documents exist and what purpose they serve. Key documents/records include:

project charter (purpose, objectives, high-level scope)
project management plan (integrated planning outputs)
WBS (scope decomposition)
schedule baseline (planned activities timeline)
cost baseline (budget allocation)
stakeholder register and engagement plan
risk register and risk response plan
quality plan and quality checklists
change log (approved and rejected changes with impacts)
status reports and meeting minutes
lessons learned register
closure report and acceptance forms

Exam argument:
Documentation isn’t “paperwork for its own sake.” It creates:

traceability (why decisions were made)
accountability (who approved what)
ability to learn and improve (lessons learned)

4.5 Managing Constraints in Real Projects: A Decision Framework

A common exam challenge is: “A change request is submitted. What do you do?” The correct approach is not to answer “approve” or “reject” immediately; instead:

confirm change request validity (is it real, can it be described?)
assess impact on scope, time, cost, quality, risk
check dependencies (does it affect other planned activities?)
consider alternatives (reduce scope elsewhere, phase delivery, re-sequence tasks)
decide based on governance authority and project objectives
update baselines and communicate

4.6 Project Closure: Acceptance, Handover, and Lessons Learned

Closure is often overlooked by students, but exams frequently test it. Closure should include:

final deliverable verification against acceptance criteria
formal acceptance sign-off
transition/handover to operations or client
documentation storage and archiving
lessons learned (what worked, what didn’t, what to improve next time)

Mini-case example (Training project closure):
At closure, you need:

attendance registers
facilitator reports
assessment results (e.g., pre- and post-training)
UAT or operational acceptance sign-off
a final stakeholder briefing (including benefits realised and remaining support needed)

4.7 Common Closure Pitfalls (and how to answer in exams)

Pitfalls include:

closing without formal acceptance, leading to disputes later
not transferring knowledge properly to operations
ignoring lessons learned due to “time pressure”
leaving change requests unresolved without documented decisions

High-mark answers explicitly link closure activities to risk reduction and stakeholder satisfaction.

5) Exam Preparation: Typical Assessment Themes, Worked Scenarios, and Integrated Answers

This final section focuses on how NWU-type short course project management assessments often look and how to craft answers that maximize marks. It includes worked scenarios aligned to likely question types: conceptual explanations, diagram interpretation (WBS/stakeholder mapping), applying risk response, and writing change control justification.

5.1 How to Structure Answers for Maximum Marks

A practical framework:

Define the concept (one or two sentences, accurate and clear)
List key components (bullets, using correct terminology)
Apply to the scenario (use the case facts)
Justify your decision (explain impact on scope/time/cost/quality/risk)
Conclude with an outcome (what approval, what update, what next action)

This structure prevents the common “definition-only” response that earns limited marks.

5.2 Scenario-Based Practice Set (CRM Implementation)

Use the following consistent mini-scenario across exercises:

Scenario: A retail chain implements a CRM system across two departments before a national sales campaign. The sponsor requires delivery by 10 weeks. A vendor is contracted to deliver configuration and migrate customer data. Training must be completed before go-live. End users request additional reporting dashboards during testing.

5.2.1 Question Type: Risk Identification and Response

Prompt (typical): Identify 4 project risks and propose suitable response strategies.

Model answer (example):

Vendor configuration delay
- Threat: Likelihood High, Impact High
- Response: Mitigate by milestone-based delivery contract, weekly progress reviews, schedule buffer
Data migration errors due to incomplete legacy fields
- Threat: Likelihood Medium, Impact High
- Response: Mitigate by data cleansing sprint, trial migration, allocate extra testing time
End users resist new workflow
- Threat: Likelihood Medium, Impact Medium
- Response: Mitigate by early involvement, training tailored to department roles, support materials
Scope creep: additional dashboards requested during UAT
- Threat: Likelihood High, Impact Medium
- Response: Transfer/mitigate by enforcing change control, prioritise dashboards via backlog, defer non-critical items to post go-live release

Marks improve when you include both likelihood and impact logic and when response strategies match risk nature.

5.2.2 Question Type: Change Control Justification

Prompt: A department requests 3 new dashboards during UAT. Explain what you do.

Model answer structure:

Record a change request (what dashboards, who requested, why)
Conduct impact assessment:
- Scope: add features; may require additional design/configuration
- Time: increases UAT testing duration and possibly delays go-live
- Cost: additional vendor hours and internal testing time
- Quality: risk of incomplete configuration and increased defect rate
- Risk: increased uncertainty during critical period
Present options to sponsor:
- approve now with possible deadline extension
- approve with trade-offs (reduce other items)
- defer to release 2 after go-live
Update baselines only after approval; communicate decision to stakeholders.

High-mark reasoning:
Do not treat “request” as “must do.” Use governance and impact assessment to align with sponsor constraints (10-week deadline).

5.3 Scenario-Based Practice Set (Construction/Facility Project)

Scenario: A company refurbishes a small office wing over 12 weeks. The project includes structural modifications, painting, and installing new electrical fittings. A safety officer reports that scaffolding access is limited in week 3 and must be scheduled carefully.

5.3.1 Question Type: Scheduling and Dependencies

Prompt: Show how you would structure dependencies for painting and electrical installation.

Model answer:

Electrical installation depends on completion of structural modifications (no scaffolding work clashes)
Painting depends on completion of electrical installation and inspection (so surfaces are ready and no rework occurs)
Scaffolding is a shared resource; schedule scaffolding-related activities in a sequence to avoid idle time and safety risks

You can state dependencies in words or with a simple order:

Structural modifications (Activity A)
Electrical installation and inspection (Activity B) depends on A
Painting preparation and painting (Activity C) depends on B
Final safety checks and finishing (Activity D) depends on C

Marks improve if you mention the resource constraint (scaffolding access) rather than only logical task ordering.

5.3.2 Question Type: Quality Assurance vs Quality Control

Prompt: Provide one QA and one QC activity for each major work package.

Model answer:

Structural modifications
- QA: verify contractor method statement and compliance checks before work starts
- QC: inspection of structural compliance after work completion
Electrical installation
- QA: confirm certified electricians are assigned and test procedures exist
- QC: test electrical circuits before cover-up/closure
Painting
- QA: ensure correct paint mix and surface preparation process is followed
- QC: finish inspection against specification (e.g., uniformity, coverage, defect checks)

5.4 Stakeholder Management Practice

Scenario: In both CRM and refurbishment projects, a stakeholder group requests additional features/improvements late in the timeline. The sponsor wants to avoid schedule slippage.

5.4.1 Power–Interest Mapping Task

Prompt: Identify stakeholders and place them into a power–interest matrix.

CRM example stakeholders:

Sponsor: high power, high interest
Project manager: high power, high interest
Vendor manager: high power, low interest (contract-based)
Department end users: low power individually, high interest
National campaign marketing team: high interest, moderate power (influences deadlines and messaging)
General customers: low interest, low power

A top answer then states engagement strategy for each quadrant:

manage closely (high power, high interest)
keep satisfied (high power, low interest)
keep informed (low power, high interest)
monitor minimal effort (low power, low interest)

5.5 Common Exam Traps and How to Avoid Them

Trap 1: Confusing planning with controlling

Students may write “we planned risk responses” when the question asks what to do during execution. Correct approach:

describe monitoring cadence, reviewing risk register, updating likelihood/impact, triggering responses.

Trap 2: Giving generic answers without connecting to the scenario

Example: “use change control” without stating impact analysis steps or governance approvals. Correct:

link to deadline constraints and acceptance criteria.

Trap 3: Not using correct terminology

Examples:

mixing QA and QC
calling WBS a schedule
confusing stakeholders with team members only

A good strategy is to write keywords explicitly.

Trap 4: Ignoring closure

Many short-course exams include closure concepts. If you answer only until execution, you lose marks. Correct:

acceptance, handover, documentation, lessons learned.

5.6 Integrated Worked Answer (Full Question Style)

Integrated prompt (representative):
“A sponsor requests a scope change during UAT. Explain how a project manager should handle it using governance, change control, and risk management. In your answer, also mention how quality acceptance will be ensured and what communication steps should be taken.”

Model integrated answer:

Receive and register the change request
- Document the request details (what changes, why it is needed, who requested it).
- Log it in the change log and confirm the current stage (UAT).
Governance and approval authority
- Identify who has authority to approve changes at UAT (steering committee or sponsor per the project governance plan).
- Inform relevant governance members that a change request has been submitted.
Impact assessment (scope, time, cost, quality, risk)
- Scope: additional dashboards/features expand deliverables.
- Time: estimate additional vendor configuration and internal testing time and evaluate whether the 10-week deadline can be maintained.
- Cost: calculate additional vendor and test/validation effort.
- Quality: increased regression risk; more defects likely unless testing is expanded.
- Risk: update risk register—e.g., “scope creep during UAT” threat likelihood increases.
Evaluate alternatives
- Option A: approve with deadline extension if sponsor accepts schedule trade-off.
- Option B: approve by deferring lower-priority dashboards to a release 2, preserving go-live date.
- Option C: reject or request clarification if the change is not aligned with acceptance criteria.
Update baselines only after approval
- If approved, update WBS, schedule baseline, cost baseline, and relevant quality/test plan details.
Quality acceptance ensures readiness
- Confirm that UAT acceptance criteria are maintained and that regression testing is performed for the new dashboards.
- Document test results and require sign-off by the sponsor or authorised acceptance authority.
Communication steps
- Communicate decision outcomes to end users, vendor, and internal teams.
- Explain what is included/excluded in the current UAT release and any deferrals.
- If delays or increased testing hours are required, communicate clearly the revised expectations and timeline.
Monitoring after change
- Review the risk register after implementation and monitor progress against updated schedule.
- Track defects and rework, and report status in the planned communication cadence.

Why this answers exam needs:
It integrates governance, change control, risk management, quality acceptance, and communications, demonstrating integrated thinking rather than isolated concepts.

5.7 Memory-Friendly Revision Checklist

Before an exam, use this checklist to ensure you can answer most question types:

Can you define projects vs operations?
Can you explain scope, schedule, cost, quality and how changes affect them?
Can you describe a WBS and why it matters?
Can you state scheduling concepts: dependencies and critical path (even at basic level)?
Can you create a stakeholder engagement strategy (power–interest) and propose communication frequencies?
Can you build a risk register with response strategies that match threat/opportunity types?
Can you execute change control: log → assess impacts → approve/reject → update baselines → communicate?
Can you distinguish QA vs QC with examples?
Can you outline closure: acceptance, handover, documentation, lessons learned?

Closing Note on Exam Readiness (Still Content-Relevant)

A learner who can translate concepts into structured, scenario-linked responses is the learner most likely to score well in NWU-style short course project management assessments. The core skill tested is reasoning under constraints: deadline pressure, stakeholder demands, quality expectations, and risks that evolve as the project progresses. Mastery means not just knowing the terminology, but consistently applying it to produce practical, defensible answers—whether identifying risks, building planning artefacts, approving scope changes, or ensuring closure and acceptance.