There’s always someone arguing documentation can wait until after go live.
The logic is hard to fault in a planning meeting.
The system isn’t finished.
Screens are still changing.
Why write procedures against something that’ll look different in 6 weeks.
Then go live arrives, the team moves onto the next release, the documentation never gets written.
I’ve seen this play out enough times to treat it as a pattern rather than bad luck.
📉 What actually happens after go live
The deferral is never really a deferral.
It’s a cancellation with a friendly face.
Here’s the sequence, more or less every time.
- Go live consumes everyone for 3 weeks
- Defects get priority, correctly, so writing slips again
- The project team rolls off, taking the system knowledge with them
- Business as usual inherits the gap, without a budget to fill it
- Six months later someone raises it as a risk
- A contractor gets hired to write it from scratch, at twice the cost
That last step is the bit worth noticing.
The work still gets done.
It just gets done later, by someone who wasn’t there, without access to the people who made the decisions.
🎧 The service desk pays for it first
The cost shows up somewhere specific.
Without procedures, people ask each other.
Ticket volume in the first quarter after a rollout is usually 3 or 4 times what it settles at later.
A meaningful share of that is failure demand, meaning contacts caused by something the organisation could have prevented.
Someone couldn’t find how to do a task.
Someone did it wrong, so a second ticket followed to fix it.
Each of those tickets costs more than the paragraph that would have prevented it.
Nobody attributes them to the documentation decision, though, because the decision was made 4 months earlier by different people.
🕳️ Knowledge leaves faster than you expect
The other loss is quieter.
Six weeks after go live, the person who configured the approval logic has moved to another program.
The vendor consultant’s contract has ended.
The 2 business people who ran UAT have gone back to their day jobs, forgetting most of the detail.
What existed as shared understanding during the build becomes archaeology.
Writing during the build is cheap because everyone’s already in the room.
Writing afterwards means reassembling a conversation that’s already dispersed.
📝 The obvious objection, answered
“The screens will change, so the work will be wasted.”
Some of it, yes.
Not as much as people assume.
What’s stable well before go live.
- The process flow, plus who does what
- Business rules, thresholds, approval logic
- Prerequisites, access requirements, roles
- Exceptions, since those come from the business rather than the interface
- Terminology, structure, where documents will live
What genuinely changes late is screen labels, button positions, screenshots.
That’s maybe 20% of a work instruction.
So draft everything else during build, then fill the volatile parts in the fortnight before go live.
The rework is real, it’s just small.
🗓️ A sequence that works
Practical version.
- Draft structure plus process content once the design is agreed
- Write procedures against the test environment, accepting they’ll need touching up
- Leave screenshots until last, since those are the throwaway part
- Verify everything in the fortnight before go live, against the real system
- Publish day 1 material before go live, sequence the rest for month 2
- Name an owner, plus a review date, before the project team disperses
That fifth point matters.
Not everything has to exist on day 1.
Identify the 20 procedures people genuinely need in week 1, do those properly, then schedule the rest.
A program that documents 20 tasks well beats one that promises 60 then delivers none.
✅ How to make the argument
Don’t argue for documentation, since nobody funds documentation.
Argue for what deferring it costs.
Support volume in the first quarter.
Onboarding time for every new starter for the next 3 years.
The contractor you’ll hire in month 8 to reconstruct it.
Frame it as spending 3 weeks now instead of 3 months later, with worse information.
That’s a different conversation to asking for time to write.
It’s also, unlike the usual version, one that sponsors say yes to.
About the author
For 19 years Aiver has worked on enterprise digital transformation programs.
These are multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He is an IT consultant based in Melbourne.
His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design.
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.
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
