Week one belongs to listening, not to proposing
The most common way an engagement fails in its first month is not bad engineering but a premature answer. A team arrives with a hypothesis, tests it against the first interview, and spends the remaining weeks refining a solution to a problem nobody confirmed. The month ends with a proposal containing a process no one recognises from the working day. A chief operating officer sees proposals like this mid-month, and far fewer at the end.
A rule for the opening fortnight: no solution language at all. The work is to establish whose work this is, what it costs today, and which parts are genuinely difficult. Week one should end with a short list of processes, an owner for each, and a rough sense of volume and pain.
The interviews are designed to produce disagreement
The interviews are usually too polite. Everyone agrees, the notes are harmonious, and the team walks away with a problem statement nobody argued for. The questions have to be built to surface conflict, because conflict is where reality is.
- Ask the person who does the work what the process is actually called, and what the approver calls it. Different names usually mean different scopes, and the disagreement is the finding.
- Ask where the last serious error happened and how it was found. The answer identifies the real control, often a person rather than a system.
- Ask what the team has already tried, and why it was abandoned. Failed internal attempts are the most honest description of a problem.
- Ask the executive sponsor what they will stop doing if this works. The answer tells you whether the outcome has a real owner.
Observation beats documentation
Documentation records the process the organisation wanted. Observation records the process that runs, and the two disagree instructively. A structured observation of one process across a full cycle — including a shift change, a month-end or a peak week — takes days and produces material no questionnaire reaches.
What the observer writes down is deliberately narrow: where each piece of information comes from, what the person checks before acting, what they have to interpret, and which messages they treat as commitments. Waiting is the finding that surprises people most often, because nobody reports waiting as a problem. The detail is in mapping a business process before building the agent.
The baseline is the deliverable that outlasts the engagement
Whatever happens to the technology, the baseline remains. It is the only part of the first month that lets anyone check whether anything improved, and it is usually deferred because it does not feel like progress.
- Volume. How many items the process handles per period, and the shape of the distribution across types and sizes, because the long tail carries the cost.
- Elapsed time. How long an item takes from trigger to completion, separated into waiting and working, and where the waiting sits.
- Intervention. How many items are corrected, chased, re-entered or escalated, and who does it.
- Rework effort. The approximate minutes consumed per intervention, obtained from the people who do it rather than estimated by the team watching them.
None of these requires a data programme. Where a system of record exists they are extracts. Where it does not, a fortnight of structured counting produces an order-of-magnitude estimate, labelled with its assumption stated. The method is in calculating the value of enterprise AI.
Data access is a business negotiation before it is a technical one
The standard failure is an access request that goes out to a list of owners and returns partial extracts, silent fields and undocumented explanations. The access that matters is rarely the whole database; it is a small set of records, a time window and an owner who can interpret them.
| Access needed | What to ask for | What usually blocks it |
|---|---|---|
| Sample transactions | A fixed period, a named process, the raw records as they were created. | Nobody owns the export, or the format is undefined. |
| Definitions | The written rule for each key field, and who changes it. | The rule lives in a person's head. |
| Correction history | What was changed, by whom, and what triggered the change. | The audit trail was never enabled. |
| Case context | A small number of real cases with their full history. | Concern about the records leaving the organisation. |
Choosing a pilot the business can survive
By day thirty, one pilot should be agreed, chosen on evidence rather than enthusiasm. A workable first pilot has a named process owner, a counted baseline, data that can be reached this month, a decision a machine may assist with, and a failure that would be visible rather than catastrophic. Some candidates will not need a model at all: where the answer is a rule, a form or a permission, the honest first finding is that no AI belongs in the design.
The last two conditions separate a pilot from an experiment. A visible failure is cheap and teaches the organisation something; a silent failure is expensive and usually reported as adoption resistance. A process where the output is reviewed by a person before it acts is the right place to begin, because it isolates uncertainty rather than accountability. The exception mechanisms are set out in designing AI workflows with human approval and exception handling.
What day thirty should contain
A written summary the business will recognise: the processes examined, the interviews held, the differences between the documented and observed process, the baseline figures with their assumptions, the data access obtained and refused, the agreed pilot and its owner, and the questions still unanswered. The interview material that produced the candidate list is described in the executive interview questions that reveal hidden AI opportunities.
That document is deliberately unglamorous. Its value is that it can be used against whoever led the engagement, including the team that wrote it, and read a year later. The way we run these engagements is described in our deployment practice.