13. Capstone Project¶
At a glance
- Module: 13 of 13 · Part V — Capstone
- Sessions: S30–S32 (Weeks 15–16), with milestones from S6 onward
- Level: Advanced
- Estimated time: ~20–30 hours, spread over 4–8 weeks
- Prerequisites: All preceding modules, or a plan to close the gaps
- Deliverables: 15 artefacts, assessed by the capstone rubric
Overview¶
The capstone is where the course comes together. You take one realistic software product from an idea to a delivered, reported, closed outcome — producing the artefacts a practising project manager would produce along the way, and managing the project against the plan you wrote.
What is assessed is integration: whether you can pull scope, schedule, cost, risk, quality, and communication into one coherent piece of work, notice when reality diverges from plan, and report it honestly. There is no new theory. The software is the vehicle, not the subject.
A modest project, managed completely, beats an ambitious one abandoned
This is the single most important sentence in the module. A small working capability that a real user has used, with an honest record of how the plan met reality, demonstrates more of what the course teaches than an impressive system whose reports were never written.
Start here¶
| Step | Read |
|---|---|
| 1. Understand what you are building and how it is assessed | This page, then the deliverables |
| 2. Choose and justify your project | Capstone options — five scenarios and how to adapt them |
| 3. Plan it properly | Lesson 1 — Planning Your Capstone |
| 4. Run it | Lesson 2 — Delivering and Controlling Your Capstone |
| 5. Close and present it | Lesson 3 — Closing and Presenting Your Capstone |
| 6. Check your work | Milestones and submission, then the rubric |
Lesson plan¶
| # | Lesson | Session | Status |
|---|---|---|---|
| 01 | Planning Your Capstone | S30 | Available |
| 02 | Delivering and Controlling Your Capstone | S31 | Available |
| 03 | Closing and Presenting Your Capstone | S32 | Available |
What you will produce¶
Fifteen deliverables, from selection through to lessons learned. Each one is traceable to the module that teaches it and the template that structures it — the full mapping is on the deliverables page.
| Group | Deliverables |
|---|---|
| Select and authorise | Project selection and rationale · Project charter and business case |
| Define | Stakeholder register · Scope definition · Requirements overview |
| Plan | Work breakdown structure · Project schedule · Effort and cost estimates · Risk register · Quality plan · Communication plan |
| Control | Monitoring approach · Change request scenario |
| Close | Final project report · Lessons learned |
Capstone options¶
Choose one of five scenarios, or propose your own of equivalent scope — see Capstone options for the detail, the difficulty each one presents, and the rationale you are asked to write:
- Option A — University Learning Management System — many diverse users, term-driven deadlines, accessibility obligations, migration from existing tools.
- Option B — Hospital Appointment Platform — safety-critical context, strict regulation, conflicting clinical and administrative priorities, a service that cannot stop.
- Option C — Public Service Complaint Portal — procurement and contracts, accessibility as a legal requirement, a public audience, policy-set scope.
- Option D — Data Analytics and Reporting Platform — genuinely unclear requirements at the start, unknown data quality, a contested definition of "done".
- Option E — E-Commerce Application — commercial pressure, third-party dependencies, seasonal demand, and constant feature requests.
Same scenarios, different emphasis
These are the example-project library projects, deliberately reused. If you have worked through the lessons using one of them, your familiarity is an advantage — the capstone is about managing the project, not about learning a new domain.
How it is delivered¶
There is no single correct delivery approach, and choosing one is part of the assessment.
| Track | What you produce instead | Assessment emphasis |
|---|---|---|
| Predictive | One baseline, status reports against it, variance analysis | Variance detection and honest reporting |
| Adaptive | Product backlog, sprint reviews, a velocity or throughput record | Requirement handling change and predictability |
| Hybrid | A baseline for the fixed-date or regulatory parts, iterations for the rest | Whether the split is justified and managed |
State your choice and your reason in the charter. An unjustified choice is a weaker submission than a justified imperfect one.
Milestones¶
flowchart LR
accTitle: The six capstone milestones in order
accDescr {
Scope agreed leads to charter approved, plan baselined, a first increment used by someone else,
a second increment with reports against the baseline, a change evaluated and decided, and
finally a reported close with lessons learned.
}
M0[Scope agreed] --> M1[Charter approved]
M1 --> M2[Plan baselined]
M2 --> M3[First increment used by someone else]
M3 --> M4[Second increment and reports against baseline]
M4 --> M5[Change evaluated and decided]
M5 --> M6[Reported close and lessons learned]Evidence for each milestone, a paced schedule for full-time and part-time study, and the submission checklist are on the milestones and submission page.
How it is assessed¶
Self-assess against the capstone rubric, or submit for instructor marking. The rubric has eight dimensions and weights coherence across artefacts heavily: whether your charter, plan, reports, and lessons tell one consistent, honest story.
Three things the rubric deliberately does not reward: the size of the software, the polish of the formatting beyond professional adequacy, and any claim that cannot be checked against your own artefacts. A project that hit problems, recorded them while they were actionable, and adjusted is a strong submission. A project that reports no variance at all is either extraordinary or not reporting.
Before you start¶
- I have completed Modules 01–12, or written down how I will close the gaps.
- I have read the deliverables and the rubric.
- I have chosen a capstone option and written a one-paragraph scope with exclusions.
- I have a folder for my artefacts, and a plan for recording actuals as I go.
- I have named a real user who will use the first increment — the M3 requirement.
Begin with Lesson 1 — Planning Your Capstone.
After the capstone¶
Nothing here tells you the course is finished and closes the door. When your lessons-learned register is written and presented, four things are worth your time:
| Do this | Why |
|---|---|
| Read the Skills Progression Map again | Find the highest level where you can honestly tick every statement. That is the most useful thing you will take from the course — a specific account of what you can now do, and what you cannot yet |
| Skim the Common Misconceptions list | It is the fastest way to find what you learned to say but not to apply |
| Work the Advanced Practice Track | Eight lessons on governance, portfolio context, complex stakeholders, advanced risk, schedule–cost–debt trade-offs, recovery, delivery metrics, and cross-organisational practice |
| Report what did not work | A confusing lesson, a wrong answer, a broken link, or a claim you could not verify — open an issue. Every correction improves the course for the next student |
Two honest statements about what completing this course does and does not mean: it is not a certification, and no certificate, badge, or accreditation is issued at the end of it; and it is not a substitute for running a real project with a real team, which is the next thing to go and do.