4 · Opening and Agreement: Write the Deployment Charter
Companion Templates
The Challenge. After the readout everyone says "continue," and each person's "continue" is a different project. You do not want to find that out in week 10.
What You Will Be Able to Do. Write a one-page deployment charter with the seven elements. Run a 60-minute contracting meeting. Settle the North Star metric, both sides' commitments, and the exit conditions at the cheapest moment the project will ever have, and make the business side as accountable for that page as you are.
Part II Navigation. The timeline below governs Chapters 4 to 9, not just this chapter (book order ≠ time order, and Chapter 7 turns the clock back). readout (week 1 Tuesday) → the five-question elimination (weeks 1 to 2, Chapter 7) → stakeholder map (the night before the charter meeting, Chapter 5) → the charter meeting (early week 3, this chapter) → shadowing Linda Marsh (week 3 Wednesday, Chapter 6) → charter signature (week 4) → the data deadlock and the way through it (after signing, Chapter 5)
Three Versions of "Continue"
On the Tuesday afternoon after the Field MVP readout, Grant Whitmore said "continue." You walked out of the meeting room in a good mood. A good mood is when people stop noticing danger.
The danger surfaced over the next two weeks, piece by piece. Kevin Doyle sent an email, copying two engineers, subject line "dashboard requirements, first draft." In week 1 he had agreed to your face to put the big screen into the backlog (Chapter 2). In week 2 you had just put it on the charter meeting agenda (Chapter 3). Two days later the first-draft email arrived. In his universe, "continue" means the backlog thaws and work starts on the management dashboard. The PMO ran its quarterly stocktake, dug out an old ticket approved three months ago for an "intelligent Q&A assistant," acceptance wording "Q&A accuracy ≥90%," and asked when that ticket closes. In the PMO's universe, "continue" means pushing ahead on that old ticket. In your universe, "continue" means entering discovery (the stage of finding out how things actually are, Chapter 2) and turning the exceptions queue from a ten-case prototype into a verifiable plan.
Three "continue"s, three projects. Each has an email for evidence, and each is spending money. Leave them alone and they run in parallel for ten weeks, then collide head-on at some reporting meeting. Kevin asks where the dashboard is. The PMO asks how the accuracy gets accepted. You explain that what you are building is an action queue (the queue that lines up the next action for every claim). At that moment everyone feels let down, and everyone is right.
What this chapter does is take that collision apart ten weeks before it happens, with one page and one hour of meeting. That page is the deployment charter.
Why This Is Hard: Vague Authorization Is More Dangerous Than None
A project with no authorization does not die of misunderstanding. It never starts, nobody commits anything, and nobody gets hurt. Vague authorization is the dangerous kind. "Continue." "Get started on it." "I support this direction." Each of these hands every party the permission it wanted, and then every party spends real money on a contradictory expectation. Kevin committed engineer schedule. The PMO hung the old ticket back on its register. You committed a discovery plan. The more each side commits, the more certain it becomes of its own version of "continue," and sunk cost hardens the expectation gap from a disagreement into a standoff. Nobody will give ground first, and time piles small differences into opposition.
Chapter 0 said it. People's agreement to an abstract description is cheap, and "continue" is the most typical case of all. The Field MVP's principle applies here too. Nobody at Anchor & Helm wants to betray this project, and betrayal is not what the charter guards against. It forces the expectations of three universes onto one table and aligns them while nobody has yet paid for a misunderstanding. A charter's use is to make the expectation gap blow up at the cheapest moment.
A team from outside doing the same work has at least one signed commercial document forcing both sides to write their expectations down. Inside, you do not even have that floor. One "continue" from Grant can start a project, and nobody has to write anything down. So the collision of three "continue"s comes earlier, and comes more often. The charter is therefore your only written agreement, and not one of the seven elements can be missing.
Prior Art: Contracting and the AI Era's New Clauses
The method behind this one page comes from a mature tradition in consulting. In Flawless Consulting, Peter Block puts contracting (the entry conversation that sets terms of engagement) first in the consulting sequence, ahead of all diagnosis and all solutions. Three ideas sit at its core, and fifty years on they hold unchanged.
First, the agreement is a 50/50 conversation about responsibility. A project is a co-build where each side carries half, and the one-way relationship of "you deliver, they accept" does not go far. Negotiating the agreement is that relationship's first rehearsal. A business side that only wants to set the questions during contracting will not turn into a co-builder later either. Inside a company one more move is missing. The business side does not accept anything, it only cooperates or fails to. Nobody will manufacture that moment of forcing someone into co-building for you. You have to manufacture it yourself, in this meeting.
Second, the agreement has fixed elements. Goal, both sides' commitments, boundaries, support needed, feedback and how it gets measured. Not one may be left blank. The cell you leave blank is the cell that blows up ten weeks later.
Third, "what you want" and "what you are willing to put in" must be negotiated in the same room. This is Block's sharpest point. The side asking is used to talking only about what it wants. The side building is used to committing only to what it will put in. The contracting conversation forces both hands onto the table at once. You want handling time down 30%? Fine, then you put in 2 hours a week from Linda's team. A want that will not discuss what it costs is a wish, not an agreement.
In the age of AI agents this method takes on one change of order and two new clauses.
The change of order is that the charter now gets signed after the Field MVP evidence. In Block's era contracting happened before any work at all, so both sides could only trade vision for vision, and the agreement filled up with toothless words like "improve efficiency." Today the cost of a prototype has collapsed (Chapter 0), so you can spend 2 hours getting ten scored cases before you talk terms. That changes the nature of the negotiation, from vision against vision to evidence against evidence. "How big a target" rests on how the waiting time in ten cases breaks down. "Whether Linda's team puts hours in" rests on three unsafe annotations. This is the whole reason this book puts the Field MVP before the charter.
New clause one, the data boundary. A traditional consulting agreement needed no separate conversation about data. Reading reports and running interviews was enough. An AI system has to eat the business side's data to work at all, so which data, de-identified to what degree, in whose environment, approved by whom, delivered when, gets promoted from a logistics question to a clause of the agreement. A project that does not write the data boundary into the charter turns, in week 9, into an email to IT that nobody answers for ten days.
New clause two, acceptance tied to the eval (the evaluation set). A traditional deliverable can be accepted by walkthrough. A probabilistic system cannot. "The demo passed" and "the boss is happy" cannot accept a system whose output may differ every time. Only one thing stands up. Both sides co-build a set of golden cases (sample cases with the correct answer settled in advance), agree on thresholds, and a score over the line is what counts. Most projects inside a company have no acceptance meeting, so acceptance is replaced by launch release conditions. The eval spec both sides co-build is the authority, golden cases plus agreed thresholds, and a score over the line releases the launch. The people who release are the business-side owner and the risk owner, not you. When the charter is signed the eval spec usually does not exist yet, so the release mechanism has to be signed first. What gets signed is "what counts as counting," and the numbers come later as an attachment (the eval spec is Chapter 11).
Deployment Charter, Definition and Seven Elements
Deployment charter, a one-page working agreement signed by both sides, setting out one measurable North Star outcome, named users and owners, boundaries and data, what each side puts in, and two-way exit conditions.
Three words in that definition carry weight. "One page." Past one page nobody remembers it, so it constrains nobody. "Signed by both sides." It is produced live in the contracting meeting, and a document you wrote and then carried to the business side for a signature does not count. The charter takes four signatures, Grant Whitmore, Kevin Doyle, you, Owen Hartley. Drop the last one and your schedule can be pulled out from under you tomorrow. What Owen signs is not what gets built. It is that these people, for these weeks, belong to this project. He is signing that these people's time goes to you first for these weeks, not agreeing to what you do with it. "Exit conditions." They matter as much as the goal, and why comes shortly.
The seven elements follow (the full fillable template is Template 4).
| # | Element | The Standard in One Sentence | What Happens If It Is Blank |
|---|---|---|---|
| 1 | North Star outcome metric | One, measurable, an outcome and not an activity | The project proves itself with activity metrics, and the board does not buy it |
| 2 | actual user and owner, by name | The person who uses it and the person who owns it after launch, names and not departments | The day the system launches is the day an orphan is born |
| 3 | Scope and Red Lines | What gets built, what explicitly does not, what is not touched at all | Scope swells at every meeting, and red lines get stepped on in the excitement |
| 4 | Data boundary and access commitments | Which data, in what form, approved by whom, delivered when | The week 9 death email, "it is going through the process" |
| 5 | Business-side commitment | People × time, by name, written into their calendar and not their wishes | A one-way delivery promise, and the handoff is certain to fail |
| Second row of it, your team's commitment and protection conditions | Your people × time, by name, countersigned by your manager, stating who has to approve before anyone is pulled | Your schedule can be pulled out from under you tomorrow | |
| 6 | Acceptance method | Write it as launch release conditions, tie it to the eval, golden cases plus thresholds, sign the mechanism now and fill in the numbers later | Acceptance turns into the political question of "does the boss think it is fine" |
| 7 | Exit conditions | Two-way, which signal lets which side call a stop | Once the project is a zombie, nobody has the authority to shoot it |
The seven elements are produced by one 60-minute contracting meeting. The skeleton agenda follows (the full version is Template 4).
- First 10 minutes, open with evidence. No vision deck. Retell the Field MVP scoring results and the readout conclusion, so every negotiation that follows is anchored to evidence.
- 10 to 25 minutes, the North Star negotiation. Definition, baseline, size of the change. The hardest 15 minutes of the meeting.
- 25 to 35 minutes, names and commitments. actual user, owner, the people and hours the business side puts in, plus your team's commitment and protection conditions. Write names, and watch the person or their manager nod in the room.
- 35 to 45 minutes, scope, red lines and the data boundary. The "not doing" list, the data clauses, the date of the security review.
- 45 to 55 minutes, acceptance and exit. Settle the acceptance mechanism first, then ride it into the exit conditions. That is the least awkward door into talking about exit.
- Last 5 minutes, read back and commit. Read the seven elements back out loud, and agree on writing it up within 48 hours and signing within a week.
Inside a company this meeting has three more things to settle, all of them in the 25 to 35 minute stretch. First, claiming the owner role needs something in return. The business side will say "you built the system, so of course you keep it running," and inside one company that sentence is literally true, so the owner cell is not a name to fill in, it is a claim to be made. Kevin claims owner, and what he gets back is that after launch this system's priorities and release schedule are his to set. A claim with nothing in return is politeness at signing and a blank at handoff.
Second, a committed input has no invoice to remind anyone, and the substitute is the fulfillment rate. The business-side commitment gets reported once a month at the sponsor weekly. Hours promised, hours delivered, one line of numbers, and whoever came up short is visible in the meeting.
Third, your team's commitment goes in too, along with the protection conditions. A team from outside has a commercial document as a shield. You do not, and your people can be pulled off at any moment to put out someone else's fire. Owen countersigns this row, and it states that pulling anyone requires going through Grant's weekly first.
Two facilitation rules. First, the meeting must have a decision-maker who can settle metrics and commitments on the spot, at Anchor & Helm that is Grant. Second, you draft the charter, and you never finalize it alone. Every cell must be changed by the business side at least once during the meeting. A business side that leaves no fingerprints on it will never think of it as theirs.
An internal reader holds three things an outsider does not. Use them. First, precedent. You can get the original charters other projects in this company wrote, including how they set their targets, and "the last project wrote it this way too" is a hard argument inside a company. Second, dropping by. The three "continue"s do not have to wait for emails to collide. Before the meeting you can walk over to Kevin's desk and then to the PMO's, ask each for their version, and bring only the differences into the room. Third, depth. You know how this company's last AI project actually died, so the pre-mortem memo can carry real events instead of imagined ones.
At Anchor & Helm: A Record of the Charter Meeting
The meeting is set for early week 3, after the readout. Grant Whitmore, Kevin Doyle, you. Your team's commitment row went past Owen Hartley beforehand, and he signs fourth. Three key rounds, ordered below by how contested they were, not by the agenda.
Round one, how -30% got negotiated.
The North Star you propose is "first-touch handling time for auto exceptions, down 30%." Nobody objects to the metric itself. It already appeared in the pre-mortem (Chapter 1). The disagreement is over the size. Grant says, "Can we write 50%? The board likes numbers it can hear."
Most people say yes here. The sponsor wants a prettier number, and the pull to agree is enormous. You do not say yes and you do not say no. You put the MVP's ten-case table on the screen and break the waiting time down by where it goes. "Across these ten claims, about six tenths of the waiting time goes to 'waiting on documents with nobody knowing whom to chase' and 'stuck with nobody claiming it.' The queue can eat into that part. The other four tenths is physical time, survey and loss assessment where somebody has to drive out there, plus the core system's own routing. The queue does not touch it. Eat half of the six tenths it can reach and you get -30%. To get -50% you have to go after automated payout decisions and a core system rebuild. The first is a red line we already agreed on. The second is another project with another budget."
Then two more lines. The business framing. "Anchor & Helm's first payment cycle runs 1.6 times the industry average. -30% pulls it back near the average, and at the board that is a 'catching up with the industry' story, and it holds. -50% is a 'crushing the industry' story, and delivering it costs a red line." The risk framing. "The baseline itself is not clean. The core system's status field does not match actual progress, and the MVP already exposed that. I would write in that the baseline is whatever discovery's reconciliation produces. Promising -50% now means signing a number on a foundation nobody has checked."
Grant looks at the breakdown for a while. "Write 30. But once the reconciliation is done, you come tell me whether that number was conservative or reckless." Done. Not once in that negotiation did anyone say "I think." Every step stood on MVP evidence.
Round two, the thirty seconds of silence over the exit conditions.
In the last fifteen minutes of the agenda you read out the draft exit clause. "When two consecutive evaluation cycles miss the threshold and no workable path to improvement exists, either side may propose termination. When the business side's promised data access or staffing goes unmet two weeks running, a resource reassessment is triggered, in three tiers. First it escalates to the sponsor weekly, then the project turns to awaiting inputs on the PMO register, and last your team's people are released to other projects."
The room goes quiet. Be ready for that quiet before it comes. Raising "under what conditions we break up" in a meeting where the goal was just agreed and the mood is good is like reading a divorce settlement at an engagement party. Kevin smooths it over. "Talking about splitting up before we have even started, is that not bad luck?"
You give the line you had prepared. "We write these two lines so that if it ever comes to that, the person who calls a stop does not have to be the villain. Without them, everyone can see the project is in trouble, but whoever says stop first owns the failure, so nobody says it and the project keeps burning money. With them, calling a stop is only executing the agreement."
Grant is silent a few seconds. "Put it in. I have approved too many projects that could not be stopped."
These two lines are harder to say out loud inside a company than outside. For a team from outside, calling a stop is a commercial move. For you it means admitting your own project failed, and it looks like undercutting Grant. You also do not hold the pause card. You are not a supplier, salaries get paid either way, and stopping reads as infighting. So the second half of the exit clause does not say who may pause. It says what triggers a resource reassessment. None of the three tiers requires you to call a stop. Missing inputs are the signal by themselves.
A few months later these two lines grow a pilot-level sibling, the kill criteria (Chapter 14), and in one launch incident they get executed by the book and save the relationship between the two sides. That is Chapter 18's story. For now one sentence is enough. The awkwardness of writing exit conditions lasts thirty seconds. The cost of not writing them is counted in quarters.
Round three, the one line that pays for the whole project.
In the business-side commitment cell you write, "Linda's team, 2 hours a week, for case annotation and rule confirmation, from discovery through one month after launch."
Kevin shakes his head. "Them marking a few for you on the side these past two weeks is fine. Putting it in the charter is another matter, that is a hard commitment. Her team carries the heaviest backlog in the department, and I cannot lock my tightest people onto this. How about two new hires working with you instead?"
You go back to the scoring sheet. "All three unsafe came out of 20 minutes with Linda. The three changes we made to the queue's ranking rules these two weeks all came from her team's annotations, and new hires would not have caught those three. 'Chase priority ≠ risk priority' is a judgment that lives nowhere in this company except inside her team's heads. Without those 2 hours the system learns the wrong priorities, and the review time wasted every week after launch runs far past 2 hours. Putting it in the charter only turns something already happening from 'helping out on the side' into a named role, and puts their hands on this system's steering wheel early."
Grant looks at Kevin. "We will find another way on the backlog. Give him the 2 hours." Kevin sets three conditions. No more than 2 hours a week, booked in advance, and not during the morning peak. All three go into the charter.
The compound interest on that line is invisible while you write it. It turns Linda from "the person nobody invited" into a person named in the agreement (Chapter 5 explains why that matters). The shadowing later, the eval co-build, all the way to the business side running this system on its own at handoff, the institutional source of that time is this one line. If the whole charter could keep one line, keep this one.
A week later the charter is signed. One page, seven elements, four signatures. The old ticket's chatbot acceptance wording went through a project approval change review, was voided and filed, and was replaced by the eval release mechanism. Kevin's dashboard went onto the "not this phase" list. Three "continue"s merged into one project.
Here is how the seven elements read on the page that got signed. The three cells actually fought over were the North Star, the business-side commitment, and the exit conditions. The other four moved fast on the agenda, filled in item by item off the template.
| # | Element | How the Anchor & Helm Charter Filled It |
|---|---|---|
| 1 | North Star outcome metric | First-touch handling time for auto exceptions, down 30%, with the baseline set by discovery's reconciled data |
| 2 | actual user and owner, by name | actual user Linda Marsh and her review team, owner Kevin Doyle (Director of Claims Operations), executive sponsor Grant Whitmore (COO) |
| 3 | Scope and Red Lines | This phase builds the auto exceptions action queue, covering missing documents / abnormal amount / disputed liability; this phase does not build the management dashboard, the non-auto lines of business, or routine claims; the red lines are no automated payout decisions, no automated outbound messages, no handling of identifiable customer information |
| 4 | Data boundary and access commitments | This phase uses auto exception claims data only, three items. The core system's exception fields, as a read-only de-identified view. The review team's Excel tracker, as a read-only export. Document emails and attachments, as read-only access. Data does not leave Anchor & Helm's environment, and name / ID number / plate number / phone are replaced with placeholders at the extraction layer before they reach any model call, with the de-identification standard set by Victor Reyes. The approver is the head of the IT data team, countersigned by Kevin Doyle as the business data owner, with access committed within two weeks of signing; the security review is run by Victor Reyes and set for week 8 |
| 5 | Business-side commitment | Linda's team, 2 hours a week, for case annotation and rule confirmation, from discovery through one month after launch; booked in advance, not during the morning peak; the fulfillment rate reported monthly at Grant Whitmore's weekly |
| Your team's commitment and protection conditions | You and your team's engineers, by name, from discovery through the completion of handoff; countersigned by Owen Hartley, and pulling anyone goes through Grant Whitmore's weekly first | |
| 6 | Acceptance method | Launch release conditions. The eval spec both sides co-build is the authority, golden cases plus agreed thresholds, and a score over the line releases the launch; the releasers are Kevin Doyle and Victor Reyes, and the case count and thresholds become an attachment once written |
| 7 | Exit conditions | When two consecutive evaluation cycles miss the threshold and no workable path to improvement exists, either side may propose termination. When the business side's promised data access or staffing goes unmet two weeks running, a resource reassessment is triggered, in three tiers. Tier one, escalate to the sponsor weekly, where the sponsor decides between more input and less scope. Tier two, the project turns to "awaiting inputs" on the PMO register, with the reason column naming whose input is missing and what it is. Tier three, your team's people are released to other projects, with the release date and reason recorded openly in the weekly project report |
Failure Modes
1. The charter gets processed into a form. The PMO says the company has a project approval template, just fill the charter into it. So one page becomes 27 fields in the requirements ticket system, each field with its own filling convention, and once it clears approval nobody opens it again. The language shifts from conversation to form-filling, and "Linda's team, 2 hours a week, not during the morning peak" becomes "business department cooperation, high." Form-filling language needs nobody to change a single cell, so nobody leaves fingerprints on it, and a signed form constrains nobody. The charter and the project approval form must be two documents. The approval form governs budget and process compliance, the charter governs the work and the expectations, and the charter stays one page forever, in a state where somebody can still mark it up in red pen.
2. The goal written as an activity list. The North Star cell reads "complete development of the exceptions system and run the launch training." Activities are controllable, outcomes carry risk. "Complete development" can always be delivered and "-30%" can fail, so both sides have a reason to write toward safety. You are afraid of carrying a metric, and the business-side handler is afraid of pledging one to his boss. But a charter written as an activity list is no charter. It accepts "work was done," nobody asks what changed, and only outcome metrics survive the boardroom (Chapter 1). The test is short. Read the goal out loud and ask, "Could this sentence fail to come true?" A goal that cannot fail is not a goal.
3. The business-side commitment clause left blank. Your team's commitment runs three pages, and the business-side commitment cell reads "will provide necessary support."
The reasons for leaving it blank come even more easily inside a company. We are all one family, it feels awkward to put it in writing. Asking for resources sounds like admitting you cannot handle it. And the business side assumes the Digital Center is a resource the company assigned to them, that doing the work is your job to begin with, and that sentence is literally true and harder to argue with than "we are paying for this." But the raw material of an AI system, the data, the tacit knowledge (the experience nobody ever wrote down), the trial feedback, all sits with the business side, and a project with zero business-side input cannot even assemble its raw material. Handoff is the worse problem. An organization that never put anything in cannot take over operating it (Chapter 22). There is only one road for the counterargument. Do not argue over whose job it is, go back to the raw material. The three unsafe were marked by Linda, not by you. Block's discipline is at its sharpest here. What you want and what you will pay get negotiated in the same room, and if you cannot agree you do not sign. A charter with no business-side commitment in it is a one-sided love letter.
4. Skipping the charter. "Kevin and I get along well, all this red tape would only put distance between us." That sentence has the causation backwards. A good relationship is the only window in which the unpleasant things can be said plainly. Talking about exit conditions now is preparation. Talking about them after something goes wrong is assigning blame. Agreements do not spend relationship capital. Vagueness does. If Kevin only discovers six months from now that the dashboard was out of scope, the trust lost in that moment is more than any haggling at the negotiating table would have cost.
Vendor View
The vendor side has a procurement contract. Charter and contract must be two documents. The contract governs the commercial and legal terms, the charter governs the work and the expectations, and the charter stays one page forever, markable in red pen. Hand the charter to the contract process and its language shifts from conversation to defense, and the co-build relationship dies before anyone signs.
Next Monday
- Find the project on your desk that has already started with no charter, and ask three key roles each to write one sentence on "what success looks like for this project." Three different sentences back is all the reason you need to call the contracting meeting.
- Draft a one-page charter with Template 4, forcing all seven elements to be filled. The cells you cannot fill, usually the business-side commitment and the exit conditions, are the project's largest exposed surface right now.
- Book the 60-minute meeting. Make sure the person who decides is in the room, and make sure you open with evidence (the scored MVP, data samples) rather than a vision.
- Write it up and send it within 48 hours of the meeting. Watch who changes what. Every change is an expectation gap blowing up early, the cheap kind.
Want an agent to get you started? In the repo you set up following Start Here, paste this to your coding agent:
In the repo/ directory of the the-last-mile repository, help me with the Chapter 4 Next Monday actions. Copy
templates/deployment-charter/charter.md into the working directory I name, and ask me the seven elements one by one.
Fill in what I answer and nothing else. Leave any cell I cannot answer blank and mark it [still to discuss]. Those
cells are this project's largest exposed surface right now, so do not fill them in for me. If I paste in de-identified
meeting minutes, follow prompt-minutes-to-charter.md to produce a draft first, then list the "still to discuss" items.
The three key roles' sentences on "what success looks like" are mine to collect, not yours to write.
If any command errors, stop and show me the output.
Chapter Kit
- Judgment frameworks. The seven elements of the Deployment Charter (North Star outcome metric / actual user and owner by name / scope and red lines / data boundary / business-side commitment by name / acceptance tied to the eval / two-way exit conditions); the 60-minute contracting meeting agenda
- Templates. Template 4, Deployment Charter and Pre-mortem Memo, the fillable seven-element template plus the full contracting meeting agenda (4.1 and 4.2)
- Key judgments
- "Vague authorization is more dangerous than none."
- "A charter's use is to make the expectation gap blow up at the cheapest moment."
- "A charter with no business-side commitment in it is a one-sided love letter."
- "Exit conditions mean the person who calls a stop does not have to be the villain."