Define done by describing the evidence that must exist when the project is complete. Name the deliverable, the quality checks it must pass, where it must go, who must accept it, and which tempting extras are outside the current scope. If another person cannot verify completion from your definition, the finish line is still too vague.
This matters beyond formal project management. A portfolio, training plan, event, room renovation, research paper, product launch, or creative release can all keep expanding when "done" means nothing more precise than "I feel satisfied." Feelings can inform the work. They should not be the only completion test.
A definition of done is a boundary, not a wish
A goal describes the change you want. A task describes an action. A definition of done describes the state that lets you stop, deliver, or move to the next stage.
"Build a useful website" is a goal. "Write the home page" is a task. A useful definition of done might say that the five agreed pages are live, the contact form reaches the correct inbox, the links have been checked, the owner has approved the final copy, and future feature ideas have been moved to a separate list.
The definition does not have to predict every step. It has to make completion observable. That protects the project from two opposite failures: stopping while essential work is missing and continuing after the agreed work is complete.
Why projects expand near the finish line
Early in a project, the gap is obvious. The draft does not exist. The event is not scheduled. The room is not painted. Later, progress becomes harder to judge. The main thing exists, but review reveals improvements, new ideas, and small imperfections. Every open possibility can begin to look like a requirement.
That is where scope quietly changes. A useful improvement becomes a new feature. A preference becomes a defect. An idea for the next version becomes a reason the current version cannot ship. The project is still moving, but the finish line is moving with it.
If the work is genuinely blocked, diagnose the specific constraint before demanding more effort. If the work is progressing but keeps growing, define done before adding another round.
Use five parts to define done
1. Name the deliverable
State what will exist, not merely what you will spend time doing. "Research competitors" has no natural ending. "Create a two-page comparison of five relevant competitors, including audience, offer, price position, and one open question for each" gives the work a visible form.
The deliverable can be a document, decision, live page, repaired object, completed session, approved design, or recorded result. Use a noun you can point to.
2. Set the acceptance checks
List the small number of conditions that make the deliverable usable. These are not every preference you could apply. They are the checks that protect the purpose of the work.
| Vague finish line | Verifiable acceptance check |
|---|---|
| Make the presentation look polished | Use the approved template, remove placeholder text, and verify every chart label |
| Get the event ready | Confirm the venue, attendee instructions, run of show, and named owner for each on-site task |
| Finish the portfolio | Publish three selected projects with a short role, process, and outcome section for each |
| Clean up the process | Document the current steps, remove one duplicate handoff, and test the revised flow once |
Good checks are specific enough to inspect and few enough to remember. If the list becomes a second project, separate the essential gate from optional refinement.
3. Define delivery, not just creation
A file on your desktop may be finished as a draft and unfinished as a project. Name the destination and the next owner. Does the work need to be published, submitted, installed, presented, archived, handed over, or approved?
Add the final transition to the definition: "submitted through the course portal," "shared with the client," "placed in the team folder with access confirmed," or "published and checked at the live address." Creation and delivery are different states.
For work that changes hands, the related guide to a project handoff document covers the context the next owner needs after delivery.
4. Write the exclusions
Most projects need a short not-now list. Name what the current version will not include: a second audience, an extra platform, custom photography, an advanced feature, a complete redesign, or research beyond the agreed sample.
An exclusion is not an admission that the idea is bad. It is a decision about sequence. Move credible ideas to a later-version list so they are preserved without holding the present work open.
5. Set the reopen rule
Done should be durable, but it does not have to mean permanent. State what evidence would justify reopening the work. A factual error, failed test, owner rejection, broken link, safety issue, or new requirement may be enough. A passing preference that appeared after delivery may not be.
This rule prevents endless polishing while leaving a responsible path for correction. If the reason for changing direction matters later, record it in a short decision log.
Define done at the right level
A project, milestone, and task need different finish lines. Do not ask one checklist to govern all three.
- Task done: the immediate action produced its expected result.
- Milestone done: a meaningful stage is ready for the next stage or owner.
- Project done: the promised outcome has been delivered, accepted, and closed within the agreed scope.
For example, "draft the survey" can be a completed task. "Survey approved and ready to send" can be a completed milestone. "Responses collected, findings delivered, and source files archived" can define the project finish. Each level answers a different question.
Do not confuse complete with perfect
Perfect has no stable test. Complete can have one.
A high standard belongs inside the acceptance checks: accurate figures, reviewed copy, working links, safe construction, correct dimensions, or whatever quality the purpose requires. Perfection adds an unlimited demand to notice and eliminate every possible weakness, including weaknesses that do not change the result.
Before another revision, ask three questions:
- Which acceptance check currently fails?
- What reader, customer, teammate, or outcome is affected?
- Will this change improve the promised result, or only make the project feel newer?
If no check fails and no meaningful outcome improves, the revision may belong in a future version. Finish the current promise first. The guide to finishing a side project while working full time can help when limited attention, rather than an unclear finish line, is the main constraint.
A ten-minute definition of done
Use this template before the next work session:
- Deliverable: What exact thing will exist?
- Purpose: What must it help someone do?
- Acceptance: Which three to five checks must pass?
- Delivery: Where will it go, and who accepts or uses it next?
- Exclusions: What is explicitly not part of this version?
- Reopen rule: What evidence would justify more work after delivery?
Read the definition as if you were the person receiving the result. Remove words such as "better," "professional," "complete," and "polished" unless the sentence explains how someone can verify them. Then keep the definition visible beside the work.
If a simple off-hours uniform fits the sessions when you are building, the live Self Made Club Joggers are a brushed-fleece, tapered option with pockets and the white ascending mark on the leg. Choose them for the role they serve in your routine. The garment does not finish the project; the boundary and the work do.
Finish the promise you actually made
A strong definition of done does not lower ambition. It separates the current promise from every possible future improvement. Name the deliverable, protect the essential quality, complete the delivery, preserve the later ideas, and stop when the agreed evidence exists.
Then close the project cleanly. Learn from it. Build the next version on purpose. Find more practical frameworks for creating and finishing in The Self Made Journal.
0 comments