Start with one workflow that costs the most manual time. Prove value there before expanding.
Step 1: Name one decision or task, not “AI for the business”
Five steps to scope an AI project without overbuilding.
Every AI project that stays on budget and on time started with someone naming a single decision or task that costs real time or money today. Not “AI for customer service.” Something specific: who handles a support ticket first, or which invoices need a second look before payment.
If you cannot describe the problem in one sentence without the word “AI” in it, the project is not scoped yet. Write down the task in plain language first, then figure out where AI fits into solving it.
Write the number down and share it with everyone involved in the project, not just the person who signs off on the budget.
Step 2: Write down what happens today, step by step
Before anyone designs a system, someone on your team should be able to walk through exactly how the task gets done right now: who touches it, what tools they use, and how long each step takes. This is not a formal process map, just an honest account.
This step usually surfaces the real bottleneck, which is often not where anyone assumed. A project scoped around the assumed bottleneck instead of the actual one ends up solving the wrong problem well.
Step 3: Decide what “working” looks like, then sort every feature into two lists
Set a measurable definition of success before development begins: a percentage reduction in review time, a specific error rate, a number of hours saved per week. Vague goals like “make it smarter” give a development team nothing to aim at and nothing to know when to stop. Write the number down and share it with everyone involved in the project, not just the person who signs off on the budget.
This number also becomes the test for whether a feature belongs in the first version. If a feature does not move that number, it can wait, which is exactly why the next step matters as much as setting the target itself.
List every feature anyone has suggested, then sort it into two columns: required to solve the core problem, and would be useful someday. Almost every overbuilt project has a “nice to have” list that quietly became part of the requirements without anyone deciding that on purpose, usually because nobody wanted to say no to a reasonable-sounding idea in the room.
Be strict here. A feature that is genuinely useful but not required for the core task should wait for a second phase, not delay the first one. The teams that ship on time are rarely the ones with the fewest good ideas. They are the ones most willing to set good ideas aside until the core problem is solved.
Working on something similar?
Let's talk →Step 4: Build the smallest version that solves the real problem
The first version should do one thing reliably: handle the specific task you named in step one, for the most common cases, with a clear path for exceptions to go to a person. This is not a demo. It is a working system that a real employee uses on a real task.
Resist the pressure to cover every edge case before launch. Edge cases are far easier to identify once you have real usage data from the common cases.
This is usually where a business owner has to make a small leap of trust, agreeing to launch something that does not yet cover every situation. That trust pays off quickly once the first version is in front of real users and producing real feedback, instead of sitting in development for months chasing a version of complete that was never clearly defined.
Step 5: Set a checkpoint before adding anything else
Agree in advance on when the team will review results and decide what, if anything, gets added next. Without this checkpoint, “nice to have” features have a way of getting added anyway, one at a time, until the project has doubled in size without anyone approving that.
A scoped project has a natural stopping point. Reaching it and deciding what comes next deliberately is the difference between a system that grows on purpose and one that grows by accident.
Your pre-build scoping checklist
Before you move forward, confirm:
- You can describe the problem in one sentence without using the word AI.
- Someone has documented how the task is handled today, step by step.
- You have a measurable definition of what success looks like.
- Every requested feature is sorted into required or later.
- The first version covers the most common cases, not every edge case.
- A review checkpoint is scheduled before any new features get approved.
- Someone on your team, not just the developer, can explain what the first version will and will not do.
When you are ready to brief a development team, use our AI project specification template to lock scope before build.
