Defining Scope, Goals & Success Criteria (SMART Goals, OKRs, the Triple Constraint)
Turning "make it better" into a scope statement, a measurable goal, and a deadline everyone actually agreed to.
Beginner
TopNotchNote
Notes that matter
scope: the boundary of the work
Scope is a precise description of what the project will deliver — and, just as importantly, what it will not. A scope statement that only lists inclusions invites arguments later about anything left unmentioned; a good one explicitly names exclusions too.
Scope creep — small, individually reasonable-sounding additions that accumulate into a much bigger project than what was approved — is rarely one dramatic decision. It is usually ten small "sure, we can squeeze that in" moments, none of which got checked against the charter.
smart goals
Turning a vague goal into something a team can actually plan against usually means running it through the SMART filter:
| Letter | Means | Bad vs good example |
|---|---|---|
| S | Specific | "Improve onboarding" → "Reduce new-user signup steps from 6 to 3" |
| M | Measurable | Has a number attached, not just a direction |
| A | Achievable | Realistic given the team's time and budget |
| R | Relevant | Actually connects to the business reason the project exists |
| T | Time-bound | Has a deadline, not "eventually" |
okrs: connecting a project to a bigger goal
OKRs (Objectives and Key Results) are a goal-setting format popular above the project level, at the team or company level. The Objective is a qualitative, ambitious statement ("become the fastest checkout in our category"); the Key Results are the 2–4 measurable numbers that prove it happened ("checkout time under 90 seconds," "cart abandonment under 12%"). A project's SMART goals should usually trace back to one of the company's OKRs — if they don't, that is worth asking about before the project starts.
the triple constraint
Every project balances three variables that pull against each other: scope (what gets built), time (the deadline), and cost (the budget, including people). Pushing on one almost always pushes on another — adding scope without adding time or budget usually means quality suffers instead, which is why some versions of the model draw quality as a fourth, central constraint rather than a free variable.
When a stakeholder asks for more scope with no change to the deadline or budget, the honest answer is "which of the other two moves, then?" — not a vague promise to make it work.
practical notes
Write the "out of scope" list before the "in scope" list is finished being negotiated — it is the part everyone forgets and the part that saves the most arguments later.
A success criterion that cannot be measured by the end of the project is not a success criterion, it is a hope. If nobody can check it off, cut it or rewrite it.