3.7. Help Ensure Knowledge Transfer
💡 First Principle: Knowledge that lives only in one person's head is a project risk the moment that person is unavailable — this task tests whether you actively identify, gather, and institutionalize critical knowledge rather than letting it stay tacit.
Enablers: identify knowledge critical to the project, gather that knowledge, and foster an environment that supports transfer (documentation, pairing, communities of practice, structured handoffs).
This task is frequently tested at project closure scenarios (a team member leaving mid-project, or a phase transitioning to operations) — but PMI expects knowledge transfer to be treated as an ongoing risk-mitigation activity throughout the project, not something addressed only at the end.
Explicit and tacit knowledge
The type of knowledge at risk decides how you transfer it.
| Explicit knowledge | Tacit knowledge | |
|---|---|---|
| What it is | Already captured in a form others can read | Lives in experience, intuition and judgment |
| Examples | A deployment checklist, an architecture decision record | Sensing which stakeholder to loop in early, spotting burnout before anyone says so |
| Best transfer | Documentation, repositories | Shadowing, pairing, mentoring, working together |
Documentation alone cannot move tacit knowledge; that needs people working side by side.
Matching the method to the situation
- Shadowing — hands-on skills that are hard to write down.
- Documentation — explicit, procedural knowledge that must be repeatable.
- Joint work sessions — knowledge that benefits from real-time back-and-forth, such as an ambiguous design decision.
- Recorded walkthroughs — audiences that cannot attend at the same time, such as teams across time zones.
When someone is leaving
A departure with a known date is a live risk, and the response starts immediately, not in the last week. The tested sequence:
- Identify which of the person's knowledge and responsibilities are critical to continuity.
- Select a receiving team member and pair them with the departing member.
- Gather and actively transfer the knowledge — documentation, shadowing, structured handover sessions, joint work.
- Verify the receiver can apply it independently before the departure date.
⚠️ Exam Trap: "Ask the departing member to write everything down" skips both ends of the sequence. Without identifying what is critical first, effort goes into documenting the wrong things; without verification, nobody knows the handover worked until it fails.
Building an environment where knowledge flows
Colocation lets team members absorb each other's tacit knowledge through osmotic communication — overhearing conversations in a shared space — which email-only teams lose. It is costly and not always practical, but when a team has uneven product knowledge it is the keyed remedy. Pair programming, two people working together at one workstation, spreads knowledge continuously and removes single points of failure. Information radiators make key information visible to everyone, and inviting stakeholders to stand-ups, reviews and retrospectives extends that openness.
When a high performer refuses code reviews, pairing, or knowledge sharing, have a private conversation to understand their reluctance, explain why collaboration matters for team resilience, and agree a way of participating that uses their strengths.
⚠️ Exam Trap: Tolerating the lone expert because their individual output is excellent treats the knowledge silo as a success. It is a single point of failure, and the keyed answer addresses it through conversation.
⚠️ Exam Trap: Treating knowledge transfer purely as a project-closure activity ("we'll document lessons learned at the end"). The better-scoring answer usually addresses the knowledge risk as soon as it's identified, not deferred to closeout.
