A project knowledge base that is still useful in month eight

Give the project a front door

A project notebook needs one note that explains how to use the rest of it. We call ours “Start here” and pin it. It says what the project is for, what stage it is at this month, and the two or three questions the team is trying to answer right now. Then links: the brief, the research notes, the decisions, the reference material people keep asking for.

The person this note is written for joined last week and does not want to ask who owns which document. If they can read “Start here” and open the right thing without a message in chat, the note works. If they ask anyway, the note is missing something, and that question tells you what.

Keep it short. Ours is under 200 words and has been rewritten four times. The first version was a page and a half, and I am fairly sure nobody read past the second paragraph. A front door is a door, not a lobby.

Organize around the questions people actually ask

A structure that works mirrors how people look things up, not how the company is organized. On a research project the questions are usually: what do users need, why did we pick this direction, which constraints still apply, and where is the raw material. Each of those deserves a note or a small group of notes. The org chart does not.

We got this wrong first. Our first project notebook had sections named after teams: Design, Engineering, Marketing. Within a month the same decision lived in two of them with slightly different wording. When we rebuilt it around questions, duplicates disappeared on their own, because a decision only answers one question.

Titles should say what a note contains, not where it came from. “Research, first-time import, April” is recognizable in a list of forty. “Notes 3” is not. We also use a handful of hierarchical tags like “status/active” and “status/superseded” so you can filter without opening anything.

Someone has to own the meaning, not the permissions

A shared notebook does not maintain itself, and giving everyone the manage role does not change that. What works is an agreement in plain words, written into “Start here”: Ihor keeps the front door accurate; whoever changes a decision updates the decision note the same day. That is the whole policy. No approval chain, no new hierarchy.

Ownership here means keeping the meaning current. It does not mean approving every edit. Version history covers the case where someone changes a sentence badly; you can see what changed and who did it, and roll back if needed. What history cannot do is tell you that a decision from February is now wrong. Only a person can.

Review at a natural boundary: the end of a research round, a release, a quarter. Ask a colleague who did not write the notes to find one specific thing, say the reason behind a constraint. Time how long it takes. If it is more than two minutes, the fix is usually a link from “Start here”, not a new section.

Close the project without rewriting its past

When the work ends, add a closing note: what was delivered, which ideas stayed open, where the final materials live. Then move the notebook into a stack with an obvious name like “Done 2026” and check who still has access. That is a twenty-minute job, and skipping it is how a knowledge base turns into a graveyard.

Resist the urge to tidy old decisions so they match the final outcome. If the team chose direction A in March and switched to B in June, both notes should stay as written, with a line on A that says “superseded by B, see decision of June”. A future project is far more likely to want the method or the constraint than the deliverable, and the method lives in the messy middle.

I have deleted an old project notebook exactly once, and I regretted it within a month when somebody asked why we had ruled out a vendor. Trash keeps things for 30 days. After that it is gone, and so is the reason.

A worked example: Ihor’s study of how people sort their notes

Ihor leads a three-person research project: how do people organize a collection of a few thousand notes? The notebook starts with “Start here”: the question, what is in scope (personal collections, not team wikis), who is involved, and where the raw interviews live. A second note describes the method: eight interviews, forty minutes each, a fixed set of six questions and one open one.

Each interview gets its own note with the recording attached and the moments that mattered marked by timestamp. Observations stay linked to their interview; a synthesis note explains patterns without pretending the sample is bigger than eight. When the team decides to drop a planned survey, the decision note says why: two pilot responses showed people could not estimate their own note counts, so the numbers would be noise.

Two months in, a designer from another project needs to know which interview mentioned renaming notebooks. Full-text search over the notebook finds it in the transcript PDF attached to interview five. She did not need to ask Ihor. That is the whole point of the structure, and it took the team perhaps an hour of setup across eight weeks.

Make freshness visible without faking it

When a note has been checked, say so in one line at the top: “Reviewed after round two; constraints still valid, numbers in section 3 are old.” A date alone misleads. A note edited yesterday may describe a decision that died in spring, and a reference nobody has touched in a year may be perfectly correct.

When a note is superseded, link to the replacement and say in one sentence what changed. Do not delete it. The backlinks from the old note are often the only map of what else depended on that decision.

Read for meaning, not for recency. That is slower, and it is the honest answer. A knowledge base is useful in month eight for one reason: three people kept telling the truth in it, in short sentences, near the thing they were describing. The tooling helped, but it was the smaller part.

Where to go next

Find it again in a year

Learning and research: from sixty saved papers to one argument