Key Concepts
Knowledge is one of the most valuable things a project produces, and it needs deliberate transfer or the organization loses twice: once when the team disbands, and again when the next project relearns the same lessons. This task covers explicit knowledge, which can be documented, and tacit knowledge, which transfers only when people spend time together.
During the project lifecycle, the team, project manager, and stakeholders will learn a great deal about the business problem, the technical domain, and the specifics of the product or service being created. That knowledge is one of the most valuable things the project produces. If it walks out the door when the team disbands, the organization loses twice: once when the project ends, and again on the next project that relearns the same lessons from scratch.
Knowledge transfer is not a closing activity. It runs through the entire project, from the moment a team member learns something worth sharing, to the final handover of the product to the people who will support it. Project managers play a critical role in providing the tools, time, and environment to make this happen.
Types of Knowledge
Before we can transfer knowledge, it helps to understand what kind of knowledge we are dealing with. Knowledge falls into two broad categories.
- Explicit knowledge is information that can be recorded with words, pictures, or numbers. It is the knowledge we can store in documentation, models, diagrams, and notes, then share with others. Specifications, process guides, lessons learned registers, and decision logs are all examples of explicit knowledge.
- Tacit knowledge is personal knowledge that is harder to describe and share. It includes beliefs, experience, intuition, and judgment accumulated over time. A senior developer who instinctively knows which part of the codebase is fragile holds tacit knowledge that no document fully captures. So does a project manager who has learned how a particular sponsor communicates under pressure.
Both types matter, and both require deliberate attention. Explicit knowledge is easier to transfer but often neglected because people assume documents will speak for themselves. Tacit knowledge requires people to spend time together, ask questions, and work alongside each other. Neither transfers automatically.
Agile practitioners often claim co-located teams help share and boost tacit knowledge. While it is true that working alongside someone certainly helps accelerate the adoption of the beliefs, experience, intuition and insights that make up tacit knowledge, there is also a division in definitions too.
Agile teams often use the term “tacit knowledge” to describe all unwritten expertise. Such as how to reset the 3D printer, the fact that daily stand-ups occur 30 minutes later on Mondays, and the unwritten agreement to hold meetings in the afternoons to allow people to get work done in the mornings etc. This is tacit knowledge because it is not documented and is created by mutual agreement, but it could be written out if people took the time to record it, and more importantly, people took the time to seek it out and read it.
So if coming from an agile background, be aware of the true definition of tacit knowledge when approaching this subject for the PMP® exam. It is not “all the undocumented team knowledge”; it is more the things that cannot be documented like experience, intuition and decision making based on hard to define criteria.
1.7.1 Identify Knowledge Critical to the Project
Not all knowledge is equally important to transfer. A project generates an enormous volume of information, and trying to capture everything produces noise rather than insight. The first task is identifying which knowledge is genuinely critical. What does the organization need to retain in order to operate what the project delivered? What does it need in order to avoid repeating the same mistakes on future projects?
Knowledge exists at three levels, and we need to identify critical knowledge at each one.
Individual Knowledge
At the individual level, team members carry knowledge about how to perform their work correctly, including the scope, constraints, and decisions that shaped it. This includes reading specifications, WBS descriptions, and user stories, but also the unwritten understanding of why certain choices were made and what alternatives were considered and rejected.
Project Knowledge
At the project level, the project manager holds knowledge about how this project fits into the organizational landscape. This includes what dependencies exist, what relationships were built, what risks materialized, and what worked or did not work in terms of approach. The PMO can be an excellent source and destination for this level of knowledge, since it exists to define and maintain standards across projects.
Organizational Knowledge
At the organizational level, the focus is on executing agreed strategy through portfolios, programs, and projects. Portfolio and program managers seek knowledge that can be adapted from one initiative and applied to others, building the organization’s collective capability over time.
A useful framework for the full knowledge transfer lifecycle comes from PMI’s Pulse of the Profession research. It identifies five activities: identifying what knowledge needs to be transferred, capturing it, establishing methods for sharing it, applying it to new work, and assessing whether the transfer was effective. Most organizations invest in the first two and neglect the last three, which is why the same lessons keep being relearned.
1. Identifying: Determine what knowledge needs to be transferred
2. Capturing: Accumulate the essential knowledge that needs to be transferred
3. Sharing: Establish methods for transferring the knowledge
4. Applying: Use the knowledge that is transferred
5. Assessing: Evaluate the benefits of the knowledge that is transferred
This model is a helpful framework for understanding the activities that need to occur for effective knowledge transfer. As project managers, we need to ensure that stakeholders understand their roles in these activities and that time and tools are available for their application.
When identifying critical knowledge, practical questions to ask include: what would a new team member need to know to continue this work? What decisions were made that are not documented anywhere? What would be lost if the three most experienced people on this project left today?
1.7.2 Gather Knowledge
Gathering knowledge means systematically collecting, analyzing, and organizing the information identified as critical so that it is available to others. This is the capture step, and it requires both the right mechanisms and the right culture.
Lessons Learned Sessions
A common mistake is to treat lessons learned as a closing activity only. By that point, the team is tired, people have mentally moved on, and the specific details of what happened and why have already begun to fade. Lessons learned reviews should be conducted after every significant phase or milestone, not just at project end. More regularly scheduled events generate richer information and build the habit of reflection throughout the project.
Getting honest input requires the right environment. Organizations need to capture both positive and negative experiences, but people are often reluctant to discuss failures openly.
Gathering and learning from lessons helps prevent reinventing the wheel and struggling with the same issue repeatedly within your project or across your organization. So, some time and effort spent documenting lessons learned can pay big dividends in the future – assuming we genuinely learn from them.
Some tips for getting the most out of lessons learned session include:
1) Consider multiple sources of lessons. Ask what did we learn from:
- Implementing organization strategy
- Scheduling and planning
- Vendor management
- Working with customers and clients
- Teamwork
- Conflict management
- Other lessons learn
2) Model the desired behavior – be open and transparent about sharing negative information and errors made with the team to demonstrate it is OK to communicate this type of information. For instance, it is OK to say, “I noticed an error on the status report and am sending it out again.”
3) Record findings in the Lessons Learned Register – during or immediately after the session, not days later when memory fades
Then, at the end of the project or phase, transfer the register contents into the organizational Lessons Learned Repository so future projects can benefit.
Lessons Learned Register
The Lessons Learned Register is the primary artifact for capturing explicit project knowledge. It records knowledge gained during the project so that it can be used within the current project and later entered into the broader organizational repository. The register typically contains the category and description of a situation, its impact on the project, recommendations, and any proposed actions. It should record successes and failures, challenges and surprises, and anything the team would do differently. At the end of a project or phase, the information is transferred to the Lessons Learned Repository.
Lessons Learned Repository
The Lessons Learned Repository is the organizational store that collects lessons learned from across all projects. Where the register belongs to a single project, the repository belongs to the organization. It is the institutional memory that allows future teams to learn from the experiences of those who came before them. A repository is only as useful as the quality of what goes into it, and only as valuable as the frequency with which people consult it. Both require deliberate habit and organizational support.
On predictive projects, lessons learned sessions are typically scheduled at phase gates and at project closure. They are facilitated workshops involving the core team and key stakeholders. The outputs are documented in a Lessons Learned Register and rolled up into the organizational repository. A final project report often includes a consolidated summary of lessons learned covering scope, schedule, cost, risks, stakeholder relationships, and vendor performance.
Agile Knowledge Sharing
Agile approaches replace end-of-phase, and end-of-project lessons learned reviews for much more frequent retrospectives that occur every sprint or iteration.
The “Learn” step in an iteration includes the Demo that reviews the latest increment of the evolving product and the team retrospective. The retrospective is a workshop that captures insights similar to a Lessons Learned Review and, as a minimum, asks:
- What Went Well?
- What Did Not Go Well?
- Any Recommendations or Experiments to Try in the Next Iteration?
Good retrospectives drive change and experimentation. So, there is often more emphasis on brainstorming and voting on changes to try in a retrospective than traditional teams likely discuss in a lessons learned review.
Information Radiators and Transparency
Agile teams take a different view for sharing knowledge than traditional project management approaches. Instead of documenting project information in plans, specifications, logs and registers, they favor big-visible-charts called Information Radiators.
Information radiators are typically flipcharts, graphs, drawings or kanban boards displayed in high traffic areas, or on easy-to-find websites that share information with as many relevant stakeholders as possible.
The agile principle of “Transparency” promotes open and honest sharing of information to raise everyone’s awareness of work, progress and issues. It is a form of knowledge transfer similar to the goals of traditional knowledge sharing to help current and future projects – just implemented with a different set of tools.
1.7.3 Foster an Environment for Knowledge Transfer
Capturing knowledge in a register is necessary but not sufficient. Knowledge only transfers when individuals actually connect, absorb, and apply what they have learned. Fostering an environment for this to happen means treating knowledge as a project asset and building the structures, time, and culture that allow it to flow.
Knowledge as an Asset
Document explicit knowledge for archiving and sharing, and do it in a form that future readers can actually use. A lessons learned register that lists only “Communication could have been better” provides no actionable value. Specific descriptions of what happened, why, and what would be done differently are what make the register worth reading. Treat the register as you would a deliverable: assign ownership, allocate time to complete it, and review its quality before filing it.
Encourage individuals to share tacit knowledge through collaboration rather than assuming documentation alone will do the job. Some of the most valuable project knowledge is never written down because people do not realize it is worth recording, or because it is difficult to articulate. Creating opportunities for people to work alongside each other, ask questions, and discuss decisions in real time is how tacit knowledge actually moves between people.
Knowledge Transfer Mechanisms
The channels through which knowledge moves can take many forms. Practical mechanisms include the following.
Communities of Practice
A Community of Practice is a group of people who share a common interest and learn by engaging in shared activities, exchanging knowledge, and building a shared collection of practices and resources. Communities of Practice create ongoing channels for knowledge flow that extend beyond any single project, allowing practitioners across the organization to learn from each other continuously.
Job Shadowing
Job shadowing is a direct observation method where one individual observes another performing their work within their normal work environment. It is particularly effective for tacit knowledge that is difficult to capture in writing, because the observer can ask questions in context and see judgment and decision-making in action rather than just reading about it.
Networking, Meetings, and Training
Networking and social events create informal connections that make knowledge-sharing conversations more likely to happen, because people share more freely with colleagues they know and trust. Meetings, seminars, and training sessions that include interaction between participants, rather than one-way delivery of information, generate deeper learning and broader transfer than passive formats.
Project Repositories and Wikis
Project repositories and wikis provide accessible stores of explicit knowledge that team members and future project teams can consult. These work best when they are easy to search, regularly maintained, and actively pointed to rather than passively existing on a server somewhere. A repository that nobody knows about or nobody updates is not a knowledge management tool; it is a graveyard for documents.
As project managers, we can support knowledge transfer by scheduling lunch-and-learn sessions, inviting speakers, and making sure time is allocated for learning in the project plan. If knowledge transfer is not in the schedule, it will not happen.
Minimizing Knowledge Loss at Handoffs
Any handoff from one group to another can result in information loss. When a project transitions from a delivery team to an operations team, from one phase team to another, or from the project to the customer, knowledge leaks at the boundary. The receiving group does not know what it does not know, and the outgoing group often underestimates how much contextual knowledge they carry that was never written down.
Strategies to minimize this loss include keeping the same people involved across handoffs where possible and running structured knowledge transfer sessions before key transitions. Pairing incoming team members with outgoing ones during a handover period helps surface tacit knowledge. Building detailed transition plans that cover not just what is being handed over but the reasoning behind key decisions is equally important.
Hybrid projects often face difficult knowledge transfer challenges because they combine teams, tools, and working styles from both predictive and agile traditions. Knowledge captured during the predictive planning phases may not be accessible to the agile delivery teams who need it. Meanwhile, the tacit knowledge built up through iterative delivery may never make it into the formal project record.
Building deliberate bridges between these two knowledge streams helps make sure neither is lost at project closure. This might include incorporating agile retrospective outputs into the formal lessons learned register, and ensuring the product backlog reflects key planning decisions.
Remote Teams and Knowledge Transfer
Remote teams present a particular challenge for knowledge transfer. Without co-location, tacit knowledge is much harder to recognize and share. The water-cooler conversation, the overheard discussion, the informal question asked while walking past someone’s desk, these are all knowledge transfer moments that disappear in a distributed team.
At the same time, remote teams have one advantage: everyone is on an equal footing. There is no division between onsite and remote workers, and everyone relies on the same electronic tools and documented information. This levels the playing field in a way that co-located teams with some remote participants rarely achieve.
Successful all-remote organizations tend to share a common set of habits. They write things down explicitly rather than relying on verbal explanations. They make documentation publicly available rather than restricting it on a need-to-know basis. They also prioritize asynchronous communication that creates a written record over synchronous communication that leaves no trace. These habits, applied deliberately, can significantly improve knowledge transfer in any distributed team environment.
Deliverables and Tools
- Lessons Learned Register
- Lessons Learned Repository
- Retrospectives
- Communities of Practice
- Job Shadowing
- Project repositories and wikis
- PMIS (Project Management Information System)
- Knowledge transfer lifecycle (Identify, Capture, Share, Apply, Assess)
- Lunch-and-learn sessions
Related Topics
FAQ
What is explicit knowledge?
Information that can be recorded with words, pictures, or numbers, such as specifications, process guides, lessons learned registers, and decision logs.
What is tacit knowledge?
Personal knowledge that is hard to describe and share, including beliefs, experience, intuition, and judgment.
How does tacit knowledge transfer?
It requires people to spend time together, ask questions, and work alongside each other; it does not transfer automatically.
Is knowledge transfer a closing activity?
No. It runs through the entire project, from the moment a team member learns something worth sharing to the final handover of the product.
How does this task fit into the 2026 PMP exam?
Task 1.7 sits in the People domain of the 2026 Exam Content Outline. The 2026 PMP Exam page has the domain and task breakdown and what changed in the new exam.
Mastery Map and Quiz
Congratulations! You earned the Knowledge Transfer badge.