What “finished” actually means

There is a scene that repeats itself: the provider delivers, presents, invoices and closes the project. Every ticket is green. And three months later the business is still solving the same problem with the same spreadsheets as always.

Nobody lied. The project was “finished” by the definition that had been agreed. The trouble is that the definition did not include the business.

The three definitions that fall short

“It works in the test environment.” The most common and the most misleading. The test environment has clean data, small volumes and no edge cases. The client’s reality has fifteen years of data loaded by different people to different standards, plus an exception for the biggest account that nobody ever wrote down.

“The demo goes well.” A demo is a rehearsed happy path. It shows the software can work, not that it works.

“Every requirement is covered.” This is the most dangerous, because it looks rigorous. A requirements list is a hypothesis about how to solve the problem, written before starting, when the least was known. Meeting it to the letter and not solving the problem is entirely possible — and it is what happens when someone gathers requirements instead of diagnosing.

The definition that does work

Finished is when the problem that started the project has stopped existing, in the real operation, with the real people who run it.

That implies three things that are uncomfortable for a provider, which is why almost nobody signs it:

1. The condition is written first, at the end of discovery, and comes from the business problem — not from the solution imagined later.
2. It is verified in production, with real data and real users.
3. If it is not met, the project is not finished. Even if the software is written. Even if the hours are spent.

How to write a condition like that

It is not a statement of intent, it is something you can go and check. The difference:

• Bad: “The system will improve order management.” None of that can be verified.
• Better: “Orders are entered once, in one place, and the warehouse team sees them without asking anyone.”

The second one can be checked. Someone walks into the warehouse on an ordinary Tuesday and sees whether it is true. It does not need a number: it needs to be observable.

When the condition does have a number, better — “the monthly close stops taking three days” — but demanding numbers where there are none leads to inventing them, and an invented metric is worse than no metric.

The part almost nobody does

If “finished” is verified in production, then the provider has to still be there when the system goes into production. And that is precisely the moment when a good share of providers has already left: the contract said delivery, and delivery has happened.

That is why the definition of finished and the contracting model are the same subject. If you are paid to deliver, you deliver. If you are paid to solve, you stay until it is solved.

Before signing

Ask one thing: how will we know this is finished, and who verifies it?

If the answer talks about deliverables and not about the business, you already know how it ends.