Where we are
Session a1 drew the line: AI drafts artifacts and collates noise, you keep judgment and the signature. Session a2 built the governed setup - what goes into a workspace, who is allowed to connect what, and the material that never goes in at all. Tonight we stop talking about the system and pick up the single artifact you sign off more than any other: the plan. Northwind, our fictional retailer building a governed data platform, has a six-milestone plan and a slipping M3 gate. Its plan is the one you will pull apart.
The four ways an AI-drafted plan goes wrong 7 min live
These are not random errors. They are structural, they show up in roughly the same order every time, and each one has a visual tell you can spot before you have read a single line of detail. Once you can see them, a bad plan announces itself from across the room.
Live1 and 2 - invented dates and orphan owners3 min▶
Invented dates. Ask a model for a plan and it will give you dates, because a plan without dates looks unfinished and the model is optimising for looking finished. The tell is rhythm: everything is two weeks or four weeks apart, everything lands on a Friday, nothing sits awkwardly around a holiday or a hiring gap or the one week your architect is on leave. Real schedules are lumpy. Smooth is suspicious.
Orphan owners. The second tell is in the owner column. "The team", "engineering", "the data function", "the vendor" - these are not owners, they are places where an owner should have been. A model does this honestly: it does not know your people, so it writes the category. The damage is that an action with no name is an action nobody does, and the plan still looks complete on the page.
The Friday that was not there. A programme director reviewed a plan where nine of eleven milestones landed on a Friday and the tenth was a Thursday only because of a bank holiday. She asked one question in the review: "which of these dates did someone commit to out loud?" The answer was two. The other nine were the model's rhythm, dressed as a schedule. The plan went back the same afternoon.
Live3 and 4 - missing gates and phantom dependencies3 min▶
Missing gates. Discovery flows into build, build flows into test, test flows into go-live, and at no point is there a sentence you could hold up and say "this is true" or "this is not true yet". Gate criteria that read "ingest working well", "quality acceptable" or "design complete" are not gates. A gate is testable by someone who was not in the room: DQ pass rate at or above 99% on three consecutive nightly runs. That either happened or it did not.
Phantom dependencies. Two versions of the same defect. The first is a dependency the plan asserts but nobody confirmed with the other side - Veridian will deliver the POS extract by the 29th, says a document Veridian has never seen. The second is quieter and worse: a real dependency the draft dropped because keeping it made the schedule impossible. Models smooth. A constraint that breaks the story tends to leave the story.
The gate that meant nothing. A steerco approved a plan whose M3 exit criterion was "ingest working well across sources". Six weeks later two people were arguing in front of the sponsor about whether it had been met: 6 of 9 source systems were landing and 812k rows a night were flowing, which one person called working and the other called two-thirds done. Nobody was lying. The criterion had simply never been testable, and the argument was baked in from the day it was signed.
Self-studyWhy these four, and not others2 min read▶
All four come from the same root: a model can produce structure but has no access to commitment. Dates, owners, gate thresholds and cross-team agreements are all social facts. They exist because named humans agreed to them in a room, and no amount of text in a workspace contains that agreement unless someone wrote it down.
- Structure is knowledge. What phases a data platform programme usually has, what typically depends on what, what questions to ask - genuinely useful, and genuinely available to a model.
- Commitment is not. Who will do it, by when, and what "done" means to your sponsor. That comes from your team and nowhere else.
- The failure is always at the seam. Every one of the four defects is the draft quietly filling a commitment-shaped hole with structure-shaped material.
This is rail two of the course stated precisely: the dates come from the team. AI drafts structure, never commitments.
The seven-point rubric, run in five minutes 7 min live
You are a head of delivery with four programmes and forty minutes. You cannot read every line of every plan, and you should not - that is your PM's job. What you can do is run seven questions that are cheap to ask and expensive to fake. Every one of them is answered by looking at the shape of the document, not by understanding the work.
LiveThe seven questions4 min▶
Run them in order. Two or more failures and the plan goes back - not because it is wrong, but because it is not yet reviewable.
| # | Ask | You are looking for |
|---|---|---|
| 1 | Does every milestone have a testable gate criterion? | A sentence a stranger could mark true or false. "DQ at or above 99% for three nights", not "quality good". |
| 2 | Does every action have one named owner and one date? | A person, not a function. One name, not two. If it says "the team", it has no owner. |
| 3 | Is every external dependency confirmed by the other side? | A name and a date on the other team, plus when they said it. Unconfirmed is a risk, not a dependency. |
| 4 | Where did each date come from? | A person, a capacity calculation, or a contract. "It looked about right" is the failure state. |
| 5 | What is explicitly out of scope? | A non-goals list. A plan with no exclusions has not been negotiated with anybody yet. |
| 6 | What happens if the hard gate slips? | Named knock-on milestones and the decision that would be needed. Not "we would replan". |
| 7 | What is this plan's single biggest assumption? | One sentence, and whether it is being actively watched. If your PM cannot name it, nobody is watching it. |
LiveRunning it on Northwind, out loud3 min▶
Northwind is week nine. M3 (raw ingest signed off) was gated for 10 August and now forecasts 24 August. Six of nine source systems are landing, 812k rows a night, DQ pass rate 96.4% against a 99% gate. Here is the rubric on that plan in about ninety seconds:
- Q1 gates. M3's criterion is numeric and dated - good. M4's is "modelled warehouse reviewed", which fails.
- Q2 owners. Marcus L. on ingest, Sofia K. on modelling, Dan R. on BI. Named, single, real.
- Q3 dependencies. The Veridian POS extract is the live one. Has Priya N. got it in writing? Ticket VN-2291 has been open eleven days, so the honest answer is no.
- Q4 provenance. The new 24 August forecast came from Marcus and the nightly throughput, not from a model. Good.
- Q5 out of scope. Decision D-14 descoped real-time POS to nightly batch until M5. It is written down, which is why nobody is arguing about it.
- Q6 slip. If M3 moves to 24 August, does M4 move? What is the compression plan? This is the escalation session a4 builds.
- Q7 assumption. Risk R-03: two data engineers hired before M4 starts. Nobody has been hired. That is the whole programme in one line.
Ninety seconds, one finding. A PMO lead ran exactly this pass on a plan she had already skimmed twice. Questions one through six were fine. Question seven produced a five-second silence, then: "I suppose we are assuming the contractors get approved." Nobody had raised it, no risk existed for it, and it was four weeks from being the thing that stopped the programme. The rubric did not find a mistake. It found the thing nobody had said out loud.
Self-studyWhat the rubric deliberately does not ask2 min read▶
- It does not ask whether the estimates are right. You cannot tell from a document, and pretending you can is how leaders become the bottleneck on their own programmes.
- It does not ask whether the sequencing is optimal. That is a working session with the architect and the delivery lead, not a review question.
- It does not ask whether AI was used. Irrelevant. A weak plan written by hand fails the same seven questions, and a strong plan drafted with AI passes them.
PMBOK's planning performance domain frames it well: a plan is not a prediction, it is a coordination device. It only works if the people it coordinates recognise their own commitments in it. Every rubric question is really the same question - is this document connected to real people, or is it just internally consistent?
What a good AI-drafted plan actually looks like 4 min live
None of this means the answer is "do not use AI on plans". A good AI-drafted plan is genuinely better than the hand-written one it replaced, because the effort moved from formatting to thinking. The rule is simple: structure and questions from the model, numbers and commitments from the people.
LiveThe division of labour that works2 min▶
| From the model | From the people |
|---|---|
| The milestone skeleton for this kind of programme | Which milestones your sponsor will actually gate |
| Candidate gate criteria, written testably | The threshold number, and who signs it off |
| The dependencies this shape of work usually has | Confirmation from the other team, with a name and a date |
| The questions you have not asked yet | The answers, and the awkward one nobody wants to give |
| Consistent formatting across every artifact | Every date, every owner, every commitment |
Notice what the left column is worth. "The questions you have not asked yet" is the most under-rated output in this entire course. A model that has your charter, your risk register and your owner list will produce a list of unresolved items faster than any human review, and it has no political reason to leave the embarrassing ones out.
Fourteen questions, one that mattered. A delivery lead asked her loaded workspace for the questions her plan could not answer. She got fourteen. Eleven were obvious, two were pedantic, and one read: "M4 assumes modelling capacity that no named person in the owner list currently has." That was risk R-03 before anyone had written it as a risk. The model did not know the team was short. It knew the plan referenced work with nobody attached to it, and unlike the humans in the room it had no reason to be tactful about it.
LiveThe reframe: you are reviewing your PM, not the model2 min▶
This is the sentence to take into your next plan review. You are not reviewing the model's work. You are reviewing your PM's. The model just made producing it cheap.
It resolves almost every awkward conversation leaders are currently having about this:
- "Is it allowed?" becomes "is the artifact good, and did a named human sign it?" Which is the standard you already had.
- "Did AI write this?" becomes a question you do not need to ask. It changes nothing about your review and it makes your PM defensive.
- "The AI got it wrong" stops being available as an answer. The accountable name on the plan is a person, and PMI's 2026 AI standard is explicit that oversight means real intervention triggers, not perfunctory review.
The one thing that genuinely changes is your expectation of throughput. If a first-draft plan now takes ninety minutes instead of two days, then a plan that fails the rubric is not a tragedy, it is a Tuesday. Send it back. The cost of a rework loop has collapsed, so use the loop.
Find the five defects in Northwind's plan ★ 12 min · everyone reviews
Below is a real-shaped extract from Northwind's draft plan. It reads well. It contains exactly five planted defects, one per failure mode plus one extra. Give yourself four minutes on your own, write down what you find, then compare with the table below.
Run rubric question 1 down the exit criteria column. One of the three is not testable by a stranger. Which?
Run question 2 down the owner column. One owner is not a person.
Run question 3 on the dependency. Who on the Northwind side has confirmation from the other party, and does anything in this document tell you that?
Run question 4 on the dates. M3's 24 August came from Marcus and the nightly throughput. Where did 12 September come from?
Run question 7. What must be true for M4 to start at all - and is it anywhere on this page?
LiveThe answer key - open after you have found yours4 min▶
| # | Defect | Failure mode |
|---|---|---|
| 1 | M4 due 12 Sep. Nobody produced this date. It is exactly nineteen days after M3, which is the model's rhythm, not Sofia K.'s estimate. | Invented date |
| 2 | M4 owner is "the team". Sofia K. is the data architect and is nowhere on the page. | Orphan owner |
| 3 | M3 exits on "ingest working well". Today that is 6 of 9 systems and 812k rows a night at 96.4% DQ. Working, or not working? The criterion cannot answer. | Missing gate |
| 4 | "Veridian POS extract delivered by 29 Aug" is asserted as fact. Ticket VN-2291 has been open with the vendor for eleven days and Priya N. has no written commitment. That is risk R-07, not a dependency. | Phantom dependency |
| 5 | The hiring gate is absent entirely. Risk R-03 says there is no data engineer to build the model. "M4 begins immediately on M3 sign-off" quietly assumes two people who do not exist. | Dropped hard gate |
Defect five is the one that matters, and it is the one most groups miss, because it is not on the page. The other four are things the plan says wrongly. This one is a thing the plan does not say - and a smooth document is exactly where an absence hides best.
Write your PMO's plan-review checklist ★ 10 min · build your own
Seven questions is the teaching version. What you take back to your PMO is five, in your own words, on one side of paper, with a name against the sign-off. A checklist nobody can remember is a checklist nobody runs.
Pick your five from the seven. Most PMOs keep gates, owners, dependency confirmation and provenance of dates, then choose between out-of-scope and the biggest assumption. Keep assumption if you can only keep one.
Rewrite each in the language your organisation actually uses. If you call them stage gates, say stage gates. If your RAG rules are written down, cite them by name.
Add the sign-off line. Who is allowed to approve a plan at each value or risk tier, and what they are attesting to. This is the "clear structures, roles, authority and guardrails" that PMI's standard asks for, written in one sentence rather than a policy.
Add your two-strike rule: how many failed points send a plan back, and how fast the loop is expected to be. Publish the number so it is not a judgement call in the moment.
Test it this week on a plan you have already approved. If it finds nothing, your checklist is too soft. If it fails everything, it is too strict for a first draft. Tune once, then leave it alone for a quarter.
Five lines, one quarter. A PMO lead replaced an eleven-page plan-quality standard nobody had opened in two years with five questions on one page. Reviews went from a day of reading to twenty minutes across four programmes, and the send-back rate went up in month one, then fell below the old baseline by month three - because the PMs had learned the five questions and started answering them before submitting. The checklist did not improve reviews. It improved drafts, which is the only place quality was ever going to come from.
Try it yourself - this week ◐ 30-45 min total
- Run the seven questions on one live plan you have already approved. Not a draft - one that is in flight and that you signed. Write down what you find and resist the urge to fix it silently.
- Ask each of your delivery leads question seven, verbally, this week: what is your plan's biggest assumption and who is watching it? Note who answers in one sentence and who cannot answer at all.
- Cut your checklist to five questions and circulate it. Include the sign-off line and the send-back threshold.
- Find one gate criterion in your portfolio that is not testable and rewrite it with a number, a threshold and a signer. Just one. It is a surprisingly hard hour.
- Check whether any dependency in your top programme is asserted rather than confirmed. If you find one, that is not a plan defect, it is an open risk - which is exactly where session a4 starts.
Official sources covered
Taught from the delivery canon and PMI's public AI guidance. Certification (PMP, PMI-ACP) and the full normative text of the AI standard stay with PMI. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · A plan lands with every milestone exactly four weeks apart, all on a Friday. What is the tell?
Failure mode one. Even spacing is the model's rhythm, not your team's capacity. Ask rubric question four: where did each date come from? A person, a calculation, or a contract - or it is fiction with good typography.
2 · Northwind's M3 exits on "ingest working well across the in-scope sources". Why does that fail the rubric?
Failure mode three. A gate must be markable true or false by someone who was not in the room. "DQ at or above 99% on three consecutive nightly runs, all 9 sources landing" is a gate. "Working well" is an argument waiting for a steerco.
3 · Your PM submits a plan that fails three rubric points. What is the right reaction?
You are reviewing your PM's work, not the model's. Fixing it yourself removes the accountability the plan depends on, and banning the tool fixes nothing - a weak hand-written plan fails the same seven questions. Name the gaps, set a 48-hour loop.