In IT projects, “done” is the most dangerous word

This past week, I’ve had more client calls than usual. A few retainers are in progress, and slowly but surely, things are moving in the right direction. It’s the kind of momentum that feels steady - not rushed, not overwhelming - just consistent growth.

But one thing stood out during these conversations: how much communication speed changes everything.

Prospects who seem eager sometimes take three to five days to confirm something simple. And during those pauses, projects stall, timelines slip, and momentum fades.

It reminded me of something I’ve seen many times in IT projects - people often use the same words but mean completely different things.

The Misunderstanding: What “Done” Really Means

Take the word “done.” It sounds simple enough, but in reality, it’s one of the most misunderstood words in project delivery.

Ask five people what “done” means, and you’ll get five completely different answers.

For a developer, “done” might mean the code runs without errors. For a client, “done” might mean the product is deployed, tested, and ready for real users.

For management, “done” might mean an invoice can be sent. Same word - different worlds.

And that’s where most delivery conflicts begin. Not because someone didn’t do their job, but because no one stopped to define what completion actually looks like.

When that happens, deadlines drift, invoices sit unpaid, and trust quietly erodes.

Why It Matters

In IT, ambiguity is expensive. Every misunderstanding turns into a delay. Every delay pushes payments, eats into margins, and strains relationships.

What’s worse is that these conflicts often appear small in the beginning - a single word, a small assumption, a missing step in communication - but they multiply over time.

By the time everyone realizes what went wrong, it’s too late. The client feels misled, the team feels frustrated, and the project feels stuck.

That’s why clarity isn’t just a best practice. It’s a competitive advantage.

The Fix: Define “Done” Before You Start

The solution isn’t complicated, but it does require discipline. If you want “done” to mean the same thing for everyone, you have to define it deliberately - not casually.

Here’s how to do it right:

1/ Define “done” in writing. Spell out exactly what completion means for each deliverable. It could be a checklist, a working demo, or a client-approved test case - but it has to be documented.

2/ Use user acceptance criteria. Before delivery, decide what tests or reviews must be passed before final sign-off. This creates an objective measure of completion, not a subjective one.

3/ Set sign-off timelines. Define how long the client has to review deliverables. If they don’t respond within a certain number of days, acceptance is automatic. That one clause can save weeks of unnecessary back-and-forth.

4/ Update definitions as the project evolves. When the scope changes, update what “done” means too. Otherwise, you’ll keep chasing a moving target.

TL;DR

Most IT delivery issues don’t come from bad work - they come from bad definitions. “Done” means different things to different people.

Define it clearly, tie it to acceptance criteria, and set timelines for review. Clarity turns chaos into progress.

Clarity creates confidence. Assumptions create chaos.

In IT projects, the difference between success and frustration often boils down to a single word.

When “done” is clearly defined, you avoid disputes, maintain trust, and keep cash flow predictable. When it’s left open-ended, every task becomes a negotiation.

Because in the end, “done” shouldn’t be an argument. It should be a definition everyone agrees on - before the work begins.