Projects are privileged learning contexts. In a real project, with deadlines, pressure and concrete results, knowledge is tested in ways that reading alone never produces. Mistakes have consequences. Successes have identifiable causes. Decisions leave traces.
If your knowledge management system does not capture what happens in your projects, it is missing the most valuable source of learning.
The project as learning context
There is a difference between theoretical knowledge and operational knowledge. Theoretical knowledge you acquire by reading and studying. Operational knowledge you acquire by doing: you discover that a principle that seemed clear in theory is more complicated in practice, that what worked in one context does not work in another, that there are nuances no book mentions because they are only learnt in the field.
This operational knowledge is the most valuable and the hardest to transfer. If you do not actively capture it, it is lost. You keep making the same mistakes in different projects because you never converted them into explicit learning.
What a project contains in the system
For each significant project, it is worth having in the system:
A project note: the central reference point. Contains the project objective, the important decisions taken (and their reasons), the main resources being used, and the current status.
A decision log: not all decisions, but those that are not obvious. When you make a decision that is not the only possibility, note what you decided and why. In the future (weeks, months, years), this will allow you to review whether the logic remained valid or where it broke down.
Working notes: quick captures during the process. Ideas that arise, things you notice, questions that appear. They do not have to be perfect; they are the material for later reflection.
During the project
The key during the project is light capture: not burdening yourself with a heavy documentation process, but creating the habit of recording the most significant things.
Useful practices:
- Brief weekly project review: ten minutes to update the project note with the current status and note the week’s learnings.
- Capture problems in the moment: when something does not work as expected, capture the problem, and when you resolve it, capture the solution. Do not wait until the end of the project.
- Mark important decisions: when you make a decision that could be reviewed later, mark it explicitly. “Today we decided X because Y.”
Project closure: the most ignored phase
Most projects end — or are abandoned — without any closure ritual. The pressure to move on to the next project is so great that there is no time to reflect on the one that has just finished.
This is the biggest waste of knowledge I have seen in professional environments. A well-done closure takes one or two hours and produces learnings worth weeks of future work.
The basic project closure includes:
- What went well? Not as self-congratulation, but as identification of practices worth repeating.
- What went wrong or could have gone better? Without judgement, with curiosity. What were the mistakes and their causes?
- What did I learn that I did not know before? New operational knowledge: about the domain, the team, yourself.
- What would I do differently next time? The most practical question and the most directly transferable.
The answers to these four questions go into your learning notes in the system. Not into the project archive (which is archived), but into your active knowledge repository.
Transferring knowledge between projects
The goal of all this is not to accumulate notes on past projects. It is for what was learnt in one project to improve the next ones.
Transfer happens in two ways. The first is active: when you start a new project, you search your system for learnings from similar projects. What worked before? What mistakes do you want to avoid? Are there resources or references you used that are still relevant?
The second is passive: simply the fact of having captured and processed the learnings makes them more accessible in your memory. You do not need to search for them explicitly because you internalised them by writing them.
In the next chapter we talk about sharing what you know: why teaching is one of the most powerful ways to learn.
