Value Management Before Value Engineering: Asking Why Before Cutting What

On construction and property projects around the world, a familiar moment arrives early in design. The estimate comes back higher than anyone hoped, and the first proposal is to take something out: a lower specification here, a smaller atrium there, a cheaper cladding system. Sometimes that is exactly right. Often it is the wrong question asked at the wrong time, because nobody has yet asked what the project is for, whether the building is the right answer to the client's problem, and which of its features actually carry the value the client is paying for.

The discipline that addresses this has two names that are frequently confused. Value engineering is the later, more technical job of meeting agreed functions at less cost. Value management is the broader process, and it starts earlier, with whether the project should proceed at all and what would count as success.

This comprehensive blog will explore the distinction between value planning, value engineering and value analysis; what the two early value management workshops, VM1 and VM2, are designed to decide; what the value-engineering job plan actually does, function by function; and why function-first analysis is what prevents a workshop from becoming a simple exercise in cutting cost. Whether you are a client adviser, quantity surveyor, architect, engineer or project manager, understanding why "why" must come before "how to do it for less" is key to buying value rather than merely spending less.

1. An Umbrella, and Three Different Times to Use It

Value management is best understood as an umbrella term. It describes the overall process and a family of techniques for securing value for money, and it is meant to be continuous rather than a single event. Under that umbrella sit three activities that differ less in their tools than in their timing and in the question each one asks.

Value planning is carried out before the decision to build, at the briefing stage, or at the very start of design. Its question is strategic: is a building the right answer, and if so, what must it achieve? Group techniques are used to reach a shared decision on the criteria by which the proposed design, or even the business strategy behind it, will be judged.

Value engineering comes later, during detailed design and sometimes into construction. Its question is narrower: given functions that the parties understand and accept, how can those functions be delivered at less cost? It is a systematic procedure aimed at achieving the required functions at least cost.

Value analysis is retrospective. Once a building is complete and in use, it asks whether the building performs as expected and whether the objectives established at the first workshops have actually been met. Its purpose is learning rather than blame: what went right and why, what went wrong and why, and what should not be repeated on the next project.

These are three different moments and three different questions, not three names for the same meeting. A value-engineering study held at concept stage has very little to work on, because functional analysis of elements and components assumes that a building has already been chosen as the solution and that a design exists. Conversely, a value-planning conversation held during detailed design arrives too late to change the decisions that matter most, because the largest decisions, and therefore the greatest potential for better value, sit at the start of the design process.

The distinction also rests on different assumptions. Value engineering assumes that all parties understand the functions being provided and that every feasible alternative delivers the same level of functional performance, so that alternatives can be compared on cost alone and an increase in value can be read as a reduction in cost. Value management makes no such assumption. It is a structured process of dialogue and debate among designers and decision-makers, intended to develop a common understanding of the design problem, to identify the design objectives explicitly, and to build a group consensus about the merits of alternative courses of action. It does not claim to find the optimal answer; it establishes a common decision framework within which people can think and communicate.

Reviews are recommended throughout a project to agree objectives and priorities, to finalise the brief and to ensure that value for money is achieved. The number of reviews depends on the size and scale of the project, and the people attending should understand the purpose of each meeting and have sufficient authority to make decisions. A team leader, increasingly called a facilitator, organises and manages the workshops and should be appointed at the earliest opportunity, so that preparation, follow-up and continuity sit with one person.

In UK practice of this period, the early workshops were commonly run using SMART, the Simple Multi-Attribute Rating Technique, as a way of structuring debate. The discipline itself had evolved over decades, changing its name along the way, but its consistent aim was to eliminate unnecessary cost without loss of the required function or quality.

Figure 1: Planning, engineering, analysis: three times, one umbrella. Value planning comes before the decision to build or at early briefing, value engineering comes later in design, and value analysis looks back once the building is in use. The sequence is a way of thinking about timing, not a fixed project calendar.

2. VM1 and VM2: Decide Whether, Then Choose Among Costed Options

The two early value management workshops are timed to coincide with points at which the client must make important decisions. Each was typically a one-day event, and each has a distinct job.

VM1 takes place at the end of the concept stage, when a new facility is first suggested as a possible solution to a perceived problem; in the RIBA plan of work of the period, this was Stage A. VM1 is closely tied to the decision whether the project should proceed. Its primary objective is to verify the need to build before the client is committed to expenditure. Its secondary objective is to ensure that there are clear project objectives that every party understands.

The stages of VM1 resemble those of value engineering on the surface, but the differences matter. Before the workshop, the key stakeholders are identified. This is harder than it sounds, because many clients are organisations made up of groups with different interests, priorities and perceptions, and there may not even be agreement that a building is needed. Unless the most senior representatives of those interests take part at this early stage, problems tend to surface later, and it is not unusual for recommendations to be blocked because the people in the room were not representative or lacked the authority to carry decisions forward. A workshop of substitutes is not the same exercise.

In the workshop itself, the team first identifies the design objectives. Each participant explains what they perceive the problem to be, and the aim is a "meeting of minds" on what the problem is and agreement on a set of key objectives, assuming that the need to build is confirmed. Those objectives are then structured into a value tree: a primary objective broken down progressively into sub-objectives and lower-level attributes. This is not a mechanical exercise. It involves discussion and negotiation among competing individual objectives until each member can accept the tree as a fair representation of what the project is meant to achieve. The lower-level attributes later become the criteria against which design options are compared. The workshop then moves to speculation, using techniques such as brainstorming to generate alternative ways of meeting the objectives, and to evaluation, in which ideas that are not feasible or are too costly are set aside. Development of the surviving proposals is mostly carried out after the workshop, and arrangements for that work should be made before the team disperses.

VM2 follows at the end of the feasibility stage, then RIBA Stage C, when the outline brief is complete and the design team has prepared a selection of costed outline schemes. Its stages are more analytical. The team first checks the design objectives and amends them if circumstances or new information justify it; a degree of flexibility is sensible at this point, though not indefinitely. The value tree is then reconstructed, both to reflect any changes and to simplify it so that only attributes that genuinely discriminate between the options remain. Capital cost is deliberately left to the end.

Next, importance weights are assigned. Each member gives a view on the relative importance of each branch, and the weights are discussed until the final values represent joint agreement that everyone can accept, even if some compromise is involved. The options are then scored against each attribute according to how well the team believes they satisfy it, again by discussion. A sensitivity analysis follows: where members feel uneasy about particular scores or weights, those are revisited and changed to see whether the order of merit alters. Often it does not, but checking matters so that the team is comfortable with the result. Only then is the estimated capital cost of each scheme set against its overall score, so that the option offering the best value for money can be chosen. A final session looks for marginal value improvements in the chosen design.

The numbers in this process are a facilitative device, not the decision itself. Their purpose is to structure and formalise debate, and it is the process of agreeing them that carries the value. A reasonable interpretation is that the value tree and the weights are as much consensus devices as analytical ones: they make objectives explicit enough to argue about. There is also a theoretical caution here. Weighted scoring of this kind draws on multi-attribute utility theory, and used naively it implies that decision-makers are fully rational and consistent and that value can be reduced to a single score. Value management, by contrast, treats the model as requisite: good enough to represent the group's shared understanding at the point a decision can be made, not a claim to the optimal answer.

Figure 2: VM1 asks whether; VM2 chooses among costed options. VM1, at the end of the concept stage, verifies the need to build and agrees objectives in a value tree. VM2, after feasibility, checks the objectives, weights and scores the costed outline schemes, tests uneasy scores, and only then reconciles cost with value. The stage letters are those of the period.

3. The Value-Engineering Job Plan: Function First

Value engineering is older than value management. Its roots are often traced to the early years of the twentieth century, when G. J. Churchward, designing a range of locomotives for the Great Western Railway, sought maximum interchangeability of parts and introduced design disciplines intended to ensure that each component delivered maximum function at minimum cost. The idea resurfaced in the United States at General Electric, where a shortage of key components led the purchasing engineer Lawrence Miles to frame the task as getting the function when the part could not be had. Identifying a component's function and finding another way to provide it often reduced cost as a side effect, and the basic philosophy followed: eliminate the cost that does not contribute to the required function.

In building design, unnecessary cost has long been regarded as endemic, simply because of the complexity of the process. Every design contains some. The usual explanations are a lack of ideas, a lack of cost analysis, a lack of time, a lack of information and the lack of a yardstick against which to judge. That is a widely held view rather than a measured rate, and no reliable figure for the proportion of unnecessary cost should be assumed. What it does explain is the appeal of a structured procedure, run by a multi-disciplinary team of quantity surveyors, architects, engineers and others under a team leader, that can be inserted systematically into design.

That procedure is the job plan, and it has five phases.

The information phase gathers data on the building or component under study, and it places great emphasis on functional analysis. Whether the subject is a whole building or a window, the team first establishes what it does, and what else it does. This is little more than defining the problem properly, but concentrating effort on those simple questions sharpens the work that follows. Functional analysis systems technique (FAST) diagrams are one way of structuring the phase. A related idea, functional costing, relates cost to worth, where worth is the least cost of providing the function.

The speculation phase uses creative techniques, most commonly brainstorming, to generate as many alternative ways as possible of providing each function identified. The rules are simple: suspend judgement, welcome unusual ideas, aim for quantity, and build on the ideas of others. Keeping this phase separate from evaluation is essential, because criticism kills momentum.

The evaluation phase assesses the ideas for feasibility and cost, combining and consolidating them into a short, manageable list worth developing further. Ideas that fail to perform the required basic function are eliminated. The development phase works the survivors up in detail, making sure that every interface with adjacent components is accounted for and that the cost of each option is estimated as rigorously as the data allow, including life-cycle costing. The presentation phase identifies the best solution and recommends it, usually through a formal presentation followed by a written report.

The defining move is the first one. Alternatives are generated for each function, not for each component someone would like to keep or remove. A fair reading of the method is that without functional analysis the exercise collapses into cost-cutting, which is precisely what value engineering is not. Its purpose is to raise value by removing cost that contributes nothing to function; a lower cost is a consequence, not the aim.

Workshop formats varied. One approach placed a value engineer in the design team from the briefing stage as a facilitator, with mini-workshops following the job plan at about 15 percent and 35 percent design completion. Another was the two-day workshop, then described as perhaps the most popular format in the UK, in which information and speculation occupy the first day, evaluation follows, and detailed development is carried out largely outside the workshop before the presentation. Whatever the format, establishing the team leader and team early, and doing preparatory work before the workshop, improves the outcome. These formats and timings are those of their period, not a current standard.

Figure 3: The five-phase job plan: information, including functional analysis; speculation, generating alternatives for each function; evaluation, narrowing to a short list; development, including interfaces; and presentation of a recommended solution. Functional analysis comes before any search for cheaper alternatives.

4. Why "Why" Has to Come First

A workshop that opens with "what can we take out?" has skipped two steps. It has skipped value planning, because nobody has confirmed that the objectives behind the design are agreed and still valid. And it has skipped functional analysis, because nobody has asked what each item does before deciding it can go. The result may be a lower estimate, but it is not necessarily better value, and it may quietly remove something that a key stakeholder regarded as the point of the building.

The deeper reason lies in the nature of the problem. Value engineering deals largely with hard, technical questions where functions are reasonably easy to identify and where data can serve as objective evidence. The questions value management handles are different: they are bound up with conflicting objectives, internal politics and value judgements for which there is no external proof. Some describe these as "messy" or "wicked" problems. That is why value management is best understood as a social process, concerned with how people with different interests reach a shared understanding of both the problem and its resolution. It accepts pluralism rather than pretending it away, and uses difference as a source of creativity, which in turn places heavy demands on the facilitator. The facilitator's role is to enable and guide rather than to act as the visiting expert, to attend to how the group is working as well as what it is producing, and to ensure that every voice is heard and no vocal individual dominates. Senior stakeholders and a skilled facilitator are not ceremonial; they are what make the early questions answerable.

Team composition shapes the answers too. Some organisations prefer a facilitator who is not directly involved in the project, drawn from a trained internal pool or engaged as an external consultant, because perceived neutrality helps keep discussion unbiased. Opinions differ on whether a review team should be entirely fresh. New members are more likely to challenge the original ideas and avoid what is sometimes called single-solution fixation, but original designers may resent the challenge and resist the changes, so a mixed team is often suggested as a middle course. In the early phases, the key senior people must be present; later, the team should reflect the expertise needed to implement the project.

Cost planning sits next door to all of this and supports it. A cost plan allocates and controls cost against a brief, and good pre-contract cost control is indispensable. But a cost plan does not, by itself, ask whether the brief is the right brief. The two disciplines work together; they are not the same job.

Consider a client whose new headquarters scheme has returned an estimate well above budget. The cost consultant offers a list of omissions and downgrades that together would bring the capital cost back into line: a reduced reception, simpler external works, a cheaper façade, fewer meeting rooms. Each item is defensible in isolation. Nothing on the list, however, has been tested against agreed objectives or examined for what it actually does. A different sequence would begin by checking, with the senior people who own the business case, what the building is meant to achieve and how those objectives rank; it would then analyse the functions of the costly elements and generate alternative ways of meeting them. That sequence might confirm several of the same omissions. It might also reveal that the meeting rooms carry a function the business values highly, while a feature nobody listed as important is consuming cost. Which route gives the better outcome depends on the project, but only the second can tell the difference.

Figure 4: Not this, unless the function has been examined. Cutting items straight from the estimate is the shortcut; agreeing why the project exists, analysing what each element does, and then generating lower-cost ways of meeting those functions is the sequence. The sequence makes better value possible but does not guarantee a saving.

5. A Review That Keeps the Questions in Order

The distinctions above are easiest to lose under time pressure, when an estimate is high and a decision is due. A short review, applied before any value exercise is commissioned or reported, helps keep the questions in the right order. It is an aid to judgement, not a certified protocol.

1. Is this a value-planning moment or a value-engineering moment? If the real issue is whether the project should proceed, or what would count as success, it needs a value-planning conversation of the VM1 kind. If the functions are agreed and the question is how to deliver them for less, value engineering is the right tool. Using the second to answer the first is the commonest mistake.

2. Are the key stakeholders actually in the room? At the early workshops, that means senior representatives of the interests that make up the client, with the authority to carry decisions forward. If they are absent, the outcome may be overturned later.

3. Has a value tree been built, or rebuilt, and have weights been discussed rather than assumed? The tree should be one that every member can accept as a fair statement of the objectives, simplified to attributes that genuinely distinguish the options. Weights imposed without discussion defeat the purpose of the exercise.

4. If options are being scored, have uneasy scores been tested, and has cost been reconciled with value rather than substituted for it? Capital cost belongs at the end of the analysis, set against the overall scores. A choice made on cost alone, without reference to how well each option meets the objectives, is not a value decision.

5. If value engineering is under way, did functional analysis come before the search for cheaper alternatives, and will the job plan run through to a recommended solution? A list of savings without a statement of the functions each change preserves, and without a developed and presented recommendation, is not the output of a value-engineering study.

6. Which stage names, workshop timings and methods need a current source? The stage letters, the mini-workshop timings and the popularity of the two-day format described here belong to their period. The current RIBA Plan of Work uses a different stage structure, and current value management standards and practice should be consulted before any of this is written into an appointment or a project procedure.

Applied honestly, the review tends to slow the first meeting down and speed everything after it up. A team that has agreed why the project exists and what each part of it is for argues less about what to cut, because it can see what each cut would cost in value as well as in money.

Conclusion

Value management is the umbrella. Beneath it, value planning asks whether the project should proceed and what it must achieve; value engineering then looks, function by function, for better and less costly ways of meeting agreed objectives; and value analysis checks afterwards whether the building delivered what was intended. VM1, at the end of the concept stage, verifies the need to build and turns the client's objectives into a value tree that everyone can accept. VM2, after feasibility, revisits those objectives, weights and scores the costed outline schemes, tests the scores that make people uneasy, and only then sets cost against value to choose the best value for money.

The value-engineering job plan carries the same logic into later design. Its first phase asks what each element does before anyone asks what it costs, and its later phases generate, evaluate, develop and present alternatives for those functions. Remove that functional analysis, and what remains is cost-cutting with a respectable name.

That is the practical lesson. A list of omissions offered in response to a high estimate may be the right answer, but it can only be shown to be right once the objectives have been agreed by the people who own them and the functions of the affected elements have been examined. Asking why before cutting what is not a delay to the cost exercise; it is what makes the cost exercise mean something. Senior stakeholders, a capable facilitator and a disciplined sequence are what make that possible. The benefits claimed for the approach follow from that discipline rather than from any particular scoring technique: the need for a project is verified, objectives and decisions are discussed openly and made explicitly, alternatives are always considered, and there is a clearer audit trail for why money was spent where it was. Value management is not a cure for every ill in the industry, and it should not be presented as one, but those benefits are considerable when the questions are asked in the right order.