A system nobody uses is worth nothing. It doesn't matter how well it was built, how clean the code is, or how many features shipped on time. If the team is still running the old spreadsheet, the project failed.
That sounds obvious, but most software projects define done as delivered: the build is finished, the invoice is paid, and everyone moves on. Whether people actually use it becomes somebody else's problem.
Why good systems go unused
Usually it isn't the software. It's the conditions around it:
- The data isn't in it yet, so nobody trusts it.
- Someone still doesn't have access.
- Nobody owns making the switch, so the old way never retires.
- There's no date when the old way stops.
Any one of these is enough to stall a rollout. None of them is a coding problem.
Define done as used
We ask one question before we call anything finished: what still has to be true for this to be used, and who is making that true? The answer is usually a short list: the data, the access, the person running it, and a date.
Then we work that list like any other part of the project. On one rollout, the team picked a date to stop using the old shared schedule entirely. Having a date turned the switch from a someday into a plan.
What this means if you're buying
When you hire someone to build a system, ask how they'll know it worked. If the answer is the launch date, keep asking. The work is done when your team uses it without being reminded.