Can you turn around a failing implementation without ripping everything up and starting again?

Usually, yes that's the more common outcome.

Most failing implementations aren't failing because the software is wrong; they're failing because scope was unclear, the project team was isolated from the stakeholder community and focused on building the system to the ‘as is’, rather than a fully stakeholder scoped ‘to be’ ideal state, The wider stakeholders were not taken along with the implementation process and trust in the system is lacking or a heavy focus on keeping the operational status quo at the cost of system optimisation that can release the desired benefits.

Fixing those doesn't require a restart. It requires someone who can diagnose accurately, get the right people in a room telling the truth at the same time, and reset the plan around reality instead of the optimistic version everyone's been reporting upward.

Teams have reverted to spreadsheets or side-systems after go-live. How do we get them back into the actual system?

You don't get them back by mandating it harder that's been tried, and it's probably how you ended up here.

You get them back by finding out what the spreadsheet or work around does that the system doesn't, because there's almost always a real reason, not a stubbornness reason.

It's often something small: the system takes eleven clicks to do what the spreadsheet does in one, or it doesn't show the one piece of context they need to make a decision. Fix that specific gap and adoption generally follows. If the issue is broader then look to what’s in it for them, not how it will make the business better but what they’re getting for their extra 11 clicks (let’s be clear 11 clicks is bad and needs fixing but you get the point). New systems don’t always make thing quicker or easier, what they do is give better outcomes, focusing on how those outcomes will make life better for the stakeholders is where you’ll get your adoption.

We went live months ago and people still aren't using the system properly. What's actually going on?

By this stage it's rarely a training problem, even though training is what usually gets offered again. If people have had months and still haven't adopted it properly, it’s usually because the system doesn't map cleanly onto how the work actually happens and they've quietly decided that's not their problem to fix so they've either built a workaround that's less painful than the system, or they’ve just gone back to using the old systems and processes.

Watch what they do when nobody's watching, the spreadsheet still open next to the system, the WhatsApp group coordinating what the system should be coordinating. That's not resistance to change, that's evidence. It tells you exactly where the design and the reality diverge and gives you a place to start the conversation with them.

What does a rescue engagement actually look like day to day in the first couple of weeks?

Less analysis than people expect, more direct intervention.

Days one to three are usually spent getting an honest, first-hand picture, talking to the people actually doing the work, and living their pain with them. From there it's rapid triage: working with the teams to build trust and get them aligned to the wider issues, so if required, we are able to create immediate tactical fixes for what's causing the most damage, while starting the proper diagnostic on root cause in parallel. This work is hands on and will be done in line with day to day operations so we can ensure minimal disruption.

The trust that built during this phase will be key to aligning teams around a the wider more complex strategic business transformation objectives.

By the end of the first two weeks you should have a stabilised situation and a wireframe for a clear, honest read of the operational landscape along with next steps.

We’re 6 months and are not seeing the promised benefits?

Some gap between the business case and reality is normal benefits cases are built pre-go-live on assumptions, and reality is always messier and nuanced but here’s a couple of things to check.

Check usage. What often happens is leadership looks at the long-standing metrics, sees the team using the new system day to day, and assumes that means proper usage. But the reality is one person using it exactly as designed, and everyone else somewhere below that, right down to people who've gone back to working the old way while the system sits open on their screen looking pretty but doing nothing.

Check that you don’t have existing KPI’s and targets that are pulling away from the behaviour and related benefits you want to see from the new system. I've seen a CRM built to optimise converting sales with existing client relationships, while the sales team stayed targeted purely on new client acquisitions. People optimise for what they're paid on, not what the tool's built to enable.

Our ERP and WMS don't talk to each other properly and it's causing chaos. What's actually going on?

Integration problems are almost never "the systems can't talk to each other" they're generally "nobody agreed what data means the same thing in both systems before they went live."

A SKU status, an order state, a stock adjustment, if the two systems have different definitions of what those mean when they update you get numbers that don't reconcile, phantom stock, orders stuck in limbo to name but a few.

The fix is rarely more middleware. It's usually a data governance and master data exercise that should have happened before go-live and didn't. Done properly it will require the input and alignment of all process stakeholders even if they don’t officially use the system. This exercise is deceptively complex and notoriously difficult so be sure to recognise this and work to give the teams the operational breathing space to get it done properly.