System implementations fail at a high rate, and the failures cluster around the same causes. Almost none of them are the software being bad.
Fix the process before you automate it
The most expensive mistake is buying software to solve a problem that is actually a process problem. Automating a broken process produces a faster broken process and a licence fee.
Before evaluating anything, map what actually happens now — not what the policy says, what people actually do. That exercise usually reveals workarounds, duplicated data entry and steps nobody can explain, and sometimes reveals that the problem can be solved without new software at all.
Decide what you need before you look at what exists
Vendors demonstrate their strengths. If you evaluate against demonstrations rather than against your requirements, you will select on features you do not need.
Write requirements first, split into:
- Must have — the system is unusable without it.
- Should have — significant value, workaround possible.
- Nice to have — would be good.
Be ruthless about the first list. A must-have list with twenty items is a wish list, and it will lead you to an expensive system that does everything adequately and nothing well.
Evaluate on the things that are hard to change later
Features can be added. These usually cannot:
- Data export. Can you get your data out, in a structured format, including history and attachments? Test it during the trial rather than accepting an assurance.
- Integration with what you already run — accounting, payroll, e-commerce. Whether it is standard or a development project, and who pays.
- Fit to your actual workflow, since heavy customisation is where budgets and timelines fail.
- Vendor viability and whether they support New Zealand customers in New Zealand hours.
- Contract terms — price increase provisions, renewal notice periods, data ownership.
The costs beyond the licence
Subscription cost is usually the smallest component. Budget for implementation and configuration, data migration and cleaning, integration development, training, and the productivity dip during transition.
That dip is real and should be planned for. Output drops while people learn, and a business already at capacity should not schedule a go-live during its busiest period.
Data migration is harder than expected
Existing data is messier than anyone believes — duplicate customers, inconsistent codes, missing fields, records nobody has maintained.
Two decisions to make deliberately: how far back to migrate, since full history is rarely necessary and always expensive; and whether to clean before or after, which is almost always before, because migrating bad data means cleaning it twice.
People decide whether it works
The technical implementation is usually the easy part. Adoption is not.
- Involve the people who do the work in selection and design. Systems chosen by management and imposed on staff get worked around.
- Be honest about why. If the system will change roles, say so. People who suspect a hidden agenda resist.
- Train on their actual tasks, not on the software generally.
- Identify people who will help others and give them early access and extra support.
- Provide real support in the first weeks, when frustration is highest and habits form.
- Turn off the old system on a defined date. Running both is the most reliable way to end up with neither working properly.
Sequencing
Phased implementation beats a single switchover for most businesses. Start with one module, one team or one site, learn, then extend.
Avoid go-live during peak trading, at year end, or when key people are on leave. Have a documented rollback position for the first weeks — what you do if it does not work.
Define success before you start
Agree what improvement you expect and how it will be measured — time saved on a specific process, error rate reduced, information available that was not. Without that, the project is judged on whether people like it, and a business that cannot say whether an implementation worked will repeat the same mistakes on the next one.
Security and privacy
New systems change your risk position. Confirm access controls and multi-factor authentication, that backups actually cover the new system, and — where personal information is involved — that the arrangement supports your Privacy Act obligations, including where data is stored and who at the provider can reach it.
business.govt.nz publishes guidance on choosing business software, and the National Cyber Security Centre publishes material on securing systems, both free.
