Work Breakdown, Schedule & Risk Register

Apologetic question: "Why does a plan need humility?"

Milestone 7 — Work Breakdown, Schedule & Risk Register

“Instead you ought to say, ‘If the Lord wills, we will live and do this or that.’” — James 4:15 (ESV)

Chapter: Chapter 7 — Planning the Build: Estimates, Schedule, and Risk Week: 7 of 16 — the last week of planning before construction begins Due: End of Week 7, before the Week-8 design review. The review inspects this plan; if it does not exist, the review cannot approve a baseline. Submit: Commit to your capstone repository and post the commit URL to the Canvas dropbox. Where it lands in the final package: docs/plan.md (work breakdown, estimates, capacity, schedule, burn-down baseline, scope decision) and docs/risk-register.md (eight risks with triggers, owners, and responses), plus a calibration column added to docs/hours-log.csv. Neither document earns points under its own name in Week 16. They feed the hours log line — through the estimate-versus-actual analysis that this week’s plan is the thing being checked against — and the retrospective line; a grader opens the plan and the register when either line is contested. The plan is also the document every subsequent milestone reports progress against. AI policy: Open, with one hard limit. An assistant may propose tasks and risks — that is its strongest use in this course. It may not supply durations. Every hour figure in your plan is yours, produced from your own estimates and your own calibration factor. Log the session in docs/ai-usage.md: which tool, which prompt, what you kept, what you threw away.

The Setup

You are the only engineer on this project and you have just been handed the schedule.

That sentence is not hypothetical. It is precisely the position a junior engineer is put in during their first year — not as a punishment, but because somebody has to say how long. Your specification is done. Your stack is chosen and defended. Somewhere between here and Week 16 there are roughly 87 hours of your life available for this project, and a specification that, if you are like most students, describes about double that much work.

Nobody is going to discover this for you. There is no project manager who will look at your plan and say this doesn’t fit. There is only the plan you build this week and the arithmetic it does or does not perform. If the arithmetic happens now, you spend Week 8 in a design review with a defensible scope and a buffer. If it happens in Week 13, you spend the last month choosing which graded deliverable to abandon.

So this week you build the instrument that tells you the truth early: a work breakdown fine enough to estimate, estimates honest enough to be wrong in known ways, a schedule that admits you will lose weeks, a buffer you declare instead of hide, and a risk register that will announce trouble before it arrives instead of after.

Then you make the cut. In writing. With your name on it.

Learning Targets

You will demonstrate that you can:

Decompose a technical specification into a deliverable-oriented work breakdown that obeys the 100 percent rule, with tasks sized 1–6 hours.
Trace every task to a requirement identifier, or justify it as enabling work.
Estimate under genuine uncertainty using three-point estimates, and read the spread as a signal about your own understanding.
Schedule against real capacity — sequencing by risk, honoring dependencies, and planning the weeks you will lose.
Baseline a burn-down and name the week the plan goes over budget.
Run a risk register with likelihood, impact in hours, exposure, observable triggers, owners, and responses that exist as funded tasks.
Calibrate future estimates against your own logged history rather than your optimism.
Decide — cut scope deliberately, record the decision, and defend it.

The weekly status block — paste this into your submission comment

Every milestone submission carries these five lines. It takes two minutes, it is the same five lines every week, and it is the difference between an instructor who can help you in Week 6 and one who finds out in Week 14. Copy it into the Canvas submission comment when you submit — not into a document.

Shipped:     what actually works this week, in one line
Cut:         what I dropped or deferred, and where it went (backlog / change request / gone)
Hours:       planned N / actual N        (from docs/hours-log.csv)
Blocked on:  the one thing in my way, or "nothing"
Ship confidence: green | amber | red — if amber or red, the one thing that would move it

Say red when it is red. A red in Week 6 is a conversation and a scope cut. A red discovered in Week 15 is a grade. Nobody has ever been penalised in this course for an honest amber; the only expensive answer is the green that was not true.

Normal Tier

Required deliverables

docs/plan.md, containing:
- a work breakdown structure of at least six work packages and at least twenty-five tasks, each with an identifier, a requirement trace, a done-when, and a dependency where one exists;
- three-point estimates (O / M / P) with E = (O + 4M + P) / 6 computed for every task;
- a capacity table for Weeks 8–16 showing course overhead, known losses, and hours available to the project;
- a declared project buffer with its percentage and its hours, stated separately from task estimates;
- a schedule assigning work packages to weeks, with a gate per week — the condition that must be true before the next week starts;
- a burn-down baseline: total calibrated remaining effort, the ideal line, the projected line, and the first week the plan exceeds remaining capacity;
- a scope decision table: what you cut, deferred, or re-estimated; the requirement identifiers affected; hours recovered; MoSCoW priority before and after; and one honest sentence of why.
docs/risk-register.md with at least eight risks, each phrased cause → uncertain event → consequence, scored for likelihood and impact (impact in hours), sorted by exposure, and carrying an observable trigger, an owner, and a response. At least two risks must come from different categories than the rest — technical, dependency, scope, schedule/personal, data/legal.
A calibration pass: your calibration factor computed from docs/hours-log.csv, stated in docs/plan.md, and applied to every remaining estimate. Say how many finished tasks it is built on.
An updated docs/requirements.md: every requirement you cut or deferred now reads Won’t, flagged for change control at the Week-8 review.
This week’s hours logged, with the new ai_assisted column in use.

Normal-tier rubric (out of 100)

Criterion	Points
Work breakdown is deliverable-oriented, obeys the 100 percent rule, tasks sized 1–6 hours	16
Every task traces to a requirement identifier, or is justified enabling work	10
Three-point estimates on every task, with expected effort computed and spreads inspected	14
Capacity table and schedule for Weeks 8–16 with dependencies, gates, and planned losses	12
A declared project buffer, sized and justified — not padding hidden inside tasks	8
Burn-down baseline: total remaining effort, ideal line, projected line, crossing week named	8
Risk register: 8+ risks with likelihood, impact in hours, exposure, trigger, owner, response	16
Calibration against your own hours log, with the factor stated and applied	8
The scope decision: the plan fits the capacity, and what you cut is recorded with identifiers	8
Total	100

Two plans for the same project, side by side

This is the part of the milestone students most often get wrong, so here is the contrast in full. Both excerpts describe the same work package on the same project. One of them was submitted in about twenty minutes.

The weak version:

Work package 3: Expiry features
  - Add expiry dates             (1 day)
  - Show what's expiring         (1 day)
  - Send reminder emails         (2 days)
Risks: emails might be hard. Might run out of time.

Six things are wrong, and each of them will cost you in a nameable week. The estimates are in days, which is a unit that does not exist in a plan built on hours per week — is a “day” 3 hours or 10? Nothing traces to a requirement, so cutting the reminder email in Week 12 silently breaks a requirement your traceability matrix still claims is covered. There is no done-when, so “show what’s expiring” is finished whenever you decide you are tired of it. There is no spread, so the fact that you have never sent transactional email from an application is invisible in the plan. The risk is unscored and untriggered — “might be hard” cannot fire, cannot be watched, and cannot be responded to. And “might run out of time” is not a risk; it is the consequence of every other risk, which means the author has written the symptom instead of the cause.

The strong version:

WP-3  Expiry and alerts  ·  FR-007, FR-008, FR-009  ·  owner: me  ·  11.0 h raw

| Task  | Name                          | Reqs   | O | M | P  | E   | Done when                                     | Dep   |
| T-3.1 | Expiry date + days-remaining  | FR-007 | 1 | 2 | 3  | 2.0 | Item stores a date; list shows days remaining | T-2.1 |
| T-3.2 | Expiring-soon view            | FR-008 | 2 | 3 | 5  | 3.2 | 200 seeded items sort by urgency under 1.5 s  | T-3.1 |
| T-3.3 | Daily digest email            | FR-009 | 3 | 5 | 12 | 5.8 | One real message delivered to a real inbox    | T-3.2 |

R-05  Because I have never sent transactional email from an application, T-3.3 may
      run far past its 5.8 h estimate and displace WP-6 verification work in Week 11.
      technical/novelty · L 4 · I 3 · E 12
      Trigger: T-3.3 passes 6 logged hours without one delivered message.
      Owner: me.  Response: mitigate — 2 h spike in Week 9 to send one message from
      the chosen provider; if the spike fails, cut T-3.3 and mark FR-009 as Won't.
      Contingency: expiring-soon view (FR-008) already satisfies the core need.

Notice the connection the weak version cannot make. T-3.3 has a spread of 4× — which is the number that produced R-05, which produced a spike in Week 9, which produced a trigger, which produced a decision rule the author will not have to invent while panicking in Week 11. The estimate, the risk, and the schedule are one system. That is what you are building.

Medium Tier (+up to 25% extra credit)

Stronger project management. Pick what genuinely fits your project — a technique bolted on to earn points reads exactly like a technique bolted on to earn points.

A dependency graph and critical path. Draw the finish-to-start dependencies across your work packages and identify the longest chain. Then say what it means for a solo builder, where nothing runs in parallel: which tasks, if they slip, slip everything.
Feeding buffers before integration points. Rather than one buffer at the end, place a named two- to four-hour feeding buffer immediately before each hard integration, and justify each one against a specific risk row.
A P50 / P80 range for the whole plan. Sum the task variances (sd = (P − O) / 6, variance = sd²), take the square root of the total, and report the plan at both P50 and roughly P80. Then state the caveat honestly: the roll-up assumes tasks are independent, and they are not — a single wrong architectural assumption correlates half your estimates at once. Treat P80 as a floor on your uncertainty, not a ceiling.
Quantified risk reserve. For your top five risks, compute probability × impact-in-hours and add the total as an explicit contingency reserve, separate from the schedule buffer. Show the arithmetic.
A plan-on-a-page. One printed page: work packages, weekly capacity, burn-down, top five risks. If it does not fit on one page, you do not yet know what matters.

Hard Tier (+up to 25% additional extra credit)

Required: a memo no tool can write for you.

Write a two- to three-page Scope Defense Memo, addressed to your instructor as though they were the client who commissioned this system. It must do four things an assistant cannot do on your behalf, because each of them requires owning a decision:

Defend the cut. Name what you removed, with requirement identifiers, and argue why this scope still delivers the value the project was justified on in Week 2. Anticipate the client’s objection to the specific thing you cut, and answer it.
Argue the counterfactual. Take the one feature you most wanted to keep. Make the strongest honest case for keeping it — the hours it would cost, what it would displace, and what would have to be true for that trade to be right. Then say why you decided against it anyway. A memo that only argues one side is advocacy, not judgment.
Name your own weakest estimate — the task you are least confident in — and state the evidence that would change it, the spike that would produce that evidence, and the week by which you must run it. Commit to a trigger date: the date after which you will cut rather than continue.
Own the AI accounting. State exactly where you used an assistant in producing this plan, what you kept, what you discarded and why, and how you will know by Week 11 whether your AI-assisted hour estimates were right. Include the honest sentence: here is the part of this plan I am least sure of, and here is how you will find out before I do.

Graded on judgment, honesty, and self-awareness. A model can generate a plausible scope memo; it cannot decide what your project is for, and it cannot be accountable for the decision in Week 16.

Submission

Commit to your capstone repository, then post the commit URL to the Canvas dropbox.

your-capstone/
├── README.md
├── docs/
│   ├── requirements.md          # updated: cut requirements now Won't
│   ├── architecture.md
│   ├── plan.md                  # NEW — WBS, estimates, capacity, schedule,
│   │                            #       burn-down baseline, scope decision
│   ├── risk-register.md         # NEW — 8+ risks, triggers, owners, responses
│   ├── hours-log.csv            # updated: ai_assisted column, Week 7 hours
│   ├── ai-usage.md              # updated: this week's sessions
│   ├── adr/
│   │   └── 0001-choose-the-stack.md
│   └── scope-defense-memo.pdf   # Hard tier only
└── ...

Commit message: plan: baseline WBS, schedule, risk register, and scope decision.

Blank templates and fully worked examples of all three artifacts — work breakdown, schedule and burn-down, and risk register — are in Appendix B, each with the bad version annotated next to the good one. How this milestone’s artifacts reach the Week-16 rubric — which lines they feed, and why the milestones are graded both on their own and again inside the final — is in Appendix C, along with the week-by-week pace table that tells you whether you are on track.

Hints

Remember before you estimate. The highest-value hour this week is spent adding work packages you had forgotten, not refining ones you already have. Precision on an incomplete task list is precision on a lie.
Estimate the task you understand least, first. Your reaction to it tells you whether it is a task or a spike.
Do the first five expected-value calculations by hand. Once the weighting stops feeling like magic, let code/plan-check.py do the rest.
Model the cut before you make it. --exclude WP-5,T-3.3 lets you see what a candidate cut recovers before you commit to losing the feature.
Score risk impact in hours. “Impact: high” is a feeling. “Impact: 4 — about 15 hours” is a claim you can act on.
A risk response that is not a funded task is not a response. Every mitigation you write should appear in the WBS with an estimate. Adding them will raise your total. That is the correct outcome.
If you come in under budget on the first pass, be suspicious. Re-read the invisible-work table in §7.2 of the chapter before you celebrate.
Write the scope decision the same day you make it. Six weeks from now you will not remember whether a feature was descoped deliberately or simply forgotten — and neither will your reviewer.

What Mastery Looks Like

A master’s plan is one somebody else could take over.

The work breakdown reads like a list of things that will exist, not a list of areas to work in. Every task has a done-when a stranger could check, which means the plan doubles as a checklist. The estimates carry spreads, and the tasks with wide spreads have already been converted into timeboxed spikes scheduled early — because the author understood that an unknown is cheapest in Week 9 and most expensive in Week 14.

The schedule sequences risk first. The third-party integration is in Week 12, not Week 15. Documentation has a week, not an evening. Every row has a gate.

The buffer is a number in a box, not a fog in thirty estimates. The register has eight risks, each with a trigger you could actually observe, and every response already appears in the plan with hours attached.

And the scope decision is signed. It names what was cut, with requirement identifiers, and says why in one sentence that does not flinch. That is the artifact that separates a student who built a plan from a student who made a decision — and making decisions under uncertainty, in writing, is the whole job you are about to enter.

Coach’s Note — You will be tempted, somewhere around Rep 9, to lower the buffer from 25% to 10% because it makes the gap disappear. Notice that temptation when it comes. It is the exact move that turns an honest plan into a comfortable one, and it costs nothing today and everything in Week 13. If you genuinely believe a smaller buffer is right, argue for it in one sentence in the document — that is legitimate. Sliding it down quietly to make the arithmetic work is not.

When You’re Done

A theological footnote. James does not forbid the plan; he corrects the grammar. “Come now, you who say, ‘Today or tomorrow we will go into such and such a town and spend a year there and trade and make a profit’— yet you do not know what tomorrow will bring” (James 4:13–14, ESV). The rebuke lands on the confident indicative, not on the itinerary. And the correction he offers is not silence but a better sentence: “If the Lord wills, we will live and do this or that” (James 4:15, ESV). That is what you are building this week. A three-point estimate is a hedged claim about a future you do not govern. A risk register is a written admission that specific things are outside your control, followed by the diligence of deciding what you will watch for anyway. A declared buffer is honest speech where padding would have been a small, comfortable lie. Christ’s own instruction to count the cost before building the tower (Luke 14:28) and Solomon’s “the plans of the diligent lead surely to abundance” (Proverbs 21:5, ESV) leave no room for treating humility as an excuse not to plan. Plan diligently. Then hold it loosely, and say out loud which parts you do not control — because the engineer who can do both is the one people trust with the schedule.