What 200+ Real Project Lessons Reveal About How We Think About Design Quality

What 200+ Real Project Lessons Reveal About How We Think About Design Quality

Over the past few years, I've been sitting with a growing body of evidence that's changed how I think about what good engineering design actually means. 

At EDC, we run a structured lessons learned system across our offices in Cork, Dublin, Limerick, Galway, London and Istanbul. Every month, teams contribute real issues from live projects. What went wrong, what had to be reworked, what caused friction on site. That information is pulled into a central register, filtered by system, and shared across the business so it can actually be used. 

We don't just store it either. Our operations team reviews the most significant items monthly, runs targeted training sessions, and issues technical memos where clarification is needed. 

That register now runs to over 200 entries. And when you step back and look at it as a whole, the pattern is not what most people would expect. 

The problem isn't a lack of knowledge. It's how, and when that knowledge is applied. 

If a lesson doesn't change how decisions are made, it hasn't really been learned. That's what this system is built around. And what it's shown us is worth sharing. 

We're Not Dealing With Unknown Problems

The issues coming through are rarely surprising. Coordination clashes between systems. Underestimated clearances. Drainage allowances that don't work in reality. Layouts that don't properly account for access and maintenance. 

None of these are new. None of them are particularly complex. And yet they keep appearing across different projects, teams, and locations. 

That's the part worth paying attention to. Because if the same issues are recurring across the business, this isn't about individual mistakes. It's about how the process itself is set up. 

Coordination Is Still Happening Too Late 

One of the clearest trends in the data is around coordination. 

It's happening. But it's happening too late to be effective. 

By the time clashes are identified or access issues are flagged, the design is already well developed. Equipment has been selected, routes are defined, space is constrained. At that point, coordination becomes a process of compromise rather than good decision-making. 

You're no longer asking "what's the best solution?" 

You're asking "what can we make work?" 

That shift is where quality starts to drop. Coordination shouldn't sit at the end of the process as a check. It needs to shape the design from the beginning. Otherwise, we're just resolving problems we've already built in. 

One of the direct changes we've made as a result: coordination assumptions are now challenged explicitly in the first design team meeting on every project. It's a small process shift. The impact on downstream clashes has been material. 

Small Assumptions Are Driving Big Issues

Another pattern that stands out is how often problems trace back to small assumptions. 

A clearance that's slightly underestimated. A drainage opening that's assumed rather than verified. A tolerance that isn't fully considered. 

Individually, these decisions don't feel significant. They're the kind of things that get signed off with a quick "that should be fine." 

But on site, they rarely are. Those small gaps force adjustments during installation. Systems get shifted, reworked, or compromised to fit. And something that looked minor on a drawing becomes a real cost and programme issue. 

It's not that the design was fundamentally wrong. It's that it wasn't thought through far enough. 

There's Still a Gap Between Design and Reality

A lot of the lessons also point to a disconnect between design intent and how things are actually built. 

Systems that technically fit within a space, but don't account for how they'll be installed. Equipment that meets all the right criteria on paper, but doesn't leave enough room for proper access. Layouts that work in a model, but not in sequence on site. 

In many cases, contractors end up bridging that gap themselves. Adding tolerances, adjusting routes, making it work in real time. But that comes at a cost. Because ultimately, if a system is difficult to install or maintain, it's not a strong design. No matter how well it performs on paper. 

The Bigger Issue: We're Repeating Ourselves

The most telling part of all this isn't the individual issues. It's the repetition. 

We're not uncovering new problems, we're seeing the same ones come up again and again. And that raises a bigger question. 

If we already know where things go wrong, why aren't we preventing it? 

This is where most lessons learned processes fall down. Information gets captured, documented, maybe shared but it doesn't consistently influence the next design. The register we've built is specifically structured to address that: live, accessible, filtered by system, and tied into monthly training and technical guidance. 

The goal is simple. Make sure the next project benefits from the last one.

A More Honest View of Design Quality 

There's a tendency to judge design quality based on completeness, compliance, or level of detail. 

But those aren't the things that cause problems on site. 

The issues we're seeing come from something much simpler: decisions that didn't fully account for reality. Better design isn't about adding more at the end. It's about getting more right at the beginning. 

And if the same lessons keep coming up, that's where the focus needs to be.