Definition of Done: Align Before Work Starts

I'm Kurt Schmidt, founder of Schmidt Consulting Group, and the single most expensive mistake I see B2B services firms make is delivering work that the client doesn't consider finished. And finding out at the worst possible moment.

The definition of done sits at the center of almost every delivery dispute I've encountered. Not quality issues. Not missed deadlines. A mismatch in what "finished" actually means, baked in at kickoff and invisible until the engagement closes.

Here's the core problem: your team's definition of done and your client's definition of done are two different documents. The gap between them is where margin, goodwill, and renewals go to die.

---

Why Do Delivery Disputes Happen Even When the Work Is Good?

Most agencies I've worked with assume that delivery disputes are quality problems. The code broke, the copy missed the brief, the design was off-brand. They invest in QA processes, creative reviews, and delivery checklists. All of that is useful. But it misses the actual source of most disputes.

Your team's definition of done is usually this: the deliverable meets the spec. The thing was built. It works. It matches what was scoped. You can check every line and feel confident.

The client's definition of done is usually this: the problem is solved and the outcome they pictured is real.

Those two things overlap. They're not the same. You can hit every line of the spec and still land a client who feels the work isn't finished, because their unspoken definition included things nobody wrote down. A level of polish. A hand-off. A result. An adjacent deliverable they assumed was part of the package.

This is why QA doesn't solve it. You can't quality-check your way out of a definitional mismatch. The dispute is about what "done" was supposed to mean.

---

Why Is the Definition of Done Gap Invisible Until It's Expensive?

At kickoff, everyone is optimistic. The client is excited. Your team is energized. Nobody wants to be the one who pumps the brakes and asks awkward questions about where the boundaries are. Nobody does.

The differences hide inside shared words. "A website." "A strategy." "A campaign." Both sides hear the same phrase and picture completely different finish lines. The client hears "a website" and pictures trained staff, a smooth launch, maybe some early traffic wins. Your team hears "a website" and pictures a staging environment signed off and handed over.

That gap stays invisible through the entire engagement. It might even feel like things are going well. And then it detonates at delivery, when both sides are invested, neither wants to be wrong, and fixing the mismatch is at its most expensive and most damaging to the relationship.

In my experience working with services firms across a range of industries, the blow-up at delivery is almost never a surprise in retrospect. Someone on the team usually knew the client had different expectations. The problem is that nobody made it explicit when it was cheap to do so.

---

Where Does the Definition of Done Mismatch Actually Live?

The gap between your definition and the client's shows up in four recurring places. Understanding them by name makes them easier to catch at kickoff.

Scope edges. These are the adjacent things the client assumes are included and your team assumes are extra. Revisions beyond the agreed rounds. Staff training. Data migration. The "quick" addition that gets requested in week three. Every one of these is a clear boundary in your mind and an obvious inclusion in theirs. Scope edges are the most common source of margin erosion in services delivery.

The quality bar. Your team considers the work finished. The client expected another level of refinement that was never priced. "Done" and "polished" are different words with different cost structures, and clients often don't know which one they're buying until they see what they got.

Output versus outcome. You defined done as the deliverable. They defined it as the result. You built the thing; they wanted the thing to work inside their organization, which includes adoption, integration, and downstream effects you may not control and certainly didn't price. outcome-based pricing touches on this distinction, but the solution starts at the definitional level.

The hand-off. What "delivered" actually includes. Do you hand over files and walk away, or do you make sure they can use what you built? Clients almost universally assume the second. Agencies almost universally scope the first. The hand-off assumption gap alone accounts for a significant share of the "we're not done yet" conversations I've seen firms work through badly.

---

How Do You Build a Shared Definition of Done That Actually Holds?

The fix is up-front and written. Before work starts, both sides need to align on what "done" means, explicitly, in a format both parties look at together. And I want to be specific about what "written" means here, because this is where most firms get it wrong.

The definition of done needs to be a standalone document, or at minimum a discrete section both sides sign off on independently, rather than acceptance criteria buried inside a 40-page SOW that nobody rereads. Short enough that it gets read. Specific enough that "is this finished?" has a factual answer rather than an argued one.

Build it around three components.

First, inclusions stated plainly. Not in legal language. In the kind of language you'd use in a client conversation. "This engagement includes two rounds of revisions, defined as consolidated feedback delivered in a single document per round." If you want to avoid scope edge disputes, name the scope edges.

Second, exclusions stated equally plainly. This is the part agencies skip, and it's the part that does the most work. Unspoken assumptions default to the client's favor every time. "This engagement does not include staff training, data migration from legacy systems, or content creation for pages beyond the ten agreed at kickoff." If you're not writing the exclusions, you're not writing a definition of done. You're writing a wish.

Third, acceptance criteria concrete enough to be objective. "The site loads in under three seconds on mobile" is a criterion. "The site feels fast" is not. "Two rounds of consolidated written feedback have been incorporated" is a criterion. "The client is satisfied with the design" fails that test. The test for a good acceptance criterion is whether a third party could read it and determine independently whether it's been met.

At, I've written about how scope creep compounds over an engagement. The definition of done is the upstream fix that prevents most of what shows up downstream.

---

What Does the Kickoff Conversation Around Definition of Done Actually Look Like?

Making "done" explicit requires asking uncomfortable questions early. I've seen agency leaders avoid these questions because they feel like friction at kickoff. They feel like you're creating doubt in a moment where confidence is what closes the deal and starts the relationship well.

That instinct is understandable. It's also expensive.

The questions that need to get asked are: What does success look like to you at the end of this? What would make you feel this wasn't complete? What are you assuming is included that we haven't explicitly discussed?

That last question is the most valuable one you can ask. Clients rarely lie in response to it. They tell you what they're assuming, and now you know what needs to be written down.

Some of those assumptions can be absorbed. Some need to be repriced. Some need to be declined. But you're having that conversation before either side has anything to defend, which means it resolves in a fraction of the time and cost of the same conversation at delivery.

Every boundary you make explicit at kickoff is a dispute you don't have to work through when the relationship is on the line. The math on that trade-off is not close. walks through how to structure this conversation operationally.

One thing I'll add: the definition of done document is a living artifact that gets updated throughout the engagement. If scope changes mid-engagement. And it often does. Revisit it. Update it. Get sign-off again. The two definitions can silently drift apart over a long engagement even when you started aligned, and that drift creates the same end-of-project blow-up you were trying to avoid.

---

Is There a Situation Where a Definition of Done Doesn't Apply?

Short engagements with a single, unambiguous deliverable are lower risk. If you're writing one white paper with a clear brief, a word count, and a defined review cycle, the definition of done is mostly self-evident and the documentation can be lighter.

The risk scales with engagement length, deliverable complexity, and the degree to which the client's desired outcome depends on things you don't control. A six-month website rebuild with a development team, a migration, and a content component? Every component of the definition of done framework applies, and skipping any of them is a choice to absorb the cost of the mismatch yourself.

I'll also say this plainly: the definition of done is a shared reference both sides can rely on. Using it to litigate against a client at delivery destroys the thing you built it to protect, which is the relationship. The point is to make sure that when you say "done," the client is already nodding, because you agreed on what the word meant before either of you had anything to defend. The Agile Alliance's definition of done offers useful framing from the software development world that services firms can adapt. The principles transfer cleanly even if the implementation looks different.

---

Key Takeaways

• Your team's definition of done and your client's definition of done are separate documents; aligning them is a delivery function.
• The gap between the two definitions hides inside shared words like "strategy," "website," and "campaign," then surfaces at delivery when it's most expensive to resolve.
• Scope edges, quality bar, output-versus-outcome confusion, and hand-off assumptions are the four places the mismatch reliably lives.
• A written definition of done requires both inclusions and exclusions; the exclusions do most of the protective work because unspoken assumptions default to the client's favor.
• Acceptance criteria need to be objective enough that a third party could determine independently whether they've been met.
• Revisit the definition of done if scope changes mid-engagement; silent drift between the two definitions produces the same blow-up you were trying to prevent.

The kickoff conversation that surfaces a client's hidden assumptions is uncomfortable for about fifteen minutes. The delivery conversation that happens without it can cost you the margin, the renewal, and the referral. Which discomfort are you choosing?