We rolled out an assessment tool for Dingley recently, they said they'd started using it, and then nothing came back. No bug reports, no "quick question", nothing.
I assumed the worst, that it was broken and they'd quietly given up on it. They were just using it. It was working.
That isn't normal. I've delivered a lot of software and there's usually a couple of weeks of edge cases and small problems after go-live. Four things were different on this one.
The requirements were an interactive demo, not a document
Instead of writing a spec and asking people to imagine it, we built a clickable demo with nothing real behind it. No database, no logic, just screens you could move through.
This is the one I'd tell everyone to steal. A written requirements document asks the client to translate paragraphs into a mental picture of software, and then to spot what's wrong with a picture they've had to build themselves. Most people can't do that, and the ones who can still miss things. Put a fake screen in front of the same person and they'll tell you in five seconds that the button is in the wrong place, that nobody has that information at the point you're asking for it, or that the form is missing the field they actually care about.
It costs a few days. Those few days are cheaper than the same change made after it's built, and much cheaper than the same change made after it's live.
Testing time was ringfenced
Testing sits at the end of the plan, which means it's the first thing that gets eaten when the build runs late. Nobody decides to skip testing. It just quietly becomes three days instead of two weeks because the deadline didn't move.
That is where the fortnight of little problems after go-live comes from. It doesn't come from anything clever going wrong. On this project the testing time was fixed and everything else had to fit around it.
Nobody tested their own work
The whole team tested, but nobody tested what they'd built. If you wrote it, you test somebody else's.
You can't see your own assumptions. You test the path you had in mind while you were writing it, because that's the software you think you built. Somebody who wasn't in your head goes a different way through the same screen and finds the thing you never once tried.
The help was on the page, not in a manual
Every page has a help section on it explaining that page. No training day, no PDF that lives in someone's inbox, no video nobody watches.
Most of the support calls in the first month of a new system are not faults. They're one person who wasn't in the room on training day and doesn't know what a field means. If the answer is on the screen in front of them, they don't ring you and they don't stop using it.
We also didn't cut any scope, which I still find slightly suspicious.
Maybe some of it was luck. I think it was mostly the demo.