Skip to content

Curriculum Roadmap

The complete 16-week teaching sequence: 32 sessions, two per week, each designed for about two hours of contact time plus independent study.

This page is the master plan. It shows what is taught, in what order, why that order, and how each part of the course builds toward the capstone. Students can use it to see the whole journey; instructors can use it to plan delivery.

At a glance

  • Length: 16 weeks · 32 sessions · ~2 hours per session
  • Modules: 13, grouped into five parts
  • Prerequisites: One software development course
  • Culminates in: An integrated capstone project (sessions 30–32)

How to read this roadmap

Each of the 13 modules below gives the module title and sessions, then:

Field Meaning
Sessions The sessions in the 16-week plan that deliver this module
Learning objectives What you will be able to do afterwards, written so they can be checked
Prerequisites What must already be in place
Key concepts The ideas and terms the module introduces
Practical activity The workshop where you apply the ideas, using the Campus Event Portal case study
Assessment / self-check How you confirm you have learned it
Expected student outcome The capability you should have at the end

Why this order

Where the labs fit. Each module has one or more numbered labs, which work through the same techniques on the scenarios in the example-project library — an LMS, a hospital appointment platform, an e-commerce store, a banking app, a complaints system, an analytics dashboard. The module's Practical activity below is a shorter workshop that uses the Campus Event Portal case study, so you practise each idea twice: once in a small, controlled scenario, and once with a lab's fuller dataset and arithmetic. Neither replaces the other, and neither is optional if you want the capability the module promises.

The sequence is not the same as a flat list of topics. Three decisions shaped it.

1. Vocabulary before technique. Modules 01–03 establish what a project is, how it is initiated, and how a plan is structured. Every later module uses this vocabulary. A student who starts at "critical path" without knowing what a work package is will memorise the arithmetic and miss the point.

2. Predictive planning before adaptive delivery. The course teaches plan-driven planning first (Modules 03, 05, 06, 07) and then adaptive approaches (Module 04 sits after the integrative planning session). This is deliberate: agile is best understood as a response to the limits of predictive planning, and you cannot appreciate what Scrum changes until you have seen what a baseline and a work breakdown structure are. Agile is not "the absence of planning"; you need to know what planning looks like first.

3. Measure, then control, then govern. Measurement (Module 11) comes only after there is something to measure — a baseline, a schedule, a budget. Closure, ethics, and advanced governance (Module 12) come last because they require the full context of the course.

Two consequences are worth stating plainly:

  • Estimation (topics 14–15) is taught with scheduling (topics 9–10), not later, because you cannot build a schedule without estimating duration, and you cannot estimate cost without a schedule. Separating them would be artificial.
  • Documentation is paired with closure in one session (session 26). Documentation exists to support handover, closure, and lessons learned, so teaching them together is coherent rather than a saving.

Master calendar

Session Week Module Topic Focus
S1 1 01 1 What software project management is; projects versus operations; why the discipline exists
S2 1 01 2 How software projects differ from other projects, and what that changes
S3 2 01 3 Project life cycles and development approaches
S4 2 02 4 Stakeholders: identification, analysis, and governance
S5 3 02 5 Project initiation and the business case
S6 3 02 6 Feasibility and project selection
S7 4 03 — Integrated planning: how the parts of a plan interlock; baselines
S8 4 04 11 Agile and predictive approaches compared
S9 5 04 12 Scrum: roles, events, and artefacts
S10 5 04 13 Kanban, flow, and work-in-progress limits
S11 6 05 7 Requirements and scope management
S12 6 05 8 Work breakdown structure and the scope baseline
S13 7 06 9 Scheduling: activities, dependencies, duration, critical path
S14 7 06 10 Gantt charts, dependencies, float, and compression
S15 8 07 14 Effort and cost estimation
S16 8 07 15 Function points, expert judgement, and analogous estimation
S17 9 — — Mid-course consolidation and capstone checkpoint
S18 9 08 16 Risk identification, assessment, and response planning
S19 10 09 17 Quality management, assurance, and control
S20 10 10 18 Team organisation and resource management
S21 11 10 19 Communication and stakeholder management
S22 11 11 20 Software project metrics
S23 12 11 21 Monitoring and control
S24 12 11 22 Change and configuration management
S25 13 12 23 Procurement and vendor considerations
S26 13 12 24, 27 Project documentation, closure, and lessons learned
S27 14 12 25 Distributed and remote teams
S28 14 12 26 Ethical and responsible project management
S29 15 12 28 Advanced project management and governance
S30 15 13 29 Capstone: plan review, baseline, and risk clinic
S31 16 13 29 Capstone: build, control, and reporting work session
S32 16 13 29 Capstone: final presentations, closure, and retrospective

Session 17 is a consolidation checkpoint rather than new content: it is placed where the planning half of the course meets the control half, so gaps can be closed before the material becomes cumulative. Session 7 is an integrative session with no single numbered topic — it assembles the pieces introduced around it.

Part I — Foundations

Module 01 — Foundations of Software Project Management

Sessions: S1, S2, S3 · Weeks 1–2

Learning objectives. By the end of this module you will be able to:

  1. Define a project and distinguish it from operations, a programme, and a portfolio.
  2. Explain how software projects differ from projects in other domains, and give three consequences of those differences for how the work is managed.
  3. Compare predictive, iterative, incremental, and adaptive life cycles, and select one for a given situation with justification.
  4. Identify the main roles on a software project and state what each is accountable for.
  5. Evaluate a project against multiple dimensions of success rather than time and cost alone.

Prerequisites: None (the entry point to the course)

Key concepts: project · operations · programme · portfolio · deliverable · life cycle · predictive, iterative, incremental, and adaptive approaches · roles and accountability · success criteria · the linked constraints of scope, time, cost, and quality

Practical activity: Lab 01 — Writing a Project Charter: turn a one-paragraph idea into a bounded project definition, and begin the artefact set that runs through to the capstone.

Assessment / self-check: Quiz — Foundations (questions 1, 3, 8 and 10 cover this module) plus the Lab 01 rubric.

Expected student outcome: You can look at a piece of work and say whether it is a project, what kind of life cycle suits it, who is accountable for it, and what success would actually mean — before any planning has happened.

Material: Module 01 — Foundations of Software Project Management

Module 02 — Project Initiation & Stakeholders

Sessions: S4, S5, S6 · Weeks 2–3

Learning objectives. By the end of this module you will be able to:

  1. Identify stakeholders for a given project and analyse their influence, interest, and attitude using a structured register.
  2. Explain how governance arrangements allocate decision rights, and identify the approval path for a scope change.
  3. Write a business case that states the expected value, the cost, and the rationale for a proposed project.
  4. Apply at least two feasibility and selection techniques, such as cost–benefit analysis, weighted scoring, or payback reasoning.
  5. Justify a recommendation to proceed with, defer, or reject a proposed project.

Prerequisites: Module 01

Key concepts: stakeholder identification and analysis · influence versus authority · sponsor · governance · decision rights · business case · options appraisal · cost–benefit analysis · weighted scoring · go/no-go decisions

Practical activity: Extend the charter from Lab 01 into a complete Stakeholder Register, then write a one-page selection recommendation weighing two competing project proposals.

Assessment / self-check: The stakeholder and selection work is self-marked against the Project Charter and Stakeholder Register guidance; questions 2, 4 and 9 of the Foundations quiz cover this module.

Expected student outcome: You can take an idea, work out who cares about it and who can stop it, make an explicit case for or against doing it, and know who has to say yes.

Material: Module 02 — Project Initiation & Stakeholders

Module 03 — Integrated Project Planning

Sessions: S7 · Week 4

Learning objectives. By the end of this module you will be able to:

  1. Describe the components of an integrated project management plan and explain how each constrains the others.
  2. Explain the purpose of a baseline and describe what changes when one is re-set.
  3. Construct a one-page integrated plan for a small project, consistent with its charter.

Prerequisites: Modules 01–02

Key concepts: project management plan · integration · baseline · the constraints trade-off · rolling wave planning · plan depth versus project size

Practical activity: Produce a one-page integrated plan for the Campus Event Portal scenario, showing how scope, schedule, cost, and risk decisions constrain one another.

Assessment / self-check: Peer or self-review using the "could a stranger act on this?" test from How to Self-Assess.

Expected student outcome: You can explain, on a single page, how the parts of a plan hold together — and spot the point at which a change to one part forces a change to another.

An integrative module

This module deliberately cross-references two lessons whose natural homes are later: predictive versus adaptive planning is delivered in session 8 (Module 04), and change control is delivered in session 24 (Module 11, change and configuration management). Module 03 is about seeing the plan as one connected artefact.

Material: Module 03 — Integrated Project Planning

Part II — Agile & Adaptive Delivery

Module 04 — Agile, Scrum & Lean Delivery

Sessions: S8, S9, S10 · Weeks 4–5

Learning objectives. By the end of this module you will be able to:

  1. Explain the values and principles of agile software development and what each implies for how a team works.
  2. Describe the Scrum roles, events, and artefacts, and explain how they reinforce one another.
  3. Apply Kanban concepts — visualised work, explicit policies, and work-in-progress limits — to a flow of work, and explain what a WIP limit is for.
  4. Justify a choice between predictive and adaptive delivery for a given project, using evidence about requirement stability, risk, and stakeholder availability.
  5. Identify at least three common misapplications of agile and predict their consequences.

Prerequisites: Modules 01–03

Key concepts: Agile values and principles · iterative and incremental delivery · Scrum roles, events, and artefacts · product backlog and increment · Lean principles · Kanban board · work in progress · WIP limits · flow versus utilisation · hybrid delivery

Practical activity: Build a product backlog and run an iteration-planning simulation for the Campus Event Portal, then compare the resulting plan against the predictive plan from Module 03.

Assessment / self-check: Self-marked against a planning comparison rubric (planned); a module quiz is planned — see Self-Assessment.

Expected student outcome: You can look at a delivery situation and argue, with reasons, for an agile or a plan-driven approach — and describe what you would do differently under each.

Material: Module 04 — Agile, Scrum & Lean Delivery

Part III — Planning Knowledge Areas

Module 05 — Scope & Requirements Management

Sessions: S11, S12 · Weeks 6

Learning objectives. By the end of this module you will be able to:

  1. Elicit requirements using at least three techniques and select an appropriate technique for a given stakeholder group.
  2. Distinguish functional from non-functional requirements, and write both as verifiable statements.
  3. Construct a work breakdown structure that decomposes scope to work-package level without gaps or overlap.
  4. Define a scope baseline and explain what it protects.
  5. Diagnose scope creep in a scenario and recommend a proportionate response.

Prerequisites: Modules 01–03

Key concepts: requirement · functional and non-functional requirements · elicitation techniques · verifiable requirements · acceptance criteria · work breakdown structure · work package · the 100% rule · scope baseline · scope creep · gold plating · verification versus validation

Practical activity: Write a requirements list for the Campus Event Portal and decompose it into a Work Breakdown Structure, then trace two plausible scope changes back to the baseline.

Assessment / self-check: WBS self-marks against the template's guidance; a module quiz is planned — see Self-Assessment.

Expected student outcome: You can turn an ambiguous request into a bounded, decomposable scope, and explain to a stakeholder why the boundary you drew matters.

Material: Module 05 — Scope & Requirements Management

Module 06 — Schedule Management

Sessions: S13, S14 · Week 7

Learning objectives. By the end of this module you will be able to:

  1. Define activities from work packages and estimate their duration.
  2. Identify dependencies and classify them as mandatory, discretionary, or external.
  3. Construct a network diagram and determine the critical path for a small project.
  4. Calculate total float and explain what float means for managing risk and attention.
  5. Apply schedule compression techniques and evaluate their trade-offs.

Prerequisites: Modules 03 and 05

Key concepts: activity · dependency types · network diagram · critical path · total and free float · milestone · lead and lag · crashing · fast-tracking · schedule as a model, not a promise

Practical activity: Build a Mermaid network diagram and Gantt chart for the Campus Event Portal, identify the critical path, and argue for or against compressing the schedule.

Assessment / self-check: Self-marked against a scheduling checklist (planned); a module quiz is planned — see Self-Assessment.

Expected student outcome: You can turn a work breakdown structure into a defensible schedule and explain which activities actually determine the finish date.

Material: Module 06 — Schedule Management

Module 07 — Cost & Estimation

Sessions: S15, S16 · Week 8

Learning objectives. By the end of this module you will be able to:

  1. Distinguish effort, duration, and cost, and explain why conflating them produces bad estimates.
  2. Apply analogous, expert-judgement, bottom-up, and size-based estimation techniques to the same piece of work and compare the results.
  3. Explain the role of function points and analogous estimation in size-based estimating.
  4. Express an estimate as a range and explain what the range communicates.
  5. Produce a project budget with an explicit contingency reserve.

Prerequisites: Modules 05–06

Key concepts: effort versus duration versus cost · analogous estimation · expert judgement · bottom-up estimation · size-based estimation · function points · estimate ranges · contingency reserve · budget · estimation uncertainty · estimate revision

Practical activity: Estimate the Campus Event Portal using two independent techniques, reconcile the difference, and present the result as a range with a stated confidence.

Assessment / self-check: Self-marked against an estimation-quality rubric (planned); a module quiz is planned — see Self-Assessment.

Expected student outcome: You can produce an estimate you can defend, explain its uncertainty, and say what you would do when someone asks for a single number.

Material: Module 07 — Cost & Estimation

Mid-course checkpoint

Session 17 — Consolidation and capstone checkpoint

Week 9

Purpose. This session contains no new topic. It exists to consolidate the planning half of the course before the control half begins, and to review capstone progress against milestones M1–M3.

Learning objectives. By the end of this session you will be able to:

  1. Demonstrate, from your own artefacts, that the plan is internally consistent.
  2. Identify the weakest link in your plan and state what you will do about it.
  3. Explain how your estimates and schedule depend on your scope baseline.

Prerequisites: Modules 01–07

Key concepts: plan coherence · traceability from charter to schedule · gap analysis.

Practical activity: A structured review of your artefact set: charter → stakeholders → scope → WBS → schedule → estimate. Each artefact must agree with the one before it.

Assessment / self-check: A self-audit checklist; any inconsistency becomes an action item for the capstone.

Expected student outcome: You can defend your plan as a coherent whole, and you know exactly which part of it is weakest.

Part IV — Control & Advanced Practice

Module 08 — Risk Management

Sessions: S18 · Week 9

Learning objectives. By the end of this module you will be able to:

  1. Distinguish risks from issues, assumptions, and constraints.
  2. Identify risks using at least three complementary techniques.
  3. Assess and prioritise risks using probability and impact.
  4. Maintain a risk register with owners, triggers, and responses.
  5. Select appropriate response strategies for threats and for opportunities.

Prerequisites: Modules 01–03

Key concepts: risk · threat and opportunity · issue · assumption · risk register · probability and impact · risk matrix · exposure · avoidance, mitigation, transfer, acceptance · exploit, enhance, share · trigger · residual risk · contingency plan

Practical activity: Build a Risk Register for the Campus Event Portal, including at least one opportunity, and write a contingency plan for the highest exposure.

Assessment / self-check: Self-marked against the risk register guidance; a module quiz is planned — see Self-Assessment.

Expected student outcome: You can find the risks that matter before they happen, decide which deserve action, and name the person who owns each response.

Material: Module 08 — Risk Management

Module 09 — Quality Management

Sessions: S19 · Week 10

Learning objectives. By the end of this module you will be able to:

  1. Define quality in terms of fitness for purpose and conformance to requirements.
  2. Write quality criteria that are specific and verifiable.
  3. Distinguish quality planning, quality assurance, and quality control.
  4. Explain the difference between verification and validation, and place each in a delivery process.
  5. Design a proportionate review and testing strategy, and reason about accepting technical debt.

Prerequisites: Modules 03 and 05

Key concepts: fitness for purpose · conformance · quality criteria · quality planning, assurance, and control · verification versus validation · reviews · testing strategy · definition of done · technical debt

Practical activity: Write acceptance criteria and a review-and-test strategy for the Campus Event Portal, and justify one deliberate decision to accept technical debt.

Assessment / self-check: Self-marked against a quality-plan checklist (planned); a module quiz is planned — see Self-Assessment.

Expected student outcome: You can specify what "good enough" means in testable terms, and explain how your process will catch defects rather than hope to find them late.

Material: Module 09 — Quality Management

Module 10 — Resources, Team & Communication

Sessions: S20, S21 · Weeks 10–11

Learning objectives. By the end of this module you will be able to:

  1. Compare team structures and explain their effects on communication and decision-making.
  2. Explain how team development stages change a team's behaviour over a project.
  3. Identify sources of motivation and de-motivation in a software team.
  4. Apply conflict-handling and negotiation approaches to a realistic disagreement.
  5. Construct a RACI matrix and a communications plan for a project.

Prerequisites: Modules 01–03

Key concepts: team structures · Conway's law · team development stages · motivation · conflict and negotiation · resource allocation · over-allocation · resource levelling · RACI · communication planning · escalation

Practical activity: Produce a RACI matrix and communications plan for the Campus Event Portal, then resolve a scripted conflict between a developer and a stakeholder.

Assessment / self-check: Self-marked against the RACI and communications-plan guidance; a module quiz is planned — see Self-Assessment.

Expected student outcome: You can plan who does what, who is told what and when, and handle a disagreement without damaging the project or the relationship.

Material: Module 10 — Resources, Team & Communication

Module 11 — Metrics, Monitoring & Control

Sessions: S22, S23, S24 · Weeks 11–12

Learning objectives. By the end of this module you will be able to:

  1. Distinguish leading from lagging indicators and select measurements that support decisions.
  2. Track progress against a baseline and interpret schedule and cost variance.
  3. Apply earned value measures responsibly, including schedule and cost performance indices.
  4. Describe flow measures — work in progress, cycle time, throughput — for iterative work.
  5. Produce a clear, honest status report and recommend corrective action.
  6. Explain change control and configuration management, and run a change request through an approval path.

Prerequisites: Modules 03, 06, and 07

Key concepts: metric · leading and lagging indicators · variance · planned value, earned value, actual cost · schedule and cost performance indices · estimate to complete · cycle time · throughput · work in progress · status reporting · escalation · corrective action · change control · change request · configuration management · baseline control · metric gaming

Practical activity: Produce a status report with variance analysis for the Campus Event Portal, plus a completed change request assessed against the scope baseline.

Assessment / self-check: Self-marked against the status report guidance; a module quiz is planned — see Self-Assessment.

Expected student outcome: You can tell how a project is really doing, say so plainly when it is not going well, and control changes instead of absorbing them silently.

Material: Module 11 — Metrics, Monitoring & Control

Module 12 — Advanced Project Management

Sessions: S25, S26, S27, S28, S29 · Weeks 13–15

Learning objectives. By the end of this module you will be able to:

  1. Explain the procurement cycle, select an appropriate contract shape for a piece of work, and identify the risks a contract does not remove.
  2. Produce and maintain the documentation a project needs, and explain the handover pack a closed project must leave behind.
  3. Design a coordination approach for a distributed or remote team, and identify its additional costs.
  4. Evaluate an ethical dilemma in project management and justify a course of action.
  5. Run a project closure, capture lessons learned, and explain why closure is a managed activity.
  6. Explain how projects sit within programmes and portfolios, and why governance decisions may override an individual project's interests.

Prerequisites: Modules 01–11

Key concepts: procurement · statement of work · contract types · vendor management · project documentation · handover · project closure · lessons learned · post-implementation review · distributed and asynchronous work · time-zone coordination · ethical and professional responsibility · portfolio and programme governance · scaling · hybrid delivery

Practical activity: Assemble a closure pack for the Campus Event Portal — documentation, lessons learned, and a post-implementation review — and write a short ethical case analysis.

Assessment / self-check: Self-marked against the retrospective guidance; a module quiz is planned — see Self-Assessment.

Expected student outcome: You can run the parts of a project that extend beyond your own team and beyond delivery day: contracts, documentation, distance, ethics, closure, and the portfolio context that can redirect your project.

Material: Module 12 — Advanced Project Management

Part V — Capstone

Module 13 — Capstone Project

Sessions: S30, S31, S32 · Weeks 15–16

Learning objectives. By the end of this module you will be able to:

  1. Integrate every artefact you have produced into one internally consistent project record.
  2. Deliver a small software project end to end, controlling it against an agreed baseline.
  3. Report honestly on progress, including variance and decisions needed.
  4. Close the project with a defensible post-implementation review and retrospective.

Prerequisites: All modules (01–12)

Key concepts: integration · baseline control · honest reporting · closure · lessons learned · professional judgement.

Practical activity: The capstone itself. Session 30 reviews and baselines the plan; session 31 is a control-and-reporting work session; session 32 is final presentation, closure, and course retrospective. See Module 13 — Capstone Project.

Assessment / self-check: The capstone rubric (planned) and the course retrospective; self-marked against the rubric with the "could a stranger act on this?" test.

Expected student outcome: You can take a small software project from idea to reported close, producing the artefact set a practising project manager would produce, and explain every decision you made.

Material: Module 13 — Capstone Project

Required topic coverage index

Where each of the 29 required topics is taught. Session numbers refer to the master calendar.

# Required topic Module Session
1 Introduction to software project management 01 S1
2 Software projects versus other projects 01 S2
3 Project life cycles and development approaches 01 S3
4 Project stakeholders and governance 02 S4
5 Project initiation and business cases 02 S5
6 Feasibility and project selection 02 S6
7 Requirements and scope management 05 S11
8 Work Breakdown Structure (WBS) 05 S12
9 Project scheduling 06 S13
10 Gantt charts and dependencies 06 S14
11 Agile and predictive approaches 04 S8
12 Scrum roles, events, and artifacts 04 S9
13 Kanban and work-in-progress limits 04 S10
14 Effort and cost estimation 07 S15
15 Function points, expert estimation, and analogous estimation 07 S16
16 Risk identification and response planning 08 S18
17 Quality management and assurance 09 S19
18 Team organization and resource management 10 S20
19 Communication and stakeholder management 10 S21
20 Software project metrics 11 S22
21 Monitoring and control 11 S23
22 Change and configuration management 11 S24
23 Procurement and vendor considerations 12 S25
24 Software project documentation 12 S26
25 Distributed and remote teams 12 S27
26 Ethical and responsible project management 12 S28
27 Project closure and lessons learned 12 S26
28 Advanced project management and governance 12 S29
29 Integrated capstone project 13 S30–S32

Capstone milestones

The capstone is integrated, not bolted on: each milestone reuses artefacts produced in the labs, so no work is wasted.

Milestone Due by Built from
M1 — Charter and stakeholder register Session 6 Lab 01, Module 02 activity
M2 — Scope baseline and WBS Session 12 Module 05 activity
M3 — Schedule and budget Session 16 Modules 06–07 activities
M4 — Risk register and communication plan Session 21 Modules 08 and 10 activities
M5 — Status reports and change request Session 24 Module 11 activity
M6 — Closure pack and retrospective Session 32 Module 12 activity and the capstone itself

Milestones M1–M3 are reviewed at the mid-course checkpoint in session 17.

How this roadmap is validated

The repository ships a checker that verifies this roadmap automatically:

python tools/check-curriculum.py

It confirms that all 32 sessions are present exactly once and span 16 weeks of two sessions; that all 13 modules and all 29 required topics appear; that no module's sessions are interrupted by another module; that no module depends on a later module; that every module has at least three objectives that begin with an observable action verb; and that every module section links its material — the module page, its lessons, and its labs — so this roadmap can be used to navigate the course, not only to read about it.

See the Learning Path for what to study first, the Semester Calendar for the same 32 sessions turned into a week-by-week plan with lab windows and checkpoints, and the Skills Progression Map for how capability develops across the course.