The system went live
and nothing got faster

How do we know the implementation did not work?

Go-live is a date, not a result. Ask what was supposed to get faster or cheaper, then check. If nobody wrote that down before the project started, these signs will tell you most of what you need:

• People keep a spreadsheet beside the system, and when the two disagree they trust the spreadsheet
• The same number gets entered twice, once in the system and once somewhere else
• Reports get exported and fixed by hand before anyone reads them
• Month-end or job cost reporting takes as long as it did before go-live, or longer
• One or two people are the only ones who know how to get certain things done, and work waits when they are away
• Your supervisors talk about the system as something they feed, not something they use

One of these on its own can be a training gap. Several together usually mean the system was set up around the wrong process.

Why does a system go live and change nothing?

Because it was configured to do what the business did before, including the parts that should have stopped. The implementation partner built what they were told. If nobody decided how work should move after go-live, the system got the old path with new screens.

That shows up as the same two costs you had before the project. The first is waiting. A purchase order can still sit for days, because the approval moved into the system but the habit of who approves it and when did not. The second is re-entry. Information still gets typed a second time, or hunted down in an inbox, because the step that should have passed it along was never built, or was built and nobody trusts it.

Data plays a part too. If records came across in a state nobody trusts, people check the new system against the old source, and now you are running both.

Is it the software or the way it was set up?

Find out before you spend anything. Take one real transaction, a job, an order or a month-end, and walk it through the system from start to finish with the people who do the work. Every time it leaves the system for a spreadsheet, an email or a phone call, write down why.

Then sort each one into four piles:

1. Training. The system does it and people do not know how
2. Configuration. The system can do it and was not set up to
3. Process. The step should not exist, or belongs to someone else
4. A real gap. The software cannot do it

In our experience the first three piles hold most of the list, and all three can be fixed without replacing anything. Only the fourth is a question about the software.

Should we replace it?

Not first. A replacement means new licences, a second implementation, and a second disruption for the same people who are still tired from the first. If the cause was how the work moves, the new system inherits it and you pay twice for the same result.

Replacement makes sense when the fourth pile is long and covers how you actually make money, when the vendor has stopped developing the product, or when nobody local can support it. Even then, fix the process first, so the second implementation does not repeat the first.

Is this our implementation partner's fault?

Sometimes, but rarely only theirs. A partner configures to a scope and a budget, from what the client tells them. If nobody on your side could say how work should move between estimating, operations and accounting, the partner filled the gap with the software's defaults or with the old process.

Go back to them with evidence, not a complaint: the walk-through, the list of workarounds, and which ones are configuration. Some of the fixes will be theirs to make. A good partner will welcome a client who can say clearly what they need.

Why do our people keep working around the system?

Because the workaround is faster for them, or the system asks them for something nobody downstream uses. A spreadsheet that takes two clicks will beat a screen that takes twelve. A field that matters to accounting but not to the person typing it gets left blank, and the report built on it is wrong.

Treat every workaround as a finding before you treat it as a discipline problem. Resistance is information about the design. Some workarounds point to training. Many point to a step that should be set up differently, or should not exist at all.

What does fixing it look like?

Smaller and less dramatic than the original project. In order:

1. Walk one real transaction end to end and list every workaround and every place information gets typed twice
2. Sort the list into training, configuration, process and real gaps
3. Decide who owns each step across departments, so every field gets filled by someone whose job it is
4. Fix the cheapest piles first. Training, configuration and process changes usually cost less than add-ons or a replacement, and they show you whether the real gaps are as big as they looked
5. Pick two or three numbers that should move, such as days to close month-end, days from job completion to invoice, or hours a week spent re-entering information, and check them every week until they do

What if we are still partway through the implementation?

Then this is the cheapest moment to catch it. Before go-live, ask the partner to walk one real transaction through the configured system with the people who will use it every day. Workarounds that show up in that test do not go away at go-live. Fix the process now, while the changes are still configuration and not rework.