Ask any engineering team how they manage change to their codebase.
You’ll get a confident answer.
Version control, branches, pull requests, code review, a deployment pipeline, rollback if something breaks.
Every change attributable to a person, a date, a reason.
Now ask the same organisation how they manage change to their standard operating procedures.
The answer is usually a shrug.
Someone edits the Word document.
Maybe they save it with a new filename.
Maybe they email it round.
🔁 The same organisation, 2 completely different standards
This is the part I find genuinely odd.
It’s not that people don’t understand change control.
They understand it extremely well, for code.
They just don’t apply any of it to the documents that tell humans how to operate the system that code runs.
Consider what a typical SOP lacks.
- No record of what changed between versions
- No record of who approved the change
- No review before publication
- No way to see the previous version
- No rollback when the new version turns out to be wrong
- No test confirming the procedure still works
Put that list in front of a developer describing their codebase, they’d be alarmed.
Put it in front of the same person describing their team’s procedures, nobody blinks.
⚠️ Why it matters more than people think
A wrong procedure has a similar failure profile to a wrong deployment.
Someone follows it.
The task gets done incorrectly.
A second problem gets created downstream.
The difference is detection speed.
Broken code often fails loudly, immediately.
A broken procedure fails quietly, repeatedly, for months, while everyone assumes the person made a mistake.
In regulated environments it’s worse still.
A procedure is evidence.
If you can’t show what it said on the date something happened, plus who approved it, then you’ve got an audit problem rather than a documentation problem.
🧰 What decent change control looks like for documents
None of this requires new tooling.
Most organisations already have everything needed.
- Version history, meaning you can see the previous version, always
- A visible owner, a person rather than a team
- A last reviewed date on the page itself
- A summary of what changed at the top, so reviewers aren’t re-reading 12 pages
- An approval step for anything with compliance implications
- A scheduled review cycle, realistic rather than aspirational
That fourth point saves more reviewer time than anything else on the list.
Reviewers skim when they can’t see what’s different.
Show them the diff in plain language, they’ll actually check it.
🔗 Tie the procedure to the change that triggered it
Here’s the step that closes the loop.
When a system change goes through, the procedures affected by it should be part of that change, not an afterthought.
Practically.
- Tag work instructions with the process task ID they support
- Flag affected documents as part of release planning
- Treat an un-updated procedure as an open item, not a nice-to-have
- Publish the procedure update in the same release window as the system change
Do that, then documentation stops drifting.
Skip it, then every release widens the gap between what the system does, what the documents say.
Eighteen months of that produces a knowledge base nobody trusts.
🧪 Test procedures the way you’d test code
There’s an equivalent to testing, it’s just rarely done.
Follow the procedure yourself, in the system, exactly as written.
Not skim it.
Follow it.
You’ll find the missing prerequisite, the step in the wrong order, the field renamed 2 releases ago.
It takes 10 minutes for most work instructions.
It’s the single highest value quality check available, plus almost nobody does it.
✅ The argument worth making
If you’re trying to get documentation governance funded, don’t argue for documentation governance.
Argue the comparison.
Every change to the system goes through review, approval, version control, plus rollback.
Every change to the instructions telling 400 people how to use that system goes through nothing.
Ask which of those is more likely to cause an incident.
Then ask why only 1 of them has a process around it.
That’s a conversation sponsors follow, because it uses a standard they already believe in.
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
