Skip to content

Capstone Milestones and Submission

Milestones exist to catch a capstone that has quietly stopped being a project — paperwork with no software, or software with no management record. Each one requires evidence, and evidence is something someone else can check.

The milestones

flowchart LR
    accTitle: Capstone milestones with their evidence points
    accDescr {
    M0 scope agreed, M1 charter approved, M2 plan baselined, M3 first increment used, M4 reports
    against the baseline, M5 change decided, and M6 reported close, each leading to the next.
    }
    M0[M0 · Scope agreed] --> M1[M1 · Charter approved]
    M1 --> M2[M2 · Plan baselined]
    M2 --> M3[M3 · First increment used]
    M3 --> M4[M4 · Reports against baseline]
    M4 --> M5[M5 · Change decided]
    M5 --> M6[M6 · Reported close]
ID Milestone Evidence it is met Gate: do not proceed until
M0 Scope agreed A written scope paragraph with at least three explicit exclusions, and the chosen option with its rationale You can say what will exist at the end in one sentence, and what will not
M1 Charter approved Charter with observable success criteria, constraints separated from assumptions, and authority stated The success criteria could be checked by someone who is not you
M2 Plan baselined WBS, schedule with float and the critical path, estimate with a range and basis, risk register, quality plan, communication plan The schedule's durations and the estimate's effort reconcile, or you have explained why they differ
M3 First increment used by someone else A working capability, demonstrated on realistic data, plus a note of what the user said — including what did not work Someone who is not you has used it and told you something specific
M4 Second increment and reports against baseline The second increment plus at least two status reports written during the project, containing measured variance and a decision required The reports contain actuals, not plans restated
M5 Change evaluated and decided A change request against the untouched baseline, with options and costs, decided by a named authority The baseline was updated, or the rejection or deferral was recorded
M6 Reported close and lessons Final project report comparing the outcome with the original plan, and a lessons register with owned changes Variance is explained, not hidden, and at least one lesson changes something a future project would use

M3 is the milestone that matters most

A working increment that only you have seen is not evidence that anything is usable. Finding a real user is part of the assignment, and the discomfort of watching someone struggle with your interface is the most useful hour of the whole capstone.

Pacing

Choose the pace that matches your situation, and put the dates in your milestone plan.

Pace Duration Milestones by week Notes
Intensive (full-time) 4 weeks M0–M1 w1 · M2 w2 · M3 w3 · M4–M6 w4 Feasible only with a small, fixed scope. Two status reports require two reporting points, so plan weekly cadence
Standard (part-time) 8 weeks M0–M1 w1–2 · M2 w3 · M3 w5 · M4 w6–7 · M5 w7 · M6 w8 The recommended pace. Two increments, two reports, one change — enough to exercise everything
Term-length (alongside study) 14–16 weeks M0–M1 w1–2 · M2 w3–4 · M3 w8 · M4 w10–13 · M5 w12 · M6 w15–16 Allows a more ambitious capability, and requires discipline in keeping actuals

Three practical rules regardless of pace:

  1. Record actuals weekly. Effort and dates, as they happen. A reconstruction at the end is not evidence, and it is the single most common reason a strong project scores badly.
  2. Write each status report before the next period begins. A report written afterwards is a summary.
  3. Keep one folder per project, with filenames that sort sensibly — 01-charter.md, 06-wbs.md, and so on, matching the deliverable numbers.

Submission checklist

Selection and authorisation

  • Deliverable 1 — selection and rationale, with the scope paragraph and at least three exclusions
  • Deliverable 2 — charter with observable success criteria, plus the business case with benefits
  • The delivery approach is stated (predictive, adaptive, or hybrid) with its reason

Definition

  • Deliverable 3 — stakeholder register with at least six stakeholders and one non-supportive high-influence stakeholder, plus the RACI
  • Deliverable 4 — scope statement with testable acceptance criteria, exclusions, assumptions, constraints
  • Deliverable 5 — requirements overview with the three traceability checks run and their findings recorded

Planning

  • Deliverable 6 — WBS with owners and estimates, satisfying the 100% rule against the scope statement
  • Deliverable 7 — schedule with float, critical path, calendar, and its basis stated
  • Deliverable 8 — estimates with a basis and a range; budget arithmetic that can be checked
  • Deliverable 9 — risk register with owners, triggers, residual exposure, an opportunity, and an accepted risk
  • Deliverable 10 — quality plan with numeric exit criteria, definition of done, and a defect log
  • Deliverable 11 — communication plan, with escalation triggers and time limits

Control

  • Deliverable 12 — monitoring approach: measures with pre-agreed thresholds, two status reports written during delivery, issue log, decision log
  • Deliverable 13 — change request evaluated against the untouched baseline, with options and a recorded decision

Close

  • Deliverable 14 — final project report compared with the original plan, with variance explained
  • Deliverable 15 — lessons learned with owned changes and at least one thing that went well
  • The consistency checks on the deliverables page have been run
  • Self-assessment completed against the capstone rubric

Failure modes, and what to do about them

What you notice What it usually means What to do
Everything planned, nothing built, M3 approaching Scope was decided by enthusiasm Halve the scope to one capability and re-plan the milestone dates
Documents are beautiful, software is absent Effort went to the artefacts because they are easier Stop writing; deliver the smallest usable capability and use it with a real user
Charter says one thing, reports say another The charter was never revisited Update the charter through change control, and note what changed and why
Status reports contain no variance Either the plan was too loose to measure, or reporting is sanitised Re-baseline so that measurement is meaningful, and report the variance you have
Reports were written at the end Actuals were not recorded as you went Say so honestly in the report; a retrospective admission is better than an invented timeline
The change request has no cost figures It was evaluated after the decision Re-derive the impact, and record that the assessment was retrospective
Lessons are generalities They were written without looking at the artefacts Anchor each lesson in a specific artefact and a specific consequence

If the capstone goes wrong

Projects go wrong, and the capstone is designed so that a project going wrong is still a valuable submission — provided you handled it. What the rubric rewards is detection and honest response:

  1. Record what happened when you noticed it, not when it was resolved.
  2. Report it in a status report with the consequence stated, as you would on a real project.
  3. Evaluate your options with costs — reduce scope, extend, or re-baseline — and get the decision recorded.
  4. Reflect on it in the lessons register, naming what you would do differently and what signal you would watch for next time.

A capstone that slipped, was noticed late, and was re-baselined honestly can score higher than one that apparently went perfectly, because a project with no recorded variance provides no evidence that the monitoring skill exists. The one thing that cannot be recovered is reporting that quietly stopped being true.