Nothing is finished while it still needs the people who built it.
Carsten Christiani
Somewhere in your company there is probably a system that only works because whoever built it still answers the phone. It might be a reporting setup, an automation, the website, or lately an AI agent. It looked finished at the handover, and in a sense it was, because it worked. What nobody checked is whether your own people could keep it working once the builder had moved on to something else.
The best picture I know for this is teaching a child to ride a bike. The handover is the bit where you run alongside holding the saddle. You only find out whether they can ride when you let go, and finished is the moment you have let go and they haven't noticed.
So the test is about letting go. If the builder disappeared tomorrow, would the thing keep running, and could another competent person understand it well enough to improve it? A manual doesn't answer that. Your people do, by running it, handling the exceptions, recovering it when it breaks and changing it safely when the business changes. If it works only while the builder is around, it hasn't been handed over, however good the technology looks.
The exception is where it shows. Anything works on a normal day. What matters is the odd case nobody thought of, the order that doesn't fit the form or the data that arrives a day late. In a company that can carry the system, someone handles the case and, if it might come back, changes the rule. In a company that can't, someone calls the builder, or quietly works around it, and over a year or two the workarounds become the real way things are done, with the official process still sitting there in the documentation.
People learn to carry a system the way they learn anything that matters, by doing it under load, a little more each time, until it stops feeling like someone else's machine, and what they learn that way stays when the builder goes. So a handover worth the name includes a few awkward exceptions handled by your people while the builder keeps their hands in their pockets.
That last part is harder than it sounds, and it applies to advisers as much as to builders. The useful skill is saying clearly what you see and then stopping. It isn't the adviser's job to carry the client's system for them, however tempting that is when you can see exactly what should happen next. When it goes well there's a strange side effect, which is that people find the answer themselves and nobody sees the help. I've come to think that is usually the help working.
The usual consulting logic runs the other way. The longer the client needs you, the better the account, which is exactly what makes a builder's presence expensive and their absence dangerous. I come into every piece of work trying to make myself redundant, and with every process I touch, I ask whether it could be automated or handed to someone cheaper. What we build sits in the client's accounts, under the client's name, and the AI models underneath are replaceable, and so are we.
It's the test we build our own work toward, and no client team has yet passed it with us from start to finish. That is the next thing we are proving.
On Monday, pick one system that somebody built for you in the last year. Ask the person who uses it most what they would do if it broke tonight and the builder didn't pick up. Then ask them to change one small thing in it, in a test copy if there is one, while you're there. Whatever they can't do is the part that isn't finished yet, whatever the invoice says, and it goes back to the builder as unfinished work, with your person doing the change and the builder only watching.
And on the day it runs without the builder, go and celebrate. Then call them about the next thing if you like, or don't. You're free to choose either, which is rather the point.