Here’s a situation that plays out on most programs.
A team has a procedure they wrote themselves.
It’s a Word document, slightly out of date, structurally messy, missing the prerequisites.
You produce a properly written replacement.
Clear steps, verified against the system, tested, well structured, findable.
Six months later they’re still using their own version.
This happens often enough that it’s worth understanding rather than complaining about.
🔨 People overvalue what they built
There’s a consistent finding in how people assess value.
Something you assembled yourself gets rated more highly than an identical item you didn’t.
The effort you put in becomes part of how you judge the result.
Documentation is no different.
The team wrote their procedure during a difficult period, probably out of hours, probably because nobody else would.
That history is attached to the document.
Your version has no history attached to it at all.
It arrived, fully formed, from someone who wasn’t there.
On the quality of the writing alone, yours wins easily.
On the dimension they’re actually judging, it doesn’t.
🧭 Familiarity is a real feature
There’s a practical element too, which is easy to dismiss.
Their version is organised the way their brain organises the task.
They know the third bullet under the second heading is the bit they always forget.
They know what the shorthand means.
Your version might be objectively better structured, though it costs them relearning.
For someone doing this task 40 times a week, relearning a document has a genuine cost.
So the resistance isn’t always sentimentality.
Sometimes it’s an accurate calculation about their own efficiency.
⚠️ Why it still needs solving
None of that makes the situation acceptable.
Two versions of a procedure in circulation causes real damage.
- A new starter finds the wrong one, since both look official
- Updates get applied to 1 version, not the other
- The team’s version misses changes made during the last release
- Nobody knows which one an auditor would be shown
- Support gets calls caused by people following outdated steps
So the goal isn’t winning the argument about which document is better.
It’s getting to 1 version everybody uses.
🤝 How to actually get there
The instinct is to argue quality, which never works, since quality isn’t what they’re weighing.
Better approaches.
Start from their document, not yours.
Take their version as the base, then improve it.
The result carries their authorship, so the resistance largely disappears.
Keep their organising structure where you can.
If their headings match how they think about the task, keep them.
Fix accuracy, findability, plus the missing prerequisites instead.
Credit them explicitly.
Name them as contributors on the published version.
That preserves the ownership that made them value it in the first place.
Involve them in the change, not just the review.
Someone who chose 3 things about the final document treats it as partly theirs.
Someone who only approved it doesn’t.
Show what the merged version solves for them.
Not “mine is better”.
Something like “this one gets updated automatically when the system changes, so you’ll stop getting calls about the old steps”.
That’s a benefit in their terms.
🕳️ What to do when they still won’t move
Occasionally someone holds out regardless.
A few practical moves.
- Find out what their version has that yours doesn’t, since it’s often a real gap
- Ask what would need to be true for them to switch
- Accept a transition period, with both versions linked to each other
- Make sure the official version is easier to find, since convenience eventually wins
- Escalate only as a last resort, framed as risk rather than compliance
That first point is worth doing seriously.
Homegrown documents frequently contain an exception, a workaround, or a warning that nobody else knew about.
Their attachment to it might be telling you something useful.
✅ The broader lesson
The pattern here isn’t limited to documentation.
People protect what they made.
Any change process that ignores that will produce polite agreement, followed by quiet non-adoption.
Build the replacement with them rather than for them, then the same person who resisted becomes the one telling their team to use it.
That’s a much better outcome than winning the argument.
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
