9 barriers to knowledge transfer in project-based organizations

Every project teaches the organization something. The hard part is making sure the next project gets to use it. In most companies the lessons are real, the documentation is even halfway decent, and yet the next team still steps on the same rake the previous one did six months ago.

That gap, between knowledge generated and knowledge applied, is the single biggest source of avoidable waste in project-based organizations. A PMO that closes it turns the entire portfolio into a learning system. A PMO that does not turns every project into a fresh start.

The framework below comes from B. H. Reich’s PMJ research on knowledge management in projects, updated for the way distributed, AI-assisted teams actually work in 2026.

Why knowledge transfer in projects is its own problem

Knowledge management in an R&D lab or a product team is hard, but at least the team stays together. Project work is different: teams form, deliver, dissolve. The expertise that built one project walks out the door, often before anyone has thought to capture it.

That structural fact reshapes the whole problem. The PMO is not just running a wiki; it is running a relay race where the baton has to survive a dozen handoffs. The barriers below all come back to one of three failures: lessons never captured, lessons captured but unfindable, or lessons available but ignored.

1. Lessons never actually learned

The most common failure is the easiest to describe and the hardest to fix. The retro happens, somebody writes notes, the notes go in a folder, and nobody reads them on the next project.

The fix is not “do more retros.” It is to make past lessons impossible to miss when starting a new project. Two habits do most of the work:

• Maintain a searchable repository, tagged by client, sector and project type, so the kickoff team can pull only the lessons that match the work in front of them.
• Treat the previous baseline as an artifact, not a memory. ITM Platform stores the approved schedule, effort and cost of every project as a reusable baseline, so a new team can see exactly what was planned, what changed and why before they commit to their own estimates.

2. Picking the wrong team for the work

Even with a competent group of people available, the right combination of skills for a specific project is hard to spot. Aggregated experience, tacit know-how, and the multicultural dimension on international projects are all invisible on a CV.

Planners who are not deep experts in every technical area will inevitably mismatch requirements and capacity. The result is a team that cannot transfer knowledge internally because some of the knowledge it needs simply is not in the room.

A PMO that maintains structured profiles of past roles, skills and project outcomes (often as custom fields on people and projects) gives planners a fighting chance to staff the work correctly the first time.

3. Volatile project governance

When a member of the governance structure leaves mid-project (executive sponsor, steering committee chair, even the PM) the team loses more than a name on a chart. They lose the unwritten context: why scope was cut, why a vendor was preferred, what the sponsor will never approve regardless of how it is dressed up.

The mitigation is to document the decisions and the rationale, not just the outcomes. A status report that says “we cut feature X” is a lot less useful six months later than one that says “we cut feature X because the sponsor flagged regulatory risk in Q2.”

4. Lack of recognition for the knowledge management function

In most organizations, knowledge transfer has no owner. Project managers think the PMO does it. The PMO thinks the line managers do it. Line managers think it happens by osmosis. Nobody is wrong, and nobody is doing the work.

The most effective PMOs treat knowledge transfer as a named deliverable with a cadence, a budget and a person accountable. It does not have to be a big program; it has to exist on someone’s job description.

5. Inadequate knowledge integration

Large projects require expertise from many domains. The risk is not that the experts are wrong individually, but that nobody is responsible for fitting their pieces together coherently.

This is where the project manager earns the role. The PM is not the deepest expert on any single topic and should not pretend to be. The PM’s job is to make sure the experts are communicating, the interfaces between their work are explicit, and the integrated result still makes sense to the customer.

6. Incomplete transfer from external suppliers and consultants

Complex projects almost always pull in outside specialists. The transfer between the consultant and the project team is where critical knowledge most often goes missing, usually for understandable commercial reasons: the consultant wants to protect intellectual property, the team is rushed, and nobody schedules a serious handover.

Most failures attributed to “the vendor did not deliver” are in fact failures of knowledge transfer at the design stage. Preventive measures help:

• Define the handover artifacts in the contract, not after the kickoff.
• Insist on a working demo, not a slide deck, as the proof of transfer.
• Have an internal counterpart shadow the consultant from day one.

7. Loss of team members

When a key person leaves, planned or otherwise, an irreplaceable chunk of context goes with them. Some of it can be documented; some of it is genuinely irrecoverable.

The realistic goal is not to capture everything, it is to capture the most expensive things to relearn. A short interview at the moment of departure, focused on decisions taken, vendors trusted and traps avoided, is worth ten generic “exit documents.”

For broader patterns on team continuity and resourcing, our piece on project human resource management digs deeper into how to plan for these handovers before they happen.

8. No role-based knowledge map

Most teams do not actually know who knows what. The result is escalation roulette: a question lands with the most visible person rather than the most informed one, decisions get made by the wrong people, and the right experts stay buried.

A role-based knowledge map (who owns what skill, who has done this kind of work before, who is the second name on the call if the first is unavailable) makes the team’s competence legible. Researchers like Crowston and Kammerer, and Faraj and Sproull, have documented for decades that teams with this kind of map outperform on integration-heavy work.

In 2026 the map does not have to be a static document. With AI-assisted portfolio tools you can ask the system directly. PMPilot, ITM Platform’s AI assistant, lets PMOs query the portfolio in plain language, including questions like “who has worked on data migration projects in the last two years” through its data analysis layer.

9. Loss of knowledge between phases

As a project moves from design to build, from build to test, from test to operations, the team composition changes. Each handover is an opportunity to lose context.

Written documentation alone rarely survives the trip intact. Subjective interpretations creep in, the rationale behind a design choice gets stripped out, and the next phase ends up rediscovering why an earlier decision was made.

Two habits push back:

• Capture the why, not just the what. A short paragraph explaining why a decision was made saves the next phase from re-litigating it.
• Use multimedia where it helps. A two-minute recording from the outgoing lead is often clearer than two pages of prose.

How a PMO turns these barriers into a system

None of these nine obstacles is solved by a single tool or a single template. What a serious PMO does is build a quiet, repeatable system:

• A baseline of what was planned on every project, so the next team starts from data, not memory.
• A library of what changed and why, so context survives handovers.
• A skills map that is queried, not just maintained, so the right people get pulled into the right work.
• A handover protocol for both internal team transitions and external supplier exits.

Each of those is a small habit. Stacked together, they are what separates an organization that learns from one that just runs projects.

Next steps

• Browse our PMO articles for more on building a learning-oriented project office.
• See how ITM Platform supports portfolio-wide visibility, baselines and AI-driven analysis from a single workspace.