Skip to main content
All resources

Guides

Building proposal knowledge that survives turnover

General advice on institutional knowledge does not fit proposal work. What actually leaves when a senior colleague does, and how to capture it before they go.

Why the general advice does not fit this problem

Search for institutional knowledge loss and you will find human-resources guidance: mentorship programmes, exit interviews, documentation drives, recorded walkthroughs. It is reasonable advice for operational knowledge, and it mostly misses what proposal work loses. Proposal knowledge is not procedural — nobody forgets how to write a technical approach. It is evaluative. It is knowing which of the forty projects in the archive is the right one to cite for this client, and why the obvious choice is the wrong one. No exit interview surfaces that, because the person leaving does not experience it as knowledge. They experience it as an opinion they happen to hold.

Our reading, not a rule
The distinction between procedural and evaluative knowledge in proposal work is ProposalOS's framing of the problem, offered as a way to explain why generic knowledge-management advice underperforms here.
Institutional knowledge is not what your team knows. It is what your team can still retrieve after the person who knew it has gone.

The knowledge that actually walks out

Documents rarely leave — they sit in a shared folder. What leaves is the judgement around them: which of four similar methodologies suits a municipal client, why a particular reference is stronger than it looks, which regulator reads submissions literally. That knowledge is uncaptured precisely because it was never written down for anyone else.

  • Which past project to cite for a given kind of client, and which one looks comparable but scores badly.
  • Why a bid was declined two years ago, and whether the reason still holds now the tender has reissued.
  • What a particular evaluator or authority has objected to before.
  • Which colleague actually did the work on an assignment, as distinct from who was named on the contract.
  • Which paragraphs in the last submission were rewritten at review, and what was wrong with the originals.

Capture at the moment of use, not in an exit interview

Asking someone to document ten years of judgement in their final fortnight produces a thin document nobody reads. The alternative is to capture each decision as it is made: when a contributor chooses a methodology for a section, the reason for choosing it is worth one sentence, recorded then. Over a year of proposals that accumulates into something a successor can actually use. The cost is seconds at the moment the judgement is fresh, which is the only moment it is cheap.

The test that tells you whether it worked

There is one question worth applying to any proposal repository, and it is not whether the material is there. It is this: can a colleague who was not involved in the last submission tell which version of a document is the approved one, and see which project record a claim about past experience rests on, without asking anybody? Until both are true, what you have is storage — a place to look rather than something to draw on. Most firms that believe they have solved this have solved the first half and not the second.

Give every reusable item four properties

This is the minimum that turns a file into something reusable by someone who did not create it. Fewer than four and a successor still has to ask.

  1. An owner — a named person responsible for whether it is still true, not the person who happened to upload it.
  2. A version — so "the latest one" is a fact rather than a guess about file dates.
  3. An approval state — whether the firm stands behind this, or whether it is a draft somebody left in the folder.
  4. A link to its evidence — the certificate, contract or record that supports the claim, attached to the claim rather than filed separately.

What to review, and how often

Reusable knowledge decays. A certification expires, a methodology is superseded, a reference contact changes employer. Reuse without review is how a confident, outdated claim reaches an evaluator.

  • Certifications and registrations — check against their expiry date, not on a calendar.
  • Project references — confirm the contact annually, before you cite them again.
  • Methodologies — review when the practice changes, and record who approved the change.
  • Company facts such as headcount or turnover — refresh at each financial close.

Where this pays off

The return is not felt on the submission you are working on. It is felt on the one after the person leaves — when the successor finds the right project reference in ten minutes instead of asking three colleagues and settling for the one everybody remembers. That is also why the investment is hard to justify in the moment and obvious in hindsight, and why the practical answer is to build it out of work you are doing anyway rather than as a project of its own.