Understanding Business Processes through Exception Handling

Many discovery interviews begin with a reasonable assumption: if a company has written process documentation, that documentation describes how the work gets done. Procedures, flowcharts, and standard operating guides feel authoritative, so an interviewer may treat them as a map and simply confirm the details with staff. The source behind this article argues that this assumption breaks down, and that the place where it breaks down most clearly is the exception.

A practitioner quoted in the source characterizes documentation as covering the golden path and perhaps an edge case or two. The rest of the picture usually lives outside the document. It includes the people who step in when something breaks, the time that gets lost in those moments, and the informal arrangements between colleagues.

The before and after contrast is the core idea. On the golden path, the work follows the documented route. When a case leaves that route, it can pass through a different person and acquire a different waiting time, and a procedure listing only the normal steps has no place to record either.

This gap matters for discovery work because exception paths are often where the costly delays sit. A workflow that looks short and efficient on paper can carry significant hidden time once you follow the cases that do not fit the template. An interview that asks only how the process is supposed to run will tend to collect the golden path and miss the places where the business is actually spending its effort.

A dependency graph records who feeds whom and what waits on what. In the approach the source describes, embedded practitioners called Varick's FDEs sit with one department at a time and work alongside its process leads. They assemble what they learn into this graph and treat it as the source of truth about how the business really runs.

Read the graph by following the arrows. Each arrow is a handoff: work or information passes from one node to the next. Where an arrow feeds a step, that step depends on the one before it. The waiting is recorded as a dependency in its own right, which is why the graph can show that downstream steps are held up by a reconciliation that a procedure listing the steps would not highlight.

The graph is more authoritative than the organizational chart because the chart shows reporting lines rather than work flow. It is more authoritative than the documentation because the documentation shows the intended route. The graph is built from handoffs that were observed and described, so it can reveal dependencies that neither of the other sources shows.

The source's method is to interview people about failure. Rather than asking how things run, the interviewer asks what happens when they go wrong, and then follows the answer to whoever handles the problem next. Each handoff is recorded, along with the time it consumes. The source's four-day reconciliation example shows why the time matters: the handoff timing is part of the dependency graph.

The flowchart shows the same account in the order the work moves. Reading it from the top, the case enters with Sarah, passes a decision about whether it has gone wrong, and on the wrong branch moves to Chris. The handoff into Chris and the dependency of downstream steps on Chris are the points where the case can stall or depend on someone else. The source does not give more detail about the ordinary branch beyond Sarah's role, so the diagram stops there.