Most software implementations fail for three reasons: the underlying process wasn't fixed first, too much went live at once, and the people who have to enter the data (often the site or warehouse team) weren't considered. The software itself is rarely the problem. If your new system has turned into an expensive data-entry exercise nobody trusts, the fix is usually to step back, pick one process, get it working properly end to end, and rebuild confidence from there.
The pattern is familiar. The sales demo looked great and the features ticked every box. A few months after go-live, half the team is still using the old spreadsheets, the reports don't match the accounts, and people quietly work around the new system. Here is why that happens and what to do about it.
The three reasons implementations fail
1. The process wasn't fixed first
If a process is broken, putting it into software just means doing the wrong thing faster. Before any system goes live, map the process you actually want. Who touches it? Where does it stall? What information gets lost between steps? Fix the process, then configure the tool to support it.
Many failed implementations tried to copy every quirk of the old way of working into the new system, or forced the business into the vendor's default process without checking whether it fitted. Both end with people working around the software. We cover this in more depth in fix the process before you buy the software.
2. Too much went live at once
Switching on every module on the same day is the fastest way to overwhelm a team. Everyone is learning at once, nobody has time to fix the small problems, and every issue gets blamed on "the new system".
The implementations that stick usually start with one function, get it working well, build confidence and then expand. For a builder, that might mean accounting first, then job costing, then timesheets, rather than everything in week one.
3. The people entering the data weren't considered
If a system adds work to your site crews' day, it will fail, no matter how powerful the back-office features are. For example, if your foreman has to fill in long forms each evening on a system that is slow on a phone or needs good Wi-Fi, he will stop using it within weeks. When the field data stops, every report downstream becomes unreliable, and the office stops trusting the system too.
Other warning signs
Beyond the big three, these often show up in stalled projects:
- No internal owner. The vendor or consultant led the project, and once they left, nobody in the business owned the system.
- Dirty data migrated as-is. Old duplicates and inconsistent codes were loaded straight in, so reports were wrong from day one.
- Not connected to the accounts. The new system and Xero or MYOB disagree, so finance keeps its own spreadsheet "just to be sure".
- Training was a single demo. People were shown the software once and left to work it out.
- Success was measured by go-live, not by use. The project was declared finished when the system was switched on, not when people were actually using it.
How to rescue a stalled implementation
If you are already part-way in, you don't necessarily need to start again. A structured rescue looks like this:
- Find out what's really being used. Talk to the people doing the work. Which parts of the system do they use, which do they avoid, and why?
- Pick one process to fix completely. Choose the one with the most value and the clearest owner. Get it working end to end, including data flowing to your accounting system.
- Clean the data that matters. Fix job codes, customer records or product lists that are causing wrong reports.
- Simplify the front line. Cut field and data-entry screens back to the essentials. Remove fields nobody fills in.
- Connect it to the rest of the business. If the system doesn't talk to Xero, MYOB or your other tools, a proper integration often does more for adoption than extra training.
- Then expand. Bring in the next module or team only once the first one is stable.
What to do differently next time
- Start small. Pick one problem and solve it completely before moving to the next.
- Design for the field first. If the people entering data won't use it, nothing downstream works.
- Run old and new in parallel for a set period. Don't cut over cold, but don't let parallel running drag on either.
- Measure adoption, not features. The best system is the one people use, not the one with the longest feature list.
- Make sure it connects. Check up front how the new system will share data with your accounts and other tools.
If you're choosing a new system now, our guide to choosing an ERP system in Australia and our overview of the construction software stack for builders are good places to start.
Frequently asked questions
Should we scrap the system and start again?
Usually not straight away. Most stalled implementations can be recovered by fixing one process at a time, cleaning the key data and connecting the system to your accounts. Replacing it only makes sense if the software genuinely can't support how your business works.
Why won't my team use the new software?
Most often because it makes their day harder: too many fields, slow on a phone, or it duplicates work they already do somewhere else. Talk to them, simplify what they have to enter, and show them what they get back from it.
How do we know if an implementation is succeeding?
Look at use, not features. Are people entering data on time? Do the reports match the accounts? Has the old spreadsheet been retired? If the answers are yes, it's working.
Is it the software or the implementation that failed?
In our experience it is usually the implementation approach. The same software can work well in one business and fail in another depending on process, data and how the rollout was handled.
If you've got a system that isn't delivering, book a free initial chat and we'll talk through what's going wrong and whether it can be recovered.