Why the project exists and what counts as success

AI for project management · Lesson 1 / 20

A goal is not a list of work

Most of the projects I ran that ended badly did not fail on dates. They failed on meaning: the team delivered exactly what was written down and the sponsor said this is not what we needed. The cause is always the same. At kickoff we froze the scope of work and never froze the change that scope was supposed to produce. Until someone can answer what will be different when we finish, every argument about priority comes down to opinion, and the loudest person wins.

Three questions that get collapsed into one

Why. Which business pain goes away. Counted in money, hours, tickets, or removed risk.
What. The result we hand over. That is scope, and scope is not a goal.
How we will check. An observable sign you can measure a month after delivery without asking anyone for an opinion.

A usable success criterion has one property: it can be failed. If a criterion cannot possibly come out negative, such as improving the working experience, it is a mood, not a measure. Test it by asking which measured value would force us to admit the project did not work.

Goal card: six lines at kickoff

Pain today: [what hurts, with a number]
Who feels it: [role, not department]
What we change: [project result in one line]
Success signal: [metric + value + measurement date]
Failure signal: [value at which we call it a miss]
Who confirms the result: [one name]

A model helps at exactly one thing here: it turns a vague paragraph into structure and asks the questions you skipped. It does not know your company and will quietly insert generic metrics like NPS or time to market unless you supply the facts.

Here is my project described in plain words: [text].
Ask me 7 clarifying questions that must be answered before
a success criterion can exist. Do not propose metrics until
I answer. Then assemble the six-line goal card and list
separately everything you inferred on your own.

Insight. A success criterion with no measurement date always gets interpreted after the fact in favour of whoever is reporting.

Common mistake. Setting the goal as shipping on time. A deadline is a constraint, not a goal, and you can ship on time while changing nothing.

Pro tip. Ask the sponsor to describe failure before describing success. People state failure far more honestly and concretely.

Cheat sheet

A goal describes a change, not a delivery.
A criterion you cannot fail is not a criterion.
The result needs one name behind it, not agreement with the business.
The model structures wording, you supply the facts.

1. How does a project goal differ from its scope?

2. Which success criterion is unusable?

3. What does a model do worst during framing?

🔒 Answer the question correctly to move on to the next lesson.