The Value Behind Value Engineering

Posted on January 26, 2011


Value engineering’s history began with General Electric’s “value analysis” process in the 1930s, where unnecessary costs were identified and eliminated from projects. This process shares a lot with modern day’s lean processing, which seeks to eliminate anything which does not add to quality, use, appearance or function. The Department of Defense is credited with the adaptation of value engineering to the facility development process.

Value engineering works best as a collaborative, integrated process, not a set of singular actions. Yet value is a measurement of benefit-per-cost, and the definition of value is a personal, subjective metric. The stock market is a good example:  at a certain price, thousands of times a day, a person finds a stock that is a value and they purchase it.  Conversely, thousands find that same stock no longer a value and they sell.

As an architect in design-bid-build (DBB), value engineering had shame attached to it; subtle and implicit:  we failed. VE in a DBB environment carried a stigma that the project process was broken. Under ideal project conditions, value engineering would be unnecessary—clients would always have enough money. The reality:  money or not, every client wants to save a buck if possible.

Value engineering exists because an owner cannot make every project decision or communicate every deciding fact in her head—nor should she be expected to. Architects are entrusted to make those decisions, using industry standards as a guideline, with the understanding the owner makes all value decisions. Without the owner, the project team—architects, engineers, contractors—lacks control over total project outcomes and may find it cumbersome to coordinate value-creating ideas. It is a team effort. Still, value ideas are best explored before working drawings are completed.

Value engineering is maximized in project delivery environments that are integrated because ideas can be continuously hypothesized, tested and implemented. Also, every idea has a ripple effect that affects every other discipline in some way, so with an integrated team value engineering make perfect sense—and so much less sense in a traditional, siloed, DBB set-up. In the traditional method, separate team professionals are naturally inclined to influence their scope of work with their own determination of value. In DB, real dollars are shaved off the guaranteed maximum price (GMP).

Keep in mind, research has proven that in software development late stage problems are more than 100x as costly to fix than early stage ones. VE has a similar value return proposition. Early decisions have savings magnitude. Changes for “savings” after the drawings are done are fictitious:  after the redesign, reengineering, redrawing, repurchasing and time delay, pennies on the dollar savings are the result, and often the VE solution costs more than the original solution.

In the end, the evolution of project value engineering is a process aimed at value creation rather than cost reduction. This is an important connection to design-build (DB) and something traditional DBB misses out on. DB is a process centered on fluidity and flexibility, while DBB is a rigid, linear process. The idea to understand is that as a project progresses from concept to construction, net savings and value creation shrink exponetially. In the concept stage, the return on value engineering is infinite. In the detail stage, value is reduced. In the construction stage, the value is zero.