Design to Cost · Value
FAST Diagram
Order functions logically: how, why, when — to expose functions that exist only by tradition.
- Time1 h
- FormatTeam
- StageValue
FAST Diagram: what it is and why it works
A FAST diagram (Function Analysis System Technique) arranges a product's functions in a logical chain instead of a flat list. Along the main axis, each step answers how a function is accomplished in one direction and why it is needed in the other. Functions that happen at the same time as, or are triggered by, a function on the main path are placed above or below it and answer the question when. By testing every link with how, why and when, the team sees which functions truly serve the purpose of the product and which exist only by habit or tradition.
A plain function list shows what a product does; a FAST diagram shows how the functions depend on each other. That makes it much easier to spot duplicated functions, functions working at cross purposes, and functions that do not serve any higher-level need. It also makes the logic of a design explicit, so a team can challenge it without arguing about parts. Charles W. Bytheway introduced the technique in 1965 within the value engineering community, and it remains a core tool in value engineering studies. It builds on the verb-noun functions from functional analysis, supplies the candidates for the useless function hunt, and gives a value engineering workshop a clear map of where to focus creativity.
What you need
- A function list in verb-noun form from functional analysis
- A clear definition of the scope: which system or subsystem is being studied
- The product's cost breakdown, to attach costs to functions later
- A cross-functional team that understands how the product is designed, built and used
- A large wall, whiteboard or digital canvas and sticky notes or cards
What you get
- A FAST diagram showing the how-why logic of the main functions and the when relationships
- Identified duplicated, conflicting or orphan functions
- A list of functions to challenge on need and willingness to pay
- A shared understanding of the design logic across disciplines
When to use it
When a feature survives because it always has, not because it must.
How to do it, step by step
- Place the higher-order function (the customer’s need) on the left, then the basic function just to its right, behind the scope line.
- Build the critical path to the right by asking “how?”, and read it back to the left by asking “why?”.
- Place functions that happen at the same time above or below the path, using the “when?” question.
- Mark functions that duplicate each other or work at cross purposes.
- Challenge every function with: does the user need it, and would they pay for it alone?
Worked example: Case labeling station on a packaging line
Illustrative scenario — figures are realistic but not from a real company.
A household chemicals producer planned four new bottling lines. Each included a case labeling station quoted at about $86,000. The project team suspected the station specification had grown over the years and built a FAST diagram before ordering.
- The team placed identify case as the basic function and enable shipment traceability as the higher-level function it serves.
- Asking how to identify a case, they added print label, apply label and verify label, then reject unreadable case. Asking why for each one confirmed the chain back to traceability.
- The when questions revealed two functions hanging off the diagram: orient case, performed by a case turner so labels always faced one side, and verify label again, performed by a second scanner at the palletizer.
- Orient case traced back to a labeling requirement from one retailer that had been withdrawn three years earlier; the second scan duplicated the first verification.
- The team challenged both: would the customer notice, and would anyone pay for them separately? Neither passed. Quality confirmed that the first verification and reject function fully covered traceability.
Result. The case turner and palletizer scanner were removed from the specification, saving about $23,000 per line, or roughly $92,000 across the four lines, plus the maintenance and changeover effort they would have required. The team noted that nobody had defended the two functions once the diagram made their logic visible.
Common pitfalls and how to avoid them
- Drawing a FAST diagram of parts instead of functions.Use verb-noun functions only and move part names to a separate column if needed.
- Mixing directions, so how and why do not read consistently.Agree on the orientation at the start and test every link in both directions.
- Setting the scope too broad, so the diagram becomes unreadable.Limit the study to one system or subsystem and mark the scope boundaries on the diagram.
- Removing functions that meet safety or regulatory requirements because they seem to serve no customer need.Mark such functions as required and include the requirement they serve on the diagram.
Frequently asked questions
What does FAST stand for in value engineering?
FAST stands for Function Analysis System Technique. It is a method for arranging the functions of a product, process or project in a diagram based on how, why and when logic. It was introduced by Charles W. Bytheway in 1965 and is widely used in value engineering to understand design logic and identify unnecessary functions.
How do you read a FAST diagram?
Follow the main path and ask how in one direction: each function to that side explains how the previous one is accomplished. Read in the opposite direction and ask why: each function explains why the next one is needed. Functions above or below the path answer when, meaning they occur at the same time or are triggered by it.
What is the difference between technical FAST and customer FAST?
Technical FAST diagrams focus on how a product or system works, following the logic of its technical functions. Customer-oriented FAST diagrams, sometimes called task FAST, focus on functions from the user's perspective, such as what the user needs to achieve. Technical FAST is common in engineering studies; customer FAST helps when user needs are the main question.
Origin
FAST diagramming (Function Analysis System Technique) — Charles W. Bytheway, 1965, Society of American Value Engineers.
Related methods
- Functional AnalysisExpress the product as functions — verb plus object — free of solutions: what must it do, not how.
- Useless Function HuntChallenge every function: who needs it, what breaks without it, what does it cost? Kill the orphans.
- Value Engineering WorkshopCross-functional session: state the function, brainstorm alternative ways to deliver it, cost the best…
More in “Value”
Find what the customer actually values — and what they never asked for.