After years running R&D and knowledge management at a large contracting firm, I've seen these five mistakes repeat across different companies — along with a practical fix for each.
The most common mistake I see is teams deciding to gather "lessons learned" in a single close-out meeting. By then, most of the important detail — why a decision was made, which alternatives were rejected, exactly where a problem occurred — has already been forgotten. Documentation needs to be part of the everyday flow of work, not an end-of-project chore. In the R&D projects I managed, we logged each technical package the moment a final decision was made, not months later.
A large share of technical knowledge lives in the heads of experienced engineers and supervisors, not in any document. When that person leaves the company or moves to another project, the knowledge leaves with them. A knowledge management system exists precisely to solve this — converting tacit knowledge into documented knowledge that any new team member can access, without having to relearn it from scratch.
Many companies have a document archive, but it's a disorganized pile, not a searchable system. An important technical report might be buried in someone's inbox, a personal folder, or an old group chat. Without a standard classification structure (by project type, phase, technical topic), even documented knowledge is effectively unretrievable — which, in practice, is no different from not having it at all.
Many companies believe buying an expensive knowledge-management platform solves the problem. Experience shows the deciding factor is organizational culture, not the tool. If teams lack the motivation or time to log their experience, even the best software stays empty. Knowledge management needs to become part of the formal project process (a fixed agenda item in weekly meetings, for example), not an optional side activity.
Even when knowledge is properly documented and categorized, it's often never actually used in decisions on the next project. A new project team, without consulting prior project experience, repeats the same mistakes. The fix is to make reviewing existing knowledge a formal step in new-project planning — for example, a dedicated session before the design phase starts to review "what we learned on similar projects."
In a short consultation, I'll review your current documentation and knowledge-sharing processes.
Request a Consultation