You’ve been in this meeting. Bids come back 25% over budget. Someone suguests “we need to value engineer this." And thus begins months of theater that saves little but costs everyone - in time and sanity.

I've lead these conversation on both sides of that table. And from both perspectives, the mythology around value engineering is one of the most expensive belief systems in our industry. So let's get clear on expectations. 

The Process Problem

Often “VE” occurs late in the design phase; the team authors documentation then used by either an internal team or third-party cost estimator to develop estimates. When those estimates come back high, the project team goes back to the drawing board and starts looking for ways to save money. This is reactive and backwards, and the resulting dysfunction is where any project can go off the rails. The developer needs to be critical of the design inputs earlier in the conversation and question first principles in programming, conceptual, and schematic stages, not a reviewer at milestone handoffs.

Question First Principles

Value Engineering should not be simply a cost-cutting exercise. It's a creative, organized effort which analyzes the requirements of a project early in the programming effort for the purpose of achieving the essential functions at the lowest total cost over the life of the project. That distinction matters enormously in practice. 

I worked on a single-story residence that had a deep foundation system, designed for a multi-story building. The reasoning was technically defensible: seismic requirements, a liquefaction zone, flood risk. So the engineers had designed for all of it simultaneously. The foundation cost was enormous and visually absurd — you could see it was out of scale for what we were building.

When we looked at the flood risk specifically and asked what would happen if we eliminated that risk rather than engineered around it, the answer to change the scouring expectations by introducing erosion protection. And with the flood risk removed, we went from a seven-figure deep foundation to a fraction of that cost. Not by cutting. By redesigning the problem. That is what real value engineering looks like. Not trimming line items, questioning assumptions earlier in the design process.

This example also touches on another item nobody talks about: 60 to 70% of your construction costs are structure and systems — foundations, superstructure, MEP. Yet almost every exercise I've seen focuses entirely on the other 30%. Finishes. Fixtures. The things you can see and touch and easily have a subjective opinion to argue about in a conference room.Why? 

Because cost cutting often involves top-down decisions made without input from the project team. Often developers don't feel qualified to challenge what an engineer has put forward. Engineering disciplines carry a credibility moat that design disciplines don't. A structural engineer can cite seismic loads, liquefaction zones, code requirements, and most developers back down immediately. But those underlying assumptions can be misplaced, or dead wrong, and as the example above illustrates, expensive.

Don’t Let Fake Numbers Distract You

At early schematic stages, estimates are accurate within 15 to 25 percent, and that's being generous. Estimators are working with limited information, so they pad with generous assumptions. They have to. But then the developer sees a number that's 25% over their underwriting, panics, declares a 20 to 30% savings target, prompting resource spending on a VE exercise.

But here's the problem… cost overruns frequently arise when initial estimates fail to capture the true financial requirements of a project — not because the design is actually over budget, but because the data they're based on is incomplete. The gap the developer is chasing is often a gap in information, not a gap in value. They're not cutting fat — they're cutting into a number that was never accurate to begin with.

So they spend weeks (months) in internal meetings, pulling design consultants away from production to generate alternate schemes. They get estimates on those alternates. They review those estimates. They meet again. And by the time a contractor actually looks at the "savings," the schedule has slipped, overhead has accumulated, and the market has moved. You spent time to save money. In the end, you spent both.

The Only Savings That Count Are Committed

The hard rule I work by: if a contractor isn't at the table and willing to contract to the number they're quoting, the savings don't exist. A notation on a spreadsheet that feels good in a Monday morning meeting and evaporates the second someone has to actually build it.

Realistic VE, and the kind that persists, delivers somewhere between 5 and 10 percent in savings with minimal schedule impact. Go beyond that and you're not engineering value, you're changing scope. You're losing program. You're altering the value proposition of the asset itself.

Finally, bid of DD. By design development, you have enough information for a qualified contractor to put forward a hard estimate — not a guess, a commitment. That number becomes your baseline. They you interrogate the project with the contractor at the table (a new and informed perspective yields new information). With the design consultants in the room, you interrogate the project and work together to find scopes where real savings are available — the ones the contractor will stand behind when the time comes to build.

Everything else is fiction dressed up as financial discipline.

The question worth sitting with: how much of your past VE work resulted in an actual, contractually-committed savings?

The link has been copied!