Almost every proposal I have read treats go-live as the end of the story, including some of ours from a few years ago. Then the system meets two hundred people who never attended a workshop, on a busy week, with real customers waiting.
What happens after that follows a pattern regular enough to plan for.
The first week tells you how people actually work
Usage never matches the plan. Somebody uses the search box as a to-do list. Somebody else runs a report at seven every morning and pastes it into a spreadsheet, because that is the format their manager has always wanted. A branch turns out to have quietly decided that one field means something different from what everyone else assumed.
Watch what people do rather than what they write on a feedback form. Which screens get opened forty times a day, which have never been opened at all, where people stop halfway through and give up. That is the real requirements document and you only ever get to read it after launch.
The exceptions arrive in the second and third week
The customer who pays in a currency nobody mentioned. The order that has to be split between two branches. The supplier who invoices the parent company rather than the office that bought the goods. The job cancelled after the invoice has already gone out.
None of these came up while the requirements were being written and nobody was hiding them. Ask somebody how the process works and they describe the normal case, because exceptions are not thought of as process. They are thought of as Tuesday.
Assume there are a dozen and leave time and money for them. A project with nothing left in the budget on go-live day either stalls there or quietly pushes people back to the old way of working.
The workarounds are information
Within a fortnight people will have invented their own ways round the parts that do not fit. A spreadsheet kept on the side. A WhatsApp group where the decision is actually made before anybody types it in. A field being used to store something it was never intended for, because there was nowhere else to put it.
The instinct is to stamp on them. Ask why first. Nearly every time, the workaround is the cheapest available description of something the system is missing, and usually something small. Block it without asking and you have not removed the workaround. You have only stopped being told about it.
Week six, when the goodwill runs out
There is a dip, and it lands around the fifth or sixth week with enough regularity that I now plan for it. The novelty has gone. Whoever championed the project has moved on to the next thing. Everybody is being watched a little less closely than they were on day one, and a month of small irritations has had time to add up.
The usual response is more training, and training is rarely the problem. Fix the three things people complain about most, fix them where everyone can see, and fix them in days rather than in the next release. Changing something small within a week does more for adoption than any amount of instruction, because it tells people that speaking up is worth the effort.
What to fix now and what to leave alone
Not everything raised in the first month deserves the same attention, and treating it as though it does will exhaust the team before the system has settled. What I fix in the same week, without a discussion about priorities:
- Anything that produces a wrong number, however small the number
- Anything that loses somebody's work
- Anything a customer is waiting on
- Anything that takes more steps than the old way for the task people do most often
What I leave alone for at least a month: requests for new features, since about half of them stop being asked for by the third month. Complaints in the first fortnight about how it looks, which are usually about unfamiliarity rather than design. And the department that wants the old system's words back, which is worth revisiting later but not in week two, when everything is raw.
The only number worth watching
Logins, satisfaction scores and support tickets all move for reasons you cannot act on. What matters in the first ninety days is whether the work is being done in the system or beside it. Pick the three or four things your business does most and count how many of them are complete in the system by the end of the day, without somebody tidying up afterwards.
If that number is climbing, the rest follows. If it is flat, another training day will not move it and neither will a strongly worded email from somebody senior.
Plan for the ninety days properly. Put a name against them, keep money aside for them, and agree it while the contract is being written rather than in the third week when everyone is busy and the supplier has moved on to their next client. If you are in the middle of one now and it is not going the way you were told it would, this pattern is usually enough to work out where you are. If it is not, say so and we can look at it together.
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.