Knowledge / Workflows
Lessons learned and institutional knowledge capture
Capturing decisions, defects, precedents and outcomes from completed projects into structured knowledge the next project can reuse.
Lessons learned is a workshop in the last month of a project, a spreadsheet that follows it, and the memory of the people who were there. The workshop captures what the room remembers. The real lessons are in the record: the RFI that was raised three times before anyone changed the detail, the parapet that leaked on two blocks, the compensation event caused by a gap in the ground survey, the subcontractor whose delivery dates slipped every time. Nobody extracts them because the project is over. Lessons learned AI for construction is only worth a firm's time if it keeps the completed record connected, so the next project can ask what happened last time, while the digital lead or the design director decides what becomes a standard.
What the workflow involves today
Book a lessons learned workshop in the final weeks, with whoever is still on the project.
Ask the room what went well and what did not, and write down what people remember.
Record the lessons in a spreadsheet or a report, grouped by topic, and file it on the shared drive.
Circulate it to the next project team and to the technical leads for comment.
Archive the project record: drawings, RFIs, minutes, variations and diaries go into a folder tree nobody reopens.
On the next project, rely on someone remembering that this detail or this subcontractor caused trouble before.
Rediscover the lesson when the same RFI is raised again.
Where generic AI tools fail
A general-purpose tool can summarise the lessons learned report, and the summary is as thin as the report. What it cannot do is read across a completed project's record and connect an outcome to its cause: that the leak at the parapet in the first winter traces back to an RFI response that accepted a substitute membrane, which traces back to a submittal reviewed in a week when the design manager was covering another job. Those links run through documents of different kinds that were never written to refer to each other, and the tool has no way of holding them together.
The output reads like knowledge. It has headings, it names themes, and it will say that early engagement with the ground investigation is recommended. The next project cannot ask it anything specific, because there is nothing specific behind it: no clause, no drawing, no event with a reference. When a design manager two years later asks whether the firm has used this cladding detail before and how it performed, the summary has no answer, and the person who knew has left. The lesson exists as a sentence in a report, which is much the same as not existing.
What changes with structured knowledge
When a completed project's drawings, RFIs, minutes, variations and diaries remain a connected record rather than an archived folder, the project is still there to be asked. A detail, a specification clause, a subcontractor or a client is a thread that runs through the record, and the outcome at the end of the thread is visible from any point on it.
What the digital lead or the design director receives is precedent with its source: the previous projects where this detail was used, the RFIs it generated and how they were answered, the instruction that changed it and the defect that followed or did not, each with the document, revision and date it came from. On request the same record produces a list of the questions raised most often, the details revised most often and the packages that generated the most change, as a starting point for deciding what should become a standard.
The digital lead decides what becomes a firm standard, what goes into the next project's specification, and which subcontractors and details need a second look before they are used again. The decision can be shown to rest on what happened, in which document, rather than on who remembered it, and less of the firm's knowledge leaves with the people who carried it.
We onboard a focused slice of your project data, configure the ingestion paths, extract a structured context graph, and build a workflow against the resulting structured knowledge layer.
Related to
This workflow reads meeting minutes and decision records, RFIs and site diaries as the record of what was decided, questioned and recorded on the day, alongside the variations and drawings that show what happened next. It sits beside project knowledge search, which answers questions on a live project, and RFI drafting and precedent search, which is where the previous project's answer is most often needed.
Does the project have to be structured while it is live, or can this be done at close-out?
Which parts of the record does it read?
How do we see it on one of our completed projects?