The purpose of value engineering is to protect the required function while improving the relationship between outcomes, resources and lifecycle consequences.
When budgets tighten, leaders often ask teams to “value engineer” a project. In practice, this can become a polite instruction to remove cost. Specifications are reduced, cheaper components substituted and contingencies challenged. The investment becomes less expensive—but not necessarily more valuable.
Cost reduction and value improvement can coincide. They are not the same decision.
A change creates value only when it improves the relationship between what the organisation needs and the full resources, risks and consequences required to achieve it. A cheaper asset that fails earlier, consumes more labour or constrains future capacity may reduce project cost while destroying enterprise value.
The Strategic Context
Value management begins before detailed design. It clarifies what matters, why it matters and how alternatives will be judged. Value engineering applies similar functional reasoning when solutions are sufficiently defined to test components, methods and configurations.
This distinction protects leaders from optimising too late. Once a design is mature and commitments are made, many high-value alternatives are no longer available. The project can substitute materials or simplify features, but it may be unable to reconsider the operating model, location, sequence or business need.
Current UK infrastructure guidance emphasises outcome-led and value-based decisions across the lifecycle. The principle is transferable: value should shape the investment from initiation, not arrive as a cost-reduction exercise after approval.
What Leaders Commonly Misread
The first misreading is that value is an inherent property of the product. Value depends on the stakeholder, time horizon and system. Automation may create value for throughput but reduce flexibility. Standardisation may lower operating cost but constrain premium customer offerings.
The second is that function means technical performance only. Required function may include safety, service continuity, maintainability, adaptability, compliance, user experience and resilience.
The third is that capital cost is the correct denominator. Purchase price is only one part of lifecycle commitment. Installation, energy, consumables, downtime, training, maintenance, data, spares and disposal can materially alter the decision.
The fourth is that more functionality means more value. Unused features add complexity, support obligations and failure modes. The question is not how much the solution can do, but which functions are necessary to produce the intended outcome.
Reframing the Issue
A simple value relationship compares required function with lifecycle resources and consequences. It should not be used as a mechanical ratio; many benefits and harms cannot be responsibly reduced to one number. Its value is as a discipline for comparison.
Leaders should ask:
- Which functions are essential to the strategic outcome?
- Which features merely reflect the current solution concept?
- What alternative could provide the same function differently?
- What cost or risk moves outside the project if we choose the cheaper option?
- Which option remains valuable under more than one future scenario?
This moves the team from defending specifications to examining purpose.
Define Value Before Generating Alternatives
An effective value process starts with evidence about the need and the operating environment. Participants should agree evaluation criteria before becoming attached to solutions.
Criteria might include:
- safety and regulatory confidence;
- customer or citizen outcomes;
- lifecycle cost;
- delivery time and disruption;
- reliability and maintainability;
- adaptability and scalability;
- environmental or social consequences;
- workforce capability; and
- strategic optionality.
The criteria should be weighted or prioritised transparently. Otherwise, the loudest stakeholder or lowest initial price may dominate.
Separate Function from the Existing Solution
Functional analysis asks what must be achieved without assuming how it will be achieved.
Consider a hypothetical manufacturer planning a new press line. The initial request may specify another large machine. The underlying functions could include increased forming capacity, shorter changeovers, safer handling and improved traceability. Alternatives might include debottlenecking the existing line, redesigning tooling, outsourcing selected demand, changing product architecture or installing modular equipment.
The original machine may still be best. The value process earns confidence by demonstrating that it was chosen from credible alternatives rather than inherited from the first proposal.
Protect Lifecycle Value from Project-Level Savings
Project teams are often measured against capital budgets and completion dates. Operational costs appear after handover and may belong to another business unit. This creates an incentive to approve savings that transfer cost downstream.
Executives should require lifecycle consequences to accompany material substitutions. A lower-cost pump, software licence or coating system may change maintenance frequency, inventory, energy consumption, reliability, training or warranty exposure.
The same logic applies to schedule. Accelerating delivery may create earlier benefits, but it can also increase rework or disrupt operations. Value integrates these consequences instead of optimising one constraint.
Related article: Why the Iron Triangle Is Too Narrow for Executive Project Control
Decision Framework
| Stage | Leadership purpose |
|---|---|
| Understand | Confirm need, stakeholders, constraints and value criteria |
| Challenge | Separate required functions from inherited solutions |
| Generate | Create genuinely different ways to achieve the functions |
| Evaluate | Compare lifecycle value, risk, feasibility and reversibility |
| Develop | Resolve interfaces and test the strongest alternatives |
| Decide | Select, defer or reject with an explicit evidence trail |
| Verify | Confirm that promised value survives design and implementation |
The quality of alternatives matters more than the number generated. Cosmetic variants do not create strategic choice.
From Strategy to Execution
Immediate action: Before the next cost-reduction decision, identify the function being protected and the lifecycle consequence of each option.
Medium-term capability: Establish facilitated value reviews at initiation, scope definition, design maturity and major change points. Include operations, users, commercial, engineering and finance.
Long-term positioning: Build value criteria into portfolio selection and benefits management. Projects should compete on the quality and resilience of the outcomes they enable, not only their capital request.
Related article: Change Control Is Capital Allocation in Disguise
Signals to Monitor
- “Value engineering” begins only after a budget problem emerges.
- Savings are reported without lifecycle effects.
- Functions and acceptance criteria change after a cheaper option is selected.
- Operations carries costs that were absent from the business case.
- Alternatives differ only in supplier or specification, not solution logic.
- Optionality, resilience and maintainability have no decision weight.
- Teams add functionality that cannot be linked to an outcome.
Questions for the Leadership Team
- Which function are we protecting through this decision?
- Whose definition of value is dominating the analysis?
- What cost or risk is being transferred beyond the project boundary?
- Which alternative would we choose under a different demand or funding scenario?
- Are we removing waste, reducing performance or merely lowering initial price?
- How will we verify that the selected option actually creates the expected value?
Closing Perspective
Value engineering becomes dangerous when it is used to legitimise predetermined cuts. Used properly, it is a disciplined challenge to assumptions: what must the system accomplish, what alternatives exist and which choice produces the strongest lifecycle outcome?
The executive responsibility is not to defend every specification. It is to ensure that savings do not quietly purchase a weaker future.
About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.