When an AI project dies in month six, the post-mortem usually names a technical cause — the data was worse than expected, the accuracy plateaued, the integration slipped. Pull the thread, though, and there's almost always a person behind the technical cause: the department head who never granted real data access because they never really agreed to the project. The compliance lead who surfaced a blocking concern in month five that they'd have raised in week one if anyone had asked. The team whose workflow the AI changes, who were 'informed' but never consulted, and who quietly route around the tool at rollout. None of this is exotic organizational dysfunction — it's the predictable result of treating alignment as an email thread. The fix is a small set of structured conversations, run early, that surface who is actually on board, what everyone actually expects, and what was actually agreed. Here's the structure.
Map stakeholders by decision power and exposure
The standard stakeholder map sorts people by interest and influence, which for AI projects misses the axis that matters: exposure — how much this system changes their work, their numbers or their risk. Cross decision power with exposure and you get four groups, each needing a different kind of alignment. The quadrant that sinks AI projects is the one most maps ignore: high exposure, low power. The claims handlers, the analysts, the AP clerks — the people whose daily work the system changes. They can't approve or kill the project on paper, but they decide its fate at rollout: adoption is theirs to give, and quiet workarounds are theirs to invent. Aligning them late, with training sessions after the build, is how technically successful projects fail commercially.
| Group | Who they typically are | What alignment means for them |
|---|---|---|
| High power, high exposure | The sponsoring department head; the budget owner whose metric this moves | Deep involvement: they co-own the scope, the metric range and the sign-off |
| High power, low exposure | Adjacent executives, legal/compliance leads, IT security | Early, brief, explicit consultation — one structured conversation in week one beats their veto in month five |
| Low power, high exposure | The operators whose workflow changes; the team lead who manages them | Consulted before design, shown demos during, given a real channel to flag what won't work — they're where requirements and adoption both live |
| Low power, low exposure | Everyone else with an opinion | Informed on a cadence; protected from having to attend meetings |
The expectation-setting session: have the error conversation first
Before the build starts, get the high-power and high-exposure stakeholders into one session with a single agenda: calibrate what this system will actually be like to live with. Most AI project disappointment isn't about outcomes — it's about the gap between outcomes and unstated expectations, and this session exists to make the expectations stated. Three conversations belong in it, and the second one is the one teams skip. First, what AI can't do yet: concretely, for this use case — where it will be genuinely good, where it will be mediocre, what's out of reach this year regardless of vendor claims. Second, the error tolerance conversation: the system will be wrong some percent of the time; walk through what a wrong answer looks like here, what it costs, and what error rate each stakeholder can actually live with. Do this with real examples — 'here's a case; the system codes it wrong; finance catches it at month-end; that happens N times per month at the accuracy we're targeting.' It is remarkable how often the sponsoring executive and the operating team discover, in this conversation, that they have different answers by an order of magnitude. Third, what happens when it's wrong: the escalation behavior, the human override, the rollback — so nobody's mental model is 'it just works.' The session's output is one page: expected performance range, agreed error tolerance, failure behavior, signed by attendees. That page prevents more month-six mess than any technical decision on the project.
Cadence design: demo-driven, not slide-driven
A slide-driven cadence — weekly decks of progress, metrics and RAG statuses — feels like governance and functions as concealment: misalignment survives slides comfortably, because slides are abstractions and everyone nods at abstractions. The alternative is a demo-driven cadence: at every checkpoint, stakeholders watch the actual system behave on real (or realistic) cases, including cases where it fails. A stakeholder who watches the system misclassify an invoice will tell you on the spot whether that error is tolerable — information you cannot extract from a slide that says 'accuracy: 91%'. Show failures deliberately: curate two or three of the current worst cases into every demo. It builds calibration and, counterintuitively, trust — stakeholders who've watched the system be wrong in week four don't panic at the production incident in month four; they recognize it.
- Every checkpoint includes live behavior on real cases — no demo, no meeting; if there's nothing new to show, send a written update instead and save the room.
- Curate failures in: 2-3 current worst cases per demo, with what's being done about each. Demos of cherry-picked successes are slide decks with extra steps.
- Keep one artifact current per checkpoint: the metric-vs-range chart from the expectation session, so 'where are we against what we agreed' is always one glance.
- Cadence: high-exposure operators every week or two; the decision group every three or four weeks; everyone else gets the written note.
- End every demo with the same question to the room: 'what did you see that you couldn't live with in production?' — then write the answers into the requirements or the risk register that day.
Handling the skeptic honestly
Nearly every AI project has one: the senior person who thinks this is hype, or a threat to their team, or the third attempt at something that failed twice already. The instinct is to route around them — keep them off the invite list, manage them through their boss. It fails predictably: the skeptic's objection doesn't disappear, it waits, and it lands in month six with interest, often in front of the steering committee. The honest playbook works better and is simpler. Bring them in early and privately, and ask for their actual objection — often it's a specific, informed concern wearing a cynical coat ('the 2019 project died because the data was garbage, and nobody has fixed the data'). Put their concerns in the risk register verbatim, with their name if they'll allow it — being taken seriously converts more skeptics than being presented to. Then agree, in writing, what evidence would change their mind: which metric at which threshold, demonstrated on which cases. That converts the disagreement from a status war into a testable claim, which is exactly the terrain where an AI project can win. And if the evidence goes their way — if the data really is too broken — the skeptic just saved you five months, which is worth saying out loud. A converted skeptic is the most credible advocate the project will ever have, precisely because everyone knows they weren't cheap to convince.
The sign-off that actually binds
Most AI project sign-offs are ceremonial: a deck is presented, heads nod, someone writes 'approved' in the minutes. Ceremonial approval binds nobody, which everyone discovers the first time results disappoint and the room fills with people who 'always had concerns.' A binding sign-off is a short document, not a meeting outcome, and it commits both directions — the approvers to specific expectations, and the project to specific deliverables. It also names its own re-opening conditions: the things that legitimately trigger renegotiation (the kill-line being crossed, a scope change, a constraint appearing), so that renegotiation is a defined process rather than an ambush. Aiporate builds this document into its intake for exactly this reason — the outline and scoping work only pays off if what was agreed is written where nobody can unremember it.
- The scope, by reference: the scoping document version number being approved — not a summary of it, the document itself.
- The metric range: ship line, kill line, and who decides in between — signed here so results season isn't negotiation season.
- The error tolerance page from the expectation-setting session, attached verbatim.
- Each signer's committed contribution, named: 'X grants read access to the claims database by the 15th; Y's team provides 2 hours/week of case review.' A sign-off without contributions is an audience, not an agreement.
- Re-opening conditions: what events trigger renegotiation, and the changelog rule — material changes go back to these signers, nobody else.
