Stakeholders and verifiable project goals — questions

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 (ÖNORM ISO 21500). All three parts count: someone with no influence is still a stakeholder, and someone who only believes they are affected will act as if they were.

The point of the list is not the names. Every stakeholder pursues interests of their own: the trainer wants to be faster than with paper, the committee wants to show where the fees went, the members want as little as possible stored about them, the operator wants not to be woken up at night. Those interests are legitimate, they conflict with each other, and none of them is written down anywhere unless you ask.

Projects fail at the acceptance because an interest was never asked about — most often that of the operator or of the people whose data is processed, because neither appears in the conversation where the idea is born.

Points the answer must contain:

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

Three ingredients make the difference:

The test is not whether the sentence sounds professional. It is whether somebody who was not involved can check it without asking you what you meant. "Fast" fails that test: fast compared with what, on which machine, with how much data? Two people can both be honest and disagree about whether it was met, which means the goal cannot settle anything at the acceptance.

Wishes are allowed to exist — write them down as wishes. What is not allowed is calling one a goal, because then the project has a yardstick that cannot measure.

Points the answer must contain:

Because they cost one line each and prevent the two most expensive conversations of the year.

The first conversation is scope creep during the project: in March somebody asks "could it also do payments?", and without a non-goal there is no cheap way to say no — the discussion starts from scratch and usually ends with a yes that nobody had time for. With the line written down, the answer is "that is out of scope; if we want it, we change the charter deliberately".

The second is disappointment at the acceptance: the client expected the Excel import because nobody ever said it was not coming. A non-goal is the cheapest form of expectation management there is.

A non-goal is not a promise never to do the thing. It says: out of scope for this project, in this year. And it must not be a secret plan — "no mobile app for now" is a roadmap entry, not a non-goal, and it will be read as a promise.

An empty non-goals section is not accepted in this course: if nothing is out of scope, the scope was not thought through.

Points the answer must contain:

Because it measures your effort instead of the result. It is satisfied the moment the API exists, whether or not anybody can do anything useful with it — and it would still be "achieved" if the trainer never manages to record a single session.

Nobody outside the team cares how the thing is built. The client cares what somebody can do afterwards that they could not do before; the API is a means, and means belong in the design, not in the goals.

There is a second, quieter problem: a goal phrased as an implementation decision forbids every other implementation. If halfway through it turns out that a server-rendered page would do the job in a third of the time, the charter now says no — for no reason anybody would defend if asked.

Rewritten: "A trainer can record attendance for a session from the phone at the door and see it in the club database within a minute." That says what changes for a person, is checkable by somebody who was not there, and leaves the technical route open.

Points the answer must contain:

Scope and quality, schedule, cost. The first has two halves — the scope (which functions) and the quality (how well they must work). The schedule is when it is there, the cost is what it takes: effort, money, devices, licences.

The three are coupled, so a goal that names only one of them is not agreed yet. In a school project the deadline is fixed by the calendar and the cost is fixed by the hours that actually exist, which leaves scope and quality as the only adjustable dimension. A team that refuses to cut scope cuts quality instead, quietly, somewhere around March.

An outcome goal says what exists at the end and is checked at the acceptance, on the product: "members can be enrolled in courses online". A process goal says how the work is done and is checked during the project, on the way of working: "the team meets weekly and records its decisions in the repository".

Both belong in the charter, each marked as what it is. The usual failure is a charter full of process goals — meetings, tools, methods — with no statement of what will exist in June.

Points the answer must contain:

WHAT FOR? FOR WHOM? END RESULT? SUCCESS CRITERIA?

The fourth question is the one that turns a wish into a goal, because it forces an observable condition. The first two occasionally delete a goal outright — which is a good outcome and is far cheaper in October than in May.

Applied to "the app should be fast": what for — the trainer records attendance during the session, not afterwards; for whom — the trainer; end result — an attendance list that opens while the group is still lining up; success criterion — under one second for a group of 30 on the lab laptops.

Points the answer must contain:

Goals in one charter influence each other, in three ways:

A goal conflict is not a planning error, it is the normal state. What is an error is leaving it unnamed: the team then averages the two, delivers both badly and discovers at the acceptance which one actually mattered. The charter’s job is to say which of the two wins when they collide.

Below the goals sit the sub-goals, decomposed until each is checkable on its own — and they are not equally important. Weighting them is a small weighted scoring: each sub-goal gets a weight with a stated reason, and "what do we build first" becomes a calculation instead of a mood.

Points the answer must contain:

An overall goal like "trainers spend less time on administration" is agreed but cannot be acted on or checked. Operationalising it means breaking it down until every part can. The tool is the goal hierarchy: the overall goal at the root, goal classes below it (technical, economic, ecological, …), and sub-goals refined over one or more levels until each is described by a criterion — a property of the solution — and an extent — how far it has to be realised. "The attendance list for 30 members opens in under one second" is such an operational goal.

The hierarchy can be built three ways:

The hierarchy also checks itself: an operational goal that cannot be traced up to the root is a wish that slipped in.

Points the answer must contain: