Bachelor of Commerce in Project Management (MANCOSA) Study Notes

A Bachelor of Commerce in Project Management at MANCOSA blends core business disciplines with applied project management practice: planning, scheduling, risk and procurement, governance, stakeholder management, and control. These study notes are written in an exam-focused style aligned with what students in South Africa typically look for—e.g., MANCOSA project management modules, plus cross-references to common themes found in South African university curricula (including the language used at Unisa and CUT for related business and project management content). The aim is to give you clear frameworks, reusable steps, and practical examples you can adapt to assignments and exam questions.

1) MANCOSA BCom Project Management: Curriculum Map, How to Study, and How Exam Questions Are Built

MANCOSA’s BCom in Project Management is structured around building competence across the project lifecycle. While module codes differ by year/registration track, the underlying learning outcomes and assessment styles tend to be consistent: students must demonstrate knowledge (definitions, principles, frameworks), application (calculations and decisions), and professional reasoning (justifications with stakeholder and governance considerations). In practice, exam papers and assignments often combine short theory questions with scenario-based tasks—where you must select the correct tool and apply it to the case.

1.1 Typical “cluster” themes across the lifecycle

Most project management content—whether branded at MANCOSA or mirrored at other South African institutions like UNISA (Business Management and related projects) and CUT (Operations/Project-related business themes)—clusters into the same lifecycle logic:

Initiation and governance
- Problem definition, feasibility, business case
- Roles: sponsor, project manager, steering committee
- Stakeholder identification and engagement
Planning
- Scope definition (requirements, deliverables)
- Work Breakdown Structure (WBS), scope baseline
- Scheduling (activities, sequencing, estimating)
- Budgeting, cost baseline
- Risk register and planning responses
- Quality planning and acceptance criteria
Execution and control
- Resource management, procurement
- Change control and performance reporting
- Monitoring & controlling using earned value and dashboards
Closing
- Lessons learned, transition to operations
- Closure documentation and final reporting

In exams, questions are rarely “pure theory.” Instead, they usually ask you to:

Identify which framework fits the scenario.
Produce the expected output (e.g., a WBS outline, a risk matrix table, an argument for a governance decision).
Justify decisions in plain language using project management terminology.

1.2 How MANCOSA-style exam questions often look

A typical mixture might include:

10–20% definition and concept checks: “Explain the difference between a project and operations,” “Define risk appetite,” “What is a baseline?”
40–60% scenario application: given a case with dates/costs/risks, compute something or select responses.
20–40% short essays: “Discuss stakeholder influence vs interest,” “Justify a procurement strategy,” “Recommend a control approach.”

Key exam skill: You don’t just answer—your answer must follow the logic chain:

Use the right concept/tool
Apply it to the scenario facts
Provide a clear conclusion (“therefore…”)

1.3 Study method that works for project management exams

A reliable approach for BCom project management modules:

Learn the language
- Baseline, change request, constraint, assumption
- Risk likelihood vs impact
- Milestone, critical path, float
- Earned value: PV, EV, AC, CV, SV, CPI, SPI
Build a “framework bank”
- Stakeholder register template
- Risk register template
- WBS and schedule planning checklist
- Procurement decision checklist
- Quality planning checklist
Practice calculations early
- Scheduling: forward/backward passes, critical path
- Budgeting/control: earned value and variance interpretation
- Break-even and feasibility style computations if included in your module
Write “justification paragraphs”
- Examiners reward well-structured reasoning.
- Use a repeating pattern:
  - Observation (from the scenario)
  - Principle (tool/concept)
  - Action (what you recommend/do)
  - Why (benefits and constraints)

1.4 Common “gotchas” in exams (and how to avoid them)

Confusing project scope with product requirements
- Scope is what work must be done to deliver the product deliverables.
Mixing risk with issue
- A risk may happen (uncertain), an issue has happened (certain).
Using dates without checking dependencies
- In network scheduling, sequencing logic matters.
Earned value interpretation errors
- CPI = EV/AC (cost efficiency), SPI = EV/PV (schedule efficiency).
Quality vs acceptance
- Quality planning ensures processes/product meet requirements; acceptance is formal sign-off.

1.5 A mini “case” to practise how questions are framed

Imagine a scenario: A company is building a retail kiosk system. Stakeholders include store managers (power/high interest), IT staff (power/low interest), and customers (low power/high interest). The project has fixed end date requirements, limited skilled technicians, and a supplier that has missed delivery twice.

An exam might ask you to:

Identify stakeholders (use a matrix)
Create a risk response plan for the supplier risk
Explain the governance decision: whether to approve change requests for additional kiosk features
Compute schedule impact if a critical activity slips by 3 days and determine float consequences

Your job is to match each sub-question with the correct tool and show applied reasoning.

2) Project Initiation and Governance (MANCOSA): Business Case, Stakeholders, Scope Definition, and Legal/Professional Context

Initiation and governance are where projects succeed or fail long before a schedule is even printed. In many BCom project management modules, students underprepare the “why” and “who decides.” Exams often reward answers that show you understand accountability, decision-making, and how governance structures prevent unmanaged change.

2.1 The business case: turning need into a decision

A business case explains:

The problem/opportunity
Expected benefits (financial and non-financial)
Costs and risks
Feasibility and alternatives
Options and decision criteria

In exams, business case questions usually test whether you can distinguish:

Outcome/benefit (what changes for the organisation)
Deliverables (what the project produces)
Activities (how the project produces them)

Example: business case elements (retail system)

Suppose the project is to implement an inventory scanning system for stores:

Problem: Inventory inaccuracies causing lost sales.
Benefits: reduced stockouts, faster stock counts, better reporting.
Costs: software licences, training, implementation consultancy, hardware.
Risks: supplier delays, user adoption risk, data migration errors.
Alternatives: buy vs build; in-house vs outsourced rollout.
Decision: proceed if ROI threshold met and timeline within constraints.

Even if you’re not asked to compute ROI, you must demonstrate the structure: justify the project’s existence and link it to organisational goals.

2.2 Project governance: roles, committees, and decision rights

Governance answers “who has authority to decide what.” In projects, governance prevents:

“CEO-level” decisions happening informally without documentation
Scope and budget creep without approval
Conflicts between sponsor expectations and project execution realities

Common roles:

Project Sponsor: owns the business need; authorises resources; clears escalations.
Project Manager: responsible for planning/execution/control; manages team and reporting.
Steering Committee / Governance Board: reviews performance, approves major changes.
Functional Managers: provide resources and manage functional constraints.
PMO (if applicable): standards, templates, and oversight.

Governance in exam answers: what to include

Which body approves major scope changes?
What reporting cadence exists (weekly status, monthly steering updates)?
How are escalations handled if risks materialise?

2.3 Stakeholder analysis: influence vs interest and how to respond

A classic exam tool is the stakeholder power/interest grid. You place stakeholders based on:

Power: ability to influence resources, decisions, or approval.
Interest: how engaged/impacted they are.

Typical categories:

High power / High interest: manage closely (keep satisfied, frequent communication)
High power / Low interest: keep informed (brief, periodic updates)
Low power / High interest: keep informed/collaborate (consult regularly)
Low power / Low interest: monitor (minimal effort)

Example stakeholder register (mini-template)

Stakeholder	Power	Interest	Interest/Need	Likely Concerns	Communication Plan
Project Sponsor	High	High	Benefits realisation	Costs/time overruns	Monthly steering, escalation
Store Managers	High	High	Store performance improvement	Disruption to daily operations	Bi-weekly training sessions + feedback loop
IT Staff	Medium/High	Low	System stability	Extra workload	Technical workshops monthly
Customers	Low	High	Faster service	Privacy and usability	Surveys, user testing sessions

In exams, the best answers go beyond the grid:

Provide specific communication actions (workshops, trainings, sign-offs).
Mention how you handle resistance: training, demonstrations, phased rollout.

2.4 Scope definition and the scope baseline

Scope work defines:

What is included (deliverables, acceptance criteria)
What is excluded (important for avoiding scope creep)
Constraints and assumptions
Requirements (functional/non-functional in many cases)

A scope baseline usually includes approved scope statements and WBS. Any change requires change control.

Exam distinction: requirements vs deliverables

Requirements describe “what the system must do.”
Deliverables are tangible outputs produced by the project.

2.5 Change control: how governance stops scope creep

Change control is the process of managing requests so that:

Changes are evaluated for impact on time/cost/scope/quality
Approvals happen via agreed authority
Approved changes update baselines

Key exam elements:

Change request submitted (what changes, why)
Impact assessment
- Schedule impact: which activities shift and by how much?
- Cost impact: additional labour/materials?
- Quality impact: rework?
Recommendation
- Approve / reject / defer
Decision and documentation
Update baselines and communicate

Example scenario: feature addition

A sponsor requests adding a “mobile reporting dashboard.” Impact assessment includes:

New requirements for data visualisation
Integration testing time
Additional developer days
Potential risk: delays in data availability
Decision might be: approve but only after milestone M2, funded by contingency.

2.6 Quality in initiation: acceptance criteria and standards

Quality planning starts early. Many modules ask how you define:

Standards and policies to follow
Acceptance criteria for deliverables
Methods for quality assurance vs quality control

Quality assurance (QA): process-focused (“are we doing the right process?”)
Quality control (QC): product measurement (“does it meet specs?”)

Example

If delivering a software module:

QA: coding standards, peer reviews, automated testing strategy
QC: performance testing results, defect thresholds, sign-off criteria

2.7 Professional context and risk-aware governance

South African business environments emphasise compliance, ethics, and governance. In project management exams, even when legal details aren’t asked, your answers should be risk-aware:

procurement rules and approval processes
data privacy considerations (especially for system projects)
conflict management and record keeping

Even without citing statutes, demonstrate:

you document decisions
you control change
you manage stakeholder expectations

3) Planning Tools: WBS, Scheduling (Critical Path), Budgeting, Risk Management, and Procurement Strategy

Planning is where you transform objectives into work you can execute and control. In BCom project management exams, you’ll typically need to demonstrate structured thinking: build the WBS, derive a schedule, estimate costs, and create a risk and procurement plan.

3.1 Work Breakdown Structure (WBS): from deliverables to work packages

A WBS is a hierarchical decomposition of the project scope into manageable components:

Level 1: major deliverables
Level 2+: sub-deliverables
Lowest level: work packages (detailed scope, deliverable ownership, measurable outputs)

Why WBS matters in exams

It supports accurate estimating and scheduling.
It forms the basis for cost baseline.
It defines what gets tracked in performance reporting.

Example: building the WBS for a “training rollout project”

Deliverable: Training rollout

Sub-deliverable: Training materials
- Content writing
- Slide development
- Translation/review
Sub-deliverable: Training delivery
- Trainer scheduling
- Venue booking
- Participant invitations
Sub-deliverable: Evaluation and handover
- Knowledge tests
- Feedback collection
- Final report and sign-off

Your WBS does not need to be extremely detailed in an exam—but it must show logic and measurable outputs.

3.2 Scheduling fundamentals: dependencies, durations, and milestones

A project schedule uses:

Activities: tasks to be completed
Dependencies: relationships between activities
Durations: how long each activity takes
Milestones: key completion points without detailed duration

Typical dependency types:

Finish-to-Start (FS): A must finish before B starts
Start-to-Start (SS): A and B start together (less common in simplistic exams)
Finish-to-Finish (FF) and others may be mentioned but often FS dominates exam problems.

3.3 Critical Path Method (CPM): building and interpreting the network

CPM requires:

Identify activity durations and dependencies.
Perform forward pass to calculate earliest start/finish.
Perform backward pass to calculate latest start/finish.
Identify activities with zero float; the longest path is the critical path.

Worked exam-style example (single network)

Consider these activities (durations in days):

A (2d) start
B (4d) FS after A
C (3d) FS after A
D (2d) FS after B
E (5d) FS after C
F (1d) FS after D and E (must wait for both)

Compute:

Forward pass (Earliest times)

A: ES 0 → EF 2
B: ES 2 → EF 6
C: ES 2 → EF 5
D: ES 6 → EF 8
E: ES 5 → EF 10
F: ES = max(EF of D=8, EF of E=10) = 10 → EF 11

Backward pass (Latest times)
Project finish = 11 (EF of F)

F: LF 11 → LS 10
D and E feed into F:
- D must finish by LF of F’s dependency; since F ES is 10, D’s EF latest = 10 → D duration 2 → LD?
  Let’s compute precisely:
- For D (duration 2): if D finishes by 10, then DL? (latest finish = 10) → latest start = 8
- For E (duration 5): latest finish = 10 → latest start = 5

Now determine floats:

A leads to B and C; compute using downstream constraints.
- B latest finish = 8? Wait: B feeds D; D latest finish = 10, D duration 2 → D latest start 8, so D earliest start depends. But B finishes to start D:
  - B → D FS, so B EF must be ≤ D LS (8).
    Therefore B latest finish = 8 → B latest start = 4 → B float = (LS – ES) = 4 – 2 = 2 days (non-critical)
- C → E FS, so C EF must be ≤ E LS (5).
  C EF earliest = 5, so float 0 (critical path through C)
A → B and C: A EF earliest = 2. Latest finish for A must satisfy both B and C:
- A EF ≤ min(B LS=4, C LS=2) = 2 → A latest finish 2 → A latest start 0 → float 0

Thus critical path is: A → C → E → F, total duration 2 + 3 + 5 + 1 = 11 days.

Interpreting results in exam answers

If a critical activity slips, project finish date changes unless mitigation occurs.
If a non-critical activity slips within float, finish date may remain unchanged.

3.4 Schedule impact of delays: quick exam reasoning

Suppose activity E (duration 5) slips by 2 days.

E earliest finish increases from 10 to 12.
Since F must wait for both D and E, F earliest start becomes max(D EF 8, E EF 12) = 12.
Then F finishes at 13 (since duration 1).

So the project finish date increases from 11 to 13 days—a 2-day delay, because E lies on the critical path.

This type of logic question is common: you don’t need to redraw the whole network if you understand critical dependency chains.

3.5 Budgeting and cost baseline: estimate, aggregate, approve

Cost planning often includes:

Cost estimation by resources and rates
Contingency reserves
Funding limits (cash flow management)

A cost baseline includes:

Estimated costs by time (sometimes monthly)
Approved total cost target
Assumptions and constraints

Example cost estimation pattern

Labour: number of person-days × day rate
Materials: quantity × unit price
Equipment: rental × days
Travel: trips × cost per trip

In exams, if you’re given a simplified cost breakdown, you must:

total costs accurately
explain what is included vs excluded
separate contingency from base cost if the question indicates it

3.6 Risk management: from identification to response planning

Risk management is one of the most frequently examined topics in project management curricula.

Core steps:

Identify risks
Assess likelihood and impact
Prioritise (risk matrix, scoring)
Plan responses
Monitor and control (track changes)

Risk vs issue

Risk: uncertain event (may happen)
Issue: occurred (certain)
Exam questions often try to trick you by describing something that has “already happened.” That is an issue, not a risk.

3.7 Risk matrix and risk scoring (with a consistent example)

Suppose you score:

Likelihood (L): 1–5
Impact (I): 1–5
Risk score = L × I

Example risks:

Supplier delay
- L = 4, I = 4 → score 16 (high priority)
Skill shortage
- L = 3, I = 3 → score 9 (medium)
Stakeholder resistance
- L = 2, I = 4 → score 8 (medium)

Response options (choose based on risk type):

Avoid: change plan to remove risk
Mitigate: reduce likelihood/impact
Transfer: insurance/contractual risk transfer
Accept: contingency reserve; monitor closely

Response planning for supplier delay

If supplier delay affects schedule:

Mitigate: multiple supplier quotes, expediting options
Transfer: penalty clauses in contract
Avoid: change procurement strategy (dual sourcing)
Accept: only if contingency exists and schedule float allows

3.8 Procurement strategy: make-or-buy decisions and contracting approaches

Procurement is often examined through scenario-based questions: decide between procurement methods, define procurement planning, and manage vendor risk.

Key concepts:

Make vs buy
Contract type (e.g., fixed price vs time and materials—conceptual)
Tendering/quotation
Supplier evaluation criteria
Contract management

Example: make-or-buy scenario

A company needs a specialised component:

Make internally: cost lower but takes longer due to learning curve
Buy: faster but risk supplier delay and higher unit cost

An exam answer should link procurement decisions to:

schedule constraints (deadline)
quality requirements
risk tolerance and governance approvals
available resources

3.9 Quality planning and control during execution (brief bridge)

Planning should include how you will ensure quality later:

quality assurance activities
quality control checkpoints
acceptance tests and sign-off procedures

Often, exam questions ask: “What quality control method would you use for this deliverable?” Your answer should be precise:

inspection checklists
test plans
sample size logic (if specified)
acceptance criteria referencing requirements

4) Monitoring & Controlling: Earned Value, KPIs, Change Impact, Risk Watch, and Reporting

Monitoring and controlling is where many students underperform because they focus only on planning. Examiners want evidence you understand performance measurement, interpretation, and corrective action.

4.1 Control mechanisms: what you monitor and why

Typical project controls:

Scope control: ensure deliverables match scope baseline
Schedule control: ensure progress aligns with plan
Cost control: ensure spending aligns with budget
Quality control: ensure deliverables meet standards
Risk control: monitor identified risks and detect new ones
Stakeholder control: manage expectations and communication effectiveness

A good exam answer names control objectives and links them to performance data.

4.2 Earned Value Management (EVM): the core calculation set

EVM compares:

PV (Planned Value): what work should cost by a given date
EV (Earned Value): what work actually completed would have cost under the plan
AC (Actual Cost): what you really spent for the work completed

Common metrics:

Cost Variance (CV) = EV − AC
Schedule Variance (SV) = EV − PV
CPI = EV / AC (cost efficiency)
SPI = EV / PV (schedule efficiency)

Exam interpretation rules (must be memorised)

CV < 0 → cost overrun
SV < 0 → schedule behind plan
CPI < 1 → poor cost efficiency
SPI < 1 → behind schedule

4.3 Worked EVM example (fully consistent numbers)

Suppose by week 6:

PV = R500,000 (planned value by that time)
EV = R420,000 (earned value for the work actually completed)
AC = R480,000 (actual cost spent)

Compute:

CV = EV − AC = 420,000 − 480,000 = −R60,000
SV = EV − PV = 420,000 − 500,000 = −R80,000
CPI = EV / AC = 420,000 / 480,000 = 0.875
SPI = EV / PV = 420,000 / 500,000 = 0.84

Interpretation:

Cost performance is worse than planned (CPI < 1 and CV negative).
Schedule performance is behind (SPI < 1 and SV negative).

A high-scoring exam response adds corrective action ideas:

Analyse why costs are high: overtime? rework? poor procurement?
Analyse why progress is behind: delays? missing inputs? dependency issues?
Propose a corrective plan: re-sequence tasks, adjust resource allocation, enforce change control.

4.4 Corrective and preventive actions: “what to do next”

Monitoring data triggers:

Corrective actions: bring performance back on track
Preventive actions: reduce risk of future slippage
Change requests: if corrective actions require scope/time/budget change

In exam scenarios, you should:

avoid generic statements (“work harder”)
specify mechanisms: adjust schedule baseline, re-plan resources, request supplier acceleration, approve additional budget contingency, etc.

4.5 KPI dashboards and reporting cadence

Modules often ask for reporting formats and what to include. Even without a formal template, a good report includes:

Progress summary: % complete by deliverable
Variances: schedule/cost (and reasons)
Risk status changes
Issues requiring escalation
Forecast: estimate to complete (EAC) if included in the module
Next reporting period plan and dependencies

Example reporting narrative (short but structured)

“Earned value indicates behind schedule: SV −R80,000; and cost overrun: CV −R60,000.”
“Root causes: Supplier delay for component X; rework due to requirement change.”
“Corrective action: renegotiate supplier delivery plan; implement revised QA checkpoints; submit change request for additional labour.”
“Risks to watch: stakeholder adoption risk; additional approvals for extended working hours.”

4.6 Change impact assessment under control

When a change request arrives, you evaluate:

schedule shift: which critical activities affected?
cost increase: labour/material changes
quality impact: testing and acceptance modifications
risk change: does it create new risks?

Exam tip: “critical path awareness”

If a change affects a critical activity, you can argue for greater timeline impact than if it affects a non-critical activity.

4.7 Risk watch and risk register updates

Monitoring and controlling risk includes:

tracking risk triggers (if/when indicators occur)
updating likelihood/impact
closing risks when response becomes effective
adding new risks uncovered by execution realities

A strong exam answer suggests:

how risks are escalated
how contingency plans are activated
how the project manager ensures stakeholders remain informed

4.8 Procurement and vendor performance control

Procurement control measures:

vendor delivery performance (on-time in-full)
quality of supplied goods
compliance with contract terms
payment milestones tied to accepted deliverables

If vendor delays occur:

escalate under contract management process
activate agreed mitigation clauses
reassess schedule and budget forecast

5) Capstone Integration: Putting It All Together with South African University-Style Topics, Case Practice, and “Answer Patterns” for MANCOSA + Related BCom/Project Modules

This final section consolidates the major exam competencies into repeatable answer patterns, using scenario practice that mirrors what South African students often face across MANCOSA, UNISA, and similar business programmes at institutions like CUT. The goal is not repetition—it is synthesis: combining initiation governance, planning tools, and controlling techniques into a coherent “full project” response.

5.1 Full-project case practice: from initiation to control

Assume a case: A municipality is implementing a digital procurement workflow to reduce processing time for vendor onboarding.

Project objectives:

reduce onboarding turnaround time
ensure compliance and auditability
improve stakeholder transparency

Key stakeholders:

Municipal procurement office (high power/high interest)
IT department (high power/low interest)
Vendors (low power/high interest)
Audit unit (medium power/high interest)

Constraints:

compliance requirements (must meet audit standards)
fixed go-live date
limited IT capacity during peak periods

Risks:

supplier/vendor data quality issues
IT resource conflicts
resistance to new workflow by internal users

Step-by-step “full exam answer pattern”

When asked to “outline the project approach,” structure your response like this:

Initiation
- Business case summary: why the project exists, expected benefits
- Governance: sponsor approval and steering decisions
- Stakeholder plan: power/interest and engagement
Planning
- Scope: deliverables, acceptance criteria, in/out of scope
- WBS: break deliverables into work packages
- Schedule: activity network and critical path reasoning
- Budget: cost baseline and contingency logic
- Risk register: identify, score, response
- Procurement: make/buy, contract approach, supplier evaluation
Execution and Control
- EVM if data provided (PV/EV/AC, variances)
- Change control: process steps and documentation
- Risk updates: triggers and mitigation activation
- Reporting: dashboard content and escalation
Closing
- Acceptance and handover to operations
- Lessons learned and improvement actions

Examiners reward completeness and clarity. If a question is partial (e.g., only asks for risk management), you still show the link to the lifecycle.

5.2 Answer pattern for stakeholder and communication questions

When asked: “Discuss stakeholder management,” avoid generic descriptions. Use a repeatable layout:

Identify stakeholders
Categorise on power/interest grid
Explain engagement strategy per category
Provide communication methods and frequency
Mention conflict management and escalation

Example statement

“High power/high interest: engage closely with bi-weekly sessions to confirm deliverable readiness and unblock decisions.”
“High power/low interest: provide monthly summary reports focusing on milestones, risks, and budget status.”
“Low power/high interest: consult through user workshops and incorporate feedback into training materials.”

5.3 Answer pattern for WBS and schedule questions

When asked: “Create a WBS and draft a schedule,” the expected logic is:

WBS: deliverables → work packages with measurable outputs.
Schedule: activities derived from work packages.
Dependencies: show how tasks rely on each other.
Critical path: identify the chain that determines project completion.

Common exam mistakes

Creating a WBS that lists activities (instead of deliverables/work packages).
Creating a schedule without dependencies.
Claiming critical path without float/zero-float reasoning (even if the question doesn’t demand full CPM tables).

5.4 Answer pattern for risk management questions

Risk questions often ask: “Identify risks and propose responses.” Strong answers:

List risks with short but specific descriptions.
Provide likelihood and impact scoring (or a risk matrix).
Prioritise top risks.
Provide responses (avoid/mitigate/transfer/accept).
Add triggers and owners (who monitors/acts).

Example response writing style

“Supplier delay risk (L4/I4=16): mitigate by dual sourcing and expediting options; transfer by including penalty clauses; monitor weekly supplier delivery performance; trigger escalation if deliveries slip by more than 5 working days.”

5.5 Answer pattern for EVM/control questions

When asked about performance:

Compute PV/EV/AC-based metrics if numbers are given.
Interpret variances using the CV/SV and CPI/SPI rules.
Provide root-cause hypotheses tied to scenario facts.
Recommend corrective actions (schedule, cost, scope, quality).
Link to change control if required.

If the question doesn’t provide EVM numbers, you can still discuss:

what data you would collect (progress measurements, cost tracking)
reporting cadence
how you decide escalation thresholds

5.6 Mini checklists you can memorise for exams

Planning checklist

Scope defined (deliverables + acceptance criteria)
WBS created to work-package level
Activity list and dependencies defined
Durations estimated and assumptions recorded
Budget estimated and contingency understood
Risk register created with response plans
Procurement strategy selected and vendor evaluation defined

Control checklist

Progress measurement method defined (% complete rules)
Cost tracking system aligned to WBS
Schedule variance monitored (critical path awareness)
Change control process followed
Risk register updated with triggers and owners
Reporting includes variances, risks, issues, and next steps

5.7 Consistent terminology: what exam markers expect

Use consistent, professional terms:

Baseline: approved plan for scope/time/cost.
Control: process of comparing actual vs planned and taking action.
Variance: difference between planned and actual/earned.
Milestone: significant event marking progress.
Float (total float): amount of time an activity can slip without affecting project completion.
Contingency: budget reserved for known unknowns.

Markers look for these terms because they signal correct conceptual framing.

5.8 South Africa relevance: integrating curriculum expectations and assignment practice

South African students often also engage with concepts that appear in related courses. For example:

UNISA commonly emphasises business planning, risk awareness, and structured written responses.
CUT programme work often integrates operational planning thinking and practical management reasoning.
Although you are studying specifically at MANCOSA, your writing style should align with how examiners in South Africa assess business modules:
structured answers
applied reasoning
clear assumptions where needed
legible tables and calculations

In assignments, your risk register and stakeholder register should be presented neatly, as these are “high marks” outputs. In exams, you may not have time to build full registers—so you must present concise versions while still hitting the required elements: likelihood, impact, response, and ownership.

5.9 Common scenario types and how to respond quickly

Scenario type A: “Schedule slips because supplier is late”

Response:

identify which activities affected
check whether affected activities are on critical path
propose procurement and schedule mitigation
update risk register and request change control if needed

Scenario type B: “Costs rising because rework”

Response:

link to quality failures and acceptance criteria
recommend QA/QC corrective actions
calculate EVM if numbers available, interpret CPI
re-baseline only if change is approved

Scenario type C: “Stakeholder resistance causes delays”

Response:

use stakeholder power/interest analysis
update engagement plan
propose workshops/training/feedback cycles
log issue and mitigate risk (adoption risk)

5.10 Final synthesis: what a top-scoring answer looks like

A top-scoring exam response usually has:

Correct definitions in the exact context of the question
Clear application of tools (WBS, critical path logic, risk scoring, EVM)
A consistent narrative across the project lifecycle
Calculations that are correct and explained briefly
Recommendations that are realistic and linked to scenario constraints

When you combine these, your answer reads like a project management professional document—not just study notes.

Quick Reference Tables (for last-minute revision)

Earned Value metrics (cheat sheet)

Metric	Formula	Meaning
CV	EV − AC	Cost overrun if negative
SV	EV − PV	Schedule behind if negative
CPI	EV / AC	Cost efficiency (<1 means overrun)
SPI	EV / PV	Schedule efficiency (<1 means behind)

Risk scoring concept

Likelihood (L)	Impact (I)	Score = L×I	Priority
1–2	1–2	1–4	Low
2–3	2–3	4–9	Medium
3–5	3–5	9–25	High

These study notes focus on the core competencies assessed in a MANCOSA BCom in Project Management context: governance and initiation, planning tools like WBS and CPM, risk and procurement strategy, and control via performance monitoring including earned value. Use the answer patterns, practise the calculations, and ensure your exam writing connects tools to scenario facts with clear, justified recommendations.