FMEA – Define the Product Design Function(s) or Intent – Step 2

Defining the product design function(s) is key to the success of conducting a successful Design FMEA.

FMEA is a risk management tool that looks at and manages the risk of failure of the product functions. Failure to identify these functions leads to failure of managing the risk of those failures.

Once again I will use the Design FMEA to demonstrate the FMEA process.

Introduction

If we know all of the functions that a design has to achieve, then we can consider how those functions could potentially fail to meet the customer requirement. This is the key to understanding the exact functions that the product performs.

This often causes difficulties with FMEA’s as there is a tendency to generalise functions as a combination of functions. In the first FMEA article I used a pen as an example.

Pen Example      

Let’s consider the design a fountain pen. What is a primary function of a pen? To write?. We cannot design this pen to write on its own!    

We have to consider our design functions which might be: to retain ink, to dispense ink, to provide comfortable grip, to allow left and right handed use, to resist leaks, to provide smooth contact on writing surface etc.”

The outcome that a user expects is that (in the hands of a capable person) the pen will write. However, this is not a single function of the pen design as seen in the above example but a combination of functions that deliver the customer requirement.

Define the Product Design Function(s)

A robust method of defining a products function is the use of the Function Tree. I gave a brief description of the process in a previous article but I will explain further how this is applied. 

The function tree is a process used to determine prime functions and their subordinate functions for a given product. The process steps are as follows: - 

• Brief the team

• Brainstorm the functions of the product

• Organise the brainstorm outputs onto a function tree

Brief the Team

The team is led by the design owner and briefed on the process steps and the methodology for defining the functions.

The team meeting would be arranged with appropriate team roles (leader, scribe, time manager and facilitator) and the agenda would be set to allow time for briefing, brainstorming, organising the brainstorm output and reviewing.

Brainstorm the Functions of the Design

Follow the rules of brainstorming as follows: - 

• Keep the output visual

• Keep to the allotted time (time managers role)

• Volume is king

• Do not discuss ideas (this comes later)

• Do not criticise

• Involve all of the team (facilitators role)

• Do not organise the brainstorm (this comes later)

We use a VERB-NOUN sentencing technique to describe each function.

Example - Using the fountain pen as an example, functions would look like this: -

Organise the Brainstorm Outputs onto a Function Tree

It is very seldom that design specifications are written in this way so we use the Function Tree tool to capture and sort all the functions of a design from Primary functions to tertiary functions. 

Primary Functions – those that are identified nearest to the customer usage intent 

Secondary functions – those unique functions that support the primary functions 

Tertiary functions – functions that support the secondary functions and typically support more than one function.  

Measureable level – sometimes referred to as actionable level, are those functions that will have a specific measurable or set of measurables that can be specified.

First, Organise the Brainstorm Output by selecting the primary functions, then secondary and so on. Remember there may be more that four levels and it’s OK to add or duplicate functions (see fig 1).

The model used shows just four levels. However, in practice this may be more or less than four.

To check that the functions actually support one another, start by asking “How?” the primary function is achieved, through to the secondary and so on (see fig 2).

Then we ask of the tertiary functions "why?" and moving back up the tree, providing the answer at each level, making grammatical sense throughout.

The purpose of an FMEA is to precent failures of function. Therefore, if a functions is not fully described, prevention of failure of that function cannot be managed. This will become even more evident when I describe how to detrmine and record failure modes (the way a product funtion could potentialy fail).

Complete the FMEA Form

At this stage, all the primary functions are recorded on the FMEA Form. Recording the primary functions does not mean that the other functions will be missed, there is a discipline that needs to be observed for all FMEA meetings whixh is explained in the next section.

FMEA Discipline

Accepting that conducting an FMEA is a team event, it is also important to remeber the following: -

• Keep the Boundary diagram displayed during every meeting

• Keep the Function Tree displayed during every meeting

• Complete the assessing questions at the end of each FMEA stage

• If questions remain unanswered at the end of any meeting, keep a question log for the team.

Graham Cripps

Results Consortium Ltd

www.resultsresults.co.uk