A business leader asks the data team for a model that sets the right price for a product. The team builds a model that finds the price that sells the most items, delivers it on schedule, and confirms that it performs exactly as designed. The leader wants the price that earns the greatest profit margin, so the model answers a question that nobody needed answered.
That example comes from RAND's study of failed AI projects, which draws on interviews with experienced data scientists and engineers, and it shows the pattern at its simplest. The request means one thing to the person who makes it and another to the person who builds it, and nobody finds out until the work is finished. A short written scope, agreed in one working session before any data work begins, closes that gap. It also produces the list of data requirements that every later decision depends on.
In Brief
- A written AI scope is a one-page statement, agreed by the business owner and the technical lead, that fixes what the model decides, who uses its output, and how success is measured.
- RAND's research ranks miscommunication about a project's purpose above every other cause of AI project failure.
- The scope has six parts: the decision, the use of the output, the cost of a wrong answer, the success metric, whether AI is needed at all, and the time commitment.
- The scoping session follows a set order and ends with a signed one-page scope, which the team reviews whenever priorities or data change.
- Each part implies data requirements, and the team assesses the data against those requirements.
- A scope is ready when the business owner and the technical lead, asked separately, describe the same model.
Why AI Scoping Comes Before Data Work
Data work is the most visible and most expensive part of an AI initiative, which is where teams naturally start. Cleaning, integrating, and labeling data all feel like progress, and all of them pay off only if the model they feed answers the right question.
RAND interviewed 65 experienced data scientists and engineers about why AI projects fail, and its authors conclude that misunderstandings and miscommunications about the intent and purpose of a project cause more AI projects to fail than any other factor. The study's recommendation for business leaders is specific. They need to help technical staff understand what the project must achieve and how the finished product will be used, because they cannot assume the engineering team will discover on its own which design choices make the product useful in its business context.
A scope is the written form of that explanation. It is a statement of the problem the model solves, short enough to fit on one page and specific enough that two people reading it separately would describe the same model. Without one, teams spend a data budget against a problem nobody has defined, which is the precondition failure that sits upstream of every data readiness decision.
Who Needs to Attend an AI Scoping Session
A scope written by one person is a guess. The session works because four perspectives meet in the same room, and each one holds information that the others lack.
- The business owner is accountable for the result and can say what the business actually needs from the model.
- The technical lead is the data scientist or machine learning engineer who will build the model, translates the request into what can be built, and flags what cannot.
- The person who acts on the output is the dispatcher, analyst, or agent whose daily work changes when the model gives an answer, and who knows how the output would really be used.
- The data owner knows where the relevant data lives and who maintains it, and can say early whether the data exists at all.
RAND notes that leaders can do without deep technical knowledge of AI themselves as long as they employ staff with a strong data science background when selecting objectives for AI product teams. That is why the technical lead sits in the room while the objective is still being shaped.
The aim is a single working session. When the group cannot agree on the decision or the metric during the session, that disagreement is the most useful finding it produces, because it would otherwise surface much later and at a much higher cost.
The Six Parts of a Written AI Scope
A written scope has six parts. Each part has an answer of a few sentences in plain business language, and a part that nobody can answer marks the work that remains before data work should begin.
The Decision the Model Informs
The first part names the specific decision that changes because the model exists. A usable statement sounds like "release a shipment as planned or hold it for document review", and an unusable one sounds like "improve logistics performance". The decision needs a moment when it is made and a person who makes it, because a model without a named decision has no job to do.
The opening pricing example shows why this part comes first. A request for "a model that sets the price" hides a choice between maximizing volume and maximizing margin, and naming the decision forces that choice into the open before anyone builds anything.
How the Output Gets Used
The second part describes where the model's output appears, who sees it, what they do differently because of it, and what happens when they ignore it. RAND places this on the business leader, who needs to explain how the completed product will be used and cannot assume the engineering team will work it out.
This part also states the value pathway, which is the route by which the output turns into higher revenue or lower expense. A May 2026 MIT Sloan article on research from its Center for Information Systems Research names launching projects without clear value pathways as one of five common mistakes in AI initiatives. A model whose output reaches nobody who can act on it has no pathway, however accurate it is.
The Cost of a Wrong Answer
Every model gives wrong answers some of the time, because AI algorithms are inherently probabilistic. RAND's interviewees point to the inflated expectations that senior leaders hold about what AI can achieve, often driven by hype, as a recurring cause of failure. The third part states what a wrong answer costs in each direction. A model can say yes when the answer is no, or no when the answer is yes, and the two errors rarely cost the same.
Writing both costs down in business terms decides how the model is tuned and which success metric fits. It also gives the person who acts on the output an honest picture of how often the model is expected to be wrong, which protects trust in the model on the first day it makes a visible mistake.
The Success Metric in Business and Model Terms
The fourth part defines success twice, once in the language of the business and once in the language of the model. RAND describes failed projects in which business leadership did not realize that the metrics measuring the success of the AI model did not represent the metrics of success for its intended purpose, and the opening pricing example is the plain case, where items sold stands in for profit margin.
The business owner writes the first definition, such as fewer shipments held up at the border each month. The technical lead writes the second, naming the model measurement that approximates it, and states the conditions under which the two diverge. Both people sign both lines, so a good model score is never reported as business success without the link between the two being visible.
Whether the Problem Needs AI at All
The fifth part tests whether a simpler tool already answers the decision. RAND reports interviewees who received instructions to apply AI to datasets with a handful of dominant patterns that a few if-then rules could have captured quickly.
If a rule or a standing report answers the decision acceptably, the team builds the rule and stops there. If the rule answers it only partly, the rule becomes the baseline that any model must beat to justify its cost, and for problems whose data is still being captured it can serve as the first stage of a staged build, an approach in which a rule runs first and a trained model replaces it as the data accumulates.
The Time Commitment for an AI Problem
The sixth part states how long the organization commits to the problem and who funds it for that period. RAND reports that leaders underestimate the time and cost of acquiring, cleaning, and exploring data, and that shifting priorities lead to projects being abandoned before they can show results. Its recommendation is that leaders be prepared to commit each product team to a specific problem for at least a year, and that a problem unworthy of that commitment is probably not worth pursuing at all.
A problem whose data has not been captured yet takes longer to reach a trained model, and the written commitment is what keeps that effort from being cut short when priorities shift.
How to Run an AI Scoping Session
A scoping session has three stages, and the preparation and the sign-off matter as much as the meeting itself.
What to Prepare Before the Session
Preparation is what makes one working session enough.
- Send the original request, in the words it was first made, to all four attendees.
- Ask each attendee to write down, separately, the decision the model should change and how they expect its output to be used. The differences between those answers become the agenda.
- Ask the data owner to list the systems that might hold the data the decision depends on, without judging its quality.
The Order to Work Through the Six Parts
The parts build on each other, so the order matters.
- The decision comes first, because every other part depends on it.
- The use of the output comes second, because it shows whether the decision can actually change.
- The cost of a wrong answer comes third, because it sets what the success metric must protect.
- The success metric comes fourth, because it can only be chosen sensibly once the cost is in view.
- Whether AI is needed comes fifth, because it can only be judged once the decision, the use, and the metric are clear.
- The time commitment comes last, because it depends on everything above, including how much data the problem needs.
After each part, the technical lead restates the answer in their own words and the business owner confirms or corrects it. A misunderstanding corrected in the room costs little, and the same misunderstanding found during the build costs far more. When the two versions of an answer differ, the group records both and resolves the difference before moving on, with the business owner holding the final word on what the business needs and the technical lead holding the final word on what can be built.
Signing Off the Scope
One attendee writes up the scope on the template below soon after the session, and the business owner and the technical lead each confirm it in writing. The signed scope then lives where the build team works, and it becomes the reference for every later question about what the model is for.
A One-Page AI Scope Template
The template holds the six parts, the data requirements that follow from them, and the sign-off.
- Decision. The decision that changes, who makes it, and when.
- Use of the output. Where the output appears, who sees it, what they do differently, and what happens if they ignore it.
- Cost of a wrong answer. The cost if the model says yes and is wrong, the cost if it says no and is wrong, and which one is worse.
- Success metric. The business definition, the model measurement that approximates it, and the conditions under which the two diverge.
- Simple alternative. The rule or report tried or ruled out, and the baseline the model must beat.
- Time commitment. How long the organization commits, who funds it, and the dates when the scope is reviewed.
- Data requirements. The inputs, the outcome records, the delivery needs, the quality priorities, and the history required.
- Sign-off. The business owner, the technical lead, and the date.
Turning an AI Scope Into Data Requirements
Once the six parts are written, each one implies something about the data. Working through them in order produces the list of requirements that a data team can act on.
- The decision defines the inputs. The model can only use facts that are available at the moment the decision is made, so the scope lists what the decision maker could know at that point.
- The success metric defines the outcome records. Measuring success requires a record of what actually happened after each decision, such as whether a shipment was delayed.
- The use of the output defines freshness and delivery. It sets how quickly the output must reach the person and how current the inputs must be for the output to be useful.
- The cost of a wrong answer defines where data quality matters most. Errors in the fields that drive the costliest mistakes matter more than errors elsewhere.
- The time commitment defines how much history is available. It also shows how much must still be collected.
The team assesses the data against that list. The case for assessing readiness against a specific initiative depends on someone having stated what the initiative needs, and the scope is the document that states it. The assessment itself starts with the six-question diagnostic that separates data quality from data availability. A quality finding leads to scoping a data quality fix to the use case, and an availability finding leads to a staged build around new data capture.
A Worked Example of Scoping a Customs Delay Model
A logistics company that appears in the quality versus availability diagnostic and in the staged build example shows the whole sequence. Its operations leadership wants AI that forecasts which shipments will face customs delays before they are dispatched, and the first request in the room is "a model that predicts customs delays". The scoping session turns that request into six answers.
- The decision. Whether the customs desk releases a shipment as planned or holds it for extra document review before it leaves. The customs desk makes the decision at dispatch.
- The use of the output. The model's score appears next to each shipment in the dispatch queue, and the customs desk reviews flagged shipments before they go out. The dispatch coordinator points out that a flag with no reason attached will be ignored, so the scope requires each flag to show the shipment attribute that drove it.
- The cost of a wrong answer. A missed delay leaves a shipment stuck at the border with a customer waiting. A false flag sends a shipment to extra review, which costs desk time and can delay a shipment that would have cleared. The group decides that missed delays hurt more, so the team tunes the model to flag generously, with desk capacity as the limit.
- The success metric. The business owner defines success as fewer shipments held up at customs each month among those dispatched. The technical lead names the model measurement, how well flagged shipments match the delayed ones, and records that it approximates the business outcome only while the desk has the capacity to review every flag.
- Whether AI is needed. A rule that flags routes with a history of delays exists today. The group agrees that this rule is the baseline the model must beat.
- The time commitment. The group commits to the problem for at least a year, because the model needs examples of delayed shipments to learn from, and those examples accumulate at the pace shipments are delayed.
Applying the requirements list to this scope gives the data team five requirements.
- Inputs before dispatch. Route, shipment volumes, and the customs documentation that accompanies each shipment.
- Outcome records. Whether each shipment was delayed at customs.
- Delivery. A score and a reason visible in the dispatch queue before the shipment leaves.
- Quality priorities. The customs documentation field and the delay outcome matter most, because a wrong or missing value in either one corrupts the examples the model learns from.
- History. Enough delayed-shipment examples to train and evaluate a model, collected over the committed period.
Running the diagnostic against these requirements gives a clear result. The company holds years of clean data on volumes, routes, and delivery times, and it holds no record of customs documentation, because that information was never required before. The data does not exist, which makes this an availability-bottlenecked problem and points to a staged build around new data capture.
The scope does two jobs at once. It stops the team from building a general delay predictor that nobody at dispatch would use, and it exposes the data gap before anyone spends money on cleaning data that was never the constraint.
Keeping an AI Scope Current
A scope that the team writes once and files loses its value, because the problem, the priorities, and the data all change after the session, so four events call for a review.
- Each gate in a staged build. A gate is the checkpoint where the team decides whether to move to the next stage, and the team rereads the scope at each one to confirm that the decision, the use of the output, and the success metric still hold.
- A shift in priorities. RAND reports that rapidly shifting priorities lead to projects being discarded before they can show results, and to finished projects being ignored because they no longer address what leadership considers most important. A written scope makes the shift visible, because the business owner must either update the scope and the commitment or end the project on purpose.
- A change in what the data allows. A missing field or an unreliable source discovered during the build is a reason to revise the scope, and a scope revised in the open keeps both sides describing the same model.
- A sponsor who is hard to reach. RAND describes failed projects in which business leadership does not make itself available to discuss whether the technical team's choices match its intent, and it advises technical teams to keep business stakeholders informed of progress and interim discoveries. The scope names the business owner as the person who answers, and its review dates are calendar commitments for that person.
Signs an AI Scope Is Not Ready
Any one of the following means the session is not finished, and data spending should wait.
- The business owner and the technical lead describe the decision differently when asked separately.
- The success metric exists only as a model measurement, with no business outcome attached to it.
- Nobody who acts on the output has been consulted.
- Nobody can say what a wrong answer costs in either direction.
- A simple rule has been neither tried nor ruled out.
- The project exists because a technology is available, and the team searches for a problem to fit it.
- The commitment ends before the data collection does.
The simplest final check is to ask the business owner and the technical lead to describe the model independently, in writing. Matching descriptions mean the scope is ready, and differences mark exactly where the next conversation should happen.
Key Takeaways
- Hold the scoping session before any data cleaning, integration, or labeling budget is committed.
- Put the business owner, the technical lead, the person who acts on the output, and the data owner in the same room.
- Prepare in writing, work through the six parts in order, and sign off a one-page scope.
- Build the simple rule first when one answers the decision, and make the model beat it.
- Derive the data requirements from the scope, then run the quality versus availability diagnostic against them.
- Review the scope at every gate and whenever priorities or data change.