Most AI initiatives die between the idea and the first document. Someone says 'we should use AI for this' in a leadership meeting, everyone nods, and then the idea enters a discovery limbo that lasts a quarter — workshops, vendor calls, a slide deck nobody signs off on. The uncomfortable truth is that the first version of an AI project outline doesn't need a quarter. It needs one structured working session with the right five or six people in the room and an agenda that forces decisions instead of collecting opinions. The outline that comes out won't be complete — that's the point — but it will be concrete enough to test, staff and fund. Here's the agenda that produces it, and what the resulting document looks like.
Before the agenda: who has to be in the room
The session only works with a specific mix of people, and it breaks with the wrong ones. You need the person who owns the business problem (not a delegate — the person whose number improves if this works), someone who actually touches the data the project would run on, one person with real AI delivery experience, and the person who can approve a budget of the size this will need. Five or six people is the ceiling. Above that, the session becomes a stakeholder briefing, and briefings don't produce decisions. If you can't get these people into one room or one call for two hours, that itself is a finding: the project doesn't have the organizational pull to survive, and the outline session just told you so for free.
- The business problem owner — the person whose metric moves if this succeeds, in person, not represented.
- A hands-on data person — someone who can answer 'do we actually have that field, and is it populated' from memory or a live query.
- One person with AI delivery experience — internal if you have them, external if you don't; someone has to know what's feasible this year versus what's a demo.
- The budget holder — because a scope decision made without the person who funds it is a suggestion, not a decision.
- Optionally, one skeptic — the person most likely to object later, invited now, so their objection shapes the outline instead of killing it in month three.
The agenda: six steps in a fixed order
The order matters more than the timings. Each step constrains the next — the metric only makes sense once the problem is one sentence, the data check only makes sense against a metric, and the scope cut is only honest after the data check has delivered its bad news. Teams that reshuffle the agenda (usually to start with the exciting solution discussion) end up with an outline that describes a technology in search of a problem.
| Step | Time | The forcing question | Output |
|---|---|---|---|
| 1. Problem statement | 15 min | What decision or task is slow, expensive or error-prone today — in one sentence, no mention of AI? | One sentence everyone in the room accepts |
| 2. Success metric | 15 min | What number moves if this works, by how much, measured how? | One primary metric with a current baseline (or a note that the baseline is unknown — also a finding) |
| 3. Data reality check | 20 min | What data does this need, do we have it, who owns it, and how bad is it? | A rough inventory: exists / exists-but-dirty / doesn't exist, per data source |
| 4. Scope cut | 20 min | What is the smallest version that moves the metric — and what are we explicitly not doing? | An in-scope list of 3-5 items and an out-of-scope list at least as long |
| 5. Team shape | 10 min | What roles does this scope need, which exist internally, which don't? | A role list with a build/borrow gap marked against each |
| 6. Next 30 days | 10 min | What must be true in 30 days for this to continue — and who owns each item? | 3-5 named actions with owners and dates |
What the outline document contains
The session's output is a two-to-three page document, written up within 24 hours while the decisions are still warm. It is not a scoping document — that comes later and goes deeper. The outline exists to answer one question for everyone who reads it: is this worth the next 30 days of investigation? Its structure mirrors the agenda directly, which means writing it up is transcription, not authorship.
- Problem statement: the one sentence from step one, verbatim — resist the urge to improve it in private afterward.
- Success metric: the number, the baseline, the target, and how it will be measured. If the baseline is unknown, say so and make measuring it a 30-day action.
- Data reality: the inventory from step three, including the ugly parts. An outline that hides data problems is a scoping document's future archaeology dig.
- Scope: in-scope and out-of-scope lists side by side. The out-of-scope list is the document's most-referenced section six weeks from now.
- Team shape: the roles needed, marked as have / can-train / must-bring-in. No names yet — shapes, not people.
- Next 30 days: the named actions with owners. This section is what makes the document alive rather than archival.
- Open questions: everything the session couldn't answer, written down explicitly so nobody mistakes the outline for a plan.
Why speed here is a feature, not a risk
The instinct to slow down — more stakeholders, more analysis, more workshops — feels responsible but usually isn't. A fast outline is cheap to falsify: if the 30-day actions reveal that the data doesn't exist or the metric can't be measured, you've spent two hours and a month of part-time investigation to kill a bad project. A slow discovery process produces the opposite dynamic: by the time the same problems surface, six people have spent a quarter on the initiative, a deck has been presented upward, and the project has accumulated defenders whose credibility is attached to it continuing. Speed at the outline stage isn't recklessness — it's keeping the cost of being wrong low during the phase when being wrong is most likely. The discipline that makes the speed safe is the explicit open-questions section: a fast outline that admits what it doesn't know is rigorous; a fast outline that pretends completeness is just a slow failure with better velocity.
What still needs deeper discovery afterward
The session deliberately defers real investigation, and the outline should name what it deferred. Pretending the two-hour version answered everything is how outlines get mistaken for plans. Three areas almost always need genuine discovery in the following weeks, and they map directly onto the deeper documents that come next.
- Data quality in depth: the session established whether data exists; the 30-day window establishes whether it's usable — completeness, consistency, access permissions, and whether the fields mean what everyone assumed they mean. This feeds the data inventory document.
- Integration reality: where the AI output actually lands — which system, which workflow, whose screen — and what that integration costs. The session's scope cut assumed this is tractable; discovery verifies it.
- Behavioral requirements: what the system should do when it's uncertain or wrong. This needs structured stakeholder interviews, not a room vote, and it becomes the core of the requirements work.
- The full scoping document: the outline is the argument for doing that work; it is not a substitute for it.
