Where we are: week 3, and the plan still looks perfect
In b2 you turned Elena V.'s mandate email into a charter. In b3 you laddered six milestones with gate criteria: M1 discovery and source inventory, M2 landing zone and platform stood up, M3 raw ingest signed off with a gate on 10 August, M4 modelled warehouse signed off, M5 governed BI in production, M6 first AI/ML use case live. Nine source systems, 812k rows a night, a 99% data-quality gate, every milestone with a definition of done, nothing red. That is exactly when a programme is most dangerous. A milestone ladder tells you the order you would like things to happen in. It says nothing about what physically cannot start until something else finishes, who outside your programme controls one of those arrows, and which arrow no amount of overtime can shorten.
Three relationship types, and the label that actually matters 6 min live
Textbooks spend a lot of pages on the three logical relationships and about a paragraph on the distinction that decides whether you keep your job. Learn the three quickly - they are genuinely useful shorthand - then spend your real attention on the second row: is this arrow inside my control, outside it, or a hard gate that no amount of parallel effort can shorten?
LiveThe three types, in about ninety seconds2 min▶
- Finish to start. The default. Marcus L. finishes the raw ingest, then Sofia K. starts modelling. If you can only remember one, remember this one.
- Start to start. Dan R. can start building the BI semantic layer once modelling has started, working off the agreed model rather than the finished tables. He does not need Sofia to be done, he needs her to be underway. This is where you find compression.
- Finish to finish. Data-quality certification cannot finish until ingest finishes, because the last table has to pass the 99% gate too. Very common at gates, and very often mislabelled as finish-to-start, which makes your plan look four weeks longer than it is.
Six weeks that were never really there. A delivery lead inherited a plan where BI development sat entirely after warehouse sign-off, finish to start, six clean weeks of it. In the first walkthrough Dan R. said the thing that had never made it into a document: "I only need the agreed model, not the built tables - I have been waiting on paper, not on data." Relabel one arrow to start-to-start and the programme got four weeks back without anyone working a weekend. Nobody had been lying. Nobody had ever asked.
LiveInternal, external, and the hard gate3 min▶
| Label | Who controls it | What you actually do about it |
|---|---|---|
| Internal | You, through your own team | Resequence, resource, overlap. This is the pile you can genuinely manage your way out of. |
| External | Somebody who does not report to you and has other priorities | Confirm in writing, name their owner, agree a date, and put it on the risk register the day it is unconfirmed. |
| Hard gate | Physics, law, contract, or hiring reality | Nothing shortens it. Make it visible, start it early, and stop pretending the plan absorbs it. |
A hard gate is the one that kills programmes, because it behaves so politely until it does not. Everything upstream of it can be green. Everyone can be busy. The burndown can look healthy. And then you reach the gate and discover that no amount of parallel work, overtime, or clever resequencing helps, because the thing you need is a signed contract, a legal approval, a decommissioned legacy system, or two people who do not work here yet.
The green programme that stopped dead. A platform migration ran green for eleven weeks. Every workstream on track, every demo good. In week twelve it hit a security review that could only start after the penetration test, which could only be booked once the environment was frozen. Nine weeks of gate, none of it on the plan, none of it compressible. The retro finding was not "we were late". It was "we drew our arrows only between our own tasks."
Self-studyLead, lag, and why they are not slack2 min read▶
- Lag is enforced waiting. Northwind's DQ certification has a three-day lag after each ingest cut, because the checks run over three nightly batches of 812k rows. That is not padding, it is how long the machine takes.
- Lead is deliberate overlap: starting the successor before the predecessor is done. Dan R. starting on the agreed model is a lead of about two weeks.
- Neither is slack. Slack is how long an activity can slip without moving the end date. Write lag only where you can name the mechanism - three nightly batches is a mechanism, "buffer for issues" is a feeling, and feelings belong on the risk register.
Pulling dependencies out of three weeks of notes 5 min live
Here is the honest split. Reading twenty pages of stand-up notes, workshop scribbles and call summaries and surfacing every instance of "X said they need Y before Z" is a mechanical, tedious, high-recall reading task. That is one of the very few things AI does better than a tired human at 6pm on a Thursday. Deciding whether Veridian actually agreed is a phone call, and no model can make it.
LiveWhy extraction beats a workshop whiteboard2 min▶
The traditional way to build a dependency map is to get everyone in a room and ask "what are you waiting on?". It works, and you should still do it. But it has two known failure modes, and extraction covers both.
- People only report what they are currently blocked by. Nobody says "in nine weeks I will need the legacy warehouse decommissioned" because it is not hurting yet. Notes from three weeks ago remember it. R-05 lives in exactly that gap.
- The quiet person in the room stays quiet. The vendor manager who mentioned the Veridian spec lead time once, in passing, in a call summary, will not repeat it in a workshop where the architect is talking.
So run both. Extract from the notes first, bring the table to the workshop, and let people argue with rows instead of staring at a blank wall. Feed it stand-up notes, workshop outputs, call summaries, ticket comments and the b3 plan, raw and messy - cleaning it first is how you accidentally delete the sentence that mattered.
LiveThe non-negotiable follow-up: confirm every external arrow3 min▶
Extraction gives you candidates, not commitments. The follow-up is not optional and it is not a nicety: every external dependency must be confirmed by the other side, in writing, with a named owner and a date. Until then it is not a dependency. It is a rumour with an arrow drawn on it.
The confirmation message is four lines and takes two minutes to send:
State the dependency in one sentence, in their language. "We need the POS extract field spec from Veridian before we can build the ingest."
Name the owner on their side. Not the company - the person. "Priya N. tells me this sits with your integration lead."
Ask for a date and say what it feeds. "Can you confirm a date? It feeds our 10 August M3 gate."
Say what you will do with the answer, then mark the row confirmed only when the reply exists - not when you sent the message, and not when someone nodded on a call.
The dependency that was one person's assumption. A programme carried an arrow that said the finance system team would provide a nightly reconciliation feed by a certain date. It had been in the plan for four months, dark green, never questioned. When someone finally asked the finance team, the answer was: "we have never heard of this, and we do not have a feed like that." The whole arrow had come from one architect saying "finance can probably give us that" in a workshop nine months earlier. Four months of a plan built on the word "probably".
The critical path, and the gate sitting in the middle of it 5 min live
The critical path is the longest chain of dependent work through your programme. Everything on it moves your end date one day for every day it slips. Everything off it has slack. Which means the only genuinely important question about any dependency is: is it on the path? At Northwind the path runs straight through R-03, and R-03 is not a task.
LiveWalking the Northwind chain out loud3 min▶
- M3 raw ingest signs off on 10 August. Nine source systems landing 812k rows a night, all passing the 99% DQ gate. Marcus L. owns it, and NWD-412 (the failed CDC load) is the live blocker.
- Model design can start now. Sofia K. does not need the data to design the model, she needs the source inventory from M1. This is a start-to-start, not a finish-to-start, and it buys you weeks.
- M4 modelled warehouse cannot start. Not "will be slow". Cannot start. Sofia designs; two data engineers build. Northwind has hired neither. R-03.
- Therefore M5 governed BI and M6 the first AI use case both move day for day with the hiring, not with anything Dan R. or Sofia K. do.
Notice what happened. R-03 was on your risk register as a resourcing risk, medium-ish, the kind of row people skim. Drawn on the dependency map it is a wall across the critical path, and every week it stays open is a week added to M4, M5 and M6 simultaneously. So make it impossible to skim: give it its own shape on the diagram (in the Mermaid below the gate is a hexagon, not a box); write the arithmetic underneath it - offer accepted plus four weeks notice plus two weeks onboarding is the earliest possible M4 start, and sponsors argue with adjectives but concede to arithmetic; give it a decision date rather than a status - "if no accepted offer by 24 August we switch to contract engineers", which is a trigger, and next week builds a register full of them; and put it on page one of the status report, not in the risk annex, every week until it closes.
"We will backfill in Q3." A data programme carried a two-headcount gap as an amber risk for five months. Every status report said recruitment was underway. Nobody ever drew it on the plan, so nobody ever computed what it meant: the build phase could not start, so the whole back half of the programme was sliding one week per week, silently, while the front half stayed green. The day someone finally drew the arrow, the sponsor approved two contractors in an afternoon. Five months of the plan had been fiction because a risk row is easy to skim and an arrow across the critical path is not.
Notes to table to diagram ★ 14 min · everyone builds
Three moves. Extract to a table with sources you can check, argue with the table, then render the confirmed map as a diagram. Do not skip straight to the diagram - a pretty graph of unverified arrows is the most persuasive wrong artifact in delivery.
Load the raw notes into your Northwind workspace: three weeks of stand-ups, the M2 workshop output, and Priya N.'s summary of the Veridian call. Then run the extraction prompt below. Expect twelve to twenty candidate rows, several of them wrong - that is the correct outcome.
Walk the table with the team for ten minutes. Delete the inventions, merge the genuine duplicates, split the fake ones, mark what is truly confirmed, and send the confirmation messages for every external row today.
Render the confirmed map as a diagram, with unconfirmed arrows visibly marked, and bring it to the next steerco.
| ID | Predecessor → successor | Type | Class | Status |
|---|---|---|---|---|
| D-01 | Veridian POS extract spec (Veridian integration lead) → build POS ingest (Marcus L.) | Finish to start | External | UNCONFIRMED - no date stated, VN-2291 open |
| D-02 | Legacy warehouse decommission window (Elena V.) → M5 governed BI cutover (Dan R.) | Finish to start | External - IT ops | UNCONFIRMED - surfaced from a week-1 note, R-05 |
| D-03 | NWD-412 CDC load fix (Marcus L.) → M3 raw ingest sign-off (Marcus L.) | Finish to start | Internal | Confirmed - 10 Aug gate |
| D-05 | Two data engineers hired (Elena V.) → M4 warehouse build (Sofia K.) | Finish to start | HARD GATE - R-03 | Open, no accepted offer |
Read D-02 again. That row came out of a single sentence in a week-1 note nobody remembered, and nobody would have raised it in a workshop, because in week 3 the legacy warehouse is not hurting anyone. It hurts in week 22, when it is a nine-week external gate on M5. Now render the map. Mermaid is the fastest way to get a dependency graph into a document, a wiki or a pull request without opening a drawing tool, and it diffs in version control like text because it is text. The syntax itself is taught properly in learn-mermaid-with-phoebe - here you just need enough to draw a map.
Find the gate everyone forgot ★ 8 min · interrogate your map
You now have a map. A map is a claim, and claims should be attacked. Five questions, asked of any dependency map, will find the missing arrow more reliably than another workshop. Run them on Northwind now, then run them on your own programme this week.
Run it, and read question 1's answer with real suspicion - this is where the missing environment, the unbooked security review and the undiscussed data-sharing agreement show up.
Take question 5 seriously. "When M4 fails to start" is a terrible answer and it is the true answer on most programmes. The fix is a leading indicator: offers out, interviews booked, agency briefed. Then turn every hole into a new dependency row or a risk row - next week you build the register that holds them.
Try it yourself - this week ◐ 40-60 min total
- Run the extraction prompt over three weeks of your own real notes. Do not clean them first. Count how many rows come back that you had genuinely forgotten - that number is your case for doing this every quarter.
- Classify every row internal, external, or hard gate, and be honest about the third column: if you have zero hard gates on a programme of any size, you have not found them yet. Then send confirmation messages for every external row today, four lines each.
- Draw your critical path as a Mermaid graph, about eight nodes, with any hard gate in a different shape. Paste it into your next status pack.
- Run the five-question interrogation on it. Write down the answer to question 5 - the earliest date you would know - for your single biggest gate. If the answer is "when it fails", design a leading indicator this week.
Official sources covered
Dependency logic, critical path and gates come from the delivery canon, which has not moved in decades and will not. The AI half is the extraction step. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · AI extracts a dependency from your notes: Veridian must ship the POS spec before ingest can be built. What is it until Veridian replies?
Extraction produces candidates. An external dependency is confirmed only when a named person on the other side agrees in writing, with a date. Until then it is one architect's assumption wearing an arrow.
2 · R-03 means two data engineers are not hired, and M4 cannot start without them. Your sponsor asks you to run things in parallel to catch up. What is the honest answer?
Parallel work fixes a slow dependency. A hard gate has no task to overlap: offer accepted plus notice plus onboarding is the floor. Show the arithmetic and give it a trigger date for switching to contract engineers.
3 · Dan R. says he only needs the agreed model, not the built tables, to start the BI semantic layer. What changes on your map?
He is still dependent, so the arrow stays - but the relationship is start-to-start, not finish-to-start. Mislabelling this makes a parallel workstream look sequential and adds weeks that were never really there.