Most small machine-learning and automation projects do not fail because the model was weak. They fail in the first two weeks, when a room full of reasonable people produce a scoping document that lists thirty things the AI system “should” do and no indication of which ones are real. Someone wants explanations for every prediction, someone wants a chat interface, someone wants it to run offline, and someone else mentions, almost in passing, that customer data cannot leave the country. All four requests end up in the same bullet list, and the project spends months trying to satisfy them equally.
This explainer is about a plainer way to scope an AI project: write the hard limits first, label everything else as a wish, and let the wishes break ties only after the limits are met. It sounds obvious. In practice almost nobody does it, and the difference shows up in how fast a team agrees and how little they regret later.
Hard limits versus wishes, in plain terms
A hard limit is a condition that, if broken, makes the whole system unusable or unacceptable, no matter how good everything else looks. A wish is a quality that would make the system better but whose absence you could live with. That is the entire distinction. The difficulty is emotional, not intellectual: people feel that calling their request a “wish” means it will be ignored, so they insist it is a limit.
A useful test is the “launch day” question. Imagine the system goes live tomorrow. Which missing items would force you to switch it off, pull it back or apologise to someone? Those are limits. Which missing items would only prompt a note on the roadmap? Those are wishes.
Where the limits tend to hide in AI work
Limits in AI projects cluster in a few predictable places. None of them are glamorous, which is exactly why they get lost behind the exciting feature requests.
- Data boundaries. Where may the data live, who may see it, and for how long may it be kept? If an answer here is “only in-region” or “never copied into a vendor’s training pool”, that is a limit, full stop.
- Latency and availability. A fraud check that answers after the payment has cleared is not a slow fraud check; it is a useless one. Response-time ceilings are almost always limits.
- Human override. If a person must be able to stop or reverse the system’s output, that requirement shapes the architecture and cannot be bolted on later.
- Legal and contractual duties. Retention rules, audit trails and consent terms belong on the limits list even when nobody enjoys discussing them.
- Budget ceiling. A monthly spend above which the project gets cancelled is a limit. A “nice if cheaper” is a wish.
Where the wishes live
Wishes are the features people can describe vividly in a meeting: a friendly interface, multilingual output, one-click dashboards, a slightly higher accuracy figure on a benchmark that does not match your data, or support for a file format that three users have mentioned. They are not bad ideas. They are simply ideas that should queue behind the limits.
For example, an article on the same site about how machine learning feeds everyday business choices makes the point that decisions improve when the inputs are clear. Scoping works the same way: the clearer the ranking of needs, the better the decision about what to build first.
A four-column worksheet you can fill in an hour
You do not need software for this. A whiteboard or a shared document with four columns is enough.
- Requirement. One sentence, written so a stranger could test it.
- Who asked for it. A name or a role. Requirements nobody will own are usually wishes.
- What breaks if we miss it. Be concrete. “Users are unhappy” is a wish. “We breach a contract” is a limit.
- Verdict. Limit, wish, or park.
Push the group to keep the limits column to a handful of rows. If you cannot, the project is probably two projects. Splitting it early is cheaper than discovering it in month four.
Arguments you will hear, and how to answer them
- “Everything is critical.” Ask which item they would drop first if the launch date were halved. The answer reveals the true ranking.
- “We might need it later.” Then it is a wish today. Write it down under “later” and move on.
- “The competitor has it.” Interesting, but it only becomes a limit if your customers will leave without it. That is a claim you can check.
Why ranking beats scoring
Teams often respond to this idea by building a weighted scoring matrix with eleven criteria and decimal weights. Resist that. Scores give a false sense of precision, and they let a pile of small wishes outvote a single limit. A limit is a gate, not a weight: you either pass it or you do not. Only after every option passes every gate does it make sense to compare on wishes, and by then the field is usually down to two or three candidates, so the comparison is quick.
A short detour: the same habit in other fields
The habit is not special to software. People planning heart care across borders face the same pile of mixed preferences, and BestCardiacHospitals, a website that educates international patients on how to compare care options, describes a staged approach and notes that its material is educational, not medical advice. For a team scoping a project the takeaway is the same, just with different stakes: settle the non-negotiable conditions before you weigh the extras.
Keeping the list honest after kickoff
Once the limits are agreed, they need maintenance. Three light-touch practices help.
- Re-read the limits at every milestone. If a limit has quietly become irrelevant, delete it. If a wish has turned out to be decisive, promote it, and say why in writing.
- Test the limits first. Build the thinnest possible slice that proves each limit can be met before polishing any wish. A prototype that fails a hard limit is a cheap lesson.
- Show wishes as a ranked backlog. People accept a “not yet” far more easily when they can see where their item sits in the queue.
A related read from the archive, an explainer on how computers estimate future market moves, shows how much depends on the assumptions fed in at the start. Scoping is where those assumptions get chosen, so it is worth the hour.
What good looks like
A well-scoped AI project has a one-page summary that any newcomer can read in three minutes. It lists perhaps five limits, each with a reason attached, followed by a ranked wish list that everyone understands is negotiable. When a new request arrives, the team asks a single question: does this threaten a limit, or is it a wish? Most requests turn out to be wishes. That answer alone saves an astonishing number of meetings.
If your current scoping document runs to several pages with no ranking, try this tomorrow: print it, take a pen, and mark each line L or W. Then count the Ls. If there are more than seven, argue about them until there are fewer. You will have done the hardest part of the project before writing a line of code.