Goal Hierarchy

Latest revision as of 14:58, 28 February 2021

When managing projects, it is important that they have a specific direction to be successful. The direction of the project can be found by defining the purpose. If there is no purpose, there is no reason to do the project. When breaking down the purpose in smaller parts the scope can be defined. The scope should only include the processes that will help you ensuring that the project will be a success. ^[1] One way to help you defining the scope of your project is to apply the Goal Hierarchy from the book ‘Power in projects, programs and portfolios’ ^[2] also known as Goal Breakdown Structure.

The Goal Hierarchy is a goal-oriented iterative method that can be used to define the scope of your project. This by setting goals that can be brought up to date as knowledge expands. ^[2] The method consists of a hierarchy with a main goal on top followed by sub-goals, project-goals, deliveries, and success criteria. The goals are broken down in different levels of details, by asking ‘why?’ and ‘how?’. You ask, ‘why are we doing this?’ to make sure the goals make sense and ‘how are we doing this?’ to make the goals specific. Since the method is an iterative process you ask the questions again and again to improve the goals. ^[3] It can be used for both project-, program- and portfolio management, however, the focus will be on using the method in a project management context.

This article will investigate the Goal Hierarchy and its purpose and how it can be applied to make your project more specific and goal oriented. The application of the method will be followed by its limitations with a critical reflection of the method and its application. Hence you will be aware of what the method can and cannot do and when it will be beneficial to use after reading this article. (Please note that some images may be incorrectly aligned with the text if your screen resolution is not set to 150%).

[edit] Context

The Goal Hierarchy is a method that is developed for project management within the purpose perspective to find out what the scope of the project is. This, as mentioned previously, does not mean that the method cannot be applied to other types of management such as program- and portfolio management. Program management involves several projects that cannot be solved individually to achieve an objective. ^[4] In those cases, the Goal Hierarchy could be extended to include more projects with the same main goal on the top of the hierarchy. This will make the process more complicated, but it is far from impossible. The same applies to portfolio management where one or more portfolios strive to achieve strategic objectives with selected programs or projects. ^[1] This type of management will also need an extended version of the method for it to be usable. This by customizing the method to the specific portfolio. Even though the method can be used for different management types, this article will focus on how to use the Goal Hierarchy as a project manager in order to simplify its use.

[edit] Description and Purpose

The Goal Hierarchy is a goal-oriented iterative method that can be used to help project managers define the scope of their project. In addition, the method can assist the project managers to fulfil their main responsibility, which is to deliver the project deliverables within the project's goals. ^[5] To define the scope of the project and deliver the project deliverables within the project's goals, the method can be used for most projects (read more under section 'Limitations'). The place to start is to figure out what the project should lead to. When doing projects, you have to think about the end before the beginning, which is not an easy thing to do. Nevertheless, it is the place to start. If you do not have a goal from the beginning, it is impossible to know what you are searching for. However, it requires knowledge and an analysis to set goals, and with high uncertainties in the very beginning of the project this can be a challenge. The way to work around it is to define goals in different steps as knowledge of the project expands and the uncertainties decreases. ^[2] By using the Goal Hierarchy, you can get help with how to get started with your project goal setting as well as ensuring that you are on the right track throughout the project lifespan.

Figure 1: The Goal Hierarchy inspired by figure 3.8 (Attrup and Olsson) ^[2] and figure 17 (Geraldi, Thesen, Oehmen and Stringl) ^[3] made by Emilie Torp.

The method consists of three elements: goals, deliverables, and success criteria. Together they make a hierarchy of goals. To improve the understanding of the Goal Hierarchy, the figure 1 have been developed with inspiration from (Attrup and Olsson) ^[2] and (Geraldi, Thesen, Oehmen and Stringl) ^[3] while the use of it remains the same.

The goals are broken down in different levels of details: a main goal, sub-goals, and project-goals. They state where the project is heading and why the project is relevant. This by asking the questions ‘why?’ and ‘how?’ again and again to improve the goals doing the lifespan of the project. The question ‘why?’ is about making sure that the goals are relevant at all time. This forces the project manager to adjust the purpose as the project knowledge expands keeping the project up to date. The question ‘how?’ is about looking down in the hierarchy and reflect on whether what your doing is relevant. If not, the direction should be changed to achieve the goals. ^[2]

The deliverables can be found further down in the hierarchy. They describe what have to be delivered when the project is finished. You ask the question ‘what?’ to find out what to deliver to fulfil the purpose of the project. They can be described in further details with sub-deliverables as shown in figure 1. ^[2]

The success criteria are added to be able to measure the goals to ensure that the impact you wish the project to fulfil becomes a reality. The success criteria should be measured as close as possible to the deliverables, since the project-goals are the goals that you have the most influence on. The higher you reach in the hierarchy the less you can make the criteria specific and useful. Furthermore, some success criteria might be more important that other. These can advantageously be added to the Goal Hierarchy to make a greater focus on meeting these specific criteria. ^[2]

In short, the connection between the three elements is that a project will carry out deliverables that creates an impact that can be measured with success criteria to find out if the goals are achieved. This will be elaborated in the next section.

[edit] Application

The Goal Hierarchy can be implemented in both project-, program- and portfolio management (as mentioned under the section ‘Context’). When working with a program- or portfolio management the method will naturally become more complex with an extended version of the hierarchy. Consequently, the focus of the following will be on projects to make the application as clear and usable as possible.

Figure 2: The Goal Hierarchy elements in a project lifespan inspired by figure 3.4 (Attrup and Olsson) ^[2] and figure 1-5 (PMBOK) ^[1] made by Emilie Torp.

[edit] Project Lifespan

When talking about the application of the Goal Hierarchy in projects it is essential to be aware of the lifespan of projects. The project lifespan is a collection of different project phases from the beginning to the end of a project. ^[1] In figure 2 the application of the three elements: goals, deliverables, and success criteria from the Goal Hierarchy is shown in a project lifespan connection. The lifespan of projects consists of four phases. The first phase of the project is the beginning where the purpose and goals are defined. The goals can be developed and changed as knowledge expands in the project lifespan. The second phase is where the project is organized and prepared. In this phase the deliveries and success criteria are defined to make the project deliveries specific and the goals measurable. In the third phase the work and deliveries of the project is carried out. In the fourth and last phase of the project lifespan the success criteria should be achieved. Finally, after the project has ended the results of the project can be checked out by making sure the goals have been achieved.

[edit] Step by Step

The purpose and main goal of a project are often formulated by a management, after which a project group aims to solve the task. To make the use of the Goal Hierarchy more understandable, five steps have been set out. Each step describes how parts of the method are used. ^[2] In figure 2 it is possible to see when in the project lifespan the different steps are to be performed.

[edit] Project Case

Through all steps in the following, we will look at a fictive project case. The case is about a municipality that wishes to have ‘less traffic congestion’ on their road network. The head of the road department finds out that the surrounding municipalities have the same challenges. Therefore, the municipality chooses to cooperate with them. Since the municipalities are not road owners of the largest traffic roads, people from the Danish Road Directorate gets associated with the project. The project group now consists of various professionals with one project manager. To reach the goal of having ‘less traffic congestion’ they use the Goal Hierarchy.

Figure 3: Step 1 of the Goal Hierarchy inspired by figure 3.6 (Attrup and Olsson) ^[2] and figure 17 (Geraldi, Thesen, Oehmen and Stringl) ^[3] made by Emilie Torp.

[edit] Step 1 - Define the goals

The first step is about defining the goals. When using the Goal Hierarchy, you do not necessarily have to start by looking at the purpose of the project. Of course, the purpose is the reason why we are doing projects, however, by searching for goals the purpose might become clearer. This can be done by for example applying post-it notes on a board or wall by members from the project group. Doing so you can create a number of goals and then move the post-it notes up and down in the hierarchy by asking the questions ‘why?’ and ‘how?’ repeatedly. ^[2]

With the project case of having less traffic congestion, the project manager can examine: ‘how can we achieve the purpose: less traffic congestion?’. The answer to this may be by optimizing the road network and improving the public transportation (see figure 3). For each of the goals there is an outcome, which is to have a better road network and public transport. To get back into the hierarchy, the project manager can then ask the question: ‘why should we optimize the road network and improve public transport?’. The answer to this is to get less traffic congestion. This iterative process can be made as the knowledge expands in the first phase of the project improving the goals and thereby the purpose of the project.

Figure 4: Step 2 of the Goal Hierarchy inspired by figure 3.7 (Attrup and Olsson) ^[2]and figure 17 (Geraldi, Thesen, Oehmen and Stringl) ^[3] made by Emilie Torp.

[edit] Step 2 - Examine how the goals can be achieved

The second step is about examining how the goals can be achieved. To figure that out the question ‘how?’ is asked yet again to make the goals in greater detail and to make them more specific. In this way, the goals get concrete deliveries that have to be delivered for the goals to be met. ^[2]

In the project case the goals are scaled down by asking ‘how?’ to each goal to examine how the goals can be achieved. To optimize the use of resources and the time within the project group, the project manager chooses to divide the project group in two. One group that works with the goal of optimizing the road network and another group with improving public transport. The first group will then have to investigate how the goal 'Optimize road network' can be concretized. This is done by asking the question ‘how should we optimize the road network?’, the answer to this is by increasing the focus on passability and by developing the road network. Then the question of ‘how?’ is asked again: ‘how should we increase the focus on passability?’. This is done by coordinating the roadwork, optimizing the traffic signals, and expanding the road network. This process will continue until specific deliveries have been made to fit the goals. Meanwhile the second group will be doing the same process in order to improving the public transportation.

Figure 5: Step 3 of the Goal Hierarchy inspired by figure 3.8 (Attrup and Olsson) ^[2] and figure 17 (Geraldi, Thesen, Oehmen and Stringl) ^[3] made by Emilie Torp.

[edit] Step 3 - Move focus up and down in the hierarchy

The third step is about moving the focus up and down in the hierarchy. We do this to ensure that the project manager do not forget that the first solutions not necessarily are the best possible solutions. By using the Goal Hierarchy, you can make sure that you do not get stuck on certain solutions to soon. Furthermore, the iterative process might help you get the bigger picture of the project scope and its purpose. ^[2]

In the project case the project group changes the focus from only looking at ‘how?’ to include the ‘why?’. By doing so they forces themselves to look up and down in the hierarchy. The first group starts out by asking, ‘why’ from the bottom of the hierarchy to the top. For example, ‘why do we need a coordination of roadwork?’. It is because we want to focus on passability. Followed by asking, ‘why should we focus on passability?’. That is because we want to optimize the road network. After that process they will continue by asking the question ‘how?’, which might create more deliveries. The process of moving the focus up and down in the hierarchy continues until the two groups are satisfied with the goals and deliveries. When the two groups are done with the process, they can then meet up and put it all together. This might even create new or improved goals or deliveries. Furthermore, there might be goals that can fit together after the union of the goals. An example of this is that the goal ‘develop road network’ also improves the public transportation (see figure 5).

Figure 6: Step 4 of the Goal Hierarchy inspired by figure 3.8 (Attrup and Olsson) ^[2] and figure 17 (Geraldi, Thesen, Oehmen and Stringl) ^[3] made by Emilie Torp.

[edit] Step 4 - Separate the goals and deliveries

The fourth step is about separating the goals and deliveries in the Goal Hierarchy. When the project group have decided what should be the goals and deliveries the iterative process is finished. Keep in mind that when you decide on which deliveries should be delivered that they must be as specific as possible to avoid an any confusing about what is expected to be delivered. ^[2]

In the project case the iterative process that have been made doing the first phase of the project (step 1-3) is now over. The next step is to discuss what should be the goals and what should be the deliverables doing the organizing and preparing phase. After the discussion in the project group they have finished making the Goal Hierarchy shown in figure 6. They have broken down the main goal ‘less traffic congestion’ by making two subs-goals stating that they wish to optimize the road network and improve public transportation within the boundaries of the municipalities. Those goals are still not tangible, so the sub-goals are broken down into project-goals. The project group decides to make four project-goals where they want to focus on passability, developing the road network, making public transportation attractive and to increase availability. The deliveries are found by asking the question ‘what?’. This to find out what should be delivered to achieve the goals. The group decides on seven deliveries, where some of them have been elaborated in further detail by sub-deliveries.

Figure 7: Step 5 of the Goal Hierarchy inspired by figure 3.10 (Attrup and Olsson) ^[2] and figure 17 (Geraldi, Thesen, Oehmen and Stringl) ^[3] made by Emilie Torp.

[edit] Step 5 - Add success criteria

The fifth and final step is where the goals are made measurable. However, not all goals are equally fitted for this (as mentioned under the section ‘Description and Purpose’). The further away the goals are placed from the deliveries, the less influence you have on making them a reality (see figure 4). Therefore, you need to be careful if you decide to make success criteria far away from the deliveries since other parameters might change the direction of the project. ^[2]

The project group has reached the point where they only are missing the step of making specific success criteria to the project-goals. As an example, they agree that they would like it to be 20% faster to get from A to B before May 2022 and that they would like to have the road network expanded by 45% before September 2023. In figure 7 the rest of the chosen success criteria are shown. It should be noted that the success criteria should be as detailed as possible as it will make it more useful and easier to determine if the success criteria have been achieved.

After the five steps have been completed, it is time to carrying out the work required to fulfil the goals shown in figure 6. After the work is completed, the deliveries shown in figure 6 are carried out. Followed by achieving the success criteria, described in figure 7, after the ending phase of the project. At last by not least, the goals from figure 6 have been achieved in the operating and maintaining phase. Thus, the Goal Hierarchy has been used by the project group which has made their project goal-oriented with specific deliveries and measurable success criteria. Furthermore, they were always sure of the purpose of the project throughout the project lifespan.

[edit] Limitations

The Goal Hierarchy is not without its limitations. Before deciding to use the Goal Hierarchy, consider whether the project you are working on can benefit from using the method. The same applies if you are using the method for a program- or portfolie management case. There are differnet goal setting phases for different types of projects. For example, in the case of a building- or delivery project they are often based on their deliveries where their success criteria are directly linked to the deliveries. This since there is a clear purpose from the beginning of the project. One example can be a project where a construction firm has to build a bathroom. The goal is not that relevant to focus on since they already have a delivery where the success criteria e.g. can depend on what the quality of it when it is completed is. Conversely, the Goal Hierarchy can be useful for the more strategic projects. Instead of the project being about making a bathroom, it can be about how the company wants to make bathrooms and at the same time improve their customer service. The Goal Hierarchy is then recommended to be used, since the project becomes more goal-oriented. At the same time, if the project is at a strategic level there is a need to find a more specific purpose without limiting the flexibility of the project.

For projects about delivering a specific product, it might be better if you use a more task-oriented method, such as the Work Breakdown Structure, to create an overview of the activities and work tasks of the project. However, you must not forget that if you change focus from looking at goals to activities the purpose and goals of your project might be forgotten along the way. Also, the project manager might not always be the best person to define activities for people with other expertise. ^[3] However, it is possible for a company to apply both the Goal Hierarchy and Work Breakdown Structure to a project. This by using the Goal Hierarchy to define the goals and deliverables and the Work Breakdown Structure to create a structure over a work-oriented description of the deliveries.

In addition, there is a limitation in using the Goal Hierarchy since there can be a point in time where it is no longer possible to ask the question ‘why?’. If you continue to ask '‘why?’ you might end up wondering why we are existing. Therefore, you need to stop the process at a given time to avoid a major and unrealistic purpose of the project. This since you need a clear purpose to make a clear direction for the project. ^[2]

[edit] Annotated Bibliography

• Attrup, M. L. and Olsson, J.R. (2008). Power i projekter og portefølje, DJØF Publishing

This book provides an insight into how to apply the Goal Hierarchy step by step. It is also possible to get concrete and easy to read examples of how the method is used for different types of projects, which makes the book very useful. In general, the book provides with lots of useful tools to manage projects in practice and it is therefore highly recommended.

• Project Management Institute, Inc.. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition). Project Management Institute, Inc. (PMI). Retrieved from https://app.knovel.com/hotlink/toc/id:kpGPMBKP02/guide-project-management/guide-project-management

This book is a standard that provides basic knowledge of project-, program-, and portfolio management, however, the focus is mainly on project management. To get an insight of how the Goal Hierarchy can be used in the differnet types of management, the standard is used to distinguish differences and understand what the objectives are within each form of management. The book is not the easiest to read, but if you are looking for answers to something specific, it is definitely useful.

• Geraldi, J., Thuesen, C., Oehmen, J., & Stingl, V. (2017). How to DO Projects? A Nordic Flavour to Managing Projects. Dansk Standard. DS Handbook Vol. 185

This book provides insight into the four perspectives of project management: purpose, people, complexity and uncertainty. The book shows an extended version of the Goal Hierarchy based on figure 38 from Olsson and Attrup, 2015, in chapter 6. The biggest difference is that the Goal Hierarchy is shown in one overall figure in 'How to DO Projects'. The book can be recommended since it consists of useful theories and methods of project management.

[edit] References

1. ↑ ^{1.0 1.1 1.2 1.3} Project Management Institute, Inc.. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition) - 5. Project Scope Management, page 13, 18-19, 129. Project Management Institute, Inc. (PMI). Retrieved from https://app.knovel.com/hotlink/pdf/id:kt011DX4T1/guide-project-management/project-scope-management
2. ↑ ^{2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20} Attrup, M. L. and Olsson, J.R. (2008). Power i projekter og portefølje, page 96-109, DJØF Publishing
3. ↑ ^{3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8} Geraldi, J., Thuesen, C., Oehmen, J., & Stingl, V. (2017). How to DO Projects? A Nordic Flavour to Managing Projects, page 113-115. Dansk Standard. DS Handbook Vol. 185
4. ↑ The Standard for Program Management — fourth edition, page 10. (2017). ProQuest Ebook Central https://ebookcentral-proquest-com.proxy.findit.dtu.dk
5. ↑ AXELOS (2017). Managing successful projects with prince2 2017 edition, page 61. ProQuest Ebook Central https://ebookcentral-proquest-com.proxy.findit.dtu.dk