The Goal Tree Part 3

Review

In my last post I introduced you to the basic structure of the Goal Tree (a.k.a. The Intermediate Objectives Map).  I also expanded on the purpose of each component and presented some tips on how I go about constructing this logic diagram.  And finally, I presented a visual representation of the Goal Tree’s structure.  The figure below is what I presented and I am inserting it as a frame of reference for today’s post as we begin to construct a Goal Tree by way of an actual company’s case study.

As we proceed, it’s important to understand that the real value of a Goal Tree/IO Map is its capability to keep the analysis focused on what’s really important to system success.  Dettmer [1] tells us that a “Goal Tree/Intermediate Objectives Map will be unique to that system and the environment in which it operates.”  This is an extremely important concept because “one size does not fit all.”  Even two manufacturing companies, producing the same kind of part will probably have very dissimilar Goal Trees. 

Constructing a Goal Tree/Intermediate Objectives Map

A Goal Tree/IO Map could very quickly and easily be constructed by a single person, but if the system it represents is larger than the span of control of the individual person, then using a group setting is always better.  So with this in mind, the first step in constructing a Goal Tree/IO Map is to clearly define the system in which it operates and its associated boundaries.  Another important consideration is whether or not it falls within your span of control or your sphere-of-influence.  Defining your span of control and sphere of influence lets you know the level of assistance you might need from others, if you are to successfully change and improve your current reality.

Once you have defined the boundaries of the system you are attempting to improve, your next step is to define the goal of the system.  Remember, we said that the true owner(s) of the system is/are responsible for defining the goal.  If the true owners aren’t available, it is possible to articulate it by way of a “straw man,” but even then, you need to get concurrence on the goal from the owner(s) before beginning to construct your Goal Tree/IO Map.  Don’t lose sight of the fact that the purpose of the Goal Tree/IO Map is to identify the ultimate destination you are trying to reach.  The Goal Tree/IO Map’s most important function, from a problem-solving standpoint, is that it constitutes a standard of system performance that allows problem-solvers to decide how far off-course their system truly is. So with this in mind, your goal statement must reflect the final outcome and not the activities to get you there.  In other words, the goal is specified as an outcome of activities and not the activity itself.  

Once the goal has been defined and fully agreed upon, your next order of business is to develop three to five Critical Success Factors (CSFs) that must be firmly in place before your goal can be achieved.  As I explained in a previous post, the CSF’s are high-level milestones that result from specific, detailed actions.  The important point to remember is that if you don’t achieve every one of the CSF’s, you will not accomplish your goal.  

Finally, once our CSF’s have been clearly defined, your next step is to develop your Necessary Conditions (NCs) which are the simple building blocks for your Goal Tree/IO Map.  The NC’s are specific to the CSF they support, but because they are hierarchical in nature, there are typically multiple layers of them below each of the CSF’s.  As mentioned in my last post, Dettmer recommends no more than three layers for the NC’s, but on numerous occasions I have observed as many as five layers working quite well.  With the three components in place, you are now ready to construct your Goal Tree/IO Map.  Let’s now look at a case study where a company constructed their own Goal Tree/IO Map.

The Case Study Example

The company in question here is one that manufactures a variety of different products for diverse industry segments.  Some orders are build-to-order while others would be considered orders for mass production parts.  This company had plenty of orders to fill, but unfortunately they were having trouble not only filling them, but filling them on time.  As a result, this company’s profitability was fluctuating between making money one month and losing money the next.  Because of this, the board of directors decided to make a leadership change and hired a new CEO to “right the ship.”

The new CEO had a diverse manufacturing background meaning that in his career he had split his time between job shop environments and high volume manufacturing companies.  When the new CEO arrived, he called a meeting of his direct reports to not only meet them, but to assess their capabilities.  He soon realized that most of the existing management team had been working for this company for many years and that their skills appeared to be limited.  Before arriving, the new CEO had concluded that the best approach to turning this company’s profitability around and stabilizing it would be to use the Theory of Constraints Thinking Processes.  But after meeting his new team and evaluating their capabilities, and since time was of the essence, he decided instead to use the Goal Tree/IO Map to lay out an improvement strategy.

Next time

In my next posting we will discuss how this new CEO and his team developed their Goal Tree/IO Map. The next series of posts will be written as though you were actually leading the construction of the Goal Tree/IO Map in your own company.  I’m presenting it this way to add a flavor of realism to the discussion.  As always, if you have any questions or comments about any of my posts, leave me a message and I will respond. 

Until next time.

Bob Sproull

References:

[1] Dettmer, H. William. The Logical Thinking Process: A Systems Approach to Complex Problem Solving. Milwaukee, WI: ASQ Quality Press, 2007