Specifying Goals

Type: Rules
Sources: various authors, including D. Doering ('Die Logik des Misslingens'); Tom Gilb; Jürgen Appelo; my own experience


to describe goals (of an organization, of an IT system, …) in a clear and useful fashion
Note: like always, goals are a kind of requirement. So it doesn't hurt at all if you use the rules to lower levels of requirements, e.g. system requirements.

Rules and Notes

R1: Seperate different goals, even if they seem interrelated, for you can reference them. This is of major importance for goals which somehow constrain the rest of the set. Break a goal down as soon as you realize it has more than one measurable dimension.

R2: Name each goal unambiguously, use a short name. Rank the goals by relative priority. This avoids conflict.

R3: use the PAM structure:
P urpose
A dvantage
M easure
Purpose: Supplies a higher level rationale for the goal. Understanding the why gives you freedom in finding proper solutions.
Advantage: Differentiates the goal from others and from non-goals. So you also know what NOT to achieve.
Measure: Keeps you on track and supports your communication with the higher management. Gives you a clear sense of 'done' and provides satisfaction at the end. Makes it possible to evaluate measures concerning suitability and effectiveness.

Note: go see Tom Gilb's Website for more information on powerful forms to use when specifying goals.

R4: Iterate! There's nothing bad about changing goals along the way. Please restate the set of goals, though.

R5: Avoid comparatives, work until you know what they really mean. Try decomposing a comparative goal into a number of specific goals.

R6: Mind if you specify positive (get to x) or negative goals (avoid y). A positive goal gives you fewer opportunities to succeed than a negative goal, which can be good or bad. Be aware of the possibility that someone states a goal negatively because he does not know how it can be stated positively. You're bound to fail, not within the scope of the stated goals but in the scope of the real goals. Negative goals tend to be too global.

R7: global and specific goals are good, unclear goals are bad. try to make a global goal specific, however. if your global goal is unsufficient and you cannot come to a specific goal, try stating intermediate goals that maximise the opportunity of success. How? By specifying many subgoals with a good chance of reaching them. another way to put it is: try to set goals so, that by adhering to them you will be in a better tactical position towards your strategy.
global: the future state is determined by few (sometimes only one) criteria
specific: the future state is determined by many criteria
unclear: the future state is not determined by a sufficient number of criteria

R8: be extremely suspicious if you seem to have only one goal. this situation is very rare and the phenomenon indicates you forgot a number of goals.

R9: with your goals, define end-states, not suggested ways of getting there.

R10: here's an additional checklist to use on your goals (abridged version of Tom's)

  1. Is each goal, each promised result specified clearly enough to measure or test?
  2. Are the ultimate ends clarified? What goal is it intended to serve?
  3. Are all assumptions, risks and uncertainties brought out explicitly?
  4. Do all people who need to understand the goals have the same interpretation? Check by asking people to write their understanding down. Discuss results.

R11: Check each goal: does it give direction, can it be used to improve morale, and does it give awareness of context (also see here)?

R12: Do not tie goals to (monetary) rewards (aka Abused Management By Objectives (AMBO))!

Costs, Savings

<What does it take to implement those rules? What does it give?>

Side effects

  • You will find wonderful new ways of reaching the goals, because of the freedom you gain by not assuming solutions as ultimate goals.
  • In decision making along the way, you will know what to do.
  • You will benefit by always having a clear set of objectives. No more guesswork, no excuses!


"Begin with the end in mind." — Stephen Covey
"An agile goal is a 'higher purpose,' which transcends the goals of all stakeholders." — Jürgen Appelo

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License