I use to say that one of the benefits of the Goal Tree is to provide a project Work Breakdown Structure (WBS) to roll out the project, or the Goal Tree to be used ahead of a new project planning to ensure that no step was forgotten. With experience accumulating, I can confirm this to be true, yet with some moderation.
Using a Goal Tree for project planning
Let’s start with the easiest case: using a Goal Tree for project planning. The Goal Tree is well suited to analyse all milestones and steps necessary to achieve the project and “deliver” at the final milestone: the Goal.
The Goal Tree is the framework of the rational analysis that lists all requirements necessary to fulfill in sequence, in order to achieve the Goal / complete the project. Once the Goal Tree is built and checked for logical soundness, rotate it 90° right and you can see the rough project WBS. The Goal stands for the terminal milestone and the Tree structure is the sequence of predecessors and successors in the different branches.
Of course, the true project planning starts now: each prerequisite (Necessary Condition) must be given its project status, i.e. requalified either as an action or a milestone or a gate. Probably some prerequisite are formulated in a too broad way and have to be split into several more detailed steps. Others can be considered as global tasks implicitly summarizing obvious sub-tasks and can be left as they are.
Then, the time required to complete each Necessary Condition must be evaluated in order to compute the project completion time. When using the Critical Chain Project Management approach, the resources will be allocated at this early stage in order to avoid the resource overburdening and plan with finite capacity.
Using a Goal Tree for a strategy deployment
When a Goal Tree is used to define the strategy and plan the strategy deployment, using the Goal Tree as a high-level project WBS is still possible – not always necessary! – but might be a little tricky. The reason for that is that a strategic Goal Tree is fairly conceptual in its top and more specific, i.e. action-oriented in its lower structure.
Therefore when rotating the Goal Tree, many of the Necessary Conditions on the right side (towards the project’s end) are terminal outcomes and milestones. Very few are actions. Conversely, almost all Necessary Conditions in the lower portion of the Goal Tree are actions, provided the Goal Tree is detailed enough and the lower Necessary Conditions are expressed as actions.
Now, strategic thinkers don’t need to go very deep into the operational details of the strategy deployment. The upper layers of the Goal Tree are usually sufficient for them to get a clear view about the where to go and what to do. Details are left for subordinates to work out and take care of.
That’s where project planners can be caught short of sufficient material to start with as a project WBS; what to plan when almost all you have are milestones?
In order to avoid this, a Goal Tree has to be worked out in details far enough to be turned into an usable project WBS. Which means that the people accountable for or in charge of carrying out the actions necessary to achieve the Goal must go on building the Tree down to a level of detail sufficient to list the actions.
This is required for the doers to be clear on what must be done and for the planners to have good inputs to properly plan. When those conditions are granted, the rotation of the Goal Tree and its conversion into a project WBS is possible and relatively easy.
Not originally designed for that (?)
The Goal Tree was designed to get clarity on the Goal to achieve and all the Necessary Conditions or prerequisites to achieve it. The Goal Tree then feeds the other logic tools of the Logical Thinking Process used in sequence to solve the problems hindering the organization to achieve the Goal.
There are 5 to 6 such logic tools used in the complete sequence, the last one* being the PreRequisite Tree (PRT). It lists all steps necessary to overcome obstacles that are cluttering the path to achieving the Goal. Those steps are mainly actions to be carried out.
*the true last one is called the Transition Tree (TT), but is barely used and mostly ignored for being too detailed with low-level, obvious actions.
In the Logical Thinking Process, it is the PreRequisite Tree that is rotated to display the project WBS. And of course this makes sense because the PRT holds a lot of required actions.
Now, the Goal Tree is a latter addition to the other preexisting logic tools and is derived from… the PreRequisite Tree. I was quick to see a shortcut in cases when the Goal Tree alone is enough to provide guidance – the roadmap and benchmark – to achieve the Goal, and rotate the Goal Tree itself. With more experience accumulated doing this, I can now refine the conditions for it to work and when it brings a little difficulty.
Chris HOHMANN 