Skip to content

Lesson 1 — Planning Your Capstone

At a glance

  • Module: 13 — Capstone
  • Level: Advanced
  • Estimated time: 60 minutes (plus delivery time)
  • Example project: any of the example projects, or your own

Learning objectives

By the end of this lesson you should be able to:

  1. Choose a capstone scope that is deliverable in the available time.
  2. Sequence the artefacts so each one builds on the last rather than restarting.
  3. Set milestones you can actually reach, and self-assess against the course's capability ladder.
  4. Recognise the failure modes that most often sink a capstone, and avoid them.

Prerequisites

  • Modules 01 through 12

Introduction

The capstone is not a new topic. It is the same twelve modules applied to one small project, without the scaffolding of an exercise. That is the point: integration is the skill being assessed, and integration is what a single-topic exam cannot test.

This lesson is the planning lesson for the capstone — the equivalent of Session 1 of a project you are about to run. Work through it before you write anything else.

1. Choosing a scope you can finish

The most common capstone failure is ambition. A modest project managed completely scores far better than an impressive one abandoned in the middle, because the artefacts are the assessment, and a plan with no reports behind it demonstrates nothing.

A workable size, part-time:

Dimension Workable Too large
Duration 3–6 weeks part-time A full term, unattended
Software One capability, working end to end A platform with several modules
Team You, or 2–4 people More than 5 without a coordinator
Artefacts The full management set, at small scale A large set, half-complete

Choose one of the options in the capstone overview, or propose your own of equivalent scope. Then write one paragraph of scope — what will exist when you are done, and what will not. The "what will not" half is the part that keeps the project finishable.

2. The artefacts, in order

Each artefact depends on the one before it. Producing them in this order means you never write something twice.

# Artefact Builds on Template
1 Business case and charter Your scope paragraph Project Charter
2 Stakeholder register Charter Stakeholder Register
3 Requirements with acceptance criteria Charter Lesson template guidance
4 Scope statement and WBS Requirements Work Breakdown Structure
5 Schedule with critical path WBS (Module 06 practical activity)
6 Cost estimate and budget Schedule (Module 07 practical activity)
7 Risk register Charter and plan Risk Register
8 RACI Team and scope RACI Matrix
9 Communication plan Stakeholder register Communications Plan
10 Two or more status reports Baseline and actuals Status Report
11 Retrospective and lessons learned The whole project Retrospective

Note what is missing from that list: a separate large design document, meeting minutes, and a standalone test plan. They are not required, and adding them is how a capstone becomes a documentation exercise instead of a project.

3. Milestones

Set milestones that produce evidence, not intentions.

flowchart LR
    accTitle: Capstone milestones from planning to delivery
    accDescr {
    Scope agreed leads to charter approved, plan baselined, a first increment delivered, a second
    increment delivered, and a reported close with a retrospective.
    }
    M0[Scope agreed] --> M1[Charter approved]
    M1 --> M2[Plan baselined]
    M2 --> M3[First increment delivered]
    M3 --> M4[Second increment delivered]
    M4 --> M5[Reported close and retrospective]
Milestone Evidence it is met
M0 Scope agreed A written scope paragraph with explicit exclusions
M1 Charter approved Charter with success criteria and constraints
M2 Plan baselined WBS, schedule with critical path, budget, risk register
M3 First increment Something working that someone else has used
M4 Second increment A second increment, plus at least one status report against the baseline
M5 Reported close Acceptance, retrospective, and lessons placed in a template

The M3 threshold matters most: someone else must use it. A working increment that only you have seen is not evidence that the system is usable, and usability is one of the quality attributes the course has been building toward.

4. Capstone failure modes

Failure mode How it presents Prevention
Ambition Everything planned, nothing finished Write exclusions in the scope paragraph
Artefacts without a project Beautiful documents, no software Make M3 and M4 mandatory before the paperwork is polished
Inconsistent story Charter says one thing, reports say another Revisit the charter at each milestone; update rather than contradict
No actuals Reports contain plans, not measurements Record real dates and effort as you go, not at the end
Sanitised reporting No problems described A project with no variance teaches nothing; record the one you hit
Unowned lessons Retrospective notes written and filed Put each lesson into a template the next project will use

The most common is the fourth. A status report written at the end from memory is a summary, not a report, and the difference is visible immediately.

5. Self-assessing your readiness

Before you begin, assess yourself against the capability ladder in Skills Progression. The level you are aiming for is Controller: able to run a small project against a baseline, measure it, and report honestly on what happened.

A practical readiness check — can you, unaided:

  • Turn a paragraph of scope into a WBS with acceptance criteria?
  • Find the critical path through a network of five or more activities?
  • Produce a cost estimate that shows its assumptions and a range?
  • Write five risk statements in cause–event–impact form with owners?
  • State a definition of done you could test?
  • Write a status report that leads with variance and states a decision required?

Any item you cannot do unaided points to a specific module to revisit. That is the whole purpose of the check: it converts a vague sense of readiness into a short reading list.

Key terms

Term Meaning
Scope paragraph One paragraph stating what will and will not exist
Baseline The approved version of scope, schedule, and cost
Increment A usable addition to the product
Evidence Something observable that demonstrates a milestone is met
Actuals Recorded real dates, effort, and costs
Capability ladder The five-level progression in Skills Progression

Worked example

Task: plan a capstone on the illustrative university admission portal, scoped to six weeks part-time. Details are invented for teaching.

Step 1 — Write the scope paragraph, exclusions first. "An online application form for one programme: applicants create an account, complete and submit an application, upload one document, and receive an acknowledgement. Excluded: eligibility rules, notifications, payment, multi-programme support, and integration with the student records system." Six exclusions is what makes the project finishable in six weeks.

Step 2 — Choose the option and the track. Option A (build it), predictive baseline with two increments — chosen deliberately, because the cost is the artefact of interest and a single baseline makes variance visible. Option C (adaptive) would be equally valid and would produce a velocity record instead.

Step 3 — Write the charter. Success criteria are stated as observable outcomes: a real applicant completes an application unaided; a department administrator can see the submitted application; an acceptance criterion exists for every requirement. Constraints: one developer, six weeks, part-time availability.

Step 4 — Build the artefacts in dependency order. Requirements first — six of them, each with an acceptance criterion. Then the WBS, then the schedule with the critical path. Two of the six requirements fail the "can this be tested?" test on first writing and are rewritten, which is the cheapest possible time to discover it.

Step 5 — Set milestones with evidence. M3 requires that a real applicant completes an application unaided — a person who is not the builder. The first attempt exposes a validation message that makes no sense to anyone outside the project. That is the increment doing its job.

Step 6 — Record actuals as you go. Effort is logged per activity each week. The estimate proves optimistic by about 30%, concentrated in the document-upload activity, which is the most valuable single sentence the project will produce.

Step 7 — Write the status reports during the project, not after. Two reports against the baseline, each with real variance and a decision recorded. The second contains the finding from step 6 while it is still actionable.

Step 8 — Close and put the lessons where they will be found. The retrospective produces three changes. The most important — "estimate file handling and validation separately, they are consistently underestimated" — goes into the estimating guidance in the course's own templates, not into a folder.

Step 9 — Self-assess against the ladder. Evidence for each capability is named: the critical path computation, the risk register, the definition of done, the two reports. The capstone is assessed on coherence across artefacts, and this is what coherence means.

Common misconceptions

“A bigger project scores better”

Assessment weights coherence and completeness of the management artefacts. An abandoned ambitious project has no reports, no variance, and no retrospective — it demonstrates the least, not the most.

“The software matters most”

The software is the vehicle. A small working capability that someone else has used, with an honest record of how the plan met reality, is the strongest submission there is.

“Status reports can be written at the end”

A report written afterwards is a summary. What is being assessed is whether you noticed variance while it was still actionable and recorded what you did — which requires writing it as it happened.

Practical activity

Plan the capstone.

  1. Choose a capstone option and write your scope paragraph, with at least three explicit exclusions.
  2. Draft the charter with success criteria stated as observable outcomes.
  3. Build the six-milestone plan, and for each milestone state the evidence that would show it is met.
  4. Complete the readiness checklist, and list the modules you need to revisit.
  5. Set up your artefact folder and record your first actuals entry.

What "good" looks like: a scope with real exclusions, success criteria that could be observed by someone else, milestone evidence that could be falsified, and an honest readiness list rather than a ticked box on every line.

Self-assessment

  1. Why does writing the exclusions matter more than writing the scope?
  2. What makes a milestone evidence rather than an intention?
  3. Why is a status report written at the end of the project of limited value?

  4. Your readiness check shows you cannot compute a critical path. What should you do?

  5. Apply it — your capstone. Working alone, you have chosen an e-commerce platform and sketched the full feature set of a real store: catalogue, basket, payments, delivery tracking, returns, reviews, loyalty points, and an admin back office. You have roughly eight weeks of part-time effort.

    Hint: A strong answer cuts the scope explicitly and says how the exclusions will be recorded.

Show answers
  1. Because the exclusions are what determine whether the project can be finished. Scope grows by default unless something forbids it, and a scope paragraph with no exclusions has no boundary.
  2. It is observable and could be falsified — a real user completed an application unaided; a report contains measured variance. An intention to "complete the build" cannot be checked.
  3. Because its purpose is to inform a decision while the decision is still available. Written afterwards it records what happened and cannot change it, so it demonstrates none of the monitoring skill being assessed.
  4. Return to Module 06 and do the practical activity rather than reading it. The readiness check exists to route you to a specific short piece of work, not to discourage you.
  5. The scope cannot be built at this size, so write the exclusions as carefully as the inclusions: for example, one release with catalogue, basket, and a payment-provider integration; returns, reviews, loyalty points, and the admin back office explicitly out of scope, each with a sentence saying why (they depend on data you do not have, or they need a user you cannot reach). Then choose the sequence so nothing is written twice: charter and stakeholders, scope and WBS, schedule and estimates, risk register, and only then delivery, with actuals recorded as you go. Set milestones that produce evidence rather than documents — the strongest first milestone is a working increment shown to one real user. If the reduced scope still feels tight, cut again: a finished small capstone demonstrates every technique, while an unfinished large one demonstrates none.

Summary

  • Choose a scope you can finish, and write the exclusions as carefully as the inclusions.
  • Build artefacts in dependency order so nothing is written twice.
  • Set milestones that produce evidence, including a real user for the first increment.
  • Record actuals and write status reports during the project; a report written afterwards is a summary.
  • Use the readiness checklist to convert a vague sense of unease into a short reading list.

Further learning

Next

You have completed the course content. Continue to the capstone overview to begin delivery.