Help Ensure Knowledge Transfer

Introduction

This lesson covers Task 1.7 of the People domain of the July 2026 PMP Examination Content Outline (ECO), a domain that carries 33% of the scored questions. Projects create and consume knowledge: how the legacy system really behaves, why a design decision was taken, which supplier answers quickly, what the regulator will check. Much of this knowledge lives in people's heads. When a key engineer leaves, when a team rotates, when a phase ends or when the project hands over to operations, unrecorded knowledge disappears and the organisation pays for it again with delays, defects and repeated mistakes.

The ECO describes three enablers for this task: identify the knowledge that is critical to the project, gather it (both tacit and explicit), and foster an environment in which knowledge is transferred. The exam presents situations such as a departing expert, a new team member who needs to become productive, a supplier who holds all the know-how, or a closing project whose lessons are lost. You must choose the practical action that captures and shares knowledge before it is lost.

After this lesson you will be able to identify critical project knowledge, distinguish tacit from explicit knowledge, choose capture and sharing techniques, and create the conditions in which people share.

Learning objectives

• Define knowledge management and its place in project work.
• Identify the knowledge that is critical to a project and the risk of losing it.
• Distinguish explicit from tacit knowledge and select suitable capture techniques.
• Apply methods to transfer knowledge: documentation, communities of practice, pairing, shadowing, workshops, retrospectives, handover.
• Build a culture and an environment where people share knowledge.
• Plan knowledge transfer for turnover, handover and project closure.

1. What knowledge management means in a project

Knowledge management is the set of activities that make the knowledge of individuals and groups available to the people who need it, at the time they need it. In a project it has two directions:

• Using existing knowledge to deliver better (lessons from earlier projects, expert advice, standards, templates, data).
• Creating new knowledge during the project and making it available to the team, to future projects and to operations (decisions, solutions, estimates, lessons learned).

Knowledge management is different from information management. Information (a document, a data record) can be stored in a repository. Knowledge includes understanding, judgement and experience, which are much harder to transfer, and for this reason a repository alone is never enough. The best results come from combining tools (repositories, wikis) with people-based connections (conversations, mentoring, communities).

2. Identify the knowledge critical to the project

Not all knowledge deserves the same effort. The project manager and the team ask: what knowledge would hurt the project if it were lost, unavailable or concentrated in one person?

Typical categories of critical knowledge:

Methods to identify critical knowledge:

• Skills and knowledge matrix. List key activities and artefacts on one axis and people on the other, and mark who can perform each. Activities with only one name are single points of failure.
• Knowledge risk assessment. Add the risk "loss of key knowledge" to the risk register, assessing probability (turnover, contract end, retirement, supplier change) and impact.
• Dependency analysis. Which tasks depend on a person, a supplier or an obsolete system?
• Interviews and retrospectives. Ask: "What do you know that nobody else knows?" and "What did you have to learn the hard way?"
• Review of past projects. Previous lessons learned show recurring knowledge gaps.

The result is a short, prioritised list of knowledge items, each with an owner, a form (tacit or explicit), the risk, and the planned capture method.

Example: finding a single point of failure

A utility company runs a project to replace its billing platform. The skills matrix shows that only one analyst, Maria, understands the 15-year-old tariff rules, which exist only in the legacy code. She plans to retire in eight months, and the cutover is in ten. The project manager records a risk (probability high, impact high), adds a knowledge-transfer task with a deadline of month four, and assigns two analysts to work with her. Without the matrix, the problem would have appeared during testing of the migrated tariffs, when it would have been much more expensive to solve.

3. Explicit and tacit knowledge

Explicit knowledge is codified and stored. Tacit knowledge is personalised: it moves through relationships. A frequent exam theme is choosing the right approach: asking a departing expert to "write everything down" captures only the explicit part; pairing, shadowing and recorded walkthroughs are needed for the tacit part.

Techniques by type

Worked example: capturing the knowledge of a departing expert

Scenario. You manage a data-centre migration for a retailer. Raj, the network engineer, is leaving in six weeks. He knows the firewall rules, the quirks of a legacy load balancer and the people at the telecom provider. Only some of the rules are documented. The migration cutover is in ten weeks. Raj says, "I will write a document in my last week."

Step 1 - Identify the critical items. Interview Raj and the team and list what depends on him: firewall rules (explicit but incomplete), exception handling for the load balancer (tacit), telecom contacts and escalation habits (relationships), the real behaviour on month-end peaks (tacit).

Step 2 - Choose methods for each type. Firewall rules: export and review the configuration with a second engineer, document the reasons for each exception. Load balancer: schedule three recorded working sessions in which Raj performs real tasks and explains his choices, with a successor (Lena) doing the next iteration while he observes (reverse shadowing). Contacts: introduce Lena to the telecom provider in a joint call and add the contacts to the stakeholder register. Peak behaviour: a workshop with operations to capture history, summarised in the wiki.

Step 3 - Schedule it early. Put the sessions into the plan for weeks one to five, not in the last week. Reserve the time of Raj and Lena and adjust other assignments if needed.

Step 4 - Verify the transfer. Ask Lena to perform a failover test without help in week five. Where she hesitates, run an additional session.

Step 5 - Store and keep current. Place the material in the project repository, assign an owner, and tag it for the operations team that will inherit the platform.

Why not other choices? Relying on a written document in the last week would capture only part of the knowledge and leaves no time to check it. Hiring a replacement with no overlap loses the tacit knowledge. Asking Raj to remain available informally after he leaves depends on goodwill and on contract and legal conditions. The best approach combines several techniques, starts early, and verifies the result.

4. Foster an environment that supports knowledge transfer

Tools do not create sharing; culture and incentives do. People share knowledge when it is safe, rewarded and easy.

Conditions that help:

• Psychological safety. Mistakes can be discussed without blame. A lessons-learned session that looks for culprits produces silence.
• Leadership behaviour. The project manager shares their own mistakes, asks questions and thanks people who share.
• Time and space. Sharing is planned in the schedule (for example, one hour per week), not squeezed out by delivery pressure.
• Recognition and incentives. Contribution to the knowledge base, mentoring and teaching count in performance conversations. If experts are rewarded only for personal output, they will not share.
• Collaboration tools and practices. Wikis, shared channels, team spaces and co-location or regular video contact. The tools should be simple and used in daily work rather than being a separate chore.
• Diverse teams and cross-functional work. People from different backgrounds expose assumptions and spread skills.
• Trust across organisational boundaries. With suppliers and partners, contracts and relationships should allow the transfer of knowledge, including intellectual-property and confidentiality terms.
• Information radiators. Visible boards, dashboards and walls share status and decisions without meetings.

Barriers to remove:

Example: an environment that encourages sharing

A distributed team of 18 people across three time zones keeps a decision log, a shared wiki with a "how to" per component, and a weekly 30-minute "show and tell" in which one person presents something learned. Each retrospective produces one improvement and one lesson that is added to the repository. New members receive a buddy for their first month. After a year, the time for a new engineer to become productive drops from eight weeks to five, and the team survives the departure of two senior members without a delay. The project manager protects the weekly hour even when the schedule is tight, because the data show the payoff.

5. Knowledge transfer at key moments

Knowledge transfer is a continuous activity, but some moments need explicit planning.

In agile teams, knowledge is spread by cross-functional teams, pair or mob working, collective ownership of code, daily stand-ups, working agreements, retrospectives, and the visible backlog. The risk is that documentation is minimal; the team must still record what the next team or operations needs (decisions, architecture, support information). The Agile Manifesto values working software over comprehensive documentation, not the absence of documentation.

In predictive projects, formal documentation, stage-gate reviews, handover checklists and a lessons-learned register carry more of the weight, but tacit transfer remains necessary.

Example: handover to operations

A project delivers a payment gateway. The operations team is new to the technology. The project manager plans a six-week transition: week one, the operations engineers shadow project engineers; weeks two and three, they run the daily deployments with the project team observing; week four, they handle incidents with the project team on call as backup; weeks five and six, they run alone with a warranty-support line. Runbooks are written from real incidents, not from design assumptions. At the end, operations sign the readiness checklist. The project would have failed if the team had simply delivered a 200-page manual at the closing meeting.

6. Measuring and keeping knowledge current

A repository that nobody maintains is a hidden risk: outdated advice is worse than none. Good practice:

• Assign an owner and a review date to every knowledge item.
• Remove or archive obsolete items.
• Track simple indicators: number of single-person dependencies on the skills matrix, time to productivity of new members, usage of the repository, number of repeated issues, results of handover tests.
• Review the register of lessons learned at each phase or release, and feed relevant items into planning and risk identification of current and future projects.
• Update the organisational process assets (templates, checklists, historical data, lessons learned) at the end of the project.

7. Common pitfalls and exam tips

Pitfalls

• Waiting until the last week of an expert's contract to ask for documentation.
• Treating knowledge management as a tool purchase.
• Capturing only explicit knowledge and ignoring tacit knowledge.
• Collecting lessons learned only at closure, when people and memory are gone.
• Writing documentation nobody uses, owns or updates.
• Blame-oriented reviews that silence people.
• Depending on one person or one supplier for critical know-how.
• Forgetting the receiving team: operations or support must be involved before the handover.

Exam tips

• When a key expert will leave, the best answer usually combines early action, several techniques (documentation plus shadowing or pairing), and a check that the knowledge was transferred.
• Tacit knowledge needs interaction (mentoring, shadowing, pairing, communities); explicit knowledge needs documentation and repositories.
• Lessons learned are collected throughout the project, not only at the end.
• A safe, blame-free environment and protected time come before tools.
• When the scenario has a single point of failure, reduce it: cross-train, document, add a second person.
• In an agile team, knowledge is shared by collaboration and visibility, but the project must still produce the documentation needed for operations, compliance and handover.
• A handover is complete when the receiving party can operate or maintain the result, not when the documents are delivered.

8. Mini case study

Situation. You lead a 14-month project to modernise a hospital's patient-scheduling system. At month six, the lead clinical analyst, Dr. Okafor, who explains the rules for operating-theatre scheduling, announces that she will move to another hospital in eight weeks. The two other analysts understand the basic scheduling but not the exceptions (emergency overrides, equipment sterilisation windows, surgeon preferences). The vendor's developers rely on her for answers every day. The knowledge is mostly undocumented. A cutover to production is planned for month twelve. The sponsor says, "Just ask her to write a manual."

Question. What should you do?

Model solution.

1. Treat it as a risk and as a task. Add "loss of clinical scheduling expertise" to the risk register (high probability, high impact) and make knowledge transfer a planned work package with an owner and a date.
2. Identify the critical knowledge with Dr. Okafor and the analysts: list the scheduling rules and exceptions, their sources (policy, practice, regulation), who else knows them, and which are in code or documents.
3. Choose techniques by type. Explicit rules: capture them in a structured rules catalogue (decision table) reviewed with the clinical department. Tacit judgement: pair each of the two analysts with her on real scheduling cases (pairing and shadowing), run recorded walkthroughs of difficult scenarios, and hold a workshop with theatre nurses and surgeons. Relationships: introduce analysts to the theatre managers and the sterilisation unit.
4. Plan the time. Reduce Dr. Okafor's other duties for eight weeks, schedule two sessions a week, and agree on a possible limited consulting arrangement after her departure, subject to HR and legal conditions.
5. Verify. Ask the analysts to resolve a set of ten realistic exception cases without her; compare results with her answers; run another session on the gaps.
6. Store and use. Add the rules catalogue and recordings to the project repository, link them to the backlog or requirements, and make sure the testers and the operations team use them. Update the knowledge register with owners.
7. Reduce future dependency. Ask the sponsor to name a permanent clinical product owner, and add a second reviewer on rule changes.

The sponsor's suggestion alone would capture only part of what is needed, late, and without verification.

Key terms

• Knowledge management: activities that make knowledge available to those who need it.
• Explicit knowledge: knowledge that can be written down or coded.
• Tacit knowledge: knowledge from experience that is hard to articulate.
• Single point of failure: a task or knowledge item that depends on one person or source.
• Skills matrix: a grid showing who can perform which tasks.
• Shadowing / reverse shadowing: observing an expert / being observed by an expert while doing the work.
• Community of practice: a group of peers who share a field and exchange experience.
• Lessons learned register: a record of what the project learned, available to later work.
• Handover: the transfer of the result and the ability to operate it to the receiving team.
• Organisational process assets: templates, historical information and lessons stored by the organisation.

Summary checklist

• I can list the critical knowledge of a project and find single points of failure with a skills matrix and risk assessment.
• I distinguish explicit and tacit knowledge and match techniques to each.
• I start capture early, combine several techniques, and verify that transfer has worked.
• I create a safe environment, protect time for sharing and reward contributors.
• I plan transfer for onboarding, turnover, phase ends, supplier exits, handover and closure.
• I keep knowledge assets owned, current and used, and update the organisational process assets.

Official sources

• PMI, PMP Examination Content Outline (July 2026), People domain, Task 1.7: https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, New PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)