Most IT projects don’t stall because of the technology.
They stall because nobody agrees on how the work actually gets done.
The software gets delivered.
The training happens.
Then, a few months later, people quietly go back to the old way.
Usually it comes down to processes, and more specifically, the gaps between them.
Every team knows their own patch well.
Very few can explain what happens either side of it.
🧭 A process is never really a single process
On paper, a process looks tidy.
A trigger, a few steps, an output.
In practice, that output lands on someone else’s desk and becomes their input.
Procurement feeds into onboarding.
Onboarding feeds into access provisioning.
Access provisioning feeds into support.
None of these run in isolation, even though they’re often documented that way.
When you only map one process at a time, you get an accurate picture of a small thing and a very poor picture of the whole.
That’s where projects come unstuck.
🔗 The gaps are where the trouble lives
Handovers are the weak points in almost every organisation I’ve worked with.
One team finishes their part and assumes the next team knows what to do with it.
The next team makes their own assumption and fills the gap with a workaround.
Nobody writes the workaround down.
Six months on, that workaround has quietly become the process.
Then a new system arrives and the whole thing breaks, because the new system was designed around the documented process, not the real one.
Mapping end to end brings these gaps into the open before they cost you.
🗺️ Mapping makes the invisible visible
Process mapping gets a bad name because people picture a wall of boxes and arrows nobody reads.
Done well, it’s much simpler than that.
You follow a piece of work from start to finish and note every point where it changes hands.
You ask who does what, when, and with what information.
You look for the steps that exist only in someone’s head.
Those are the risky ones.
If a person leaves and the process goes with them, that’s not a process.
That’s a dependency.
A good map shows the whole flow on one page, in a way a new starter could follow.
👥 Shared understanding beats individual expertise
Here’s the part that matters most for project teams.
When everyone can see the full flow, conversations change.
People stop defending their patch and start looking at the system.
A developer can see why a small change to a form creates three hours of manual work downstream.
A finance lead can see why the approval step sits where it does.
Decisions get made faster because the trade offs are visible.
You also get better questions in workshops.
Instead of asking what the new system does, people start asking what happens to the exception cases they handle manually.
Those are the questions that stop rework later.
📋 Documentation people will actually use
Process documentation earns its keep when it’s written for the person doing the job, not the person auditing it.
That means plain English, short steps, and real screen names.
It means saying who owns the step, not just what the step is.
Standard operating procedures work best when they’re short enough to read on a Monday morning and specific enough to follow without asking a colleague.
Keep the detail where it’s needed and cut everything else.
A twenty page procedure that nobody opens is worse than a one page one that everyone does.
Good knowledge management is less about volume and more about findability.
⏱️ Keeping it current once the project ends
Most process documentation is accurate for about a fortnight after go live.
After that, small changes creep in and nobody updates the record.
The fix is unglamorous but it works.
Give each process an owner and a review date.
Build the update into the change process, so a system change automatically triggers a documentation check.
Make it easy to flag something that’s out of date.
If people need to fill in a form to report a wrong step, they simply won’t bother.
✅ A sensible place to start
You don’t need to map everything before you start a project.
Pick the three or four processes the new system touches most.
Follow each one end to end, including the parts that happen outside the system.
Talk to the people doing the work, not just the people managing it.
Note the handovers and the manual workarounds.
Then bring the teams together and walk through the map as a group.
You’ll usually find at least one surprise in the first hour.
That surprise is the reason the exercise is worth doing.
Projects run better when people understand not just their own steps, but how their work lands for everyone else.
That’s not a documentation exercise.
It’s a team one.
