Value engineering in construction field guide

What value engineering really is, and what it is not

Value engineering is a structured method for improving the value of a project by studying what each system has to do and finding a way to deliver that function at a lower life-cycle cost without giving up performance. Value is the relationship between function and cost. You raise it by holding the function and lowering the cost, or by adding function for the same money. Done right, it is a disciplined study run to a recognized job plan, not a pass through the estimate with a red pen.

Here is the part the word gets wrong on most jobs. When a project comes in over budget, someone says value engineer it, and what they mean is make it cheaper. The team strips ductwork insulation, drops the equipment to the bottom-tier line, deletes redundancy, and calls the result value engineering. It is not. That is cost-cutting wearing a borrowed name, and it usually buys a lower first cost by handing the owner higher operating cost, more callbacks, and a stack of change orders when the cheap substitute does not fit the rest of the design.

The discipline came out of manufacturing in the 1940s and was carried into construction and the public sector, where it is now a formal study with its own standard. SAVE International publishes the value methodology and certifies the people who lead it. This guide goes deep on the method itself. Where value engineering touches the front-end planning, the preconstruction guide carries that thread, and where accepted changes have to flow back into the contract, the change order guide carries that one.

Value equals function divided by cost

The whole method rests on one relationship. Value equals function divided by cost. Function is what the element must do. Cost is what it takes to provide it, measured over the life of the project, not just at purchase. When you keep the function and cut the cost, value goes up. When you add function for the same cost, value goes up. When you cut the cost by cutting the function, value does not move, and often it falls.

That last line is the one that separates the method from the hatchet. A rooftop unit has to condition a given space to a setpoint at a design load. That is the function. If a smaller unit cannot hold the load on a design day, dropping to it does not improve value, it lowers function faster than it lowers cost. If a different unit holds the same load with the same service life at a lower installed-plus-operating cost, that is value, and that is the kind of move the study is hunting for.

Cost in the equation is never first cost alone. A cheaper unit that runs less efficiently and fails sooner can cost the owner more across ten years than the one it replaced. Real value engineering measures cost the way the owner actually pays it, which means life-cycle cost. Hold that idea, because it is the test that catches false savings every time.

Why it matters, and what it costs when it is done wrong

Done right, value engineering finds real savings without losing performance. It keeps a project inside the owner's budget while protecting what the building has to do, and it does it by questioning whether the design is the lowest-cost way to deliver the required function, not by quietly lowering the standard. That is money the owner keeps with nothing given up, which is the only savings worth the name.

Done wrong, it backfires, and the backfire is predictable. The classic pattern is a first cost that looks better on the bid day and an operating cost that is worse for the next twenty years. Strip the insulation and the system sweats and the energy bill climbs. Substitute the off-brand equipment and parts are slow and the service contract costs more. Delete the redundancy and the one failure that the redundancy was there for takes the building down. Each of those reads as a saving on the spreadsheet and shows up as a loss in the building.

The other cost is the change order. A cut made without checking how the system connects to everything around it does not stay cut. The cheaper coil does not match the existing piping, the smaller unit needs a different curb, the deleted scope was holding up something else. Now the saving is gone and a change order is sitting on top of it. Scope cut carelessly comes back as a claim. The change order guide is where that fight gets managed, and the best way to win it is to not start it.

Is value engineering just cost-cutting?

No. The difference is function. Value engineering keeps or improves the function while it lowers the cost. Cost-cutting just removes scope or quality and lets the function fall with it. They can land on the same line of the estimate, but they are opposite moves, and confusing the two is the single most common failure in the whole subject.

Run the test on any proposed cut. Ask what function the element provides and whether the cheaper version still provides it. If the answer is yes, at equal performance and equal or better life-cycle cost, that is value engineering. If the answer is that the function drops, the reliability drops, or the operating cost rises, that is cost-cutting, and it should be called that out loud so the owner can decide with the truth in front of them. A team that labels every reduction value engineering is hiding the cost of the reduction, usually from the person who will pay it later.

There is a legitimate place for cutting scope. Sometimes the budget is real and something has to go. That is a scope decision, made openly with the owner, and it is honest. What is not honest is dressing it up as a value study so it sounds like a free win. The method exists to find the wins that are actually free. Calling the painful cuts by the same name burns the credibility of the real ones.

Function analysis, the heart of the method

Function analysis is what makes value engineering different from every other cost exercise, and it is the part most people skip. Instead of looking at the thing, you define what the thing must do, in two words, an active verb and a measurable noun. A wall does not exist to be a wall. It exists to support load, resist water, separate spaces, or block sound. Name the function that way and you have separated the job from the current answer to the job.

That separation is where the savings hide. Once the function is support load, you are free to ask what else supports load, and you are no longer married to the assembly on the drawing. Once the function is resist water, the question becomes what is the lowest-cost way to resist this much water in this condition, which may or may not be the detail the designer reached for first. The verb-noun discipline forces the team off the existing solution and onto the requirement, and only the requirement has to be protected.

The payoff is finding the high-cost, low-value functions. You map cost to function and look for the place where a lot of money is buying a little of what the project actually needs, or buying something the project does not need at all. That is the target. A feature that costs real money and delivers a function nobody required is pure waste, and the only way to see it is to have named the functions in the first place. Skip function analysis and you are not doing value engineering. You are just shopping for cheaper parts.

The SAVE job plan

Value engineering is not a meeting where people suggest cheaper materials. It is a structured study that follows a sequence, and the recognized sequence is the SAVE International job plan. It runs in six phases: Information, Function Analysis, Creative, Evaluation, Development, and Presentation. The order is the point. You gather facts before you define functions, define functions before you brainstorm, brainstorm before you judge, judge before you develop, and develop before you present. Jump a phase and the study loses the rigor that makes its results defensible.

The phases keep the study honest in a specific way. Judging ideas too early kills the good ones before they are understood. Developing ideas before evaluating them wastes effort on alternatives that were never going to fly. Presenting before developing puts half-baked numbers in front of the owner. The job plan is a guard against all of those, and following it is what lets the team stand behind the recommendation when someone asks how they got there.

Treat the phases as the framework, not a rigid script. A small study compresses them and a large one runs each as its own working session over days. The methodology and the certification behind it are SAVE International's, and the depth of the study is a project decision. What does not change is the order, because each phase feeds the next.

The information phase

The study opens by gathering what is true about the project before anyone proposes a change. The team pulls the drawings and specifications, the current cost estimate broken down far enough to see where the money sits, the schedule, the site constraints, and the codes and standards that govern the work. You cannot improve value on a project you do not understand, and the most common reason a study produces bad ideas is that it started without the facts.

The part that gets shortchanged is the owner's value criteria. The team has to know what value means to this owner on this project before it can improve it. A hospital owner values uptime and infection control. A developer flipping a building values first cost and speed. A school district values operating cost across a thirty-year hold. The same proposed change is good value for one and bad value for another, and the study has no compass until those criteria are written down.

The cost model matters as much as the criteria. You want cost mapped to the systems and, where possible, to the functions, because the function analysis that follows needs to see where the money is concentrated. A study working from a lump-sum number with no breakdown is guessing about where the value problems are.

The function analysis phase

This is the phase that earns the method its name, and it is where the verb-noun work gets done formally. The team lists the functions of the project and its systems, classifies them, and separates the basic functions, the reason the thing exists, from the secondary functions that support or come along with it. Basic functions are protected. Secondary functions are fair game for question.

The common tool here is the FAST diagram, the Function Analysis System Technique. It lays the functions out left to right on how-and-why logic: ask how a function is achieved and you move toward the detail, ask why and you move toward the purpose. Built right, the FAST model shows the team which functions are doing real work and which are riding along, and it puts cost against each so the high-cost, low-value functions stand out instead of hiding inside an assembly.

The output of this phase is a focused target list, not a pile of cut ideas. The team leaves knowing which functions are worth attacking in the creative phase, because that is where cost is high relative to the value the function returns. Get this phase right and the rest of the study aims itself. The FAST technique and the function vocabulary are SAVE International's, and a study that skips straight to brainstorming cheaper parts has skipped the only phase that tells it where to look.

The creative phase

With the target functions named, the team brainstorms ways to deliver them. The rule that makes this phase work is to separate generating ideas from judging them. You want quantity first. Every alternative way to provide the function goes on the list, including the ones that sound expensive, unusual, or half-formed, because a weak idea often triggers a strong one and judgment kills both if it comes too early.

The discipline is harder than it sounds. The natural reaction to an odd idea in a room full of professionals is to explain why it will not work, and the moment that starts, people stop offering ideas. A good facilitator holds the judging off until the next phase and keeps the list growing. The question on the table is narrow and useful: what are all the ways to deliver this function. Not which way is best. That comes later.

Because the team is working from functions rather than the existing design, the ideas range wider than a normal cost review would reach. Brainstorming on support load opens up framing systems a value review aimed at line items would never surface. The breadth here is the whole reason the function analysis came first.

The evaluation phase

Now judgment is allowed. The team screens the long list of ideas against feasibility and against the owner's value criteria, and most of the list falls away. An idea can be brilliant and still be wrong for this project because it blows the schedule, fails a code requirement, or trades against something the owner values more than the saving. The criteria written in the information phase are the yardstick, which is why writing them down early mattered.

The screen runs in stages. A quick first pass drops the ideas that are plainly infeasible or that hurt a basic function. What survives gets weighed harder, ranked by how much value it could add against how much risk and effort it carries. The goal is a short list of alternatives worth the cost of developing into real proposals, because development takes time and you do not spend it on ideas that will not survive scrutiny.

Keep the reasoning in the record. An idea rejected here should have a one-line note on why, because the owner or the designer will ask later whether anyone considered it, and the answer wants to be yes, here is why it was set aside, not silence.

The development phase

The surviving ideas get worked into actual proposals. This is where an idea stops being a suggestion and becomes something the owner can act on: a description of the change, the technical detail that shows it works, the effect on schedule and on adjacent systems, and the numbers. The numbers are the part that carries weight, and they have to be first cost and life-cycle cost, not first cost alone.

Each proposal should stand on its own. It states what is being changed, what function is preserved and how, what it saves, what it costs to implement, and what it does to operating and maintenance cost over the life of the asset. A proposal that shows a lower first cost and ignores the operating side is not finished, and it is exactly the kind of half-analysis that produces false savings. The development phase is where the team proves the saving is real by costing it the way the owner pays.

Development also surfaces the second-order effects that the creative phase happily ignored. The alternate unit may need a different curb, a different disconnect, a different control sequence. Those costs belong in the proposal, because leaving them out is how a clean-looking VE idea turns into a change order after acceptance.

The presentation phase

The study ends by presenting the developed proposals to the people who can decide, which means the owner and the design team, not the value team. The value team recommends. The owner decides. That line is the whole governance of the method. The team that ran the study does not get to impose its proposals, because the proposals trade against criteria that belong to the owner, and only the owner can say which trades are acceptable.

A good presentation gives each proposal plainly: the function it protects, the change, the first cost and life-cycle savings, the risks, and a clear recommendation. The owner accepts, rejects, or asks for more work, and each of those is a legitimate outcome. A proposal that saves money but trades against something the owner values more is correctly rejected, and the study still did its job by surfacing the choice.

What comes out of this phase is decisions, and decisions are records. The accepted proposals now have to flow into the design and the contract through a controlled process, which is where the study hands off to the change management side of the project.

What is life-cycle cost, and why is it the real test?

Life-cycle cost is the total cost of an asset across its life: the first cost to buy and install it, plus the cost to operate it, plus the cost to maintain and repair it, plus the cost to replace it at the end of its service life, often discounted back to present value. It is the only honest measure of cost in a value study, because it is the cost the owner actually pays, and a cheaper first cost that costs more to run is not value.

This is the test that catches false savings, and it catches them reliably. The high-efficiency unit costs more on bid day and less every month it runs. The cheap unit costs less on bid day and more every month after. Compare them on first cost and the cheap one wins. Compare them on life-cycle cost and the answer often flips, because the energy and maintenance differences compound for the life of the equipment. A value study that decides on first cost is not finished, and on long-lived mechanical and electrical systems the operating cost usually dwarfs the first cost over the hold.

The discount rate and the analysis period are real assumptions, and they belong to the owner and the project, not to a rule of thumb. A short-hold developer and a thirty-year institutional owner will rank the same two units differently and both be right, because their analysis periods differ. Confirm the period, the rate, and the energy assumptions against the project before the life-cycle number decides anything.

When should value engineering happen?

As early as the design allows, because the earlier the study runs, the more value it can find and the cheaper the change is to make. Most of what a project will cost is committed during design, while the work is still lines on a drawing. A value study run at schematic or design development can change the system itself for the cost of a redraw. The same idea after the equipment is bought and the slab is poured costs a change order, a schedule hit, and rework.

The curve is steep. Early, the team can question the structural system, the mechanical approach, the floor-to-floor height, the routing of the main distribution. Those are the decisions that set the big numbers, and they are still movable. Late, those decisions are locked, and the only things left to value engineer are the small ones, where the savings are thin and the disruption is high. A study brought in after the contract is signed is mostly limited to substitutions, and substitutions are where the cost-cutting trap lives.

This is the strongest reason to fold value thinking into preconstruction, where the builder is pricing the design as it develops and can test alternatives while they are still cheap to change. The preconstruction guide covers that front-end work. The short version is simple: a value study is worth the most when it runs before the decisions it wants to influence have already been made.

The VE workshop and the team

A formal value study runs as a workshop, a focused block of time with a multidisciplinary team working the job plan together. The team is mixed on purpose: the disciplines that touch the project, plus people with enough distance to question assumptions the design team has stopped seeing. A study run by the same people who produced the design tends to defend the design. Some independence in the room is what lets the hard questions get asked.

The workshop is led by a facilitator, often a Certified Value Specialist, the credential SAVE International grants to people trained and tested in the methodology. The facilitator's job is process, not answers. They keep the team moving through the phases in order, hold judgment off during the creative phase, and keep the study aimed at function rather than letting it slide into a line-item cost review. A good facilitator is the reason the job plan actually gets followed instead of collapsing into a meeting about cheaper parts.

Size the workshop to the project. A large public project may run a multi-day study with an independent team. A smaller one folds the method into existing design meetings with a lighter touch. The structure, the certification, and the independence are matters of judgment for the project and, on public work, often a matter of the owner's program.

The owner's value criteria

Value is defined by the owner, not by the lowest number, and the study cannot improve value until it knows what the owner means by it. The criteria usually run wider than cost: quality and durability, schedule, aesthetics, flexibility for future change, and operating cost across the hold. A change that saves money but slows the schedule on a project where the owner needs the building open by a date is bad value, even though it is cheaper.

Write the criteria down and, where you can, weight them. The same proposal scores differently against different priorities, and an unweighted study quietly substitutes the team's priorities for the owner's. When the criteria are explicit, the evaluation phase has a real yardstick and the presentation can show the owner exactly how each proposal trades against the things they said mattered.

This is also the protection against the cost-cutting trap. When the criteria include operating cost and durability, a cut that lowers first cost by raising operating cost fails the owner's own test and gets caught before it ships. A study with no defined value criteria has nothing to fail against, which is why those studies drift into cutting whatever is easiest to cut.

The VECP and shared savings

On public and federal work there is a formal channel for contractor-initiated value engineering called the value engineering change proposal, the VECP. A contractor who finds a way to deliver the required function for less, after the contract is signed, submits a VECP, and if the owner accepts it, the savings are shared between the contractor and the owner. The shared-savings clause is the incentive: the contractor is rewarded for bringing the idea forward instead of pocketing it or sitting on it.

In the federal system this lives in the Federal Acquisition Regulation, Part 48, with the value engineering clauses, and for construction contracts the relevant incentive clause is commonly FAR 52.248-3. The split between contractor and government on an accepted VECP under a fixed-price contract is set by the clause. The point worth carrying is the structure, not a memorized percentage: the contractor develops the idea on its own initiative, the owner shares the resulting savings, and the contractor is paid its share only if the proposal is accepted.

The exact clauses, splits, and procedures vary by contract, agency, and jurisdiction, and they change over time, so confirm the value engineering provisions in the actual contract before relying on them. The methodology and the sharing mechanism are matters of the contract and the project. What holds across all of them is that a VECP still has to preserve the required function. A proposal that lowers cost by lowering performance is not a valid VECP, it is a request to change the scope, and the owner will treat it that way.

What good value engineering looks like

Good value engineering delivers the same function for less, and it shows up in a handful of recognizable moves. Right-sizing is the most common: the design carried more capacity, more redundancy, or more material than the function required, and the study brings it back to what the load actually needs. An oversized chiller plant sized off a conservative load that the real building never sees is money the owner can keep with nothing lost.

Alternative materials and methods are the next bucket. A different product, assembly, or installation method delivers the same function at a lower installed-plus-operating cost. The test is always the same: equal function, equal or better life-cycle cost. A duct material that meets the same pressure class and leakage class for less, or a routing that shortens the run without hurting performance, is real value.

Simplification and standardization round it out. Reducing the number of different components, standardizing on fewer equipment models, or cutting steps out of an assembly lowers cost in installation, in spares, and in maintenance, all without touching what the system does. A building with three types of rooftop unit instead of eight is cheaper to buy, stock, and service for its whole life. None of these lowers the function. That is what makes them value engineering and not cost-cutting.

What bad value engineering looks like

Bad value engineering lowers the function and calls the result a saving. The patterns are easy to spot once you know them, and they are exactly the moves that get made when a job is over budget and someone wants a cheaper number by Friday. Stripping insulation is the classic. The duct or pipe still runs, so it looks like the function is intact, but the system sweats, loses energy, and the operating cost climbs for the life of the building.

Cheap substitutes are the next pattern. The off-brand equipment carries the same nameplate rating and a worse service life, slower parts availability, and a control package that does not integrate cleanly. The first cost drops and the total cost rises, which is the opposite of value. Removing redundancy is the most dangerous one, because it works perfectly until the day it does not. The redundancy was bought to cover a failure, and deleting it saves money right up to the failure it was there for.

The quietest bad move is deferring cost to operations. A change that lowers the construction cost by raising the maintenance burden has not saved anything, it has moved the cost off the project budget and onto the owner's operating budget, where a first-cost analysis cannot see it. All of these share a signature: they look like savings on bid day and they are losses across the life of the asset, and most of them generate change orders when the cheap choice collides with the rest of the design.

Avoiding the cost-cutting trap

The trap is letting value engineering become a synonym for make it cheap, and there are four habits that keep a study out of it. Keep the function. Every proposed change has to deliver the same function at the same performance, and the verb-noun definition is what you check it against. If the function falls, it is not value engineering, and saying so is the job, not a failure of the study.

Use life-cycle cost, not first cost. The test that catches false savings is total cost over the life of the asset, and a study that decides on first cost will walk straight into the trap it was supposed to avoid. Let the owner decide. The value team recommends and the owner accepts or rejects against criteria that belong to them, because a team imposing its own idea of cheap is how value studies lose the owner's trust.

Document why. Every accepted change should carry the function it preserves, the life-cycle basis for the saving, and the owner's decision, because that record is what answers the question when someone asks two years later why the system is what it is. A change with no recorded reasoning is indistinguishable from a corner that got cut, and on the day a problem shows up, that distinction is the whole argument.

After acceptance: flowing the change into the work

An accepted value engineering proposal is a decision, not yet a built change. It has to flow into the design and the contract through the same controlled process as any other change, because a VE idea applied to the field without updating the drawings, the specifications, and the contract sum is a change that nobody can track and that the next person cannot explain.

The design team revises the documents to reflect the accepted proposal, the cost change is captured against the contract, and the schedule effect, if any, is recorded. On a contract with a defined change process this runs as a change order or a bulletin, and the savings or cost difference is documented there rather than disappearing into the final number. The change order guide covers that mechanism in full, including getting the change priced and signed before the work proceeds.

The discipline matters because a value change that bypasses the change process creates the same problem as an undocumented field change. The drawings no longer match the building, the cost record no longer reconciles, and the reason for the change lives only in someone's memory. Run accepted VE through the change process and the building, the documents, and the budget stay in agreement.

Keeping the value study on record

The value study is a record, and a study nobody can find later cannot be defended later. Capture the study itself: the functions analyzed, the proposals generated, the evaluation against the owner's criteria, the life-cycle cost behind each accepted proposal, and the owner's decision on each one. That package is what answers the question, months or years out, of why the project is what it is and whether a given change was a real value improvement or a quiet cut.

The reason to keep it tight is the same reason the change order log exists. When a problem surfaces, the first question is whether the system was ever right, and the value study record is the answer. It shows that the change preserved the function, that the saving was measured over the life and not just the first cost, and that the owner accepted it knowingly. Without that, an accepted VE proposal and a careless cut look identical in hindsight.

This is field-tool work, not a binder that gets lost. Keeping the study, the proposals, the decisions, and the life-cycle basis in a field system like FieldOS, attached to the project and the change record, means the reasoning travels with the job instead of living in one person's email. The decision and the basis for it stay retrievable on the day someone needs them.

Common mistakes

• Calling line-item cost-cutting value engineering, when the function is being lowered along with the cost.
• Skipping function analysis and going straight to shopping for cheaper materials.
• Deciding on first cost and ignoring life-cycle cost, which is where false savings hide.
• Running the study too late, after the decisions worth influencing are already locked.
• Stripping performance or deleting redundancy and booking it as a saving.
• Working with no defined owner value criteria, so the study has nothing to fail against.
• Letting the value team impose proposals instead of leaving the decision to the owner.
• Applying an accepted change to the field without flowing it through the contract change process.

Field checklist

Standards and references

The methodology itself comes from SAVE International, which publishes the value methodology standard and certifies practitioners, including the Certified Value Specialist credential that facilitators often hold. The job plan, the function vocabulary, and the FAST technique are theirs, and a study that claims to follow the value methodology is claiming to follow that standard. The depth of the study and whether a credentialed facilitator runs it are project decisions.

Life-cycle cost analysis is the cost framework behind the method, and there are recognized procedures for it, including standards for measuring life-cycle cost of buildings and systems. The analysis period, the discount rate, and the energy and maintenance assumptions belong to the owner and the project. Confirm them before a life-cycle number decides anything, because the same two options can rank differently under different but equally legitimate assumptions.

On public and federal work, the value engineering provisions live in the Federal Acquisition Regulation, Part 48, with the incentive clauses for contractor-initiated proposals, commonly FAR 52.248-3 for construction. The specific clauses, the savings split, and the procedures vary by contract, agency, and jurisdiction, and they change over time, so the contract and the applicable regulation control. Cite the value engineering provision that actually governs the project, and treat the function-preservation requirement as the line that does not move: a proposal that lowers performance is a scope change, not value engineering.

Terms and definitions

Value engineering carries a vocabulary that is precise inside the method and loose everywhere else, which is part of why the word gets misused. These are the terms as the methodology uses them.

Keep the value equation in front of all of it. Value is function divided by cost, cost is measured over the life of the asset, and any change that lowers the function is not value engineering no matter what it saves on bid day.

Value engineering

A structured method to improve a project's value by analyzing required functions and delivering them at lower life-cycle cost without losing performance

Function

What an element must do, stated as an active verb and a measurable noun, such as support load or resist water

Value = function / cost

The core relationship: value rises when function is held and cost falls, or when function is added for the same cost

SAVE job plan

The six-phase study sequence from SAVE International: Information, Function Analysis, Creative, Evaluation, Development, Presentation

Life-cycle cost

Total cost over the life of an asset: first cost plus operating, maintenance, and replacement, often discounted to present value

VECP

Value engineering change proposal, a contractor-initiated proposal on public or federal work where accepted savings are shared with the owner

FAST diagram

Function Analysis System Technique, a how-and-why map of a project's functions used to find high-cost, low-value functions

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is preconstruction?
• What is a change order?
• Is asphalt or concrete better for pavement?
• What is construction closeout?
• What is an assured equipment grounding conductor program (AEGCP)?