Almost every proposal I have read, including ones we wrote years ago, puts training in the last week. Two days, a room, a projector, a set of slides made the Friday before. Everyone signs the handover form and the supplier leaves.
Four months later somebody rings because a report stopped running and nobody remembers what used to fix it.
Why the session at the end does not work
By that point your people have watched a system being built. They have not run one. Those are different skills and only the second one survives contact with a bad Tuesday.
The timing is also the worst possible. The two days land exactly when the old way is being switched off and everyone's real workload has doubled. People sit in the room with their phones out because there is an actual customer waiting.
And it covers everything evenly, which sounds fair and is useless. A person running this day to day needs about six things cold and can look up the rest. A two-day tour gives equal weight to the screen they will open forty times a day and the one they will open in March.
Documentation written for the invoice
There is a whole genre of handover document that exists to be delivered rather than read. Ninety pages, a picture of every screen, a paragraph under each one saying what the buttons are called.
Nobody opens it. It answers the question of what is on this screen, which anybody can see by looking, instead of what to do when the month-end figures do not balance, which is what they will actually ring about.
Write it for the person who inherits this in two years and has never met you. That is a much shorter document and a much less comfortable one to write, because it has to admit where the awkward parts are.
What works instead
- Your people do the real task, on the real system, with real records, while we sit next to them. Not a demonstration. They have the keyboard.
- Whoever is going to run it is in the project from early on rather than introduced at the end as the recipient.
- Written instructions organised around what goes wrong, in rough order of how likely it is, aimed at somebody who never met the person who built it.
- A named owner inside your organisation who knows that they are the owner.
- A period after go-live where we are reachable but not doing it for you. If we are still doing it, the handover has not happened yet.
The named owner is the part that gets skipped
Everybody agrees a system needs an owner, and then the name never gets written down. What you end up with is shared responsibility, which is not responsibility at all. When something breaks, three people each assume one of the others is dealing with it.
The owner does not have to be technical. They need to know what the system is for, who to call, and be senior enough to say no when somebody asks for a change that would quietly break something else.
A test you can run yourself
Pick an ordinary task. Ask one of your own people to do it end to end, unaided, while the supplier is still in the building. Sit and watch.
If they get through it, the handover is real. If somebody leans over and takes the keyboard, you have just watched a demonstration and you should say so before the final invoice is paid, not after.
I came to software from aviation. I spent years as an Air Safety Officer at India's aviation regulator, investigating accidents and running safety audits, and in that world documentation is not a deliverable you hand over at the end. It is the thing that lets somebody who was not there work out what happened. That is the standard I hold software to. A system only its author can run is not finished.
If there is something in your business right now that only one person knows how to run, that is worth dealing with before the day they hand in their notice, not after. Send me a description of it and I will tell you what it usually takes to fix.
Working through this on a live programme?
A 45-minute call with the engineer who would run the work. We will tell you whether AI is the answer, including when it is not.