Many AI projects start with the question of tools: which assistant, which platform, which model. That is the wrong way in. A tool is useless if it does not serve a specific process, on available data, with people ready to change the way they work. A diagnostic puts these questions back in the right order.

The tool-first trap#

When leadership starts with the tool, three problems almost always appear. The scope is decided by default, according to what the vendor offers. Priorities follow the demos, not the real stakes. And results are judged on a general impression, for lack of a measured starting point.

A diagnostic reverses this logic. It starts from processes, not tools.

What a diagnostic looks at#

A useful diagnostic covers four dimensions.

Processes. Where is time spent? Which tasks repeat? Where do decisions get stuck? The diagnostic observes how work really happens, not the organisation chart or the written procedure.

Data. What information exists, in what form, in which system, and who controls it? Data that is inaccessible or unreliable cannot support a use case.

Decisions. Who decides what, on the basis of which information, and how often? AI is useful where a decision relies on long or repetitive reading of documents.

Skills and habits. Who already uses AI, and how? What holds people back? A diagnostic is not limited to technology: it also measures the organisation's capacity to adopt change.

The deliverables to insist on#

A serious diagnostic produces concrete documents. Ask at least for:

  • a map of the processes studied, with the friction points identified;
  • an inventory of the available data and its quality;
  • a list of candidate use cases, each described in a few lines;
  • a risk assessment, notably on sensitive data and compliance;
  • a recommendation on the order in which to tackle them.

If the provider cannot show what this kind of deliverable looks like, question their method.

What the diagnostic does not promise#

An honest diagnostic does not promise quantified gains. It identifies leads and the conditions they depend on. Quantified objectives are set afterwards, from a measured starting point. Be wary of any proposal that announces results before observing your processes.

The duration is set at scoping#

The duration of a diagnostic depends on its scope: the number of processes, departments and systems involved. It is defined at the scoping stage, with a written scope. A vague scope produces a vague diagnostic, whatever its duration.

From prioritisation to plan#

The diagnostic produces a list of candidates. Prioritisation ranks them on three criteria: expected value, technical feasibility and risk. The implementation plan builds on this ranking. It then organises the first use cases, governance, and finally roll-out and training.

Questions to ask a provider#

  • Which processes will you observe, and with which people?
  • Which data will we need to make accessible, and in what form?
  • Which deliverables will we receive at the end of the diagnostic?
  • How will the candidate use cases be prioritised?
  • What are the limits of your approach?

The quality of these answers often says more than the sales presentation.

Key takeaways#

The diagnostic is not an administrative step before the project. It is the part of the project that avoids spending time and money on the wrong topics. It also gives leadership a solid basis for deciding.

Further reading#