Goal Systems International

Constructing and Communicating Common Sense

The Intermediate Objectives Map

By H. William Dettmer

ABSTRACT
The Intermediate Objective (IO) Map is an adaptation of the Prerequisite Tree (PRT), which itself
is one of the tools of the Logical Thinking Process (LTP). The IO Map takes its place at the front
end of the LTP as a means of establishing the benchmark of required performance for whatever system is the subject of a thinking process analysis. The IO Map helps users establish the goal, critical
success factors, and key necessary conditions for any systemthe standards by which success or
failure of any system are measured. The results of using the IO Map as the first step in the LTP are
a) more precisely focused Current Reality Trees (CRT) that can be constructed much more quickly,
and b) substantially more robust conflict resolution using Evaporating Clouds (EC).
Evolution of the Intermediate Objectives Map
The Intermediate Objective (IO) Map dates back to at least 1995. It was casually mentioned
during a Management Skills Workshop conducted by Oded Cohen at the A.Y. Goldratt Institute,
but it was not part of that workshop, nor did it ever find its way into common usage as part of the
Logical Thinking Process (LTP). It was described as a kind of Prerequisite Tree without any obstacles.
I never thought much about it for the next seven years, until in late 2002, when I began grappling with the use of the LTP for developing and deploying strategy. At that time, Id been teaching
the LTP to a wide variety of clients for more than six years, and I had been dismayed by the number of students who had substantial difficulty constructing Current Reality Trees and Evaporating
Clouds of sufficient quality. They always seemed to take a very long time to build a CRT, and their
Evaporating Clouds were not always what I would characterize as robust.
It occurred to me that application of both the CRT and the EC seemed to lack effective focus. I
observed a substantial number of inconsequential cause-and-effect sequences in CRTs, and the ECs
didnt always seem relevant to the larger system challenges. They lacked reference to a should-be
view of the systemwhat ought to be happening.
It occurred to me that the IO Map Id seen in 1995 could be modified and applied to improve
the initial quality of CRTs. As time went on, I began to realize that the IO Map could serve a similar purpose with Evaporating Clouds.
Overview
Ill start with a brief recapitulation of the LTP. Then well consider the importance of establishing a goal and necessary conditions before starting a thinking process analysis. Third, well discuss
the functions of the IO Map. Ill explain how it fits in with a CRT and an Evaporating Cloud, and
Ill review the steps in constructing an IO Map.
The Logical Thinking Process (LTP)
The Logical Thinking Process was originally composed of five different logic trees: The Current Reality Tree (CRT), the Evaporating Cloud (EC), the Future Reality Tree (FRT), the Prerequisite Tree (PRT), and the Transition Tree (TT). (See Figure 1). Three of thesethe CRT, the FRT,
and the TTwere considered cause-and-effect, or sufficiency trees. The other twothe EC and
the PRTwere characterized as necessary condition trees. This made the latter two more like
flow charts than true logic trees.
Now, the sequence here is important. The CRT was the entry point into the process. The LTP
was originally intended for complex problem solving, and the CRT constituted the first step in this
process: problem definition.
Starting with what amounted to a blank sheet of paper and a lot of opinions, the LTP analyst
was expected to come up with a list of undesirable effects, or UDEs. From there, a backward-chain

111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

Goal Systems International

Constructing and Communicating Common Sense

Figure 1. The Logical Thinking Process

(original conception)
111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

of cause and effect was developed, culminating in a core problema root cause that supposedly accounted for 70 percent or more of the organizations undesirable effects.
The next step in the process was to ferret out the underlying conflict, the one perpetuating the
core problem, using an Evaporating Cloud. The output of the cloudthe injectionbecame the basis for the Future Reality Tree, which was intended to be a logical test of the efficacy of this mother
of all injections before implementation was attempted.
Next, the Prerequisite Tree, was designed to reveal the obstacles to implementing the injection
and to help create ways around them. Finally, the Transition Tree was intended to be a step-bystep implementation, or execution, procedure.
All in all, the Thinking Process was a brilliant concept. In fact, it was most probably the very
first true system-level problem-solving toolone that guided whole-system optimization, rather
than mere local process improvement.
But there was a problem with the original concept of the Logical Thinking Process. This problem limited its wider application, and it unfortunately began with the very first step in the processthe CRT.
Difficulty of the CRT
This big hurdle was that most people had a difficult time with the CRT. Getting started was
not as easy as it seemed. Moreover, there were problems with replicating results. I observed this
phenomenon the first time I had different students from the same organization working on the
same system problem independently. Each of them saw their organizations problems somewhat
differently, and though there were commonalities, in many cases they reached different statements
of the core problem.
This is a serious problem for any method that purports to be rational and scientific. The results of applying such methods should be independently replicable with the same procedures. Because the CRT is all about problem definition, if that part of the system analysis wrong, the rest of
the analysis is mostly worthless. These experiences raised the obvious questions: Why is the CRT
so difficult, and why are the results so inconsistent?
Problems with CRTs
The first and most obvious drawback to most of the CRTs I saw students create is that they
were too ponderoustoo complex. Because of this characteristic, they required a long time to construct, and they sometimes had a hundred or more entities. Such a tree may paint a detailed picture of the system, but its not very practical to present to decision makers. They wont sit still long
enough for analysts to justify their determination of the core problem. On the other hand, without
sufficient detail (however that might be defined), a CRT might not identify the right root causes.
The second obvious problem was that of too many undesirable effects. Ive seen CRTs with 20
to 30 UDEs. And usually, on closer examination, many of these couldnt be considered truly critical
from a system-level perspective. In other words, many so-called UDEs were really minor irritations, petty grievances, or personal axes to grind for the analyst. The best example of one of these
that I can recall is an UDE that read: My in-basket is always too full of paperwork.
The final deficiency I saw in most of the CRTs was the designation of core problems that were
so broad or vague as to be ultimately not actionable. In a misguided effort to find V-shaped connections that would merge two dozen or more diverse UDEs into a single core problem, the core
problem statements ended up being either a) historical events, or b) statements so broad that there
was no chance of acting on them. My personal favorite among the core problems I saw was: The
companys leadership is ineffective. (Try selling that core problem to a companys leader!)
UDE Determination
Logically (no double meaning intended!), the place to start in trying to resolve the problems
with CRTs lay in deciding what constitutes an undesirable effect and what doesnt. After all, if people can agree on that, the odds get better that a truly rational, evidence-based analysis will reach

111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

the same root causes, even if done by different peopleas long as those people have comparable
knowledge of the system.
The original definition of an UDEthe one that was provided to me in my original Jonah
Coursewas:
Anything thats happening in your system that you dont like.
There was an additional qualification:
An UDE is negative on its own merit.
Whats wrong with this definition? Basically, there is no objective criterion for what is undesirableor to whom its undesirable. Because this definition is purely subjective, it opened the door to
all kinds of personal gripes, regardless of their real impact on the organization. Many of the ones I
saw in early CRTs constituted no more than localized irritations that may not have had much impact on the larger system. Without some kind of objective criterion for what was undesirable, unnecessary detail crept into the analysis.
The Problem
The problem is that without a standardized benchmark for what should be happening in a system, it becomes exceptionally difficultand a matter of subjective opinionto determine whats
actually wrong with a system. The opening lines to the title song in the movie Paint Your Wagon
[Lerner and Lowe, 1951] express the lack-of-a-benchmark problem very well:
Where am I going? I dont know.
When will I get there? I aint certain.
All that I know is I am on my way.
Why is it important to know where youre going? In the immortal words of Yogi Berra, If you
dont know where youre going, when you get there, youll be lost. [See endnotes, Yogi Berra] (We
may be lost, but were making good time!) Without a clear sense of direction, UDEs dont reflect the
true pain of the system. Analysis becomes more of a shotgun approach, characterized by:
Numerous do-overs
Circling around, but never actually hitting, the real systemic issues, and
The CRT becoming a kind of amorphous mass, rather than an accurate focusing tool.
The net result is wasted time and frustration, and ultimately, after one or two bad experiences
like this, people end up avoiding the use of the CRTthe most important TP tool of all, because a
well-defined problem is more than half-solved.
Criteria for a Solution to the CRT Problem
Avoiding the Paint Your Wagon syndrome is actually fairly easy. Only four things are required:
A clear definition of the system in question and its boundaries
A single articulated consensus goal of that system
Determination of the critical success factors, which are no more than the minimum terminal
outcomes necessary to declare the goal achieved, and
Identification of some high-level supporting necessary conditions, which are usually functional
in nature.
In the aggregate, these will represent a measurable, objective benchmark for what should be
happening if the system is to succeed.
111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

The Intermediate Objectives (IO) Map

An IO Map is no more than a graphical, hierarchical representation of these aforementioned
benchmarks. The goal is at the top. The critical success factorsthe terminal outcomeslie immediately below the goal and are connected to it. And the relevant necessary conditions lie below the
critical success factors. (Refer to Figure 2) Its worth noting that the critical success factors are
limited in number usually no more than three to fivemaybe in rare cases as many as six, but not
often.
The real value of an IO Map
is its capability to keep the
analysis focused on whats really
important to system success,
avoiding the squeaky wheels
that attract attention but arent
really critical in the overall
scheme of things. Without an IO
Map, its not always obvious
where that ultimate destination
really is. Opinions canand do
differ. But the IO map keeps everyones eye on the ball.
The IO Maps most important function, from a problemsolving standpoint, is that it conFigure 2. Basic IO Map
stitutes a standard of system performance that allows problem-solvers to decide how far off-course the system is. You cant do that if
people cant agree on where theyre supposed to be.
So, the IO Map provides a graphic depiction of the goalthe fixed, immovable destination
were aiming for. It also gives us some reliable intermediate channel markers to help us establish
the proper course to the goal. And the necessary conditions could be considered short-term functional navigation aids on the way to satisfying the critical success factors.
These elements, embodied in an IO Map, establish the benchmark by which we determine how
the systems performance is deficient. The IO Map gives us the entering argument for the gap
analysis that will become our Current Reality Tree. It provides the basis for determining the systems real UDEs, and this basis is represented by the goal and the critical success factors. Moreover,
it ultimately prevents diversions or distractions by keeping the focus of the analysis on whats
really important to the system. Besides giving direction to the overall system analysis, the IO Map:
Confines UDEs in the Current Reality Tree to the truly high-level issues that actually constitute show-stoppers
Limits total UDEs to a manageable numberusually no more than the sum of the goal and the
critical success factors. This means at most, 5-6 system-level UDEs, and quite often fewer than
that, and
Speeds development of the CRT. Logical Thinking Process students who use an IO Map typically complete robust, logically sound CRTs in a matter of a few hours, rather than days, as
used to be required in the early days of the Logical Thinking Process.
System Boundaries
To construct an IO Map one must decide on the goal and critical success factors of the system.
But this presumes that you have clearly defined the boundaries of the system youre working on. In
other words, what could be considered to be inside the system, and what would be considered part
of the external environment? Moreover, systems can vary in breadth and scope. They can be societal, national, local, business, or family.
111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

Span of Control and Sphere of Influence

Its also helpful to begin with a sense of the limits of your authority and influence. While this is
not, strictly speaking, necessary in constructing an IO Map, its certainly helpful in deciding whose
help youre likely to need later on.
Your span of control includes all those aspects of your systems over which you have unilateral
change authority. As you can see from Figure 3, many people dont have very much. People may be
largely limited to deciding how to arrange their desk at work, their reclining chair or car keys,
when they set their alarm clock or do their outside chores, and last but not leasttheir rubber bath
toys! Notice that most people dont even have control over their dogs, who can be relatively independent themselves.
Sphere of influence includes those things over which you can exercise some influence, even if
you cant completely control them. Most peoples sphere of influence includes all other
aspects of their homes and family, and a few
levels of management at work. Everything
else in the world lies in the external environment.
Reviewing the IO Map
The IO Map separates the wheat from
the chaff. In other words, it helps differentiate whats important from what isnt. And it
shows the logical connections between the
goal and necessary conditions and those activities required to achieve them.
It must be emphasized that an IO Map
depicts a should-be view of the system,
Figure 3. Span of Control and Sphere of Influence
without regard to whats actually happening. SOURCE: Dettmer, The Logical Thinking Process (2007)
That comes later, in the Current Reality
Tree. The IO Map is telling you, Knowing what we know now about our system and its environment, if you want to achieve this goal, these are the thingsthe building blocksthat must be successfully accomplished.
A Typical IO Map
Figure 4 shows a notional IO Map for a typical small manufacturing company. Notice that the
goal is profitabilityto make more money, now and in the future. To do that, two critical success
factors are indispensable: Maximizing revenues and controlling costs. Notice that these are very
high-level terminal outcomes, and they are indispensable outcomes to any kind of for-profit commercial company. You can safely conclude that if you satisfy these two factors, your company will
be profitable.
Below the critical success factors are the necessary conditions. Notice that these elements begin to become much more functionally oriented. The critical success factors are considerably more
conceptual. The first level of necessary conditions under revenuessatisfied customers and sufficient market demandcould be considered a favorable interface with the market. The second level,
below the first, starts to get into very specific kinds of activities, such as quality control, supply
chain management, customer service, and pricing. Notice that the necessary conditions under cost
control could be considered the prime domain of Six Sigma.
The Link Between the IO Map and Other LTP Tools
Now that we know what an IO Map is, its time to see how it can be used as the foundation of
the Thinking Process. For problem-solving purposes, the IO Maps best uses are in determining the
undesirable effects in a Current Reality Tree, and defining important elements of an Evaporating
Cloud.
111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

Figure 4. IO Map Example

(small manufacturing company)

111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

Figure 5 shows the general structure of fully developed IO Map. It can be as detailed as the
user wants to make it. Greater detail merely involves penetrating down into more layers.
Normally, in using an IO Map for constructing Current Reality Trees, its not necessary to go
further down than one level of necessary conditions below the critical success factors. If one feels
more comfortable with deeper penetration, two levels are acceptable. But in almost all cases one

Figure 5. A Fully-Developed IO Map

level is enough to determine a systems UDEs. However, if you anticipate the need to construct one
or more Evaporating Clouds later, you might extend the IO Map to three or four layers below the
critical success factors. Theres no harm in doing thisit just gives you a more complete visual picture of what must be done to ensure success. But its not necessary at this point for getting started
on a CRT. You can always come back to the IO Map and extend it downward later, if the need actually arises. If you choose not to do so at this point, when the FRT is constructed, all the content that
would be at the lower levels of a more developed IO Map, will show up in the sufficiency-based logic
of the FRT in greater detail. So don't fret too much about how deep to go, you won't miss it out
later because your intuition will force you to put it in.
The IO Map and the Current Reality Tree
Once youve got an IO Map done to the required depth, youre ready to start using it. For a
Current Reality Tree, you need use only the goal and the critical success factors to determine undesirable effects. The functional levels below the CSF will be represented in the CRT in supporting
entities below the level of UDEs. You may also use the goal and CSF IO Map elements to articulate
the left side of an Evaporating Cloud. And as well see in a few minutes, the supporting necessary
conditions can be useful in Evaporating Clouds, too.
Defining Undesirable Effects becomes quick and easy once the top two layers of an IO Map are
in place. Merely examine the goal and each critical success factor in turn, and ask the question:
Are we achieving this now? or Are we achieving this to the degree that we should now?

111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

If the answer is yes, theres no UDE associated with that particular block. Maybe one or two
critical success factors are doing just fine, but the third one is hurting. If thats the case, then the
system isnt reaching its full potential with respect to the goal, so that would be one UDE. The failure to satisfy the one critical success factor might be another. One might also choose to designate
the failure to satisfy a subordinate necessary condition as an UDE, too. However, I personally prefer to confine my UDEs to the top
two levels. Lets see how the top
two layers of an IO Map point directly to Undesirable Effects.
(Refer to Figure 6)
The goal is to make more
money now and in the future. If
the company is losing moneyor
not making as much as it couldis
there any doubt in your mind that
this is undesirable? If sales revenue is deteriorating, is there any
doubt that Throughput is not increasing? If your warehouses are
overloaded, is there any question in
your mind that inventory hasnt
been minimized? And if overhead
exceeds revenues, doesnt it seem
that operating expense might not
Figure 6. IO Map to Undesirable Effects
be effectively controlled? Most important of allis there any doubt
in your mind at all that these are
the true system-level UDEs, and not
just somebodys personal petty aggravations?
If you had this little sufficiency relationship (see Figure 7)
to start with, is there any doubt in
your mind about whether you could
drill down to the right critical
root causes and do so quickly? And
how confident would you be that
you had identified the right system
UDEs?
Notice that using an IO Map
naturally limits UDEs to a manageable numberthe maximum is
the sum of the goal and all critical
success factors. The actual number
will likely be less than that. BeFigure 7. Beginning a Current Reality Tree
sides making the problem analysis
more robust and quicker, it naturally limits definition of the problem to something that a decisionmaker with quickly and easily can grasp.
Defining an Evaporating Cloud
Now lets consider how a well-developed IO Map might help in building an effective Evaporating Cloud quickly. Most people can articulate a conflict easily enoughwhat the two sides are con-

111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

tending about. This statement of the opposing sides is rendered as the two prerequisites in an
Evaporating Cloud.
The challenge for most people is deciding what real requirements the prerequisites are supposed to be satisfying, and then deciding on the overall objective of those requirements. People will
often speculate, inserting what looks good, rather than what can be logically supported. Determining the objective is often the most challenging part of building a cloud from right-to-left. This is
because its often difficult to state a single outcome for which both stated requirements are truly
necessary. The result is that people often contrive some soft, feel-good kind of statement to fit the
situation, such as Manage well. Theres a better way.
The question you should ask yourself is: Is the final configuration of the Evaporating Cloud
especially the statements on the left sidereally directly related to the success or failure of the system as a whole? If its not, you could be fiddling while Rome burns. Now lets consider what an IO
Map can do to improve the quality of Evaporating Clouds.
The IO Map and the EC
Three of the five elements of an Evaporating Cloud can be easily extracted from a systems IO
Map. The resulting cloud is much more likely to be both more robust and more reflective of the systems goal attainment than it would otherwise be if these elements were merely brainstormed.
Since any conflict associated with a system analysis is going to obstruct the resolution of problems that are important to the overall system, it only makes sense to reflect the systems goal and
necessary conditions somewhere in the cloud. The obvious source of these elements is an IO Map.
Constructing an EC from and IO Map (Variant #1)
The first and most obvious option is to relate the conflict to the overall system goal and two
critical success factors that support it.
(Refer to Figure 8) Identifying what
these elements are is a no-brainer. The
real challenge is relating each side of the
conflictthe opposing prerequisitesto
a pair of critical success factors. Its possible that this cant be done at all. If not,
move on to one of two other variants.
In this case, however, if we trace the
chain of necessity upward from the conflicting prerequisites, we can see that the
conflict might be between different
branches leading to different Critical
Success Factors. The typical example of
this configuration is the kind of conflict
that frequently arises between sales and
production. Each of those two functions
would likely be striving to satisfy differFigure 8. EC from IO Map (Variant #1)
ent critical success factors, and the overall objective of the cloud would, of course, be the system goal. Notice that in this depiction there are
several layers of necessary conditions between the actual conflict and the clouds requirements.
This is an important thing to keep in mind.
The reason is that each cloud has assumptions inherently associated with each side of the conflict. If one is perceptive enough to notice, just about every intermediate layer of necessary conditions between the bottom of the IO Map and the CSF represents an assumption underlying the arrows on that side of the Evaporating Cloud. So, not only have the two requirements and objective
been easily accounted for, the IO Map might also suggest several relevant assumptions underlying
each side.

111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

10

Constructing an EC from an IO Map

(Variant #2)
Now, what happens if your conflict
lies within a discrete functional area
say production, for example? Sales and
marketing dont enter into the matter at
all.
In this case, we would just slide
down one layer in the IO Map. (See Figure 9) A critical success factor becomes
the clouds objective, the last pair of converging necessary conditions becomes
the requirements, and the intervening
necessary conditions in each downward
path still point to assumptions. In this
case, as in Variant #1, we still begin with
Figure 9. EC from IO Map (Variant #2)
the conflicting prerequisites and look for
the lowest level of necessary condition
that they pertain to. Then we work our way up each path until you reach convergence at the critical
success factor.
Constructing an EC from an IO Map (Variant #3)
The final variation of this technique
presumes that the conflict is embedded
considerably deeper in the IO Map. In
this case, the conflicting prerequisites
prevent the attainment of a necessary
condition that lies below the level of the
critical success factorperhaps in one
functional branch, lets say raw material
inventory management. (Refer to Figure
10)
If this is the case, determining the
Evaporating Cloud elements begins the
same way: with the articulation of the
conflicting prerequisites. Then, as we
trace the path of necessity upward, we
find the convergence at a necessary condition somewhat below the critical sucFigure 10. EC from IO Map (Variant #3)
cess factor. But the same principle applies: the last two entities in each path prior to convergence represent the conflicts requirements, and
the convergence entity is the objective.
Now, clearly, using the IO Map for this purpose requires that we previously develop the IO
Map down well below the goal and critical success factors. The goal and critical success factors
alone would be sufficient for determining system-level UDEs. But a limited IO Mapmeaning the
top 2-3 layers onlywould not be enough to help very much with Evaporating Cloud construction.
If the idea of using an IO Map to help with both Current Reality Trees and Evaporating Clouds
is appealing, there are a couple of choices. One is to construct only the high-level IO Map before
starting the CRT, and defer the detailed development until the conflict resolution stage. The other
would be to build a comprehensive IO Map at the very beginning of the process, in which case only
the top part of the IO Map would be used for the CRT. The rest of the IO Map would be ready and
waiting when we get to conflict resolution. Either way, the time-consuming problem definition and
conflict resolution stages of a thinking process analysis are drastically compressed, from days or
111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300
2007 by H. W. Dettmer
All rights reserved

11

weeks to hours or, at most, a few days.

How to Construct an Intermediate Objectives (IO) Map
What follows is a simple procedure for creating an IO Map. A detailed description of the IO Map,
and the rationale and procedures for constructing one, may be found in The Logical Thinking Process [Dettmer, 2007].
1. The first step in the process is to clearly define the system that constitutes the object of you interest. What could be considered inside the system? What could be considered outside of it?
An established organizational boundary is usually a good starting point.
2. The next step is to define that systems goal. This is the end state or outcome for which the system exists. Its the result that the systems owners would say is its primary purpose. Express that
goal in a concise phrase not a complete sentence on a Post-it note.1
3. The third step is to determine the critical success factors (CSF). Each one is a terminal condition
required for the goal to be realized. There should be no more than 3-5 CSF. Theyre the high-level
show-stoppers without which the goal cant be attained. Express these as conditions or outcomes
on Post-it notes.
4. Determine the key necessary conditions (NC) needed to realize the CSF. These are supporting
components of each CSF, the discrete building blocks or intermediate milestones without which
each CSF cant be realized. Theyre likely to be functional in nature. For the purpose of constructing
a CRT, theres no need to build down more than one layer below the CSF. Express the NCs in concise phrases on Post-it notes.
5. Arrange these components of the IO Map on a large sheet of paper, or in a computer flowcharting program. Locate the goal at the top. Arrange the CSF horizontally below the goal. Place
the NCs below the CSF they support.
6. Connect the Goal, CSF, and NC. Use single arrows, without ellipses. Be alert for crossconnections.
Your initial arrangement of Post-it
notes should look something like Figure 11
With the connecting arrows added, your IO
Map should look like Figure 12. Notice the
cross-connection between one of the necessary conditions and two of the critical success factors.
7. Verify each connection. Are the CSF
really critical to goal attainment, and are
there no more than about 3-5 of them? Are
the CSF exclusively high-level outcomes? Is
each CSF the LAST thing that must happen before goal attainment (that is, a terminal condition)? Are all the NCs functional
components of the CSF they support? And
finally, have all cross-connections been
identified?
1

Figure 11. Post-it NotesInitial Arrangement

Post-it is a registered trademark of the 3M Corporation.

111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300

2007 by H. W. Dettmer
All rights reserved

12

The final step is logical scrutiny. Look

for missing elements at every level below
the goal. Rearrange entities as required to
minimize cross-over lines. And trim off
any low-level entities that would be better
address in execution planning.
An Aid to Constructing the IO Map
If one is not sure where to start, and if
the company already has a mission, vision,
or values statement of some kind, these
can be of some help. Any company that
went through the TQM revolution of the
1980s and 90s probably has these somewheregathering dust! Theres not enough
space in this paper to go into how to convert mission, vision and/or values stateFigure 12. Final IO Map Connections
ments into an IO Map. That discussion
may be found in The Logical Thinking
Process [Dettmer, 2007]. Suffice it to say that these statements can shorten the process somewhat.
The first thing to do is to determine whether a goal statement can be extracted from the mission statement. Critical success factors might also lie in the mission statement, but they could also
be embedded in vision or values statements. Necessary conditions are likely to be more difficult to
elicit from a mission, vision, or values.
Conclusion
The IO Map represents a revolutionary improvement in the use of the Logical Thinking Process. I provides the opportunity to create more robust Current Reality Trees and Evaporating Clouds
by ensuring that the focus of the LTP analysis remains always on the goal and critical success factors of the larger system. For more information on the IO Map and other improvements to the LTP
refer to Dettmer, 2007.
ENDNOTES:
1. Dettmer, H. William. The Logical Thinking Process: A Systems Approach to Complex Problem
Solving. Milwaukee, WI: ASQ Quality Press, 2007.
2. http://www.apollomanagedcare.com/QuotableQuotes.htm (Yogi Berra)
3. Lerner, Alan Jay, and Frederick Lowe. Paint Your Wagon, 1951.

111 Hurricane View Lane , Port Angeles, WA 98362 USA www.goalsys.com gsi@goalsys.com 1-360-565-8300

13