FDE ACADEMY · MODULE 01 · LESSON 01
Watch the work before you name the problem
How to run an observation session, what to record while you are in the room, and why the process description you were sent is usually a description of the process people believe they follow.
- Effort
- Roughly two hours in the room, plus an hour to write it up. Estimate only.
- Skills
- change-management
Free and self-paced. No certification is offered.
01The brief is not the problem
You will be handed a problem statement. It will be short, it will contain a solution, and it will have been written by someone who does not do the work. “We need an AI to answer staff questions about policies” is four assumptions stacked into one sentence: that staff have questions, that the answers are in the policies, that the policies are findable, and that a model is the missing part.
Observation is how you test those assumptions cheaply. It costs a morning. Discovering the fourth assumption was wrong after the stack is deployed costs the engagement.
02What to record while you are watching
Sit behind the person doing the work and ask them to do it normally, narrating as they go. Do not offer solutions in the room; you will be tempted within ten minutes. Record what actually happens, in the order it happens, with the systems named.
The five things worth writing down for every step are the artefact, the system, the hands, the wait and the exception. The exceptions are the expensive ones: a process that works for 85% of cases and has a two-day manual path for the rest is a process whose automation value lives entirely in that 15%.
- Artefact — what object is being moved or changed: a PDF, an email, a row, a decision.
- System — where it lives right now, including the shared drive and the personal inbox.
- Hands — who touches it, and what they are authorised to decide.
- Wait — the time between steps, which is usually far larger than the time inside them.
- Exception — what happens when the artefact is unusual, and how often that is.
03Volumes, or you are guessing
Before you leave, get numbers with units and a period: documents per week, average pages, how many people, how many are concurrent at 9am. Every downstream decision — model size, hardware, whether retrieval is even necessary — is arithmetic on those numbers, and an estimate you took from the room is worth more than a confident figure you invented later.
If nobody knows the volume, that is itself a finding. Count for one week before you design anything.
04Do this
PRACTICAL TASK
Observe one workflow and write it as a record
Produce a numbered record of one real workflow, from the artefact arriving to the work being finished, with volumes, and check it against the use-case ontology on this site.
What you need
- Access to one person who does the work, for about two hours
- Permission to take notes; agree in advance what may leave the room
Steps
- 01
Pick the narrowest workflow anyone has complained about. Not “document management” — “answering a client question about a matter we handled in 2019”.
- 02
Watch it end to end without interrupting. Write the steps as a numbered list with the artefact, system, hands, wait and exception for each one.
- 03
Get three numbers before you leave: volume per week, people involved, and how long the whole thing takes from arrival to done.
- 04
Now open the use-case index and find the entry that matches what you saw. Read its “What this is” section and mark every sentence that is true of your customer and every sentence that is not.
- 05
Read the closest entry in full — for a document-search workflow, start here — and note which of its “Compliance hot spots” you saw evidence of in the room.
You are done when
- You can state the weekly volume, the number of people and the end-to-end elapsed time, and say where each number came from.
- You can name the use case your workflow maps to — or say that none of the thirty-two fit, and why.
- Your record contains at least one exception path that was not in the brief you were given.
05Where these facts live
This lesson does not restate anything that is already recorded with its evidence elsewhere on the site. These are the pages it leans on.
- Use-case ontology
The thirty-two business problems this site is organised around, with the data types each usually touches.
- Day 1 — Observe
The same observation, run as a paid engagement: what a commercial day one covers.
- Observe the workflow before choosing the technology
The same argument at article length, with the four questions to ask while you are standing behind somebody.
Ticks are stored in your browser only. They are not sent anywhere, they are not attached to an account, and clearing your browser data removes them.