What a Project Is, and What 'Done' Actually Means

The part overview framed project management as the craft of turning a goal into a delivered outcome. Before you can manage that journey, you have to be honest about what kind of thing you are managing — and about the single most-skipped step that quietly sinks more projects than any other: deciding, in plain words, what “done” means.

This page does two things. First, it defines what a project actually is, so you can tell it apart from ongoing work. Second, it shows you how to write a definition of done that is concrete enough that two people reading it would build the same thing. Get this right and most of the chaos in later pages never happens. Skip it and no amount of planning will save you.

A project has three defining traits

The word “project” gets thrown at almost any pile of work. But a real project has three traits, and if any one is missing you are probably looking at something else — a routine, a habit, or a wish.

1. It is temporary

A project has a beginning and it will stop. This is what separates a project from operations — the ongoing, repeating work that keeps an organisation running.

Serving coffee every day is operations. Opening a second cafe is a project. Answering support tickets is operations. Rolling out a new support system is a project. A hospital ward treating patients week after week is operations; moving that ward to a new building is a project.

The distinction matters because temporary work needs different handling. Operations you optimise and sustain. A project you finish — and “finishing” only makes sense if you know what the finish line looks like.

2. It pursues a specific goal

A project exists to produce a particular result, not just to keep people busy. “Improve the website” is not a goal; it has no edge you could ever reach. “Cut the checkout page from five steps to two so more shoppers complete a purchase” is a goal — specific, and you can tell when you have hit it.

If you cannot name the specific result, you do not yet have a project. You have an area of concern.

3. It has a clear end

Because a project is temporary and aimed at a specific result, it must have a recognisable end. The end is not “when we run out of time” or “when everyone gets bored.” It is the moment the specific result exists and has been accepted by whoever asked for it.

That moment has to be defined in advance. A project without a defined end does not end — it just slowly stops mattering while still consuming people’s evenings.

Operations                 Project
----------                 -------
repeats indefinitely       temporary — it stops
keeps a result steady      creates a new result
"how well are we running?" "are we finished yet?"

Why an undefined ‘done’ makes projects drift forever

Here is the quiet killer. Most projects that “never end” did not fail because the work was too hard. They failed because nobody ever wrote down what finished looked like, so there was always one more thing that might count as part of it.

When “done” is undefined, three things happen, every time:

• Every new idea looks in-scope. With no boundary, any suggestion — “while we’re at it, could it also…” — sounds reasonable. The work quietly expands. (This is scope creep, and an undefined done is where it breeds.)
• Nobody can honestly say it’s finished. Without agreed criteria, “are we done?” becomes a matter of opinion, and someone’s opinion is always “not yet.”
• People build different things. Everyone fills the blank with their own picture. The designer thinks done means beautiful; the boss thinks done means shipped; the engineer thinks done means bug-free. All three are “working hard” and none of them are building the same product.

The common trap — treating ‘done’ as obvious

The most common mistake is assuming everyone already knows what done means, so writing it down feels like bureaucracy. It isn’t. The whole point is that “done” feels obvious and different to each person — and those differences stay invisible until they collide near the deadline. Writing it down early is cheap. Discovering the disagreement in the final week is expensive.

Defining done: observable, agreed criteria — not a vague aspiration

A definition of done is a short, written list of criteria that must all be true for the work to count as finished. The two words that do all the work are observable and agreed.

Observable means someone other than you could look and confirm it — no mind-reading, no “it feels ready.” Compare:

Vague aspiration              Observable criterion
----------------              --------------------
"The report is good."         "The report covers all four regions,
                               fits on two pages, and the finance
                               lead has signed off."

"The ward move is smooth."    "All 24 beds are in the new ward, every
                               patient's records transferred, and the
                               charge nurse confirms the first shift
                               ran without a safety incident."

"The app is finished."        "A new user can sign up, place an order,
                               and receive a confirmation email, on both
                               phone and desktop, with no known critical
                               bugs."

Notice each observable version could be checked by someone who wasn’t in the room. That is the test. If confirming a criterion requires a debate, it isn’t observable yet — sharpen it until a stranger could tick the box.

Agreed means the people who matter — whoever asked for the work, and whoever is doing it — have seen the list and said “yes, that’s it.” A definition of done that lives only in your head is not agreed; it is just your private hope. Read it aloud, get a nod from the person who will accept the work, and keep the list where everyone can see it.

In practice — the one-page checklist

A warehouse team was told to “get ready for the holiday rush.” Vague. They turned it into a checklist anyone could verify: seasonal staff hired and trained, extra shelving installed, the two busiest aisles restocked to double depth, and a dry run completed with picking times under the target. Suddenly “ready” was five ticks, not a feeling. The night before the rush, they knew exactly whether they were done — and so did their manager.

Outcome versus output: the change versus the thing

There is one more distinction that keeps projects honest, and it trips up experienced people constantly.

• The output is the thing you produce — the report, the new ward, the app, the trained staff.
• The outcome is the change in the world you actually wanted — better decisions from the report, safer care in the ward, more customers checking out, a rush handled without collapse.

You can deliver the output perfectly and still miss the outcome. A team ships a beautiful new feature (output delivered) that nobody uses (outcome missed). A cafe opens a second location on time and on budget (output) that loses money because it’s on the wrong street (outcome missed).

Why does this matter for defining done? Because it tells you what your success criteria should point at. The output being delivered is the minimum. But a good project keeps the outcome in view, so that when someone proposes a change, you can ask the clarifying question: “does this get us closer to the outcome, or is it just more output?”

Output  = the thing you produce      (did we build it?)
Outcome = the change you wanted      (did it work?)

Case study — the highway that was built perfectly

Large public projects are full of outputs delivered without outcomes. A well-known pattern, documented across decades of infrastructure research (see the work of Bent Flyvbjerg from the 2000s onward), is the road, bridge, or rail line delivered as specified — the output — that draws far fewer users, or costs far more to run, than promised — the outcome never materialising. The lesson isn’t that these teams were lazy; many hit their output targets exactly. It’s that a project measured only by “did we build the thing?” can succeed on paper and fail in reality. Name the outcome, and you keep asking the question that matters.

The one-sentence objective anyone can repeat

Pull all of this together and you get the most useful artefact in project management: a single sentence stating the objective and how you’ll know you succeeded. If everyone on the team can repeat it from memory, you have alignment. If they can’t, you don’t — and you found out cheaply.

A reliable shape:

We are [doing what] for [whom]
so that [the outcome],
and we'll know we're done when [the observable success criteria].

Worked example, for a clinic:

We are moving the physiotherapy service to the ground floor for our
mobility-impaired patients so that they no longer need the lift or the
stairs, and we'll know we're done when all equipment is installed
downstairs, the first full week of appointments has run there without
incident, and the lead physiotherapist has signed off.

That one sentence carries everything from this page: the specific goal, the clear end, the outcome (not just the output), and observable, agreed criteria. Write it before you plan a single task. It becomes the thing you point back to every time someone asks “should we also…?” — which is exactly the conversation the next page prepares you for.

How it connects

This one sentence is the seed of everything ahead. Scoping and gathering requirements turns its “what” into a bounded list of what’s in and out. Breaking work down turns that list into tasks. And scope creep and the iron triangle is, at its heart, the discipline of protecting this sentence from a thousand well-meaning additions.

Try this

Take a real project you’re involved in this week — at work or at home — and write its one-sentence objective using the shape above: “We are [doing what] for [whom] so that [the outcome], and we’ll know we’re done when [observable criteria].” Then do the honest test: send it to one other person on the project and ask them to say what “done” means in their own words. Where their answer differs from your sentence is exactly where the project would have drifted. Fix the sentence until you both read it the same way.

Reflect

1. Think of a project you’ve seen that “never ended.” Looking back, was “done” ever actually written down and agreed — or was it always a matter of opinion?
2. For a project you’re on now, can you state its outcome (the change in the world) separately from its output (the thing produced)? Which one is the team actually being measured on?
3. Take one criterion you’d use to call your project finished. Could a stranger confirm it without asking you what you meant? If not, how would you sharpen it?
4. Whose “yes, that’s it” would you need for your definition of done to count as agreed — and have you actually got it?
5. If you asked three people on your project to describe done right now, how far apart would their answers be — and what would that gap cost you later?

Show reflections

1. The useful realisation is that “never-ending” projects almost always trace back to an undefined done, not to difficulty. If done was never written and agreed, drift was baked in from day one — and the fix is upstream, not more effort.
2. A strong answer separates the two cleanly and notices when the team is measured only on output (“did we ship it?”). That’s the warning sign that the outcome could quietly fail even as the project “succeeds.”
3. The test is whether an outsider could tick the box. If confirming it needs your explanation, it’s still an aspiration, not an observable criterion. Sharpen by naming what could actually be seen, counted, or signed off.
4. “Agreed” needs a specific person — usually whoever will accept or pay for the work. If you haven’t literally shown them the list and heard a yes, you have your hope, not their agreement, and the collision is still coming.
5. The bigger the gap, the more the project is really several different projects being built in parallel. Naming the gap now is cheap; it turns into rework, arguments, and blown deadlines if you leave it until delivery.