Many times, design-build mistakes get blamed on construction. The real problem usually started in preconstruction, weeks or months earlier, when nobody had a system to catch them.
Design-build is supposed to be the smarter delivery method. Owner, architect, and GC aligned from day one. Fewer surprises. Better outcomes. And when it works, it really works.
But walk through the process of a blown design-build project and you’ll usually find the same thing: the team knew something was wrong early on, and nobody had a system to quickly identify the issue and force the conversation. The decision got delayed. The issue got buried. And by the time it surfaced in design development or, worse, during construction, it cost real money.
Here are five ways design-build teams lose before a single shovel hits the ground, and what you can do about it.
1. The Kickoff Meeting Happens Without an Alignment Agenda
Every design-build project kicks off with energy and optimism. Introductions are made. Relationships are warm. Everyone is nodding. And almost nobody has been clear about who makes what decisions, what triggers a design change review, or how disputes between the owner and design team get resolved.
A kickoff meeting without a real alignment agenda isn’t a kickoff. It’s a social event with a KPI chart. Three months later, when the owner wants a change that the architect says affects structural assumptions and the GC says it breaks the budget, everyone points at everyone else. Because nobody documented the decision-making framework on day one.
The alignment conversations that don’t happen in week one become the change orders that show up in week thirty.
Most times, decisions made in early meetings become part of the contract record. Not just the documents, but the decisions. That means a conversation about structural assumptions in schematic design that nobody documented properly can become a change order dispute six months later, when the design-builder claims they relied on an informal owner preference that the owner swears was never a directive.
2. Junior PMs Inherit the Process Without Inheriting the Knowledge
Your senior design-build PM is good at what they do because they’ve been doing it for fifteen years. They know that a structural assumption made informally in a schematic design meeting carries contractual weight whether it was documented or not. They know when an owner’s comment about finish quality is passing feedback versus a scope preference that’s about to show up as a change order request. They know which design decisions cascade into downstream coordination issues and which ones can wait a week without consequence. You get the point.
When that PM is stretched across four projects, or when a junior PM takes the lead on a growing portfolio, that knowledge doesn’t transfer automatically. What transfers is a folder full of files and a few handoff meetings. What doesn’t transfer is the judgment about when to escalate an owner’s informal preference to the design team, which design-phase conversations need to be formally captured before they become contract record, and where the quiet land mines are in a standard Design-Build agreement. That’s not in any folder.
This isn’t a talent problem. It’s a systems problem. Design-build preconstruction has a set of recurring failure points: undocumented design assumptions, owner preferences treated as informal guidance, coordination gaps between the architect and GC during schematic design, and when that knowledge lives in someone’s head instead of a shared playbook, every project rediscovers those failure points the hard way.
Design-build teams that scale well have codified what their best people know. They’ve turned institutional expertise into a repeatable process. And when a junior PM sits down at a new project, they’re not starting from zero. They’re starting from a proven structure with the right checkpoints already built in. This is gold.
3. Owner Expectations Are Set Informally, or Not at All
Owners choose design-build specifically because the model promises project speed and stakeholder transparency. Open-book pricing, a unified team with shared accountability, real-time cost feedback as design evolves, these are the core arguments for the design-build delivery method. In progressive design-build procurement, owners are selecting teams partly based on their ability to deliver that kind of visibility. By the time any challenges surface, the project is weeks behind or the design has gone in a direction that generates an expensive redirect.
Real transparency in design-build means the owner can see project health between meetings and that decisions are logged when they’re made. In a delivery model where the owner has no separate architect watching independently on their behalf, the system is the safeguard. Without it, the owner who signed up for transparency ends up with the same information gaps they were trying to avoid.
That’s what preconstruction transparency is actually worth. Not a better update email. A fundamentally different outcome.
4. No One Owns the Decision Log
Design-build preconstruction is a constant stream of decisions. Material choices, scope definitions, site assessments, structural assumptions, owner preferences on flexibility vs. cost. Most of these decisions are made correctly. Almost none of them are documented properly.
Design-build preconstruction is a constant stream of decisions. Material choices, scope definitions, site assessments, structural assumptions, owner preferences on flexibility vs. cost. Most of these decisions are made correctly. Almost none of them are documented properly.
That’s fine, until something changes. And in design-build, something always changes. The problem is what happens when it does. The design-build implementer is responsible for maintaining the project record, but that record is only as useful as the system behind it. When decisions live in meeting notes, email threads, and people’s memories instead of a structured log, the DBI’s record becomes a reconstruction project the moment something is disputed. When a scope question comes up six months later and the answer is “we discussed that in preconstruction,” everyone’s story differs slightly. The dispute resolution conversation starts right there.
A documented decision history protects everyone on the team. It protects the GC when the owner changes their mind about a scope item that was locked three months ago. It protects the architect when the structural assumptions from schematic design are challenged. It protects the owner when they need to understand why the project costs what it costs — and it gives them confidence that the team is managing the design process with the rigor the contract requires, not just with good intentions.
Teams that maintain a real decision log don’t just have better documentation. They have better conversations. When people know decisions are being captured, they show up differently to the meetings where decisions get made.
5. Every Project Starts From Scratch
Walk through your last five design-build projects. How different was the preconstruction process on each one? Different meeting cadences, different milestone structures, different accountability systems, different tools. Some of that variation is appropriate. Projects are different. Owners are different.
But most of that variation has nothing to do with the project. It reflects whoever was running preconstruction at the time and what they happen to prefer. That’s hero-dependent project management, and it has a ceiling. You can only scale as fast as you can find, hire, and develop senior design-build PMs who carry the process in their heads. And for firms pursuing larger portfolios — particularly public projects using qualifications-based progressive design-build selection — sophisticated owners are specifically evaluating whether the team has systematic process, not just talented individuals. The proposal that demonstrates a proven playbook wins over the one that relies on the résumé of a single star PM.
The firms that win more design-build work and deliver it more profitably have a different model. They start every project from a proven playbook. They customize it to the specific project and owner. But the structure, the checkpoints, the accountability system, those come pre-loaded. Nobody reinvents the wheel. Everyone starts from what works.
That’s how you scale capacity without scaling headcount. That’s how a junior PM delivers at a senior level. And that’s how a firm competes for larger design-build portfolios with confidence that the process can hold.
The Pattern Underneath All Five
Every one of these failure modes comes from the same root problem: design-build preconstruction is running on informal systems. Good intentions, experienced people, and no shared structure to hold it together.
That’s not a people problem. Design-build teams are full of talented, experienced professionals. It’s an infrastructure problem. The front end of a design-build project deserves the same systematic rigor the construction phase gets. And when it has that, the whole project changes.
See How Precon Playbook Works
Precon Playbook is the collaboration system built specifically for design-build preconstruction. Pre-populated playbooks, enforced accountability, and real-time owner visibility from day one.
Precon Playbook 