Skip to content

Lesson 2 — Delivering and Controlling Your Capstone

At a glance

Learning objectives

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

  1. Record actuals as you go, in a form that makes variance visible without extra tooling.
  2. Run a monitoring cycle on your own project: measures, thresholds, a status report, and a decision.
  3. Diagnose the difference between working on the wrong thing, working slowly, and reporting inaccurately — and respond to each.
  4. Handle a mid-project change without silently re-defining the baseline.
  5. Keep your artefacts consistent while the project moves underneath them.

Prerequisites

Introduction

Planning a capstone demonstrates that you can plan. Delivering one demonstrates the harder skill: noticing what is actually happening, while it is still happening, and responding to it. The capstone deliberately makes this difficult in a particular way — you are your own project manager, so there is nobody else to notice the slip, and no meeting forcing you to look.

The trap is well concealed. When a project has one person, the easiest thing to protect is the belief that it is going fine. Work continues, documents get polished, and the milestone that requires a real user keeps being deferred — because asking someone to use half-finished software is the most exposing part of the whole exercise. This lesson is largely about doing it anyway, in the order that makes it useful.

1. Recording actuals: the minimum that works

You need three things, and nothing more:

Record When Why
Effort actually spent, per work package At the end of each working session The comparison with your estimate is the single most valuable finding your capstone produces
Dates: planned against actual, per activity When an activity finishes, not when you remember Variance is only visible if it is dated
What changed — scope, dependencies, assumptions As it happens, one line each The raw material for your change request and lessons

The cheapest workable method is a single table appended to weekly, or a spreadsheet with one row per work package. What matters is that it is written during the period. A reconstruction at the end is a summary, and the difference is visible in the rubric's practical-reasoning dimension.

2. Your monitoring cycle

Run a short cycle — weekly is right for most capstone paces — with four steps:

  1. Measure against thresholds you set before you needed them. Three or four measures are plenty: milestone slip in days, work packages completed against planned, open defects, and blocked items. Thresholds come from the project dashboard template you produced in deliverable 12.
  2. Write the status report, leading with variance and the decision required. If there is no variance, say so and state the evidence — a report that is always green and never explains itself teaches nothing.
  3. Make one decision. It can be small: drop a task, split an activity, get the missing data, or ask for help. A monitoring cycle with no decision is a diary.
  4. Update the artefacts the decision affects. This is the step that keeps the submission coherent, and the one most often skipped.

3. Three diagnoses, three responses

Trouble in a solo project looks the same in all three cases — the milestone moves. The response is different in each, and confusing them wastes the time you do not have.

Diagnosis Evidence Response
Working on the wrong thing The effort is being spent, but not on the critical path; scope has quietly grown Stop, re-read the scope statement, and cut back to the launch capability
Working slowly The activity is on the critical path, and it is taking longer than estimated for a reason you did not anticipate Re-estimate honestly with a range, check whether the cause is a missing skill or an unclear requirement, and apply the Lesson 5 trade-offs rather than general effort
Reporting inaccurately The report says Green, and you would not defend that to a stranger Fix the report first. Optimism here is more damaging than the slip itself, because it removes the option to act

The third row is the important one for a solo project. There is no one to disagree with you, so the only protection against drifting into flattering reports is a written standard: would a stranger reading this conclude the same thing? Applying that test weekly is the entire discipline.

4. Handling the change scenario

Your capstone requires one change request (deliverable 13), described on the change scenario page. Three habits make it a genuine exercise rather than a formality:

  • Assess against the untouched baseline. If you assess a change against a plan you have already slipped, every change looks affordable. Keep the original figures.
  • Look for the underlying need. The requested solution is often more expensive than the need it serves — a confirmation screen instead of an email, a report instead of a notification.
  • Record the decision, then reconcile. A change that is decided but never reflected in the baseline makes every later report unexplainable.

5. Keeping the artefacts consistent

Coherence is weighted heavily in the rubric, and it degrades quietly. Four habits prevent most of it:

  1. One source of truth per fact. If the finish date appears in four documents, three will eventually be wrong. Decide where the canonical version lives and reference it elsewhere.
  2. Update in the same session as the decision. A change decided on Tuesday and reflected next month has already propagated errors.
  3. Re-run the consistency checks on the deliverables page at each milestone, not once at the end.
  4. Write the report from the artefacts, not from memory. This is how a discrepancy gets found while it can still be fixed.

Key terms

Term Meaning
Actuals Effort, dates, and costs as they really occurred
Variance The difference between planned and actual, with a cause
Monitoring cycle A short, repeating sequence of measure, report, decide, update
Threshold The level of variance at which a decision must be taken
Untouched baseline The original approved plan, used as the reference for assessing a change
Reconciliation Updating affected artefacts once a change is decided
Consistency check A check that two artefacts that should agree actually do

Worked example

Task: run the middle of a capstone on the admission-portal option, six-week pace, at the end of week 3. Figures are invented for teaching.

Step 1 — Read the actuals instead of the feeling. Effort logged per work package shows the document upload package at 11 person-days against an estimate of 8, and the admin review console untouched. Two packages are complete against a plan of three. That is the picture: one activity is over on the critical path, and the work that slipped is not the work that matters. Reading logged effort rather than recollection is what makes the next step possible.

Step 2 — Diagnose before responding. The upload overrun is not slow work: the validation rules were not decided until halfway through, so the activity was effectively re-estimated in progress. That is unclear requirements, not insufficient effort, and the response is to decide the rules and move on — not to work evenings on the console.

Step 3 — Write the status report, with the variance leading. Four working days behind on the upload, one day of that absorbed by float, three days of schedule effect. Cause: validation rules undecided at the start of the activity — which was itself a symptom of a definition-of-ready criterion that the team had skipped. Consequence: the first increment moves from week 4 to week 5 unless scope is reduced. Decision required: which of the two deferrable scope items comes out.

Step 4 — Make the decision and record it. The decision is to defer the file-replacement capability, keeping a single-file upload. It is recorded in the decision log with the reason — it is inside the agreed scope boundary, so it is a prioritisation decision rather than a change request — and the scope statement is updated to move the item to "deferrable".

Step 5 — Update every affected artefact in the same session. Schedule: the first increment moves one week. WBS: the deferred package marked as not in this release. Dashboard: the completed-against-planned measure updated with the new denominator. Requirements matrix: the deferred capability's status changed to deferred. Five minutes of work, and it is what stops the submission from contradicting itself three weeks later.

Step 6 — Apply the stranger test to the report. The draft says the project is "slightly behind schedule". A stranger would not know by how much, on which path, or what it means for the milestone. The report is rewritten to say four days on one activity, one absorbed, three of schedule effect, and the milestone moving from week 4 to week 5 with the reason. That rewrite is the monitoring skill the rubric is looking for, and it takes ten minutes.

Common misconceptions

“I will write up the actuals at the end”

By then the effort is a recollection, the dates are approximations, and the variance analysis — the part that carries the most assessment weight — becomes a guess. Recording takes about two minutes per session; reconstructing takes hours and produces weaker evidence.

“The report is Green because I am still working on it”

Effort is not progress. A report is green when the plan's measures are inside their thresholds, and if the milestone date has moved, the report must say so regardless of hours spent.

“A small change does not need the process”

Small changes are exactly the ones that never get recorded — and a series of unrecorded small changes is how a baseline becomes fiction. Log first, assess second, and note that the assessment for a small change can be a sentence.

“Consistency checks are a final tidy-up”

They are a weekly control. Run at the end, they produce a rewrite; run during delivery, they produce a decision — and the same discrepancy costs far less while the work around it is still in progress.

Practical activity

Run one full monitoring cycle on your capstone, in writing.

  1. Log the current actuals: effort per work package and planned versus actual dates. Use only records made during the work.
  2. Compute the variance for each measure in your dashboard, and apply your thresholds. Mark each item Green, Amber, or Red.
  3. Diagnose the largest variance using the three diagnoses in section 3. Name which one it is, and the evidence.
  4. Write a one-page status report leading with that variance, its cause, its consequence, and the decision required. Apply the stranger test before finishing.
  5. Make the decision, record it in your decision log, and update every artefact it affects in the same sitting. Note which artefacts you had to change — that list is itself a finding.

What "good" looks like: actuals drawn from records rather than memory, a variance with a cause and a consequence rather than an adjective, a diagnosis that names a system cause rather than personal effort, a decision recorded with a reason, and a list of artefacts updated within the same session.

Self-assessment

  1. Why is effort recorded during the work more valuable than an accurate reconstruction at the end?
  2. A project is Green on every measure but the milestone date has moved. What has gone wrong, and what do you change?
  3. Give one example each of "working on the wrong thing" and "working slowly", and say how the responses differ.
  4. Why does assessing a change against an already-slipped plan make changes look cheap?

  5. Which two artefacts in your own capstone are most likely to contradict each other, and what would you do about it now?

  6. Apply it — your capstone monitoring cycle. At the end of week 5 of 8 you have finished two of the five work packages, one milestone is nine days late, and you have just spent three days rewriting the database schema because a data model you designed in week 2 turned out to be wrong. Everything else is “fine” in your notes.

    Hint: A strong answer diagnoses the cause before choosing the response, and names what has to be written down now.

Show answers
  1. Because it captures the reason for the variance while the reason is still known, and it is contemporaneous evidence rather than recollection. A reconstruction cannot distinguish "the estimate was wrong" from "I do not remember what happened", and the cause is what the variance analysis is for.
  2. The measures have stopped measuring anything that matters, or the thresholds were set so loosely that a date change does not breach them. Either way the monitoring is not doing its job. The fix is to include a measure that the date directly affects — milestone slip in days — with a threshold that makes a moved date visible, and to re-baseline so the measures have meaning again.
  3. Working on the wrong thing: effort is being spent off the critical path, or on scope that grew quietly; the response is to re-read the scope statement and cut back to the launch capability. Working slowly: the activity is on the critical path and is genuinely taking longer than estimated; the response is an honest re-estimate plus a deliberate trade-off — reduce scope, extend the date, or accept a lower quality bar in a named respect — rather than applying more hours.
  4. Because the comparison baseline has already absorbed the previous slip, so the change appears to consume only its own cost while it is in fact adding to an already-negative position. The untouched baseline is what makes the true cumulative impact visible, which is the only version a decision-maker can act on.
  5. Typical pairs are the scope statement against the WBS (deferred items reappearing as work) and the schedule against the estimate or the budget (two different effort figures). The remedy is to choose one owner document for each fact — the finish date, the effort total, the in-scope list — and have the others reference it rather than repeat it.
  6. Diagnose first. Two of five packages at 5 of 8 weeks is roughly on plan by count; the nine-day milestone slip plus three days of rework caused by your own earlier design is the real signal, and its cause is insufficient design before building, not slowness — which is a corrective-action case, not a replan. Concretely: record the actuals you have been leaving out (effort per work package, planned against actual dates, and this change), write one status report with the variance and the forecast, and decide the response — either freeze the remaining data model in a short design pass now, or cut a work package to absorb the nine days. Then update the affected artefacts so they stay consistent: the schedule, the risk register (a wrong data model is now a documented risk with a response), and the decision log. A capstone with silently inconsistent artefacts loses more marks than one that is honestly late.

Summary

  • Record actuals as you go: effort per work package, planned against actual dates, and one line per change. It takes minutes and it is the evidence most of the assessment rests on.
  • Run a monitoring cycle — measure against pre-agreed thresholds, write the report, make one decision, update the affected artefacts.
  • Diagnose before responding: wrong thing, slow work, and inaccurate reporting have different fixes, and the third must be fixed first because it removes the ability to act.
  • Judge every report with the stranger test: would someone else conclude the same thing from what you wrote?
  • Handle the change scenario against the untouched baseline, look for the underlying need, and reconcile the decision into the artefacts.
  • Keep artefacts coherent with one source of truth per fact, updates in the same session as the decision, and the consistency checks re-run at each milestone.

Further learning