People · Topic 6 of 7

Knowledge Transfer

Explicit and tacit knowledge, lessons learned, retrospectives, communities of practice and handover methods that keep project knowledge from being lost.

  • 4 min
In a nutshell
  • Explicit knowledge can be documented, and tacit knowledge needs interaction.
  • Lessons learned are captured throughout the project, not only at closure.
  • Retrospectives are regular, team owned meetings that produce improvement actions.

What it is

Knowledge transfer is moving what people know from one person, team or project to another. It protects the project when a team member leaves, helps new members become useful quickly and lets the organization reuse what it has learned.

A project produces valuable knowledge every day: how a tricky integration works, which supplier is reliable, why a decision was made. If nobody captures it, it disappears when people move on.

Capturerecord what is knownSharemake it findableApplyuse on the workImproveupdate from experience

How it works

Explicit and tacit knowledge

Explicit knowledge can be written down and stored. Examples are procedures, templates, designs and data. It is easy to share through documents, wikis and repositories.

Tacit knowledge lives in people's heads and habits. It includes judgment, rules of thumb and how to handle awkward situations. It is harder to share, so it needs conversation, demonstration and working side by side.

TypeExamplesBest sharing methods
ExplicitProcedures, designs, checklists, codeDocuments, wikis, repositories, training material
TacitJudgment, intuition, relationshipsMentoring, pairing, shadowing, communities of practice

Methods for sharing knowledge

Different methods suit different needs. Teams usually use a mix.

  • Documentation and wikis: good for stable, explicit information.
  • Lessons learned register: a living list of what went well, what went badly and what to do differently, kept through the project, not just at the end.
  • Retrospectives: short, regular team meetings where the team inspects its own way of working and agrees improvements.
  • Pair work or mob work: two or more people work on the same task, so skill and context spread naturally.
  • Mentoring and shadowing: a less experienced person learns alongside an expert.
  • Communities of practice: groups of people who share a discipline and exchange ideas across teams.
  • Cross training: team members learn each other's tasks, which reduces dependence on a single person.

Creating the right culture

People share when they feel safe. A blame culture hides mistakes and wastes the chance to learn. A project manager encourages openness by treating mistakes as information and recognizing people who share what they know.

Time must also be set aside. If everyone is fully booked on delivery, no knowledge transfer happens.

Transfer at key moments

Certain moments carry particular risk of knowledge loss.

  1. Onboarding: new members need context, access and a buddy to ask questions.
  2. Handover: when a role changes hands, the leaver should brief the successor and share sources.
  3. Phase or project end: capture lessons and archive records for future projects.
  4. Handoff to operations: the support team needs documentation, training and a period of joint working.
Project workknowledge createdLessons logcaptured oftenOrganizationassets updatedNext projectreuses it

Predictive, agile and hybrid views

Predictive projects often formalize knowledge through lessons learned sessions at the end of phases and archive them as organizational assets. Agile projects spread knowledge continuously through daily stand ups, reviews and retrospectives, and by working in cross functional teams.

Hybrid teams combine both. They keep a formal record where governance requires it and rely on frequent team practices to keep knowledge moving.

Exam tip

If a scenario involves a key person about to leave, the best response usually combines a structured handover with spreading the knowledge across the team, not just asking for a document.

What to remember for the exam

  • Explicit knowledge can be documented, and tacit knowledge needs interaction.
  • Lessons learned are captured throughout the project, not only at closure.
  • Retrospectives are regular, team owned meetings that produce improvement actions.
  • Pairing, mentoring, shadowing and communities of practice transfer tacit knowledge.
  • Cross training reduces the risk of relying on a single person.
  • A culture without blame encourages people to share problems and learning.
  • Plan time and resources for knowledge transfer, since it does not happen by itself.
  • Lessons learned and records become organizational process assets for future projects.

Common mistakes

Waiting until the end to capture lessons. Memory fades, and the team may be gone, so capture lessons as they occur.

Assuming documents are enough. A manual cannot hold judgment, which is why conversations and working together matter.

Relying on one expert. A single point of knowledge is a risk to schedule and quality.

Skipping handover during turnover. The next person starts from zero and repeats mistakes.

Collecting lessons but never using them. A register that nobody reads is wasted effort, so feed it into plans and checklists.

Watch out

Do not treat a retrospective as a place to assign blame, because people stop being honest and the improvement value disappears.

Check yourself

  • Why is tacit knowledge harder to transfer than explicit knowledge?

    It sits in people's experience and judgment and cannot be fully written down, so it needs interaction such as mentoring or pairing.

  • When should lessons learned be captured?

    Throughout the project, with a final consolidation at closure.

  • What is the purpose of a retrospective?

    To let the team inspect how it works and agree improvements for the next period.

Topic 6 of 7 in People

Test yourself on People

The full PMI PMP question bank has 1,463 questions, with timed practice exams and an explanation for every answer.

This study guide is independent and is not affiliated with, endorsed by, or sponsored by PMI. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.