Knowledge Management

Integration technique · See it on the map

Guide only — Names whatever knowledge-management systems the org runs.

Moving know-how from the person who has it to the person who needs it.

When to use it

Onboarding someone into judgment a document can't transmit — reading a vendor's estimate skeptically, running a tense negotiation, recognizing a risk that looks routine but isn't. Also use it continuously through the project, whenever a decision's reasoning is worth more to a later reader than its outcome alone.

When to avoid it

When what's actually needed is a fact, a figure, or a document that already exists — routing that through a mentoring conversation instead of a lookup wastes both people's time and belongs to information management instead. Also avoid running it only as a single closeout ceremony: see the lessons-learned pitfall below.

Steps

1. Identify who holds knowledge nobody else on the project has — the estimator who's negotiated with this vendor before, the PM who's run this kind of cutover.
2. Build a standing way to connect them to whoever needs it: pairing, a short recurring retro, a community of practice — not a one-off exit interview when someone is already walking out the door.
3. Capture lessons as they happen into the project's lessons-learned narrative body, with enough of the reasoning attached that a later reader gets the 'why', not just the headline.
4. Make that narrative something people actually open mid-project — attach it to the decisions it should inform, a similar change request or a similar risk — rather than filing it and moving on.
5. Before anyone rolls off the project, have them walk a successor through the judgment calls they made, not just the documents they left behind.

What it produces

• A lessons-learned narrative body that grows continuously through the project, carrying the reasoning behind decisions, not only their outcomes.
• Working relationships and habits — pairing, a recurring retro — that are not themselves an artifact but are the reason later artifacts read as informed rather than boilerplate.

Common pitfalls

• Lessons-learned theatre: a body written entirely at project closeout, when nobody is still around to act on it and nobody starting the next project reads it going in. driftless models lessons learned as one prose body per project, and a body that stays empty until the closeout meeting is a symptom of this, not a deliverable in its own right — capturing it continuously, into something people actually consult mid-project, is what makes the closeout version worth reading.
• Treating 'wrote it down' as the finish line — writing it down is information management; getting two specific people talking about a specific judgment call is the harder job this technique is actually for.
• Recording only the outcome of a decision and losing the reasoning behind it — a later reader who never saw the judgment exercised can't reuse it, only imitate the outcome blindly.
• Tying it to a single milestone instead of threading it through the project as a habit — a short retro every few weeks surfaces more usable knowledge than one retrospective at the end.

Worked example

A mid-size ERP migration runs a 20-minute retro at the end of every sprint, not just at project close. Partway through, the integration lead who handled a similar migration two years earlier explains, in that retro, why they insisted on a parallel-run week before cutover instead of a big-bang switch — a call that appears in no document because it was a judgment call made under uncertainty. The PM adds two sentences to the project's lessons-learned narrative capturing the reasoning, not just 'ran a parallel week'. When a similar cutover risk shows up in a later phase, a PM who wasn't in that room reads why the earlier call was made and reuses the reasoning, instead of repeating a checklist item without understanding it.

Source

• PMBOK-6 §4.4.2.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.