Functional Analysis

INTRODUCTION

The concept of functional analysis was first developed by Lawrence D. Miles to address difficulties in satisfying the requirement to meet shortages of manufactured parts and electrical components which were in high demand during World War II. His concept of functional analysis was further developed in the 1960s by Charles W. Bytheway, a design Engineer. Bytheway introduced the methodology called Function Analysis Systems Technique (FAST) whilst extending Miles’s functional analysis concepts.
In designing, developing and proving any project, the mission and consequent functions that the project shall perform shall be clearly established. This functionality shall be distributed throughout the different design levels (e.g. systems, subsystems, units). The allocation of the unit functions in a systematic manner is an important step in establishing a design which meets all the project objectives (Woodhead & Downs, 2001).
Based on the above, one can draw several parallels between functional analysis and project management, and better still, the latter can almost always acts as a platform on which the former is applied. First of all, both are requirement-oriented and function-based processes. Both focus on the functions required by a design, process, or service to accomplish its objective or mission. Furthermore, both strive to develop alternatives designed to achieve only the required function at the lowest cost while meeting the fundamental requirements of the customer (Hallows, 1998). It is on account of these parallels that functional analysis and FAST methodology can play an important role in project management.

TERMINOLOGY

Tree model: A model used to arrange functions in a hierarchical tree structure. The top functions are developed first and decomposed to lower level functions.

THE CONCEPT FUNCTIONAL ANALYSIS AND FAST METHODOLOGY

Functional analysis is the technique of identifying and describing all the functions of a system. The purpose of the analysis is to identify and partition all the functions of the system required to perform the intended mission. In the classical method of functional analysis developed by Larry Miles, words were used specifically to emphasise the function of a unit. For example emphasis was placed on what a unit actually does and not the result of what it does. Later in the functional analysis phase, values are assigned to these functions. These values can be dollars, weight, or any other pertinent value. These values are used to evaluate the functions in terms of their importance, or value to the overall system.
The FAST modelling process starts with the facilitator asking several probing questions designed to identify the scope of the model, its objective function, and the basic function or functions. Three main questions that are asked are;

These questions are designed to identify the mission of the system while bounding the scope of the problem or opportunity. By stating the mission of the project as a problem or opportunity the team is able to precisely specify what the project is to accomplish (Male & Kelly, 1993).
The case study used throughout this brief to give examples / applications of various functional analyses and FAST is one of a trucking company whose management was facing difficult times and decisions. The problem company X was facing was ‘dead heading’ (Dead heading occurs when a truck goes from point to point without a load of cargo). Company X embarked on a project with the aim to minimise dead heading by the use of an information sharing system that provides an on time communication solution. Communication had been identified as the main problem.
In line with the FAST modelling, the scope of the company X’s communication solution model can be identified by answering the three probing questions.

What are the Problems or Opportunities

It is easy to describe the main problem as deadheading. The problem description prompts other sub-questions i.e. why has the problem occurred? This type of question, not only identifies the problems they also help to identify opportunities. The solution to the problem of deadheading creates an opportunity for more deliveries and therefore more profit. We therefore, at this stage, are trying to identify the goal of the model we intend to develop. The goal gives purpose and direction of the project. It defines the final deliverable or the outcome of the project so that everyone understands what is to be accomplished in clear terms. This will be used as a continual point of reference for any questions that arise regarding the problem or opportunity.

Why is this a problem or opportunity?

Why is deadheading a problem? The logical answer would be, “unnecessary cost”. It gives us an idea of the value of the problem or opportunity as the case may be. This question clearly helps the design team to stay within the scope of the project. It is helps to focus on the unnecessary cost caused as a direct fallout of the underlying problem or opportunity. The cost of eliminating deadheading can therefore be directly compared to the value of sales / profit made by having more deliveries.

Why is a solution necessary?

Following the above sequence, this question is designed to help the team obtain measurable business values that will result from doing the project. Whatever criteria were used, they must answer the question, “what needs to be achieved for us and the customer to say the project was a success?”
To start a FAST model, one common method used to identify and decompose functions is to randomly “brainstorm” functions by starting with the objective or mission of the model and discussing how it might be accomplished. Once a function is identified, the process is repeated until all possible ways are exhausted. Furthermore, some of the identified functions become topics for the brainstorming and the process is repeated.
There are several variations to the FAST model. I have used the “Technical FAST” model as an example. It is most useful in product development. This is one variation of the FAST model, primarily used for construction projects, which keeps the critical path very simple, and at a high level of abstraction by removing functions that occur “all the time” from the critical path and positioning them in the top right-hand corner of the model. This is a less rigorous approach however; it is valid as long as it meets the HOW/WHY logic of the model.
One way to organize this is to put the answers to “How the objective is established”. Then the column to the left side is labelled “WHY” and the column to the right labelled “HOW”. Then, for every function that is put in the middle column, the answers to “HOW” and “WHY” this function is accomplished is put in their respective columns. After this brainstorming process is carried out to the extent possible, it is necessary to write all the functions on small notes. Then, scope lines can be drawn on flipchart sheets, comprehensible to each member of the team so everyone can contribute actively to developing the model.
The method used to achieve the basic function is described by all functions to the right of the basic function. These are called “dependent functions.” Any function on the HOW or WHY logic path is a critical path function. The major critical path is formed, when the functions along the WHY direction enter the basic function. It is possible to have a minor critical path if they depict how an independent or supporting function is accomplished.
Several functions have already been identified. The objective of higher order is to “generate more revenue”, the basic function being to “make more profit”. Next we ask,” How do you make more profit?” A logical answer to that is “making more deliveries” These functions are placed on the FAST model from left to right. Next, the functions are tested in the WHY direction to identify any missing functions because it won’t sound right if there’s one missing. Therefore, why do you “make more deliveries?” The answer: To make more profit. And why do you “make more profit?” “To generate revenue”; the process is continued until all the functions identified during the brainstorming exercise are exhausted. The idea is to complete the critical path first. Once the critical path has been extended to the point it is out of the scope of the system, the remaining functions are positioned in the “WHEN” direction to describe the supporting functions, independent functions, specifications and activities that fully describe the system.
Looking at some of the activities, or supporting functions, notice the activities, or supporting functions in the “when” direction under “make profit”. These are called supporting functions because they support a function on the critical path. These are functions that happen at the same time, or are caused by the critical path function “make profit”. Generally, these functions also support a market concept, or customer requirements. The objective or specifications can then be added to the diagram. These functions are specified by the customer, regulations, or other sources. One way of depicting this function is by positioning them in the upper right corner of the diagram.
Once the whole system has been described using the fast model, opportunities can be identified for improvement in the model. In value engineering methodology cost would be allocated to the functions in order to identify the high cost functions. Also any unwanted or unnecessary functions would be explored to se if they can be eliminated. Many times functions can be combined to reduce cost.

FUNCTION TREE TECHNIQUE

Another functional analysis technique that can be applied the trucking company project is the Function tree. The Tree structure provides clear visibility of the large number of functional elements makings up the project. A tree structure enables errors, omissions, inconsistencies and duplications to be detected through the branches. A hierarchical structure starting at system level working down in detail allows verification that the lower level functions are consistent with the top functions. A graphical hierarchical structure may be useful during the initial decomposition and structuring of functional requirements. Using the Tree function technique allows the functions to be regrouped and the relationship between functions to be established. A lower level function may be required by a number of main function trees.
Decomposition is important to the overall project plan because it allows you to determine the required resources, and schedule the work. At the top system level, the required function is derived from the mission statement and is the basis of the model functional specifications. The solution to meet these functions may require new lower level functions to be identified which are a result of the chosen solution. These new functions may be either serviced at the system level where they were derived, in which case the function is satisfied, or may be passed to a lower level. A function, which is passed to a lower level, is a higher level function for the recipient level. As the detail of the design progresses, each tier of the design shall include additional functions necessary to support the higher level functions. Both types of functions may be either solved internally within the system or refined into requirements and functions to be met at some lower level unit. Depending on where and how, some functions have some level of importance associated with them. Often at the lower levels, solutions are available which readily meet most of the functions or during development, it shall be established that a particular function is only met under specific conditions.
Whatever approach one uses, functional analysis can generally be represented as shown in figure 2. The function, “Generate more revenue” represents the reason for doing the project. The top level functions are the dependent functions and are further partitioned into some number of functions; i.e. when all of the first level functions are completed, the project is completed. Because a function tree is based on the project requirement, functional requirements, and already defined functions, all functions must satisfy a customer’s requirement and shall be distinguished from those required to satisfy a requirement generated by the selected functional solutions.
For any function which does not possess these characteristics, we partition into a set of necessary and sufficient function at the next level down. This is a good way to introduce standardization into system development methodology.