Field note · FDE practice
Observe the workflow before choosing the technology
The first three days of a deployment decide most of it. This note describes what to watch, what to write down, and the four questions that turn an observation into a scope — plus the two signals that mean the project should not be an AI project at all.
- Source
- Written by us. Method and judgement — no statement on this page rests on a fetched document.
- Evidence
- none on this page — it links to the pages that hold it
01Why the order matters
A tool chosen before the workflow is understood is a bet that the described problem is the real one. It usually is not. The task people describe in a meeting is the task as it appears in the process document; the task as performed contains the exceptions, the copy-paste, the second spreadsheet nobody mentions, and the person everyone asks when it goes wrong.
Watching costs two or three days. Choosing wrongly costs the deployment.
- ASSESSMENT
We assess the first three days of observation as the part of an engagement with the highest return, because they change the specification rather than the implementation.
BasisRests on the structure of the work: implementation choices are reversible in days, whereas a wrong objective is discovered at rollout and costs the whole engagement.
02What to watch
- 01Sit beside three people who do the taskNot the manager who owns it. Ask them to do it as they normally would, and to narrate. Say nothing for the first pass.
- 02Count the exceptionsHow many of the last twenty items went through the normal path? The exception rate decides whether automation is worth building and where the human stays.
- 03Follow one item end to endOne invoice, one contract, one support call. Where it waits, who touches it, what gets re-typed, and how it is corrected when it is wrong.
- 04Find the shadow systemThere is almost always a spreadsheet, a mailbox rule, or a folder naming convention holding the process together. It is the actual specification.
- 05Ask what happens when the output is wrong todayThe existing error path tells you what accuracy the deployment has to reach, and who will notice when it does not.
03Four questions that turn an observation into a scope
- 01What is the unit of work, and how many per week?WhyVolume decides whether the deployment is worth building and what it must be sized for.A usable answerA countable unit — a document, a call, a ticket — with a weekly number and a peak.
- 02What does a correct answer look like, and who decides?WhyWithout a named person and a set of examples, quality is a matter of opinion at every review.A usable answerTwenty real cases with expected outputs, agreed by a person who is accountable for them.
- 03What does a wrong answer cost, and who absorbs it?WhyThis decides how much human review the design has to keep, and it is a compliance input as well as a design one.A usable answerA named consequence — a rework, a missed deadline, a regulatory exposure — with who carries it.
- 04What may this data touch?WhyThe residency, confidentiality and personal-data answers eliminate most of the market before any comparison starts.A usable answerA data inventory for the corpus, and the constraint stated as a boundary the architecture must respect.
- RECOMMENDATION
We recommend writing the four answers down and having them signed off before any tool is compared, and treating a missing answer as a reason to keep observing rather than to make an assumption.
BasisDepends on the engagement being a deployment rather than an evaluation. Rests on the four questions above, each of which eliminates candidate architectures rather than ranking them.
04Two signals to stop
Observation sometimes concludes that there is no deployment here. That is a successful outcome and it should be said out loud on day three rather than on month three.
- Nobody can produce twenty examples with agreed answers. Without them there is no way to tell whether the system works, and every review becomes a negotiation.
- The bottleneck is upstream. If the delay is waiting for a counterparty, or for a decision, the model has nothing to accelerate — the work is process design, and it should be scoped as that.
- ASSESSMENT
We assess "no agreed examples" as the strongest single predictor of a deployment that will be delivered and then not adopted.
BasisRests on the evaluation model recommended throughout this site: without a fixed set of cases and expected answers, no change can be shown to be an improvement, so adoption depends on impression rather than measurement.
05Related
Use cases
Stacks
Deployment reports
More field notes
Ask this as a question