Skip to content

Lesson 3 — Closing and Presenting Your Capstone

At a glance

Learning objectives

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

  1. Confirm acceptance properly: the deliverable, the criteria, the acceptor, and the evidence.
  2. Write a final project report that compares the outcome with the original plan and explains variance rather than excusing it.
  3. Present a project in ten minutes, including one honest problem, without losing the audience's confidence.
  4. Turn lessons into changes that outlive the project, and route them to where they will be found.
  5. Self-assess against the capstone rubric accurately, which is itself a professional skill.

Prerequisites

Introduction

Closure is the stage most often skipped, in the capstone and in professional practice, because the interesting work is finished. What remains is uncomfortable: comparing what happened with what was promised, stating what was not delivered, and admitting what you would do differently.

Two habits make it manageable. First, closure is a comparison, not a verdict — the report's job is to make the difference between plan and outcome legible, not to make it look small. Second, the honest version is more useful and usually scores better, because a project with no recorded variance provides no evidence that the monitoring skill being assessed exists at all.

1. Acceptance: criteria, acceptor, evidence

Acceptance is a transaction, and it needs three things recorded together:

Element Weak Workable
Criteria "The application form works" "An applicant who has not seen the system completes an application unaided in under 10 minutes"
Acceptor "The department is happy" A named person in a named role who observed it
Evidence "Tested" What was demonstrated, on what data, on what date, with what result

For a capstone, your acceptor is the real user from M3 and anyone else you recruited. Record what they said, including what they complained about — an acceptance record with no criticism in it is either a very good system or an incomplete record, and the rubric can tell which by comparing it with your defect log.

2. The final report: comparison, not justification

The final project report is built around four tables, and each one is a comparison:

  1. Outcome against the original plan — the date, the cost, the scope, and the quality bar you promised in the charter, beside what happened. If you re-baselined, both baselines appear, with the cause stated.
  2. Delivered and not delivered — both columns populated. Deliverables that were quietly dropped are the standard way a project's closure fails an audit.
  3. Variance with causes — for each significant variance, what caused it and why it was not prevented. A cause that names a system — requirements undefined at the start, data unavailable until late — is a finding. A cause that names effort is usually a symptom.
  4. Residual limitations and risks — what is still true after closure, who accepted it, and who owns it now. A limitation recorded as accepted is managed; one left unrecorded becomes a surprise.

Two writing rules apply. Separate facts from judgements — "the upload took 11 days against an estimate of 8" is a fact; "the estimate was reasonable" is a judgement, and both belong, clearly labelled. And write the report from the artefacts, not from memory, so that it agrees with everything else you are submitting.

3. Presenting it in ten minutes

If you present your capstone, the structure below works and leaves time for questions. Nine slides, or six with a demonstration.

# Content Time Notes
1 What the project was, and why this one 1 min The rationale from deliverable 1, not a description of the domain
2 What exists now — demonstrate it 2–3 min Working software, on realistic data, by you using it as a user would
3 How you managed it: scope, plan, critical path 1–2 min Show one artefact; the schedule with float is the most informative
4 What went wrong, and what you did 2 min The variance, the cause, the decision, the outcome — this is the high-scoring slide
5 Measures: planned against actual 1 min One honest table beats five charts
6 What is not delivered, and why 1 min Named, with the reason, accepted by you
7 Lessons, with the change each one produced 1 min Owned, and routed to an artefact

On slide 4 — the problem — two things matter. Lead with the variance rather than building up to it, and state the decision you took. An audience loses confidence in a presenter who hides a problem far more than in one who names it and shows what was done about it. If the capstone went badly, that slide is the strongest thing in the presentation, provided the record shows you noticed and responded.

For questions that cannot be answered, the professional answer is "I do not know, and here is how I would find out." Inventing a figure under pressure is the one move that damages a submission's credibility, because it is checkable against your own artefacts.

4. Lessons that outlive the project

A lesson is learned when something a future project will use has changed. Sorting your lessons by destination makes this concrete:

Lesson type Where it must land Example
Estimating An estimating basis in your own template or checklist "File upload with validation is 35–40% more effort than a plain form"
Definition of ready The criteria you would apply before starting similar work "Realistic record volumes must exist before performance work begins"
Process A change to a checklist or a template, not a paragraph A definition-of-done criterion requiring tests against realistic data volume
Environment A setup note, so the next project does not rediscover it The setting that made the test relay behave differently from production
People An onboarding note, or a named deputy for a single-person dependency Who else can operate the release process

Then disposition them honestly: adopted, not adopted (with the reason), or worth proposing (to whoever owns the process). "Not adopted" is a legitimate outcome and recording it is better than a list of intentions nobody will act on.

5. Self-assessment, honestly

Self-marking is part of the capstone, and it is a professional skill rather than a formality: estimating your own performance accurately is what makes improvement possible. Three practical rules:

  1. Mark against the written descriptors, not against your intentions. If the descriptor requires a specific artefact, its absence is the answer, whatever the reason.
  2. Write one sentence of justification per dimension, citing the artefact and the section. If you cannot cite one, that is evidence for the lower level.
  3. Identify your weakest dimension and what would have moved it up one level. That sentence is usually the most valuable output of the whole capstone.

Key terms

Term Meaning
Acceptance A named person confirming the deliverable met stated criteria, with recorded evidence
Original baseline The plan as first approved, retained for comparison after re-baselining
Variance analysis Explaining the difference between plan and outcome by cause
Residual limitation Something still true after closure, accepted by a named person
Routed lesson A lesson placed into an artefact a future project will use
Disposition The recorded decision on a lesson: adopted, not adopted, or proposed
Self-assessment Marking your own work against written descriptors, with justification

Worked example

Task: close the admission-portal capstone at the end of week 8 (part-time pace). Figures are invented for teaching.

Step 1 — Record acceptance properly. The criteria agreed at charter time: an applicant who has not seen the system completes an application unaided within 10 minutes. Two testers attempted it; both completed it, one in 9 minutes and one in 14, with the same sticking point — the file-size message was unclear. The acceptor is the admissions officer who observed the second attempt. The record includes that observation, which is also defect D-014 in the log: acceptance that hides its own criticism is not a record.

Step 2 — Compare against the original plan, not the revised one. The charter promised one end-to-end capability in eight weeks with a single developer. Reality: delivered in eight weeks, with the file-replacement capability deferred and two days of effort unabsorbed in the upload package. The report states the original plan, the one re-baseline in week 3 and its cause, and the outcome against both. The re-baseline is not presented as the achievement: the original promise is the reference point, which is the only version that teaches anyone anything.

Step 3 — State variance with causes, at system level. Two variances matter. First, the upload package took 11 days against an estimate of 8, because the validation rules were undecided when the activity began — a definition-of-ready failure, not an estimating failure, although the estimate was also optimistic for file-handling work. Second, performance verification was compressed, because realistic data arrived in week 6 of 8 — a scheduling error, since the data dependency was known and not planned for. Neither cause is "lack of effort", and naming the system causes is what makes the lessons usable.

Step 4 — Record what is not delivered and what is accepted. Two capabilities deferred (file replacement and multi-programme support), one limitation accepted (the upload validates type and size but not content), owned after closure by whoever continues the work. The report names them rather than letting them disappear into a revised scope.

Step 5 — Route the lessons to destinations. Four lessons, each with a destination: file handling is 35–40% more effort than a simple form (→ an estimating basis); realistic data volumes are a definition-of-ready criterion (→ a checklist the next project will use); the test relay setting differs from production (→ a setup note); one person held all release knowledge (→ a named deputy, recorded as not adopted, because no second person was available). The fourth is honestly marked rather than dressed up.

Step 6 — Present the problem slide first among the interesting content. The presentation gives the demonstration two minutes, then spends two minutes on the upload variance: what was noticed, when, what was decided, and what it cost. The audience's question is "why did the upload overrun?", and the answer — the rules were not decided when the work started, and the criterion that would have caught it is now in the checklist — is a better answer than any explanation of the domain.

Step 7 — Self-assess and name the gap. Marking against the rubric, the strongest dimension is consistency across artefacts (the reconciliation habit from week 3 is visible in seven documents agreeing). The weakest is quality of assumptions: three assumptions in the charter were never tested, and one of them — that the test environment's mail relay behaved like production — was wrong and cost two days. The self-assessment records that as the gap and states the change: assumptions get an owner and a test date, not just a row in a table.

Common misconceptions

“Closure means declaring success”

Closure means making the comparison legible: what was promised, what was delivered, what was not, and why. A report that declares success without the comparison is not closure, and a project whose outcome was mixed but is explained honestly is a better submission than a vague claim of success.

“Presenting a problem weakens the result”

Concealment does more damage than the problem. The audience is assessing whether you noticed, responded, and recorded it — which is exactly what project management is. A variance with a cause, a decision, and an outcome demonstrates more competence than a flawless-looking project that offers no evidence of monitoring.

“Lessons learned means a list of lessons”

A list changes nothing. A lesson changes something only when it lands where a future project will meet it — a checklist, a template, an estimating basis, a setup note — with an owner and a disposition. Lessons that stay in the project folder die with the project.

“Self-assessment is just filling in the rubric”

Marking yourself honestly against written descriptors is the mechanism by which the course's skills transfer to work you do without a rubric. Citing an artefact per dimension, and naming the dimension you would most want to improve, is what makes it useful rather than ceremonial.

Practical activity

Close your capstone.

  1. Write the acceptance record: the criterion, the acceptor (a named person), and the evidence of what was observed — including anything that went wrong during acceptance.
  2. Complete the final project report, comparing against the original plan and stating every re-baseline and its cause.
  3. List what was not delivered and what limitation you accept, with the person accepting it.
  4. Write four lessons, each with a destination and a disposition (adopted, not adopted, or proposed).
  5. Self-assess against the rubric, citing one artefact per dimension, and name the dimension you would most want to improve and what would have moved it up a level.
  6. Prepare a ten-minute presentation using the structure in section 3, and rehearse the problem slide first — it is the one that needs to be clear rather than smooth.

What "good" looks like: an acceptance record that includes the criticism, a report that compares with the original plan rather than the revised one, both delivered and not-delivered columns populated, lessons with destinations and honest dispositions, and a self-assessment that cites artefacts and names a real gap.

Self-assessment

  1. Why must the final report compare with the original plan as well as any revised one?
  2. What three elements make an acceptance a record rather than an opinion?
  3. Why does an honestly presented problem often strengthen a project's assessment?
  4. What makes a lesson "learned" rather than merely "recorded"?

  5. What should you do when asked a question in a presentation that you cannot answer?

  6. Apply it — your final report. Your capstone delivered four of five planned work packages on a re-baselined schedule, and the fifth was dropped. In your report you plan to say that the project was a success because the software works and the user liked it.

    Hint: A strong answer says what the report must compare, what it must not do, and the one limitation it must record.

Show answers
  1. Because the revised plan has already absorbed the earlier variance, so comparing only against it understates the total difference and makes the project look better than it was. The original promise is also the version the organisation needs in order to judge whether its planning is realistic — which is how lessons transfer to future business cases.
  2. Stated criteria that could fail, a named acceptor in a role, and recorded evidence of the demonstration or observation. Without all three, acceptance is one person's recollection, and it cannot be relied on if the deliverable's behaviour is questioned later.
  3. Because the assessment is of the management, not of the luck. Naming a problem, with its cause, the decision taken, and the outcome, demonstrates monitoring and judgement — the skills being assessed — whereas a project reporting no problems provides no evidence that either exists.
  4. A change to something a future project will actually use — a template, a checklist, a definition of ready, an estimating basis, an environment note — with an owner and a recorded disposition. Anything living only in the closed project's folder will not survive the people who wrote it.
  5. Say that you do not know, state what you would do to find out, and be specific about the route — check the log, test it, ask the named person. Inventing an answer is worse than not knowing, because it is checkable against your own artefacts and it undermines everything else you have recorded.
  6. The report compares the outcome against the original plan, not the revised one: state the original date and scope, the re-baseline and its cause, and the variance in both cost and time — then explain it rather than excusing it. Report the dropped work package explicitly, with the decision that dropped it and who made it, in the same place as the delivered items; a report that lists only what happened reads as a justification. Name the residual limitations — for example the fifth package's capability is absent, and whatever the workaround is, it has an owner — and record the acceptance evidence: which criteria were checked, by whom, and what was actually observed. “The user liked it” is a useful observation, not an acceptance record. Finish with what you would do differently, phrased so the next project can act on it.

Summary

  • Acceptance needs criteria, a named acceptor, and recorded evidence — including the criticism.
  • The final report compares the outcome with the original plan, states re-baselines and their causes, lists what was not delivered, and records residual limitations with the person who accepted them.
  • Present the working software, one artefact that shows the plan, and the problem slide — leading with the variance, the decision, and the outcome. State honestly when you do not know something.
  • Lessons are learned only when they land in an artefact a future project will use, with an owner and a disposition. "Not adopted" is an honest outcome; an unrecorded intention is not.
  • Self-assess against the written descriptors, citing one artefact per dimension, and name the dimension you would most want to improve. That sentence is the practical output of the capstone.

Further learning