Rollout day arrives.

The new system goes live, the training is done, the project team is on standby.

Then someone in the contact centre asks a simple question about a refund, opens 3 different folders, finds 2 versions of the same document, gives up, then asks the person next to them.

That moment is where a lot of good project work quietly leaks away.

The process was mapped properly.

The instructions were written properly.

They just weren’t stored anywhere people could find them under pressure.

Knowledge management isn’t the glamorous part of a big program, but it’s the part that decides whether the new way of working sticks.

🗂️ Pick a single home before you write anything

The most common problem on large rollouts isn’t missing documentation.

It’s documentation living in too many places at once.

Maps sit in the project SharePoint, instructions sit in a training folder, quick reference guides sit in someone’s email, then a slightly different version sits in the LMS.

Every one of those copies looks official to the person who finds it first.

Agree on a single home early, then treat everything else as a link to that home.

A few things to sort out before anyone starts writing.

• Who owns the space once the project team leaves
• Who can publish, who can only comment
• How people will search, not just browse
• Whether frontline staff can reach it from the systems they actually use

🏠 Where these things usually belong

There’s no perfect tool, so it helps to match the content to the platform.

Process maps suit a process repository or a wiki, because they need version history plus a clear owner.

Work instructions suit the same space, sitting one level below the map they support.

Training material suits the LMS, because it needs completion tracking.

Announcements suit the intranet, because they’re temporary.

The rule of thumb is fairly simple.

• Maps show how work flows across teams
• Work instructions show how 1 person completes 1 task
• Training explains the change
• The intranet points to all of it

If your organisation already runs Confluence, SharePoint or a dedicated process tool like Promapp or Nintex, use it.

A slightly imperfect platform that people already log into beats a perfect one nobody opens.

🔗 Link the instructions to the tasks on the map

This is the part most programs skip, then regret.

A process map on its own tells someone what happens next.

It doesn’t tell them how to do it.

So make every task box on the map a doorway to the instruction behind it.

Most modern process tools support this natively.

If you’re working in Visio or Lucid, you can still hyperlink shapes directly to the published instruction.

Here’s what makes the linking hold up over time.

• Give every task a stable ID, something like PR-04-03
• Use that same ID in the work instruction title
• Link the shape to the published page, never to a file path
• Keep 1 instruction per task, rather than 1 long document covering 6 tasks
• Review links whenever the map changes, not once a year

Stable IDs matter more than people expect.

Task names change constantly during a rollout.

A link built on a task name breaks the first time someone renames “Verify customer” to “Confirm customer identity”.

A link built on an ID survives.

🧭 Make it findable at the moment of need

Nobody reads documentation in advance.

They read it while a customer is waiting.

So the distance between the person’s screen plus the instruction needs to be very short.

A few practical ways to close that gap.

• Put links to the process area directly in the new system, on the relevant screens
• Add the process ID to the top of the instruction so people can search by it
• Write titles the way people speak, not the way the project charter does
• Keep instructions to 1 page where you can

Search behaviour is worth a quick test before go live.

Ask 5 people from different teams to find a specific instruction, then watch what they type.

You’ll learn more in 20 minutes than in a month of structure debates.

✍️ Keep the maps light, keep the instructions specific

Detailed maps look impressive in a steering committee pack.

They’re painful to maintain.

Keep the map at a level where a new starter can follow the flow in about 2 minutes.

Push the detail down into the work instructions, where it belongs.

Screenshots, field names, exception handling, who to call when the system says no.

That split gives you 2 useful outcomes.

• Maps stay stable, so they don’t need constant rework
• Instructions can change quickly when the system gets an update

🔄 Plan for the day after handover

Every rollout eventually ends.

The project team moves on, the consultants leave, the documentation stays.

So name an owner for each process area before that happens, not after.

Set a review cycle that’s realistic, maybe every 6 months for stable processes.

Add a small note at the bottom of every instruction showing the owner plus the last review date.

It’s a tiny detail that tells readers whether they can trust what they’re reading.

Good knowledge management on a big program isn’t really about tools.

It’s about making sure the right answer is easier to find than the wrong one.

Get that right, then the rest of the change work has something solid to stand on.