THE FUNCTION WHEEL (JEFF RUDE) 

P 1 

The Function Wheel 
By Jeff Rude 
 

Preface 
In the world of the Value Methodology, there are many ideas and opinions for how to best perform both 
the  process  as  a  whole  and  each  of  the  individual  phases.    Arguably  the  most  contentious  phase  to 
attempt to present ideas is in the Function Analysis phase.  This is the phase where we, as practitioners 
and lovers of the art of value, can tend to diverge and polarize into as many directions and philosophies 
as there are religions in the world.  To preface this discussion, it’s necessary to mention two things: 

1. This is an idea at the Verge: This is a paper based on the result of the mixing of two opposite 
opinions  about  both  the  formation  of  functions  and  the  use  of  those  functions  in  a  logical 
manner to help teams to arrive at relevant and unique discussion points.  These opinions were 
discussed in French so some of it may have been lost in the translation. 

2. This is Not a New Idea: This is something that according to AFAV, and some standards that I was 
referred  to,  is  nothing  new  and,  in  fact,  is  written  into  some  of  the  European  standard.    This 
being said, it is a new idea for me and, I assume for others within SAVE and so I write this paper 
to  present  it  to  you  all.    It  also  needs  to  be  mentioned,  however,  that  there  will  likely  be 
someone  who  is  familiar  with  the  AFAV/EGB  standard  “Pieuvre”  or  Octopus  who  eventually 
reads  this  paper  and  accuses  me  of  bastardizing  their  tool.    To  these  folks,  I  agree 
wholeheartedly, I modified the tool to make it work for me and I invite anyone to again improve 
upon it with their own expertise. 

This paper is meant to be an exploration into another tool, another approach, another opportunity to 
use  our  favorite  tool,  Function  Analysis,  the  one  thing  that  differentiates  us  as  Value  practitioners,  to 
improve the experience of our workshops and the output from said workshops.  I am writing this in the 
hopes that some will be so inspired and have the liberty to use this tool within their own workshops that 
they  will  be  able  to,  in  turn,  improve  on  it.    This  of  course  is  the  best  case  scenario.    Worst  case,  the 
three people who actually read this paper will put it down halfway through and take a nap and forget to 
pick it back up again. 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 2 

Overview & History 
I would like to start off the discussion of the function wheel with a quick explanation of why even call it a 
Function Wheel in the first place.  It may help to go back into the history of where I learned about it and 
then move into the Function Wheel itself.   

About two years ago one of the French business schools I teach at got the bright idea that we should 
team up and present an extended week Value Class where I would have the opportunity to teach the 
SAVE standard MOD I and we would combine it into an extended week where an Association Francaise 
pour l’Analyse de la Valeur (AFAV) certified trainer would teach their Level 1 training along with me.  We 
each had the opportunity to complete our full courses, while the other one watched.  For the sake of 
keeping this paper light, I would like to give you a quick description of the AFAV trainer. 

For the sake of this paper the AFAV trainer, I will give him the name Pierre, was a retired veteran of the 
world of Value Consulting in France.  He was around 80 years old and has probably forgotten, as they 
say, more than I know about value.  Having worked in the automotive sector and other manufacturing 
sectors before moving into independent consulting for his career, he had a lifetimes worth of knowledge 
and about three times as many opinions on the subject of value.  Over the seven days of training, when I 
was  teaching  he  would  sit,  listen  and  comment  when  necessary  to  add  AFAV  factoids.    When  he  was 
teaching I would do the same.  As the week progressed, I listened a whole lot more than I commented, 
picked up a lot and Pierre, commented a lot and listened less.   

Due to a well engrained respect for my elders I took many opportunities to, rather than put down his 
tools and use of function, to reach out and understand why he said the things that he said and why he 
did the things that he did within his version of the value process.  To put it succinctly, the SAVE standard 
methodology  and  that  of  AFAV  is  extremely  different.    In  fact,  after  having  spent  some  time  in 
discussions with Pierre, we decided that the only thing that we do truly have in common was that we 
followed  a  methodology  that  included  understanding  the  project,  analyzing  its  functions,  and 
discovering  alternatives  to  perform  those  functions.    When  taken  from  a  non‐dogmatic  point‐of‐view, 
it’s really the foundation of value and is really quite a lot to agree upon. 

So  to  keep  a  long  story  short,  out  of  this  one  week  conversation,  a  lot  of  things  were  discussed  and 
argued and I have done my best to distill the best of those interactions into a workable tool that will be 
gentle with our SAVE Function fundamentals sensibilities.  To save anyone the stress and the heartache 
of arguing that the FAST Diagram does everything the Function Wheel does, I will state right now that I 
agree.  In my personal opinion as a fellow Function and FAST Fundamentalist, the FAST Diagram is far 
superior and, as a side note, the students far preferred the FAST to this method.  However, I have since 
been involved in projects that didn’t seem appropriate for FAST due to the relation of the components 
of the project nor did they seem appropriate for Tabular Function Lists where this Function Wheel has 
worked quite well. 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 3 

Positive Attributes of the Function Wheel 

 Visually clear interactive connection between the elements of the project and how they interact 
functionally with the project under study. 

 The system offers a directed approach for identifying functions as they relate to the elements. 

 The system offers a big‐picture view of the project. 

 Very quick to assemble.  As easy as tabular function with more logic associated to it. 

An additional benefit to a function wheel is that it may very well rival the oohs and aahs that come out 
of the client when they see a multicolor post‐it wall.  Something about the shape of a well completed 
complex wheel looks like  a fireworks explosion.  This also changes the  challenge of people thinking in 
the process diagram flow pattern which is often brought about by the left‐right logic path of the FAST 
Diagram. 

Basics of the Function Wheel 
The Octopus and the Horned Beast 

The Function Wheel is a derivation of the French “pieuvre” which translates into Octopus Diagram.  In 
order  to  populate  the  Octopus  using  another  tool  that  is  called  a  “bête  a  cornes”  or  Horned  Beast 
Diagram which helps to identify and understand the functions acting on a particular project.  These two 
work  hand  in  hand;  one  (the  Horned  Beast)  to  help  identify  the  functions  and  elements  and  then  the 
other (the Octopus) to identify how the functions relate to each other and the project as a whole.   

The Horned Beast 

Since the majority of this discussion is going to be about the Octopus/Wheel portion of the diagram, I 
will offer a brief discussion of the Horned Beast diagram as I understand it.  I have been told that this is a 
diagram used regularly in project management, however I had never used it in my own endeavors and 
had never even heard of it until my fateful meeting with Pierre.  The Horned Beast Diagram begins with 
asking three key questions: 

 Who or what will this project or product serve? 

 Who or what does it affect or interact with? 

 What’s the goal? 

Using these three questions, an AFAV practitioner would then create the Horned Beast: 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 4 

Who or what will this project or  Who or what does it affect or 
product serve? interact with?

User Rain

Rain Coat

What’s the goal? Why?

Protect the User from the Rain

As  illustrated,  the  two  elements,  derived  from  the  Horned  Beast’s  questions  helped  to  generate  a 
function.    Within  the  creation  of  the  Horned  Beast  diagram  Pierre  and  I  discovered  a  fundamental 
difference  in  our  understanding  of  function.    Apparently,  within  the  world  of  AFAV  an  idea  such  as 
“Protect the User from the Rain” is an acceptable function since it has the verb and a noun.  Hours of 
discussion failed to convince him that this was actually two, three or possibly four really stellar functions 
built  into  one  not‐so‐stellar  non‐function.    But  rather  than  laugh  at  the  silly  man,  it  started  me  to 
thinking, “One hundred well trained and well experienced Frenchies can’t just be stupid… there must be 
something that can come out of this.”   

This  example  of  a  non‐function  is  a  perfect  example  of  how  many  Subject  Matter  Expert  (SME)  team 
members think who are new to the  process and haven’t undergone forty hours or more of functional 
semantics  finishing  school.    So  if  anything  this  non‐function  is  a  super  way  to  begin  the  discussion  of 
function.    By  starting  with  an  idea  and  playing  with  it  a  bit  with  the  team,  one  of  these  solid  “non‐
functions” can easily be turned into at least a couple golden nugget functions without having to play a 
silly  semantics  game  with  SMEs.    This  is  especially  effective  when  your  SMEs  are  savants  who  are 
insulted  by  the  fact  that  you  are  forcing  them  to  work  within  a  Two  Word  Verb‐Noun  linguistic 
boundary. 

Not  to  belabor  the  Horned  Beast  concept  but  once  the  Elements  are  laid  out  visually  and  we  can  see 
their interaction the transition between the discussion of “what is it” and “what does it do” has been 
much  smoother,  more  enjoyable,  and  productive  for  team  members.    It’s  important  to  note  that  the 
Horned Beast Diagram concept would also be a time intensive discussion in a typical workshop agenda 
and so the Function Wheel is my attempt to combine both discussions into a workable and logical tool.  
Essentially,  the  Horned  Beast  diagram  is  a  visual  tool  to  illustrate  the  fundamental  questions  listed 
above. 

The Octopus Diagram / Function Wheel 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 5 

The purpose of the Octopus Diagram is to illustrate the associations of a system and the elements of its 
environment.    These  associations  are  actions  of  the  system  and/or  one  of  these  environmental 
elements.    The  associations  are  to  be  described  by  an  infinitive  verb  followed  by  one  or  more 
complementary nouns.  Rather than going into an exercise in translation, I will admit right now that this 
is  the  point  where  my  mind  wandered  away  from  the  finer  points  of  the  Octopus  and  ran  into  how  I 
could actually use what I was being taught.  

The Function Wheel is an attempt to repurpose and clearly explain what appears to be a useful tool for 
the French and make it palatable for our brand of function identification and analysis.  The basic premise 
behind the Function Wheel is to illustrate the relationship between the elements that act with or against 
a project, the functions of those interactions, and the project itself.  Additionally, it identifies functional 
interactions between functions.  I just confused myself writing this so I will list it out: 

1. Identifies project elements or Factors 

2. Identifies interactions between the elements and the project using function 

3. Identifies possible interactions between different elements using function 

This  is  helpful  in  many  ways  for  a  team  to  visualize  and  justify  or  challenge  the  validity  of  project 
elements,  factors  acting  on  the  project,  or  functional  relationships  between  all  the  pieces.    Up  to  this 
point,  it  has  been  as  easy  to  complete  as  a  Tabular  Function  Diagram  while  not  sacrificing  some 
semblance of a logical connection between those functions and their project. 

I have started calling it a Function Wheel not only because it comes across better for clients than calling 
it  an  Octopus  but  also  because  when  finished,  the  team  will  have  created  a  function  diagram  that 
resembles  a  wheel  with  spokes  moving  towards  a  center  point  which  is  the  project.    The  best  way  to 
describe the Wheel is to charge forward into explaining how to create one.  The tools I have been using 
for them are exactly the same as the FAST Diagram: Post‐It’s and Markers. 

How to build the Function Wheel Diagram 
Circumference ‐ Populating the Tire of the Wheel 

Starting with a Post‐It with the project in the middle, we can start by using the questions of the Horned 
Beast, along with other questions that may help the team the facilitator will begin by creating a circle of 
Elements or Factors that will be related to the project.  At this point I have not determined the best title 
for this part which is why I am jumping between “Elements” and “Factors”.  As a team leader, my goal is 
not  in  naming  the  products  as  much  as  it  is  using  the  appropriate  terminology  for  the  team  to 
understand what we mean by the term.  The best description for the Element/Factor term that I have 
come up with is as follows: 

Project Elements are those parts in the environment of the project that will influence or be influenced by 
the project.* 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 6 

You could just as easily replace the word project for product, system, service etc.  Some of the questions 
that I have used with teams to populate the radius of the wheel start with the Horned Beast questions 
and move from there*: 

 Who or what will this project or product serve? 

 Who or what does it affect or interact with? 

 What are some unique features of this project? 

 Where is this project going to be? 

 How is it going to be used? 

 When does it need to be used? 

 What are the wants and needs? 

 When does it need to be completed? 

The completed wheel will likely grow and shrink as the team develops and refines the project elements.  
It’s a great opportunity to discuss all the parts of the project and I have found that most teams actually 
enjoy populating the circumference of the wheel as it allow them to rehash what they have just learned 
in  the  information  phase.    It  allows  for  a  very  natural  transition  from  Information  Phase  into  the 
Function Analysis phase and delivers a visual representation of what the team learned.  After this step, 
the wheel will look like this: 

If we were to continue with the Raincoat example from the Horned Beast discussion, the first product 
may look something like this: 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 7 

An important part to each step of the process is to confirm consensus that everyone on the team agrees 
that all of the elements of the project have been identified and represented.  Once the circumference of 
the wheel has been completed and the team agrees that it looks proper, we can move on to the next 
step of identifying interactions between the functions. 

Interrelations ‐ Building the Spokes of the Wheel 

Now  that  the  circumference  of  the  function  wheel  has  been  completed  the  next  step  is  to  build 
interconnections  between  the  functions  as  they  relate  to  the  center  product.    This  exercise  is  fairly 
intuitive  and  there  are  some  simple  questions  that  the  team  can  work  with  in  order  to  build  the 
connection.    The  most  basic  question  that  is  asked  is,  “Does  Element  X  relate  to  Element  Y?”    If  a 
connection  is  established,  then  sticking  with  Element  X  we  would  then  ask  if  it  relates  to  Element  Z, 
Element  A,  Element  B,  etc.    Each  time  a  connection  is  established,  we  would  draw  a  line  connecting 
them, normally with a curve running through the center product/project.  The final product would look 
similar to this: 

Factor - Factor -
Environment Environment

Factor - Factor -
Environment Environment

Factor - Factor -
Environment Environment

Factor -
Environment
 

Following our Raincoat example: 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 8 

Salty Seadog Rain

Color Wind

Rain Coat

Sea Water Materials

Storage
 

So for this example, we can see that there are a number of interconnections and relations between the 
elements of the Raincoat.  There is a connection between the Rain and the Wind elements as they relate 
to the Raincoat.  There is a relation between the Sea Water and the Wind as they relate to the Raincoat.  
There is a relation between the Seadog and the Color of the Raincoat.  There is a relation between the 
Storage  of  the  Raincoat  and  the  Materials  that  are  being  used  to  make  it.    There  is  also  a  relation 
between the Seadog and the Materials being used to make the Raincoat.  

One fact to point out immediately is that the Salty Seadog element, the user, could in some minds have 
a connection to all the other elements.  In the interest of simplicity and to avoid over complications of 
the model, I generally avoid showing the obvious relations to the elements that could potentially have 
five or more lines coming from them.  Drawing those lines tends to state the obvious and doesn’t help 
with the function identification as the lines are intended.  A practitioner will often find themselves faced 
with a function or two that seem to relate to everything.  These are key elements and are important.  If 
faced with a team that wants to connect it to everything, it’s an opportunity to question those links and 
whether they are relevant to the scope of this particular project.  Often this scope discussion will help to 
hone 

At this point in the construction of the Function Wheel, the team can easily transition into discussing the 
functions along the interconnections.  In the studies that I have facilitated using this tool, the transition 
is extremely natural as the connections start very clearly illustrate that there are functional relationships 
between  the  elements  as  they  relate  to  the  project  or  product.    So  the  next  step  is  to  populate  the 
wheel with the functions. 

Functions – Populating the Function Wheel with Functions 

We now need to identify the functions on the spokes of the wheel.  For a value practitioner, this process 
will be natural as you move forward into the wheel using the guidelines of the wheel that have already 
been established.  The lines are the relations and they either relate to another element or they relate 
back  to  the  project  itself.    There  are  some  questions  a  practitioner  can  ask  to  help  the  team  in  their 
function identification: 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 9 

 What does Element X do in relation to Element Y? 

 What does Element X do to Element Y? 

 How does Element X affect the project? 

 How do Element X and Y affect the project? 

 How do Element X and Y affect Element A? 

Eventually,  functions  will  populate  the  spokes  of  the  wheel.    On  the  wall  they  will  be  different  color 
post‐its.    The  functions,  following  SAVE  Standards,  should  be  stated  in  the  Active  Verb  –  Measurable 
Noun context.  When populated, they should look something like this: 

Factor - Factor -
Environment Environment

Verb Verb
Noun Noun
Factor - Factor -
Environment Verb Verb Environment
Noun Noun

Verb Verb Verb

Factor -
Environment
 

Following the Raincoat example, it would look something like this: 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 10 

Looking  at  the  Raincoat  example,  we  can  see  that  there  are  some  functions  that  are  related  to  each 
other as well as the elements being related to each other.  One rule that I have been using up to this 
point is that the same function can go up as many times as is necessary in different areas of the Wheel 
and often it  has turned out to be a Basic Function, but not always.  This function wheel will generally 
grow and shrink as the team discusses and refines it.  It’s often a matter of moving it to a larger wheel, 
expanding it out or contracting it in.  The size of the wheel and the number of functions that relate to it 
are often not fixed until the end of the exercise. 

The How‐Why Logic Path 

I have attempted, on the Wheel, to use the How‐Why logic path that is so effective on FAST diagrams.  
Up to this point, I can say that it does work but only so well, especially when there are many instances of 
the same function on the wheel and they start to interrelate to one another.  One possibility might be, if 
a  Value  Team  Leader  were  in  a  situation  where  he  or  she  had  a  Function  Analysis  intense  workshop 
where the client was in need of real focus, that a FAST could be made using the functions identified in 
the  Wheel  portion  of  Function  analysis.    It  all  depends  on  the  amount  of  time  a  team  leader  has  to 
complete  it.    Usually,  these  Function  Wheels  have  taken  between  one  to  two  hours  to  complete  on 
moderately complex projects. 

Basic Functions 

Once the Function Wheel has been completed, the team can discuss which of the functions are basic, 
secondary  and  required  secondary  functions.    This  is  done  similarly  to  how  one  would  complete  the 
discussion  using  a  Tabular  Function  Diagram  and  any  of  your  own  creativity  in  this  endeavor  can 
enhance it. 
 THE FUNCTION WHEEL (JEFF RUDE) 

P 11 

Way Forward 
How can it get better?  Essentially this is the only way forward I would like to propose on the Function 
Wheel.  For those of you who would like to be so courageous as to attempt one of these in your own 
workshop and see how it works and see how it doesn’t work, it would be fantastic if we could improve 
upon  the  model.    As  stated  above,  for  the  moment  this  is  an  ugly  mix  of  some  AFAV  stuff  along  with 
some SAVE stuff and a little bit of my own stuff.  This is far from a refined and scientifically proven tool 
and very little research has been put into it.  It has been tested however and among the team members 
that I asked about it actually preferred it to other Function Analysis tools.  It’s fast, it lets the experts flex 
a bit more of their intellectual muscle and it creates a diagram that can easily represent the discussions 
held  within  the  team  as  they  relate  to  the  project  as  a  whole  and  the  needs  of  the  client.    I  invite  all 
those who are interested to try one out in your next project and let me know how it went.