When Two People Describe the Same Process Differently

Conflicting process descriptions, where two people give incompatible accounts of the same piece of work, are not a data quality problem to be resolved before the real analysis starts. They are the finding. A handoff that both sides describe identically is usually working, and a handoff where each side believes the other owns a step is where things fall on the floor.

Most discovery work treats disagreement as noise and averages it away. That instinct destroys the most valuable output of the whole exercise.

The four kinds of disagreement

They are not all the same, and they need different responses.

The first is ownership. Both people believe the other one checks the numbers. Neither does. This is the expensive one, because it produces silent failure: nothing alerts, nobody complains, and the error surfaces three months later at a customer.

The second is sequence. One person says approval happens before the work starts, the other says after. Often both are right, on different days, depending on who is available and how urgent it is. What you have found is not a contradiction but an undocumented branch.

The third is duration. Sales says the handover takes a day, delivery says it takes a week. Almost always the difference is waiting, and almost always the person who does not experience the wait is the one who reports the shorter figure. Delay is invisible from the side that is not doing the waiting.

The fourth is existence. One person describes a step the other has never heard of. This usually means it was added locally by somebody solving a problem, and it has never been communicated upstream.

Why the average is the wrong answer

The temptation, faced with two accounts, is to reconcile them. Take the midpoint on the duration, pick the more senior person's version of the sequence, and produce one clean map.

That map will be wrong in a specific and unhelpful way: it will describe a process that nobody runs. The sales version is real for sales. The delivery version is real for delivery. The average is real for nobody, and it hides the exact thing you needed to see, which is that the two halves of your business hold incompatible beliefs about a handoff they share every week.

Keep both. Mark the disagreement. It is more useful as an open question than as a resolved one.

The three questions that turn a conflict into a fix

When two accounts diverge, three questions usually settle what to do.

What happens if neither of you does it? Ask this about the ownership gaps. If the answer is "nothing, it just goes out wrong", you have found a real defect. If the answer is "it gets caught later by finance", you have found a hidden control, which is worth documenting rather than removing.

When did each of you last see it work that way? Recency separates a live branch from a memory. One of the accounts is often describing how it ran before a change nobody announced.

Who told you that was the process? Answers cluster into three: someone taught me, I read it, or I worked it out. Processes learned by working it out are the ones that vary most between people, and they are usually the undocumented ones.

For consultants, this is the deliverable

If you are doing this inside a client, the disagreements are worth more than the map.

A client can build their own flowchart. What they cannot do, because they are inside it, is see that their operations lead and their finance lead have described the approval step in mutually exclusive ways for two years. That observation is external by nature. It is also unusually persuasive, because it is not your opinion about their business, it is their own people's words placed next to each other.

Surfacing that is a lot of the value in abi. Clone for consultants, which puts the interview accounts against the map and flags where they differ, along with coverage by department so you know which parts of the picture are evidence and which are still guesswork. Consultants get five client maps free, and the interviews are the paid part.

The awkward part

Presenting disagreement to a client, or to your own team, has a social cost that nobody mentions in the methodology.

You are telling two people, often two people who get on, that they have been operating on different assumptions. Handled badly this becomes a search for who was wrong. Handled well it becomes a shared realisation that the process never made it clear, which is the accurate reading and also the one that survives the meeting.

The framing that works is that the process failed to specify, not that a person failed to know. This is almost always literally true. Nobody decided the ownership would be ambiguous, it simply was never decided at all.

When disagreement is genuinely just noise

Not every conflict is a finding, and pretending otherwise wastes people's time.

Two accounts that differ on wording, or on where the boundary of the process sits, are usually not telling you anything. Someone calling it "the intake step" and someone else calling it "the qualification call" is vocabulary, not divergence.

Differences in duration under about twenty per cent are also noise. Human estimates of time are simply not precise enough to carry that resolution, and treating a two-hour versus a two-and-a-half-hour estimate as a discrepancy will send you chasing something that does not exist.

The disagreements worth pursuing are the categorical ones. Does this step exist. Who owns it. Does it happen before or after. Those are the ones where somebody is going to be surprised.

Where to look first

Go to the boundaries. Interview the last person in one department and the first person in the next, about the same piece of work, separately.

Sales to delivery. Delivery to finance. Support to engineering. Those three seams carry most of the disagreement in most small companies, and each one takes half an hour to test.

You will find something at the first seam you try. That is not a claim about the method. It is a claim about what happens to shared work when nobody has ever written down who owns the middle of it.