Project Management Tools and Techniques (Regent Module) Summaries — Study Notes for Regent Business School (MBA/Project Management Context)

Project Management Tools and Techniques sits at the heart of how projects are planned, monitored, and delivered within time, cost, quality, and scope constraints. In Regent Business School project management modules, the emphasis is typically on turning “theory tools” (like WBS, Gantt charts, risk registers, and stakeholder matrices) into practical decision-making and controlled execution. These exam-focused notes summarise the most tested tools and techniques, explain when to use them, and provide concrete scenarios to help you apply them under pressure.

1) Project Management Core Tools: Scope, Planning, Scheduling, and Control (Regent + Cross-University Exam Style)

A strong exam answer on “project management tools and techniques” usually requires two things: (1) you can name and define the tool, and (2) you can apply it to a realistic project situation with clear cause-and-effect. Tools are not just diagrams; they are decision support systems that help you manage uncertainty and align stakeholders.

1.1 Work Breakdown Structure (WBS): The Backbone of Scope Control

The Work Breakdown Structure (WBS) is a hierarchical decomposition of the total project scope into manageable deliverables and work packages. In exam terms, you should treat WBS as the “scope-to-plan bridge.” Without it, other tools like scheduling, budgeting, and tracking become unreliable because the work is not clearly structured.

Key concepts to include in answers

Deliverables orientation: WBS is deliverable-based, not activity-based.
Work packages: The lowest level where cost and time estimation is feasible.
Measurable outcomes: Each element should produce something verifiable (e.g., “Training manual approved,” not “Work on training”).

Example scenario (useful for application)
Assume Regent’s module assignment describes a project to implement a small Student Support Portal for a South African university department. The project scope includes:

Requirements and design
Content migration
Training for staff
Pilot testing and rollout

A simplified WBS could be:

WBS Level	Component	Deliverable / Work Package Example
1	Student Support Portal	Portal implementation and rollout
2	Requirements & Design	Approved functional requirements
2	Content Migration	Migrated FAQ library (verified)
2	Training	Staff training sessions completed
2	Pilot & Rollout	Pilot report + go-live checklist

If an examiner asks, “How does WBS help control scope?” you should explain:

It defines what is included.
It enables controlled change by showing where an “extra request” fits (or doesn’t fit).
It improves estimating because you estimate at work-package level.

1.2 Gantt Charts: Scheduling Visibility and Progress Tracking

A Gantt chart displays planned start and finish dates for tasks across a timeline. Many exam questions ask about “planning and scheduling tools,” and Gantt charts are often expected as a straightforward but powerful tool.

What to mention

Tasks are listed vertically; time periods are shown horizontally.
It supports tracking by comparing planned vs actual progress.
It helps communicate schedule to stakeholders who need a simple view.

Common exam trap
Students sometimes describe Gantt charts as if they “ensure success.” In reality, the chart is only as good as the plan behind it. If scope is unclear, the Gantt chart becomes a projection rather than a controlled schedule.

Mini-case: identifying schedule risk using Gantt
In the Student Support Portal example:

Content migration work package depends on “approved content template.”
If approval delays by 2 weeks, then dependent tasks slip.

In exam answers, link the concept:

Identify dependencies.
Use the chart to show knock-on effects.
Update schedule with change control.

1.3 Critical Path Method (CPM) and Network Diagrams: The “Time Discipline” Tool

The Critical Path Method (CPM) calculates the longest path through the project network, identifying tasks that directly determine the project’s minimum completion time.

To score well, write about:

Forward pass: calculate earliest start/finish times.
Backward pass: calculate latest start/finish times.
Float/slack: how much a task can be delayed without affecting the end date.
Critical tasks: tasks with zero float.

Example network (portal project)
Let’s assume the project has these activities:

Requirements approved (A) — 5 days
Design complete (B) — 3 days, depends on A
Content template approved (C) — 4 days, depends on A
Content migration (D) — 6 days, depends on B and C
Staff training (E) — 2 days, depends on D
Pilot & rollout (F) — 3 days, depends on E

Total minimum time is determined by the longest dependency chain. The chain could be:

A (5) → B (3) → D (6) → E (2) → F (3) = 19 days
Meanwhile A → C → D also totals:
A (5) → C (4) → D (6) → E (2) → F (3) = 20 days

That makes the second path critical (20 days), meaning:

If any task on A-C-D-E-F is delayed, the whole project end date shifts unless recovery actions reduce duration.

How to write this in an exam

State that CPM helps identify which tasks must not slip.
Explain float concept briefly but clearly.
Mention how managers use this for resource prioritisation.

1.4 Budgeting and Cost Baseline: Ensuring “Money Time” Alignment

Project management tools often include a cost baseline, created from resource estimates and planned time-phased budgets. Even in modules that focus more on technique than finance, exam questions may ask how tools support cost control.

Key terms that typically appear:

Estimate at completion (EAC) (if earned value is used—see Section 2)
Budget at completion (BAC)
Cost baseline: the approved time-phased budget for measuring performance

Practical link

WBS work packages → estimate labour/materials → build cost baseline.
Scheduling tools (Gantt/CPM) → allocate budget by time period.

2) Planning, Risk, Stakeholders, and Monitoring: Techniques You’ll Actually Use in Exam Scenarios (Regent Module Summaries)

Exams often reward structure: definitions followed by application. This section focuses on stakeholder management, risk analysis, and monitoring/control tools—areas where marks often differentiate between “textbook recall” and “exam-grade application.”

2.1 Stakeholder Analysis: Mapping Power, Influence, and Engagement

Stakeholder management is not only about identifying “who cares.” It’s about managing influence and communication needs.

A common exam-friendly tool is the power-interest grid:

High power, high interest: manage closely; frequent communication
High power, low interest: keep satisfied; periodic updates
Low power, high interest: keep informed; encourage feedback
Low power, low interest: monitor; minimal effort

Example for the Student Support Portal
Stakeholders might include:

Project sponsor (e.g., faculty head): high power, high interest
IT department manager: high power, medium interest (depends on internal constraints)
Lecturers/staff users: medium/high interest, medium power
Students: medium power (through demand), high interest
External vendor support: medium power, low interest unless contractual issues arise

An exam response should connect:

Stakeholder categories → communication plan.
If you ignore high-power/high-interest stakeholders, you risk late approvals and schedule slip.

2.2 Communication Plan: The “Delivery Mechanism” Tool

A communication plan outlines:

Who receives what information
Frequency (weekly, monthly, ad hoc)
Format (meetings, reports, dashboards, emails)
Responsible person/role

A high-scoring answer includes at least one example:

Weekly status meeting with sponsor (progress, risks, decisions needed).
Monthly steering committee report (RAG status, performance vs baseline).
Daily team stand-up (blockers, work package progress).

Technique tie-in
Communication is also a control tool:

If risks are detected but not communicated, they become “surprise problems.”
A communication plan supports early detection and escalation.

2.3 Risk Management Tools: Risk Register, Probability/Impact, and Response Planning

Risk management is commonly tested through the use of a risk register and risk assessment methods.

A strong risk register entry includes:

Risk description (clear statement)
Category (schedule, cost, quality, technical, stakeholder, compliance)
Probability (likelihood)
Impact (severity on objectives)
Risk owner
Response strategy (avoid, mitigate, transfer, accept)
Contingency plan (what to do if it occurs)
Status (open, closed, monitored)

Probability-Impact Matrix
A common method assigns probability and impact scores (e.g., 1–5) and calculates risk priority (e.g., probability × impact). Even if your module doesn’t demand numeric scoring, exam answers often benefit from showing a ranking logic.

Example risk register entries (portal project)

Risk: Delay in content template approval by department admin
- Probability: 4/5
- Impact: 4/5 (content migration slips)
- Strategy: Mitigate (draft template early; schedule approval checkpoints)
- Owner: Project manager
Risk: Vendor issues with portal integration
- Probability: 2/5
- Impact: 5/5 (integration affects pilot readiness)
- Strategy: Mitigate/Transfer (SLA clauses; test integration early; escalation path)
- Owner: Technical lead

Counter-argument you can use in exams
Some students treat risk as “bad things only.” A complete answer can mention:

Risks include opportunities (positive risks) too.
A risk register can track both threats and opportunities.

2.4 Quality Planning and Quality Control Tools: From Standards to Acceptance Criteria

Quality management is frequently overlooked by students focusing only on schedule/cost. But in project management exams, quality tools can earn significant marks because they show holistic control.

Quality planning typically includes:

Quality standards (what “good” means)
Acceptance criteria (how deliverables are measured)
Quality assurance vs quality control
- Quality assurance: process-focused (prevent defects)
- Quality control: product-focused (detect defects)

Tools and techniques

Checklists for inspections
Sampling plans (if relevant)
Reviews and audits
Test plans for software projects

Portal example
Acceptance criteria might include:

Students can reset passwords within 3 minutes
Staff dashboard shows session statistics correctly
Accessibility and usability checks pass defined threshold

In exam answers, link quality to risk:

Poor quality increases rework → schedule slip.
Rework often triggers cost overruns.

2.5 Monitoring and Control: Performance Metrics and Change Control Logic

Monitoring is about collecting data; control is about taking corrective actions. Many exam questions ask, “How do you control scope/schedule/cost?” The correct approach usually references:

Baselines (scope baseline, schedule baseline, cost baseline)
Variance analysis (difference between planned and actual)
Change control system (evaluate impact, approve or reject changes, update baselines)

Change control in simple exam terms
A change request should pass through:

Log the change request
Assess impact (scope, schedule, cost, quality, risk)
Decide approval/rejection
Implement changes if approved
Update baselines and communicate

Why this matters
Without a structured change process:

“Small” changes accumulate.
The project ends with hidden scope creep and stakeholder conflict.

3) Earned Value Management (EVM) and Performance Reporting: Quantitative Techniques for High-Marks Answers (Regent + SA University Exam Patterns)

If your Regent module aligns with common project management curricula, Earned Value Management (EVM) is often one of the most examinable “quantitative technique” sections. Even if your course notes simplify EVM, you should know how it works conceptually and be able to compute basic indices if asked.

3.1 EVM Foundations: Planned Value, Earned Value, Actual Cost

EVM compares three measures:

PV (Planned Value): what you planned to accomplish by a given date (cost budgeted)
EV (Earned Value): what you actually accomplished by that date, valued at the planned cost
AC (Actual Cost): what it cost to do the work accomplished

This triangle allows you to measure schedule and cost performance separately.

Use-case structure in exams

Choose a reporting date.
Compute PV, EV, AC.
Determine variances and performance indices.
Conclude whether the project is ahead/behind schedule and over/under budget.

3.2 Variance and Index Calculations (with Consistent Example)

Consider a hypothetical portal work package set with the following scenario at the end of Week 4:

Assume the work package has a budget total (BAC) that implies planned cost distribution. For simplicity, at Week 4:

PV = 200,000 (planned value by Week 4)
EV = 180,000 (earned value by Week 4)
AC = 210,000 (actual cost by Week 4)

Compute:

Schedule Variance (SV) = EV − PV = 180,000 − 200,000 = −20,000
→ negative indicates behind schedule.
Cost Variance (CV) = EV − AC = 180,000 − 210,000 = −30,000
→ negative indicates over budget.

Now compute performance indices:

Schedule Performance Index (SPI) = EV / PV = 180,000 / 200,000 = 0.90
→ doing work worth 90% of what was planned.
Cost Performance Index (CPI) = EV / AC = 180,000 / 210,000 ≈ 0.86
→ spending more than planned for the work achieved.

How to write the interpretation

“At Week 4, the project is behind schedule (SV negative, SPI < 1).”
“At the same point, the project is over budget (CV negative, CPI < 1).”
Then propose causes and responses:
- behind schedule may indicate dependencies slipping or under-resourcing
- over budget may indicate rework or inefficient processing

3.3 Forecasting: EAC and ETC Concepts (Exam Language)

Even where full formula scoring is limited, examiners expect you to distinguish:

Estimate to Complete (ETC): forecast remaining cost from now to finish
Estimate at Completion (EAC): forecast total final cost

A simple (conceptual) exam answer can say:

If cost performance is consistently poor (CPI < 1), EAC tends to be higher than BAC.
If schedule performance is consistently poor (SPI < 1), project completion may shift unless corrective action is taken.

If your module includes the common simplified EAC approach:

EAC ≈ AC + (BAC − EV) / CPI
Using the consistent values:
AC = 210,000
BAC is not given above; if we assume BAC corresponds to PV at completion, you’d need the total budget. For exam readiness, it’s better not to invent BAC. Instead, focus on the interpretation: CPI suggests cost inefficiency, which increases forecasted final cost.

Avoid exam loss by not forcing numbers
If the prompt does not supply BAC, do not pretend a number exists. Compute what you can (SV, CV, SPI, CPI) and state what that implies.

3.4 Performance Reporting: Dashboards, Status Reports, and RAG Ratings

EVM outputs should lead to a coherent reporting practice. Common tools include:

RAG status (Red/Amber/Green) based on thresholds for schedule, cost, risk.
Variance reports that show what changed and why.
Trend charts showing performance over multiple reporting periods.

Example RAG logic

Green: SPI ≥ 1.0 and CPI ≥ 1.0 with no major risk escalation
Amber: one index slightly below 1.0 and risks controlled
Red: both indices below 1.0 or major risks newly triggered

For the Week 4 example:

SPI = 0.90 (Amber/Red depending on threshold)
CPI ≈ 0.86 (worse than planned)
You could justify an Amber to Red status depending on how Regent’s module case thresholds are set (if a case study uses specific thresholds, match them).

3.5 Corrective Action Planning: Turning Metrics into Decisions

High marks often go to students who connect EVM metrics to management actions.

If SV is negative:

Re-plan critical path activities
Reduce lag on dependencies
Add resources (crashing) if feasible
Re-baseline only with formal change control (important exam point)

If CV is negative:

Investigate cost drivers: rework, scope creep, procurement delays
Improve estimation and resource allocation
Strengthen quality control to reduce defects
Negotiate recovery plan with stakeholders

Counter-argument to include
Sometimes negative SV and CV does not automatically mean failure:

It can happen because early work is complex.
The key is trends: if performance improves in later periods, recovery is possible.

4) Scheduling and Resourcing Techniques: Dependency Logic, Resource Allocation, and Optimization (Tools for Planning Under Constraints)

Real projects rarely fit neat schedules. This section covers practical scheduling techniques and the “engineering” of plans—how to handle dependencies, resource limits, and optimisation decisions. In many South African university exam contexts (including Management-oriented modules that borrow from standard PMBOK concepts), students are assessed on both technical understanding and realistic judgement.

4.1 Dependencies and Logic: Finish-to-Start, Start-to-Start, etc.

In network scheduling, you must know common dependency types:

Finish-to-Start (FS): predecessor must finish before successor starts (most common)
Start-to-Start (SS): successor can begin when predecessor starts (overlap)
Finish-to-Finish (FF): successor finishes when predecessor finishes
Start-to-Finish (SF): rare in practice, successor cannot finish until predecessor starts

Portal example

“Content migration” (D) may have a Finish-to-Start with “Content template approved” (C).
“Staff training” (E) may be Start-to-Start with “Pilot testing begins” if training can start using mock interfaces before full pilot completion.

Exam tip: if you state a dependency type incorrectly, downstream calculations and critical path reasoning can fail. Use FS as default unless the case explicitly describes overlap opportunities.

4.2 Resource Planning: Capacity, Skills, and Constraints

Resource planning turns a schedule into something feasible. Constraints may include:

Limited technical staff
Budget limits for contractors
Availability of vendors
Environment constraints (testing windows)

Resource leveling
When multiple tasks demand the same limited resource, resource leveling adjusts start times to smooth demand, but may delay the critical path. In exam terms:

Leveling reduces peaks in resource usage.
It can increase schedule risk unless compensated.

Resource smoothing vs crashing
Students should distinguish:

Smoothing: adjust schedule without increasing cost significantly; prioritise leveling.
Crashing: reduce project duration by adding resources (overtime, contractors), usually at extra cost.

4.3 Crashing and Trade-Offs (Time-Cost Tradeoff)

The time-cost tradeoff is usually explained with a basic logic:

Shortening duration typically increases cost.
You choose the “least expensive” crash options first, often focusing on critical path tasks.

Exam-ready steps

Identify critical path activities.
For each critical activity, estimate crash cost per unit time.
Crash activities with lowest cost per time reduction.
Continue until you reach target duration or cost limit.

Why it matters for project management
If you crash without a revised plan:

You may increase errors, lower quality, and create even more cost variance.
You might overload resources and create stakeholder dissatisfaction.

So a full answer includes a judgement:

Crashing should be paired with quality safeguards and risk mitigation.

4.4 Estimating Techniques: Bottom-Up, Analogous, and Three-Point Estimates

Although this section focuses on scheduling and resourcing, estimating links directly to scheduling accuracy. Exams often ask which estimation technique is suitable under uncertainty.

Bottom-up estimating

Break work into work packages (WBS).
Estimate each package and aggregate.
More accurate but time-consuming.

Analogous estimating

Use historical data from similar projects.
Faster but less precise.

Three-point estimating

Uses optimistic, most likely, pessimistic estimates.
Often yields a better estimate than single-point guesses.

Even if numeric formulas aren’t required, you should explain:

Why pessimistic/optimistic assumptions reflect uncertainty.
Why three-point helps schedule buffers.

4.5 Buffer Management: Risk-Aware Schedules

A schedule can be protected with buffers:

Time buffers around high-uncertainty tasks.
Schedule contingency when risk is expected.
Contingent planning with triggers.

In exam scenarios, when uncertainty is high (e.g., vendor integration), schedule contingency is a rational tool. But you should show governance:

Buffers must be documented and defended.
They should not become hiding places for poor performance.

5) Tool Selection, Integration, and Exam-Winning Practice: How Regent Students Link Techniques into a Coherent Plan (Regent + South African Business Context)

This final section synthesises the techniques into an integrated management approach and provides “how to answer” guidance aligned with typical South African university exam expectations for business modules (where marking often rewards logical sequencing, correct terminology, and realistic justification).

5.1 Choosing the Right Tools: Matching Tool to Project Need

A common weakness in student answers is listing tools without justification. In high-quality exam answers, you match tool selection to the management problem.

Tool-to-need mapping (exam friendly)

WBS → define scope clearly and create estimating structure
Gantt → communicate schedule and track planned vs actual progress
CPM/network diagram → identify critical path and protect minimum duration
Risk register + matrices → quantify and plan for threats/opportunities
Stakeholder power-interest grid → decide engagement and communication approach
Quality checklists/acceptance criteria → prevent and detect quality failures
EVM (PV/EV/AC, SPI/CPI) → quantify performance variances and forecast
Change control → manage scope creep and baseline updates

5.2 Building an Integrated Project Management “Control System”

A project management plan is not one document; it’s a system of linked artefacts:

Scope definition (requirements + WBS)
Schedule development (network logic + Gantt representation)
Cost baseline (resource estimates and time-phased budgeting)
Risk planning (risk register + response strategies)
Quality planning (quality standards and acceptance criteria)
Communication planning (stakeholder engagement and reporting cadence)
Monitoring & control (EVM, variance analysis, audits)
Change control governance (evaluate and update baselines)

A coherent answer explains that these tools are connected:

WBS informs scheduling and costing.
Scheduling influences reporting dates for EVM.
Risk register informs contingency and buffer decisions.
Quality criteria influence acceptance during monitoring.
Change control prevents uncontrolled baseline drift.

5.3 Mini Integrated Case Study (Full Exam Style Walkthrough)

To consolidate everything, consider a concise case scenario commonly used in project management exams:

Project: Implement a Student Support Portal for a South African university department.
Time horizon: 20 working days (based on the critical path reasoning in earlier examples).
Objective constraints: deliver portal with staff training completed and pilot-ready functionality.
Key deliverables: approved requirements/design, content migration completed, training sessions done, pilot report and go-live readiness checklist.

Step 1: Scope and WBS

Deliverables are broken into work packages (requirements approval, design complete, template approval, migration, training, pilot rollout).
Each work package gets an owner and acceptance criteria.

Step 2: Schedule development with dependencies

Use network logic (mostly FS dependencies).
Identify critical path using CPM so you know which tasks have zero float.
Represent schedule in a Gantt chart for communication.

Step 3: Cost baseline

Estimate each work package cost.
Create time-phased budget for PV.

Step 4: Stakeholder plan

Sponsor and department head: high power/high interest → weekly close communication.
IT manager: high power/medium interest → biweekly technical checkpoints.
Students: high interest → user testing updates and feedback loops.
Vendor: medium power → escalation communication plan.

Step 5: Risk planning

Content template approval delay: mitigate with early draft and approval checkpoints.
Vendor integration issues: mitigate with SLA and early technical testing.
Update risk register at each reporting period.

Step 6: Quality planning

Define acceptance criteria for portal features and training deliverables.
Use checklists and reviews to validate readiness.

Step 7: Monitoring and control using EVM concepts

At a reporting point (e.g., Week 4), collect:

PV from schedule baseline
EV from verified work package completion
AC from timesheets/invoices/resources consumed

Compute:

SV, CV, SPI, CPI
Then interpret and decide:
If behind schedule (SV negative), focus on critical tasks and dependencies.
If over budget (CV negative), investigate cost drivers and implement corrective action.

Step 8: Change control

If a new requirement appears (“Add additional reporting module for staff”):

Log change request
Assess impact on WBS, schedule baseline, cost baseline, quality standards, and risks
Approve/reject through sponsor governance
Update baselines only after approval

This integrated approach is the difference between a “tool list” answer and an “exam-winning” answer.

5.4 How to Structure a High-Scoring Exam Response (Practical Writing Template)

Many Regent students struggle not with knowledge but with exam structure. Use a consistent pattern:

Define the tool/technique in one or two precise lines.
Explain why it matters for project objectives (time/cost/scope/quality).
State how it is applied step-by-step (or show the key formula/logic).
Provide a short example (portal case or any invented but consistent mini-case).
Conclude with an action/decision (what a manager should do based on outputs).

Example: “Explain a risk register and how you would use it.”

Definition
Purpose (prioritise and manage uncertainties)
Components (probability, impact, owner, response)
Example entries
Use in monitoring (updates, triggers, escalation)

5.5 Common Mistakes That Lose Marks (and How to Avoid Them)

1) Treating tools as substitutes for planning
Gantt charts, CPM, and EVM require accurate data. If scope or progress measurement is weak, results are misleading.

2) Mixing up EV vs PV meaning
EVM comparisons are meaningless if you confuse “planned work value” with “earned work value.”

3) Writing risk management as a one-time activity
Exams expect risk register updates and reassessment across reporting cycles.

4) Ignoring change control governance
Scope creep and baseline drift are classic reasons projects fail. You should always mention formal evaluation of change.

5) Forgetting quality and stakeholder communication
A schedule that meets dates but fails acceptance criteria is still a project failure in operational terms.

5.6 Linking to Regent Coursework and Exam Keywords (South African University Study Language)

South African project management modules often align with business school language such as “planning,” “monitoring,” “control,” “stakeholder engagement,” and “performance reporting.” When students refer to study material and assignments from institutions like UNISA and CUT (Cape Peninsula University of Technology), examiners often reward answers that reflect standard project management vocabulary used across curricula.

To keep your revision aligned with how marks are commonly awarded, ensure your revision notes include these keyword clusters:

WBS, scope baseline, work packages
Gantt chart, schedule baseline, dependencies
CPM, critical path, float/slack
Risk register, probability, impact, response strategies
Stakeholder matrix, communication plan, engagement strategy
Quality assurance, quality control, acceptance criteria
EVM, PV, EV, AC, SPI, CPI, forecasting
Change control, variance analysis, corrective action

Final Consolidation Checklist (Quick Exam Revision)

Before sitting the exam, you should be able to answer quickly and correctly:

Define WBS, Gantt, CPM, risk register, stakeholder power-interest matrix, and EVM.
Explain the purpose of each tool (what objective it protects).
Apply tools to a realistic scenario (like the Student Support Portal project).
Compute SV/CV/SPI/CPI when given PV/EV/AC (and interpret them).
Describe how monitoring outputs lead to corrective actions and change control.

These integrated techniques represent the practical “Regent Module” mindset: project success is not luck—it is the result of structured planning, controlled execution, proactive risk management, and disciplined performance reporting.