What is a Goal Diagram?
Goal Diagram Definition
A goal diagram visualises goals, relationships between goals and relationships between stakeholders and goals. Goal diagrams – also known as goal models – help in a simple way to identify relationships and derive requirements from stakeholders’ goals. Goals are intentions that stakeholders pursue through software, systems, products, or projects. A goal diagram describes a snapshot that documents an assessment of the goals, the dependencies between the goals, and the priorities set by the stakeholders. It is a presentation that should be reviewed cyclically for relevance to ensure a sustainable alignment of development with stakeholders’ goals.
Advantages of Goal Diagrams
Goal diagrams are easy to create and read. They also offer a number of advantages:
- Individual goals and the interaction of goals are easier to understand compared to capturing goals by tables.
- Stakeholders pursue goals. Sometimes they “own” a goal, sometimes they show “interest” in a goal. Communication with stakeholders is facilitated because the significance of individual goals can be clarified at an early stage for a development or project.
- The use of AND/OR decompositions increases the understanding of the participants and forms the basis for the selection of action alternatives. In AND decompositions, several goals are addressed simultaneously, in OR decompositions one goal is divided into several subgoals, of which only one has to be achieved.
- Conflicts and contradictions can be identified so that important decisions can be made early on and undesirable developments avoided.
- The weighting of goals helps to prioritise derived requirements.
The Reading Direction in Goal Diagrams
Goal diagrams can be read in two opposite directions:
- From top to bottom – this direction answers the question of “how”. Here in the example: How does Stakeholder 1 want to achieve market leadership with an innovative product? By developing a quality product at low cost.
- From bottom to top – this direction answers the question of “why”. Why should development take place in Asia or Eastern Europe? Because development at low cost is important to achieve market leadership with an innovative product.
Download the Goal Diagramm Guide for free now.
Everything important about goal diagrams at a glance.
- Goals and the importance of documenting them
- Definition of goal diagram
- Relationships, key figures and functions
- Challenges and advantages
Knowledge on 8 pages to take away.
What are Goals?
The word goal is a universal term that is understood and interpreted differently depending on the context. Basically, a goal – or an objective or a target – is a future, aspired and defined condition. It can be a company goal, a social or personal goal, an economic goal or an ecological goal. The characteristics of a goal are content, time frame and degree of fulfillment.
Stakeholders pursue goals in the context of a project or the development of software, systems or services. For example, they expect a system to help them achieve these goals. For this to succeed, the system must have defined characteristics. The description of such a feature from the stakeholder’s point of view is called a goal. In Requirements Engineering – Grundlagen Prinzipien, Techniken Klaus Pohl defines it as follows: “A goal is the intentional description of a characteristic feature of the system to be developed or of the associated development process”.
Stakeholders and Goals
Persons, groups and organisations that are directly or indirectly affected by or have a concrete interest in the activities of a company are referred to as stakeholders. It is important for organisations to know their stakeholders, their goals and the significance of these goals for the stakeholders. Not every goal is equally important. Often the goals of individual stakeholders contradict each other and early communication is necessary to clarify such contradictions. Although this can lead to conflicts between stakeholders, the coordination of goals among each other is an essential basis for the later project. Without clarification, unnecessary efforts are invested in the implementation of contradictory goals, development costs rise and product quality suffers. In case of doubt, developers have to make decisions later that should have been clarified at the beginning of the development process. Dissatisfaction will spread among those involved and, in the worst case, products will be released that do not have a clearly defined range of functions and are difficult to market.
Goals and Requirements
There are many sources for the determination of requirements – e.g. requirements result from the architecture of a solution or the interaction of different systems. Requirements can also be derived from goals and, conversely, requirements can also be assigned to goals. This sounds easier than it often is in practice. A successful stakeholder analysis is a prerequisite for the determination of objectives. If not all necessary information is available, this leads to the interpretation of the findings and there is a risk of misjudgement.
The confrontation with goals and the resulting derivation of requirements offers another advantage: the success of a development can be determined on the basis of the achievement of goals. Goals are therefore not only guidelines for the project start, but also offer orientation in the course of the project. The implementation of requirements thus becomes essential for the achievement of the goals. In other words: The prerequisites for market success are only met if the stakeholder goals are met.
Realistic or Utopian Goals
There are always discussions about the definition of objectives. Should goals be formulated realistically and offer an incentive because they can be achieved at an affordable cost? Or may they also be formulated in a utopian way and thus stimulate new thought patterns and considerations – especially in times of disruptive business models – in order to explore new paths and options?
Basically
- goals must be clearly defined, i.e. as precisely as possible,
- measurable and
- be scheduled.
It is just as important for an organisation as it is for an individual to accept a goal as a challenge that must be mastered. Only if a goal meets the criteria mentioned and is accepted as such, there is a chance to achieve it, regardless of whether it has been formulated realistically or uptopically.
Download the Goal Diagram Guide for free now.
Everything important about Goal Diagrams at a glance.
- goals and the importance of their documentation
- definition goal diagram
- relations, key figures and features
- challenges and advantages
Knowledge on 8 pages to take away.
Documentation of Goals
Like requirements, goals change in the course of a project or development. In volatile markets and with regular communication with stakeholders, this is the rule rather than the exception. It is essential for the achievement of objectives that a change in objectives leads to clear measures and clear consequences. For this to succeed, goals must be documented, because otherwise a scope creep, i.e. an uncontrolled change of a development, threatens. Without documentation – a goal diagram is a form of documentation – new goals can quickly be taken more seriously than existing ones. This interpretation has far-reaching, unintended consequences. Only by documenting the goals, describing the relationships between the goals and weighting the goals will it be possible to focus permanently on the interests of the stakeholders.
Visualisation using AND/OR Graphs
A goal diagram consists of so-called AND or OR decompositions (hence the alternative name AND/OR graph).
In an AND decomposition, a goal is divided into subgoals, all of which must be fulfilled in order to achieve a goal. You can recognise AND decompositions in the goal diagram by solid lines. In our example, the goal “Market leadership with innovative product” is broken down into the subgoals ” development of quality product” and “development at low cost”. In an OR decomposition, a goal is also broken down into subgoals, of which only one must be fulfilled in order to achieve the overall goal. OR decompositions are represented by interrupted lines. In our example, “development at low cost” can be implemented in Asia or Eastern Europe.
Relationships in the Goal Diagram
Goals have relationships with each other. They can, for example, contradict or determine each other.
In our example, there is a conflict between the goal “development of quality products” and “development in Asia”. The reason for this conflict could be documented by a note in the diagram. Irrespective of this, however, it can be deduced from this that goal diagrams must be created individually. For many organisations, development in Asia is an everyday occurrence and does not represent a conflict. Why this is judged differently here, the organisation should absolutely clarify. It is also possible that one goal requires the fulfillment of another goal. This relationship can be identified in the goal diagram by a need or demand relationship.
Key Figures and Features
Targets can be quantified by assigning key figures. In goal diagrams, this is usually represented by the use of additional objects or by the documentation of the success factors in the goal description. Which success factors or key figures are used depends on the respective goal. A goal “market leadership with innovative product” as such is not very meaningful. It is not precisely formulated, it cannot be measured and it is not scheduled. Which market is being talked about here, in which time periods should the goal be realized, from which sales level, profit margin or market share does the goal prevail?
In the development of software, systems or services, goals are achieved through features. These can also be documented by additional objects or as an aspect in the goal description. The idea here is not, however, a detailed description of hundreds of features to achieve the goal, but – if meaningful and useful – the assignment of essential features. If a bank wants to offer transfers around the clock, it is important that an SMS tan can also be sent at night.
The Maintenance of Goal Diagrams
A goal diagram is a useful tool for documenting the goals of stakeholders, the importance of these goals for each stakeholder – multiple stakeholders can be represented in a goal diagram – and the relationships between the goals. Like many aspects of requirements engineering, it is advisable to regularly deal with the goals, because the goals and motives of individual stakeholders can change. Organisations do not have to find new goals every day, but as soon as new goals are formulated, they should be recorded and evaluated like the previously documented goals. A new orientation of the project may result – even if this does not only bring joy in organisations, what would be an alternative?
If goals shift in the course of a project, additional expenses may arise or expenses already incurred become useless. Here, too, a goal diagram provides a good basis for later discussions. The prerequisite for this is the versioning of the respective goal diagrams. A goal diagram is therefore not only an instrument for planning and control, it is also an instrument for safeguarding.
Notes:
Here you can find additional information from our blog:
The best way to a decision
Argue – but do it right
The three most common misconceptions about vision