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.

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

Advertisements

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

What advice to people wanting to experience the Logical Thinking Process Training Course?

Paris June 28th, 2017. The 6-day Logical Thinking Process Training Course with Bill Dettmer is just over. We asked the participants not in a hurry to rush to an airport or train station if they would share their thoughts about the course in front of a camcorder?

Cédric, Sverre and Leo were so kind. Bill asked them about their favorite takeaways and advices for people willing to take the course.

As a veteran with 5 attendances (being part of the organizing party) I delivered my testimony long ago, however, I reflected on what I would say now.

My favorite part of the course changed over the sessions, which is understandable with all that repeat. Now my favorite part is working hands-on on trees, cross presenting them and have them scrutinized. That’s the closest we can get in a room session while working on somebody’s real-world case.

This brings me to my advice: come prepared (read the pre-course reading material) and have a real-world problem to work on. The best is a problem with which the participant has enough inside knowledge and enough influence – if not power – to make change happen.

What happens during the course?

This last June 2017 session was in my opinion a good one because the cases were mostly about founding a new business, spinning-off from actual one, or trying to reinvigorate an existing fading one.

With entrepreneur spirit and most of the options open, the Goal Tree was piece of cake. Well it seemed to be piece of cake. Once in front of a large empty sheet of brown paper and a demanding mentor in the back, the candidate entrepreneurs had to turn their brilliant idea in a compelling and robust Goal Tree.

The Current Reality Tree (CRT) brought most of them back into their unsatisfactory actual state, but at least with clear understanding of what causes the Undesirable Effects (UDEs). Conflicting objectives or decisions were uncovered and creativity called in to dissolve the conflicts.

Logical Thinking Process / Theory of Constraints’ Thinking Processes aware readers recognize the Evaporating Cloud (EC) to do that.

On the group went, injecting solutions into their current reality in order to turn the UDEs into Desirable Effects (DEs). This was done thanks to the Future Reality Tree (FRT), a kind of logical (and virtual) proof of concept to test the solutions.

Bill instructed the group to look for possible Negative Branches that may grow out of a seemingly brilliant idea and end up in a new and unexpected UDE. When such a branch is spotted, the trainee can be happy to have tested the solution on paper before messing up in real world! Luckily there are ways to trim such unwanted negative branches and it’s part of the training.

The final exercise is to list the possible obstacles to implementation and overcome them with a Prerequisite Tree.

Five trees per attendant gives a lot to review and scrutinize! And just as many learning opportunities!

View Christian HOHMANN's profile on LinkedIn

What is Lean Coffee?

A Lean Coffee is a semi formal* meeting in which participants choose the topics they want to discuss, vote for the topics and then discuss the most voted topics during a limited time period. At the end of the ‘timebox’, the group decides to continue or switch to the next if they feel they got enough.

*by semi formal I mean the meeting is structured, but either agenda-less or very flexible about contents.

Lean coffee start is credited to Jim Benson and Jeremy Lightsmith back in 2009 in Seattle.

Advantages of a Lean coffee

Traditional meetings are moderated in ‘push mode’: the organizer sets up an agenda and invites participants. Those may have different interests in attending the meeting, ranging from very high to almost none. Nevertheless it is often difficult to avoid attending even if interest is low and there is seldom a way to influence the content as an attendee.

In Lean coffees, the moderator ‘pulls’ the topics from the attendees, which gives everyone an opportunity to have his/her point of interest discussed. If a proposed topic does not get many votes, the attendance may not be the suitable one or the topic is indeed of no interest.
Another specific meeting may be organized or the topic left off the list.

Pulling the topics from the attendees is also a way to show respect and fight the eighth muda. Jim Benson states “When we invite people to meetings and give them a strong agenda up front, we are completely robbing ourselves of the wisdom the attendees would bring with.
In other words, Lean coffees trades passive listeners for active resources and knowledge sources. Attendees are not supposed to leave their brains at the door but bring them in and use them.

Lean coffees are time-boxed, which forces to keep focus on the subject. The participants get a feeling of greater intensity and effectiveness compared to traditional meetings.

Here is a selection of videos about Lean coffee.




View Christian HOHMANN's profile on LinkedIn

Autonomy, accountability and tunnel effect

One young employee told me “I don’t like my manager to ask me over and over again about the progress of my work. I like to get my objective and then be let on my own to achieve it, I’ll report when I’m done”.

Well I thought, you have never been project manager nor in charge of a team. You probably barely know anything about project management techniques and the difficulties to synchronize multiple outcomes, and probably voluntarily ignore the existence of dependencies between tasks for your own selfish comfort.

This kind of cocky open arrogance from someone without significant experience is not something a seasoned project manager will appreciate. Chances are that facing such a mindset, the manager will reinforce his/her control.

It is one thing to demand empowerment, autonomy and be willing to take accountability, it is another to give periodic feedback about the progress of a task or project.

What managers or project managers don’t like at all is the tunnel effect, a common metaphor in France and in project management parlance that describes the extended period during which, the customer and/or the project manager are left in the dark, without any clue about the progress of the job do be done.

At the end of the tunnel, when customers and/or project managers discover the results, chances are that the outcome is not satisfactory or can even endanger the whole project! Something that could have been prevented if there had been periodical feedback, assessment and realignment if required.

This is why software development went for methods insuring loops, scrums, instances during which the stakeholders can share the state of current development, mitigate the risks and even take into account late changes.

Giving periodic feedback is not only something to please customers and project managers, it is also something useful for colleagues and other stakeholders that are dependent on tasks or outputs. By getting feedback and insight, those stakeholders can adjust their own schedules and actions according to current progress.

Management at all levels is highly facilitated through shared visual management, like for example using a Fever Chart, a simple visual dashboard/indicator introduced by Critical Chain Project Management.

Therefore, even in organizations granting a large autonomy to their associates, there is no such a thing as getting an objective and returning to report when it’s achieved.

View Christian HOHMANN's profile on LinkedIn

Continuous Improvement: Prevent frustrations related to the S curve

When implementing some solutions, like in continuous improvement, project managers better take care about the frustrations related to the S curve.

S curve

S curve

The “S curve” is the shape of the performance curve over time. It describes a latency (t1) before the performance p1 takes off after the improvements have been implemented, then a more or less steep rise before stabilization at the new level of performance p2.

This latency time after the first improvements until improvements become noticeable has several possible causes and can pose different problems.

>Lisez-moi en français

The most trivial reason for a lack of significant effects after a while is that the solutions put in place do not produce the expected effects. It is therefore advised to estimate in advance, at the moment improvements are implemented, when the effects should be noticeable, in order to have an alert when the estimated time is elapsed.

Another trivial reason is a long cycle time. This may be the case with lengthy process of transformation, processing time or latency inherent to the process before the success of the operation can be judged. Typically, these are technical lead times, time required for chemical or biological transformation processes or “responsiveness” from third-party organizations, etc.

The delay may be due to the improvement process itself, which may require several steps such as initial training, implementation of the first improvements, measurement of their effects and time to analyze them.

Another reason, that may be coupled with the previous one, is Little’s law. It states that the lead time through an inventory or queue of work in progress (WIP) is equal to the value of this inventory divided by the average consumption. This means that if the improvement occurs at a point decoupled from the measurement point of its effectiveness by either inventory or WIP, the effect must first propagate through the queue before it can be detected. Everything else being kept equal.

Please note that this delayed improvement phenomenon or “S curve” described here in the context of continuous improvement can be found in the implementation of any project.

This discrepancy can be a problem for Top Management awaiting return on investment and wishing it as quick as possible. This is all the more true if the activity is highly competitive because an improvement can determine the competitiveness and/or profitability of a project, an offer or even of the whole organization.

It is therefore recommended that the project leader reminds the likeness or certainty of the S curve, even to the managers pretending to know it. Under pressure of business they tend to “forget” it.

The second problem with delayed effects concerns those closer to execution who expect some benefits from improvement, such as problem solving, elimination of irritants, better ergonomics, etc.

Assuming that the operational, shopfloor staff have been associated with the improvement, their frustration and their impatience to see changes is even more important. Without promptly demonstrating that “it works”, there is a significant risk of losing their fate, attention and motivation.

In order to prevent this, the project manager must choose intermediate objectives in short intervals in order to be able to communicate frequently on small successes.

The recommendation  is to look for a weekly interval and not exceed the month. The week represents a familiar time frame to operational staff, and the month being, in my opinion, the maximum limit. Beyond the month it usually becomes an abstraction and attention gets lost.

View Christian HOHMANN's profile on LinkedIn