Rolling it out when nobody is assigned to it
Most small organisations implement software as a side task. That is workable, but only if the sequence is right.
Implementation guidance assumes a project manager, a steering group and a change function. A twenty-person organisation has none of these, and the rollout is done by whoever bought it, in between everything else.
This can work. What kills it is doing everything at once. For a concrete example of task-switching cost after purchase, learn more can be used to identify the behaviours and measures that rollout should actually change.
Sequence it in stages
- Configure and load, with a small group only. Nothing is announced.
- Pilot with the people who ran the trial, doing real work for two or three weeks.
- Fix what the pilot found. This stage is always skipped and it is the one that determines the rest.
- Roll out to one team or one process, not everything.
- Extend, once that team is genuinely running on it.
- Retire the old system, deliberately and on a date.
Simultaneous rollout to everything means every problem arrives at once, at the moment fewest people know how to solve it.
Pick the first group carefully
The first group should be capable, reasonably willing, and doing work that is important but not the most time-critical thing in the organisation.
Not the most enthusiastic group — they will make it work regardless and tell you nothing. Not the most critical process — a problem there is expensive. A representative group doing real but recoverable work is what you want.
Keep the old system available, briefly
A hard cutover with no fallback is the highest-risk option and is chosen because it is simplest. A short overlap — read-only access to the old system for a defined period — removes most of the fear and most of the risk.
Bound it explicitly. Indefinite parallel running is the failure mode: the old system stays alive, some people keep using it, and the new system never becomes the record.
Decide the data cutoff
How much history moves? Everything is expensive and often unnecessary. Nothing makes the new system unusable for anyone who needs to look backwards.
A common answer is active records plus a defined period of history, with the rest kept as an archive extract. Making this a decision rather than an accident prevents both the six-week migration and the discovery in month two that nobody can find last year's records.
Tell people what is happening and why
Rollouts announced as a fait accompli generate resistance out of proportion to the change. A short explanation — what problem this solves, what will change for you, what stays the same, when — costs one message.
Include what will be worse initially, because something always is. Naming it in advance converts a broken promise into an expected inconvenience.
Fix things fast in the first fortnight
Early problems set the narrative. A permission that is wrong, a missing field, a report that does not match — each is small and each becomes 'the new system does not work' if it sits for a week.
Reserve real time in the first two weeks for nothing but responding to these. It is the highest-value time in the whole implementation.
For operational controls that often change during adoption, NCSC 10 Steps to Cyber Security provides a public baseline.