Amin Terouhid, Ph.D., CVS

Maryam Mirhadi, Ph.D., MVA

Executive takeaway. A Value Engineering Change Proposal (VECP) should allow an owner to confirm that the alternative preserves functions and performance, produces supportable savings, and can be implemented. The proposal should combine technical evidence, contract revisions, cost and schedule analysis, risks, and life-cycle effects.

Understand what qualifies as a VECP

A Value Engineering Change Proposal, or VECP, is a contractor-initiated proposal submitted after contract award under a value engineering provision. It requires a change to the contract and seeks better value without impairing essential functions or characteristics. The Federal Highway Administration explains that a VECP may improve performance, value, or quality; reduce construction cost; or shorten delivery time while considering life-cycle cost and other applicable factors. [1]

A function characterizes what the project must accomplish. Performance defines how well that function must be delivered through measurable requirements. Resources include cost, time, labor, equipment, materials, and energy. Life-cycle value considers performance and resource use during construction, operation, maintenance, and replacement. These characteristics distinguish a VECP from a routine product substitution, correction of a contractor error, change in quantity alone, construction claim, or request for payment for work already required by the contract. The contract governs whether a proposal qualifies, what the contractor must submit, how long the owner has to review it, how proposal data may be used, how savings are shared, and how payment is made. For example, Federal Acquisition Regulation clause 52.248-3 establishes minimum content and a savings-sharing method for federal construction contracts that contain the clause. State, local, and private contracts may differ. Both parties should therefore review the applicable provision before developing the VECP. [2]

Build a decision-ready proposal

The proposal should begin with a concise comparison of the existing requirement and proposed change. It should identify the drawings, specifications, contract sections, permits, and approvals requiring revision, then explain the reasons, advantages, and disadvantages. The owner should be able to see what would change and what would remain unchanged.

The contractor should then demonstrate functional equivalence, meaning that the alternative provides the same required functions or some level of enhancement to the functions at the required level of performance. A function matrix is a compact table that compares those functions and performance criteria for the existing and proposed solutions. Appropriate support may include design calculations, product data, test results, code analysis, prior-use information, quality-control requirements, and required professional approvals. SAVE International’s Value Methodology supports evaluating required functions rather than favoring a particular solution. [4]

The proposal should next explain how the change will be implemented. It should address design responsibility, submittals, permits, procurement, temporary work, installation, inspection, testing, warranties, operations, maintenance, and training. If commissioning is required, the documented testing and verification that systems are ready for service, it should also be included. The contractor should state when written authorization is needed and show the effect on the current project schedule. Until authorization is issued, the existing contract requirements remain in effect. [2]

Present cost and schedule effects transparently

The cost analysis should present separate estimates for the affected existing work and the proposed work using consistent quantities, pricing dates, labor and equipment rates, markups, and assumptions. It should identify contractor development and implementation costs, subcontractor effects, owner review or testing costs, and changes to operating and maintenance costs. The difference between two supplier quotations is not the total saving when the change transfers or adds other costs. The schedule analysis should identify the activities and logic relationships added, removed, or revised by the proposal to determine if any adjustments need to be made to the schedule, and if it is justified.

Use a disciplined owner review

The owner should first screen the proposal for compliance with the contract and for completeness. Technical reviewers should then verify function, performance, code compliance, constructability, the practical ability to build the alternative—safety, quality, schedule, and operational effects. Estimators should reconcile quantities, rates, exclusions, development costs, owner costs, and life-cycle consequences. Questions, assumptions, revisions, and the final decision should be recorded in a controlled decision log.

Owners typically appoint one review lead and establish a response schedule; involve design, construction, estimating, scheduling, operations, maintenance, procurement, legal, and funding representatives as needed; separate documented savings from uncertain benefits; and identify or assess risks. An accepted VECP should be implemented only through the written contract modification required by the contract. A complete proposal makes value visible, testable, and auditable for both parties.

References

[1] Federal Highway Administration. Value Engineering Change Proposals.

[2] Federal Acquisition Regulation 52.248-3. Value Engineering-Construction, October 2025.

[3] Electronic Code of Federal Regulations. 23 CFR Part 627, Value Engineering.

[4] SAVE International. About the Value Methodology.

Amin Terouhid, Ph.D., CVS

Maryam Mirhadi, Ph.D., VMA

Executive takeaway. A Function Analysis System Technique (FAST) diagram is a function-logic model used in value engineering (VE). It shows why project functions are needed and how they are achieved. By testing those relationships within a defined study scope, FAST separates needs from proposed solutions and opens the discussion to alternatives.

Start with functions, not components

SAVE International’s Function Analysis Guide presents FAST diagramming technique and relationship validation as tools for organizing functions, while Value Analysis Canada describes FAST as a way to identify missing, duplicated, or unnecessary functions. [1] [2] A function states what a project or system must do. In standard VE practice, the team describes it with an active verb and a measurable noun. The verb states the required action; the noun identifies what receives the action and what the team can evaluate.

This language keeps the analysis focused on need. For example, “install roof drain” is an activity and “roof drain” is a component; both point toward a particular solution. By contrast, “collect water” states the required result without prescribing equipment. Examples of properly worded functions include “control runoff,” “transfer loads,” and “convey passengers.” Measurable means the team can establish performance criteria—requirements used to judge how well the function is performed. [3]

Test the How/Why logic

FAST arranges functions according to function logic: the reasoned relationship between required actions, not the sequence of construction. Moving left to right, the team asks, “How is this function achieved?” The answer is a lower-order function, a more specific action. Moving right to left, it asks, “Why is this function needed?” The answer is a higher-order function, a broader purpose. Reading both ways helps expose unsupported assumptions and missing functions. [2]

The main horizontal chain is commonly called the FAST critical path. Here, the term means the principal How/Why path through the function model. It is not the critical path in a Critical Path Method (CPM) schedule, which identifies the sequence of activities controlling project duration. FAST contains no activity durations, dates, or schedule float. The team identifies the functions by asking, “When this function occurs, what else must occur?” In FAST, When expresses a supporting relationship, not clock time.

Use scope lines to focus the study

Scope lines are vertical boundaries defining the part of the function model the VE team will examine. A higher-order function may remain outside the left boundary because it explains the project purpose but is not open to change. A lower-order function may remain outside the right boundary because the logic continues beyond the selected subject. Within the scope, the basic function is the studied system’s principal purpose. Classification depends on scope; a function may be basic in one study and secondary in another.

Hypothetical example: a building roof-drainage system

Assumptions: The study concerns a conventional building roof within a defined property boundary. The illustration is a simplified function model, not a final design.

Figure 1. Simplified FAST model for roof drainage

Arrows label the questions; the connecting lines represent logical relationships, not workflow or elapsed time

Reading left to right, the owner protects property by controlling runoff; runoff is controlled by removing water, conveying it, and maintaining the gradient that enables movement. Reading right to left tests why each function exists. The supporting functions, collect water, exclude debris, and permit maintenance, may be essential even though they are not on the main path.

Because the model avoids naming roof drains, downspouts, pipes, scuppers, or detention tanks, the team can compare different ways to perform the functions. Performance criteria may include flow capacity, reliability, maintainability, code compliance, site constraints, and water-quality objectives. Resources include money, materials, labor, energy, and time. Comparing performance with the resources required over design, construction, operation, maintenance, renewal, and disposal connects the discussion to life-cycle value—the value delivered over the system’s useful life—rather than initial cost alone.

Common mistakes that reduce the diagram’s value

Teams sometimes replace functions with components (“roof drain”), specifications (“six-inch pipe”), or activities (“install piping”). Others arrange the boxes in installation order, turning FAST into a process flowchart or CPM schedule. Additional mistakes include leaving scope lines undefined, treating When as elapsed time, accepting logic that works in only one direction, combining competing solutions in one function model, and adding so much detail that the central relationships disappear. A useful FAST model remains implementation-free: it defines required actions without committing the team to a particular component or design solution. [4]

The facilitator’s role and the owner’s next steps

A FAST facilitator is the neutral process leader who guides the analysis without selecting the design. The facilitator draws out functions from knowledgeable participants, challenges solution-oriented wording, tests How/Why logic in both directions, and records disagreements and assumptions. The diagram is a shared model that the technical team validates against project requirements and available evidence, not an answer imposed by the facilitator.

As a professional recommendation, owners should define the study scope and performance criteria before diagramming; involve people who understand design, construction, operations, and maintenance; test every principal-path relationship in both directions; record unresolved assumptions; and use the agreed functions to organize the creative, evaluation, development, and recommendation phases of the VE study. FHWA’s VE Job Plan likewise places function analysis before creative and evaluation work. That sequence reinforces the central point: FAST is successful when it improves the alternatives and decisions that follow. [3]

References

[1] SAVE International. Function Analysis Guide.

[2] Value Analysis Canada. Function Analysis System Technique (FAST).

[3] Federal Highway Administration. The Value Engineering Process and Job Plan.

[4] Borza, J. S. FAST Diagrams: The Foundation for Creating Effective Function Models (2011).

Amin Terouhid, Ph.D., CVS

Maryam Mirhadi, Ph.D., VMA

Executive takeaway. Function analysis identifies what a project, process, organization, or system must accomplish before the value engineering (VE) team decides how to deliver it. By separating the required purpose from the proposed solution, owners can explore more alternatives while protecting the functions. The resulting discussion supports better decisions about both initial expenditure and long-term ownership of the subject project, process, organization, or system.

Begin with the purpose behind the proposed solution

Value Engineering (VE) is a structured, systematic methodology designed to optimize project outcomes relative to consumed resources. According to SAVE International [1], the process relies on a multidisciplinary team—guided by a certified facilitator—that rigorously analyzes required system functions before generating and evaluating potential alternatives. Function analysis provides the foundational framework and common language that makes this process effective. To apply this methodology effectively, key terminology must be clearly delineated:

• Component: The physical entity or mechanism that performs a function (e.g., a steel beam).
• Function: The essential action or purpose a system or component performs (e.g., transfer loads).
• Specification: The prescriptive parameters governing materials, construction, or performance (e.g., load capacity).

Defining a requirement purely by its function—such as “transfer loads”—allows project teams to evaluate alternative materials and configurations without prematurely committing to a single design path.

Use two words to make the need clear

Function analysis commonly pairs an active verb, which expresses an action, with a measurable noun, which identifies what the action affects. This concise format focuses discussion on one function at a time and helps move attention away from a predetermined solution. [2] Examples of these pairs include:

• Transfer loads
• Control temperature
• Convey passengers

These two-word expressions define what the system must do. However, they do not replace detailed engineering performance criteria. Instead, they serve as a neutral baseline. For instance, while “convey passengers” establishes the core functional need, the project team must still define specific performance parameters—such as peak demand, vertical rise, maximum wait time, accessibility standards, and system reliability.

Classify functions within a defined study scope

Determining functions requires establishing a clear study boundary (scope). Within this boundary, functions are categorized into two primary types, although other types of functions also exist:

• Basic Functions: The fundamental, primary reasons for the system’s existence.
• Secondary Functions: Auxiliary tasks that support the basic function or satisfy secondary requirements

SAVE International emphasizes that while basic functions must be preserved, secondary functions often represent significant cost-reduction or optimization opportunities. Importantly, functional classification depends on the defined analytical boundary. For example, “control temperature” represents a basic function when evaluating an HVAC system, but a secondary function when evaluating a complete airport terminal facility. Categorizing a function as secondary does not imply it is optional; many secondary functions remain mandatory for reasons such as operational integrity.

Open alternatives, then test them against the requirements

Reframing the right questions to ask expands the solution space. For example, asking “Which elevator model minimizes equipment cost?” focuses narrowly on procurement, finishes, and vendor pricing. In contrast, asking “How else can we convey passengers between these levels?” encourages the team to evaluate spatial layouts, service relocations, operational adjustments, or existing equipment upgrades alongside new equipment installations.

Proposed alternatives must undergo rigorous technical validation against baseline design criteria. For instance, substituting stairs for an elevator is invalid if regulatory accessibility standards require vertical motorized transit. Similarly, relocating services to reduce foot traffic may create unforeseen operational bottlenecks. As outlined by the Federal Highway Administration (FHWA), the VE process sequentially transitions from function analysis to creative alternative generation, followed by rigorous technical and financial evaluation [3].

This evaluation phase must account for life-cycle performance, balancing initial capital costs against long-term operational expenditures (energy consumption, routine maintenance, and replacement schedules). A low-cost capital option that incurs high maintenance or energy costs over time rarely delivers optimal long-term value.

Practical exercise: rewrite the question

To apply function analysis, consider the baseline proposals in the table below. Identifying the underlying function and establishing clear evaluation criteria allows teams to objectively assess alternative options.

(Note: The examples provided above are illustrative; exact functions and performance parameters must be calibrated to the specific project scope.)

Implementation Recommendations for Project Teams

To successfully integrate function analysis into upcoming project planning, the following course of actions is recommended:

• Select a Critical System or component: Document its core functions, quantitative performance criteria, baseline design solution, and projected life-cycle costs.
• Align Stakeholders: Engage owners, designers, contractors, and facility operators to confirm non-negotiable performance baselines prior to generating solutions.
• Facilitate Consensus: Conduct structured workshops to resolve scope ambiguities and standardize functional definitions.
• Document Decisions: Formally log the technical and financial rationale for accepting or rejecting each alternative.

Adopting this structured methodology transforms function analysis from a theoretical exercise into a repeatable, value-adding decision process.

References

[1] SAVE International. About Value Engineering.

[2] Value Analysis Canada. Function Analysis Phase.

[3] FHWA. The Value Engineering Process and Job Plan.