Every workflow project begins with a document describing how the process works. Almost every workflow project then discovers, somewhere around user acceptance testing, that the document described how the process is supposed to work.
The gap between those two things is where budgets go to die. Discovery is the phase meant to close it, and it usually fails in a specific, predictable way: it interviews the people who own the process instead of the people who perform it.
Three processes, not one
For any established business process there are reliably three versions in circulation.
The documented process lives in the procedure manual and the compliance pack. It is complete, correct, and describes a world in which nothing goes wrong. It is what a manager will describe when asked.
The performed process is what the team actually does. It contains the documented process plus every accumulated workaround: the spreadsheet that tracks what the system cannot, the colleague who is asked before anything unusual is approved, the informal rule that requests under a certain value skip a step because the queue is otherwise unmanageable.
The exception process is what happens when the case is strange. It is almost never written down anywhere, it is held in the heads of two or three long-serving people, and it accounts for a startling proportion of total handling time.
A discovery phase that captures only the first of these produces a specification that will be signed off enthusiastically and will fail on contact with real work.
What to actually do
Watch the work, do not just discuss it
Sit with someone processing real cases for two hours. Not a walkthrough — actual work, in their environment, on their queue. You are watching for the moments they do something the manual does not mention: switching to a spreadsheet, opening a second system to check something, hesitating, or asking a colleague. Every one of those is a requirement nobody was going to tell you about.
The single most productive question in the entire phase is asked in the moment: What made you do that?
Ask for the last ten cases, not the typical one
Typical is a reconstruction, and people reconstruct toward the documented process. Ask instead for the last ten cases they handled and walk each one. The distribution you get is real, and it will not match the one you were described. It also surfaces frequency, which the interview cannot: the exception everyone warns you about may occur twice a year, while the undocumented shortcut happens forty times a day.
Find the queues and the ageing
Where does work pile up, and how old is the oldest item? Queues are the honest signal of where a process actually hurts. A step everyone complains about but which has no backlog is an irritation; a step with a quiet three-week queue is the constraint, whether or not anyone mentioned it.
Establish the baseline before you change anything
If you cannot state today’s cycle time, volume, rework rate and cost per case, you will not be able to demonstrate improvement later — and the project will be evaluated on impressions instead of numbers. Capture the baseline during discovery, agree it with the sponsor in writing, and agree which metric the project is expected to move.
This is also the honest moment to discover that the sponsor’s actual goal is not the stated one. Reduce cycle time sometimes means stop the complaints from the regional director. Those imply different projects.
Map the systems of record early
For each piece of data the process touches: which system owns it, who can write to it, what the integration surface is, and what happens when it is unavailable. Integration discovery late in a project is the most common source of schedule overrun, because it is the one area where the answer can be that is not possible rather than that will take longer.
What discovery should produce
A discovery phase that has done its job hands over five things:
- A process map that includes the exception paths, each marked with an observed frequency. A map showing only the happy path is not finished.
- An explicit decision inventory. Every point where a human judgement is made, who makes it, what information they use, and whether the rule is written anywhere. This tells you what can be automated, what must stay human, and what needs a rule agreed before build.
- The agreed baseline metrics and the specific number the project will move.
- An integration register naming each system, its owner, its interface and its failure behaviour.
- A written list of what is out of scope, agreed by the sponsor. This is the cheapest insurance available on any workflow project.
The uncomfortable finding
Good discovery sometimes concludes that the process should not be automated as it stands — that three of its eight steps exist only to compensate for a data quality problem upstream, and automating them would make the compensation permanent.
Reporting that costs you scope in the short term. Not reporting it costs the client a system that faithfully encodes a workaround, at which point the workaround is no longer a workaround. It is the process.
A discovery phase that never produces an uncomfortable finding probably was not looking very hard.
Who to talk to, in order
Discovery access is usually rationed, so the sequence matters more than the total number of conversations.
The longest-serving operator, first. Not the best performer — the one who has been there longest. They hold the exception process, and crucially they remember why steps exist. A step that looks redundant is often a scar from an incident nobody has documented, and removing it re-opens the wound.
The newest joiner, second. They still notice what is strange. Someone three months in can tell you which parts of the process made no sense during training, and they have not yet stopped seeing it. Six months later that information is gone permanently.
The person downstream, third. Whoever receives the output of this process knows its real quality in a way the people producing it do not. Ask them what they routinely have to fix. Every answer is a defect the upstream process cannot see.
The sponsor, last. Deliberately last. Going in with observed evidence changes the conversation from negotiating a description to reconciling one, and it is much harder to be told the documented process is what happens when you have watched it not happen.
Reading the artefacts
People misremember. Artefacts do not, and three are consistently underused.
The spreadsheets. Every mature process has shadow spreadsheets, and each one is a precise specification of something the system does not do. Ask for copies. The column headings are a requirements document written by the people who needed it.
The email folders. Where the process actually escalates. Search for the phrases people use when something has gone wrong — “chasing”, “still waiting”, “urgent” — and you find the friction points, with dates and frequencies attached.
The audit log. If the current system has one, it beats every interview. It shows real cycle times, real rework loops, and which steps get reversed. People describe a process as linear; logs routinely show cases going backwards.
Sizing the exceptions
The most common discovery failure is not missing the exceptions — it is failing to size them.
Teams talk about exceptions in proportion to how painful they are, not how often they occur. The result is a design that carefully handles a twice-yearly edge case and ignores something happening forty times a day, because the first one is memorable and the second has been absorbed into normal work.
Force the numbers. For each exception path: how many per week, how long does it take, who handles it, what triggers it. When you cannot measure, estimate in the room and mark it as an estimate. A wrong number that is visible gets corrected; an absent number gets designed around badly.
The output is a frequency-weighted map, and it usually reorders the priorities everybody arrived with.
The handover that survives contact with the build team
Discovery documents rot fast. Three habits keep them useful.
Record the source of every statement. “Approvals over £10k go to the regional director” is a different fact depending on whether it came from the policy document, the manager, or an operator saying that is what they do. When they conflict — and they will — you need to know which is which.
Separate observation from inference. “We observed the operator check the CRM before approving” is an observation. “The process requires a CRM check” is an inference. Inferences are useful and frequently wrong; labelling them means they get tested rather than inherited.
List the questions you could not answer. Every discovery ends with unknowns. Writing them down converts them from invisible risk into a tracked list. The alternative is that they surface in build as surprises, and by then they have a cost.
EFTEDRA builds workflow automation on IBM Business Automation Workflow and Claude — assistant tasks and coach views that install into the processes you already run. See what we build, or try the live demo.