FUNCTION LOGIC MODELS

Forward

This monograph is the first in a series concerning function models. The second concerns the language
and ground rules of FAST (Function Analysis System Technique), and the third, advanced applications.
These monographs are presented in this manner so that readers may select those areas of particular
concern based on past experience and expertise in value management methodology. Those new to VM
should start with the basic monographs, “Function, Definition” and “Analysis and Function
Relationships – An Overview” and then study the model monographs in sequence.

Function Hierarchy Models: Introduction

The SAVE-International approved value methodology (VM) workshop is the most common introduction
to the value methodology. Typically, they are 40 hours in duration, half theory, and half-practical
application. The “live” projects used should have been carefully selected for both potential application
and as educational vehicles. Due to the limited time available, they must be small in scope. Rarely do
the attendees have the opportunity to participate in the project selection. Too frequently, however, upon
completion of the basic workshop, the participants are expected by their management to select new
projects representing high rates of return on the VM “investment” and to conduct “full scale” VM
studies. The projects thought of by management are not small, easily understood ones but rather from
within major systems, products, or entire procedures. In fact, they are often complete products,
buildings or highways. SAVE International, through its Value World and international conference
proceedings, has published has published a wealth of material about project selection. The starting point
is usually assumed to be trying to select the “best” projects from many potential ones. As one very
successful company president said, “Find the dogs and make them profitable.” The function hierarchy
model can effectively assist in appropriate project selection and offers strong features for project control
as well as its more traditional role of developing full project understanding.

The Function Hierarchy Model

In the 1980s with the advent of easily understood and convenient computers, models of many shapes
and forms became prevalent as management tools. Within the field of value management, cost models
rose in prominence. This was particularly true in the application of VM within the construction industry
where such models came into such widespread use that standard elements were defined which allowed
costs to be assigned to specific elements as part of the initial project set-up.

The function hierarchy model was developed during the era when value management projects expanded
from relatively small assemblies to entire major products or systems and became more viable with the
explosion of computer technology. They have been proven to be extremely valuable when the value
practitioner and management are faced with non-standard problems; for example, when a whole new
system is being designed. In these projects, there are no standard elements. Thus the driving force is the
functions which will be required, not hardware or a specific subsystem such as air conditioning, lighting,
or structural frameworks for construction projects, or disc drives, PC Boards or power supplies for
computers. That is not to say that a function hierarchy model should not be used for projects with
known functions and associated hardware; however, the models best show their benefits when applied in

1
the design stage of new or at least “next generation” conceptual designs. Successful applications have
included the design of a next generation computer systems and the management and control of a total
manufacturing plant from initial design of both equipment and facilities through turnkey state.

Ground Rules

The construction of the model is a straightforward format. The top of the model is the basic function of
the entire project. The functions of any tier are those that must occur to achieve the next higher level
function of which they are a subset. Further, as parameters are assigned to each function, the total of the
function values (costs, weight, space, etc.) of any tier must add up to the values of the function of which
are a subset.

Function 1 F1 = F1.1 + F1.2 + F1.3

$1000

Function 1.1 Function 1.2 Function 1.3

$400 $250 $350

The second ground rule is that there must be at least two functions to each subset.

Function 1
Function 1

Function 1.1 Function 1.2 Function 1.1

Figure 1 illustrates a very simple model which was used as a training vehicle within a Module I value
management workshop. The assembly, a remote control station, is a safety device. The operator sets up
a numerically controlled multi-station turret lathe and then uses the control station with its sequenced

2
switches to turn on the lathe. The ten foot cord allows the operator to initiate the switch at a safe
distance as a precaution against injury due to imperfect setup.

Figure 1

Function: Transmit
1.0 Signals

Function: Initiate Function: Enhance Function: Transmit Function: Initiate

1.1 Signal (Start) 1.2 Grip 1.3 Signal 1.4 Signal (C/O)

Function: Initiate Function: House Function: Initiate Functional Protect

1.1.1 Signal 1.1.2 Components 1.4.1 Signal 1.4.2 Switch

3
4
The teams defined the highest order function (basic function of the entire project) as “transmit signal.”
The next level functions, (i.e.; what functions had to be accomplished in order to achieve the highest
order function) were determined and two of those were detailed down to a third level. A cross check
may be to ask why are the functions at any level necessary? The answer should be, “They are required
to accomplish the next higher level function.”

Typically the next step would be to assign cost targets and any other factors (weight, reliability,
maintainability, etc.) desired to be controlled by the project manager. Since this was a training project
with a satisfactory operating hardware in existence, the workshop team used the hardware to help define
the functions. They also decided that cost was only to control factor of concern—as long as the other
factors were maintained by the VM analysis—and assigned hardware to the functions by part numbers
from Figure 2. They then assigned the cost of those parts to the functions as shown in Figure 3. Notice,
however, that in some cases an individual part supported more than one function. For example the cost
of Part 20 had to be allocated to both “initiate signal” and “house components”. Since this example only
pertained to a small assembly within the total turret lathe, customer oriented functions, other than
“enhance grip,” were not considered. Once the training was completed and the full turret lathe was
studied, customer oriented functions were a major part of the analysis.

Figure 3

Function: Transmit
1.0 Signals
Hardware: W.A.C.S.
Cost $146.60

Function: Initiate Function: Enhance Function: Transmit Function: Initiate

1.1 Signal (Start) 1.2 Grip 1.3 Signal 1.4 Signal (C/O)
Parts 16-22 Part 3 Parts 1 Parts 4-15
Cost $33.20 Cost: $36.00 Cost: $47.73 Cost: $29.47

Function: Initiate Function: House Function: Initiate Function: Protect

1.1.1 Signal 1.1.2 Components 1.4.1 Signal 1.4.2 Switch
Parts 16, 20 Parts 17-22 Parts 12-15 Parts 4-11
Cost: $18.62 Cost: $14.57 Cost: $25.07 Cost: 4-11

Figure 4 illustrates a portion of a function hierarchy model used on a large aerospace design project.
Three levels of indenture are shown. The full project had as many as seven levels and involved over 200
functions. For ease it was computerized. This project followed the typical process whereby functions
were first defined and then hardware assigned to functions as designs were developed. The model also
illustrates the capability to assign other control factors such as cost targets (mfg), budgets (eng), weight
allowances, and the responsible designer.

5
 Figure 4
Control Engine
1.0
Function: Control Engine
Hardware: Descent Asm.
Eng. Cost: $52,000
Mfg. Cost: $14,000
Weight: 10 lbs.
Designer: JWC

1.1 1.2 1.3 1.4

Function: Control Yaw
Hardware: Control Asm.
Eng. Cost: $23,000
Mfg. Cost: $6,000
Weight: 3.5
Designer: JWC
Function: Control Pitch Function: Control Throttle Function: House Components
Hardware: Control Asm. Hardware: Input/Output Hardware: Housing
Eng. Cost: $13,4000 Eng. Cost: $24,500 Eng. Cost: $1,100
Mfg Cost: $4,500 Mfg. Cost: $3,000 Mfg. Cost: $500
Weight: 2.8 Weight: 2.6 Weight: 1.1
Designer: ARC Designer: EAB Designer: WDT

1.2.1 1.2.2 1.2.3 1.2.4

Function: Receive Signal
Hardware: Signal Box
Eng. Cost: $1,600
Mfg. Cost: $300
Weight: .28
Function: Prevent Noise Function: Activate Switch Function: Active Bridge
Hardware: +/- Pitch Hardware: Saturating Cir. Hardware: Saturating Cir.
Eng. Cost: $2,600 Eng. Cost: $3,000 Eng. Cost: $ see 1.2.3
Mfg. Cost: $475 Mfg. Cost: $1,250 Mfg. Cost: $ see 1.2.3
Weight: .32 Weight: .60 Weight: .70

1.2.5 1.2.6 1.2.7 1.2.8

Function: Prevent Start
Hardware: Field Power
Eng. Cost: $1,600
Mfg. Cost: $825
Weight: .20
Function: Output Signal Function: Indicate Signal Function: House Components
Hardware: Bridge Circuit Hardware: Verify Circuit Hardware: Chasis
Eng. Cost: $1,100 Eng. Cost: $2,000 Eng. Cost: $1,500
Mfg. Cost: $1,200 Mfg. Cost: $250 Mfg. Cost: $100
Weight: .40 Weight: .20 Weight: .10

Figure 5 illustrates a function hierarchy model of a commercial grill used in small restaurants. (This is the same model as shown in
the monograph Function Relationships – An Overview). Since sales are highly dependent on customer reaction and perceived value at
trade shows, the “Enhance Appearance” function and its chain were extremely important and the focus of a specific VM study.

6
 Figure 5

Electric Grill

Heat
Surface

Attract
User Contain Contain Level Heat Package Test
Assembly Grease Assemply Surface Product Product

Hold Identify Enhance

Grease Elements Appearance
Hold Guide
Grease Flow

Identify Caution
Producer User Contain Ease
Grease Removal

Transfer
Heat
Conduct Generate Protect Indicate Control
Elect. Heat Circuts Status Temp.

Transfer Contain
Heat Mat’ls

Advantages of The Function Hierarchy Model

As A Control Device:

The function hierarchy model allows the project manager and other management personnel (and even
the customer if desired by management) to analyze a system’s function requirements to assure all
functions are being accomplished and no functions are redundant. For example, on the project
illustrated in Figure 4, it was discovered that, under the original hardware breakdown process, two
engineers each assumed a major function (create power) would be incorporated on the other’s
equipment. Therefore, the cost of that function, some $38,000, hadn’t been included in the original
estimate. If the function hierarchy model hadn’t been developed, that cost would not have been included
in the final contract price.

On another major system, a function hierarchy model depicted a system of a master computer
performing major computation. Five peripheral computers did initial computing or receiving data and
then partially computed information for correlation and final processing by the master computer.

7
Analysis of the function hierarchy model suggested that the peripheral computers could be eliminated
and the master computer enlarged so that the received information could be processed directly to the
master computer, stored and then calculated. That meant a savings of $400,000.

A function hierarchy model on an electronic system showed that two connecting cabinets both required
a transformer; however, neither of them utilized the standard transformers specified to full capacity and
special transformers would be too expensive. The analysis of the model suggested that one transformer
had the necessary total capacity and the second cabinet could be cabled to it. The result was a savings of
$3,800. While this redundant function situation was basically a communication problem, it did and
often does exist that designers on different sub-systems do not communicate, even though they may be
working physically close to each other.

To Manage All Performance Factors

Critical performance factors can be allocated to each function. In Figure 4, weight allowances were
assigned to each function since that was of great concern to the customer. The project manager had the
authority to make trade-offs within each level of functions, but not to exceed the total. For example, the
total weight allowance of the four second level functions equaled 10 pounds, the limit of the top level
function. If during the development cycle, the “control throttle” function could not be designed within
its 2.6 pound target, then weight could be reduced from among the other functions at the same level, but
the total could not exceed 10 pounds. In other words, management can make trade-offs along the
horizontal or same level functions, but the total cannot exceed the next higher level function value. Of
course, some factors are neither additive nor allocable across different functions. Failure rates or quality
standards typically would not be allocable. But importantly, there is management control by functions
the system or product must achieve. Figure 4 only includes weight as a performance parameter. In the
actual project, four other factors were managed: power consumption, reliability, maintainability, and
time.

To Control Costs

Costs are planned and controlled in the same manner as performance factors. However, cost can and
often are broken into controllable elements. In Figure 4, the team decided to monitor both engineering
development costs and predicted manufacturing costs.

Designer’s Relationship

The visibility and control of one designer’s functional responsibilities to another’s was discussed in the
transformer example. Many organizations include the responsible design engineer or manager at that
stage in each function block. The model will show the effect on the function in someone else’s area if a
designer alters his approach.

Easily Understood

There are many management and control devices available. Too often, however, they designed by
specialists who fully understand them, but management cannot. There are a multitude of PERT/CPM
charts existing which management takes one look at, becomes confused and then requests a simple bar
chart that can be readily understood. Since the function hierarchy model is in the same format as a top

8
down breakdown, work breakdown structure, or hardware tree, it is easy to follow and use. That is the
key to the effectiveness of any tool—is it really used.

User/Task Logic Models: Introduction

In the 1980’s there was recognition by the value management professionals that it is the customer that
really determines the value of products and services. Therefore there was a movement to include the
customer/user in the development of value study projects.1,2 Under the leadership of Thomas Snodgrass,
CVS, FSAVE and Theodore Fowler, CVS-Life, FSAVE the user/task function logic model was
developed3 This was during the time of the ascendancy of FAST diagrams, thus the user/task logic
diagram was created as a horizontal function model rather than vertical. Figure 6 depicts the standard
model format.

Figure 6
HOW? WHY?
Basic Functions

Secondary Basic

Primary Basic

Secondary Basic
Primary Basic
Scope
Line

Primary Basic

Task
Supporting Functions

Assure Convenience

Assure Dependability

Satisfy User

Attract User

Definitions of the Task/User Function Diagram

In creating this model, the developers agreed upon the following definitions of the model’s elements:

9
Task: That which is required by the user/customer

Basic Functions: Those which are essential to the performance of the task.

Primary Basic Functions: Those basic functions directly to the right of the scope line

Secondary Basic Functions: Those which branch off from the primary basic functions.

Supporting Functions: Those functions concerned with building customer acceptance and in selling
the product or service.

Primary Supporting Functions: Those supporting functions directly to the right of the scope line.
There are always four: assure convenience, assure dependability, satisfy user and attract user

Scope Line: The line directly to the right of the task that connects all primary functions to the task. All
VM study work will be performed at levels to the right of the scope line.

SAVE International Module II seminars require discussion comparing different function models, both of
the hierarchy and intuitive logic of FAST. For four years models of the grill in Figure 5 (hierarchy) and
Figure 7 (task/user) were used. The latter was prepared by Mr. Howard Ellegant, AIA, CVS-Life of
URS Corporation. Figure 7 is a copy of that diagram.

The original development of this style model occurred during a period of high interest and use of FAST
diagrams. Thus the developers originally titled their models “Task/Customer FAST”. Unfortunately,
that decision caused confusion and delays by many practitioners in accepting and using these models.
That is because the models are not FAST. FAST is based on intuitive relationships of functions and
requires specific formats and language. These models, which are a derivative of the hierarchy function
model, are based on hierarchy of function logic and have their own format and language. Thus this
monograph uses the term, user/task function logic model.

10
 Figure 7
Griddle Add Power

Generate
Conduct Power
Heat

Heat Surface Convert Power

B
A Transfer Heat

S
I Contain Grease
C
F
Remove Grease Guide Flow
U
N
C Collect Grease
T
I Contain
O Assembly
N Protect Circuit
S Protect User Caution User

Insure Collection

Assure Dependability Ventilate Product

Cook Food Protect Product Protect Shipments

S Inhibit Corrosion

U Prevent Deterioration Insure Strength

P Test Product
P
O
R Control Temperature

T Locate Control
I Assure Convenience Allow Leveling
N
Indicate Status Ease Removal
G
Insulate Product
Improve Efficiency Equalize Heating
F
U Ease Cleaning
Satisfy User Promote Sanitation Contain Splashing
N
Hide Grease
C Communicate Sanitation Prolong Finish
T
I Allow Banking
O Style Product
Enhance Apperance Color Product
N
Attract User Finish Details
S
Identify Product

Function Logic models and F.A.S.T.

11
For those exploring the value management field, the question of the relationship between function logic
models (Hierarchy and Task/User) and the Function Analysis Systems Technique (FAST) diagrams
often arises. Are they for the same purpose? Does one replace the other?4 The function logic models
only use major functions and do not enter into detailed analysis, use of secondary functions, and so on.
When a problem arises at any level of the model, it may be appropriate to develop a FAST diagram for
that level function. For example, in Figure 4 it became apparent that function 1.1.2 “Prevent Noise” was
going to be a very difficult problem within the budgeted cost and weight allowance. A FAST diagram
was created with “Prevent Noise” as the basic function directly to the right of the scope line with
“Control Pitch” as the higher order function. Thus the function hierarchy model served its purpose to
help decide where it was most effective to conduct a value methodology study to remain within the
objectives of the overall design project.

During the conduct of 10 different Module II seminars attendees were divided into four teams and each
team was assigned the same problem, but were to develop one of the four models. Then each team
presented their model and cross comparisons were made. The conclusions were that all the models—
presented function hierarchy, task/user logic, technical FAST and classical FAST—were valid and
primarily it became either a project driven choice or the “comfort zone” of the practitioner. It was
agreed that under the current designs, the task/user logic model was the most customer oriented. Many
attendees also commented that the function logic models seemed to work best on physical (hardware,
structures, etc) projects and the FAST diagrams on “soft” projects such as procedures, systems, and
organization analysis.

Summary

A function logic model is a powerful management tool which clearly depicts the functions required in a
product and relates hardware, cost, performance characteristics, and customer concerns to those
functions. As one corporate vice president comments, “This is the best tool I’ve seen yet to assure
management that all requirements are being performed and the functions are being controlled—and I can
understand and use it!”
1
Cook, Thomas F, (1996) “Determining Value Mismatch By Measuring User/Customer Attitudes”
SAVE International Proceedings
2
Bryant, John W., (1986) “Customer Oriented Value Engineering (COVE)”; Value World
3
Snodgrass, Thomas J. and Kasi Muthiah, (1986) “Function Analysis, The Stepping Stones To Good
Value”; University of Wisconsin, Madison, Wisconsin, Chapters 8-11

12