Fifteen deliverables, produced in dependency order so that nothing is written twice. Each one names the
module that teaches it, the template that structures it, and what "complete" means — because a document
that exists is not the same as a deliverable that can be judged.
Build them in order
Each deliverable depends on the one before it. Producing them out of order is the surest way to write
a document twice, and the second version will contradict the first.
The chosen option, the difficulty it lets you practise, the scope paragraph with at least three exclusions, and the delivery approach with its reason — all present, and no longer than a page
Success criteria that a stranger could observe; constraints separated from assumptions; authority stated; a named sponsor role; benefits with a measure and an owner — and where no baseline exists, that is stated rather than invented
At least six stakeholders, each with interest, influence, attitude, what they need, and an engagement action; at least one high-influence stakeholder who is not supportive, and one whose influence does not come from formal authority
In-scope deliverables with acceptance criteria that a third party could test; at least four explicit exclusions with reasons; assumptions separated from constraints, each with its consequence if false
Every requirement has an ID, a source, a priority, an acceptance criterion, and a verification method; the three traceability checks have been run and their findings recorded — including any requirement that failed
Decomposed by deliverable to work packages that one person can own; every package has an owner and an estimate; the 100% rule holds against the scope statement — every scope item appears, and nothing outside it does
Activities with durations, predecessors, and a dependency class; forward and backward pass with float shown; the critical path identified and a valid chain; dates converted on a stated working calendar; and the schedule's basis stated, including the productivity assumption
Every estimate carries its basis and a range, not just a number; at least one estimate uses a technique other than analogy (three-point, expert judgement, or function points); the budget shows overhead, contingency, and what is excluded — with arithmetic that can be checked
At least eight risks in cause–event–effect form with owners and triggers; the scoring scale agreed and applied consistently; residual exposure recorded after responses; at least one opportunity; and at least one risk that is genuinely accepted, with the decider named
Quality attributes with a measure and a target; prevention activities distinguished from detection activities; release exit criteria that are numeric and could fail; a definition of done applied to real items; and a defect log with cause categories recorded
Every high-influence stakeholder from deliverable 3 appears; each row has an owner and a frequency you actually sustained; escalation has a trigger, a recipient, and a time limit; the RACI has exactly one accountable role per row
A small measure set with thresholds agreed before they were needed; at least two status reports written during the project, not afterwards, each leading with variance and stating a decision required; an issue log and a decision log with real entries; and at least one measure that told you something you did not already know
A change evaluated against the untouched baseline with scope, schedule, cost, quality, and risk impacts; at least three options with costs; a recommendation with a reason; a recorded decision by a named authority; and the baseline updated, or the decision to reject or defer recorded
The outcome stated against the original plan, variance explained with its cause, actuals reported rather than re-planned, delivered and not-delivered both listed, residual limitations accepted by name, and the handover owner identified
At least four lessons, each with the situation, the insight, and a change to practice with an owner and a way of knowing it worked; at least one lesson about something that went well; and at least one routed to an artefact a future project would use
If you want more from the capstone, these add difficulty without changing the core requirement. They are not
assessed, and doing them badly is worse than not doing them:
Quantify a trade-off using Advanced Lesson 5:
a cost slope for crashing, or a fast-tracking option with rework probability and expected rework.
Run a recovery using Advanced Lesson 6:
triage, a stabilisation phase, two decisive moves, and an honest re-baseline.
Add a supplier dimension using Advanced Lesson 8:
a contract type with its behavioural consequences, an interface register, and a distance cost estimate.
Write a governance pack using Advanced Lesson 1:
a decision rights table with numeric limits and a change threshold design.