Five mistakes that derail a software rollout

We have run enough rollouts to notice a pattern. When a project stalls, the cause is almost never technical.

1. Everything goes live at once

The company decides that from the first of the month it will switch finance, warehouse, manufacturing and payroll all together. Everybody learns everything at the same time, mistakes overlap, and nobody can tell which module caused what.

Better: start with whatever delivers the most — usually inventory and sales. The rest gets added once the first part runs without thinking.

2. Old data is migrated without cleaning

A code list of 4,000 items where 1,200 are no longer sold, three versions of the same customer, and partners with no VAT number. Move that across as it is and you have the same mess in a new program.

Better: go through the code lists before the migration. It is not fun, but you only do it once.

3. Training is aimed at “the company”, not at roles

Everybody sits in one room for a two-hour tour of the whole system. Sales reps hear about depreciation, the bookkeeper hears about POS shifts, and nobody retains their own part.

Better: short, role-based sessions. Warehouse learns receipts and issue notes, sales learns quotes and invoices, management learns reports.

4. Nobody is allowed to decide

A question comes up — “do we handle discounts per customer or per group?” — and the project stops until everyone agrees. Without one person who can decide, every such question costs a week.

Better: name one person inside the company who owns process decisions and has time for the project.

5. Parallel running drags on

“We will run both systems for a month or two, just in case.” The result is double work, people drift back to the old program, and the new one never becomes real.

Better: a short overlap, a clear switch date, and extra support in the first week.

What actually helps

A realistic deadline, one accountable person, cleaned data and role-based training. All four sit on the customer’s side — which is exactly why they are worth agreeing before the contract is signed, not after.