People don't resist new software. They resist doing the job twice.

In the first week after go-live, everyone nods along. A month later there is a notebook back in the sales office drawer, and a spreadsheet in the warehouse that one person keeps “just for myself”. The owner concludes that people dislike change and will get used to it eventually.

That is rarely the whole story. People who do the same job every day adopt anything that makes that job shorter remarkably quickly. What they reject is software that makes it longer.

What the changeover looks like from the front line

Management has announced that from the first of the month everything goes through the new system. But nobody has switched off the old way, because nobody trusts the new one yet. What if something fails while a customer is waiting?

So each order gets entered twice: once the way it must be, once the way people know will definitely work. The new system collects data that nobody uses yet. Every day the job takes longer, and the benefit is invisible.

When the changeover drags on for months, the faster way for the hands wins. That is almost always the old one.

Why people work around a new system

It asks for information nobody has at that moment

The form will not move on until a delivery date is entered, while the customer is on the phone and nobody knows the date yet. So people type anything to get past it. A month later the delivery report is full of meaningless figures, and everyone decides the system cannot be trusted.

It was built for the report, not for the work

Management got tidy dashboards. The person entering the data got three more screens than before. The one who bears the cost is not the one who sees the benefit.

Nobody asked the people doing the work

The system was designed from the organisation chart rather than from how the work actually flows. The shortcuts people relied on for years — repeat this customer’s last order, add a note for the driver — simply do not exist any more.

Training happened once, in a meeting room

One afternoon of slides, before anyone had a real case in hand. The real questions come up in week two, with the first part delivery or the first customer who changes an order. By then there is nobody to ask.

The person who knew the old way best loses the most

The employee who knows every code and every customer by heart used to be indispensable. The new system makes that knowledge less visible. If that person is against it, the rest follow, because they trust a colleague more than a program.

What genuinely helps

None of this is expensive. Skipping it is.

• Watch people work first. Spend time with them where they work before a single screen is drawn. That is where you see the shortcuts, the exceptions and the details that turn up later than the paperwork claims.
• Start with what bothers them. The first step should take something off their plate on day one — retyping, searching, chasing. The management report can wait for step two.
• Ask only for what is known at that point. The delivery date gets entered when it is known, not when the order comes in.
• One person from the front line on the team from the start. Not a manager, but someone who does the job every day. Their “that won’t work like this” is worth more than any specification.
• Training on real cases, with someone on hand. For the first weeks, someone who knows the system has to be reachable during working hours for the questions that only appear in real work.
• A date when the old way stops. Running both in parallel with no end date is the surest route back to the notebook. Once the new system is clearly working, the notebook goes.
• Measure after the rollout. What got faster, what no longer gets retyped, where time is still lost — and tell people. Once they see their day getting shorter, they stop waiting for “this” to blow over.

When the software really is the problem

If people still work around the system after all that, it probably does not fit the work. This happens most often with off-the-shelf software that expects the business to adapt to it.

Sometimes that is fine. If your way of working is really just habit and the software offers a more sensible one, changing the habit pays off. But if the way you work is exactly why customers choose you, the system should follow the business, not the other way round.

That is how we approach it: first we spend time with the people who will use the system, and only then do we design and build it. There is more on our CRM and ERP systems page. If you already have new software gathering dust, get in touch — quite often the problem turns out not to be the people but a handful of steps set up the wrong way round.