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:
- parts management system
- the storage of parts between use
- 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.
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.