The Definition of Done

Bake Me a Cake

Tell someone to bake a cake, and you will get a cake. It might not be the one you actually wanted. Tell them to bake a cake that a specific person really likes, made out of ice cream, in their favorite flavor, sturdy enough to hold lit candles through a full round of happy birthday, and ready by tomorrow noon, and something different happens entirely.

With that level of clarity, the outcome lands right nine times out of ten, often with almost no back-and-forth at all. The difference was never the skill of the person baking the cake. It was whether “done” was ever actually defined before the work began.

The Real Pain: Rework from an Unclear Finish Line

This same gap shows up constantly in delegation, especially as a team grows. A task gets written on a board or sent in a message, something like “create this crew matrix for this contractor.” Whoever picks it up has to guess at what that actually means, dig for context, make assumptions, and deliver something that may or may not match what was actually needed.

That guessing game is not a minor inconvenience. It produces real rework, real frustration, and real wasted hours, all because the finish line was never clearly described in the first place.

The Failure Pattern: Expecting People to Read Your Mind

The failure pattern is subtle because it feels like normal delegation. A task gets assigned with a title and maybe a sentence of context, and the person assigning it assumes their own mental picture of the finished product is obvious to everyone else. It rarely is.

When the delivered work does not match that unstated mental picture, frustration follows, often directed at the person who did the work, when the real gap was upstream the entire time: nobody ever described what “done” actually looked like.

A few signs tend to show up when a team is struggling with an unclear definition of done, and they are worth checking honestly:

• Tasks come back requiring significant rework, not because the effort was poor, but because the wrong thing was built entirely.
• People spend real time digging for context or guessing at intent before they can even start a task.
• Frustration with a delivered task centers on “that’s not what I meant” rather than any actual quality issue with the work itself.

This Isn’t Laziness on Their Part, It’s Missing Information Upfront

Here is an honest admission worth making directly: this pattern is not usually the fault of the person doing the work. Expecting someone to read your mind, assuming they will simply arrive at the exact same mental picture you have without being told, is the actual root cause, and it took real self-reflection to see that clearly.

The fix was never to manage people more closely or to get frustrated when a guess landed wrong. It was to invest a few extra sentences upfront describing exactly what finished actually looks like, before the work ever begins.

The Process Improvement Board: One Sentence That Changed Everything

Here is what that shift looked like in practice. A recurring task, building a crew matrix schedule for a specific contractor, used to go out with just a title and a short description, and it regularly came back needing significant rework because nobody actually knew what the finished product was supposed to accomplish.

The fix was adding one clear sentence directly to the assignment: this task is done when you can visibly see all crews working for this company in separate colors, in a sustainable format that allows the team to allocate resources and predict crew availability for future projects. That single sentence, defining the finish line in concrete terms rather than a vague title, eliminated the rework almost entirely. Nothing else about the process changed, only the clarity of what “done” actually meant.

Why It Matters: Alignment Is the Ninth Waste

This matters because an unclear definition of done is not just an everyday annoyance, it is a recognized form of waste. Lean thinking names eight classic wastes, and a ninth sits right alongside them: misalignment, when people are not actually working from the same understanding of the goal.

An assignment without a clear finish line guarantees misalignment before the work even starts. The person assigning it has one picture in their head, the person doing it builds toward a different one, and the gap between those two pictures is pure waste, no matter how skilled or hardworking everyone involved actually is.

Teach the Framework: Conditions of Satisfaction

This concept has a name in Lean and Last Planner circles: conditions of satisfaction. Before any task, project, or handoff begins, the question worth asking is simple, what specific conditions need to be true for this to be considered genuinely done. Order a specific ice cream flavor and get handed a different one, or ask for a specific vehicle and get talked into a different package “because it’s what you really need,” and the frustration is immediate and obvious. The requester’s actual conditions of satisfaction were never met, regardless of what the other party assumed was good enough.

A useful discipline here borrows from the SMART framework: make the definition of done specific, measurable, actionable, relevant, and time-based, rather than vague language like “make it better” or “get this handled.” Pairing that clear finish line with an honest estimate of effort, the way Scrum teams size tasks before committing to them, ensures a team is not just clear on what done looks like, but realistic about how long it will actually take to get there.

A few practical elements turn any assignment into a real definition of done:

• State plainly what the finished result needs to visibly show, do, or enable, not just the task’s general title or subject.
• Include any hard constraints, a deadline, a required format, a specific audience that would make an otherwise “acceptable” result actually wrong.
• Confirm understanding before work begins, rather than discovering a mismatch only after the task comes back finished.

Turning This into Daily Practice

This does not require lengthy documentation or a formal process overhaul. It requires one habit: before sending any assignment, whether it is a text message, a sticky note, or a verbal request, pause and ask what finished actually looks like, then say that out loud or write it down alongside the task itself.

Starting with the end in mind takes a few extra seconds upfront and consistently saves far more time on the back end, in avoided rework, avoided frustration, and avoided guessing.

Connecting It Back to Building People, Not Just Projects

None of this happens automatically, especially for leaders used to holding the full picture in their own head and assuming everyone else can see it too. Building the habit of stating a clear definition of done is a small shift that pays off every single time a task gets delegated.

If your project needs superintendent coaching, project support, or leadership development, Elevate Construction can help your field teams stabilize, schedule, and flow, including how assignments get handed off clearly enough to avoid costly rework.

The Challenge

So here is the challenge worth carrying into your next assignment, whether it is for a crew, a coworker, or your own to-do list: before handing it off, ask what the definition of done actually is, and make sure you have actually communicated it. As Jason put it plainly, “When you give an assignment, when you schedule an assignment, ask yourself, what is the definition of done? What would finish look like? And have I communicated that?” On we go.

FAQ

What does “definition of done” mean when delegating a task?

It means clearly describing what the finished result needs to look like, do, or enable before the work begins, rather than relying on a general task title alone. It is the same idea as conditions of satisfaction, a concept borrowed from Lean and Last Planner thinking.

Why does an unclear definition of done cause so much rework?

Without a clear finish line, the person doing the work has to guess at what “done” actually means, and their guess often does not match what the requester actually pictured. That mismatch is usually only discovered after the work is finished, requiring it to be redone.

How is this connected to the “ninth waste” in Lean thinking?

Lean identifies eight classic wastes, plus a ninth: misalignment between people working toward the same goal. An assignment without a clear definition of done guarantees misalignment from the start, since the requester and the person doing the work are working from two different mental pictures.

What makes a good definition of done, in practical terms?

It should be specific, measurable, and time-based rather than vague, describing exactly what the finished result needs to show or accomplish. Including any hard constraints, like a deadline or required format, prevents an otherwise reasonable result from still being the wrong one.

Does adding a definition of done to every task slow delegation down?

In practice, it usually speeds things up significantly. A few extra sentences upfront, describing what finished actually looks like, consistently saves far more time than the rework, confusion, and frustration caused by leaving that finish line undefined.