Where we are: Northwind, week 1
Last session you built the workspace: one Project for the Northwind data platform, a six-document context pack, and a house-rules file. Tonight the pack is nearly empty, because week 1 is honest about how programmes actually start. You have one thing in it - a two-paragraph email from Elena V., the COO and your sponsor. Nine source systems, 812,000 rows a night at steady state, a legacy warehouse someone wants switched off, and none of that is written down anywhere yet. It is in people's heads, and your job this week is to get it onto a page that Elena will put her name against.
What a mandate leaves out 6 min live
Here is the whole brief. Read it the way you would read it at 08:14 on a Monday, with the rest of your week already booked. It is not a bad email. Elena is describing an outcome she wants, which is exactly her job. Turning an outcome into a scoped, sequenced, owned programme is exactly yours.
LiveFive things the email does not say4 min▶
Every one of these is a decision that will get made whether or not you make it deliberately. Left blank, they get made by whoever shouts on the day.
- Success measure. "See sales properly" is a feeling, not a measure. Does success mean one agreed daily sales number across stores and online? Available by 07:00? Reconciling to finance within a stated tolerance? Until that sentence exists, nobody can tell you whether the programme worked.
- Scope boundary. "All our data" is nine source systems. Are all nine in the first phase, or three that carry the sales question and six that follow? "All" is the most expensive word in the email.
- Priority order. Speed, cost and completeness are all implied and they conflict. Christmas peak pulls one way, "budget is tight" pulls the other, "all our data" pulls a third. Something has to give and Elena has not said which.
- Constraint reality. "Budget is tight" is not a number. And nothing in the email mentions that you are one data engineer short, which is the constraint that will actually decide the date.
- Decision rights. "Talk to Sofia" could mean Sofia K. decides the architecture, or advises on it, or has to be consulted before you do. Those are three different programmes.
The word "all". A delivery lead took a near-identical mandate at a grocery chain and started scoping all fourteen source systems, because the email said "all". Six weeks of discovery later the sponsor saw the plan and said, honestly baffled, "I only ever cared about tills and online." Two of the fourteen systems answered the actual question. The other twelve were a phase-two conversation that nobody had ever had, because nobody had asked what "all" meant out loud.
Self-studyWhy sponsors write it like this2 min read▶
It is tempting to read the email as vague or careless. It is neither. Elena is doing the thing a sponsor is supposed to do: naming an outcome and the pain behind it, then handing the how to someone whose job is the how. PMBOK 7 calls this stewardship, and the split is deliberate - the sponsor owns the why and the money, the delivery lead owns the shape of the work.
- She has told you the real pain. "Every report tells me something different and I have stopped trusting the numbers." That is worth more than a spec. Trust in one number is the actual success measure hiding in the email.
- She has given you an ally and a lean. "Talk to Sofia" is a routing instruction, use it in week 1 rather than week 5. "Budget is tight" may not survive a business case, but it tells you which way she leans when speed and cost collide.
Your job is not to complain that the brief is thin. It is to convert it into something specific enough that Elena can look at it and say "no, not that" - which is the only reliable way to find out what she actually meant.
The charter fields that actually earn their place 5 min live
A charter template can run to thirty fields and most of them are ceremony. Nine do the work. These nine are the ones that later stop an argument, and the reason they matter here is that they are also the exact structure you hand the model - a draft with no field list comes back as prose, and prose hides the gaps.
| Field | What it settles later |
|---|---|
| Context | Why now. Stops phase two re-litigating the whole premise |
| Objective + success measure | The number or condition that means "done and it worked" |
| In scope | Which of the 9 Northwind sources, in which phase |
| Out of scope (non-goals) | The request in week 6 that you can decline in one sentence |
| Priorities P1 to P4, ordered | What gives way when two good things collide |
| Constraints | Money, people, hard dates, systems you cannot touch |
| Assumptions | What you are betting on. Each one is a risk in waiting |
| Decision rights + named sponsor | Who signs, who is consulted, who is merely told. One human: Elena V., not "the business" |
LivePriorities are only real when they are ordered3 min▶
Ask any sponsor to rate priorities and you get four P1s, because everything genuinely does matter to them. A priority list where everything is P1 contains no information. It cannot resolve a single trade-off, which is the only job it has.
For Northwind, the ordered version might read:
- P1 - one trusted sales number across stores and online. This is the pain in the email.
- P2 - the Christmas peak date for that number, and nothing else needs to hit it.
- P3 - breadth, the remaining source systems, then P4 - decommissioning the legacy warehouse, which saves cost but changes nothing for Elena.
Now the list does work. When the vendor extract slips, P3 gives way and P1 does not. When someone asks for a self-service model, it is not on the list at all. And notice what the order reveals: if Elena reorders P2 above P1, she is telling you she would rather have a date than a trustworthy number, which is a conversation you very much want to have in week 1 rather than week 14.
The reorder that changed the plan. A PM walked a sponsor through four priorities she had drafted as speed, coverage, cost, retirement. The sponsor moved cost from third to first without hesitating, then explained that a board commitment on run-rate landed in January. Nothing in the brief had mentioned it. That single drag-and-drop killed two workstreams, saved four months, and only happened because the list was ordered enough to be argued with.
LiveNon-goals: the field that saves the programme3 min▶
Scope rarely arrives through the front door. Nobody sends a change request titled "please double the programme". It arrives sideways, in a corridor, as a reasonable-sounding sentence: "while you are in there, could you also...". The written non-goal is the only cheap way to answer that.
- An unwritten non-goal is not a non-goal. If it lives in your head, the answer in the corridor is a negotiation. If it is in a charter Elena signed, the answer is a link.
- Non-goals are not refusals. "Not in this phase, revisit at M4" is a non-goal. It respects the request and dates the conversation, which is why they rarely cause offence.
- Write the ones people will actually ask for. A non-goal nobody would have requested is filler. The useful ones feel slightly uncomfortable to write down, which is how you know they were live.
The corridor request. Week 6 of a warehouse build, a regional director caught the delivery lead by the lifts and asked for live till data on his phone, "just for my stores, it should be easy now the pipes exist". It was not easy: nightly batch and real-time streaming are different architectures, different cost, different on-call. Because "real-time POS is not in this phase" was line two of a signed charter, the answer took nine seconds instead of three weeks of investigation the team would never have got back.
Ask the model for the questions, not the answers 4 min live
Here is the counter-intuitive bit. At charter stage, the most valuable output is not a charter. It is the list of ten questions you must ask Elena before you commit to anything, generated by something that has read the email carefully and is not embarrassed to point out what is missing. Then you tell it explicitly not to answer them itself.
LiveWhy the questions beat the draft2 min▶
A model asked to write a charter from a thin email will produce a complete-looking charter, because completeness is what charters look like. It will quietly fill the gaps with the average of every data platform charter it has ever seen. That average is not wrong exactly - it is plausible, generic, and belongs to no one. Worse, it is hard to see: a gap filled with confident prose reads exactly like a fact.
Ask for the questions instead and the same reading ability works for you. It is genuinely good at noticing that "before Christmas peak" is not a date, that "all our data" has no boundary, and that nobody has been named as the person who signs off the model. That is rail one doing its job in reverse: a weak draft means a missing document, so the fastest route to a strong draft is finding out which documents are missing.
The question that moved a milestone. A TPM ran her mandate email through this move and got back a question she had not thought to ask: "who signs off that a data quality number is acceptable, and what is the threshold?" She took it to the sponsor, who did not know either, which forced a twenty-minute conversation with the finance lead. Out came the 99% figure that became the M3 gate. Without the question, "good enough quality" would have been discovered at the gate, in front of the steerco.
LiveTaking ten questions to a sponsor without looking unprepared2 min▶
There is a real fear here and it is worth naming: arriving at a COO's desk with ten questions can look like you have done nothing. Done well, it looks like the opposite. Four rules make the difference.
Bring the draft, lead with the draft. Open with "here is the charter as I understand it" and let her read a page that is 70% filled in. The questions are the visible holes in something substantial, not a blank form.
Propose an answer to every question. Never "what is the success measure?" Instead: "I have written the success measure as one agreed daily sales number, stores and online, available by 07:00. Is that what you meant?" It is far easier to correct a wrong answer than to produce a right one on the spot.
Say what each answer unlocks. "I need the scope boundary because it changes the plan by about two months." A question with a consequence attached is a decision request. A question without one is homework you are handing back.
Route the ones that are not hers. Of ten questions, maybe four are Elena's. The rest belong to Sofia K. on architecture, Priya N. on the vendor, Dan R. on reporting. Show her that you have already routed them - that is the move that reads as prepared.
Mandate email to charter draft, plus a GAPS list ★ 12 min · everyone builds
Open the Northwind workspace from b1, paste Elena's email in if it is not there already, and run this. The output you want is a charter that looks slightly unfinished, because it is. Every TBC in it is a question with a name attached.
Confirm the email is the only source in the workspace for this task, then run the prompt below. Read the charter first, then the GAPS list, then go back through the charter looking for anything asserted that the email never said.
Hunt for smuggled facts: a date, a budget figure, a team size, a technology choice, a phase-two plan. Each one is a place the model quietly averaged over your programme. Rewrite every one as TBC with the role who owns the answer.
Pick the four questions you take to Elena V. this week, and route the rest: architecture to Sofia K., the POS extract and the vendor Veridian to Priya N., reporting expectations to Dan R.
The five non-goals, written down and agreed ★ 10 min · build your own
Now the field that pays for the whole session. Five sentences, agreed by Elena V. in week 1, that will each save you a fortnight somewhere between now and M6. Here is the Northwind set - yours will differ, but the shape will not.
| Non-goal | Who will ask, and what it costs to say yes |
|---|---|
| No real-time POS data | Store operations, once the pipes exist. Streaming is a different architecture, cost and on-call rota. Revisit after M5 |
| No self-service ML for every team | Anyone who has read an AI headline. M6 is one use case, deliberately. A platform for everyone is a programme of its own |
| We are not replacing the ERP | Finance, when they see the modelled warehouse. Reading from the ERP is not replacing it. Never in this programme |
| No new BI tool | Dan R.'s team, reasonably. A tool migration inside a data migration doubles the risk and hides which one failed |
| No migration of historical archives | Whoever remembers 2019. Two years of history, not ten. Archive migration is a phase-two business case |
Draft the five with the prompt below, using the charter and the mandate email as the only sources. Sharpen each into one sentence a sponsor can say yes or no to in ten seconds - if it needs a paragraph of caveats, it is not agreed, it is deferred.
Add the "instead" for each: later phase, another team, or never. A non-goal with no destination becomes a grudge.
Take all five to Elena V. in the same conversation as your four questions and ask her to strike any she disagrees with. Then put the survivors at the top of the charter, not in an appendix, and paste them into the workspace context pack so every later draft knows what you already cut.
The line in the appendix nobody read. One programme did write its non-goals - and buried them on page nine of a charter deck. In month four a director asked for the archive migration, the delivery lead said "that is out of scope", and the director said, genuinely, "since when?" Technically since week 1. Practically since never, because it had been agreed by silence rather than out loud. They lost the argument and six weeks. Non-goals belong on page one, read aloud, with a nod from the sponsor. The document is not the agreement - the conversation is, and the document is what you keep afterwards.
Try it yourself - this week ◐ 30-45 min total
- Find the thinnest brief you have ever been handed - a real one, an email or a slide - and run the charter-plus-GAPS prompt over it. Count the smuggled facts.
- Write your own programme's priorities as an ordered P1 to P4 list, then send it to your sponsor with one question: "have I got the order right?" Watch what moves.
- Write five non-goals for a live programme. At least two should make you slightly uncomfortable. Get them agreed out loud, not by silence, and take four questions rather than ten to your sponsor - each with a proposed answer and one line on what it changes.
- Add the finished charter to your workspace context pack. Every session from b3 onward assumes it is there, and so does every draft you will ask for.
Official sources covered
Taught from the delivery canon plus the by-hand prequel course, with vendor documentation for the workspace mechanics. PMI certification and the full normative text of its standards stay with PMI. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Your charter draft says "delivery by mid-November". Elena's email said only "ideally before the Christmas peak". What do you do?
Rail two, and the most common smuggled fact of all. Nobody was asked and nothing was capacity-checked, so mid-November is invention with a professional font. AI drafts structure, never commitments.
2 · Your sponsor marks three of the four priorities as P1. Why does that break the charter?
Priorities exist to settle collisions. Everything-is-P1 carries no information and quietly hands the decision to whoever escalates loudest on the day. Push for the order, even if it takes two attempts.
3 · Week 6, a regional director asks for live till data on his phone. What makes that a nine-second conversation instead of a three-week investigation?
Scope arrives sideways, in corridors, as reasonable requests. The only cheap defence is a non-goal that was written down and agreed out loud in week 1 - on page one, not in an appendix.