Ask a team what it wants from AI and you usually hear a solution: a chatbot, an assistant, "something with GPT". The useful question comes earlier: which function should the system perform, and what kind of AI sits behind it?
That second question matters more than it looks. The AI type decides almost everything that follows: which risks are realistic, which success factors carry the project, and what the existing data has to deliver. A search system over internal policies fails differently from a model that flags transactions for review. Treat them the same and you plan for the wrong problems.
So we work in four steps: function and type, then risks, then success factors, then data requirements.
We break the use case into functions and assign exactly one AI type to each. Before any of that, one test: does a fixed rule already solve it? Price lists, catalogues, policies, checklists and text templates on structured data don't need AI. Sometimes the most honest answer is: "This doesn't need AI – not yet."
Three rules of thumb follow. A "recommendation" is usually forecast plus rule plus human. The most sensitive data in the project sets the legal and infrastructure requirements for all of it. And any output a person reads needs an evaluation set before go-live. Our default level of automation: the system suggests, a person decides.
We list six risks and rank them in a fixed order: first what would sink the pilot, then what would harm the people affected – customers, partners, employees – then the rest. Every risk is tied to a fact from the actual case, not to a generic AI fear.
Each risk gets two answers:
The test of a good risk list: turn risk number one around and you get success factor number one. And at most one risk is "consciously accepted" – with the reason written down.
Five success factors, strictly ranked. The ordering rule: first what blocks everything else, then what decides the benefit, last what is hardest to reverse.
In almost every project, number one is the same: the business unit releases its data together with the correct outcome. Without a labelled history or an approved evaluation set, nothing else can be measured – not accuracy, not benefit, not risk. After that typically come a clear human decision point, a measurable quality metric per category or field, and a correction loop that feeds back into the system.
Each factor gets a when (before launch, during the pilot, before scaling) and a who (the client, us, or jointly). Targets come only from the case itself; where the case is silent, we set them together with the client rather than inventing them.
We compare what exists today with what the use case needs, row by row, and give every gap an owner. "Not mentioned" is a valid answer for the current state – and often the most revealing one.
The last row is the one people forget: what we don't need. Data minimisation is a design decision. Free text containing names or health details, or anything classified "confidential", usually stays out of the pilot entirely. Naming the bottleneck across all four dimensions is the most useful single sentence of the whole exercise.
Four steps before any code can sound like overhead. In practice it is the opposite. Every gap found here is a gap that doesn't stop the pilot in month three. And the method is honest in both directions: it shows where AI genuinely helps – and where a well-maintained rule does the job better.
The model is the easy part. The judgment about function, risk and data is where experience counts.
Planning an AI project and want to know where the real bottleneck is? Talk to TTMS.
