Learning outcomes

  • Say what a stakeholder is, give examples, tell internal from external ones, and explain that each of them pursues interests of their own

  • Turn a wish into a goal that can be verified by someone else

  • Distinguish goals from non-goals and explain why non-goals are written down

  • Name the three dimensions a project goal is measured in, and tell outcome goals from process goals

  • Agree a goal using the four questions: what for, for whom, end result, success criteria

  • Recognise conflicting, complementary and independent goals, and weight sub-goals instead of pretending they are equal

  • Explain how a goal hierarchy operationalises the overall goal, and build one top-down, bottom-up or with the mixed approach

Stakeholders

A stakeholder is a person, a group or an organisation that is affected by the project, can affect it, or believes itself affected by it — the definition of ÖNORM ISO 21500. The last third matters: someone who wrongly believes they are affected still acts, and still costs you a meeting.

Every stakeholder pursues interests of their own, and those are not yours. They are usually legitimate, they routinely conflict with each other, and none of them is written on the ticket. That is the whole reason for listing them: a project fails at acceptance because somebody’s interest was never asked about, not because somebody was unknown.

Internal stakeholders External stakeholders

Who

inside the organisation running the project: client, project management, the team, the departments whose work changes

outside it: users, customers, suppliers, authorities, data protection, the public

In a school project

the team, the teacher supervising it, the school’s IT operations

the club or company the project is for, its members, the parents, whoever hosts the server afterwards

Typical interest

a result that is defensible, on time, with no extra work landing on them

a system that helps them rather than one that is merely delivered
Table 1. Examples and what the interest behind them is
Stakeholder Their interest

the trainer who records attendance

to be finished faster than with paper — otherwise they simply will not use it

the club’s committee

to be able to show where the membership fees went

members whose data is stored

that as little as possible about them is stored, and that they can have it deleted

whoever runs the server afterwards

not to be woken up by it, and not to be left with something they cannot patch

Goals that can be verified

A goal is verifiable when somebody who was not involved can check it without asking you what you meant.

Wish Verifiable goal

"The app should be fast."

"Opening the attendance list for a group of 30 takes under one second on the lab laptops."

"Users should like it."

"A trainer can record a full session without written instructions, in under two minutes."

"The data must be safe."

"Personal data is stored only for members with a signed consent, and can be deleted on request within one working day."

The pattern: an observable action, a measurable condition, a context in which it holds. If your goal has none of those, it is a wish — write it down as one, but do not call it a goal.

Two properties make a goal a good one: it is achievable, and it is quantifiable — whether it was reached can be measured. And it prescribes no solution: "trainers record attendance digitally" is a goal, "we build a React app" is a decision that comes later.

Scope, schedule, cost

Project goals are stated in three dimensions, and a goal that names only one of them is not yet agreed.

goal dimensions

They are coupled: hold two of them and the third follows. In a school project the schedule (Termine) is fixed by the calendar and the cost (Kosten) is fixed by the hours you actually have, which leaves exactly one adjustable dimension — scope and quality (Leistung). A team that refuses to cut scope ends up cutting quality instead, silently.

This dimension has two halves and both belong in the goal: the scope (which functions) and the quality (how well they have to work — the non-functional side, see sdd-why-specs).

Outcome goals and process goals

Outcome goal (Ergebnisziel) Process goal (Vorgehensziel)

Says

what exists at the end

how the work gets done on the way there

Example

"members can be enrolled in courses online"

"the team meets weekly and keeps decisions in the repository"

Checked

at the acceptance, on the product

during the project, on the way of working

If it is missing

nobody knows what was promised

the result may be right and nobody can repeat it

Both belong in the charter, marked as what they are. The frequent mistake is a charter full of process goals — meetings, tools, methods — with no statement of what will exist at the end.

Operationalising goals: the goal hierarchy

An overall goal such as "trainers spend less time on administration" is true, agreed — and impossible to act on or check. Operationalising it (Operationalisierung) means breaking it down until every part can be acted on and checked. The tool for that is the goal hierarchy (Zielhierarchie).

It starts from a root, the overall goal (Gesamtziel). Below it sit goal classes — technical, economic, ecological, … — and below those the sub-goals, refined over one or more levels until each one is described by a criterion (Kriterium) and an extent (Ausmaß). A criterion is a property of the solution; the extent says how far it has to be realised for the goal to count as reached.

goal hierarchy

Only the bottom row can be implemented and checked at the acceptance. The rows above explain why it is there — and a box at the bottom that cannot be traced up to the root is a wish that slipped in.

The hierarchy can be built in three ways:

Approach How it works

Top-down (Top-down-Ansatz)

start from the overall goal and decompose and refine it, level by level, down to sub-goals with criterion and extent

Bottom-up (Bottom-up-Ansatz)

detailed goals already exist — wishes from the interviews, requirements of the club. They are grouped by their contribution to the overall goal and assigned to goal classes

Mixed approach (gemischter Ansatz)

neither pure form works best, so the hierarchy is built iteratively, using both directions in turn

Top-down alone produces sub-goals nobody checked against what is possible; bottom-up alone produces a pile of details without a common direction. A school project is mixed in practice: the client brings the overall goal, the elicitation brings the details, and the charter is where both meet.

The four questions of a goal agreement

Before a goal is written down it should survive four questions. They come from the Coverdale method and they are the fastest test there is.

Question What it forces out

WHAT FOR? (Wozu?)

the purpose behind the goal. If the answer is "because it was asked for", the goal is not understood yet

FOR WHOM? (Für wen?)

the stakeholder who benefits. A goal without a named beneficiary is usually somebody’s hobby

END RESULT? (Endergebnis?)

what concretely exists when it is reached — a thing, not an activity

SUCCESS CRITERIA? (Erfolgskriterien?)

how a third party recognises that it was reached

Question four is the one that turns a wish into a goal, and questions one and two are the ones that occasionally delete a goal entirely — which is a good outcome, and much cheaper now than in May.

How goals relate to each other

Goals in the same charter are not independent, and the relationship has a name.

Relationship Meaning

Conflicting goals (Zielkonkurrenz)

reaching one makes the other harder — more functions against an earlier deadline. Must be decided, not averaged away

Complementary goals (Zielkomplementarität)

reaching one helps the other — a clean data model helps both the export and the deletion requirement

Independent goals (Zielneutralität)

the two do not influence each other. Rarer than it looks

Conflicting goals are the interesting case: it is not a planning error, it is the normal state, and the charter’s job is to say which of the two wins when they collide.

Sub-goals and their weight

The sub-goals (Teilziele) of the hierarchy are not equally important — pretending that they are is how a project ends up with a perfect export function and no working enrolment.

Weighting them is a small weighted scoring (Nutzwertanalyse): give each sub-goal a weight, state what the weight is based on, and the decision "what do we build first" becomes a calculation rather than a mood. The method itself is taught in year 4, in governance-weighted-scoring.

Non-goals

Non-goals (Nicht-Ziele) are what the project explicitly does not do. They cost one line each and prevent the two most expensive conversations of the year: scope creep during the project, and disappointment at the acceptance.

Non-goals:
  - no mobile app, browser only
  - no payment handling
  - no import from the old Excel sheets

A non-goal is not a promise never to do it. It is a statement that it is out of scope for this project, in this year.

Decisions

  • Every project charter names its stakeholders, marked as internal or external, with the interest each of them pursues.

  • Goals are written so a third party can check them; unverifiable goals go back to the team for rewriting.

  • Every goal states scope and quality, schedule and cost, and is marked as outcome goal or process goal.

  • Competing goals are named as competing, with the decision which one wins.

  • Every charter has a non-goals section. An empty one is not accepted — if nothing is out of scope, the scope was not thought through.

Pitfalls

  • Only listing users and forgetting whoever has to operate or approve the thing.

  • Listing stakeholders without their interest. The name alone tells you nothing about what they will do at the acceptance.

  • Goals that measure your effort instead of the result ("we implement a REST API"). Nobody outside your team cares how it is built; they care what it does.

  • A charter of pure process goals: much method, no promised result.

  • Goals written after the fact, matched to what was finished. That is what the frozen charter exists to prevent.

  • Non-goals that are secretly plans ("no mobile app for now"). Then it is not a non-goal.

Terminology

Deutsch English

Anspruchsgruppe, Beteiligter

stakeholder

interne / externe Stakeholder

internal / external stakeholders

Zielsetzung

objectives

Ergebnisziel

outcome goal

Vorgehensziel

process goal

Leistung, Termine, Kosten

scope and quality, schedule, cost

Umfang

scope

Qualität

quality

Wozu? Für wen? Endergebnis? Erfolgskriterien?

What for? For whom? End result? Success criteria?

Zielkonkurrenz

conflicting goals

Zielkomplementarität

complementary goals

Zielneutralität

independent goals

Teilziel

sub-goal

Nutzwertanalyse

weighted scoring, utility analysis

Nicht-Ziel

non-goal

Operationalisierung

operationalisation

Gesamtziel, Hauptziel

overall goal

Zielklasse

goal class

Kriterium, Ausmaß

criterion, extent

Zielhierarchie

goal hierarchy

Top-down-Ansatz, Bottom-up-Ansatz

top-down approach, bottom-up approach

gemischter Ansatz

mixed approach

überprüfbar

verifiable

Einflussnahme

influence

Further reading

  • Template templates/governance/projektauftrag.adoc — the goals table you fill

  • Module governance-weighted-scoring — how sub-goals get their weights (year 4)

  • Module governance-acceptance — where these goals are checked again

  • Module sdd-why-specs — where the quality half of the goal is written down

  • ÖNORM ISO 21500 — the stakeholder definition used above

  • Manz textbook, chapter 2 lesson 3 "Zielbestimmung" — the goal hierarchy, the three approaches and the goal relationships