Where we are: Northwind, week 2
Last week you turned Elena V.'s two-paragraph mandate into a charter: one trusted sales number as P1, the Christmas peak as P2, five written non-goals, and a GAPS list that sent four questions to Elena and the rest to Sofia K., Priya N. and Dan R. Some answers are in. Nine source systems confirmed. Around 812,000 rows a night at steady state. A data-quality threshold of 99% that came out of the finance conversation. And one thing everybody now knows and nobody has written down: the legacy warehouse gets switched off after the modelled layer is signed, not before. Tonight that becomes a shape.
Milestone, gate, task: three different things 6 min live
Most plans that fall apart do so because these three got mixed together. A milestone is a state the programme has reached. A gate is the testable criterion that says it truly has. A task is how somebody got it there. Milestones go to the sponsor, gates go in the plan, tasks stay with the team - and if you present tasks to a steerco you will spend the hour discussing engineering rather than decisions.
LiveThe difference, in one Northwind example3 min▶
Take M3, raw ingest. Same piece of the programme, three different sentences:
- Task: "Marcus L. writes the extract job for the POS feed." That is work. It has an owner and an estimate and it belongs in a backlog, not in front of a COO.
- Milestone: "Raw ingest signed off." That is a state. The programme is either in it or it is not, and you cannot be 70% in it.
- Gate: "All 9 source systems landing nightly for 5 consecutive nights at 99% data-quality pass, signed off by Sofia K." That is the test that settles the argument about whether the state was reached.
Notice what the gate does to the conversation. Without it, "are we done with ingest?" is a matter of temperament: the optimist says yes because data is arriving, the pessimist says no because two feeds wobbled on Tuesday. With it, you count nights. Nobody has to be brave.
The milestone that was 90% done for eleven weeks. A migration programme reported "data load 90% complete" every week for nearly three months. It was true every time: 90% of tables had loaded at least once. There was no gate, so nobody could say what the remaining 10% was, and the number never moved because it was measuring effort, not state. The week they replaced it with "all tables loaded and reconciled to source for 3 consecutive runs, signed by the data lead", the report went from 90% to 41%, and everyone finally knew where they were. Honest and lower beats fluent and flat.
Self-studyWhy task lists dress up as plans2 min read▶
A task list feels like a plan because it is long, specific and full of verbs. It is also the easiest artifact for a model to generate, which means you will be offered one constantly. Three tells:
- Every line starts with a verb. "Build", "configure", "extract", "validate". Milestones are nouns and states: "raw ingest signed off", "landing zone stood up".
- Nothing can fail. A task list has no criteria, so it has no failure mode - it just has items that are not done yet. A gate can be failed, which is exactly why it is useful.
- It is proportional to the technology, not the risk. Forty lines about pipelines, none about the fact that R-03, the data-engineer hiring gap, is a hard gate before M4.
Keep both. The milestone ladder is the sponsor's view and the contract. The work breakdown underneath it is the team's view and it changes weekly. What you never do is present the second and call it the first.
Gate criteria you could actually test 6 min live
Compare two sentences. "Ingest working well." Versus: "All 9 source systems landing nightly for 5 consecutive nights at 99% DQ pass, signed off by Sofia K." The first cannot be failed, so it cannot be passed either - it can only be argued about, usually in the meeting where you most need it to be settled.
LiveThe four parts of a gate criterion3 min▶
Every gate criterion worth writing names four things. Miss one and you have an opinion with a date attached.
- A measure. What is counted. Source systems landing, DQ pass rate, reports in production. Not "quality" or "stability" - the specific thing you can point at.
- A threshold. The number that separates pass from fail. 9 of 9. 99%. Zero P1 defects. If you cannot put a number here, ask harder - somebody has one in their head.
- A duration. How long it has to hold. This is the part everyone forgets, and it is what stops a single lucky night counting as a milestone. Five consecutive nights is a very different claim from "it worked last night".
- A person. One named human who signs that it passed. Sofia K. for the technical gates, Dan R. for the reporting gate, Elena V. for the ones that change the business case. Rail three, applied to plans.
The duration nobody wrote down. A team declared ingest complete on the strength of one clean overnight run and moved the engineers onto modelling. Four nights later a vendor feed arrived late and empty, and nobody noticed for a week because the people who would have noticed had moved on. Adding two words to the criterion - "5 consecutive" - would have kept two engineers on ingest for four more days and saved a fortnight of rework. Duration is the cheapest word in a gate and the one most often missing.
Here is the Northwind ladder with the criterion written out. This is the table you take to Elena. Note what is not in it: dates. Those come in demo 1, from people.
| Milestone | Gate criterion - measure, threshold, duration, person |
|---|---|
| M1 · Discovery and source inventory | All 9 source systems documented with owner, refresh frequency, row volume and access route; inventory signed by Sofia K. |
| M2 · Landing zone and platform stood up | Platform provisioned, access granted to the named team, one test feed landing end to end for 3 consecutive nights; signed by Sofia K. |
| M3 · Raw ingest signed off | All 9 sources landing nightly for 5 consecutive nights at 99% DQ pass, around 812k rows at steady state; signed by Sofia K. Gate date 10 Aug |
| M4 · Modelled warehouse signed off | Core sales model reconciles to source within agreed tolerance for 3 consecutive runs; legacy warehouse decommissioning approved; signed by Sofia K. and Elena V. |
| M5 · Governed BI in production | Agreed report set live in production with a named owner per report, one certified daily sales number, zero P1 defects for 10 working days; signed by Dan R. |
| M6 · First AI or ML use case live | One use case in production with a measured baseline and a stated business metric, monitoring and a rollback path in place; signed by Elena V. |
Self-studyGate criteria that cannot be tested2 min read▶
Learn to spot these on sight. Each one below has appeared, word for word, in a real plan.
| Untestable | What is missing |
|---|---|
| "Ingest working well" | All four. Measure, threshold, duration, person |
| "Data quality is acceptable" | Threshold and person. Acceptable to whom, at what number |
| "Warehouse is stable" | Measure and duration. Stable over what, for how long |
| "Business is happy with the reports" | Measure and person. "The business" is not a human who can sign |
| "Testing complete" | Threshold. Complete with how many open defects, at what severity |
Decompose with AI, take the dates from the team 5 min live
This is the session where rail two stops being a slogan. AI drafts structure, never commitments. The model has read thousands of data programmes and is genuinely good at telling you what work exists. It has read exactly zero about Marcus L., who is also on the loyalty migration until August, or about your change-approval board that meets fortnightly. Structure is transferable. Duration is not.
LiveWhat it is good at: the work everyone forgets3 min▶
The strongest use of a model at this stage is not producing the obvious branches of the WBS - you already know you need ingest and modelling. It is the pass where you ask what a plan like this usually leaves out. Four items surface almost every time, and every one of them has sunk a data programme somewhere:
- Migration of historical data. Two years of history has to land somewhere, be reconciled, and be explained when the numbers differ from the old warehouse. It is never in the first draft of anyone's plan. At Northwind it is also bounded by a non-goal: two years, not ten.
- Cutover rehearsal. Not the cutover. The rehearsal of the cutover, with the rollback, timed, on a weekend nobody wants to give up. Teams that skip it discover their rollback plan is a paragraph rather than a procedure.
- Decommissioning the legacy warehouse. Northwind switches it off after M4. That means finding every report, script and spreadsheet pointed at it, which is always more than the inventory says. Turning something off is a project, not a cleanup task.
- Training the BI users. M5 is not done when reports exist. It is done when Dan R.'s users trust them enough to stop maintaining the shadow spreadsheet, and that takes sessions, office hours and a certified-number story.
The shadow spreadsheet that outlived the programme. A retailer shipped a beautiful governed warehouse and a clean set of reports, then discovered eight months later that regional managers were still running the Monday meeting off a spreadsheet one of them maintained by hand. Nobody had budgeted a single hour for training or for the conversation about why the new number differed from the old one. The platform was done. The change was not, and the difference cost more than the platform.
LiveWhat it cannot know: how long anything takes here2 min▶
Ask for durations and you will get them, confidently, evenly spaced, and wrong in a very specific way: they describe a well-staffed team with no other commitments, no procurement, and no holidays. At Northwind the things that actually set the dates are these, and none of them are in any training corpus:
- R-03, the data-engineer hiring gap. A hard gate before M4. One engineer cannot model nine sources and keep ingest alive. The date for M4 is not an engineering estimate, it is a recruitment date.
- R-07, the vendor SLA. Veridian supplies the POS extract. Priya N. knows what their turnaround actually looks like versus what the contract says. That gap is weeks, and it lands squarely on M3.
- R-11, data quality below the 99% gate. Nobody can tell you how long remediation takes until the first real profile run. Until then the M3 date carries a range, and you should say so.
- Everything unglamorous. Change board cadence, security review queues, the fortnight in December when nothing ships in a retailer.
Build the Northwind milestone table ★ 14 min · everyone builds
Charter in the workspace, non-goals included. You are drafting the ladder, the gate criteria and the work breakdown - and deliberately refusing dates until people have been asked. The prompt does most of the refusing for you.
Run the prompt below. You should get six milestones, a criterion with all four parts on each, owners as TBC, and no dates anywhere.
Audit every criterion against the four-part rule. In practice one or two will be missing a duration - that is the part models drop most often. Add it yourself.
Read the "commonly forgotten" section and argue with it. Some items will not apply to Northwind. Two or three will, and one will be genuinely uncomfortable.
Now go and get the dates, in this order: Sofia K. for the architecture sequence, Marcus L. for ingest and modelling effort, Priya N. for the Veridian lead time, Dan R. for report build and user training.
Put their numbers in yourself, then hand the filled table back to the workspace as an updated document. From here on, every draft in this programme reads dates that came from people.
Where a date depends on a risk - M4 on the R-03 hire - record it as a range with the trigger, not a single day. Session b4 turns those into the critical path.
The capacity conversation: getting a date you can stand behind ★ 8 min · pair up and try it
You have a dateless table. Now you need a number from Marcus L. that will survive being read out at a steerco. "How long will ingest take?" gets you a number he invented in four seconds to end the conversation. These four questions get you one he has actually thought about.
"What is in your way?" Ask this first, always. It surfaces the blockers before he has committed to anything, which means he can name them without it sounding like an excuse. Access, environments, the Veridian extract, the thing he is waiting on from Sofia.
"What else are you on?" The single most useful question and the one PMs skip because they are afraid of the answer. Half of Marcus until August is a completely different plan from all of Marcus, and the difference is R-03 in the risk register.
"What would make this two weeks instead of four?" This is where the trade is. Sometimes it is a decision only you can make, sometimes it is a person, sometimes it is scope you can cut against a non-goal. You are not haggling, you are buying the difference.
"How confident are you in that number?" Ask for high, medium or low, and write it down next to the date. A low-confidence four weeks and a high-confidence four weeks are different plans and you report them differently.
Repeat the number back with its assumptions attached: "four weeks, assuming the Veridian extract lands by the 5th and you are off loyalty from August, medium confidence." If he corrects any part of that, you just avoided an escalation.
The gap that was a risk, not an error. A delivery lead had an AI-drafted plan showing three weeks for a warehouse model build. She asked her engineer blind and got seven, medium confidence. Her instinct was that he was padding. She asked the two-weeks-instead-of-four question and found the reason: the source system had four undocumented feed variants and someone would have to reverse-engineer them. The gap was not padding and it was not a bad estimate. It was an unlogged risk that the plan had silently assumed away, and it went straight into the register.
Try it yourself - this week ◐ 30-45 min total
- Take the milestone list from a live programme of yours and rewrite every milestone as a state, phrased as a noun. Anything that will not convert was a task pretending.
- Run the four-part rule over your existing gate criteria: measure, threshold, duration, person. Count how many are missing a duration. It is usually most of them.
- Ask a model what your kind of programme typically forgets. Keep the two or three that make you wince and add them to the plan.
- Run the four-question capacity conversation with one engineer this week. Ask blind. Write down the confidence level next to the date.
- Add the dated milestone table to your workspace context pack. Session b4 builds the dependency map on top of it, and b6 reports against these exact gates.
Official sources covered
Taught from the delivery canon plus the by-hand prequel course, with PMI's AI standard behind the human-oversight rule. Certification and the full normative text of the standards stay with PMI. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Which of these is a milestone rather than a task or a gate?
B is a state the programme reaches, phrased as a noun. A is a task - it starts with a verb and belongs in the backlog. C is the gate: the testable criterion that proves B was actually reached.
2 · A gate reads "all 9 sources landing nightly at 99% DQ, signed by Sofia K." What is missing?
Duration is the fourth part and the one dropped most often. "5 consecutive nights" is what stops a single clean run being declared a milestone and the engineers being moved on too early.
3 · Your AI-drafted breakdown suggests three weeks for the model build. What do you do before talking to Marcus L.?
Anchoring. Show the number first and you get the model's estimate agreed by a polite colleague, not his. Ask blind, capture confidence, then treat any large gap as an unlogged risk worth investigating.