Value Engineering: Functions, Alternatives and Lifecycle Cost

Understand Value Engineering: function analysis, FAST, Job Plan, alternatives, CAPEX, OPEX, lifecycle cost, risk, governance and project implementation.

Check it out!

Value Engineering is a structured methodology for increasing the value delivered by a project by analyzing the functions the solution must fulfill, the resources required, and the alternatives capable of meeting the requirements. In engineering projects, it helps compare technical options without arbitrarily reducing quality, safety, reliability, or performance.

Also known as Value Engineering (VE), Value Analysis, or the Value Methodology, the approach seeks the best balance among function, performance, quality, risk, schedule, implementation cost, operation, maintenance, and lifecycle. The objective is not simply to make the project cheaper, but to eliminate unnecessary costs and direct resources toward what effectively creates value for the owner and asset users.

Its application is especially relevant during feasibility, Conceptual Design, FEED and Basic Design, when there is still freedom to compare architectures, technologies, implementation strategies, and contracting models. However, value studies can also be performed during Detailed Design, procurement, and execution, provided the consequences of late changes are assessed and controlled.

What Value Engineering is in engineering projects

SAVE International presents the Value Methodology as a systematic process conducted by a multidisciplinary team and based on function analysis. The method seeks the optimal balance among function, performance, quality, safety, and resources employed.

In engineering, this means studying the project based on what each system, piece of equipment, component, document, or process needs to do. The team stops asking only “which solution was specified?” and begins asking “which function needs to be fulfilled, according to which criteria, and why was this solution selected?”

This change in perspective creates room for alternatives that can:

preserve the function at a lower total cost;
increase performance without a proportional increase in resources;
reduce implementation and operational risks;
simplify interfaces;
improve availability, maintainability, or expandability;
reduce implementation time;
avoid oversizing or unjustified redundancy;
concentrate investment on the project’s critical functions.

Value is not synonymous with the lowest price

Value can be represented conceptually as the relationship between the performance of the functions delivered and the resources required to produce them. This relationship should not be used as a simplistic financial ratio. It serves to show that value can increase in different ways:

Situation	Effect on value
Maintain the function and reduce resources without creating risks	Value increases
Increase performance with the same level of resources	Value increases
Substantially improve function and performance with a small increase in resources	Value may increase
Reduce cost by sacrificing an essential requirement	Value decreases
Add resources without a demonstrated functional benefit	Value decreases
Shift implementation cost to operations and maintenance	Value may decrease over the lifecycle

An alternative with lower CAPEX may result in higher energy consumption, more frequent maintenance, downtime, shorter service life, or expansion difficulties. For this reason, Value Engineering needs to consider total cost and expected outcomes, not only the initial budget.

Value Engineering is not cost cutting

Cost cutting starts from a financial target and seeks reductions. Value Engineering starts from functions and requirements, identifies what is essential, and develops technically substantiated alternatives.

A reduction made without function analysis may remove necessary redundancy, reduce safety margins, create incompatibilities, limit maintenance, or transfer risks to the operator. In contrast, a value study should demonstrate:

which function is being analyzed;
which requirements must remain satisfied;
which cost or resource is associated with the function;
which alternatives were considered;
which technical, economic, and operational impacts exist;
why the recommendation provides greater overall value.

Difference between Value Engineering and related methods

Value Engineering relates to other lifecycle practices but should not be confused with them.

Method	Central question	Primary outcome
Value Engineering	How can the required functions be fulfilled with a better relationship between performance and resources?	Higher-value alternatives and recommendations
Design Review	Is the design technically coherent, complete, and suitable for the requirements?	Comments, open items, and technical approval
Design Coordination	Are the disciplines and models coordinated, without physical or functional conflicts?	Resolved clashes and coordinated interfaces
Constructability	Can the solution be implemented under actual field conditions?	Executable strategies, details, and methods
Benchmarking	How do costs, schedules, and performance compare with benchmarks?	Benchmark ranges and improvement opportunities
Earned Value Management	Is the project executing schedule and cost in accordance with the baseline?	Performance indicators and forecasts
ECM	How will technical changes be requested, evaluated, approved, and implemented?	Controlled changes and updated configuration

The U.S. Federal Transit Administration expressly emphasizes that Value Engineering is not a design review. Technical review evaluates the developed solution; Value Engineering uses function analysis and structured creativity to develop alternatives. The methods can be coordinated, but one does not replace the other.

Value starts with the function, not the specified solution. By separating what the system needs to do from the way currently selected to do it, the team can compare architectures and technologies without losing essential requirements.

See how Conceptual Design structures alternatives before detailing

When to apply Value Engineering in the lifecycle

The opportunity to influence value is greatest when decisions have not yet been materialized in contracts, purchased equipment, and completed construction. The later an alternative is proposed, the higher the change cost may be and the less freedom there is to adopt it.

This does not mean the study should occur only once. Complex projects may use progressive reviews adjusted to engineering maturity and the main decision gates of the project lifecycle.

Feasibility and FEL

During feasibility and Front End Loading, Value Engineering helps verify whether the project is solving the right problem and whether the selected alternative represents the best combination of benefits, risks, and resources.

The analyses may compare:

new implementation or reuse of existing infrastructure;
centralized or distributed solution;
full expansion or phased implementation;
full redundancy or selective redundancy based on criticality;
owned acquisition, managed service, or hybrid model;
technologies with different implementation and operating costs;
continuity strategies during retrofit;
different locations, capacities, and architectures.

At this stage, high-impact decisions can still be changed at relatively low cost. An inadequate assumption corrected during feasibility prevents it from propagating into estimates, permitting, design, procurement, and execution.

Conceptual Design

During Conceptual Design, the team can structure the study around the project’s primary functions. Instead of prematurely detailing a single solution, architectures capable of meeting the requirements are compared.

Examples:

in a Data Center, compare power and cooling topologies considering availability, expansion, and concurrent maintainability;
in structured cabling, compare centralized and distributed architectures considering distances, technical rooms, redundancy, and operations;
in video surveillance, compare processing, storage, and communication architectures considering retention, availability, and cybersecurity;
in access control, evaluate centralization, edge intelligence, and integration with fire alarm, elevators, and corporate systems;
in electrical installations, compare voltage levels, distribution arrangements, panel locations, and selectivity strategies;
in retrofit projects, compare full replacement, phased migration, and temporary coexistence between systems.

FEED and Basic Design

During FEED and Basic Design, alternatives need to be developed in sufficient depth to support budgeting, scheduling, contracting, and the investment decision.

The study should consider:

design basis and criteria;
capacity and expansion margins;
safety and compliance requirements;
interfaces among disciplines;
constructability and logistics;
equipment and supplier availability;
manufacturing and delivery lead times;
energy and input consumption;
operations and maintenance;
testing, commissioning, and acceptance;
risks and contingencies;
CAPEX, OPEX, and lifecycle cost.

The connection to FEED in Engineering is direct: Value Engineering helps select and consolidate alternatives before the main investment commitment.

The greatest value opportunity appears before the main investment commitment. During FEED, alternatives can still influence scope, arrangement, estimate, schedule, risks, and contracting strategy.

Explore the role of FEED in project definition

Detailed Design

During Detailed Engineering Design, the freedom to change is already lower, but there may still be opportunities to:

simplify details without compromising requirements;
standardize components;
reduce the variety of materials and spares;
improve modularization and preassembly;
adjust routes and arrangements;
reduce unnecessary interfaces;
improve accessibility and maintenance;
incorporate final supplier information;
reduce fabrication and installation rework.

A proposal at this stage should consider the cost of revising documents and its effects on contracts, procurement, fabrication, and schedule. Apparent savings may disappear once the costs of change, cancellation, remobilization, or repeated testing are included.

Procurement and execution

During In engineering project procurement, alternatives may emerge during market inquiries, technical bid leveling, and proposal analysis. Suppliers and installers have specific knowledge that can reveal better options, but the decision should not become an informal commercial substitution.

During execution, value proposals may involve construction methods, logistics, sequencing, prefabrication, alternative equipment, or schedule reduction. When a recommendation changes requirements, specifications, scope, or price, it needs to follow the contractual process and Engineering Change Management.

Value Engineering identifies and develops the alternative. ECM controls the decision and its implementation.

An approved alternative should not become an informal change. When the recommendation changes requirements, documents, equipment, contracts, or configuration, implementation needs to be controlled and traceable.

See how Engineering Change Management controls changes

How to analyze functions, costs, and requirements

Function analysis is the element that differentiates Value Engineering from a conventional cost review. It describes what needs to be accomplished without prematurely tying the function to the existing solution.

Basic function and secondary functions

The basic function represents the essential reason for the existence of the object being analyzed. Secondary functions support, protect, control, or improve the basic function.

Functions are generally described directly using a verb and a noun. Examples:

Object	Possible functions
UPS	Maintain power; condition power; support transition
Video surveillance system	Detect events; record images; support investigation
Access control	Authorize entry; block passage; record events
Structured cabling	Transport data; organize connections; enable reconfiguration
Lightning Protection System	Intercept lightning; conduct current; dissipate energy
Generator	Supply power; sustain loads; restore autonomy
Monitoring system	Collect data; identify deviations; issue alarms
Detailed Design	Define the solution; coordinate interfaces; guide execution

Functional description prevents the discussion from being limited to brands, models, or historically used solutions.

Use functions and esteem functions

Use functions deliver technical or operational performance. Esteem functions relate to perception, identity, appearance, comfort, or user confidence. In corporate and institutional projects, both may be relevant.

A solution visible to the public, for example, may need to preserve architectural language and user experience. However, aesthetic requirements should be made explicit and evaluated, not treated as an implicit justification for any cost.

Requirements are the boundaries of creativity

Generating alternatives does not authorize ignoring requirements. Before the creative phase, the team needs to consolidate:

owner and user needs;
technical standards and legislation;
safety requirements;
availability and continuity;
performance and capacity;
environmental conditions;
physical and functional interfaces;
operations and maintenance;
cybersecurity;
service life and expansion;
budget and schedule;
commissioning and acceptance criteria.

Incomplete requirements produce incomparable alternatives. Overly prescriptive requirements, on the other hand, may inhibit innovation by determining the solution before the functions are analyzed.

Costs by function

The team should relate resources to functions. This helps identify high-cost functions, low-relevance functions consuming resources, and requirements that may be met by solutions that are unnecessarily complex.

Cost by function may include:

engineering and management;
equipment and material acquisition;
supporting infrastructure;
installation and integration;
testing and commissioning;
training and documentation;
energy and consumables;
preventive and corrective maintenance;
licenses and support;
spare parts;
downtime and operational loss;
replacement, modernization, and disposal.

Detailed-estimate accuracy is not required to begin the analysis, but assumptions, accuracy ranges, and uncertainties should be stated.

FAST diagram and functional logic

The FAST diagram — Function Analysis System Technique — organizes relationships among functions through questions such as “how is this function performed?” and “why is it necessary?”. The technique helps separate ends from means, identify duplicate functions, and recognize dependencies.

In multidisciplinary projects, functional logic also reveals interfaces. The function “maintain power,” for example, may depend on the utility supply, UPS, batteries, generator, automation, protection, cooling, and operating procedures. A change in only one subsystem may alter overall performance.

How to conduct a Value Engineering study

The Federal Highway Administration organizes the process into a Job Plan, a systematic plan for preparing the study, understanding the project, analyzing functions, generating ideas, evaluating alternatives, developing recommendations, presenting them, and following implementation.

The structure can be adapted to the scale of the project, but it should not be reduced to an informal cost-reduction meeting.

1. Preparation

Preparation defines the subject of the study, objectives, team, required information, and timing.

The following should be established:

study scope and boundaries;
problem or opportunity;
engineering stage and maturity;
decisions that can still be changed;
priority functions and systems;
mandatory requirements;
input documents;
participants and specialists;
evaluation criteria;
schedule, responsibilities, and deliverables.

Selecting the study subject is important. Studies that are too broad may generate superficial recommendations; studies that are excessively narrow may optimize one component while harming the system.

2. Information

The team needs to understand the project before proposing alternatives. The information phase gathers:

business case and objectives;
requirements and design basis;
scope and WBS;
drawings, models, and technical specifications;
estimates and schedules;
contracting strategy;
risks and constraints;
field conditions;
operations and maintenance data;
previous decisions;
interfaces and assumptions;
lessons learned and benchmarking.

The project presentation should explain why the current solution was selected and which problems it seeks to solve. Without this context, the team may rediscover options previously rejected for valid reasons.

3. Function analysis

The team identifies, classifies, and relates the functions. It also associates costs or resources with the most relevant functions.

Useful questions include:

what is the basic function?
which functions are mandatory?
which functions merely support the current solution?
how much does it cost to fulfill each function?
which functions concentrate the greatest cost or risk?
are there duplicate functions?
are there specifications that describe means instead of outcomes?
which functions differentiate alternatives?

4. Creativity

During the creative phase, ideas are generated without premature judgment. The objective is to broaden the set of possibilities before evaluation.

Alternatives may involve:

a different architecture;
different technology;
a change in capacity or modularity;
standardization;
reduction of interfaces;
redistribution of functions;
off-site fabrication;
phased implementation;
task automation;
a change in contracting model;
controlled reuse of assets;
a change in location or arrangement;
a passive solution instead of an active one;
improved operations or maintenance.

Creativity should involve people from different disciplines. Designers, operations, maintenance, suppliers, construction, commissioning, cost engineering, and safety see different constraints and opportunities.

5. Evaluation

Ideas are screened and compared against predefined criteria. Alternatives that fail to meet mandatory requirements should be discarded or returned for further development.

A matrix may consider:

Criterion	Evaluation question
Functional compliance	Does it fulfill all basic functions?
Safety	Does it maintain or improve safety conditions?
Compliance	Does it comply with standards, legislation, and owner requirements?
Performance	Does it deliver the required capacity, availability, and quality?
CAPEX	What investment is required?
OPEX	What are the energy, licensing, support, and maintenance costs?
Schedule	How does it affect engineering, procurement, implementation, and startup?
Risk	Which uncertainties and new failure modes are introduced?
Constructability	Can it be implemented under actual conditions?
Operability	Is it simple, safe, and understandable for operations?
Maintainability	Does it allow inspection, isolation, replacement, and repair?
Expandability	Does it support growth and future changes?
Sustainability	How does it affect energy, materials, waste, and service life?
Contracts	Does it require changes to scope, price, or responsibilities?

Weights may be applied when criteria have different importance. However, scoring should not conceal disqualifying requirements or replace technical judgment.

6. Development

Selected alternatives are developed to the level required for a decision. A recommendation needs to be more than an idea.

The package should include:

description of the current solution;
functions and requirements preserved;
description of the alternative;
preliminary drawings or diagrams;
assumptions and interfaces;
CAPEX and OPEX estimate;
schedule impact;
risks and opportunities;
contractual effects;
design and validation needs;
implementation plan;
expected savings or benefit;
lifecycle analysis;
conditions and responsible parties.

7. Presentation and decision

Recommendations are presented to the competent authority. The decision may be:

approved;
approved with conditions;
returned for additional development;
retained as a future opportunity;
rejected with justification.

Traceability is essential. Rejecting an alternative may be correct when risk, uncertainty, schedule, or implementation cost outweighs the benefit. The record should demonstrate the criteria used, preventing the decision from being reinterpreted later.

8. Implementation and follow-up

An approved recommendation does not yet create value. It needs to be incorporated into requirements, documents, budget, schedule, contracts, procurement, execution, testing, and As-Built documentation.

Follow-up should verify:

revised documents;
formally approved changes;
updated contracts and purchase orders;
assigned responsibilities;
treated risks;
adequate tests;
benefits actually achieved;
lessons recorded.

FHWA emphasizes that teamwork, function analysis, creativity, and structured evaluation are necessary elements for characterizing a VE study. Meetings that use only part of these elements should not be presented as a complete application of the methodology.

How to compare alternatives over the lifecycle

The highest-value recommendation is not always the one with the lowest initial cost. Lifecycle cost makes it possible to compare the resources required during acquisition, implementation, operation, maintenance, modernization, and decommissioning.

CAPEX, OPEX, and total cost of ownership

An analysis may consider:

Component	Examples
Engineering	surveys, studies, design, coordination, and management
Acquisition	equipment, materials, licenses, and transportation
Implementation	construction, installation, integration, migration, and testing
Operations	energy, consumables, connectivity, staff, and services
Maintenance	inspections, contracts, parts, repairs, and upgrades
Downtime	operational losses, contingency, and recovery
Expansion	modules, capacity, space, and new licenses
End of life	replacement, disposal, decontamination, or decommissioning

When cash flows occur in different periods, present value, discount rates, and scenarios may be applied. Sophistication should be proportional to the decision; the important point is not to compare only initial costs when alternatives have different operating profiles.

Initial savings do not guarantee a lower total cost. Energy, maintenance, licenses, downtime, expansion, and replacement can reverse the comparison among alternatives over the service life.

See the Cost Engineering and Estimating guide

Risk and uncertainty

Savings estimates are not certainties. Uncertainties related to the following should be stated:

engineering maturity;
market prices and availability;
productivity;
technology performance;
unknown interfaces;
field conditions;
delivery lead time;
learning curve;
operations and maintenance costs;
failure rate and service life.

The analysis may use ranges, sensitivities, and scenarios. An alternative with greater average savings may be inferior if it carries a high risk of failure, delay, or downtime.

Cost of change

Late changes have their own costs:

document revision;
purchase-order cancellation or change;
materials already purchased;
fabrication already started;
remobilization;
rework;
rescheduling;
schedule extension;
repeated testing;
training and documentation;
claims and disputes.

The net benefit should deduct these effects. Value Engineering cannot present the gross value of a substitution as savings without considering the cost of implementing it.

Examples in multidisciplinary systems

Structured cabling and fiber optics. A proposal to reduce the number of technical rooms may decrease CAPEX but increase distances, risk concentration, pathway occupancy, and maintenance difficulty. The study should compare function, growth, redundancy, space, cooling, power, and operations.

Video surveillance. Reducing resolution, retention, or redundancy may lower cost but compromise investigation and availability. Higher-value alternatives may involve segmentation by criticality, event-based recording, scalable storage, and review of camera locations.

Access control. The choice should not consider only the price of readers and controllers. It is necessary to evaluate integration with doors, frames, fire systems, elevators, identity, credentials, continuity, and emergency operation.

Electrical installations. A solution with a lower initial cost may increase losses, downtime, or expansion difficulty. The evaluation should consider selectivity, maintenance, efficiency, redundancy, space, safety, and shutdown impacts.

Data Centers. The highest-value alternative depends on availability and business requirements. Indiscriminate redundancy may generate investment without proportional benefit; insufficient redundancy may create unacceptable risk. The analysis should relate criticality, topology, concurrent maintainability, efficiency, and growth.

Retrofit in an operating environment. The final solution may be technically simple, but the transition may require temporary systems, maintenance windows, contingency, and rollback. The highest-value alternative is the one that considers the intermediate state and preserves continuity during implementation.

Governance, contracts, and control of results

Value Engineering needs governance to prevent technically weak recommendations from being approved solely because they show cost reduction. The owner should define responsibilities, approval authorities, decision criteria, and integration with design and contract processes.

The owner needs to govern the value decision. Engineering, cost, risk, procurement, contracts, operations, and commissioning should converge on a recommendation that benefits the asset, not merely one discipline or supplier.

Learn about Owner’s Engineering from inception through acceptance

Who should participate

Composition depends on the subject, but may include:

owner representative;
methodology facilitator;
engineering coordination;
discipline specialists;
operations and maintenance;
safety and compliance;
cost engineering and Project Controls;
procurement and contracts;
execution and constructability;
commissioning;
suppliers or independent specialists.

Independence proportionate to risk is useful for challenging assumptions without losing project knowledge. The original team should provide context and clarify decisions; the value team should have freedom to develop alternatives.

Relationship with Design Review and Design Coordination

Design Review, Design Coordination, and Value Engineering should be coordinated within the broader design-coordination framework, but each has its own purpose.

Design Review verifies engineering maturity, compliance, coherence, and completeness. Design Coordination addresses conflicts among disciplines, documents, models, and interfaces and may be performed in CAD, BIM, the Engios solution, or technical inventory and documentation structures integrated with NetBox. Value Engineering uses functions and resources to develop alternatives.

An incompatibility identified during review may generate a correction. A functional opportunity may generate a value study. If the approved alternative changes the solution, ECM will control the change.

Value proposals from suppliers and contractors

Contractors may identify more efficient solutions, but commercial proposals should not automatically be classified as Value Engineering. The recommendation needs to demonstrate:

preservation of functions and requirements;
benefit to the owner;
verifiable costs and savings;
schedule and risk impacts;
effects on warranties and performance;
intellectual property, licenses, and technology dependency;
sharing of savings, when applicable;
responsibilities for design, validation, and testing.

The change should not merely increase the supplier’s margin, reduce its risk, or relax a contractual requirement without a corresponding benefit to the owner.

Program indicators

A Value Engineering program may track:

studies planned and performed;
recommendations issued;
percentage approved;
percentage implemented;
estimated and realized savings;
lifecycle benefit;
schedule reduction;
risks eliminated or mitigated;
performance improvement;
cost of studies;
time between recommendation and decision;
reasons for rejection;
benefits replicated in other projects.

Savings should not be the only indicator. Improvements in safety, availability, schedule, reliability, operations, and sustainability also represent value.

Common mistakes

The most common mistakes include:

treating Value Engineering as across-the-board budget cutting;
performing the study after all decisions are contractually committed;
excluding operations and maintenance;
comparing alternatives with different requirements;
considering CAPEX only;
generating ideas without technically developing them;
ignoring the cost and risk of change;
using scoring to conceal a disqualifying requirement;
accepting supplier equivalency without validation;
failing to update documents and contracts;
counting estimated savings as realized benefit;
calling any cost review Value Engineering.

Checklist for approving a recommendation

Before the decision, verify:

[ ] the basic function is clearly defined;
[ ] mandatory requirements have been preserved;
[ ] the current solution and the alternative are described comparably;
[ ] CAPEX and OPEX have been considered;
[ ] risks and uncertainties have been assessed;
[ ] schedule impacts have been identified;
[ ] constructability, operations, and maintenance have been analyzed;
[ ] affected interfaces and documents have been mapped;
[ ] contractual effects have been verified;
[ ] implementation cost has been deducted from the benefit;
[ ] tests and acceptance criteria have been defined;
[ ] an owner and implementation plan exist;
[ ] the decision will be recorded and traceable.

Value Engineering produces better results when integrated with project governance. In the context of Owner’s Engineering, the owner can coordinate requirements, disciplines, costs, risks, contracts, and decisions, keeping the recommendation aligned with the asset’s objectives.

The U.S. Army Corps of Engineers reinforces that the methodology seeks to challenge requirements, assumptions, and constraints to optimize outcomes without sacrificing quality or functionality. This is the essence of its application in engineering projects: invest where function and performance justify the resources and eliminate complexity or costs that do not generate proportional benefit.

Technical references

[1] SAVE International. About the Value Methodology. Official definition of the Value Methodology, function analysis, and the relationship among function, performance, and resources.

[2] Federal Highway Administration. Value Engineering Job Plan. Official structure for preparation, information, function analysis, creativity, evaluation, development, and implementation.

[3] AACE International. Cost Engineering Terminology. Terminology for lifecycle cost, Total Cost of Ownership, and related practices.

[4] AACE International. Recommended Practice 39R-06 — Project Planning as Applied in Engineering and Construction for Capital Projects.

[5] Project Management Institute. PMBOK Guide — Eighth Edition. 2025.

[6] Project Management Institute. Construction Extension to the PMBOK Guide.

[7] ABNT NBR ISO 21502:2021 — Project management: guidance on project management.

Frequently asked questions

What is Value Engineering?

Value Engineering is a structured methodology that analyzes project functions and develops alternatives to improve the relationship among performance, quality, safety, risk, schedule, and resources employed.

Does Value Engineering mean reducing costs?

No. Cost reduction may be a consequence, but the methodology seeks to maximize value. An alternative that reduces price while impairing function, safety, reliability, or lifecycle does not represent Value Engineering.

What is the difference between Value Engineering and Earned Value Management?

Value Engineering develops alternatives to improve functions and resource use. Earned Value Management measures execution performance against scope, schedule, and cost baselines.

What is the difference between Value Engineering and Design Review?

Design Review verifies design coherence, completeness, and compliance. Value Engineering uses function analysis, creativity, and structured evaluation to develop higher-value alternatives. The processes are complementary.

When should a Value Engineering study be performed?

Preferably during feasibility, Conceptual Design, FEED, or Basic Design, when there is still freedom to change solutions. Studies may also occur later, provided the cost and risk of change are considered.

What is function analysis?

It is the identification of what each system, piece of equipment, or process needs to do. Functions are described independently of the current solution to enable comparison and generation of alternatives.

Does Value Engineering consider lifecycle cost?

Yes. Depending on the decision, the comparison should include engineering, acquisition, implementation, energy, operations, maintenance, downtime, expansion, replacement, and end-of-life costs.

Can a supplier proposal be considered Value Engineering?

It can, provided it demonstrates preservation of functions and requirements, verifiable benefit to the owner, technical and contractual impacts, risks, implementation cost, and validation criteria. An isolated commercial substitution is not sufficient.