Guide
How to scope a first AI project so it can succeed
Updated
First projects fail for reasons that are visible at scoping. Four choices make the difference and all of them are made before any money is spent.
Pick a narrow, boring use case
Something high volume, low variance and low consequence, where you own the data and can measure the outcome. Not the most valuable problem; the most tractable one.
The purpose of a first project is to learn how your organisation does this, not to transform it. Choosing the hardest problem first is the most common scoping error.
Own the data
If the data lives in a system you cannot access, belongs to a partner, or carries a consent question, the project will stall in procurement or legal rather than in engineering.
Establish access and permission before scoping the work, not during it.
Name an owner who is not IT
Someone whose team's outcome depends on it working. A project owned only by the function delivering it will be delivered and not adopted.
That person should be the one deciding whether it succeeded, using the baseline you took at the start.
Scope the risk work in
Where outputs reach customers or decisions, the evaluation and governance work is part of the project, not an afterthought. A recognised risk framework is a reasonable place to start scoping it.
Doing this at the start costs a fraction of doing it after an incident, and it is the part most likely to be demanded later by a customer or an insurer.