Frequently Asked Questions
What does someone like you do differently from a big consultancy?
I get called in specifically because the standard playbook has already failed or isn't fit for the situation, that's the pattern across most of my engagements.
Big consultancies are built for scale and repeatable methodology; that's genuinely valuable when the problem fits the method. When it doesn't, you need someone senior enough to make judgement calls without escalating through five layers, and independent enough to tell you the uncomfortable truth about your vendor, your internal team, or your original strategy without worrying about the next contract renewal.
I sit outside formal hierarchy on purpose, so I can say the thing nobody internally is positioned to say. My aim is to ensure that your value is maximised and your team is self sufficient, then I move on.
Should we fix our current system or rip and replace it?
Rip and replace is the right answer less often than people think, and the wrong answer more often than vendors will tell you (they have an obvious incentive).
Ask three questions before you decide anything: is the core platform fit for purpose for where the business is going in three years, or was it wrong from day one? Is the failure in the software, or in how it was configured and rolled out? And can you separate "this project has been painful" from "this platform is wrong" those get emotionally tangled and they're not the same question.
A proper fit assessment against your actual operational requirements, done by someone with no stake in either outcome, is worth doing before you commit to either path. These are typically carried out by senior change and transformation specialists or a transformation focused Enterprise Architect.
Can you turn around failing adoption without ripping everything up and starting again?
Almost certainly, yes that's the more common outcome.
Most 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.
We’re 6 months in 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.