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

Advertisements

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

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

Why would I learn to think (logically)?

Most people are convinced of their ability to think logically and don’t see the point of getting a specific training like the Logical Thinking Process  training course.

Indeed, in some extend most of the people have an innate basic logical thinking way, otherwise our world would be pretty weird.

Yet it is also true that many people are unable to structure properly their thoughts and express their ideas with clarity and in a straightforward brilliant logical way. Even so it makes sense in their mind, what they try to share doesn’t always make sense to others.

How many times did you listen to someone and ask (yourself) “so what?” once the speech is over.

The importance of clarity

The first important thing to achieve is to express ideas with clarity. Clarity means that the idea, purpose, objective or goal is expressed in an unambiguous way, letting no room for misunderstanding or interpretation.

Clarity is always important. As an employee to be correctly understood by managers and colleagues and as a leader to be correctly understood by the team members or subordinates.

Imagine the consequences of an ill-stated objective. Stakeholders may misunderstand it and do something unexpected but aligned onto the objective they understood. Such kind of situation can be costly in terms of motivation – the stakeholders are feeling bad about their misunderstanding, resenting their leader for his/her poor objective statement and disappointed for all the energy they put into some action, for nothing – and in terms of resources and time wasted.

Ambiguous or ill-stated objectives are also welcome for some people to smartly escape some chores or refrain to commit to something they don’t agree, don’t want or don’t like. Room for interpretation is also room for later arguing. Something not desirable when some objectives are non negotiable.

Conversely, the inability to clearly explain what has been achieved, why and how it contributes to achieving some objective may make a team member look as a poor performer even so his/her contribution was significant.

It is frustrating to be a brilliant contributor to some project but unable to explain why and how. It is also frustrating to be unable to “sell” a brilliant idea to colleagues, the boss or customers.

Sound logic

The robustness of a cause-and-effect analysis or demonstration is also important in order to convince readers or listeners about the soundness of the ideas expressed.

According to the principles of adult learning, sense and purpose must be fully understood for adults to commit to something. If the rationale of some project or actions asked is not demonstrated in a clear and sound (robust) way, it will invite opponents to fight against it, making use of all “holes”.

Some undertaking presented in a fluffy way with many unanswered questions remaining open is scary. Opponents will have it easy to reinforce the doubts and fears of the audience by pointing out the inconsistencies and “holes” in the reasoning.

Lack of confidence is very likely to turn away customers, stakeholders or decision makers from the best of proposal. Instinctive risk aversion is probably more common than innate logical thinking.

Using “long arrows”

Many people with good logical thinking abilities will mentally cut corners and use “long arrows” in their demonstration. A long arrow is a metaphor for skipping several cause-and-effect steps linking an effect to a cause or the other way round.

While the link exists, it does not appear clearly. The audience cannot understand the rational link between an effect and a cause and may lose trust or interest about the presentation, get stuck because of this logical “hole”, doubt about the reality and validity of the ideas expressed, and so on.

Long arrow example

I have to make a presentation in building n°10, 15 minutes walking from here. It rains. I need an umbrella. I must borrow one.

“Could I borrow your umbrella because I must present my report?” I ask a colleague.

My colleague may ask herself what the link is between presenting a report and her umbrella. She will probably lend me the umbrella anyway, still not understanding what for. I did not feel necessary to explain the whole sequence of cause-and-effect, perfectly clear and logical in my head but strange when expressed that way.

Now imagine asking for commitment to something very important and serious that does not make sense because of long arrows.

Mastering logical thinking is also about avoiding long arrows and being able to detect them. I guess someone trapped with long arrows would be grateful for the help by someone seeing the shortcut and helping to reformulate the idea in a more robust and clearer way.

Mitigate the risk of “negative branches”

Negative branch is another metaphor used in the Logical Thinking Process, were logical relationships are depicting in logical trees. A negative branch is an undesirable effect or chain of cause-and-effect that “grows” from an action or decision taken.

Negative branches are often growing unexpectedly because the action was decided or decision taken without checking the possibility for things to go in an unexpected and undesirable direction.

Some fixes for a problem can result in other problems to arise, sometimes worse than the initial problem that was to be fixed.

Awareness and practice of the Logical Thinking Process hones the ability to “foresee” or at least to prevent negative branches and craft better solutions.

Conclusion

Basic logical thinking is a given and it may appear strange to promote “learning to think logically”. But it is as with many other things supposed to be “common” but aren’t. Common sense for instance is not so common.

Therefore there is a lot of room to improve one’s logical thinking skills.

Once introduced to the Logical Thinking Process, there are daily opportunities to hone one’s scrutinizing abilities. Newspaper, tv news, blog posts, speeches… are not always constructed with sound logic. Fallacious reasoning is easier to debunk, as well as surfacing false assumptions or “insufficient causes” on which some thinking are built upon. Negative outcome can be sensed and hopefully prevented.

Mastering Logical Thinking helps for better analyzing situations, understanding real causes of problem, crafting better solutions and expressing oneself much better.

1View Christian HOHMANN's profile on LinkedIn

What is a critical root cause?

A root cause is the beginning of the cause-effect relationship*. Thus when working down the chain of causes and effects from a problem to its cause, a Root Cause Analysis (RCA) meets causes themselves being effects of some underlying causes and so on, down to the root cause from which everything about the problem originated.

According to wikipedia, a root cause “is an initiating cause of either a condition or a causal chain that leads to an outcome or effect of interest. Commonly, root cause is used to describe the depth in the causal chain where an intervention could reasonably be implemented to improve performance or prevent an undesirable outcome.” https://en.wikipedia.org/wiki/Root_cause

In “The Logical Thinking Process, A Systems Approach to Complex Problem Solving”, my mentor and friend Bill Dettmer defines a root cause as:

  • *The beginning of the cause-effect relationship
  • The lowest cause in the chain before passing outside the sphere of influence – the most basic thing one can do something about
  • The first cause beyond the sphere of influence, where someone can’t personally do anything about

In the context of the Logical Thinking Process (LTP) and more specifically when working with Current Reality Trees (CRT), a root cause is an entity with arrows coming out but no arrow going in. In this context a root cause is not necessarily something negative.

So far for the root cause, but what is a critical root cause?

Critical root cause

According to Dettmer, a root cause can be a historical event of the past or a fact of life nobody can do anything about. A root cause can also be out of the sphere of influence to change. Therefore, in order to solve problems and remove Undesirable Effects (UDEs), the problem solvers must search for critical root causes, which are defined as:

A policy, practice or prevalent behavior that constitute the lowest level of causality in existing reality lying within someone’s sphere of influence to change. (p108).


Bandeau_CH160601View Christian HOHMANN's profile on LinkedIn

Redefining “problem” (with Goal in mind)

In problem solving or continuous improvement workshops a problem is usually defined as a gap between the actual situation and the desired situation, and thus a problem causes an unsatisfactory situation or an UnDesirable Effect (UDE).

This definition, while true, is somewhat too vague to be useful when working on solving problems and continuous improvement.

Indeed, in a business environment* many things can be qualified “undesirable situation” or “undesirable effect”, from bad tasting coffee to important production equipment breakdown, from laser printer toner stockout to quality control rejecting an important production batch.

In most business environments improvement opportunities are literally infinite.

*business environment can be very vague as well, I suggest every reader to transpose this article into his/her environment.

From these few examples it becomes obvious that the too broad definition of problems need some refinement. The limited time and resources of an organization should not be wasted on every so-called problems, but instead solely focused on the critical ones.

Failing to do so bears the risk of spending time and burning up resources to solve “problems” without any system-wide noticeable positive effect. That’s what happens to so many Lean initiatives or continuous improvement programs, draining significant resources for frustrating results.

So, how to select the problems worth coping with?

In a business environment the organization exists to achieve a Goal, itself subordinated to the achievement of several objectives. When something hinders the organization to achieve its objectives, hence its Goal, the hinderance is worth attracting (all) focus for problem solving.

In “The Logical Thinking Process, a  Systems Approach to Complex Problem Solving”, Bill Dettmer defines a UDE as “something that really exists; something that is negative compared with the system’s goal, Critical Success Factors or Necessary Conditions.” This definition is linked to The Goal Tree and if this one is properly built, the understanding of what an UDE is will be straightforward and unquestioned.

Now with the organization’s Goal in mind, a “problem” can be understood as an UnDesirable Effect (UDE) being an obstacle for the organization to achieve its objectives, its Goal. Anything felt undesirable but not directly threatening the achievement of the objectives or Goal is an annoyance at best.

Does it mean anything NOT threatening the objectives and Goal is not worth considering?

While priority must clearly be given to issues and UDEs hindering the organization to achieve its Goal, some “annoyances” should be taken care of as well. Things making job or life easier for employees for instance may not directly contribute to corporate objective achievement but can help improve morale, ergonomics, safety and the feeling of being important enough to the organization to deserve some attention.

Well, how to select these “problems” worth considering?

This is where methodologies handover to management, “science” handover to “art” and plain rationality to humanity. It’s up to managers to sense what is to be done, why and to what extend.


Bandeau_CH160601View Christian HOHMANN's profile on LinkedIn

Is Lean about eliminating waste or not?

Some thought leaders and Lean promoters stress the fact that Lean is about eliminating waste while others seem to get away from this idea.

Could some have been wrong? Is there a shift in Lean Thinking? What is Lean finally about? Is Lean about waste elimination or not?

Well, yes and no.

Defining waste

Waste is an outcome of problems, the result of processes not delivering what is expected but Undesirable Effects instead. In order to avoid the same consequences occurring again in future, something has to be corrected and/or improved.

So when someone mentions eliminating waste, in a Lean Thinking context, it means (should mean) solving problems.

Lean for everyone

As Lean is a philosophy for everyone, not for experts only, it is necessary for people on the shopfloor, manning machines or doing routine administration tasks to develop and hone their Lean awareness and culture by eliminating waste and solving problems.

In order to do that, they have to be trained and coached to identify problems and learn how to solve them. They will do so in their familiar environment first and yes it can turn out as a kind of systematic waste hunting.

On the other end, senior management need to setup the “True North” a far away and visible reference, a Goal to achieve for the organization. It is then necessary to solve the various problems hindering the organization to achieve its Goal and improve the processes accordingly.

This again can be called waste hunting, yet it is (should be) focused onto most important problems (and wastes) standing in the way of the organization’s attempt to achieve its Goal.

Once the True North is defined, everyone is expected to align his/her contribution to the achievement of the organization’s Goal. This means pick and work on the problems necessary to be solved.

So Lean is about waste!?

A Lean transformation is not an all-out elimination of waste, but focusing limited resources on the most important leverage points to let value flow faster to the customer.

For instance, if a machine critical to timely deliver goods to the customer has very few spare capacity and often this capacity is wasted by some problems (e.g. late raw material supply or quality issues), then solving the problems in order to reduce the waste of capacity is meaningful.

If a machine in the same process has a lot of spare, unused capacity, it may be seen as a waste of capacity too, but it would only be counterproductive to reduce this waste by running the machine more than necessary. It would end up with overproduction of unecessary parts, excess inventory and transforming raw material that can no longer be used for producing anything else.

Lean is not about waste when it means optimizing every process step by eliminating waste, simply because the sum of the local optima cannot lead to the system optimum.

Wrapping up

When some Lean promoters state Lean is not about waste, they probably mean Lean is not solely about eliminating waste, as waste elimination is a means, not a goal.

Striving to eliminate all waste will not likely end up with a Lean organization.

Yet solving problems that hinder the organization to achieve its Goal is mandatory and as waste is the result of problems, Lean is about waste.

I hope this helps.

Readers are welcome to share their thoughts.


Bandeau_CH40_smlView Christian HOHMANN's profile on LinkedIn

What is an Executive Summary Tree?

An Executive Summary Tree is not another type of tree in the Thinking Processes tool box, but a concise, condensed form of a Current Reality Tree or Future Reality Tree for presentation to executives.

Bill Dettmer got used to make short, concise briefings to general officers in his career in the military. Their civilian counterparts, high-ranking executives and decision makers have no more time and patience, thus need brief presentations too.

Two trees in Thinking Process* are especially important: the Current Reality Tree and the Future Reality Tree. The first describes the links from Undesirable Effects (UDEs) or actual problems to their few root causes. The second depicts the Desirable Effects (DEs) and necessary injections to get there in future.

*When this term is singular, it refers to the process, when plural it refers to the tools (trees and cloud)

If the presentation is about the actual state, the Executive Summary Tree will be a condensed version of the Current Reality Tree. If the presentation is about where to go or what to change to, it is the Future Reality Tree which will be presented in this concise way.

The how-to is described by Bill Dettmer himself in this video.


Bandeau_CH36View Christian HOHMANN's profile on LinkedIn

Conflict Resolution Diagram / Evaporating Cloud

The Conflict Resolution Diagram (CRD), also known as Evaporating Cloud (EC) or simply ‘Cloud’, is a necessity-logic based tool from Theory of ConstraintsThinking Processes.

As the name tells, the Conflict Resolution Diagram is used to surface and resolve conflicts, e.g. dilemmas.

Conflicts, which can be named ‘different points of view’ are not always obvious, thus practitioners will refer to as ‘hidden conflicts’. Indication a hidden conflict exists is stagnation (Dettmer). Two opposite forces pull in opposite directions and nothing goes on.

The CRD is based on two assumptions:

  1. Conflicts (opposition about objectives or opposite points of view, for instance) tend to be settled by compromise. Yet compromising requires making concessions that lead to a solution which isn’t satisfactory for neither side, hence a win-lose or lose-lose situation.
  2. Conflicts are often the result of false assumptions, beliefs or myths which constrain needlessly the organization. As two opposite things cannot be true at the same time, one is necessarily false. If the falseness can be debunked, the conflict disappears (evaporates) and a no-compromise, win-win solution is found.

Resolving the conflict is done by first exposing the two sides’ arguments, second through “injection(s)”; adding something, solution, countermeasure, a “remedy” that didn’t exist in the system.

The structure of a Conflict Resolution Diagram / Evaporating Cloud

A (simple) CRD is made of five entities (round cornered boxes) conventionally named A,B,C,D and D’.

Entity A is the common objective which requires B and C to exist; in order to have A, we must have B and C.

D is a prerequisite to B (in order to have B, we must have D), while D’ is a prerequisite to C.

D and D’ cannot exist or happen simultaneously, like for example attend a meeting in Rome and in the same time attend a conference in Berlin. In this case the conflict would be a dilemma chosing between the two events. D and D’ may not happen simultaneously because available resources do not allow it and the dilemma is about allocation of the scarce resource.

Arrows are symbols of necessity relationship. In the same time the arrows are symbols for underlying assumptions, and as such can be true or false. But the assumptions are usually statements (beliefs) and/or justification for the relationship. The CRD’s purpose is to surface and test these assumptions.

The broken arrow or lightning between D and D’ is the symbol for opposition or conflict.

Surfacing and testing the underlying assumptions and injections

Once the CRD is drawn, participants are asked to verbalize all underlying assumptions under each arrow. If one of the assumption can be proven as false, it is probable that the problem evaporates (we do expect the defenders of the false assumption to give it up as false).

An assumption can also be invalidated by an injection, which are ideas or conditions that render one of the assumptions invalid.

Note: Dettmer recommends not to inject solutions in order not to constrain the injections with reservations about feasibility.


Conflict Resolution Diagram can be used as a stand-alone tool or sequentially after a Current Reality Tree (CRT). In this latter case, the analysis with the CRT helped discover the root cause of all Undesirable Effects (UDEs) usually called problems. This root cause is generally a conflict or dilemma the CRD can ‘evaporate’, thus solve the problems.

Solving a problem with a CRD is a bit more complex than in this brief description and requires some practice.

References

  • Fedurko, Jelena (2011) Behind the Cloud, enhancing logical thinking, TOC strategic solutions
  • Dettmer, H. W., (1997) Goldratt’s Theory of Constraints: a systems approach to continuous improvement. ASQC Quality Press
  • Scheinkopf, L., (1999) Thinking for a change: putting the TOC thinking processes to use. St Lucie Press/APICS

Bandeau_CH36If you liked this post, share it!
View Christian HOHMANN's profile on LinkedIn

Bending the Current Reality Tree

The Current Reality Tree (CRT) is one of the Theory of Constraints (ToC) Thinking Processes (TP) tools. A CRT is built on Undesirable Effects (UDEs) linked by logical cause-effect-cause relationship called “sufficiency”. Sufficiency logic relationship is in the form of “if A is true then B is true”, or “if A exists, then B exists”.

>Lisez-moi en français

A CRT describes the reality, lists the issues that hinders the system / organization to have better throughput.

Building a CRT in the orthodoxical way follows strict rules and good practices. Among the good practices is the one that recommends the CRT has to be built with all stakeholders and then checked for “legitimate reservation”.

I used the CRT in an unorthodox way once during an assignment, thus this post title “bending the Current Reality Tree”.

It was during a quite strange and difficult assignment in which we couldn’t get the organisation chart nor key figures but had to find out the causes of all troubles and recommend solutions nevertheless. The CEO was against the consultants, but the COO could made him agree to let us make a pre-diagnosis.

Puzzled about how to go on, I had an intuition during the managers’ interviews: write down all UDEs they would mention and try to build a CRT afterwards.

The interviews were one manager a time and we had no opportunity to have a CRT building workshop with all of them.

I collected 347 UDEs of all kind and started to sort them out in relevant categories. This sorting led to 23 categories holding all the UDEs.

Then, instead of trying to combine all the UDEs in a single tree, I built trees according to how UDEs formed links between themselves and ended up with 6 trees on following topics:

  1. Management
  2. Information Technologies
  3. Marketing
  4. R&D
  5. Overall performance
  6. Misc.

These trees helped me and my team to structure the results of the interviews and analysis. CRTs are great tools to describe the current situation as they “tell the story”.

We used the posters with the trees to debrief top management. These posters were no artwork, not very nice made: the paper sheet was the paperboard’s or brown paper and each UDE was a strip of paper printed out from my Excel file I used to order the UDEs. Nevertheless, their value was in the content, not the design.

The posters were pinned on the wall and the audience could freely walk around to read the content. People were glad to see their verbatim captured and taken into account, in an anonymous way, ordered and displayed in a logical arrangement they could understand and agree.

Summing-up

The deviations vs. CRT building:

  • no preparatory boundaries check e.g. what is in the scope, what influence a manager have on the UDEs..
  • building the tree alone after UDEs’ collecting, not in group with stakeholders, thus the trees reflected only the consultant’s point of view and understanding
  • no validity check via Categories of Legitimate Reservation
  • no cross reading except with my colleagues
  • did not use round corner boxes

What was complying to the CRT building methodology:

  • UDE clarity check. I sometimes rephrased the original stance to disambiguate or for the sake of clarity. Clarity was also checked with my colleagues
  • Sufficiency logic check, UDEs were only linked if the sufficiency condition was met

This somewhat unorthodox use of the CRT helped us to better understand the causes of the overall situation and to feed it back to the company’s management. Our audience had no problem with the deviation as they did not know about CRTs anyway.

The assignment did not get further than this pre-diagnosis. Our trees were left at client’s, up to managers to reuse them. If the assignment would have continued and led to an improvement project, it is probable that the trees would have been used as CRTs to work out Future Reality Trees, this time in a more conventional way; in workgroups.

About the authorView Christian HOHMANN's profile on LinkedIn