Project Knowledge: How to Stop Lessons Walking Out the Door

Most organisations have a lessons learned register somewhere. Most project managers have also sat in the workshop that fills it in: ninety minutes booked in the final fortnight, someone asking what went well, and a set of observations arriving months after anyone could have acted on them. The register is filed. The next project begins by asking the same questions from scratch.

The difficulty is rarely that people refuse to write things down. It is that the writing down happens at the point where the knowledge has the least remaining value to the project that produced it, and where the people holding it have already started to move on. Knowledge on a running project is a live asset. It is what someone knows about why a supplier was chosen, which part of the integration behaves unpredictably under load, which stakeholder needs a conversation before a paper, and what has already been tried and abandoned. All of that decays quickly, and it decays whether or not anyone records it.

A more useful starting point is to ask what decision the knowledge is supposed to serve. Once knowledge work is attached to a decision someone has to make this month, it stops feeling like an administrative obligation and starts behaving like any other project control.

The knowledge a register can hold

Some of what a project knows is explicit. Requirements, configurations, test results, contract terms, approved changes, cost actuals and the record of who decided what and when can all be written, stored and retrieved by someone who was not there. This is the kind of knowledge that documentation genuinely handles well, and the practical work is mostly about findability: whether a new team member can locate the current version in ten minutes without asking a colleague who is already busy.

The rest is tacit, and it sits in people. It includes judgement about which supplier commitments are reliable, the feel for how long an approval actually takes in this organisation as opposed to how long the process says, the awareness that one operations manager will support a change if consulted early and resist it if presented late. Tacit knowledge resists capture because the person holding it often does not know they hold it. It moves mainly through contact: working alongside someone, talking a problem through, watching how a difficult meeting is handled.

Managing project knowledge therefore has two quite different halves. One is making recorded knowledge usable. The other is creating enough contact between people for the unrecorded kind to transfer before the opportunity closes. Teams that treat the whole subject as a documentation exercise solve half the problem and then wonder why experience keeps leaving anyway.

The PMBOK® Guide Eighth Edition places Manage Project Knowledge at Section 2.1.6, within the governance domain, alongside integrated planning, performance monitoring and change. That placement is a reasonable clue about how to treat it. Knowledge is part of how the project makes and supports decisions, and it belongs with the mechanisms that keep those decisions sound.

What actually walks out the door

A mid-sized financial services firm was fourteen months into replacing its payments reconciliation platform. The lead business analyst accepted a role elsewhere and worked six weeks' notice. Governance was in reasonable shape: the traceability matrix was current, the risk register was reviewed fortnightly, the decision log recorded every significant call with its date and approver.

Three weeks after she left, a tester raised a defect against two exception categories that were not being matched automatically. The team could not find anyone who could say whether this was a fault or a design choice. The decision log showed the choice, the date and the name of the person who had approved it. It did not show why. The reasoning had been a specific interpretation of a regulatory reporting requirement, confirmed verbally by the finance director's team, combined with a volume assumption about how rarely those categories occurred. None of that was anywhere, because none of it had felt like knowledge at the time. It had felt like context.

The team reopened a question that had been settled six months earlier, spent three weeks re-establishing the same answer, and raised a change request to cover the rework. The artefact was complete by its own standard and useless for the question that arrived.

One habit prevents most of this, and it costs a sentence. For each significant decision, record what would have to change for the team to decide differently. That single line captures the reasoning rather than the outcome, and it doubles as an early warning: when the named condition changes, someone knows to revisit the decision rather than discovering the problem through a defect six months later.

Departures are only the most visible version of the loss. The same gap opens through reassignment, phase transitions, supplier handovers, a long sickness absence, and the ordinary distance between one person learning something on a Tuesday and another person needing it in a different workstream a month later.

Where knowledge work actually fits

The instinct to create a knowledge workstream, with its own owner and its own cadence, is usually a mistake. It adds a meeting that competes with delivery, and it will be the first thing cut when the schedule tightens. Knowledge work survives when it is attached to events that are happening anyway.

Retrospectives and stage reviews are the obvious hosts, provided they are judged by what changes afterwards. A retrospective that produces one adjustment the team makes this week is worth considerably more than one that produces twelve observations and no action. Risk reviews are another, because a risk discussion is already a conversation about what the team knows and does not know, and the register entry for a threat nobody understands well is itself a knowledge item. Supplier performance meetings, onboarding conversations and handovers between phases all carry the same opportunity.

Delivery approach changes the mechanics rather than the principle. Adaptive work has a structural advantage here, because short cycles give frequent, low-ceremony moments to surface learning while it is still fresh, and a team that reprioritises every fortnight is constantly restating what it now believes. Predictive work has fewer natural moments but firmer ones: phase boundaries and gate papers are good places to ask what has been learned that changes the plan ahead, as long as the question is asked before the paper is drafted rather than after it is approved. Hybrid delivery needs both, and needs someone to make sure that what an iterative team learns about the product reaches the governance forum making the funding decision.

For tacit knowledge, the mechanisms are more human and less documentary. Pairing a new analyst with an experienced one for a fortnight transfers more than any handover pack. Asking a departing colleague to walk through their three most contentious decisions on a call that someone records is fifteen minutes of work and often the most valuable fifteen minutes of their notice period. Getting the person who understands the integration to explain it to the person who will maintain it, in front of the actual system, moves knowledge that no document has ever held.

There is an opposite failure worth guarding against. A team that logs everything builds a repository nobody searches, and volume becomes its own barrier. Choosing what matters is the skill: the knowledge worth protecting is the knowledge whose loss would force someone to redo work, rerun a decision or rebuild a relationship. Knowing how to make that judgement under delivery pressure is one of the capabilities that structured PMP® preparation develops, because it forces you to reason about proportionality rather than reaching for a template.

Who holds the knowledge after handover

Project knowledge has two destinations, and they are commonly confused. Some of it belongs to the organisation and should improve how future projects are run. Some of it belongs to whoever will operate, support or extend the thing that has been built, and it is far more urgent, because the handover date is fixed and the receiving team has to function from that morning.

The second destination is the one that gets squeezed. Closure activities compress, the operations lead receives a folder rather than a conversation, and the support desk spends its first quarter rediscovering the reasoning the project team already had. Planning that transfer early, and naming who on the receiving side is accountable for absorbing it, converts closure from an administrative tidy-up into something that protects the value the project was funded to create.

For a PMP candidate, the useful thing to notice is where knowledge sits in the current Examination Content Outline. It appears in the People domain as a task about ensuring knowledge transfer, which covers identifying critical knowledge, gathering it and creating an environment where transfer happens. It appears again in the Business Environment domain as part of continuous improvement, where lessons learned feed back into organisational process assets. Closure carries it too, through final lessons and retrospectives. Those are three different responsibilities rather than three descriptions of the same register, and the word identifying in the first of them is doing real work: the expectation is triage, not exhaustive capture.

The practical test on your own project takes about ten minutes. Choose a decision the team made three months ago that still constrains the work. Ask whether anyone currently on the project can explain not just what was decided but what the decision depended on. If nobody can, the knowledge has already gone, and nobody noticed it leaving.

Andre Malowney

Interested in going further?

Deciding which knowledge is worth protecting, and where transfer belongs in the governance of a live project, is the kind of proportionality judgement that structured preparation sharpens. Omega's PMP® Exam Preparation works through these decisions in realistic delivery situations rather than as definitions to memorise.

The PMBOK® Guide Eighth Edition sets Manage Project Knowledge among the governance processes, which is the clearest statement of why this is a decision-support activity rather than a documentation one.

Ad · Amazon affiliate link.

References

A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What's the Difference?
A092: How Projects Create Value Through Governance
A093: Choosing a Project Governance Model
A094: Governance Metrics That Actually Tell You Something

PMP and PMBOK are registered marks of the Project Management Institute, Inc.