Chapter 7 — Planning the Build: Estimates, Schedule, and Risk

“Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Douglas Hofstadter, Gödel, Escher, Bach (1979)

“…yet you do not know what tomorrow will bring. What is your life? For you are a mist that appears for a little time and then vanishes. Instead you ought to say, ‘If the Lord wills, we will live and do this or that.’” — James 4:14–15 (ESV)

Why This Matters

Six weeks ago you had an idea. You have since turned it into a scoping decision, a requirements specification, a set of non-functional targets, a stack you can defend in an architecture decision record, and a technical specification a stranger could build from. All of that is what. This week is the first time the course asks when, and with what, and what if it doesn’t work. The hat is project manager. The phase is planning — the last station before construction. Next week your specification gets reviewed and frozen; the week after that you start writing product code. Everything between here and Week 16 runs on the plan you build in the next fifteen hours.

Here is the number that should make you sit up. You have spent roughly 105 hours of your 240-hour budget getting to this sentence. That leaves about 135. Subtract the hours that Weeks 8 through 16 spend on chapters, quizzes, reps, the design review, and the presentation, and what is actually left for your project — building it, testing it, documenting it, deploying it — is around 87 hours. Not 135. Eighty-seven. Most students discover that number in Week 13, when it has already become a subtraction problem with no solution. You are going to discover it today, while it is still an addition problem.

The AI thread runs hard through this week, and it cuts both ways. An assistant is genuinely excellent at breadth: ask it what tasks a file-upload feature needs and it will name eleven, two of which you had not thought of. Ask it what could go wrong with a third-party API dependency and it will produce a risk list worth harvesting. It is genuinely unreliable at duration: it does not know how fast you are, how strange your environment is, or how much of your last four hours went to a broken lock file. It will hand you a smooth, confident, uniformly optimistic schedule where every task takes four hours. And on the workload side, you must budget the hours AI will actually save you against the hours it will cost you in reading, reviewing, and debugging code you did not write. That is a real line item. Put it in the plan.

So the apologetic question this week is one that sits oddly on a project-management chapter and belongs there completely: why does a plan need humility? James has hard words for people who say “we will go and spend a year and make a profit” — and yet Jesus tells you to sit down and count the cost before you build the tower, and Proverbs says the plans of the diligent lead surely to abundance. Scripture commands planning and rebukes a certain kind of planner. Working out the difference is not a devotional aside. It is the difference between a plan that survives contact with Week 12 and one that shatters.

7.1 — The Project-Manager Hat, Worn by the Person Who Has to Do the Work

On a real team, estimation is a negotiation between at least two people who want different things. The developer wants the estimate to be generous. The project manager wants it to be tight. The number that comes out is worse than either of them alone would have produced and better than either deserves, because it was contested. You have no one to contest with. You are both people. And you will estimate like a developer who wants the plan to look achievable, because a plan that says you have to cut your favorite feature feels like failure. This is the central hazard of the week, and it has a name: the planning fallacy — the robust tendency, named by Kahneman and Tversky, to predict that our own tasks will go better and faster than similar tasks actually have. Experienced engineers do it too, and it survives being told about it, which is why “just be realistic” is useless advice.

What replaces the missing second person is not willpower — it is process. Every discipline in this chapter is a written substitute for a question a project manager would have asked you out loud. How long, really? becomes a three-point estimate written before the work. What else is in that? becomes the 100 percent rule. You said that last time becomes a calibration factor computed from your own hours log. What if the API is down? becomes a risk register with triggers and owners. And we’re cutting something becomes a declared buffer and a written scope decision.

Coach’s Note — You wear this hat differently from the others. The analyst hat came off after Week 4. The project-manager hat goes back on every Monday for the rest of the course — twenty minutes to update the burn-down, review the top five risks, and re-plan the week. Twenty minutes. Put it on the calendar now, before you have a reason to skip it.

The honest capacity table

Here is where the remaining 135 hours go. This is a representative allocation — yours will differ, and you will build your own version this week — but the shape is not negotiable.

Eighty-seven hours. That is your budget, and every hour of it has to cover features and tests and documentation and deployment. Write the number at the top of your plan; everything else this week gets tested against it.

7.2 — From Specification to Work Breakdown Structure

A work breakdown structure (WBS) is a decomposition of the work into deliverables — not into phases, not into technologies, not into a vibe. It has one governing rule, standard in project-management practice, and it is worth memorizing:

The 100 percent rule. The children of any node account for all of the parent’s work — no more, no less.

“No more” kills gold-plating: if it is not in the specification, it does not belong in the WBS. “No less” kills the silent killer: the work you did not write down does not get hours, so it gets done at midnight in Week 15 out of the documentation budget. Two levels are enough for a solo capstone. Work packages (a deliverable-sized chunk: 4–20 hours) contain tasks (1–6 hours). Under an hour is noise. Over six hours means you do not understand it yet — split it, or write a spike.

The bad WBS

You will be tempted to write this one. It takes four minutes and it feels like planning.

1. Backend
2. Frontend
3. Testing
4. Deployment

Four things are wrong, and each costs a specific amount. “Backend” is not a deliverable, it’s a neighborhood — you cannot estimate it, so you will guess it, and the guess will be a round number you chose because it sounded reasonable. Nothing traces to a requirement, so when you cut scope in Week 12 you will not know which requirements you just broke and the traceability matrix from Week 4 becomes a lie. “Testing” is a phase at the end, which means it is the thing compressed when Weeks 10–12 run long; every project that shipped with no tests started from a WBS that looked like this. And the invisible work is invisible — CI, seed data, error handling, the accessibility pass, secrets, the README — so none of it is budgeted, so all of it is a surprise.

The good WBS

Same project, decomposed properly, using the layout in code/wbs-template.md. This is one work package out of nine for the running example, PantryPilot — your packages will be different, but the shape is the shape.

Five differences, all load-bearing: a stable identifier, a requirement trace, a three-point estimate, a done-when somebody else could check, and an explicit dependency. That last column is what makes a schedule possible instead of a wish.

The work packages nobody writes down

Before you estimate anything, sit with this list and ask which of these exist in your WBS. For most students the honest answer is “about two.”

Coach’s Note — The single highest-value hour of this entire week is the hour you spend adding work packages you had forgotten. Not estimating. Not scheduling. Remembering. An estimate on the wrong task list is precision on a lie.

7.3 — Estimating What You Have Never Built

You are being asked to predict the duration of work you have never done, in a stack you partly do not know, at a skill level that is changing weekly. That is genuinely hard, and the correct response is not to guess harder — it is to stop producing single numbers. For every task, write three numbers: O — optimistic (everything goes right; the library behaves; no yak-shaving), M — most likely (the realistic case, if you had to bet), and P — pessimistic (it goes badly but not catastrophically: the docs are wrong, you debug for an hour, you rewrite it once). Then compute the PERT expected value and its spread:

E  = (O + 4M + P) / 6
sd = (P - O) / 6

The weighting pulls the answer toward the likely case while letting the tail pull it out: a task you estimate at 2 / 3 / 8 has E = 3.7, noticeably more than the 3 you would have written on your own. But the number that teaches you the most is the spread, not the expectation:

A spike is a fixed-length experiment — “two hours to answer can this library do X, deliverable is a paragraph and a throwaway file.” You do not estimate a spike’s outcome; you timebox it. Spikes go in the plan as tasks with hard caps, and they go early, because their whole purpose is to convert an unknown into an estimate while there is still time to react.

Estimate from the outside, not from the inside

There are two ways to predict a duration. The inside view imagines the steps: I’ll write the endpoint, then the validation, then the test — call it three hours. The outside view asks what happened last time you did something like this. The planning-fallacy research is essentially a demonstration that the inside view runs systematically optimistic, and Flyvbjerg’s reference class forecasting is the corrective: find a class of comparable past work, look at how it actually went, and start from there. You have a reference class. It is called docs/hours-log.csv, and you have been filling it since Week 1 — §7.8 puts it to work.

Until that log is thick enough to trust, use a novelty multiplier — from your novelty load in Chapter 5 — as a rough correction. Heuristics for calibration, not laws:

Bad estimate, good estimate

BAD:   Auth — 1 week

GOOD:  T-1.2  Registration with hashed password storage    FR-001, NFR-004
              O 3  M 5  P 10   ->  E 5.5 h   (spread 3.3x, acceptable)
              Done when: a new account persists with a hashed, salted password;
                         duplicate email returns 409; NFR-004 target met.
              Depends on: T-1.1 (user schema)
              Note: if the Week-5 ADR's framework ships session auth, re-estimate.

The bad one is not a task (it is a neighborhood), not a number (a “week” of what — 15 hours? 40?), and it hides at least four separable pieces with no requirement, no done-when, and no uncertainty. And that last line of the good one matters: an estimate is a claim about the future, and claims get revised when evidence arrives. Which is exactly what happens to this one in §7.8.

7.4 — The Schedule: Milestones, Dependencies, and the Weeks You Will Lose

A WBS tells you how much. A schedule tells you when, and it is built from three inputs: your per-week capacity (§7.1), your dependencies (the last column of the WBS), and the dates you do not control. Three rules govern a solo schedule, and they are not the rules a team uses.

1. Sequence by risk, not by comfort. On a team you parallelize. Alone, everything is serialized by you, so the critical path is nearly the entire plan and the interesting question becomes what order. The answer: the work most likely to kill the project goes first. That is the entire reason Chapter 9 makes you build a walking skeleton before a single complete feature — it forces the deploy, the database, and the request path to be proven in Week 9 rather than discovered in Week 14. Anything that could end the project must be attempted before Week 12, while there is still time to change course.

2. Integration is not a phase, it is a risk. Every seam between two components is a place your estimate is wrong. Schedule the first real integration of every third-party dependency early, and never let two hard integrations land in the same week.

3. Plan the weeks you will lose, because you will lose them. You will get sick. Another course will have a project due. There will be a holiday, a family thing, a week where the deploy target changes its API. A schedule that assumes nine perfect weeks is not optimistic; it is wrong, in a way you can correct today for free. The professional correction is to plan at less than full capacity — if you have 12 project hours, schedule 9 or 10. In this course we do it a better way, with one declared buffer instead of a hidden discount in every week (§7.7), but the arithmetic is the same and the honesty is the point.

Two schedules for the same plan

The one that will fail:

Integration last. Testing after building. Deployment in the final week, on a host you have never used. No dependencies, no gates, no slack. It has exactly one failure mode and it happens every time: Week 12 runs long, and the only things left to compress are the three things the final rubric weighs most heavily — tests, documentation, and a deployment somebody else can reproduce.

The one that will hold:

Risk first. Integration in Week 12, not Week 15. Documentation gets a week, not an evening. Every row has a gate somebody else could check.

Coach’s Note — Notice what is missing from the good schedule: any week where you start something new after Week 14. That is deliberate and it is not negotiable. The last two weeks are for finishing, fixing, and writing. A feature begun in Week 15 is a feature that will be half-done in Week 16, and half-done code in a graded repository is worse than no code at all — it is a reviewer’s first impression of your judgment.

7.5 — Burn-Down, Velocity, and the Honest Mid-Course Correction

A burn-down is one line: estimated hours of work remaining, plotted week by week. It is the single most honest instrument in project management, because it cannot be argued with and it cannot be flattered. Two lines matter. Ideal runs from your plannable total down to zero at the end of Week 16, sloped by each week’s capacity. Projected is your actual remaining work, burned down by what you actually retire.

And one distinction is where students go wrong: velocity is not hours worked. Velocity is the plan you retire. You can work 12 hours and burn down 5, because 4 hours went to a dependency upgrade you did not plan and 3 went to a bug in something you had already marked done. That ratio — plan retired ÷ hours worked — is your focus factor, and for a first-time solo builder it is commonly well under 1. Measure it. Do not assume it.

The burn-down line will sometimes go up. You will decompose a work package in Week 11 and discover four tasks you had not seen. When that happens, raise the line. Do not quietly absorb it, do not pretend it was always there. A burn-down that only ever goes down is a burn-down somebody is managing instead of measuring, and the gap between it and reality is exactly the size of the disaster in Week 15.

The four levers, and only four

When the projected line will not reach zero by Week 16 — and this week, for most of you, it will not — you have exactly four moves:

There is a fifth lever you do not have: you cannot add people. Brooks put the general case memorably in The Mythical Man-Month — adding people to a late software project makes it later — and alone, the lever does not even exist. This is why cutting is not a defeat in a capstone; it is the primary control. Cut in MoSCoW order, from Chapter 3: Coulds first, then Shoulds. A Must does not get cut without a written decision that goes through change control next week (Chapter 8) and updates docs/requirements.md. That is not bureaucracy. That is the difference between descoping and just not doing it.

7.6 — The Risk Register: Likelihood, Impact, Trigger, Owner, Response

A risk is an uncertain future event with a consequence. It is not a problem — a problem is happening now. The moment a risk occurs it stops being a risk and becomes an issue, and it moves to your defect or issue log; keeping that boundary clean is most of what makes a register useful. The full format, the 1–5 scales, and worked rows live in code/risk-register-template.md. The short version is nine columns, and if you skip any of the last three you have written a worry list instead:

Bad risk, good risk

Bad — R-04: The project might not get finished on time. Likelihood: high. Impact: high. Mitigation: work harder.

No cause. No specific event, so nothing can confirm or refute it. No trigger, so it can never be detected — only discovered, in Week 15, as a catastrophe. “Work harder” names no action, no week, and no cost. That row is anxiety with a border around it.

Good — R-01. Because the barcode lookup service is a free third-party API whose rate limit I have not confirmed, calls may begin failing during Week-12 integration testing, and FR-021 could not be demonstrated in the Week-16 demo. · dependency · L 3 · I 4 · E 12 Trigger: two consecutive days above 60% of the documented cap, or any 429 in the logs. Owner: me. Response: mitigate by Week 10 — cache lookups by barcode (T-4.2) and commit a fixture file of 50 known products so the demo never needs the network. Contingency: manual entry (FR-022), already specified and already in the plan.

Notice what the good row does that the bad one cannot: it tells you what to watch, when to act, and what the action costs — T-4.2, already a task, already estimated, already in the WBS. A risk response that is not a task in your plan is not a response.

Coach’s Note — Score impact in hours. The instant you write “impact: high” you have stopped doing project management and started doing feelings. “Impact: 4 — I lose about 15 hours” is a claim you can check, argue with, and act on.

Five categories reliably produce most of a capstone’s real risks: technical/novelty (you’ve never done it), dependency (somebody else’s service, license, or free tier), scope (the feature that keeps growing), schedule/personal (the other three courses, the job, the flu), and data/legal (you cannot get the data, or you cannot ship it). Write two or three in each category, then cull to the eight with the highest exposure. Eight is a register you will actually review. Twenty is a document you will never open again.

7.7 — Buffers Are Not Padding, and How Much You Actually Need

Every engineer pads. You estimate a task at 3 hours, then you write 5, because you have been burned. Multiply that across thirty tasks and your plan contains a large, invisible, undeclared reserve — and that reserve does not protect you. Two named effects eat it:

• Parkinson’s Law — “work expands so as to fill the time available for its completion” (C. Northcote Parkinson, 1955). A task with 5 hours allotted takes 5 hours, even when it needed 3.
• Student syndrome — Goldratt’s observation in Critical Chain (1997) that when people are given extra time they start late, and the safety is consumed at the front, before the work begins.

So the padding is spent before the trouble arrives, and when the trouble arrives there is nothing left. Meanwhile nobody — including you — knows how much reserve the plan actually contains, because it is scattered across thirty tasks in three-quarter-hour increments. The fix is structural:

Take the safety out of every task. Estimate each one honestly. Then declare one visible project buffer at the end, and manage it.

Two properties make this better than padding. It aggregates — thirty tasks will not all run long at once, so one pooled buffer covers the same risk with fewer hours than thirty private cushions. And it is visible — a buffer at 90% in Week 10 and 20% in Week 12 tells you something is systematically wrong long before the deadline does.

How much? For a solo capstone with meaningful novelty, hold back 20–30% of remaining capacity — use 25% unless you have a reason — and put a feeding buffer of a couple of hours immediately before every hard integration point, because that is where estimates fail hardest. The arithmetic for the running example:

Available for the project, Weeks 8-16 .............. 87.0 h
Project buffer at 25% .............................. 21.8 h
Plannable effort ................................... 65.2 h

Sixty-five hours. That, not 87 and certainly not 135, is how much work you are allowed to plan. If your WBS is bigger than that number, your plan does not fit, and the honest thing — the only thing — is to make it smaller today.

Three rules for using it. You may spend it — that is what it is for, and spending buffer is not failure. You must record the draw, one line in docs/plan.md: date, hours, which task overran, why. And you may not silently refill it by cutting scope and pretending the buffer grew; cuts reduce the plan, they do not reset the reserve.

7.8 — Calibrating Against Your Own Hours Log

Now the log pays off. Since Week 1 you have recorded what you actually spent, and that file is the only reference class in the world that is about you. Your calibration factor is the simplest useful statistic in this course:

calibration factor = (hours you actually spent) / (hours you expected to spend)

Compute it over every task you have both estimated and finished — the spikes from Week 5, the diagramming work, the data-model pass. Then apply it to everything still ahead of you.

Also compute your focus factor: of the hours you logged, what fraction went to planned tasks? If you logged 12 and retired 7 hours of plan, your focus factor is 0.58, and it will not magically improve. Bake it in. Two honest caveats. A calibration factor built on five finished tasks is a thin sample — treat it as a nudge, not a law, and recompute every Monday as the sample grows. And your factor is domain-specific: you might be well calibrated on code and badly calibrated on writing, or the reverse. If your log has a task-type column, compute it separately. If it does not, add one this week.

Running it

The chapter ships code/plan-check.py, which does all of this — PERT, roll-up, calibration, capacity, buffer, burn-down, and the verdict. Run it against code/wbs-sample.csv first, read the output, then point it at your own file.

$ python3 plan-check.py wbs-sample.csv
CALIBRATION
  completed tasks         5
  expected (PERT)         11.0 h
  actually logged         12.5 h
  your factor             1.14x   (thin sample - trust it loosely)
REMAINING WORK
  ... (nine work packages) ...
  TOTAL                                86.2 h raw    97.9 h calibrated
CAPACITY  (weeks 8-16)
  raw capacity            87.0 h
  project buffer (25%)     21.8 h
  plannable               65.2 h
  VERDICT: OVER BUDGET by 32.7 h - cut, defer, or re-estimate

Thirty-two hours over. That is not a broken example; that is what a first WBS looks like, and if yours comes out under budget on the first pass you have almost certainly forgotten a work package. Now watch the levers work. Cut WP-5 (the AI recipe suggestion — a Could, and the least defensible hour-for-hour), cut T-3.3 (the digest email), defer T-1.4 (household invites; single-member households still satisfy the core), and defer T-4.2 (the lookup cache — but only after moving its risk response into the fixture file instead):

$ python3 plan-check.py wbs-sample.csv --exclude WP-5,T-3.3,T-1.4,T-4.2
  TOTAL                                62.3 h raw    70.8 h calibrated
  VERDICT: OVER BUDGET by 5.6 h - cut, defer, or re-estimate

Closer. The last 5.6 hours come from evidence, not from wishing: the Week-5 ADR chose a framework that ships session authentication, so T-1.2 and T-1.3 get re-estimated from 5.5 h and 3.5 h down to about 2 h each. Edit those rows and re-run:

  TOTAL                                57.3 h raw    65.2 h calibrated
  VERDICT: fits, with 0.1 h to spare

It fits — by six minutes. That sounds terrifying and it is not, because standing behind that plan is 21.8 hours of declared buffer you have not touched. That is the margin. The plannable line is supposed to be tight; the buffer is the thing that saves you. A plan that fits with room to spare and keeps a full buffer usually means you under-scoped.

Coach’s Note — Do not skip the part where you write down what you cut. Six weeks from now you will not remember whether the recipe feature was descoped on purpose or forgotten, and neither will your reviewer. A cut you recorded is engineering judgment. A cut you did not record is an unfinished feature.

7.9 — Planning With an Assistant: Great at Breadth, Unreliable at Duration

Use the assistant this week, and use it precisely. Where it is genuinely strong — breadth. Give it your technical specification and a work-package name and ask: “List every task required to deliver this, including setup, error handling, tests, and documentation. Do not estimate.” You will get twenty items, of which perhaps four are things you had not considered — the migration rollback, the empty-state UI, the rate-limit handling. That is real value, and it is the “work packages nobody writes down” problem from §7.2 attacked head-on. The same move works for risks: “For a project with a single developer, a third-party product API, and a nine-week schedule, name twenty risks. Give each a cause, an event, and a consequence.” Harvest it, then throw away most of it.

Where it fails — duration. It does not know your speed, your machine, your familiarity, or that your last migration took four hours because of a version mismatch. It generates plausible-looking numbers, and plausible-looking numbers are the most dangerous kind. Three tells: suspicious uniformity (every task is 4 hours; real distributions are lumpy), no spread (a single number, because single numbers read as confident), and the invisible tail (it estimates the happy path — debugging, rework, and integration friction are simply absent).

The rule for this week: the assistant may propose tasks; only you may propose durations. Strike every number it produces and write your own O/M/P. That is not stubbornness — the durations are the only part of the estimate carrying information, because they are the only part built on your log.

The workload side: budgeting what AI costs you. You are going to use an assistant to write code from Week 9 onward. Put it in the plan honestly. An AI-assisted task is not “the same task, faster.” It is a different task with a different shape:

generation (fast)  +  reading every line (not fast)  +  verifying it does what the spec says
                   +  debugging the plausible-looking bug it introduced   =  actual hours

The published evidence on how much AI assistants speed up developers is mixed and heavily context-dependent, and it changes faster than any textbook can track. So do not plan against a number from a headline, a vendor, or this book. Measure your own. Add a column to docs/hours-log.csv this week — ai_assisted — with a yes/no per entry. By Week 11 you will have your own multiplier, worth more than every study you could cite.

One line you do not cross: a plan drafted by an assistant that you did not re-estimate is not your plan. You will still be the one standing in front of the room in Week 16 explaining why it slipped. Accountability does not delegate. That is the spine rule, and this week it has teeth, because a plan is a promise about a future you have to live in.

7.10 — Interactive Lab: The WBS & Burn-Down Planner

Below this chapter on the website is The WBS & Burn-Down Planner. Do the lab before you build your own plan — it is the rehearsal, and it is much cheaper to be wrong here. Enter ten to fifteen tasks with optimistic, likely, and pessimistic estimates. The widget computes expected effort per task, aggregates by work package, and lays the total against the weeks you have left at whatever hours-per-week you set. It draws the ideal burn-down against your projected one and marks exactly which week the plan goes over budget. Then start pulling levers: cut a work package, defer a task, re-estimate one — and watch the projected line move. The calibration panel takes the hours you have already logged in Weeks 1–6 and shows what your estimates look like once your own history is applied to them.

Three things to make it teach you something. Enter your real tasks, not toy ones — the lab is only useful if the numbers are yours. Find the crossing week before you cut anything, and write it down; that week is the honest deadline for the decision you are about to make. And try the levers in the wrong order on purpose: cut a Must and see how few hours it recovers relative to the damage, then re-estimate everything down 20% and watch the line become a lie. Feel how easy it is to make a plan look fine.

What it teaches: that a plan is a system with a small number of controls, that the controls have very different costs, and that the moment you can see the crossing week, denial stops being available.

7.11 — Why Does a Plan Need Humility?

“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. What is your life? For you are a mist that appears for a little time and then vanishes. Instead you ought to say, ‘If the Lord wills, we will live and do this or that.’” (James 4:13–15, ESV)

Read carelessly, that passage sounds like an argument against planning, which would be an odd thing to put at the head of a project-management chapter. Read carefully, it is nothing of the kind. James does not object to the town, the year, or the profit. He objects to a grammar: we will go, and spend, and trade, and make. Four declarative futures with no acknowledgment that the speaker does not control any of them.

And the correction he offers is not “stop planning.” It is a change of grammar: “If the Lord wills, we will live and do this or that.” Same plan. Different claim about who guarantees it.

Scripture is emphatically not against planning. Jesus’s own argument for counting the cost is a project-management parable: “For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?” (Luke 14:28, ESV) — the verse that opened this course in Week 1. Proverbs is blunter still: “The plans of the diligent lead surely to abundance, but everyone who is hasty comes only to poverty” (Proverbs 21:5, ESV). Failing to plan is not humility; it is negligence wearing humility’s coat. So the two commands sit together, and the seam between them is exactly where this week’s craft lives: plan diligently, hold the plan loosely, and say out loud which parts you do not control.

Look at what that means at the level of the artifacts you are building today, because the correspondence is uncanny:

• A single-point estimate is James 4:13 grammar. It will take five hours. You do not know that. You cannot know that. It is a confident claim about a future you do not govern.
• A three-point estimate is the corrected grammar. If it goes well, three; realistically five; if the library fights me, ten. Every one of those numbers is a hedged claim, honestly labeled. It is more useful precisely because it is more humble.
• A risk register is “you do not know what tomorrow will bring,” written in columns. It is the formal, disciplined admission that specific things are outside your control — and then, having admitted it, deciding what you will watch for and what you will do. That is not fatalism. It is the opposite of fatalism.
• A declared buffer is honest speech about uncertainty. Hidden padding is a small lie: it tells your reader the task takes five hours when you believe it takes three, and it tells you that you have no reserve when in fact you have twenty. Moving the safety out of the tasks and into a labeled line is a decision to stop deceiving yourself in a spreadsheet.

There is a second kind of humility this week demands, and it is harder than the first. The prideful plan is not the ambitious one. It is the one that cannot be revised in public. The student who reaches Week 11 forty hours behind and will not cut a feature is usually not defending the project — they are defending the version of themselves who announced twelve features in Week 2. Cutting feels like admitting they were wrong. They were wrong. Everyone is wrong at Week 2; that is what Week 2 is for. The humility that makes a plan survive is the willingness to say, in writing, with your name on it: I estimated this badly, here is the evidence, here is the new plan.

Proverbs holds both halves in one line: “The heart of man plans his way, but the LORD establishes his steps” (Proverbs 16:9, ESV). Plan your way — really plan, with numbers and dependencies and a register. And then live as someone whose steps are established by Another, which in practice looks like: build in buffer, watch for triggers, re-baseline without shame, and do not boast about tomorrow, “for you do not know what a day may bring” (Proverbs 27:1, ESV).

One last turn, because it keeps this from being merely private. There is a neighbor in this plan. The estimate you inflate to protect yourself is an estimate someone else builds their own schedule on — a teammate, a client, a maintainer. In your working life, planning will be an act of love or an act of self-protection, and the two produce visibly different documents. The honest plan costs you something now: it says out loud that you are slower than you wish, that the AI recipe feature is not going to happen, that the deployment scares you. That cost is the point. Vocation is ordinary work done truthfully for the sake of someone else, and this week the truthful work is a number you did not want to write down.

You are a mist. Plan like it. Then go build the tower.

7.12 — Common Pitfalls

Pitfall: A work breakdown made of phases or technologies instead of deliverables. Example: 1. Backend 2. Frontend 3. Testing 4. Deployment Fix: Decompose to deliverables, then to tasks of 1–6 hours, each with a requirement identifier and a done-when. If you cannot write the done-when, the task is not a task yet.

Pitfall: Single-point estimates. Example: “Auth — 8 hours.” Fix: Write O / M / P for every task and compute E = (O + 4M + P) / 6. If P / O is over 4, you do not understand the task — split it or spike it. The spread is the information.

Pitfall: Padding hidden in every task, and a schedule built on 100% of capacity. Example: Quietly writing 5 where you believe 3, on thirty tasks — then planning 15 hours a week × 9 weeks = 135 hours of them. Fix: Estimate honestly and declare one buffer of 20–30%. Subtract the course overhead first, then hold the buffer back: 135 → 87 → about 65 plannable. Parkinson’s Law eats invisible padding; it cannot eat a number you are watching.

Pitfall: Risks with no trigger and no owner. Example: “Risk: the API might break. Likelihood: high. Mitigation: be careful.” Fix: Every row gets an observable trigger (a count, a date, a log line), a named owner, and a response that is already a task in the WBS with hours attached. A response that is not in the plan is not a response.

Pitfall: Absorbing discovered work silently so the burn-down keeps looking good. Example: Finding four unplanned tasks in Week 11 and just… doing them, without raising the line. Fix: Raise the line. Discovered scope is information, and a burn-down that only goes down is being managed instead of measured. The gap between the pretty chart and reality is the size of the Week-15 disaster.

Pitfall: Planning against the assistant’s numbers. Example: Pasting the specification into a chat window and shipping the twelve-task, four-hours-each plan it produces. Fix: Take its task list gratefully; delete every duration it wrote. You estimate, using your own calibration factor. And budget the review-and-debug hours that AI-generated code actually costs — measure them with an ai_assisted column in your hours log.

7.13 — Reps

The reps are in the exercises; this week they are not warm-ups around the milestone — they are the milestone, built piece by piece. Preview:

• Rep 1 — inventory the invisible work packages you had forgotten, before you estimate anything.
• Rep 3 — the bad-WBS autopsy: name five defects in a real one, then rewrite it properly.
• Rep 5 — the spread test: find every task where P / O is over 4 and turn each into a spike.
• Rep 6 — compute your calibration factor from docs/hours-log.csv and apply it to everything ahead.
• Rep 10 — write twelve risks, cull to eight, and give every survivor a trigger and an owner.

Do the on-page Check Your Reps quiz when you finish this chapter — it is the ungraded rehearsal for Week 7 Quiz in Canvas, and your weekly early-warning system for whether you are actually on pace.

7.14 — This Week’s Milestone

Milestone 7 — Milestone 7: Work Breakdown, Schedule & Risk Register. You will produce docs/plan.md (work breakdown, three-point estimates, capacity, schedule, burn-down baseline, and the scope decision) and docs/risk-register.md (eight risks with triggers, owners, and responses), plus a calibration pass against your hours log.

It is graded twice, and that is not a technicality: it carries its own milestone points, both documents are graded lines in the Week-16 rubric, and every week from here runs on them. A capstone that arrives at Week 16 without a plan does not arrive at Week 16 at all.

Where your hours went this week

A realistic breakdown of the ~15 hours. If yours looks wildly different, that is a data point about your calibration, not about the table.

7.15 — Coach’s Final Word

Here is the thing nobody tells you about planning: the plan’s value is not that it comes true. It won’t. Every number in your work breakdown is wrong by some amount right now, and you will find out how wrong starting in about two weeks. The plan’s value is that it makes reality arrive early. Without one, you discover in Week 14 that the project is forty hours too big — at which point your options are to ship something broken or to not ship. With one, you discover it today, in Week 7, when the option is simply to build a slightly smaller thing very well. Same information. Ten weeks earlier. That gap is the entire return on this week’s fifteen hours.

So do not build a plan that flatters you. Build the one that tells you the truth soonest. Estimate in three numbers because you do not know the one. Declare your buffer instead of hiding it in thirty places. Give every risk a trigger, so it has to announce itself instead of ambushing you. Cut the feature you love, write down that you cut it, and stop carrying it. And then hold it all loosely. You are a mist, the API will change, and the week you lose to the flu is not in the schedule. That is not a reason to plan less carefully. It is the reason to plan carefully and keep the buffer, because the only plans that survive nine weeks of reality are the ones that admitted, on the day they were written, that they were going to need to change.

Next week the specification gets reviewed and frozen, and this plan gets reviewed with it. Bring the honest version.

See you on Monday.

Up next: the exercises builds the plan rep by rep · Milestone 7 is Milestone 7 · then Chapter 8 — the design review, the baseline, and the midterm checkpoint. Reference: Appendix B for the work-breakdown, schedule, and risk-register templates with worked examples, Appendix C for the grading contract and pace table, Appendix E for the vocabulary. Previous: Chapter 6.