Planning on running a marathon in under four hours any time soon? Well, for many runners a marathon is the ultimate challenge, and four hours are the magical threshold for travelling the 42 kilometers. These four hours are a guiding line, they offer a means of comparison with other runners and are a source of motivation. They are the goal.
In the development of ideas, products and services the definition and handling of goals is not that easy. The more persons are involved the more goals there are. It is no rarity that these goals contradict each other. This is one of the reasons why Requirements Engineering puts a heavy emphasis on the elicitation of stakeholders and their goals. And visualizing these goals is a great means of improving the understanding of them. Enter Goal Diagrams.
What Makes a Reasonable Goal?
If goals function, they are a wonderful thing. But if you really do not want to run a marathon, the goal “Run Marathon in Under Four Hours” will not help you much. So what makes a goal a goal?
- Goals must be clearly defined, as precisely as possible: You want to run a marathon in Berlin and not use your car to travel the defined distance.
- Goals must be mensurable: You want to reach the goal in under four hours.
- Goals must be realistic: Well, let’s see if you can make it in 2:02:57, which is the current world record.
- Goals must be scheduled: The Berlin Marathon takes place on September 27, 2015.
If your goal meets these requirements and if you accept it as such (and as a challenge), and if it is ambitious but realistic, then this goal will work for you. Long story short: A goal must make sense to you, and only you.
Stakeholders and Their Goals
Do you always know who your stakeholders are? I mean all of them, and all of their goals, and the importance of each goal for the individual stakeholder? Not every goal carries the same weight, and some of them even contradict each other, which is of great importance when deriving requirements from these goals and trying to meet these requirements. A lot of questions arise when dealing with stakeholders and their goals.
Sometimes this leads to some strange behavior: Stakeholders are not even interviewed any more. Well, this might work for some. But there is word of certain products on the market that no one really needs and nobody ever buys. Ok, maybe not a good solution then.
Goal diagrams help to chart stakeholder goals, partial goals and possible conflicts. Take a look at the diagram below. “Ensure Competetiveness for the Next Decade” is of great importance for stakeholder Alan Smithee. He wants to achieve this goal with a highly-innovative product, a strong customer loyalty and low development costs. The low development costs are to be realized by either developing the product at a low-cost location or by purchasing the partial systems cost-effectively.
As you can see, there is a conflict between the goals “Highly-innovative Product” and “Development at a Low-Cost Location”. There seems to be a concern that developing innovative technology might be difficult in a faraway country. This conflict has to be resolved, ideally in dialog with Alan Smithee and other stakeholders.
Goals and Requirements
There are multiple sources for requirements. e.g. the system architecture or the way a system interacts with other systems, and of course goals. This is why a Goal diagram cannot only chart goals, partial goals, conflicts, weights and different relationships to stakeholders, but also the relationships between goals and requirements.
If you are working in projects and are busying yourself with stakeholders and their goals, diagrams might be an effective and easy way for you to visualize interdependencies between all relevant elements. Using goal diagrams is not only easy but also a lot of fun! They help you to better understand your stakeholders as well as their goals, and to find ways to question or to include them in you project at an early stage.
And if you plan on running a marathon soon, why not using a goal diagram during your preparation…?