There's a well-worn statistic in construction: 80% of a project's cost is determined by design decisions, and only 20% by construction. Nod along to that statistic at your own peril, thinking that hiring the best general contractor you can find is the solution.

The disconnect is worth examining. If cost is set in design, then cost control is a design problem. And if cost control is a design problem, then the most powerful cost control instrument on any project isn't the GC's contingency line — it's the document that governs every design decision before the first one gets made. That document is the project brief. And on most development projects I've been part of, it either doesn't exist or exists in a form so thin it might as well not. The brief isn't strategy overhead. It's a cost control tool. And the failure to treat it that way is one of the most expensive habits in development.

What a Missing Brief Looks Like

Hudson's Detroit is a project I think about when I want a clear example of what "no brief" looks like in practice. The client understood they wanted to build something significant for the city. The ambition was real. What was missing was any programmatic clarity about what that ambition required: what spaces, what scale, what adjacencies, what level of service, what customer. Compounding that, the developer was early in building their own organizational capabilities. There were no internal systems for gathering feedback, no defined process for making decisions and moving on, no clear accountability for who approved what and when.

The consultant team, all talented people (albeit I am biased, having lead that team) had no real target. So they aimed at everything and nothing simultaneously. What started as weeks of wheel-spinning became months. Months became years. The ambiguity wasn't just frustrating; it was expensive in the most literal way. Every meeting where nothing got decided cost real money. Every revision cycle that reopened questions already answered cost real time. And in development, time is the biggest cost on the project.

That's the first thing the brief does: it makes time legible. When there's clarity about what you're building and why, decisions have a frame. Questions get answered and stay answered. Consultants can build on each other's work instead of revisiting assumptions every cycle.

The industry's instinct is to treat cost control as a construction problem. That's where the numbers feel concrete (pun intended). Change orders, value engineering, contractor relationships, contingency management. That's where the cost control conversations happen, and that's where they're largely too late.

Cost problems don't originate in the construction phase. They go dormant at the very beginning, embedded in assumptions that never got examined, in schedule milestones that didn't account for internal review time, in a customer thesis that was never written down so every consultant was working from their own version of it. Lack of clarity, lack of vision, and lack of process. Each adds time and, thus, cost. By the time the problem surfaces as a change order or a blown milestone, you’re just getting a glimpse at the symptom. The cause is usually traceable back to something that should have been resolved in the brief, but wasn't.

The most effective place to control construction cost is during the design and pre-development phase, which is obvious when stated plainly, but routinely ignored in practice. What's less commonly said is that cost control during design requires something to control against. The brief is that thing. Without it, you're managing cost against a moving target you can't see.

A constructive project brief has five components, and most of the time a developer will get two or three and leave the rest to the consultant team to figure out. The gaps aren't random. They cluster wherever the developer is uncomfortable staking a claim. That discomfort is usually a signal that the accountability the brief demands hasn't been accepted yet.

A Brief is the Sum of Its Parts

The first component is a schedule. Not a milestone list, but a working schedule that accounts for the iterations, the prototyping, the costing exercises, the internal alignment cycles, and the owner review periods that happen between milestones. Developers routinely leave this incomplete because filling it in requires stating plainly how their own organization operates: how long they'll actually take to review a schematic design submission, who needs to sign off before the team can move, what "approved" means and whose signature it requires. When those answers aren't in the brief, the schedule never reflects reality, and every delay gets attributed to the consultants.

The second is area programming, the spatial foundation of the project. For a hospitality development especially, the scale and configuration of every space ultimately reflects what level of service the owner intends to deliver. Assembling the right consultant team is necessary, but each discipline needs a clear target from the owner. The architect brings deep experience across many projects and should absolutely be at the table. But the first draft of the program, with sizes, adjacencies, and access relationships, should come from the owner and/or operator, because they're the only ones who know what the space actually needs to do. When that gets handed off to the architect by default, the program gets built around design conventions rather than operational intent, and the owner spends the back half of the design phase fighting to get back to what they actually needed.

The third component is the customer thesis, or market positioning: who you're building for, and what their ideal visit looks like. This isn't just brand positioning, it's a decision filter. Every choice made downstream, in the program, in the design, in the FF&E, in the pre-opening operating model, should reinforce the value proposition to that specific customer. Without an explicit thesis, each consultant operates from their own assumptions about the end user, and the project accumulates micro-decisions that point in slightly different directions. The aggregate effect is a property without a point of view, built to satisfy no one in particular.

The fourth is a responsibility matrix: a clear map of every consultant's scope and the lines of demarcation between them. In a complex hospitality project, the overlap between architecture, interiors, MEP, landscape, F&B, spa, and technology consulting is a known source of gaps and conflict. The brief should define who owns what before the first consultant is contracted, not after the conflicts surface.

The fifth is a team coordination system, encapsulating how the project team will organize, communicate, and make decisions together. This is the one developers most consistently omit, because it reads as process overhead and the assumption is that the consultants and contractor will sort it out. They won't, or at least not in a way that reflects the owner's interests. The developer needs to lead this system, not inherit someone else's version of it.

Set Your Project Up for Success

A skeptical developer reading this might say: we didn't have a formal brief and the project still got built. That's true. Projects do get completed without a proper brief. The question is: at what cost? Not just in construction dollars, but in time lost to ambiguity, in decisions that had to be remade, in consultant hours spent on work that got thrown out because the target moved. That cost is always there. It just gets attributed to other causes: a difficult consultant, a complex site, an unexpected market shift. Those causes are often real. But they're usually symptoms. The root problem is that nobody built the instrument that would have governed every decision from the start, so every decision became a negotiation.

The brief has no line item in the budget. That's exactly why it always gets cut. And it's exactly why the cost of cutting it never shows up in the place where it was actually incurred.

The link has been copied!