Project Manager (PM):
Morning. Quick one — can you just update the process document?
Technical Author (TA):
Of course. “Just update it.” My favourite three-word project plan.
PM:
It shouldn’t be a big job. We’ve only changed a few steps.
TA:
Right. And those “few steps” — do they affect upstream inputs, downstream outputs, or the system logic in between?
PM:
I… don’t think so. It’s just a tweak.
TA:
That’s reassuring. Tweaks are how most operational inconsistencies begin.
PM:
You’re overthinking it. It’s just documentation.
TA:
That depends. Are we documenting reality, or creating a version of reality we’d prefer auditors to believe?
PM:
Okay… we’re documenting the process as it is now.
TA:
Good. Then I’ll need to confirm:
- What’s changed
- Whether the system reflects that change
- Whether people are following it
- And whether any other documents now contradict it
PM:
It’s one section.
TA:
There’s no such thing as “one section.” There’s only:
-
-
- Sections that affect other sections
- And sections that haven’t been checked yet
-
PM:
You’re making this sound bigger than it is.
TA:
No, I’m making it sound as big as it becomes when no one checks properly.
PM:
Fine. What do you need?
TA:
Let’s start simple:
-
-
- Who approved the change?
- Which system behaviour changed?
- Which teams are impacted?
- Which other documents reference this process?
-
PM:
We haven’t mapped all that.
TA:
I assumed as much. That’s usually where “just update it” comes from.
PM:
Look, we’re tight on time. Can you just make the edit, and we’ll refine later?
TA:
That approach has a sound track record of producing:
-
-
- Conflicting procedures
- Confused users
- And fascinating audit findings
-
PM:
We’ll deal with that if it happens.
TA:
You will. I’ll be the one explaining how it happened.
PM:
Alright, what would you normally do?
TA:
Since you asked, the “just update” version looks like this:
-
-
- Validate the change with SMEs
- Check system behaviour aligns
- Identify impacted documents
- Update content with correct structure and flow
- Run it through review and approval
- Apply version control and ownership
- Trigger downstream updates — training, guidance, anything referencing it
-
PM:
That’s… more than I expected.
TA:
It usually is. Documentation is where assumptions go to get exposed.
PM:
Can we scale that down?
TA:
We can scale the effort. We can’t scale the risk.
PM:
So what happens if we don’t do all that?
TA:
Best case?
People ignore the document.
Worst case?
They follow it.
PM:
…that’s not reassuring.
TA:
It’s not meant to be. It’s meant to be accurate.
PM:
Alright. Let’s do it properly. I’ll get you access to the SMEs.
TA:
Perfect. I’ll start by finding out what changed — and what everyone thinks changed. Those are rarely the same thing.
PM:
You enjoy this, don’t you?
TA:
I enjoy fixing problems before they introduce themselves in a post-incident review.
PM:
Fair enough.
TA:
And just so we’re aligned — next time you say “just update the document”…
PM:
Yes?
TA:
I’ll translate it for you as:
“Please validate and stabilise part of our operating model.”
PM:
…noted.
TA:
Good. We’re making progress already.