“Training is the tour at the end, right?”
I collect the objections that surface when onboarding comes up in deployment planning. They’re the same five everywhere, wrong in instructive ways, so here they are with my answers.
The tour objection first. A fifteen-minute walkthrough teaches people where the buttons live, and that’s all it teaches. It teaches a records clerk nothing about how a draft was assembled, where each source came from, or which step still belongs to them, and it won’t teach an administrator a thing about backups, health checks, or failure modes. Different jobs, different curricula. One generic session doesn’t serve anybody well.
“Everyone saw the demo.” The demo showed the happy path. Real onboarding includes normal cases, ambiguous cases, known failures, and at least one deliberate refusal, because a user who’s never watched the system decline a task will trust its confident tone right up until the tone is wrong. I want skepticism installed before habits form.
“The vendor handles competence.” Then the institution rents its capability instead of owning it. My bar hasn’t moved: staff run routine administration, recognize degraded behavior, recover from expected failures, and train their replacements from the deployed documentation. A vendor who remains the sole source of competence sold a leash, whatever the contract calls it.
“Users will figure it out.” Some will. What they figure out unsupervised becomes folklore, and folklore includes workarounds you’d never approve. A short review after the first week and another after the first month surfaces the corrections, the abandoned tasks, and the improvisations that show where the design failed to explain itself.
“There’s no budget line for it.” There is. It’s hiding inside adoption risk, and it’s larger there. The smallest phase on the project diagram carries an outsized share of the ways deployments fail, so give it an owner, acceptance criteria, role-based material, and honest time on the schedule.
An installed system’s hardware plus software. A deployed one includes people who can run it, question it, and stop it. I don’t call the job finished until the second definition is met.