Uncovering Conflicts with a Current Reality Mind Map

One of the techniques introduced in Goldratt’s Thinking Process is constructing a Current Reality Tree (CRT), which shows how a goal depends on necessary requirements which may have their own prerequisites. As an example, consider the following (simplified) CRT for profitable products:

Since we’re using a mind map as a drawing tool, the usual CRT arrows are missing, but the interpretation is the same: child nodes are conditions that if met then result in the parent node. For example, if our “design is flexible” and we have “rapid customer feedback” then we will achieve “fast time-to-market”.  A full-blown analysis would, no doubt, have other necessary requirements (like “good execution”).

In the above example the contradiction of a flexible and frozen design is highlighted. This is a source of conflict that can impede progress towards the goal.

Check Your Premises

The next step is to extract the Evaporating Cloud and list the underlying assumptions. The contradiction exists because at least one of the assumptions is wrong.

Here’s the new mind map:

Some further thought will uncover more assumptions, but all we need now is to find a few bad ones. Some questionable assumptions are:

• “Changing designs cause havoc in the supply chain”- What’s missing that can alleviate this problem?
• “Need to scale the supply chain now”- Really? Are we sure we have a product customers want?

Inject New Requirements

The above questions lead to adding (“injecting” in TOC-speak) two new requirements to fix the bad assumptions:

• Supply chain disruption can be minimized with a good change control process that clarifies effective dates, disposition of inventory, and build schedules.
• Don’t scale the supply chain until the demand for the product is validated

Once these requirements have been added, you should go back a see if they create any new conflicts that need resolving.

But That Was Obvious, Right?

Well, maybe- but notice that many organizations have exactly this conflict of missions between product development (want maximum variation) and manufacturing (want no variation). If even this simplified example raised this, there is plenty of room for (continuous) improvement in real life!

I’m interested to see any applications you may care to share…

This two part post explores resolving conflict that impedes progress. We’ll use mind maps to diagram the Evaporating Cloud technique introduced by Eliyahu Goldratt as part of his Thinking Process in the Theory of Constraints. Part I will give an overview of the technique, which will then be applied to an example in Part II.

The Necessary Requirements to Reach a Goal

Let’s use a mind map to show the requirements that are necessary to achieve a goal (keeping the descriptions generic for the purpose of overiew only):

These are necessary requirements, meaning that all must be present to achieve the goal. Each of these requirements will typically have their own requirements, cascading down the tree structure to the preconditions at the end of each branch.

Sources of Conflict That Prevent Progress

When constructing a diagram showing the hierarchy of requirements needed to achieve a goal, you may find that some of the preconditions are in conflict with each other (as indicated by the red arrow between Preconditions 1.1.2 and 3.2):

For example, your goal might have a precondition that requires buying an expensive piece of equipment while another precondition requires minimizing spending. These kinds of conflicts cause a ‘friction’ in the system that slows (or even stops) progress towards the goal.

The Conflict Resolution Diagram (Evaporating Cloud)

For the purpose of resolving the apparent conflict, the above diagram can be simplified to show just the key elements in what is called a Conflict Resolution Diagram (or Evaporating Cloud):

Since Requirements 1.1 and 3 are assumed necessary, the contradiction or conflict rests between Preconditions 1.1.2 and 3.2. Note that each connecting line in the diagram implies a number of assumptions, like Precondition 1.1.2 is necessary for Requirement 1.1. Echoing the Ayn Rand quote above, Goldratt maintains that the problem is not the conflict or contradition, but actually due to bad underlying assumptions. Once the bad assumptions are invalidated, the conflict evaporates like a dark cloud (hence Evaporating Cloud).

Challenging Assumptions

The first step is to make the assumptions explicit by listing them:

Each of these assumptions then needs to be reviewed to see if it is really valid. Suppose Assumption 8 is found to be invalid. This usually leads to some ideas about the actual precondition needed. This new precondition is called an Injection by Goldratt, as depicted below:

Note that Precondition 3.2 can now be removed from the original diagram of the goal and replaced by the Injection. Most importantly, note that the red arrow depicting the conflict has been removed, indicating a self-consistent system of requirements necessary to achieve a goal:

The discussion to this point has focused on an overview of the mechanics involved in creating and solving a Conflict Resolution Diagram- admittedly a bit dry (unless the logic stirs your inner Vulcan).  So Part II will walk through an example.

Because Ishikawa diagrams are hierarchial, they are well-suited for capturing in a mindmap. In fact, it is easier to draw and manipulate the relationships with a mindmap than applications like MS PowerPoint. More importantly, mindmaps can provide a better tool for reviewing and documenting progress towards proving which branch is the real root cause of a problem (or effect). In addition, you can use tools like FreeMind|GTD to follow-up on the next actions to validate potential root causes.

Building a Diagram

Start by brainstorming possible causes for the problem along with possible categories (the main bones). Depending on the problem domain, the top level causes may differ. The diagram below uses the ’6M’ template (often useful for business problems): Method, Man, Management, Measurement, Material, and Machine.

Ishikawa diagram

Under each major cause, add the next level of categories until you have homes for the potential root causes you have brainstormed. Notice that your brainstorming starts at the ‘leaf’ end of the hierarchy (bottoms-up) while the Ishikawa diagram builds branches from the problem statement (top-down). The structure of the diagram gives both a stimulus for new ideas and places to collect them.

For complex problems, Ishikawa diagrams can get large as bones are added. If you use a whiteboard for initial brainstorming, take a picture with your phone to help document the work and later recapture it in an application. Better still…

Mindmap Instead

Here is the same example captured in a FreeMind mindmap:

There are a number of advantages to capturing an Ishikawa diagram this way:

• More readable end product
• Can be captured while brainstorming (only do this if you are very comfortable with FreeMind and can move quickly; nothing kills brainstorming like waiting for someone to figure out how to use software…)
• Folding of nodes can be used to focus on a particular category and drive deeper

In addition to these ‘format’ related advantages, there are some really important operational advantages to using a mindmap when meeting with your team to discuss investigations and next steps. For example, focusing on the ‘Man’ branch (click on picture to enlarge):

The team has added two potential root causes to the diagram, along with some related Next Actions (indicated by the * symbol) assigned to some resources (indicated by the @ symbol). This is the notation used by FreeMind|GTD to generate a GTD-style list of Next Actions, which is ideal for using in the team meeting:

After the action items were carried out, the team found these were not valid root causes. Here is where the flexibility of a mindmap is useful; the conclusions and data are documented right in the diagram. Also notice that the just these causes have been closed for investigation. If further brainstorming comes up with a training issue, it can be added to this active branch.

Conclusion

Mindmaps can really extend the usefulness of Ishikawa diagrams in both capturing ideas and following-up and documenting the results. Give them a try!