Knowledge transfer slips on almost every transition. Not because anyone is obstructive — it slips because of an assumption buried in the plan: that the people who currently do the work will find time to explain it.
They will not, and it is worth being precise about why. The people who know the process best are the ones the process depends on most. They are not sitting idle waiting to be interviewed. Every hour they spend explaining their job is an hour not doing it, and their job does not pause for the transition. When the calendar gets tight the session gets moved — reasonably, because the thing they were going to explain is less urgent than the thing currently on fire.
Knowledge transfer treated as something you receive will slip. Treated as a project you run, it does not.
The failure mode
It usually looks like this. Sessions are booked. Some happen; more get rescheduled. The ones that happen are unstructured — the client's expert talks through what they do while your team takes notes, and everyone leaves feeling it went well.
Then go-live comes, and the gaps appear. Not the big things, which everyone remembered to cover. The small ones: the exception handled differently for one supplier, the approval skipped in a particular circumstance, the report somebody runs on Thursdays for a reason nobody documented.
One from a recent transition
Most purchase orders followed the documented approval path. A small group of suppliers required an additional review step, for compliance reasons dating back years. Everyone on the existing team knew this. Nobody had written it down, because to them it was not an exception at all — it was simply how you handled those suppliers.
It would have been very easy to miss, and finding it afterwards would have meant discovering it through a compliance failure rather than through a conversation.
Those gaps are where transitions actually hurt.
Do the work before the sessions
The inversion that fixes this: arrive knowing what you need, rather than waiting to be told.
Build questionnaires first
Before any session, write down what you need to know — process by process, exception by exception. Specific questions, not topics. “What happens when a delivery arrives short?” rather than “receiving process”.
Two things follow. The session becomes an hour of answering rather than an hour of free recall, which respects the person's time and produces better information. And the questions you cannot answer afterwards are visible, instead of being discovered at go-live.
Write the training materials before you are trained
This sounds backwards. It works because drafting a document about a process you half understand exposes exactly where your understanding stops. The client then corrects a draft rather than dictating from scratch — faster for them, more accurate for you.
Build validation materials in parallel
For each workflow, a document setting out what you believe happens, step by step, for the client to confirm or correct. Confirming a written flow takes a fraction of the time that describing one does.
100+
pages of questionnaires, process maps and draft guides, produced before the first session
4 + 1
months of discovery and implementation, then validation
That front-loading is the whole method. It converts the client's contribution from explanation into correction, which is both faster and more accurate.
Drive the sessions
Run them yourself. Come with an agenda and the questionnaire. End by naming what is still open. The client's expert should leave having answered questions, not having delivered a lecture.
Schedule around them completely. This is the part that sounds like a platitude and is not. Early mornings, late evenings, whatever fits between their commitments. We did this deliberately, including outside normal working hours. The message it sends matters as much as the hours it recovers: your time is the constraint, not ours.
Record what you can, but do not rely on it. Recordings feel like insurance and are rarely rewatched. The structured document you fill in during the session is worth more than the recording nobody opens.
Track the gaps visibly. A shared list of open questions, updated after every session. It shows progress, and it stops the quiet accumulation of things everyone assumed somebody else had covered.
Then validate against the real thing
Knowledge transfer is not finished when the sessions end. It is finished when your team can run the process without needing to ask.
We run a validation period before go-live for exactly this — the team working real processes against live systems, with the client's people still available. On this engagement that was a month, following four months of discovery, training and implementation.
Validation is where the remaining gaps surface, and they always exist. The only question is whether they surface while the client's experts are still on hand, or afterwards.
The short version
- Write the questions before the sessions.
- Draft the documentation before you are taught.
- Run the sessions rather than attending them.
- Schedule entirely around the client, including awkward hours.
- Track open gaps where everyone can see them.
- Validate against live systems before you rely on it.
- Assume the small exceptions are where the risk is.
The point
A transition plan that waits to be taught is a transition plan that slips. The fix is not more sessions — it is arriving at each one already knowing what you need to find out.
Written by
Director of Procurement, Modern Signal
Modern Signal's procurement practice, running transitions for manufacturers and regulated businesses.
