Ask 4 people to describe a process they work on daily.
You’ll get 4 different answers.
The instinct is to treat that as a problem, something to resolve quickly so you can get on with the map.
It isn’t a problem.
It’s the most valuable thing you’ll find on the whole engagement.
Those differences are telling you something about how the organisation actually operates, which nobody has written down anywhere.
🧩 Why the versions differ
The variation isn’t carelessness, or people misremembering.
Each person is describing accurately from where they sit.
Some of the reasons the same process comes back 4 different ways.
- Everyone sees their own segment clearly, then guesses at what happens either side
- Different sites developed different habits because head office never checked
- Seniority changes the answer, since a manager describes the process they designed
- Tenure changes it too, because a 15 year veteran includes steps that were removed in 2019
- One team is describing the standard path, another is describing what they do most days, which are not the same thing
Notice that only 1 of those is really an error.
The rest are legitimate accounts from different vantage points.
Which means reconciling them isn’t correcting people, it’s assembling a picture nobody had.
🔍 What the disagreements tell you
Each type of difference points at something specific.
When the sending team and receiving team describe a handoff differently.
That’s usually a visibility gap.
Work arrives incomplete a third of the time, the receiving team has been quietly fixing it, nobody upstream has ever been told.
When two sites describe different thresholds.
Someone made a local decision years ago that never got escalated.
Worth knowing before you configure a system that enforces one rule everywhere.
When a manager’s version differs from their team’s version.
That’s a control gap.
The designed process isn’t the operating process, which has implications well beyond your map.
When only one person mentions a step.
Either it’s an exception the others rarely hit, or it’s a single point of failure.
Both matter.
When two people describe the same step in opposite order.
Usually there’s no enforced sequence, so people do it however suits them.
That’s a design decision waiting to be made.
⏱️ Why live workshops hide all of this
Build the map live in a room, then the differences vanish.
Not because they’re resolved.
Because groups converge.
Someone senior describes the process, a few people nod, the quieter ones decide it’s not worth correcting in front of their manager.
The whiteboard version becomes the official version within about 10 minutes.
You leave with a map that reflects 1 person’s understanding, held by 8 people’s silence.
Six months later a workstream discovers that the northern branch never worked that way.
The better sequence is separate first.
Ask each person to describe their part in plain writing, before anyone meets.
Then aggregate those accounts into a draft, marking every contradiction visibly.
The disagreements survive long enough to be examined.
🗣️ Handling the reconciliation conversation
This part needs care, since you’re effectively telling a room that they disagree with each other.
A few things that keep it constructive.
- Present both versions in the stakeholders’ own words, not paraphrased
- Say plainly that both are probably accurate for their context
- Ask what would explain the difference, rather than which is correct
- Show what each version costs in time, rework, or risk
- Hand the decision to whoever owns the process
That third question does most of the work.
Asking what would explain the difference invites people to solve it together.
Asking which version is right invites them to defend territory.
Same information, completely different reception.
Also worth saying the awkward thing first.
“You’ve each described this slightly differently, which is normal, so I’d like to work out why rather than pick a winner.”
People relax noticeably once that’s on the table.
⚖️ Don’t resolve everything
There’s pressure to close every difference before the map is signed off.
Resist some of it.
Certain differences shouldn’t be flattened, because they reflect genuine variation the organisation needs.
A regional office handling something differently for a legitimate regulatory reason.
A high value stream requiring an extra check that low value work doesn’t need.
Model those as separate paths, rather than forcing a single flow that suits nobody.
Other differences are worth escalating rather than deciding.
Two sites with different approval thresholds isn’t a mapping question.
It’s a governance question, so put it in front of the person who owns governance.
Your job is making the choice visible, evidenced, easy.
Not making it yourself.
✅ What you hand over
At the end of a proper reconciliation exercise, the map is only part of the deliverable.
Also worth writing up.
- Differences resolved, plus what the agreed version is
- Differences retained deliberately, with the reason
- Differences escalated, with who owns the decision
- What each difference suggested about visibility, control, or risk
That last list is the one a steering group will actually read.
Because it isn’t a process document.
It’s a picture of how consistently the organisation runs, which is a rather more interesting question than what the diagram looks like.
About the author
Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.
alisodigital.com
