UNISA BCom in Business Management: Project Management Focus Notes (CEM/EMS/EMG-Project-Style)

These notes support UNISA BCom in Business Management students who are studying Project Management concepts from the perspective of practical management—planning, scheduling, resourcing, risk, cost control, quality, procurement, stakeholder communication, and project governance. The focus is exam-relevant: how to define projects, build and evaluate a project plan, manage the triple constraint, and justify decisions using recognised frameworks such as the PMBOK®-style knowledge areas, the waterfall vs agile spectrum, and core project controls.

The guide is written to align with how South African universities commonly teach project management in College of Economic and Management Sciences (CEMS) contexts (including UNISA and comparable content from CUT and UKZN-style project governance topics), using terminology you are likely to see in course material and past exam papers—especially around project scope, work breakdown structure, network scheduling, costing, risk responses, and progress reporting.

1) UNISA Project Management Foundations (Business Management Lens for BCom)

Project management is often presented as a set of tools, but in a Business Management programme it is best understood as a discipline that connects strategy to execution. A BCom student is expected not only to “know the steps”, but also to justify choices: why a certain scheduling method is appropriate, why scope control matters, how stakeholder conflict affects delivery, and how cost and risk decisions trade off against each other.

1.1 What “a project” means in exam questions

A typical exam question distinguishes between a project and operations (business as usual). A project is a temporary endeavour with a defined start and finish, producing a unique output—whether that output is a system, a building, a service improvement, or a process redesign.

You should be able to apply the definition to scenarios such as:

• Implementing an ERP system at a retail chain (unique deliverable, finite timeline).
• Launching a new product line with marketing campaigns and supply chain setup (temporary with unique outputs).
• Building a wind farm substation for a renewable energy programme (finite delivery with technical milestones).

Key differentiators you should explicitly mention in answers:

1. Temporariness: has deadlines or end-state conditions.
2. Uniqueness: not repetitive routine work.
3. Specific deliverables: outputs with acceptance criteria.
4. Constraints: time, cost, scope, and quality expectations.

1.2 The triple constraint and why it’s not “just a triangle”

Many students memorise “time-cost-scope-quality” as the triple constraint, but exam markers want you to show understanding of how trade-offs happen. A project plan must balance:

• Scope: what work is included (and what is excluded).
• Schedule: when work is completed.
• Budget/Cost: how much the project can spend.
• Quality: how well deliverables meet requirements.

A useful way to answer: treat it as a set of constraints that influence each other.

Example trade-off scenario (consistent, exam-style)

Suppose a university IT project must integrate with student registration systems by a fixed semester start date.

• If scope increases (more integrations), schedule may slip.
• To keep schedule fixed, cost may rise (additional developers, overtime, vendor support).
• If cost is fixed and scope must stay, quality may be reduced (fewer tests), increasing risk of defects.

In exam essays, you should tie these to management actions:

• scope reduction or clarification,
• schedule compression with risk (e.g., crashing),
• contingency budgets and risk mitigation,
• quality assurance planning to protect acceptance criteria.

1.3 Project life cycle: from initiation to closure

UNISA-style project management content often expects a life cycle understanding. A typical life cycle is:

1. Initiation
   • Identify the problem/opportunity.
   • Prepare the project charter (high-level objectives, authority, initial stakeholders).
2. Planning
   • Develop plans for scope, schedule, cost, quality, resources, risk, communications.
3. Execution
   • Coordinate resources and perform the work.
4. Monitoring & Controlling
   • Track performance, manage change, implement corrective actions.
5. Closing
   • Deliver final product, obtain acceptance, document lessons learned.

Why life cycle matters for exams

Markers often ask: “At which stage is stakeholder engagement most critical?” or “When is risk highest?” You should know the general patterns:

• Early on, there is high uncertainty, so risk analysis is crucial.
• During planning, commitments become costly to change—so scope definition and estimating must be done carefully.
• During execution, monitoring ensures that changes are controlled and performance meets targets.

1.4 Project governance and the role of business management

In Business Management contexts, governance is not only about compliance. It’s about how decisions are made and how accountability is structured.

Common governance elements include:

• Project sponsor: senior authority, provides direction and resources.
• Project manager: day-to-day leadership of the project plan and execution.
• Steering committee: reviews progress, approves major changes, resolves escalation issues.
• Quality manager / QA team: defines acceptance criteria and audits compliance.
• Procurement/contract management: manages vendors and contract deliverables.
• Stakeholders: internal and external parties affected by the project outcome.

When answering questions, you should link governance to measurable outcomes:

• approval gates for scope changes,
• reporting cadence (weekly status, monthly steering committee),
• defined acceptance criteria at milestones.

2) UNISA Project Planning: Scope, WBS, Scheduling, and Costing

This section covers the core “planning” mechanisms that appear repeatedly in exams: scope statements, work breakdown structures (WBS), network diagrams, critical path concepts, and estimating/costing. The aim is to help you write structured, high-scoring answers—especially when questions ask you to “construct” or “explain” a plan.

2.1 Scope management: from requirements to scope baseline

2.1.1 Requirements vs deliverables vs scope baseline

A strong project answer distinguishes these terms:

• Requirements: what the project must do (functional and non-functional needs).
• Deliverables: tangible outputs (reports, software modules, training sessions, infrastructure components).
• Scope baseline: approved scope plan consisting of the scope statement, WBS, and WBS dictionary.

2.1.2 Writing a scope statement (exam format)

A scope statement usually includes:

1. Project justification (why it exists)
2. Objectives (SMART objectives: Specific, Measurable, Achievable, Relevant, Time-bound)
3. Deliverables (what will be produced)
4. In scope / out of scope boundaries
5. Assumptions and constraints
6. Acceptance criteria (how deliverables will be approved)

Example objective set (consistent)

For a hypothetical project: “Implement a student feedback system to improve service quality.”

• Objective 1: “Launch an online feedback form by 30 September 2026.”
• Objective 2: “Achieve 90% response rate within the first month after launch.”
• Objective 3: “Reduce average resolution time of student complaints by 15% within 3 months after deployment.”

Even if an exam scenario provides these numbers, you must show that you understand how objectives guide scope and scheduling.

2.2 Work Breakdown Structure (WBS): how to score marks fast

The WBS is the backbone of planning. It breaks the project work into manageable components.

2.2.1 What a WBS does

A WBS:

• ensures completeness (everything needed is captured),
• supports scheduling (each work package has an activity and duration),
• supports costing (each work package can be estimated),
• enables tracking and control (progress measured at the work package level),
• improves communication (clear responsibility areas).

2.2.2 WBS levels and granularity

A typical WBS uses hierarchical levels such as:

• Level 1: Major deliverables
• Level 2: Sub-deliverables
• Level 3+: Work packages

You are expected to show the link between WBS and scheduling: activities are often derived from work packages.

2.2.3 Sample WBS for a service improvement project

Consider a project: “Set up a departmental procurement portal for purchasing requests.”

• 1.0 Project Management
  • 1.1 Project charter & governance setup
  • 1.2 Stakeholder engagement meetings
  • 1.3 Risk register and change control
• 2.0 Requirements & Design
  • 2.1 Business requirements workshop
  • 2.2 Process mapping (request to approval)
  • 2.3 System design document
• 3.0 Development & Configuration
  • 3.1 Configure portal workflows
  • 3.2 Build approval rules
  • 3.3 User access setup
• 4.0 Testing & Training
  • 4.1 Test scripts & test execution
  • 4.2 UAT (user acceptance testing)
  • 4.3 Training materials and sessions
• 5.0 Rollout & Close-out
  • 5.1 Go-live support
  • 5.2 Documentation handover
  • 5.3 Lessons learned workshop

A marker looks for: logical deliverable grouping, not random task listing. Also, each work package should be small enough to estimate and track.

2.3 Scheduling: precedence, networks, and the critical path mindset

Project scheduling turns the WBS into a timeline.

2.3.1 Activities, durations, and dependencies

In scheduling, define:

• Activity: work element (often derived from work package).
• Duration: time needed to complete activity.
• Precedence relationship: how activities depend on each other.

Common dependency types:

• Finish-to-Start (FS): activity B starts after A finishes.
• Start-to-Start (SS): B can start after A starts.
• Finish-to-Finish (FF): B can finish after A finishes.
• Start-to-Finish (SF): rare in practice.

Most exam network problems use FS dependencies.

2.3.2 Network diagram and forward/backward pass (conceptual)

The critical path method (CPM) involves:

• Forward pass: compute earliest start (ES) and earliest finish (EF).
• Backward pass: compute latest start (LS) and latest finish (LF).
• Slack/float: LS – ES or LF – EF.
• Critical activities: zero slack (or minimal slack depending on exam convention).

You should be prepared to explain critical path logically:
If an activity has zero float, delaying it delays the entire project (unless change control changes the plan).

2.3.3 Example mini-network calculation (consistent and exam-friendly)

Assume a project has these activities (FS dependencies):

• A: Duration 3 days (start)
• B: Duration 4 days (after A)
• C: Duration 2 days (after A)
• D: Duration 5 days (after B)
• E: Duration 3 days (after C)
• F: Duration 1 day (after D and E)

Let’s compute:

Forward pass

• A: ES 0, EF 3
• B (after A): ES 3, EF 7
• C (after A): ES 3, EF 5
• D (after B): ES 7, EF 12
• E (after C): ES 5, EF 8
• F (after D and E): ES max(12, 8) = 12, EF 13

Project duration = 13 days.

Backward pass (working backwards from project finish = 13)

• F: LF 13, LS 12
• D: LF = LS of F = 12, LS = 12 – 5 = 7
• E: LF = LS of F = 12, LS = 12 – 3 = 9
• B: after B is D; so B LF = LS of D = 7; LS = 7 – 4 = 3
• C: after C is E; so C LF = LS of E = 9; LS = 9 – 2 = 7
• A: after A are B and C; so A LF = min(LS of B, LS of C) = min(3, 7) = 3; LS = 3 – 3 = 0

Slack:

• A: LS 0 – ES 0 = 0 (critical)
• B: LS 3 – ES 3 = 0 (critical)
• C: LS 7 – ES 3 = 4 slack (non-critical)
• D: LS 7 – ES 7 = 0 (critical)
• E: LS 9 – ES 5 = 4 slack (non-critical)
• F: LS 12 – ES 12 = 0 (critical)

Critical path: A → B → D → F with total duration 3 + 4 + 5 + 1 = 13 days.

In your written responses, show you can interpret slack and criticality.

2.4 Cost management: estimating, budgets, and cost control logic

2.4.1 Estimating approaches

Common estimation methods include:

• Top-down: start from a total estimate, break down roughly.
• Bottom-up: estimate at work package level, then sum.
• Analogous: based on similar past projects.
• Parametric: use statistical relationships (e.g., cost per unit).
• Three-point estimating: optimistic, most likely, pessimistic.

In exam scenarios, if durations and costs are given, you typically need to build a budget and explain how you would control it.

2.4.2 Budgeting vs cost baseline

• Budget is the planned spending plan.
• A cost baseline is an approved cost plan against which actual spending and performance are measured.

2.4.3 Simple cost profile example

Suppose a project budget allocates costs across categories:

Cost Category	Planned Cost (ZAR)
Labour	360,000
Materials/Software Licences	120,000
Vendor/Contractor Services	200,000
Contingency (risk buffer)	80,000
Total Cost Baseline	760,000

If an exam question then says “contingency is 80,000 and labour is 360,000,” you should be able to calculate: contingency as a percentage of total cost baseline: 80,000 / 760,000 = 10.53% (approx. 10.5%).

When you calculate, ensure internal consistency if later calculations use these values. In project control answers, show what happens when contingency is used due to change requests.

2.5 Quality planning: linking scope and acceptance criteria

Quality in project management isn’t only “testing.” It includes:

• defining standards (e.g., ISO-related standards, internal policy standards),
• planning quality assurance activities (process audits),
• planning quality control activities (inspections, test results),
• defining acceptance criteria per deliverable.

A strong exam answer will say:

• “Quality requirements are part of scope and are measured at milestone acceptance.”

Example acceptance criteria

For a software deliverable:

• System must achieve uptime target after go-live (e.g., 99.5% monthly availability).
• All test cases pass with severity thresholds.
• Security requirements met (e.g., role-based access).

If these are in a scenario, incorporate them into “how you would control scope and quality together.”

3) UNISA Project Execution & Controls: Risk, Change, Stakeholders, and Monitoring

Planning is necessary, but projects fail most often during execution when risk materialises or when scope changes are not controlled. This section focuses on monitoring & controlling: risk management, change management, stakeholder communication, and performance measurement—including how to use common metrics logically.

3.1 Risk management: identifying, analysing, responding

3.1.1 Risk register structure (what exams expect)

A risk register commonly includes:

• risk description
• probability
• impact (often financial, schedule, quality)
• risk score (e.g., probability × impact)
• risk owner
• response strategy (avoid, mitigate, transfer, accept)
• triggers/early warning indicators
• contingency actions

When writing answers, show you understand probability/impact logic and include response planning.

3.1.2 Risk identification techniques

Common techniques:

• expert interviews,
• brainstorming,
• document reviews,
• checklists from past projects,
• assumptions review,
• SWOT analysis (as a business management tool).

A business lens adds: risks are not only technical. They can be:

• stakeholder political risk (loss of sponsor support),
• procurement risk (vendor delays),
• compliance risk (regulatory approvals),
• funding risk (budget cuts),
• operational integration risk (system adoption fails).

3.2 Response strategies: when to avoid, mitigate, transfer, or accept

Use a decision rule approach in answers:

• Avoid: eliminate threat or remove cause.
• Mitigate: reduce probability and/or impact.
• Transfer: shift impact (insurance, contract clauses).
• Accept: acknowledge risk; plan for consequences (contingency).

Example: vendor delay risk

Risk: a contractor delays delivery of a key module.

• Mitigate: choose vendor with proven performance, add milestone penalties, create parallel workstreams.
• Transfer: include contract terms with liquidated damages.
• Accept: if delay probability is low and contingency time exists; document trigger conditions.

In exam essays, you should mention how response strategies link to the schedule and cost baselines (i.e., you cannot “accept” risk without a plan for contingency use).

3.3 Monitoring & controlling: status reporting and corrective actions

3.3.1 Reporting cadence

Common reporting rhythm:

• weekly project status report (traffic light: green/amber/red),
• monthly steering committee summary,
• milestone review meetings,
• issue log and action tracking.

A high-scoring exam response explains what each report includes:

• accomplishments vs plan,
• schedule forecasts,
• cost status and forecast,
• risks and changes,
• decisions required from governance.

3.4 Change management: scope creep and formal control

Change is inevitable. The question is whether it is managed formally.

3.4.1 Change control process (typical steps)

You should list steps clearly:

1. Change request submitted (who requests, what change, why).
2. Impact assessment (scope, schedule, cost, quality, risk).
3. Decision by governance (approve/reject/adjust).
4. Update baselines if approved (scope baseline, schedule baseline, cost baseline).
5. Communicate decision and implement updates.
6. Traceability: record in change log to ensure auditability.

3.4.2 Scope creep: how it happens

Scope creep occurs when work beyond scope requirements is performed without formal approval—often due to stakeholder pressure, unclear acceptance criteria, or misinterpreted “requirements.”

Business management answers should explain consequences:

• schedule slips because work expands,
• budget overruns due to additional labour/vendors,
• quality defects due to rushed rework,
• stakeholder dissatisfaction due to unclear expectations.

3.5 Stakeholder management: mapping influence and expectations

Stakeholders include anyone affecting or affected by the project. You should be able to classify stakeholders:

• sponsor, steering committee, project team,
• customers/end users,
• vendors and suppliers,
• regulators/compliance units,
• internal operational teams (IT, finance, HR).

3.5.1 Power/interest grid (exam use)

A common tool: classify stakeholders by power and interest:

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

Your written answers should link to communication methods:

• workshops for high interest,
• briefings for high power,
• newsletters or demo sessions for broader audiences.

3.6 Earned Value Management (EVM): using it in an exam-calculation mindset

Even if your module emphasises conceptual project controls, many UNISA project management assessments include EVM logic or at least the meaning of:

• PV (Planned Value): what was planned to be accomplished by a certain date.
• EV (Earned Value): what value of work was actually accomplished by that date (based on budgeted cost of work performed).
• AC (Actual Cost): what it actually cost to complete the work accomplished.

From these, calculate:

• SV (Schedule Variance) = EV − PV
• CV (Cost Variance) = EV − AC
• SPI (Schedule Performance Index) = EV / PV
• CPI (Cost Performance Index) = EV / AC

A key exam concept:

• If EV < PV, you are behind schedule (negative SV, SPI < 1).
• If EV < AC, you overspent (negative CV, CPI < 1).

Example EVM calculations (consistent example numbers)

At week 6 of a project:

• PV = 400,000 (planned)
• EV = 350,000 (earned)
• AC = 420,000 (actual)

Compute:

• SV = 350,000 − 400,000 = −50,000 (behind schedule)
• CV = 350,000 − 420,000 = −70,000 (over budget)
• SPI = 350,000 / 400,000 = 0.875
• CPI = 350,000 / 420,000 ≈ 0.833

Interpretation in your answer:

• SPI below 1: progress is slower than planned.
• CPI below 1: efficiency is worse than expected.
• Corrective action may include re-sequencing activities, adding resources, or reducing scope—depending on governance rules.

3.7 Contingency planning and reserves

Project budgets often include:

• contingency reserve (for identified risks),
• management reserve (for unknown unknowns within governance rules).

In exam answers, emphasise:

• contingency reserve is used when risks occur that were planned for,
• management reserve requires more governance approval,
• using reserves without updating plans undermines cost baseline validity.

4) UNISA Agile vs Waterfall in Business Management Projects + Procurement and Contracts

Project planning and control does not end with schedule charts. Modern business projects often require thinking about delivery approach: predictive (waterfall), iterative, and agile delivery. In South African business practice and many university curricula, you are expected to compare approaches and justify selection based on uncertainty, stakeholder needs, and regulatory constraints. This section also adds procurement and contract basics because business projects frequently involve external vendors.

4.1 Delivery approaches: predictive (waterfall) vs agile

4.1.1 Waterfall (predictive) mindset

Predictive projects emphasise:

• detailed upfront planning,
• stable requirements,
• clear milestones,
• structured change control.

Best suited when:

• requirements are well understood,
• deliverables have low ambiguity,
• compliance/regulatory needs require documentation and sign-offs.

4.1.2 Agile (iterative) mindset

Agile emphasises:

• iterative development,
• frequent feedback,
• adaptive planning,
• value delivery in increments.

Best suited when:

• requirements may evolve,
• stakeholders need regular demonstrations,
• time-to-market is critical.

4.2 How to choose an approach in an exam scenario

A high-scoring answer uses scenario facts.

Decision checklist

Consider:

1. Stability of requirements
   • stable → predictive
   • changing → agile/iterative
2. Stakeholder availability
   • frequent feedback needed → agile
3. Risk type
   • technical uncertainty → agile reduces delivery risk through iteration
4. Regulatory/documentation
   • high compliance → predictive elements are required
5. Contracting and procurement
   • procurement terms may push toward predictive deliverables
6. Team capability
   • agile requires cross-functional collaboration and product ownership

4.3 Hybrid models: often the “real” answer

Many organisations cannot go fully agile due to governance and compliance. Thus hybrid models appear:

• Predictive for initial requirements, governance, and high-level planning.
• Agile for development increments.
• Change control exists but scope is adjusted within iteration planning.

In answers, present hybrid as a pragmatic adaptation:

• Maintain governance gates and acceptance criteria,
• deliver working increments to reduce uncertainty.

4.4 Stakeholder communication in different approaches

In predictive projects:

• communication often focuses on milestone reporting and documentation.
• change requests must be formal.

In agile projects:

• communication is continuous (demos, sprint reviews).
• backlog prioritisation drives scope changes.

Business management answers should state:

• Agile does not remove governance; it changes how governance is exercised (e.g., product owner prioritisation, iteration acceptance).

4.5 Procurement management: buying goods and services in projects

Procurement is crucial when projects rely on vendors for technology, construction, or specialised consulting.

4.5.1 Procurement planning

Procurement planning includes:

• make-or-buy decision (should you purchase or develop in-house?),
• procurement strategy (single vendor vs multiple bidders),
• define contract requirements,
• define evaluation criteria (price, quality, delivery time, technical capability).

4.5.2 Types of contracts (conceptual)

Common contract types include:

• Fixed-price: supplier delivers at set price; supplier takes more risk.
• Cost-reimbursable: buyer reimburses allowable costs; buyer takes more risk.
• Time & materials: pay for time spent plus materials; used when scope is uncertain.

When answering exam questions, link contract choice to uncertainty and risk:

• uncertain scope → fixed-price may be risky for buyer,
• stable scope → fixed-price may reduce cost variance.

4.6 Contract management and performance monitoring

Contracts require performance monitoring:

• service level agreements (SLAs),
• milestone acceptance,
• penalties/bonuses (if specified),
• invoice verification against delivered scope,
• vendor progress reporting.

In a business management exam setting, emphasise:

• procurement is not “purchase”; it is controlled delivery with acceptance criteria.

4.7 Example procurement scenario (illustrative, consistent)

Imagine a project to install campus signage and a wayfinding system.

• Vendor A is selected for graphic design and printing.
• Vendor B supplies installation labour.
• Project manager coordinates installation schedule to align with building access rules.

Procurement risk:

• printing delays may affect installation readiness.

Mitigation:

• define milestone delivery dates,
• set quality checks,
• include contract clauses for late delivery (penalties or extended warranties).

Acceptance:

• installation must meet visibility standards and safety compliance before project closure.

5) UNISA Project Case Study Skills: Integrated Answers (Plan–Do–Check–Act), Leadership, and Exam-Ready Templates

The final section consolidates the knowledge into exam-ready skills: writing integrated answers, applying tools to realistic case scenarios, and using leadership concepts to explain execution and control. You should practise turning raw scenario facts into structured answers with headings, logical steps, and calculations where needed.

5.1 Integrated project management: connecting all knowledge areas in one narrative

Exams often provide a scenario and ask “discuss” or “recommend.” The highest marks come from showing integration—how scope affects schedule, how risks affect cost, how governance affects change control, and how stakeholder communication affects acceptance.

Use a consistent Plan–Do–Check–Act logic:

• Plan: scope statement, WBS, schedule, cost baseline, quality and risk plans.
• Do: execute activities and deliverables.
• Check: monitor with status reports, EVM or variances, risk review.
• Act: implement corrective actions, reforecast, apply change control.

When answering, you can explicitly mention these phases.

5.2 Leadership and team management: what markers expect beyond “manage people”

Business management students are expected to connect project leadership to outcomes:

• clarifying roles and responsibilities,
• managing conflict,
• motivating teams under deadlines,
• resolving escalation issues,
• enabling decision-making.

5.2.1 Responsibility assignment: RACI concept

A useful exam tool: RACI matrix:

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

You may not need to calculate values, but showing a RACI structure in your answer demonstrates professional project governance.

5.3 Exam-ready risk analysis and response table

A risk response table helps structure answers.

Risk	Probability	Impact	Response Strategy	Owner	Trigger
Vendor delay	Medium	High (schedule/cost)	Mitigate + Transfer	Procurement Lead	Missed milestone date
Scope creep	Medium	High	Mitigate via change control	PM	Requests outside scope definition
Resource unavailability	Low/Med	Medium	Accept with contingency	HR/PM	Team leaves/absence
Requirements ambiguity	Medium	Medium/High	Mitigate via workshops	BA/PM	Frequent rework detected

If the exam scenario provides specific probabilities and impacts, use those values exactly. If not, your general labels (Low/Medium/High) still earn marks when justified.

5.4 Building a full project plan in an exam: a practical template

When the exam asks you to “outline a project plan,” use a structured template that reads like a deliverable.

Template: Project Plan (what to include)

1. Project overview
   • problem/opportunity
   • objectives
   • stakeholders
2. Scope
   • in scope/out of scope
   • deliverables
   • acceptance criteria
3. WBS
   • list major deliverables and work packages
4. Schedule
   • activities derived from work packages
   • dependencies and critical path concept (if required)
   • milestone dates
5. Cost
   • cost baseline categories
   • contingency reserve logic
6. Quality
   • quality standards and quality control activities
7. Risk
   • top risks with response strategies
8. Communications
   • reporting cadence, audiences, formats
9. Governance & change control
   • approval process and escalation
10. Procurement (if relevant)

• vendors, contract approach, milestone acceptance

11. Monitoring

• performance indicators (SPI/CPI if required)

12. Closure

• acceptance, handover, lessons learned

Using this template consistently will improve exam performance.

5.5 Integrated case example with end-to-end reasoning (including calculations)

Scenario: “Implement a departmental procurement portal”

A department wants to implement a procurement portal to reduce approval cycle times and improve auditability. The project has a planned cost baseline of ZAR 760,000 with categories:

• Labour: 360,000
• Materials/Software Licences: 120,000
• Vendor/Contractor Services: 200,000
• Contingency (risk buffer): 80,000

The project is planned over 13 days of critical-path activity work (assume the critical path logic is required for a brief scheduling question). Management wants a project status update at week 6 and uses EVM.

At week 6:

• PV = 400,000
• EV = 350,000
• AC = 420,000

There is also a high-priority risk: vendor delay threatens readiness for go-live.

Exam-style tasks may include:

1. Identify risks and propose responses.
2. Explain how you would control scope changes.
3. Compute and interpret EVM indicators.
4. Recommend delivery approach (predictive vs agile/hybrid) based on uncertainty.

Task 1: Risk identification and response (structured)

Top risks:

• Vendor delay: probability Medium, impact High (schedule and cost).
  • response: mitigate via vendor milestone commitments; transfer via contract penalties; create parallel development of configuration templates.
• Scope creep: probability Medium, impact High.
  • response: enforce change control; clarify in/out of scope; update WBS dictionary when approved.
• Requirements ambiguity: probability Medium, impact Medium/High.
  • response: conduct business requirements workshops; implement iterative prototypes; tighten acceptance criteria.

In your answer, ensure you mention triggers:

• missed vendor milestone dates,
• new requirements outside scope boundaries,
• repeated rework in testing.

Task 2: Scope change control

Explain a formal process:

1. Change request submitted by relevant stakeholder.
2. Impact assessment:
   • schedule impact on critical path (and any near-critical paths),
   • cost impact on cost baseline (labour, vendor, materials),
   • quality impact (testing effort, acceptance criteria).
3. Steering committee decision.
4. Update baselines only if approved.
5. Communicate updated plan to team and stakeholders.

If the exam expects you to connect to contingency:

• identify whether change is due to risk materialisation (use contingency) or due to new scope (likely requires budget reallocation or management reserve approval).

Task 3: EVM calculations and interpretation

From the scenario:

• SV = EV − PV = 350,000 − 400,000 = −50,000
• CV = EV − AC = 350,000 − 420,000 = −70,000
• SPI = EV / PV = 350,000 / 400,000 = 0.875
• CPI = EV / AC = 350,000 / 420,000 ≈ 0.833

Interpretation (write clearly):

• The project is behind schedule (SPI < 1, negative SV).
• The project is over budget (CPI < 1, negative CV).
• Corrective actions should target:
  • schedule recovery: adjust sequencing, reallocate labour, negotiate vendor recovery plan,
  • cost recovery: evaluate productivity losses, control rework, confirm vendor claims/invoices align to deliverables.

Link actions to governance:

• any major plan change must be approved, and updated forecasts should be communicated to stakeholders.

Task 4: Delivery approach recommendation (hybrid justification)

Because requirements include workflows and approval rules that may evolve with stakeholder feedback, the project benefits from iterative clarification. However, procurement systems also often require stable audit/compliance rules.

Recommendation: Hybrid approach

• Predictive for governance, scope definition, compliance requirements, and schedule baselines.
• Agile/iterative for workflow configuration and testing cycles (sprint-style reviews with users).

Justification in answer:

• reduces requirements ambiguity risk,
• improves stakeholder engagement,
• maintains control over scope and acceptance criteria.

5.6 Writing the conclusion: what exam markers reward

Conclusions should not be vague. They should:

• reaffirm how tools and governance connect,
• state the most important controls (scope, schedule, cost, risk, quality),
• show one or two prioritized next actions.

Example conclusion (in exam style):

• “To ensure successful delivery, management must protect the scope baseline through formal change control, recover schedule performance by addressing vendor delay risk, and control cost by reducing rework and monitoring EVM indicators. Stakeholder communication should be maintained with structured reporting to enable timely governance decisions. A hybrid delivery approach balances early compliance planning with iterative configuration to reduce requirements ambiguity.”

Quick High-Yield Revision Points (UNISA BCom Project Management)

Use these as final recall bullets for exam revision:

• Project definition: temporary, unique deliverable, finite start and finish.
• Triple constraint: scope, time, cost, with quality tightly linked to acceptance.
• Life cycle: initiation → planning → execution → monitoring & controlling → closure.
• Scope statement must include: objectives, deliverables, in/out of scope, acceptance criteria, assumptions, constraints.
• WBS supports: scheduling, costing, tracking, and control.
• Critical path: zero float activities determine project duration.
• EVM logic: PV, EV, AC → SV/CV/SPI/CPI → interpretation drives corrective action.
• Risk management: probability/impact, risk owner, triggers, and response strategy (avoid/mitigate/transfer/accept).
• Change control: impact assessment + governance decision + updated baselines + communication.
• Stakeholders: map power/interest and adapt communication methods.
• Agile vs waterfall: choose based on requirements stability, stakeholder feedback needs, compliance constraints, and risk type.
• Procurement: contract type should reflect uncertainty; milestone acceptance and performance monitoring are essential.

UNISA Exam Practice Checklist (what to do under time pressure)

1. Read scenario carefully and list: objectives, deliverables, constraints, stakeholders.
2. Identify what is being asked (calculate? discuss? construct a WBS/network? recommend delivery approach?).
3. Choose the correct tool:
   • WBS for scope decomposition,
   • network + critical path for schedule,
   • cost baseline categories + contingency for budgeting,
   • risk register table for risk,
   • EVM indicators if PV/EV/AC provided.
4. Show working for calculations (especially EVM and critical path).
5. Write structured answers using headings and bullet points.
6. Conclude with decisions and next steps, not repetition.

If you want, I can also convert these notes into UNISA-style exam answers for common question formats (e.g., “Construct a WBS and explain how you would derive activities,” “Discuss risk response strategies with examples,” “Calculate SPI/CPI and recommend corrective actions”) using one consistent, fully worked fictional case study throughout.