Learning Path¶

What to study, in what order, and why that order. If you are new to the course, read this page before anything else — it will save you from the most common mistake, which is starting in the middle.

The full 16-week plan is in the Curriculum Roadmap. This page is the student's view of it: the shortest honest explanation of how to get from "I have never managed anything" to "I have planned and delivered a small project".

At a glance

Start here: Module 01, always
Default pace: one module every one to two weeks
Finish with: the capstone project
You need: a coding background, and nothing else

The path at a glance¶

flowchart TD
    accTitle: The six stages of the learning path
    accDescr {
    Stage 1 Foundations, Modules 01 to 02, leads to Stage 2 Planning, Modules 03, 05, 06 and 07,
    then Stage 3 Adaptive delivery, Module 04, Stage 4 Control, Modules 08 to 11, Stage 5
    Professional practice, Module 12, and Stage 6 Capstone, Module 13.
    }
    A["1 · Foundations<br/>Modules 01–02<br/>Learn the vocabulary"] --> B["2 · Planning<br/>Modules 03, 05, 06, 07<br/>Learn to plan"]
    B --> C["3 · Adaptive delivery<br/>Module 04<br/>Learn the alternative"]
    C --> D["4 · Control<br/>Modules 08–11<br/>Learn to run it"]
    D --> E["5 · Professional practice<br/>Module 12<br/>Learn the wider job"]
    E --> F["6 · Capstone<br/>Module 13<br/>Do it for real"]

Each stage assumes the one before it. The order is not arbitrary — see why this order below.

What to study first, and why¶

Start with Module 01, then Module 02. Not Module 06, not the agile material.

Here is the reasoning. Software project management is a vocabulary-heavy discipline, and the words are used differently in ordinary conversation than in project management:

In everyday speech, "risk" means "danger". Here it also means uncertain opportunity, and it is distinct from an issue, which has already happened.
In everyday speech, "estimate" means "a guess". Here it means a prediction with a stated uncertainty.
In everyday speech, "scope" means "what we're doing". Here it is a controlled baseline with an explicit excluded set.

If you skip the foundations, you will memorise techniques without knowing what they are for — and you will apply them to the wrong problems. Modules 01 and 02 install the distinctions that every later module relies on.

Then plan before you go agile. Modules 03, 05, 06, and 07 teach predictive planning: breaking down scope, sequencing work, and estimating cost. Module 04 (agile) is placed after them on purpose. Agile is best understood as a response to the limits of predictive planning — you cannot see what Scrum changes until you have seen what a baseline and a work breakdown structure are. Studying agile first produces people who can recite the ceremonies but cannot plan anything, which is the opposite of the goal.

Then learn to run a project that is already moving. Modules 08–11 cover risk, quality, people, and control. These only make sense once there is a plan to protect.

Then widen to the professional context. Module 12 covers contracts, documentation, distributed teams, ethics, closure, and governance — the parts of the job that extend beyond one team and one delivery.

Finally, do it. The capstone (Module 13) is where you integrate everything. Plan for it to take longer than you expect.

The six stages¶

Stage 1 — Foundations (Modules 01–02)¶

You will learn: what a project is and is not; how software projects differ from other projects; how life cycles work; who the stakeholders are and who decides what.

What you produce: a project charter and a stakeholder register.

You are ready to move on when: you can define "project", "programme", "portfolio", "stakeholder", and "success criterion" without looking them up, and you can name the person who would authorise a change on a project you know.

Stage 2 — Planning (Modules 03, 05, 06, 07)¶

You will learn: how a plan's components constrain each other; how to turn a request into a bounded scope; how to decompose it into a work breakdown structure; how to sequence it into a schedule with a critical path; and how to estimate and budget it.

What you produce: a scope baseline, a WBS, a schedule, and a cost estimate.

You are ready to move on when: you can explain how someone else's schedule would change if one task slipped, and you can express an estimate as a range rather than a number.

The hardest stage

Most students find this stage the most demanding, because it is where the arithmetic lives. Do the labs. Reading a critical-path calculation is nothing like doing one.

Stage 3 — Adaptive delivery (Module 04)¶

You will learn: the values behind agile software development, how Scrum and Kanban work, and how to choose between predictive and adaptive delivery for a real situation.

What you produce: a product backlog and an iteration plan, plus a written argument for your chosen approach on a given project.

You are ready to move on when: you can state three concrete situations where agile is the better fit and three where it is not, with reasons.

Stage 4 — Control (Modules 08–11)¶

You will learn: how to find and plan for risk; how to build quality in; how to organise a team and communicate with stakeholders; how to measure progress honestly; and how to control change rather than absorb it.

What you produce: a risk register, a quality strategy, a RACI matrix, a communications plan, a status report, and a change request.

You are ready to move on when: you can look at a status report that says "green" and ask the question that tests it.

Stage 5 — Professional practice (Module 12)¶

You will learn: the parts of the job that reach beyond your team — procurement and contracts, documentation and handover, distributed working, professional ethics, and project closure — and how projects sit inside programmes and portfolios.

What you produce: a closure pack and a short ethical analysis.

You are ready to move on when: you can explain why a decision that is good for your project might be bad for the organisation, and say who would notice.

Stage 6 — Capstone (Module 13)¶

You will learn: nothing new. You will integrate everything.

What you produce: one coherent project record — charter through to post-implementation review — for a small project you actually plan and deliver.

See Module 13 — Capstone Project to choose a capstone option.

Alternative paths¶

Full 16-week courseSelf-study at your own paceRevising before a capstone or examAlready know the basics

Follow the Curriculum Roadmap exactly: two sessions a week, 32 sessions. This is the intended route and the one the material is written for.

Work module by module. Each module's overview lists what to read, do, and check. Aim for roughly 8–10 hours per module including its labs, and do not skip the labs. Expect the whole course to take about 125 hours including the capstone.

Read the Skills Progression Map and find the highest level where you can honestly tick every "can do" statement. Study the module above it. The map is designed to be worked backwards for exactly this purpose.

If you have managed something before, you can skim Modules 01–02, but do take the Foundations quiz first — it is diagnostic, and it will tell you whether skimming is safe. Do not skip Module 03 or Module 05.

Why this order, and not another¶

Ordering people try	Why it fails
Agile first, everything else later	You learn ceremonies without understanding what planning agile replaces. Students cannot then plan anything.
Tools first (MS Project, Jira, Gantt software)	Tools encode decisions you have not yet learned to make. You produce a chart that is precise and wrong.
Estimation first	Estimation depends on scope and schedule. Estimating an undefined scope is guessing with extra steps.
Skip straight to the capstone	The capstone assesses integration. Without the components there is nothing to integrate.
Jump to advanced topics (scaling, portfolios)	Advanced governance assumes you can already run one project.

What you will be able to do at the end¶

By the time you finish, you should be able to walk into a small software project and:

write the charter and identify who has to approve it,
define and bound the scope, and decompose it,
build a schedule you can defend and explain the critical path,
produce an estimate with an honest uncertainty range,
run the risk, quality, and communication processes,
report honestly on progress, and
close the project with a retrospective that a colleague could learn from.

That is the whole point of the course. The remainder — experience, judgement, and the ability to do it under real pressure — comes from doing it.

Next: read the Curriculum Roadmap for the session-by-session plan, or begin Module 01 — Foundations now.