Why nobody reads lessons learned in machine building and what helps instead.

A typical case. The line has passed acceptance and is running at the customer's site. The project lead calls a lessons-learned workshop, Friday afternoon, two hours, flip chart. It ends with minutes listing points such as "improve communication with the customer" and "clarify the specification earlier". They are filed in the project folder.

A year later a similar project starts. Nobody opens the minutes. And the same discussion about the safety enclosure begins all over again.

That is rarely down to a lack of discipline. It comes from how lessons learned are usually produced and where they end up. This article covers the three usual reasons, what makes experience genuinely usable, and how to ask earlier projects directly rather than hoping someone finds the right set of minutes.

Why does nobody read lessons learned in machine building?

They are written at the end, when everyone is tired

The workshop happens once the project is effectively over. Commissioning was hard work and the next project is already pressing. What gets written down is whatever people still remember after months. That is usually the last few weeks, not the decision during the quotation phase that caused the trouble in the first place.

They are too general

"Improve communication" is always true and never helps. General statements appear because they do not hurt anyone and because the concrete details are not to hand at that moment. Someone reading such a line on the next project has no idea what to do differently.

They are stored where nobody looks at project start

The minutes sit in the old project's folder, on the network drive or on a wiki page nobody has maintained since its third entry. When a new project starts, people look at the specification and the schedule, not at the folder of a project from two years ago. And even those who do first need to know which earlier project was actually similar.

What makes a lesson learned genuinely usable?

Three qualities decide whether a piece of experience helps next time.

The last point is the hardest. A perfectly worded lesson learned is no use if it sits in the wrong folder while the quotation is being clarified.

Often the real experience is not in the workshop minutes at all. It is in the original documents, in the email with the customer change, the FAT minutes, the revised bill of materials or the OneNote page from site. Those documents are concrete and grounded in facts. All they lack is being easy to find.

How do you capture experience while the project is running?

A few habits help, whatever tool you use.

• Make a short note after every critical milestone. After design release, FAT, SAT and commissioning, a quarter of an hour with the team is enough while the details are fresh.
• Record decisions with their reason. Not just "drive changed", but why, and which email or set of minutes says so.
• Flag customer changes. Anyone who later wants to understand why a project became more expensive needs to know where each change came from.
• File it in the project folder, not the inbox. Anything that only lives in a personal inbox is lost to the next project.

The second point in particular often fails in practice because the status is scattered across Excel, OneNote and email. Why pulling it together takes so long is covered in our article on project status in Excel, OneNote and email.

For the running project, Project Memory in KoAssist helps. It is currently in pilot operation. The overview keeps track of decisions and risks, and every entry in the project profile points to its source. From emails and minutes, KoAssist suggests changes, and only what someone on the team accepts becomes valid. So by the end of the project there is already sourced material, instead of a workshop reconstructing it from memory.

How can you ask earlier projects directly?

This is where the real difference lies. Rather than hoping someone finds the right minutes, you put a question to your documents. That is the job of the KoAssist knowledge assistant, not of Project Memory. Project Memory keeps the current project in order, while the knowledge assistant searches your document base, including completed projects.

Typical questions at the start of a new project look like this.

• "What problems came up at FAT on our last packaging lines?"
• "Why was the safety enclosure changed after the fact on the line for the beverage filler?"
• "Which customer changes came in after design release on similar lines?"
• "Which interfaces were left open in this customer's earlier specifications?"

Every answer points to file, page and section. So you jump straight into the SAT minutes or the email with the customer change and read the context yourself. The knowledge assistant reads specifications, bills of materials, minutes, standards, scanned documents and image content.

That changes the role of lessons learned. They no longer have to be perfectly worded and filed in exactly the right place. The original documents become the source of experience, because you can ask them questions.

KoAssist connects to the storage you already have, such as SharePoint, OneDrive, Google Drive, network drives, OneNote, your Outlook mailbox if you wish, and exports from your PDM. There is no system migration, and the source systems remain the reference. Permissions come from your file storage, and KoAssist does not train on your data.

When in a project does looking back pay off?

Asking earlier projects is most valuable at the points where expensive mistakes are made later on.

• When clarifying the quotation and reading the specification. Which requirements triggered variations on similar projects? Our article on analysing customer specifications shows how to work through a specification systematically.
• At the design kick-off. Which solutions proved themselves, and which were changed after FAT?
• Before FAT and SAT. Which test points caused rework last time?
• Before commissioning. What cost time on earlier sites?

A few minutes of questions at these points do not replace a workshop. But they bring experience to the table exactly when it can still change something.

What is left of the lessons-learned workshop?

The team conversation still makes sense. The minutes just no longer have to carry the whole load. Experience becomes usable when the project's documents are sourced and easy to find, and when you ask them at the right moment.

You can see how a running project is kept with a sourced profile, schedule and history on the Project Memory page. If you would like to see both on your own documents, book a demo.