In this post I explain the difference between enablers and triggers in logic trees, which basically is explaining how Necessity-based logic differs from Sufficiency-based 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.
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
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.