Goal Tree Chronicles: can I have more than one goal?

I started publishing on the Internet in 1998 with the available means at that time. My undertaking had several purposes and expected benefits, but it was all intuition and nothing thoroughly planned.

Years after, knowing the Goal Tree and being fan of the Logical Thinking Process, reflecting about my author debut, I wondered if a Goal Tree can have more than one goal.

Choosing the easiest way I asked my mentor and friend Bill Dettmer instead of giving it a personal thought.

His response, wise as usual, was: “Multi-tasking doesn’t work. It dilutes focus and effort (../..) If you have what appear to be multiple goals, what you more likely have are Critical Success Factors to a higher, as-yet-undefined single goal. If you find such a situation, pose the question, “What higher level SINGLE outcome are all these multiples there to achieve?” That inevitably gets people thinking of one goal.”

I found myself a bit stupid. Would I have invested some minutes, I could have come to this obvious conclusion myself.

Yet I got a bonus. Bill continued his explanation with a Tour de France (our famous bicycle race) metaphor: “I liken the goal to the finish line of a race. There are never multiple finish lines.”

Full stop.

View Christian HOHMANN's profile on LinkedIn


Goal Tree: Why must top management define the Critical Success Factors?

Top managers discovering the Goal Tree frequently ask what input they must give and how “deep” they should commit themselves, where is the point of handover to lower ranking managers?

In this article I remind some basics about the Goal Tree as well as the necessity for top management to define the Critical Success Factors.

Some Goal Tree basics

It is the owner’s prerogative to define the Goal of the organization they purposely created. The organization’s top management takes over by delegation and has to lead it toward the achievement of this Goal.

Yet many ways may lead to the Goal but all of them are not desirable and some of them are not consistent with the organization’s values, adrift from the core business or core competences. Therefore, in my opinion top management must define/recall the organization’s’ Goal as well as the few Critical Success Factors, which make the very top of the Goal Tree.

A quick reminder about Critical Success Factors

Critical Success Factors are the few very important objectives that have to be achieved just before achieving the goal.

The Goal Tree is built upon  necessity logic. To read more about necessity logic click here.

Critical Success Factors should be expressed in measurable units in order to serve as the high level objectives and KPIs altogether.

These targets must be set in accordance with the Goal and as long as these targets are not achieved, the Goal cannot be achieved.

Critical Success Factors are therefore top management’s dashboard, the few KPIs to watch in order to see if the organization is getting closer to its Goal or drifting away from it.

Direction, values and culture

Critical Success Factors are also giving direction because for achieving them it is necessary to roll out specific actions and ensure specific Necessary Conditions are sustainably fulfilled.

Setting the Critical Success Factors will constrain the lower structure of the Goal Tree, which is a network of nested Necessary Conditions. Thus giving clear directions on what to work on in order to achieve the Critical Success Factors and ultimately the Goal.

Conversely, not setting the Critical Success Factors would let all options open including those hurting the core values or taking the organization away from its core competences and what makes a corporate culture.

Furthermore, letting lower rankings set the Critical Success Factors would be equivalent to let the tool choose its work.

View 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

Goal Tree Chronicles – Why You should NOT use a model

A Goal Tree is a logical structure linking the Goal of the organization to all subordinate Necessary Conditions (NCs) to achieve the Goal. The top most NCs are called Critical Success Factor (CSFs) in order to highlight their importance: they are the last things to achieve in order to achieve the Goal.

These CSFs should remain few, three to five (rule of thumb), as it is not reasonable to have a Goal depending on too many CSFs. If they are too many, chances are some of them are overrated NCs and should return some level deeper into the Tree .

>Lisez-moi en français

Yet saying three to five and with Eli Goldratt’s first (universal?) definition of the Goal, many will think about having maximum Throughput (T), minimum Operating Expenses (OE) and minimum Investment (I) as CSFs.

Indeed, they may very likely be found somewhere in the Tree, but are they always CSFs?

Some consultants and/or Theory of Constraints practitioners suggest having a generic skeleton of a Goal Tree ready, with T, OE and I at the top and then fill the underlying NCs with the organization’s related requirements.

I do understand the idea, but do not endorse it.

Why You should NOT use a model

A generic Goal Tree could be a consultant’s tool, not an owner’s nor CEO’s.

A Goal stated in a Goal Tree should not vary much nor frequently over time. Neither should the CSFs and NCs. Bill Dettmer states that a properly built Goal Tree remains valid as long as market conditions do not change significantly and in most businesses, the disruptions do not happen very frequently.

An owner or his/her deputies may build one strategic Goal Tree in a decade. So what is it to the CEO or owner to invest a couple of hours going through the top of the Goal Tree without any preset in regards of the life span of the Goal Tree?

Somebody’s else strategic intent

Besides, starting with a so-called generic tree is starting with somebody else’s tree, thus giving up what makes the organization specific. Does an owner or CEO only want to go for a me-too strategy? If yes, buying a how-to book on Goal Tree building or reading my posts on this blog may suffice to copy-paste what others thought out.

I believe going through the whole process, from Goal Statement to the definition of CSFs and first layers of NCs is a very useful exercise for an owner, a CEO or anybody in charge of achieving the organization’s Goal.

Much have been written about the importance of a properly stated and verbalized Goal. Giving some time to do it and review it with a facilitator and scrutinizer is often a very useful exercise and a good investment.

So is the understanding of the links from Goal to underneath Necessary Conditions. Owners and CEOs or their deputies do not have to build the whole tree, but give high level input. From my point of view, CSFs and first layer of NCs define much of the organization’s soul, culture and how this will go on in future.

Bandeau_CH40_smlView Christian HOHMANN's profile on LinkedIn

Critical Chain and Lean Engineering, a promising pair

Critical Chain Project Management (CCPM) has proven its effectiveness to terminate projects on time and even quite often before estimated finish date.

In development, engineering or Maintenance Repair & Overhaul (MRO), using CCPM can give a significant competitive advantage.

It can outperform slower competitors, earn premium for faster achievement and/or allow multiplying projects within similar timeframe and often with same resources.

CCPM is the perfect companion for Lean Engineering, giving the means to win the race-to-market and multiplying new product launches.

True Lean Engineering is something long to develop and “install”, it’s about learning and developing a reusable knowledge base as well as turning engineers into Lean thinkers.

Terminating projects earlier and multiplying them offers the learning opportunities to test and gather knowledge.

CCPM is therefore a good Lean Engineering “forerunner” giving a competitive advantage faster than the sole Lean Engineering initiative.

What CCPM per se does not is discriminate added-value tasks and non added value, the wasteful tasks listed in a project in a Lean thinking way.

Of course, when CCPM takes care about the capacity constrained resources, it invites to check the content of the tasks and scrutinize the proper use of those precious resources, thus calling for Lean-minded scrutiny.

CCPM acts then as a focusing tool for Lean-minded analysis and improvement.

These two, Critical Chain Project Management and Lean Engineering, seem to make a fine, promising pair.
Something to consider.

Bandeau_CH40_smlView Christian HOHMANN's profile on LinkedIn

Overall Equipment Effectiveness (OEE) is a Goal Tree

Overall Equipment Effectiveness (OEE) is a well-known KPI in many industries for nearly forty years in western countries. It reflects overall performance in a single number, and is built upon or integrating three other metrics: Availability, Performance and Quality.

  • Availability is the readiness of the machine / equipment to operate when required
  • Performance is the actual run rate compared to the nominal run rate
  • Quality is the number of good parts or  quantity right first time compared to the global quantity (good and no good)

Everyone of these metrics is expressed in %, OEE = availability x performance x quality

As OEE is multiplying fractions, the result cannot be greater than the smallest value of Availability, Performance or Quality. That is why OEE is a severe KPI: if one of the intermediate KPI decreases, the OEE decreases faster.

If someone is in charge of improving OEE, he or she will “speak” a Goal Tree, and it goes like this: in order to achieve the highest value of OEE, we must have:

  • the machine / equipment steadily ready to operate
  • running continuously at nominal speed
  • producing only good parts

Now with this said, what to do next? Where are the leverage points?

OEE is great to give a snapshot of performance taking into account the three high-level must haves, but when it comes to action OEE must be broken down to find where and what to act on.

In Logical Thinking Process lingo, Availability, Performance and Quality are Critical Success Factors (CSFs), high outcome objectives that enable achieving the Goal: the highest OEE.

Critical Success Factors are very useful because they provide top management the minimal but sufficient dashboard to monitor progress towards the Goal.

These Critical Success Factors are dependent on underlying Necessary Conditions.

Availability for example depends on machine’s technical condition as well as on setup and material availability. It depends also on availability of trained and entitled workforce, work orders and possibly other documents.

OEE Goal Tree

Example of OEE Goal Tree

Performance will probably depend on the machine’s condition, itself depending on the maintenance policy, maintenance frequency, and so on. Performance is also depend on the proper use of the machine by workers, the type and quality of raw material, the type and condition of its tools.

The breakdown goes on this way, from each Critical Success Factor down to the least Necessary Condition, building the whole Goal Tree. In order to list all Necessary Conditions, the same phrase applies: “In order to achieve… We must…”

The list may go on, both horizontally and vertically, according to the business.

The more regulatory constrained the business, the more likely to have a horizontally-wide Tree, as those regulatory constraints will add many mandatory Necessary Conditions.

What I really like with Goal Trees is the provided guidance by the necessity-based logic, insuring a complete and robust Tree is built. On top of it, it helps discriminating the must-haves from nice-to-haves.

Therefore it’s easy to respond logically to the claim “the machine is too old to achieve good performance, get us a new one!”. When considering what can be done to improve OEE, the age of the machine does not appear as being the biggest influencer.

In fact, many examples show that properly tended old machines can still be performant assets.

Chris HOHMANNView Christian HOHMANN's profile on LinkedIn

Continuous improvement: how easily focus is lost

In an industrial environment improvement opportunities are literally infinite, especially if nothing has been done so far about improvement and maturity, about industrial best practices and considering methodologies like Lean, Theory of Constraints (ToC) or Six Sigma was nearly nonexistent.

When starting to improve, it happens quite often: committed people get lost and lose focus. Instead of concentrating on the core issue to achieving the Goal,  they dilute efforts on lesser important subjects, secondary objectives or even unimportant things.

As a consequence real improvements are delayed or even won’t happen.

How to prevent this from happening? Here are three things that will help:

  • Choose proper KPIs
  • Have a sponsor keeping some distance
  • Start with a Goal Tree

Choose proper KPIs

Measurement is the first improvement step. Choose the (few) KPI(s) that really reflect the achievement of the assigned key objectives and assess the effects of improvement efforts with these figures.

Assigned key objectives points to a Goal set by the organization’s owner or the delegate executives. Bottom-up chosen improvement targets lead most often to local optimization which is scarcely contributing to the overall system improvement, hence the reservation about point kaizen or kaizen blitz workshops focused on local improvements/problem solving.

Expected improvement is generally about productivity, quality, timely deliveries or any combination of them. Outcome should be measured in physical units, e. g. widgets per hour, right first time rate or on time in full (OTIF) deliveries.

Pitfall to avoid with KPIs is to choose activity-related instead of outcome-related ones, like the number of kaizen events held in the week rather than additional widgets made ready for shipping.

Teams may get some scolding for not delivering the expected results even though they were convinced to have worked hard and gotten nice results. They are just not aligned with top management’s expectations.

Back-standing sponsor

Having someone higher ranking / legit, keeping some distance from details and looking at the project with a broader perspective is a good way to prevent shop floor teams to get pulled down into details and away from their objective.

The sponsor should have authority to both help the team to overcome some difficulties, when decisions are to be made with other stakeholders and authority to demand regular reports and direct the team when necessary.

Regular reports and expectation of results are powerful incentives for the team not to lose themselves during their improvement journey.

Having a back-standing manager is common practice in the consulting business where a manager will follow, support and coach the consultants shop floor team, making sure focus is kept on the right objective and progress is consistent.
Some customers can’t understand the importance of this management they consider costs added, not value-added, an easy way to charge more (Yes this may happen, but let’s assume the consultants we’re considering are good ones with real care about delivering value and some ethics).

Well, the cost of meaningless efforts, wasted time and resources on ill-chosen or defined objectives is often much higher than the cost of the back-standing manager.

When the Goal is defined at the top-level and the objectives assigned to the teams, the project governance is usually defined as well, with someone high-ranking taking the sponsor / jury role. Bottom-up initiatives do not always have it.

Start with a Goal Tree

My regular followers are used to read my posts promoting this fantastic tool: the Goal Tree. Many of you readers may not yet be familiar with Goal Trees, and I strongly recommend you to learn more about them and evaluate the potential benefits using them.

At the beginning of a project, building a Goal Tree is a smart investment worth the couple of hours required: a well-built Goal Tree will give guidance toward the assigned or chosen Goal as well as the associated few Critical Success Factors to achieve and the list of Necessary Conditions to fulfill.

The Goal Tree is built upon necessity logic (in order to achieve… we must…) and thus prevents to get lost in nice-to-haves or irrelevant “improvements”.

From the moment I used a Goal Tree from the start myself, I kept focused, consistent and more efficient for myself or the teams I worked with. Conversely, when I thought I could save the effort starting with a Goal Tree it went not that brilliantly, with some deviations, drifting and the like.

These unpleasant experiences were powerful reminders, especially when the back-standing manager legitimately “kicked the a**”.


If you liked this post, share it!

View Christian HOHMANN's profile on LinkedIn

How Goal Tree Can Keep You from Failing Projects


Chris HOHMANN – Author

For those following me on this blog or who went through some of the pages here know I am a big fan of Goal Trees.

In this post, I explain how a Goal Tree can keep a project from failing.

A Goal Tree is a Logical Thinking Process tool used to structure everything that is required to achieve a Goal.

>Read more about Goal Trees

The project I am reporting about is a tiny but important one. It will earn the company a fair share of additional output, hence net profit, provided the project is carried out properly. It is about getting an expensive spare piece of equipment that can be setup in masked time before a line changeover, and drastically reduce the changeover duration.

For confidentiality reasons I cannot be too specific about this case.

The lines changeover duration will effectively be reduced if the whole exchange process, including preparation of the parts for the new series going in and stripping and refurbishing parts of the outgoing series is well-managed.

So the project is not only about purchasing the piece of equipment, but about the whole management process including maintaining, storing, preparing, striping… of this piece of equipment.

The difficulty with this project is about knowledge and experience. The people involved have only partial knowledge of the actual process, without the spare parts. The challenge is to build a complete and robust system* which will work right first time, without the flaws and limitations of the actual system*.

*system here everything including material, organisation, process, instructions…

How to make sure everything needed is taken into account without spending more money than strictly necessary? How to ensure to meet quality standards with a solution that will not overburden the shop floor teams?

And this is where I pulled the Goal Tree in.

What most of the people do at this stage is writing down lists of hardware and requirements they know or think about. They do it partly based on their experience (if they have any) and partly with common sense analysis. They may ask experienced operators, but this is by no means not systematic.

Anyway, however the project is started, it is usually without a formal approach for making sure everything is taken into account.

Some will propose a brainstorming, which is a bit of a misnomer in this case. Brainstorming is a creativity technique used to surface lots of new ideas in order to come up with something original, or in a case like ours, a breakthrough.

In our project we weren’t looking for new ideas nor a lot of them; we knew what had to be done and how it had to be done. What we were looking for was to ensure we got everything required in order for our solution to be complete and robust.

This is where the Goal Tree comes in

The Goal Tree is based on so-called necessity logic, in which the elements of the Tree connect to each other with a logical “necessity” relationship in the form of “in order to…we need/must have…”. It starts with the Goal stated on top of the Tree: what do we want to achieve?

This Goal has to be stated in a way to be specific enough. I our case, the Goal was stated: “Ensure the change parts are available and ready for use whenever they are needed”.

It sounds pretty vague as a goal, yet as we worked out all Necessary Conditions (NCs) to achieve it, this statement proved itself being sufficient.

Underneath this Goal we need very few Critical Success Factors (CSFs), necessary to fulfil the Goal and to monitor the progress towards it.

We selected three CSFs covering:

  1. parts management system
  2. the storage of parts between use
  3. transportation of parts to and from point of use

Each of these CSFs can be assessed through a KPI or a set of indicators, which is important in order to monitor the achievement towards the Goal.

Each CSF is then checked for its Necessary Conditions (NCs) using the necessity logic question. These NCs themselves having their own NCs and so on down to the bottom of the Tree.

Goal Tree

Once the Tree was completed, a scrutinizing check was done with people who didn’t participate in building the Tree. Additional NCs came up and new branches were added.

Finally, the Tree was assumed to be complete and all necessary twenty-four actions captured in an action plan.

The 24 actions (e.g. Necessary Conditions) are to be compared to less than a dozen actions initially listed without the Goal Tree. This shows how incomplete a non structured, not backed up by an appropriate tool, action listing can be.

As the additional actions are all Necessary Conditions (read critical to Goal achievement), or at least related to NCs, the project would most probably have suffered some unexpected problems or even failed. And this is only a tiny project requiring less than 30 actions, so imagine how a non-structured approach to bigger project can end.

Conversely, a Goal Tree is build on pure logic and is much more likely to grant a complete and  robust list of tasks, especially when reviewed by someone experienced in scrutinizing and challenging Goal Trees.

What I really love with Goal Trees is the prevention of “nice-to-haves”, as anything not complying with the necessity logic is… not necessary, by definition.

Bandeau_CH6If you liked this post, share it!

View Christian HOHMANN's profile on LinkedIn


Goal Tree Chronicles – from Goal to action plan in a couple of hours


Chris HOHMANN – Author

In a previous post I described the utilisation of a Goal Tree to order ideas when working on a small project, a part of a project or an improvement plan.
In another post I gave answer to the question “is it worth the time and energy invested?”.

In this post I share my own benchmarks about time required to build a Tree.

1. Limited scope

Let’s begin with the “order the ideas” case.

When building a Goal Tree for such a limited scope, it takes a couple of hours from scratch to action plan. The action plan will contain a dozen actions and the Tree have about thirty entities.

Is it worth it?

One may question if building a Goal Tree for such a limited scope makes sense?

Yes it does. The Tree is not only a fine way to order ideas, it helps having a sound and robust series of Necessary Conditions (read requirements) without Nice-to-haves that would certainly add costs but not always more throughput.

A Goal Tree is also a very good communication tool.

People involved building Trees and Tree owners get usually good at telling the story and selling the Necessary actions to undertake, even they’re not used to present summaries and reports to any audience.

Henceforth, a Goal Tree is a collection of benchmarks, and if using my suggested color coding system, a convenient assessment tool. These benchmarks remain valid for a certain time.

So is it worth investing a couple of hours to get all of these? Yes it is. At least if communication and benchmarking is meant to be used.

2. Defining strategy

What about a broader scope, like setting up a strategic plan for mid or long term?

For such a broader scope the need for a longer time to build a Tree makes sense and it’s a bit more difficult to give an indication of required time. Depending upon the initial alignment of executives, discussion about the Goal and/or Critical Success Factors (CSFs) can take some time until all agree.

My experience with (French*) executives discovering the Goal Tree tells it can take up to several sessions to get the Goal and CSFs set.

*we French are famous for arguing, resist change and slow to get consensus, aren’t we?

Once this is achieved, I usually recommend to let the next line of managers work out the Necessary Conditions (NCs) and come back to execs with their proposals. If execs are to define the first NCs, it will usually take a little more time than with managers. The higher in the organisation, the more freedom to question everything.

To keep long story short, a strategic tree may take several days to have its top built (Goal and CSFs) in a sound and robust way.

According to the required width and depth of the Tree, additional time is necessary, especially if built in a participative way with subordinates.

Is it worth it?

Yes it is. First the previous arguments with limited scope are still valid with this broader one.

A Goal Tree defining the next years’ strategy is a great communication tool and a way to feed a Hoshin Kanri X matrix for those using it.

Such a Tree may remain valid for an extended period of time: 3 to 5 years, except for faster changing businesses.

So even investing several days to build a lasting Tree providing guidance for decisions and benchmarks is definitively worth it.

View Christian HOHMANN's profile on LinkedIn

Goal Tree: is it worth it?

Depending the methodology, building a Goal Tree requires some time and attention from top management. The one I am thinking of is typically a two to two and half day seminar (when led by an expert). Therefore the Chiefs often hesitate to invest this time as they are already overbooked and question the necessity of the exercise: is it really worth it?

Yes, it definitely is!

It is worth to invest the necessary time to re (state), refine of review the Goal, define the Critical Success Factors (CSFs) to achieve the Goal and at least the first layers of Necessary Conditions (NCs), to achieve the CSFs.

It is worth because such a Goal Tree remains valid even if top managers leave, because it is tied to business fundamentals and not to someone’s “strategy”. Much of what a Goal Tree describes will remain valid, even if people in charge change.

Yes it is worth to invest time to set the benchmarks (CSFs and NCs), as they will remain valid over a period of time, because they are business fundamentals. World expert and father of the Goal Tree Bill Dettmer uses to say “Goal Tree well built remains valid until the business environment changes or the way the organization is doing business changes significantly“. Furthermore, compared to actual performance, these benchmarks will help to define the roadmap for improvements.

With these elements, the subordinates will know onto what to align their improvement efforts and get tangible and measurable ROI instead of sprinkling “improvements” here and there with sole measurable parameter being the cost of efforts spent.

Yes it is worth the C-suite invest some of its time to provide subordinates a sound vision, a clear Goal and direction about how everyone in the organization can contribute achieving the Goal.

It is especially worth when compared with the time spent in useless meetings and daily firefighting. Firefighting makes feel important and active, but in reality it is more gesticulation than action.

Aligning people’s daily efforts on meaningful targets will solve some problems and reduce the need for firefighting.

Alas, many world-saving managers don’t like this kind of wise and humble posture. This is good for old men meditating atop remote mountains, not for business warriors they think they are.

Yes it is worth to invest some time to get a visual management tool to assess progress towards the organization’s Goal, foster, sponsor, realign and refuel improvement programs. It is worth if after building a Goal Tree, the Chiefs use it for periodical review and self assessment.

An additional latter post discusses the ‘is it worth’ question: Goal Tree Chronicles – from Goal to action plan in a couple of hours

Bandeau_CH36If you like this post, share it!

View Christian HOHMANN's profile on LinkedIn