Placeholder draft — clear and finalise before launch.
Most AI pilots are scoped in the wrong order. They start with the model and back into the problem. The ones that work start with a falsifiable definition of done and back into the smallest system that can reach it.
Here is the checklist I run through before I agree to a build. It isn’t clever. It’s just the set of questions that, when skipped, reliably come back to bite the project later.
Before the first sprint
- What does “done” look like, in one sentence the person paying would sign? If you can’t get this, stop. Everything downstream inherits the ambiguity.
- Who is the named owner? Not the sponsor. The person whose week gets harder if it breaks.
- What’s the baseline? What happens today, by hand, and how good is it? You can’t claim improvement without it.
- How will we measure it every day? If the evaluation is a manual quarterly review, it isn’t an evaluation.
The questions that get skipped
These are the uncomfortable ones, which is exactly why they matter.
- Where does the data actually live, and who owns access? This is usually where timelines double.
- What’s the compliance and identity story? Decide it before the architecture, not after.
- What’s the failure mode? When the system is wrong — and it will be — what happens?
- Who maintains this in twelve months? If the answer is “the pilot team”, it isn’t going to production.
Why a checklist beats a framework
Frameworks make you feel organised. Checklists make you answer questions. The value here isn’t the twelve items — it’s the discipline of refusing to start until each one has a real answer, written down, owned by someone.