How to identify the constraint of a system? Part 3

Inventories and Work In Progress (WIP) can be helpful clues to visually identify the bottleneck or constraint in a process, but they can also be insufficient or even misleading as I explained in part 2 of this series.

It is often also necessary to study material and parts routes to really understand where they get stuck and delayed. Chances are that the missing or delayed items are waiting in a queue in front of the constraint. Or have been stolen by another process…

In the search for the system’s constraint, experienced practitioners can somewhat “cut corners” by first identifying the organization’s typology among the 3 generic ones: V, A or T. Each category has a specific structure and a particular set of problems. Being aware of the specific problems and possible remedies for each of the V, A and T categories may speed up the identification of the constraint and improvement of Throughput.

V, A & T in a nutshell

Umble and Srikanth, in their “Synchronous Manufacturing: Principles for World Class Excellence”, published 1990 by Spectrum Pub Co (and still sold today), propose 3 categories of plants based on their “dominant resource/product interactions”. Those 3 categories are called V, A and T.

V, A & T plants

V, A & T plants

Each letter stands for a specific category of organization (factories, in Umble’s and Skrikanth’s book) where the raw materials are supplied mainly at the bottom of the letter and the final products delivered at the top of the letter.

V-plants

V type plants use few or unique raw material processed to make a large variety of products. V-plants have divergence points where a single product/material is transformed in several distinct products. V-plants are usually highly specialized and use capital-intensive equipment.

V-plant

V-plant

You may imagine a furniture factory transforming logs of wood into various types of furniture, food industry transforming milk in various dairy products or a steel mill supplying a large variety of steel products, etc.

The common problems in V-plants are misallocation of material and/or overproduction.

As the products, once gone through a transformation cannot be un-made (impossible to un-coock a product to regain the ingredients), thus if material is misallocated, the time to get the expected product is extended until a new batch is produced.

The misallocated products wait somewhere in the process to meet a future order requiring them or are processed to finished goods and sit in final goods inventory.

The transformation process usually uses huge equipment, not very flexible and running more efficiently with big batches. Going for local optimization (Economic Order Quantity (EOQ) for example) regardless of real orders leads to long lead times and overproduction.

V-plants often have a lot of inventories and poor customer service, especially with regards to On-Time Delivery. A commonly heard complaint is “so many shortages despite so many inventories”.

Misallocations and overproduction before the bottleneck will burden the bottleneck even more. Sales wanting to serve their upset customers often force unplanned production changes, which leads to chaos in planning and amplification of delays (and of the mess).

Identification of the bottleneck should be possible visually: Work In Progress should pile up before the bottleneck while process steps after the bottleneck are idle waiting for material to process.

Note: while the bottleneck is probably a physical resource in a transformation process, the constraint might be a policy, like imposing minimum batch sizes for instance.

A-plants

A-plants use a large variety of materials / parts / equipment (purchased and) being processed in distinct streams until sub-assembly or final assembly, that make few or a unique product: shipbuilding or motor manufacturing, for example.

A-plant

A-plant

Subassembly or final assembly is often waiting for parts or subassemblies because insuring synchronization of all necessary parts for assembly is difficult. Expediters are sent hunting down the missing parts.

Expediting is likely to disrupt the schedule on a machine, a production line, etc. If the wanted part is pushed through the process, it is at the expense of other parts that will be late. The same will repeat as the chaos gets worse.

In order to keep the subassembly and assembly busy, planning is changed according to the available kits. Therefore some orders are completed ahead of time while others are delayed.

The search for the bottleneck(s) starts from subassembly or final assembly based on an analysis of the delays and earlies. Parts and subassemblies that are used in late as well as in early assemblies are not going through the bottleneck. Only parts constantly late will lead to the bottleneck. For those, follows the upstream trail until finding the faulty resources where the queue accumulates.

T-plants

T type factories have a relatively common base, usually fabrication or assembly of subassemblies and a late customization / variant assembly ending in a large display of finished goods. Subassemblies are made to stock, based on forecasts while final assembly is made to order and in a lesser extend made to stock. In this latter case it’s to keep the system busy even there are no sufficient orders. Assembly is made to stock for the top-selling models.

T-plant

T-plant

Computers assembled on-demand for instance use a limited number of components, but their combinations allow a large choice of final goods.

In order to swiftly respond to demand, final assembly generally has excess capacity, therefore the bottleneck is more likely to be found in the lower part – subassemblies – of the T.

The top and bottom of the T-plants are connected via inventories acting as synchronization buffers. The identification of the bottleneck(s) starts at the final assembly with the list of shortages and delayed products. The components or subassemblies with chronic shortages or long delays point to a specific process. The faulty process must then be visited until finding the bottleneck.

Yet bear in mind that assembly cells, lines or shops may “steal” necessary parts or components from others or “cannibalize” i.e. remove parts or subsystems on some products for completing the assembly of others. If this happens, following the trail of missing and delayed parts upstreams can get tricky.

Combinations of V, A and T plants

V, A & T-plants are basic building blocks that can also be combined for more sophisticated categories. For instance a A base with a T on top, typical for consumer electronics. Yet the symptoms and remedies remain the same in each V, A & T category, combined or not.

Wrapping up

As we have seen so far along the 3 parts of this series, the search for the constraint in a system is more an investigation testing several assumption and checking facts before closing in on the culprit.

There are some general rules investigators can follow, like the search for large inventories in front of a resource while the downstream process is depleted of parts or material, but it is not always that obvious.

Knowledge about the V, A & T-plants can also help, without saving the pain of the investigation. And we are still not done in the search for the constraint! There is more to learn in the part 4!

Readers may be somewhat puzzled by my alternate use of the name bottleneck and constraint despite the clear distinction that is to be made between the two. This is because in the investigation stage, it’s not clear if the bottleneck is really the system’s constraint. Therefore, once identified, the critical resource is first qualified as a bottleneck and further investigations will decide if it qualifies for being the system constraint or not.

Bibliography about V, A & T-plants

For more information about V, A and T plants:

  • Try a query on “VAT plants” on the Internet
  • “Synchronous Manufacturing: Principles for World Class Excellence”, Umble and Srikanth, Spectrum Pub Co
  • “Theory of Constraints Handbook”, Cox and Schleier, Mc Graw Hill

View Christian HOHMANN's profile on LinkedIn

Advertisements

Goal Tree Chronicles – Enablers vs.triggers

In this post I explain the difference between enablers and triggers in logic trees, which basically is explaining how Necessity logic differs from Sufficiency logic. I then explain the basic assumption when building a Goal Tree and why the Goal will not automatically be achieved even if a most of Necessary Conditions are fulfilled.

Necessity vs. sufficiency

Necessity-based logic requires a prerequisite to be fulfilled in order to produce the expected effect. This is why necessity-based logic uses “in order to… [effect] we must … [prerequisite]” wording in the Logical Thinking Process.

Example: in order to have my hair cut, I must go to the hairdresser.

Even so there are alternatives to the hairdresser to have the hair cut, a prerequisite is necessary for the hair being cut.

Sufficiency, as its name suggests, does only require the cause to exist for the effect to automatically exist. The corresponding wording is ”if…[cause] then.. [effect].”

Example: if it rains, then the lawn gets wet. Or if I drop an ice-cube in hot water (the) it melts. In these examples there is little that can be done to prevent the effect to automatically happen when the cause happens.

Enablers vs.triggers

I assume dear readers, you understand the huge difference between Necessity and Sufficiency. While an effect will automatically happen if the cause exists in the case of sufficiency, the existence of the prerequisite (cause) in necessity-based logic is not enough to produce the effect, it only enables it.

For example, many prerequisites are necessary to build a house, like having a ground, having timber, having a permit, and so on. But having all prerequisite will not lead the house to build itself.

In sufficiency logic, the cause is the trigger while with necessity logic, the cause is “only” an enabler.

The Goal Tree is built on necessity-logic

The Goal Tree, one of my favorite logic tools, is built on layers of Necessary Conditions, linked from the Goal on the top to the very first Necessary Conditions at the bottom by necessity-logic. The convenient way to build a Goal Tree and scrutinize it is to check the sound logical relationship between an entity and the underlying Necessary Condition using the “in order to… [effect] we must … [prerequisite]” phrasing.

The logic trees and cloud from the Logical Thinking Process are either necessity-based or sufficiency-based and in the order of their sequential usage they alternate between necessity and sufficiency.

Now because the Goal Tree is built on necessity logic, the entities composing it are absolutely necessary to exist or being granted for to achieve the Goal. By definition, if one Necessary Condition is not fulfilled, the Goal cannot be achieved.

But, as Necessary Conditions are “only” enablers, nothing will happen as long as no real action is taken.

Achieving the Goal

Achieving the Goal requires all Necessary Conditions or enabling prerequisites to be fulfilled, but it is not sufficient.

This can be disturbing for those being exposed first time to the Goal Tree, because there is an implicit assumption that when the enablers are in place, the necessary actions or decisions will be taken, so that from bottom to top, all Necessary Conditions are fulfilled and the Goal eventually achieved.

Promoters, including me, tend to cut corners and advertise about the lower level Necessary Conditions “automatically” turn the upper ones to be fulfilled, and the achievement of intermediate objectives to happen like a row of dominoes propagating the fall of the first one till the very last: the system’s goal.

This is true if people in charge do their part: take the decisions and/or carry out the tasks.

This is why, “surprisingly”, some entities can be Amber or Red (condition not always / not fulfilled) even so their underlying Necessary Conditions are Green (condition always fulfilled).

If you are not yet familiar with my 3-color system, I suggest you read: 3-color system for Goal Trees

Example

Here is such an example. It comes from an operational Goal Tree built to enumerate all Necessary Conditions to pass over simple maintenance tasks from maintenance technicians to line operators. The simple tasks include daily lubrication and check of tightenings in order to prevent wear and possible breakdowns. The aim is to implement the Total Productive Maintenance ‘Autonomous Maintenance‘ pillar.

Once all Necessary Conditions are listed, the Goal Tree is scrutinized for robustness and if ok, it becomes the benchmark to achieve the Goal. The next step is to assess each Necessary Conditions for its status.


We see in the figure above (showing only a tiny part of the Goal Tree) that all underlying Necessary Conditions to “Daily lubrication / tightening is done” are Green, but the expected outcome, the effect is Amber. Since every prerequisite is Green, we expect the effect to be Green as well. Amber means the outcome is not stable, not always guaranteed, not steadily at nominal level.

It means this expected outcome, the task “daily lubrication / tightening is done”  is NOT done EVERY day.

One may argue that we cannot see any mention of the lubrication / tightening being part of operators’ duties. That’s correct. The reason for this is that in logic trees, obvious prerequisites or assumptions are voluntarily omitted for the sake of keeping the logic trees simple and legible. In our case, the work instructions include the daily lubrication and tightening routine. This is a known fact for everyone concerned with this Goal Tree.

In other words, enablers are ok, but the trigger is still missing.

It is now up to management to:

  • make sure operators have a full understanding of the work instructions,
  • make sure these tasks are carried out and
  • clarify what is to be done if operators face a dilemma like catch up late work or go as planned for maintenance routine.

Fortunately those cases are the exception. People truly involved in a project and having a clear understanding of the purpose will contribute. That is, as long as they are not exposed to undesirable effects, from their point of view.


View Christian HOHMANN's profile on LinkedIn

How to identify the constraint of a system? Part 2

When trying to find the system’s constraint, why not simply asking the middle management? At least when Theory of Constraint was young, our world spinning slower and processes simpler, the foremen usually had a common sense understanding of their bottleneck. They knew what machine to look after, and what part of their process to give more attention.

If you haven’t read part 1, catch up: How to identify the constraint of a system? Part 1

Even so they may not have discovered all 9 rules about managing a bottleneck by themselves, they intuitively applied some of them.

Nowadays the picture is blurred with complexity and frequent changes. Nevertheless, asking middle management can still give precious hints about bottlenecks. Ask what the more troublesome spot of the process is and from where / whom the downstream process steps are waiting for something. Chances are that many managers will point to the same direction.

This works for project management or (software) development as well. In those cases I would also ask who the superstar (programmer) is, the one everyone wants on his/her project and in every meeting. Chances are that that person turned into a constraint without even noticing it.

Now if the tip can be useful, refrain from rushing to conclusions from these answers and check for yourself. Many managers may tell you the same just because they all heard the same complaints in a meeting. A meeting where all managers meet…

Go to the gemba, look for Work In Progress

Let’s start the shop floor investigation searching for the bottleneck like it is described in the early text books.

Go to the gemba, follow the flow (which is easier and somewhat more natural than walking upstreams, but up to you to choose the preferred way) visually assess the work in progress (WIP) and inventories in front of the machines or work cells.

Usually the highest piles of Inventories or work in progress are sitting in front of the bottleneck and the following downstream process steps are starved from material or parts.

Yet if it would be that easy it would be no fun. The above works well in simple processes which are neat and tidy. Most often the inventories are scattered wherever it is possible to store something, FIFO (First In First Out) rules are violated and downstream processes, incentivized on productivity, work on whatever they can work on for the sake of good looking KPIs. Finding the bottleneck in such a chaos needs more than a visual check.

It is also possible that excess inventory and work in progress may be temporarily stored in remote warehouses and not in full sight, thus not visible.

Another pitfall is confusing work waves, periodically releasing parts or information, and real bottlenecks. An example could be a slow process which is not a true bottleneck but needs more than the regular shifts to catch up with its workload.

Imagine a slow machine (sM) amidst a process. The process upstream (P1) works 8 hours with best possible productivity and WIP piles up in front of sM. The downstream process (P2) works at best possible productivity and has some WIP in front of it.

At the end of the shift P1 and P2 are shut down. They both fulfilled their daily scheduled work. sM goes on for a second shift, processing the WIP in front of it.

By the end of the second shift, no more WIP (or very few) in front of sM and what was waiting in front of sM is now waiting after it, in front of P2. This is the picture the next early morning:

An observer, depending when he/she looked at the process, could have come to wrong conclusions about a bottleneck. Early morning it looks like the first machine of P2 is holding back the flow. In mid afternoon it is sM that is the culprit, when in reality there is no true bottleneck. sM has enough capacity provided it can work more than one shift.

Some would mention wandering bottlenecks, jumping from one place to another. This is something I will elaborate on in a separate post. Or series…

We are not done now with our bottleneck safari. To learn more, proceed to part 3.


View Christian HOHMANN's profile on LinkedIn

How to identify the constraint of a system? Part 1

A very common question once people get familiar with Theory of Constraints and the notion of bottlenecks and constraints is how to find them in a process. Identifying the constraint is key as the constraint, by its nature, controls the performance of the whole system.

The trouble with examples given in textbooks or case studies is that they are rather simple compared to finding the constraint in real life. This difficulty grew over time as processes got more complex, adding new layers of rules, standards and regulations. This complexity grew to an extend that many constraints remain elusive to people searching them, leading many people to be wrong when identifying “their” constraint.

Facing this kind of difficulties, readers asked me if a formal procedure to identify the constraint exists. I am not aware of such a procedure and from my experience the search for the constraint is much more like a detective’s job requiring investigation skills than applying a recipe. Some common patterns and similarities may exist, but every organization has some specificities that make the search for the constraint a special case. Therefore intuition and experience are definitely of great help.

In this series of post, I propose to review such investigations, that may help readers to transpose in their own situation, and eventually try to wrap up guidelines to identify constraints.

The usual suspects

First let’s review common bottleneck resources, keeping in mind that being a bottleneck is not synonymous of being a constraint and, as a general rule, a constraint is (and should be) a resource too long or too expensive to get more of it, or put differently turn it in a non-constraint.

A constraint was long said to be a very expensive piece of machinery or equipment which is too expensive as an investment to afford another one for additional capacity or which is not currently available.

Big stamping machines or presses, painting booth, heat treatment, surface treatment or sophisticated machine tools made good candidates for being bottlenecks and ultimately constraints.

Bad news is that things evolved, as we will see, and even if those bulky expensive or scarce equipment still make good candidates for the constraint status, they are not always the constraint.

For instance, I worked in a engineer-to-order company designing and manufacturing heavy mechanical equipment. The heat treatment was said to be the constraint and was managed by-the-book as a constraint.

After a short diagnostic, it turned out that heat treatment was not the constraint. It wasn’t because the true constraint was elsewhere in the process and those heat treatment operations could be subcontracted nearby at short notice and reasonable price. The subcontracting gave sprint capacity and provided relief whenever necessary. So heat treatment, even with long cycle times, was nothing really scarce nor excessively expensive.

Why was the heat treatment mistakenly thought to be the constraint? Because literature on the subject point this kind of process as usually being a bottleneck (remember: not enough capacity with regard to average demand placed on it). If indeed the workload often exceeded the capacity, the heat treatment was not the constraint. Failing to understand the difference between bottleneck and constraint led to a wrong conclusion.

Where was the real constraint? In engineering department where equipment are designed: people with specific skills that are long to learn.

More usual suspects

Very slow processes are usually also good candidates as bottlenecks: drying, curing, maturation, chemical or biological reactions, etc.

People with specific skills (as we have seen), knowledge, abilities, expertise, etc. that cannot easily be hired can also become constraints. So are some raw materials that are rare or dependent on harvest, climate, embargo, shortage, etc.

In some areas it is difficult to find some qualified workforce like welders, forklift drivers or specialists in some trade, which makes them constraints even so their profession is not so scarce at a larger scale.

When the constraint is not obvious nor easy to find, its identification becomes a matter of investigation. Investigation will start in part 2.


About the author, Chris HOHMANN

About the author, Chris HOHMANN

View Christian HOHMANN's profile on LinkedIn

Industry 4.0 promoter’s flaw of logic and Categories of Legitimate Reservation

Promoters of any solution or change agents of are usually in love with the object of their promotion. Love is said to be blind and oblivious of any negative aspect of the loved thing. That is why so often promoters of change highlight all the benefits of the change, regardless of any Undesirable side Effects for the people they try to convince to change. They usually also complain about resistance to change when skeptic listeners do not show enthusiasm for the promoted brilliant solution.

But promoters may also forget to adapt their communication to the targeted audience. They may know well their subject and cut corners, leaving the audience with doubts and questions about a logic they can’t completely follow.

In this post I will address:

For that I pick two sentences from an Industry 4.0 promoter’s blog post which does not seem logically sound.

The statement

“Brave companies who adopt new approaches (e.i. Industry 4.0) and adapt how they manufacture and run their businesses will be rewarded with success. While those who drag their feet and avoid risk will get left behind.”

There is no further explanation in the blog to backup these two sentences.

The first sentence, rephrased in logical cause-and-relationship reads: “if companies adopt new approaches (e.i. Industry 4.0) AND if companies adapt how they manufacture and run their businesses THEN companies will be rewarded by success.”

The AND here suggest that the two conditions must be fulfilled simultaneously in order to cause the success.

Necessity-based logic versus sufficiency-based logic

The statement is made with sufficiency-based logic, because it suggest that the adoption of new approaches and adaptation are sufficient to cause the companies to be successful.

Sufficiency is base on “if…then” or cause-and-effect relationship.

If the article was about listing all the conditions necessary to make the companies successful, it would have been necessity-based logic. In this case the relationship would have been: “in order to… the companies must…”.

The logical structure that Logical Thinking Process aware people “see” in the statement is either a Communication Current Reality Tree or a Future Reality Tree.

To learn more about necessity-based logic versus sufficiency-based logic, check my post: Goal Tree Chronicles – Enablers vs.triggers

Reservations

1 – Clarity

The first reservation about this statement is a clarity reservation about the meaning of “success”. What is “success”? How can we measure it? How can we know whether the company is “successful” or not?

Unfortunately there is no way to ask the author for clarification. One could understand that deployment of industry 4.0 technologie(s) together with adaptation of the work procedures is a success. A project manager in charge of such a program would surely agree about this definition of success.

The CEO and the board are probably looking for more than having the latest technologies installed, even it probably helps the image of the company to have a nice techno-showcase. In their view, success is more likely increase of sales, profit and market share. Let’s assume this one is meant by “success”.

We could go on and challenge the meaning of “new approaches”, “industry 4.0” or even what is exactly meant by “how they manufacture”. In case someone really need clarification, the question could be raised, otherwise let’s not go for unnecessary wordsmithing.

2 – Entity existence

An entity in the Logical Thinking Process parlance is a statement that conveys an idea. An entity is also the logical box holding the statement in the various logic trees.

An entity must only convey a single idea, therefore when building a logic tree on this statement we must have 3 entities combining their effects to produce one outcome: the success of the companies (read figure from bottom to top).

3 – Causality existence

Causality existence is checking the existence of the causal connection between entities.

“if companies adopt Industry 4.0 AND if companies adapt how they manufacture AND if companies adapt how they run their businesses THEN companies will be rewarded by success.”

Does it exist? One example would be enough to demonstrate it exists, but, in absence of hard evidence, the likeliness of the causality existence must be evaluated. We assume it’s ok.

4 – Cause sufficiency

Are the 3 proposed causes sufficient alone to produce the effect “successful companies”? I would intuitively say no. There is a lot more necessary. We are here facing a typical “long arrow” which is a leap of logic from some causes directly to the outcome, ignoring intermediate steps and conditions in between.

This is typical when people discuss matters they know well because they don’t have to detail everything, they know what is missing and is implicit. But here it is about promoting something which is quite new (in 2017), relatively complicated and not very well known by laymen. Effort should be paid to elaborate on the message in order to favor buy-in.

5 – Additional cause

This check is looking for other causes that can independently produce the same effect. There are indeed other ways for companies to be successful than going for industry 4.0, but the statement suggests there is only one, as it warns: “those who drag their feet and avoid risk will get left behind.”

Conclusion

With these two last reservations we uncover the major flaw in the statement:

  • The proposed “logic” is not likely to be enough to produce the expected effect
  • There are other ways to be successful

From the audience point of view, the argumentation is weak. This is more likely to raise suspicion about the promoter’s expertise and trustworthiness, thus distrust and reservation than frantic enthusiasm about the proposed idea.

Such a weak argumentation can have devastating effects, making decision makers to turn their backs, refusing a good plan or a clever strategy which was ill-prepared and badly presented.

The Categories of Legitimate Reservation are 8 formal “rules” or “tests” used to check the logical soundness of a reasoning or an argumentation. They are part of the Logical Thinking Process corpus.


View Christian HOHMANN's profile on LinkedIn

Reader question: Goal Tree vs. Current Reality Tree

Here is a reader’s question: I have difficulty seeing the difference between the Goal Tree and the  Current Reality Tree (CRT). With these two trees we assess the process. What are the main differences between the two?

The Goal Tree and Current Reality Tree (CRT) have nothing in common. They are not even meant to care about processes but about the system as a whole. Neither the Goal Tree nor the CRT are process maps.

>Lisez-moi en français

A Goal Tree lists all Necessary Conditions to achieve a Goal, which is not yet achieved, so it is about the future.

The CRT describes why the Goal is not yet achieved in the current state. It starts with identified Undesirable Effects (undesirable for the system as a whole) and drills down to the few critical root causes.

A Goal Tree is built from top-to-bottom with necessity logic while the Current Reality Tree (CRT) is built from top-to-bottom using sufficiency logic. This building top-to-bottom is maybe the sole commonality between the two.

To learn more about the differences between necessity and sufficiency logic, check out my post: Goal Tree Chronicles – Enablers vs.triggers

The name Current Reality Tree is somewhat misleading because the CRT is limited to the description of the negative outcomes. It does not describe all the Current Reality. This is saving a lot of unnecessary analysis as well as a warning to not mess with what is currently producing Desired Effects!

What could have caused some confusion to my reader is the fact that a Goal Tree is a benchmark against which to measure the gaps in current reality.

When doing this I use a 3-color code to indicate each Necessary Conditions status. I assess the current condition of the system with the Goal Tree as benchmark. The first autumnal-colored tree should be kept as is as a snapshot of the situation at the beginning. Distinct trees are used later to monitor the progress of ‘greening’ the tree, i.e. closing the gaps to achieve the Goal.

I hope this helps to understand the differences between a Goal Tree and a Current Reality Tree.

View Christian HOHMANN's profile on LinkedIn

Scrutinizing and improving a Current Reality Tree (video tutorial)

In this video, I scrutinize and suggest improvements on a Current Reality Tree (CRT) found on the Internet. A logically sound CRT is key to convince audience about the robustness of the analysis and the reality of the causes to the trouble. If there is room for doubt or the logical has flaws, chances are that the audience will not buy-in, especially those having some “skin in the game”…


View Christian HOHMANN's profile on LinkedIn

Beware of the Logical Thinking Process apparent simplicity

It happens often with methods and tools that look simple: people giving it a try think they master the subject when in reality they more or less failed with their trial. It is not different with the Logical Thinking Process.

The Current Reality Tree is maybe one of the logic trees the most attractive to rookies. The classic Theory of Constraints’ Thinking Processes as well as Bill Dettmer’s Logical Thinking Process propose a structured and step-by-step approach to go from gathering “undesirable effects” or UDEs to revealing the root causes via a Current Reality Tree (CRT).

Even so the two approaches have slight differences, they follow the same construction and analysis pattern and both the stress the need to build the CRT with the mandatory logical soundness. Therefore there are rules to follow as well as a check process called the Categories of Legitimate Reservations (CLR).

Alas, what most people recall is that the Current Reality Tree is built by connecting UDEs with cause-and-effect sufficiency logic relations using a simple if…then… verbalization. Then, look at the bottom of the tree and somewhere there lies the mother cause of all evil. Kill this root cause and the whole tree of negative consequences will collapse. Tada, job done.

The apparent simplicity of building a CRT and some overconfidence, mixed with the laziness to go through thorough checking ends up with disappointing trees which are not logically robust.

Besides the risk of failing to find the right causes to problems and consequently proposing inappropriate solutions, the analysts may be taken by surprise by someone listening to their brilliant demonstration and pointing out flaws of logic. Embarrassing.

This can be devastating, because even if the analysis is ultimately leading to the real core problems, the doubts raised during a flawed presentation may end up in disbelief or rejection of the conclusions.

As Bill Dettmer warns in his personal style at the end of his 6-day intensive Logical Thinking Process Training Course, “You are now armed and dangerous”. In essence he gave the participants potent weapons, but their lack of practice may lead them to shoot themselves in the leg.

Well, considering my own scars, I can only agree.


View Christian HOHMANN's profile on LinkedIn