“Constructing and Communicating Common Sense The ... · “Constructing and Communicating Common Sense™” The Intermediate Objectives Map ... “Constructing and Communicating

1111 Hurricane View Lane , Port Angeles, WA 98362 USA▪www.goalsys.com ▪[email protected] ▪1-360-565-8300

Goal Systems International“Constructing and Communicating Common Sense™”

The Intermediate Objectives MapBy H. William Dettmer

ABSTRACTThe Intermediate Objective (IO) Map is an adaptation of the Prerequisite Tree (PRT), which itselfis one of the tools of the Logical Thinking Process (LTP). The IO Map takes its place at the frontend of the LTP as a means of establishing the benchmark of required performance for whatever sys-tem is the subject of a thinking process analysis. The IO Map helps users establish the goal, criticalsuccess factors, and key necessary conditions for any system—the standards by which success orfailure of any system are measured. The results of using the IO Map as the first step in the LTP area) 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 MapThe 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 theLogical Thinking Process (LTP). It was described as a kind of Prerequisite Tree without any obsta-cles.

I never thought much about it for the next seven years, until in late 2002, when I began grap-pling with the use of the LTP for developing and deploying strategy. At that time, I’d been teachingthe LTP to a wide variety of clients for more than six years, and I had been dismayed by the num-ber of students who had substantial difficulty constructing Current Reality Trees and EvaporatingClouds of sufficient quality. They always seemed to take a very long time to build a CRT, and theirEvaporating 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. Iobserved a substantial number of inconsequential cause-and-effect sequences in CRTs, and the ECsdidn’t always seem relevant to the larger system challenges. They lacked reference to a “should-be”view of the system—what ought to be happening.

It occurred to me that the IO Map I’d seen in 1995 could be modified and applied to improvethe initial quality of CRTs. As time went on, I began to realize that the IO Map could serve a simi-lar purpose with Evaporating Clouds.

OverviewI’ll start with a brief recapitulation of the LTP. Then we’ll consider the importance of establish-

ing a goal and necessary conditions before starting a thinking process analysis. Third, we’ll discussthe functions of the IO Map. I’ll explain how it fits in with a CRT and an Evaporating Cloud, andI’ll 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 Cur-

rent Reality Tree (CRT), the Evaporating Cloud (EC), the Future Reality Tree (FRT), the Prerequi-site Tree (PRT), and the Transition Tree (TT). (See Figure 1). Three of these—the CRT, the FRT,and the TT—were considered “cause-and-effect”, or sufficiency trees. The other two—the EC andthe PRT—were characterized as “necessary condition” trees. This made the latter two more likeflow charts than true logic trees.

Now, the sequence here is important. The CRT was the entry point into the process. The LTPwas originally intended for complex problem solving, and the CRT constituted the first step in thisprocess: problem definition.

Starting with what amounted to a blank sheet of paper and a lot of opinions, the LTP analystwas expected to come up with a list of undesirable effects, or UDEs. From there, a backward-chain

© 2007 by H. W. DettmerAll rights reserved© 2007 by H. W. DettmerAll rights reserved


Goal Systems International“Constructing and Communicating Common Sense™”

Figure 1. The Logical Thinking Process(original conception)

© 2007 by H. W. DettmerAll rights reserved

3

of cause and effect was developed, culminating in a core problem—a root cause that supposedly ac-counted for 70 percent or more of the organization’s undesirable effects.

The next step in the process was to ferret out the underlying conflict, the one perpetuating thecore problem, using an Evaporating Cloud. The output of the cloud—the injection—became the ba-sis for the Future Reality Tree, which was intended to be a logical test of the efficacy of this “motherof all injections” before implementation was attempted.

Next, the Prerequisite Tree, was designed to reveal the obstacles to implementing the injectionand to help create ways around them. Finally, the Transition Tree was intended to be a step-by-step implementation, or execution, procedure.

All in all, the Thinking Process was a brilliant concept. In fact, it was most probably the veryfirst true system-level problem-solving tool—one that guided whole-system optimization, ratherthan mere local process improvement.

But there was a problem with the original concept of the Logical Thinking Process. This prob-lem limited its wider application, and it unfortunately began with the very first step in the proc-ess—the CRT.

Difficulty of the CRTThis 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 thisphenomenon the first time I had different students from the same organization working on thesame system problem independently. Each of them saw their organization’s problems somewhatdifferently, and though there were commonalities, in many cases they reached different statementsof the core problem.

This is a serious problem for any method that purports to be rational and “scientific.” The re-sults of applying such methods should be independently replicable with the same procedures. Be-cause the CRT is all about problem definition, if that part of the system analysis wrong, the rest ofthe analysis is mostly worthless. These experiences raised the obvious questions: “Why is the CRTso difficult, and why are the results so inconsistent?”

Problems with CRTsThe first and most obvious drawback to most of the CRTs I saw students create is that they

were too ponderous—too complex. Because of this characteristic, they required a long time to con-struct, and they sometimes had a hundred or more entities. Such a tree may paint a detailed pic-ture of the system, but it’s not very practical to present to decision makers. They won’t sit still longenough for analysts to justify their determination of the core problem. On the other hand, withoutsufficient 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. I’ve seen CRTs with 20to 30 UDEs. And usually, on closer examination, many of these couldn’t be considered truly criticalfrom a system-level perspective. In other words, many so-called “UDEs” were really minor irrita-tions, petty grievances, or personal axes to grind for the analyst. The best example of one of thesethat 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 wereso broad or vague as to be ultimately not actionable. In a misguided effort to find “V-shaped” con-nections that would merge two dozen or more diverse UDEs into a single core problem, the coreproblem statements ended up being either a) historical events, or b) statements so broad that therewas no chance of acting on them. My personal favorite among the core problems I saw was: “Thecompany’s leadership is ineffective.” (Try selling that core problem to a company’s leader!)

UDE DeterminationLogically (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 doesn’t. After all, if peo-ple 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 ▪[email protected] ▪1-360-565-8300© 2007 by H. W. DettmerAll rights reserved

4

the same root causes, even if done by different people—as long as those people have comparableknowledge of the system.

The original definition of an UDE—the one that was provided to me in my original JonahCourse—was:

“Anything that’s happening in your system that you don’t like.”

There was an additional qualification:

“An UDE is negative on its own merit.”

What’s wrong with this definition? Basically, there is no objective criterion for what is undesir-able—or to whom it’s undesirable. Because this definition is purely subjective, it opened the door toall kinds of personal “gripes,” regardless of their real impact on the organization. Many of the ones Isaw in early CRTs constituted no more than localized “irritations” that may not have had much im-pact on the larger system. Without some kind of objective criterion for what was undesirable, unnec-essary detail crept into the analysis.

The ProblemThe problem is that without a standardized benchmark for what should be happening in a sys-

tem, it becomes exceptionally difficult—and a matter of subjective opinion—to determine what’sactually 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 don’t know.When will I get there? I ain’t certain.All that I know is I am on my way.

Why is it important to know where you’re going? In the immortal words of Yogi Berra, “If youdon’t know where you’re going, when you get there, you’ll be lost.” [See endnotes, Yogi Berra] (Wemay be lost, but we’re making good time!) Without a clear sense of direction, UDEs don’t reflect thetrue 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 experienceslike this, people end up avoiding the use of the CRT—the most important TP tool of all, because awell-defined problem is more than half-solved.

Criteria for a Solution to the CRT ProblemAvoiding 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 behappening if the system is to succeed.


5

The Intermediate Objectives (IO) MapAn IO Map is no more than a graphical, hierarchical representation of these aforementioned

benchmarks. The goal is at the top. The critical success factors—the terminal outcomes—lie imme-diately below the goal and are connected to it. And the relevant necessary conditions lie below thecritical success factors. (Refer to Figure 2) It’s worth noting that the critical success factors arelimited in number usually no more than three to five—maybe in rare cases as many as six, but notoften.

The real value of an IO Mapis its capability to keep theanalysis focused on what’s reallyimportant to system success,avoiding the “squeaky wheels”that attract attention but aren’treally critical in the overallscheme of things. Without an IOMap, it’s not always obviouswhere that ultimate destinationreally is. Opinions can—and do—differ. But the IO map keeps eve-ryone’s eye on the ball.

The IO Map’s most impor-tant function, from a problem-solving standpoint, is that it con-stitutes a standard of system per-formance that allows problem-solvers to decide how far off-course the system is. You can’t do that ifpeople can’t agree on where they’re supposed to be.

So, the IO Map provides a graphic depiction of the goal—the fixed, immovable destinationwe’re aiming for. It also gives us some reliable intermediate “channel markers” to help us establishthe proper course to the goal. And the necessary conditions could be considered short-term func-tional 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 howthe system’s performance is deficient. The IO Map gives us the entering argument for the “gapanalysis” that will become our Current Reality Tree. It provides the basis for determining the sys-tems 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 what’sreally 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 consti-tute “show-stoppers”

▪ Limits total UDEs to a manageable number—usually no more than the sum of the goal and thecritical success factors. This means at most, 5-6 system-level UDEs, and quite often fewer thanthat, and

▪ Speeds development of the CRT. Logical Thinking Process students who use an IO Map typi-cally complete robust, logically sound CRTs in a matter of a few hours, rather than days, asused to be required in the early days of the Logical Thinking Process.

System BoundariesTo 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 you’re working on. Inother words, what could be considered to be inside the system, and what would be considered partof the external environment? Moreover, systems can vary in breadth and scope. They can be socie-tal, national, local, business, or family.


Figure 2. Basic IO Map


6

Span of Control and Sphere of InfluenceIt’s 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, it’s certainly helpful in deciding whosehelp you’re likely to need later on.

Your span of control includes all those aspects of your systems over which you have unilateralchange authority. As you can see from Figure 3, many people don’t have very much. People may belargely 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 least…their rubber bathtoys! Notice that most people don’t even have control over their dogs, who can be relatively inde-pendent themselves.

Sphere of influence includes those things over which you can exercise some influence, even ifyou can’t completely control them. Most peo-ple’s sphere of influence includes all otheraspects of their homes and family, and a fewlevels of management at work. Everythingelse in the world lies in the external environ-ment.

Reviewing the IO MapThe IO Map separates the “wheat from

the chaff.” In other words, it helps differenti-ate what’s important from what isn’t. And itshows the logical connections between thegoal and necessary conditions and those ac-tivities required to achieve them.

It must be emphasized that an IO Mapdepicts a “should-be” view of the system,without regard to what’s actually happening.That comes later, in the Current RealityTree. The IO Map is telling you, “Knowing what we know now about our system and its environ-ment, if you want to achieve this goal, these are the things—the building blocks—that must be suc-cessfully accomplished.”

A Typical IO MapFigure 4 shows a notional IO Map for a typical small manufacturing company. Notice that the

goal is profitability—to make more money, now and in the future. To do that, two critical successfactors are indispensable: Maximizing revenues and controlling costs. Notice that these are veryhigh-level terminal outcomes, and they are indispensable outcomes to any kind of for-profit com-mercial company. You can safely conclude that if you satisfy these two factors, your company willbe profitable.

Below the critical success factors are the necessary conditions. Notice that these elements be-gin to become much more functionally oriented. The critical success factors are considerably moreconceptual. The first level of necessary conditions under revenues—satisfied customers and suffi-cient market demand—could 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, supplychain management, customer service, and pricing. Notice that the necessary conditions under costcontrol could be considered the prime domain of Six Sigma.

The Link Between the IO Map and Other LTP ToolsNow that we know what an IO Map is, it’s time to see how it can be used as the foundation of

the Thinking Process. For problem-solving purposes, the IO Map’s best uses are in determining theundesirable effects in a Current Reality Tree, and defining important elements of an EvaporatingCloud.


Figure 3. Span of Control and Sphere of InfluenceSOURCE: Dettmer, The Logical Thinking Process (2007)



Figure 4. IO Map Example(small manufacturing company)


8

Figure 5 shows the general structure of fully developed IO Map. It can be as detailed as theuser wants to make it. Greater detail merely involves penetrating down into more layers.

Normally, in using an IO Map for constructing Current Reality Trees, it’s not necessary to gofurther down than one level of necessary conditions below the critical success factors. If one feelsmore comfortable with deeper penetration, two levels are acceptable. But in almost all cases one

level is enough to determine a system’s UDEs. However, if you anticipate the need to construct oneor more Evaporating Clouds later, you might extend the IO Map to three or four layers below thecritical success factors. There’s no harm in doing this—it just gives you a more complete visual pic-ture of what must be done to ensure success. But it’s not necessary at this point for getting startedon a CRT. You can always come back to the IO Map and extend it downward later, if the need actu-ally arises. If you choose not to do so at this point, when the FRT is constructed, all the content thatwould be at the lower levels of a more developed IO Map, will show up in the sufficiency-based logicof the FRT in greater detail. So don't fret too much about how deep to go, you won't miss it outlater because your intuition will force you to put it in.

The IO Map and the Current Reality TreeOnce you’ve got an IO Map done to the required depth, you’re ready to start using it. For a

Current Reality Tree, you need use only the goal and the critical success factors to determine unde-sirable effects. The functional levels below the CSF will be represented in the CRT in supportingentities below the level of UDEs. You may also use the goal and CSF IO Map elements to articulatethe left side of an Evaporating Cloud. And as we’ll see in a few minutes, the supporting necessaryconditions can be useful in Evaporating Clouds, too.

Defining Undesirable Effects becomes quick and easy once the top two layers of an IO Map arein 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?”


Figure 5. A Fully-Developed IO Map


9

If the answer is yes, there’s no UDE associated with that particular block. Maybe one or twocritical success factors are doing just fine, but the third one is hurting. If that’s the case, then thesystem isn’t reaching its full potential with respect to the goal, so that would be one UDE. The fail-ure to satisfy the one critical success factor might be another. One might also choose to designatethe failure to satisfy a subordinate necessary condition as an UDE, too. However, I personally pre-fer to confine my UDEs to the toptwo levels. Let’s see how the toptwo layers of an IO Map point di-rectly to Undesirable Effects.(Refer to Figure 6)

The goal is to “make moremoney now and in the future.” Ifthe company is losing money—ornot making as much as it could—isthere any doubt in your mind thatthis is undesirable? If sales reve-nue is deteriorating, is there anydoubt that Throughput is not in-creasing? If your warehouses areoverloaded, is there any question inyour mind that inventory hasn’tbeen minimized? And if overheadexceeds revenues, doesn’t it seemthat operating expense might notbe effectively controlled? Most im-portant of all—is there any doubtin your mind at all that these arethe true system-level UDEs, and notjust somebody’s personal petty ag-gravations?

If you had this little suffi-ciency relationship (see Figure 7)to start with, is there any doubt inyour mind about whether you could“drill down” to the right criticalroot causes and do so quickly? Andhow confident would you be thatyou had identified the right systemUDEs?

Notice that using an IO Mapnaturally limits UDEs to a man-ageable number—the maximum isthe sum of the goal and all criticalsuccess factors. The actual numberwill likely be less than that. Be-sides making the problem analysismore robust and quicker, it naturally limits definition of the problem to something that a decision-maker with quickly and easily can grasp.

Defining an Evaporating CloudNow let’s consider how a well-developed IO Map might help in building an effective Evaporat-

ing Cloud quickly. Most people can articulate a conflict easily enough—what the two sides are con-


Figure 6. IO Map to Undesirable Effects

Figure 7. Beginning a Current Reality Tree


10

tending about. This statement of the opposing sides is rendered as the two prerequisites in anEvaporating Cloud.

The challenge for most people is deciding what real requirements the prerequisites are sup-posed to be satisfying, and then deciding on the overall objective of those requirements. People willoften speculate, inserting what “looks good,” rather than what can be logically supported. Deter-mining the objective is often the most challenging part of building a cloud from right-to-left. This isbecause it’s often difficult to state a single outcome for which both stated requirements are trulynecessary. The result is that people often contrive some soft, “feel-good” kind of statement to fit thesituation, such as “Manage well.” There’s a better way.

The question you should ask yourself is: “Is the final configuration of the Evaporating Cloud—especially the statements on the left side—really directly related to the success or failure of the sys-tem as a whole?” If it’s not, you could be “fiddling while Rome burns.” Now let’s consider what an IOMap can do to improve the quality of Evaporating Clouds.

The IO Map and the ECThree of the five elements of an Evaporating Cloud can be easily extracted from a system’s IO

Map. The resulting cloud is much more likely to be both more robust and more reflective of the sys-tem’s 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 prob-lems that are important to the overall system, it only makes sense to reflect the system’s goal andnecessary 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 whatthese elements are is a “no-brainer.” Thereal challenge is relating each side of theconflict—the opposing prerequisites—toa pair of critical success factors. It’s pos-sible that this can’t be done at all. If not,move on to one of two other variants.

In this case, however, if we trace thechain of necessity upward from the con-flicting prerequisites, we can see that theconflict might be between differentbranches leading to different CriticalSuccess Factors. The typical example ofthis configuration is the kind of conflictthat frequently arises between sales andproduction. Each of those two functionswould likely be striving to satisfy differ-ent critical success factors, and the over-all objective of the cloud would, of course, be the system goal. Notice that in this depiction there areseveral layers of necessary conditions between the actual conflict and the cloud’s 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 con-flict. If one is perceptive enough to notice, just about every intermediate layer of necessary condi-tions between the bottom of the IO Map and the CSF represents an assumption underlying the ar-rows on that side of the Evaporating Cloud. So, not only have the two requirements and objectivebeen easily accounted for, the IO Map might also suggest several relevant assumptions underlyingeach side.


Figure 8. EC from IO Map (Variant #1)


11

Constructing an EC from an IO Map(Variant #2)

Now, what happens if your conflictlies within a discrete functional area—say production, for example? Sales andmarketing don’t enter into the matter atall.

In this case, we would just “slidedown” one layer in the IO Map. (See Fig-ure 9) A critical success factor becomesthe cloud’s objective, the last pair of con-verging necessary conditions becomesthe requirements, and the interveningnecessary conditions in each downwardpath still point to assumptions. In thiscase, as in Variant #1, we still begin withthe conflicting prerequisites and look forthe lowest level of necessary conditionthat they pertain to. Then we work our way up each path until you reach convergence at the criticalsuccess factor.

Constructing an EC from an IO Map (Variant #3)The final variation of this technique

presumes that the conflict is embeddedconsiderably deeper in the IO Map. Inthis case, the conflicting prerequisitesprevent the attainment of a necessarycondition that lies below the level of thecritical success factor—perhaps in onefunctional branch, let’s say raw materialinventory management. (Refer to Figure10)

If this is the case, determining theEvaporating Cloud elements begins thesame way: with the articulation of theconflicting prerequisites. Then, as wetrace the path of necessity upward, wefind the convergence at a necessary con-dition somewhat below the critical suc-cess factor. But the same principle ap-plies: the last two entities in each path prior to convergence represent the conflict’s requirements, andthe convergence entity is the objective.

Now, clearly, using the IO Map for this purpose requires that we previously develop the IOMap down well below the goal and critical success factors. The goal and critical success factorsalone would be sufficient for determining system-level UDEs. But a limited IO Map—meaning thetop 2-3 layers only—would 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 Cloudsis appealing, there are a couple of choices. One is to construct only the high-level IO Map beforestarting the CRT, and defer the detailed development until the conflict resolution stage. The otherwould be to build a comprehensive IO Map at the very beginning of the process, in which case onlythe top part of the IO Map would be used for the CRT. The rest of the IO Map would be ready andwaiting when we get to conflict resolution. Either way, the time-consuming problem definition andconflict resolution stages of a thinking process analysis are drastically compressed, from days or





12

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

How to Construct an Intermediate Objectives (IO) MapWhat 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 Proc-ess [Dettmer, 2007].

1. The first step in the process is to clearly define the system that constitutes the object of you inter-est. 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 system’s goal. This is the “end state” or outcome for which the sys-tem exists. It’s the result that the system’s owners would say is its primary purpose. Express thatgoal 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 conditionrequired for the goal to be realized. There should be no more than 3-5 CSF. They’re the high-level“show-stoppers” without which the goal can’t be attained. Express these as conditions or outcomeson Post-it® notes.

4. Determine the key necessary conditions (NC) needed to realize the CSF. These are supportingcomponents of each CSF, the “discrete building blocks” or intermediate milestones without whicheach CSF can’t be realized. They’re likely to be functional in nature. For the purpose of constructinga CRT, there’s no need to build down more than one layer below the CSF. Express the NCs in con-cise phrases on Post-it® notes.

5. Arrange these components of the IO Map on a large sheet of paper, or in a computer flow-charting program. Locate the goal at the top. Arrange the CSF horizontally below the goal. Placethe NCs below the CSF they support.

6. Connect the Goal, CSF, and NC. Use single arrows, without ellipses. Be alert for cross-connections.

Your initial arrangement of Post-it®notes should look something like Figure 11With the connecting arrows added, your IOMap should look like Figure 12. Notice thecross-connection between one of the neces-sary conditions and two of the critical suc-cess factors.

7. Verify each connection. Are the CSFreally critical to goal attainment, and arethere no more than about 3-5 of them? Arethe CSF exclusively high-level outcomes? Iseach CSF the LAST thing that must hap-pen before goal attainment (that is, a termi-nal condition)? Are all the NCs functionalcomponents of the CSF they support? Andfinally, have all cross-connections beenidentified?

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

Figure 11. Post-it Notes—Initial Arrangement


13

The final step is logical scrutiny. Lookfor missing elements at every level belowthe goal. Rearrange entities as required tominimize “cross-over” lines. And trim offany low-level entities that would be betteraddress in execution planning.

An Aid to Constructing the IO MapIf one is not sure where to start, and if

the company already has a mission, vision,or values statement of some kind, thesecan be of some help. Any company thatwent through the “TQM revolution” of the1980s and ‘90s probably has these some-where—gathering dust! There’s not enoughspace in this paper to go into how to con-vert mission, vision and/or values state-ments into an IO Map. That discussionmay be found in The Logical ThinkingProcess [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 mis-sion statement. Critical success factors might also lie in the mission statement, but they could alsobe embedded in vision or values statements. Necessary conditions are likely to be more difficult toelicit from a mission, vision, or values.

ConclusionThe IO Map represents a revolutionary improvement in the use of the Logical Thinking Proc-

ess. I provides the opportunity to create more robust Current Reality Trees and Evaporating Cloudsby ensuring that the focus of the LTP analysis remains always on the goal and critical success fac-tors of the larger system. For more information on the IO Map and other improvements to the LTPrefer to Dettmer, 2007.

ENDNOTES:1. Dettmer, H. William. The Logical Thinking Process: A Systems Approach to Complex ProblemSolving. 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.

Figure 12. Final IO Map Connections


Documents

“Constructing and Communicating Common Sense The ... · “Constructing and Communicating Common Sense™” The Intermediate Objectives Map ... “Constructing and Communicating