ERP Rescue Consultant, UK

Warning signs that a UK project needs outside help

Some trouble is normal in any ERP project. The time to bring in an independent rescue consultant is when the same problems keep returning and the people closest to the work have stopped believing the plan. In UK projects, the warning signs often include:

• Red, amber and green reporting that stays green until a deadline, then turns red overnight.
• A go-live that has been pushed back past a VAT quarter or the financial year-end, with no clear reason why the next date will hold.
• Finance running Sage, Xero or the legacy system in parallel long after go-live, because the new ledger does not reconcile.
• Payroll journals, bank feeds or the ecommerce connection failing in ways nobody owns.
• Change requests piling up faster than they are closed, each one adding cost without moving the project forward.
• Turnover in the partner's team, so new consultants keep asking questions the business answered months earlier.

When several of these appear together, the cause is rarely a single bad decision. It is usually a combination of thin requirements, an unrealistic timetable and unclear ownership on both sides. Spending more on the same approach seldom fixes that. A short, independent assessment, as described under fixing a failed ERP implementation, is the lower-risk first step.

Protecting VAT, payroll and month-end first

A struggling ERP cannot be allowed to make the business late with HMRC or with its staff. Before any redesign, I work with your finance team and accountant to agree interim arrangements, written down so they survive holidays and staff changes.

• VAT. If the next return must come from a system that is not yet trusted, your accountant decides how to prepare and check it. That may mean reconciling the system's VAT report to transaction listings, or a temporary bridging approach that keeps the digital link. Any earlier errors that need correcting are for your accountant to handle.
• Payroll. Payroll usually runs in separate software or with a bureau, so pay itself is rarely at risk. The concern is the journal: making sure it still posts to the right accounts so that the balance sheet stays reliable.
• Month-end. A temporary close checklist lists every manual step, reconciliation and spreadsheet needed until the system is fixed, with an owner for each.
• Customers and suppliers. Invoicing, statements and payment runs are checked first, because errors there are visible outside the business.

This stabilization buys time to diagnose the project properly. Without it, the team is too busy firefighting to give the recovery the attention it needs.

Reviewing the contract and statement of work with your solicitor

In the UK, an ERP implementation is often governed by several documents: the software vendor's subscription terms, the partner's master agreement, one or more statements of work and a trail of change requests. When the project goes wrong, what each party promised becomes the central question. I am not a lawyer, and legal advice must come from your solicitor. My contribution is to put the facts in order.

I build a chronology that links each deliverable in the statement of work to its current status, the change requests that altered it and the invoices raised against it. Alongside that, I highlight the clauses your solicitor will want to read closely:

• how acceptance is defined and whether any milestone was formally signed off;
• the change control procedure and whether it was followed;
• assumptions and client dependencies, and evidence on whether each side met them;
• limits of liability and any service credits;
• ownership of configuration, custom code and documentation;
• exit and transition assistance if the relationship ends.

The aim is to resolve matters through a commercial conversation rather than formal proceedings wherever that is possible. A clear, neutral chronology helps that conversation, because both sides can see the same facts instead of trading recollections.

Resetting the relationship with your implementation partner

Changing partner mid-project is expensive and slow, so the first option to test is whether the current relationship can be repaired. That depends on facts, not feelings. If the partner understands the platform, has people available and is willing to work to a revised baseline, a reset is usually the fastest route to a stable system.

I prepare for the reset by sharing the draft fact base with the partner before it reaches your board. Their perspective matters: projects often slip because business decisions arrived late, data was supplied late or key users were not released from their day jobs. Recognizing those points openly makes it easier to agree on the rest.

The reset workshop then works through a short agenda:

• what the business needs for a safe first release, and what can follow;
• disputed items, resolved against the original scope documents;
• named people on both sides, with commitments on continuity;
• acceptance criteria written in business terms;
• a governance rhythm with a shared risk and issue log.

If the reset fails, you have lost little and gained a clear record of why a change of partner is necessary. The broader method is described under ERP recovery, and the readiness side under ERP go-live support.

Continue, change partner or change platform

With the facts established and the business stable, the board can choose between realistic options rather than reacting to the latest crisis. I write each option up with its risks, dependencies and cost drivers, without figures that cannot yet be known.

• Continue with the existing partner under the reset plan, when both platform and partner are fundamentally capable.
• Narrow the first release to the processes the business cannot operate without, and phase the rest.
• Change partner on the same platform, when the product fits but the delivery team does not. The configuration, documentation and data already produced become the starting point for the new firm.
• Change platform, only when the evidence shows the product cannot support core requirements. In that case a fresh, properly run selection follows, using the requirements the rescue has clarified.

I can remain involved to run governance through to a stable go-live, or hand over a written plan for your team to follow. The work is delivered remotely in UK hours, with on-site days by arrangement. If your system is live and broadly working but underperforming, the UK ERP audit is a better fit. To see how I support projects from the start, read about my ERP implementation consulting in the UK, or start from UK ERP consulting and the UK hub.