Consider a question that should concentrate the mind: why does your industry repeat the same mistakes on every single project?

Not similar mistakes. The exact same ones. The coordination conflict that caused problems on the last hospital project. The design detail that required a field fix three projects ago. The scope assumption that created a change order two years back.

The answer isn’t carelessness. It’s architecture. Construction is structurally designed to forget.

Making movies, not making cars

Think about how a car manufacturer operates. One factory, one team, refining the same product continuously. When something goes wrong on Monday, Tuesday’s car benefits from the fix. Knowledge compounds. The system learns.

Now think about how you build. Each project assembles a temporary cast: architects, engineers, contractors, subcontractors, specialty consultants. They gather, write the script, produce the project, and scatter. The architect moves to a different project with a different GC. The MEP engineer pairs with a new design team. The electricians take their field knowledge to the next job.

The hard-won knowledge goes with them. In their heads, maybe in scattered notes. But it doesn’t live anywhere that the next project can access it.

This is the goldfish problem. Around the bowl, see the castle, forget the castle, around the bowl, see the castle again, brand new. Your projects are designed to repeat this cycle indefinitely.

The elephant that doesn’t exist

Elephants actually do have remarkable memories. They remember watering holes visited decades ago. They recognize individuals after years apart. They accumulate wisdom from repeated experience and carry it forward.

No construction project has an elephant’s memory. There’s no authoritative system that knows: we solved this coordination problem before, here’s what worked; this detail failed in the field last time, here’s the fix; this subcontractor’s productivity patterns suggest a schedule risk developing, here’s how we addressed it elsewhere.

The institutional knowledge that would break the cycle of repeated mistakes doesn’t have a home.

Why your project tools are the wrong tools

Every piece of construction technology you use is a System of Work. Revit for design. Procore for project management. Document management for files. These tools are excellent at supporting the work that happens during a project. They’re poor at preserving what was learned.

When a project closes, its Procore instance closes. You can’t search across every project you’ve ever delivered to find “all the times we solved this mechanical coordination problem.” The next project starts fresh, opens a new instance, and begins from zero.

Compare this to how a sales organization manages knowledge. They use email, presentation software, meeting tools, all Systems of Work. But the actual customer knowledge lives in a CRM, a System of Record. A salesperson can leave and the institutional knowledge about that customer persists. The patterns of what works and what doesn’t get captured and carried forward.

Construction has Systems of Work. It doesn’t have a System of Record. There’s no elephant.

What an institutional memory would actually look like

The project management system that serves as institutional memory for construction isn’t a better Procore. It’s a different category of tool.

It ingests what actually happens on projects, not just the compliant data entries, but the RFI conversations, the field coordination decisions, the change order narratives, the owner-contractor exchanges. It extracts patterns. It makes those patterns searchable across projects.

When a structural engineer starts detailing a connection for a new hospital, the system surfaces: “This configuration created a coordination conflict on three previous hospital projects. Here’s how each was resolved.” When a project manager is reviewing a subcontractor’s bid, the system notes: “This subcontractor’s productivity patterns have historically tracked about 15 percent below their schedule commitments in the first eight weeks.”

That’s institutional memory. That’s the elephant your organization needs and doesn’t have.

The owner’s stake in this

For the person writing the checks, the goldfish problem has a direct cost. It shows up in the change orders for conditions that were discoverable earlier. It shows up in the design rework for conflicts that similar projects had already solved. It shows up in the schedule growth that accumulates from coordination failures that were preventable.

Every time your project team reinvents a solution to a problem that’s been solved before, you’re paying for it.

The question worth asking any project team before engagement: how do you capture learning from past projects, and how does that learning improve the work you do on mine? If the answer is “we have experienced people,” that’s a goldfish answer. Experience lives in heads, not systems, and heads walk out the door.

The team that can say “our system captures what we learned on 200 previous projects and applies it to every new one”, that’s an elephant. And that’s the team whose track record is actually predictive of future performance.

The cycle of repeated mistakes isn’t inevitable. It’s a design choice. And it can be redesigned.