AI project requests: what to ask first

An AI project request does not need an intake process of its own. It needs the ordinary one, without the exemption the word "AI" tends to earn, plus four questions that most software requests never force you to ask. This essay is about those four, and about what to do when nobody can answer them yet.

The request is familiar by now. "Can we use an LLM for support tickets?" "Leadership wants a copilot in the product by Q2." Each sounds urgent, usually comes from someone senior, and does not say what should be different afterwards.

Why AI requests arrive vaguer than most

Most requests start from something that hurts: a report that takes two days, a customer who cannot sign in. An AI request usually starts from the other end. Someone has seen a capability in a demo and is working backwards to a use for it.

Three things then keep it vague. The sponsor is senior and the pressure is about not falling behind, so nobody asks the clarifying question. A prototype is cheap: something that works on ten hand-picked examples can exist by Friday, and it looks like most of the job. And nobody has a feel for the size, because the code is small and the real work sits in the data, in judging the output, and in the cases where it is wrong.

That is how a team ends up months into a pilot that nobody committed to and nobody can close.

The ordinary floor still applies

Before any special questions, ask the one every request has to answer: after this is done, what is true that is not true today? "Use an LLM for support tickets" cannot answer it. It names a technology and a part of the business, which makes it a topic, not a request.

"Support agents get a drafted first reply for password and billing tickets, and edit it before sending" can, and it no longer mentions a model. A model or a vendor named in a request is a proposed solution. What should change has to be stated without it.

Send the question back to the sponsor instead of filling the gap in yourself, and grant no exemption from intake. Tech debt gets the ordinary process for the same reason: the work draws on the same teams as everything else, so it enters by the same bar at the door and competes for the same capacity.

The four extra questions

Once the request states a change, four more things have to be established before a team is committed.

1. Which decision or task changes, and for whom. Name the person and the moment: "a support agent, when writing the first reply", not "the support team". Then say what the output does there: draft something a person edits, rank or flag items for a person to check, or act with nobody in between. Those are three different projects. If nobody's working day changes, there is no project yet.

2. What data it needs, and who owns that data. Where it lives, who can grant access, whether you may use it for this purpose, and whether it is any good. The owner is rarely the team being asked to build, which makes this a dependency on someone you have no authority over: established when that person agrees, not when their team's name is written down. Data leaving the company for a vendor's API adds security, legal and privacy review to the list.

3. How you will judge whether the output is good enough. A conventional feature does what the specification says or it does not. Output from a model is right some of the time, and "some" has to be pinned down before work starts. Write down the real examples it will be judged on, the one named person who judges them, and the bar. "On 200 real tickets from last month, a support lead rates at least 150 drafts as sendable with light edits" is a bar, and the numbers are yours to choose. Set it before the demo, because afterwards everyone remembers the three best examples.

4. What happens when it is wrong. It will be, sometimes, and that is its nature, not a defect to fix later. So decide who sees a wrong output first, an employee or a customer; how they would know; how it is corrected; and what the fallback is when the service is down. This answer shapes the design more than the choice of model does: a draft a person edits before sending is a different product from a reply sent automatically. It is the same line that decides where AI belongs in a planning tool: whether a person can check the output in seconds and undo it cheaply.

A discovery with an end date, not an open pilot

Often the honest answer to the second and third questions is "we do not know yet". What usually follows is a pilot with no question, no end date and no owner, which runs for a quarter and ends in a demo.

The alternative is a discovery, which is a decision with a deadline. For the support example:

• Goal: find out whether drafted replies are good enough to build for the two commonest ticket types.
• Questions: whether support operations can supply last month's tickets with personal data removed; how many of 200 drafts a support lead rates as sendable; whether an agent would spot a bad one.
• Time-box: eight person-days.
• Target date: three weeks from today.

On that date the findings are written down and one of four decisions is taken: plan the work, re-open the decision with what was learned, park it, or decline it. Not going ahead is a good result too: "the ticket data cannot be used until the contract is renegotiated" is an answer, a park with its condition already written, and it cost eight days.

What to record at commitment

When the answers exist, commit as you would commit anything, with the six things a decision-ready demand contains. The four answers add specifics.

• The outcome, written as the changed task and the person it changes for, not as "AI in support".
• The bar: the example set, the judge and the threshold.
• The data dependency, with the owner's name, what they agreed to and by when.
• The failure path: who catches a wrong output, and the fallback.
• A stop condition. "If the bar is not met on the example set by week six, this comes back for a decision." Kill criteria are easiest to write on the day you commit, and a pilot that is going quite well can go quite well indefinitely.
• An owner afterwards. The bar has to be checked again whenever the prompt, the data or the model changes, and that is standing capacity on some team's line.

If a board date arrives before the answers do, commit early and on the record: why it is early, what is still missing, who accepts the risk, and what would change the decision.

A checklist to copy

• Does the request say what will be different afterwards, without naming a model or a vendor?
• Who is affected, or why does it matter now?
• Whose task or decision changes, and at which moment?
• Does the output draft, rank or act, and who sees it first?
• What data does it need, who owns it, and have they agreed?
• Does data leave the company, and have security, legal and privacy been asked?
• Which real examples will it be judged on, who judges, and what is the bar?
• Who sees a wrong output first, and what is the fallback?
• If anything is unknown: a discovery with a goal, questions, a time-box and a target date.
• At commitment: the bar, the data dependency, the failure path, a stop condition, an owner after launch.

What DeliverySheet does and does not do here

DeliverySheet has no AI-specific fields: no model or vendor picker, no evaluation tooling, nothing that tests a model or monitors a deployed one. A request for an AI project or use case goes through the same seven stages as every other demand: Capture, Shape, Decide, Plan, Commit, Deliver, Learn.

The four answers go in as text you write, in fields every demand has: the problem, the desired outcome and the unknowns in Shape; the data owner as a dependency, the choices still open as decisions, and the ways it can be wrong as risks in Plan.

Some of it is enforced. Capture requires a stated need plus either an impact or a trigger. Discovery is one of the outcomes at Decide. It cannot be opened without a goal and a target date, it cannot be concluded without findings and one of the four decisions listed earlier, and a demand still in discovery cannot be committed. A dependency marked at risk or blocked, a decision still marked proposed, or an unresolved high or critical risk keeps a demand from reading as ready to commit, and committing it anyway, on any path except fast-track, requires the four-field exception. A dependency left at identified or requested does not block; marking it at risk while the data owner has not agreed is your call.

There are no integrations with Jira, Linear or Slack, and no notifications: a discovery past its target date shows on the Overview as a decision overdue, and the only email about your work is an optional weekly summary to the workspace owner. The AI inside the product drafts and suggests. It decides nothing. To see whether a request states the need, the impact and why now, paste it into the free request check. It applies the Capture rule and nothing more: it does not check whether the need is phrased as a model or a vendor.