There’s a familiar moment on transformation projects.
The maps are finished.
They’re clean, colour-coded, signed off by the steering committee.
Everyone agrees the new process makes sense.
Then go-live arrives, and someone in the operations team asks a simple question.
“Okay, but what do I actually click?”
The map can’t answer that.
It was never meant to.
🧭 They’re doing two different jobs
A process map shows the shape of the work.
Who’s involved, what order things happen in, where the handoffs sit, where decisions get made.
It’s a view from above.
A work instruction shows the work itself.
Which screen, which field, which approval, what to do when the thing you expected doesn’t appear.
It’s a view from the desk.
Both are correct.
Neither is sufficient on its own.
When projects treat them as competing deliverables, or assume one will cover the other, the gap shows up at exactly the wrong time.
🕳️ What happens when you only have maps
Maps alone create a familiar pattern.
The process is approved but nobody can execute it consistently.
People fill the gap themselves, which they always do, because work still has to get done.
Someone writes their own cheat sheet.
Someone else keeps doing it the old way because they were never shown the new one properly.
Within a few months you have four versions of the process running in parallel.
The map on the wall says one thing.
The floor says something else.
That drift is usually blamed on change resistance.
More often it’s just a documentation gap that nobody funded.
🌫️ What happens when you only have work instructions
The opposite failure is quieter but just as costly.
You end up with a library of detailed step-by-steps and no shared understanding of how they connect.
Each team knows its own part.
Nobody owns the middle.
Handoffs become the place where things go missing, because no single instruction covers the space between two of them.
When something breaks, there’s no way to trace it back.
You can’t improve a process you can only see in fragments.
And when the system changes, you’re updating forty documents with no way of knowing which ones actually matter.
🔗 Building them together, not sequentially
The practical move is to develop both in the same stream of work, with the map slightly ahead.
Map first, at a level that’s useful rather than exhaustive.
Get agreement on the flow, the owners and the decision points.
Then write the instructions against that structure, using the same step names and the same terminology.
If step 4 on the map is “Verify customer details”, the work instruction should be called the same thing.
That sounds small.
It’s the difference between documentation people can navigate and documentation they abandon.
Number your process steps and let the instructions inherit those numbers.
Link them in both directions where your tooling allows it.
Someone reading the map should be one click from the detail.
Someone stuck in the detail should be one click from the context.
🔄 Where the real value shows up
Something useful happens when you write the instructions.
You find the holes in your map.
A decision point that has three outcomes on paper and five in practice.
A handoff with no named receiver.
A step that assumes information which doesn’t exist yet at that point in the flow.
Writing the detail tests the design in a way that a workshop never will.
Feed that back into the map.
Then keep the loop going after go-live.
When the process changes, both artefacts change together, or you’re back to drift within a quarter.
This is the part that gets dropped when budgets tighten, and it’s the part that determines whether the project holds.
👥 Who should own what
Ownership is where this often falls down.
Process owners tend to sit with the map because it reflects accountability across teams.
Work instructions belong closer to the people doing the task, with a reviewer who actually performs the work.
Have one person or team responsible for keeping the two aligned.
Not aligned in theory.
Aligned in the sense that someone checks, on a schedule, that the instructions still match the flow.
Without that role, alignment lasts about as long as the project team does.
🧰 A workable approach for your next project
Start with a map at the level a new starter could follow.
Resist the urge to add every exception at this stage.
Identify the steps where people are most likely to get stuck, make errors, or need a decision.
Write instructions for those first.
Test them with someone who wasn’t in the workshops.
Watch where they hesitate, because hesitation marks the gap between what you wrote and what they needed.
Fix it, then expand outward.
Publish both in the same place, in the tools people already have open.
Set a review date before go-live, not after.
Transformation projects are usually judged on whether the system went live.
They should be judged on whether the work got easier.
Maps tell people where they’re going.
Instructions get them there.
You need both, and you need them talking to each other.
