ERP Recovery Roadmap: How to Rescue a Failing ERP Programme

ERP Recovery: Why Programmes Fail and What It Takes To Pull Them Back

If your ERP programme is drifting off track, you are not alone. Most organisations underestimate how quickly a delayed decision or a sanitised status report can push an implementation towards crisis. This episode unpacks what causes ERP programmes to fail, what a structured ERP recovery plan looks like in practice, and what you can do in the next 30 days to change the trajectory.

In this episode of the Comparesoft ERP Podcast, Adileh Mountain, Founder at Strat Scale Advisory, shares the warning signs, root causes, and practical recovery steps that determine whether a struggling programme can be turned around. Adileh draws on 15 years in construction and EPC (engineering, procurement, and construction) operations, plus her experience leading ERP transformation and recovery work at Deloitte.

When Does ERP Recovery Become Necessary?

Adileh explains that the call for ERP recovery typically comes from one of three people:

• The CFO calls when they have to stand in front of the board and cannot defend the programme’s position. The programme team is telling one story and the numbers are telling another.
• The COO calls when go-live is weeks away and the operational reality on the ground does not match the green status being reported to the steering committee.
• The project director calls from the loneliest position of the three. They have already escalated their concerns, but those concerns have been ignored. They need someone independent to say what their position does not give them standing to say.

What is common across all three is a moment of admission. The executive acknowledges, usually privately, that what they are currently doing is not working. That moment is where ERP recovery begins, not with a technical fix, but with an honest conversation.

How Do You Define ERP Failure?

Most people define ERP failure too narrowly. If failure only means the system never went live, the number is low. Very few projects are abandoned entirely.

But if failure includes implementations that launched on time, received a congratulatory email from the CEO, and delivered none of the promised outcomes, the real rate is much higher. Adileh describes programmes where field adoption sits at 30%, where executives quietly keep the old system running as a backup, and where finance teams reconcile reports outside the system manually because the data cannot be trusted. Those implementations are counted as successes. They are not.

Her definition is direct. An ERP failure is when your organisation spends the money, completes the implementation, and does not fundamentally change how the business runs. The technology runs. The business transformation does not.

The real measure of success is not go-live day. It is six to 12 months later, when the CFO can make decisions faster, the COO has clear project-level cash flow visibility, and field adoption averages above 80%.

Diagnosing a Failing ERP Programme: The First Step in Any ERP Recovery

When Adileh is called into a struggling programme, the first step of her ERP recovery process is reading the organisation, not the system. In the first week, she focuses on three questions:

• Is leadership getting an honest picture, or a version that has been prepared for them?
• Does anyone on the team have authority to define what good enough looks like for go-live?
• Is there someone with a vested interest in protecting the current narrative?

The technical issues (data migration problems, integration failures, testing defects) are almost always solvable. What makes them unsolvable is when the organisation cannot admit they exist.

Adileh works through 10 dimensions of implementation health using a structured diagnostic. Those dimensions are governance, process configuration, data readiness, technical development, testing, infrastructure, change management, vendor accountability, go-live readiness, and organisational honesty. Where the gaps are largest is where the ERP recovery roadmap focuses first.

The Root Causes That Make ERP Recovery Necessary

The most common driver Adileh sees is a lack of leadership direction. When the executive team treats the steering committee as a status update rather than a decision-making forum, ownership erodes and direction from the top down is lost. This pattern is present in almost every ERP recovery she has been involved in.

Incomplete requirements are a close second. If you do not clearly define your requirements before implementation begins, the vendor or implementation partner fills the gaps with their own interpretation. They rarely have the detailed knowledge of how your business actually operates, particularly in complex sectors like construction.

Adileh also highlights organisational politics. Individuals with a vested interest in the current narrative brush problems aside. The steering committee ends up hearing a sanitised version of reality instead of the true position. This is the most dangerous pattern because it is invisible until things go seriously wrong, and by then, the cost of recovery is significantly higher.

These root causes echo the findings explored in the Comparesoft episode on ERP critical success factors, where governance and early-stage decision-making were identified as consistent separators between success and failure.

ERP Recovery in Practice: $4M in Avoided Costs and 85% Field Adoption

One of the most striking examples Adileh shares is an ERP recovery she led on a programme that was six months behind schedule, over budget, and headed for failure. The organisation was 15 months into the project and in its second system integration testing cycle. Custom-built objects were failing every test scenario. Data conversions were not meeting the exit criteria agreed by the business.

The testing cycle, originally six weeks, was extended repeatedly until a holiday break forced it to pause. That pause became the turning point.

During the break, Adileh had an honest conversation with a trusted counterpart on the client side. She presented three options: two course corrections of varying scale, and a third option involving a full replanning scenario. The third was the most disruptive path, but also the one with the highest chance of delivering the intended ROI.

The executive chose the hardest option. Over the following seven months of ERP recovery execution:

• A new project baseline was established with clear exit criteria for every workstream
• Task forces were formed to address the most challenging design gaps
• A formal accountability structure was put in place, documenting performance expectations instead of relying on relationship conversations
• Field teams were brought in to help build the solution with genuine intent

The result was the smoothest go-live Adileh had ever been part of. No fires. No crisis calls. The system stabilised within a month. Field adoption landed above 85% across the organisation.

Without the recovery intervention, Adileh estimates the programme would have added another four to five months of costly iterations and seen adoption degrade significantly, particularly in the field.

Why Construction Firms Are Especially Vulnerable To ERP Failure and ERP Recovery

Construction firms do not typically implement ERP because of a clear strategic vision. They are forced into it because they have outgrown their old systems or something is broken. The most common triggers include:

• Cash flow visibility: the CFO cannot get a reliable project-level cash position without waiting two weeks for a manual consolidated report
• Subcontract management: hundreds of subcontractor relationships managed through disconnected spreadsheets, making it easy for projects to lose money quietly
• Change control: changes on every project, but financial impact not tracked from day one
• Audit and compliance: especially for firms growing into public sector work, where traceability becomes critical

The capability most consistently underweighted during ERP selection is field data capture. Firms spend significant energy evaluating financial modules and dashboards, but very little evaluation time asking whether the system can capture accurate data from a live construction site.

Everything downstream (forecasting, cash position, cost of completion) is only as good as the field data feeding it. If that data is incomplete, the conditions for a future ERP recovery are already being set.

Why Field Adoption Is the Make-or-Break Factor in Construction ERP Recovery

Field adoption is the most important factor in whether a construction ERP implementation succeeds or eventually requires recovery. Finance and accounting modules are relatively straightforward to adopt because those processes are standardised across business types. The real value of a construction ERP comes from the site: cost capture, progress reporting, subcontract management, and change documentation.

If your field adoption is low, your finance team is working with incomplete or outdated information, regardless of how well the system is configured.

What drives field adoption comes down to two things: trust and simplicity. The system has to work on-site where connectivity is unreliable. The people using it are not desk workers. They are wearing hard hats and walking the site with a clipboard.

Most importantly, the system has to give field teams something back. If it takes data from the field and returns nothing useful to the people entering it, adoption will fail regardless of how thorough the training programme was.

Once field users decide a system cannot be trusted, you are no longer fighting an adoption challenge. You are fighting human nature. That makes any subsequent ERP recovery significantly harder to achieve.

ERP Recovery Advice: What To Do in the Next 30 Days If Your Programme Is Drifting

If you are a CFO or COO and you suspect your programme is off track, Adileh recommends three actions that form the starting point of any effective ERP recovery.

1. Get an independent view of your project health

Do this before your next steering committee meeting. Not from your implementation team, not from your internal programme office, but from someone with no stake in the outcome. That single step will tell you more than six months of status reports.

2. Ask the questions that matter based on your own observations

Do not rely on the latest status report. Adileh has built a five-minute diagnostic covering 10 dimensions of implementation health. It tells you where you are on track, at risk, or in crisis.

3. Have the conversations you have been avoiding

There is almost always a conversation that has been put off. A vendor commitment that has not been documented. A go-live date that everyone knows is wrong but no one will say out loud. The cost of avoiding that conversation is everything discussed in this episode.

Month six is a critical threshold. At that point, you can still change the trajectory of your entire programme. By month 10 or 11, the cost of adjustment becomes astronomical and your opportunity narrows completely.

How To Prevent ERP Recovery: Build Honest Accountability From Day One

The best ERP recovery is the one you never need. That means building the conditions for honest accountability before problems escalate. Getting the foundations right early, including the strategic groundwork covered in ERP Phase 0, reduces the risk of needing a recovery later.

Assemble the people in your organisation who will tell you the truth. Give them the authority to act on the decisions they make. Protect them when they do.

Build a governance structure where the steering committee is a decision-making forum, not a performance. Empower your project director with real organisational standing, not just a title. Create an environment where a site manager, project accountant, or key user can raise a concern without it being managed away before it reaches leadership.

Every failure described in this episode had the same root cause: an environment where the honest picture could not reach the people who needed to act on it.

The organisations that get this right do not need ERP recovery. They course correct in real time because honesty is the path of least resistance, not the most dangerous one.

Full Transcript

Ryan (00:01): Adileh, welcome to the show. How are you?

Adileh Mountain (00:04): I’m great, Ryan. How are you?

Ryan (00:05): Very well, thank you. So Adileh, you work directly with CFOs, COOs, VPs in the mid-market construction firms. Can you give a quick overview of Strat Scale Advisory and the service you provide those leaders?

Adileh Mountain (00:19): Sure, and thank you. Thanks for having me. I help mid-market construction companies recover value from technology investments that are not delivering what they were promised to deliver. My clients are CFOs, COOs, and VPs of operations who are either heading into a major ERP implementation or they’re already in one that’s not going to plan. I come in and I find out what’s broken and try to build something that the team can actually own and deliver with success.

Ryan (00:46): What was the moment you realised you wanted to move from being inside delivery to helping organisations fix the systems behind them?

Adileh Mountain (00:56): It wasn’t a single moment, honestly, but it was a combination of events that made my direction increasingly obvious. I spent the first 13 years of my career in oil and gas, EPC operations, working across every phase of the project from design and engineering through to delivery and close. I have an engineering background myself. I kept getting pulled into problem-solving layers of the business, finding where things were unclear, building the systems around them to make things visible and bring order to some of the chaos, making complex operations easier to manage. That became my reputation over the years before I even thought of a career positioning of that.

Adileh Mountain (01:35): The oil and gas industry is very cyclical as well, so there were significant ups and downs during my time there, including the 2008 crash. There were multiple rounds of layoffs, more than one, obviously, but I was kept on each time. And that mattered a lot to me because it was confirmation. When an organisation has to make hard decisions about who stays and who goes, and they choose you, that tells a lot about the value that you’re actually delivering and not the value you think you’re delivering to them. After that, I moved into commercial real estate construction, where I implemented the same significant improvements and project tracking mechanisms and management.

Adileh Mountain (02:17): And the impact was immediate, it was real, it was visible. That was proof that my operational understanding wasn’t just industry-specific to me. At that point, I started thinking maybe I can bring that value to not just one employer, but across multiple different companies. And that was when I made the shift into Big Four Consulting, where I got to work on ERP transformations and process improvement across a range of industries and clients.

Adileh Mountain (02:50): The experience was extremely valuable, very exciting work. It showed me something I couldn’t unsee about the industry, though, and that was that the frameworks that designed these solutions — the firms, for example, had these rigid frameworks that they were using for repeatability — they weren’t for every client. Some clients had more complex businesses that needed to consider nuance.

Adileh Mountain (03:10): When a construction business needs something that doesn’t fit the methodology that’s been forced, the methodology usually wins because it historically is proven. I watched those decisions being made, and some of those times they were wrong. I didn’t always have the standing to change those decisions in the room. So it ultimately pushed me out, not because I wasn’t satisfied, but because I recognised that I could do a better job by myself, especially with my understanding of the construction industry and operations, without those rigid frameworks standing between me and a solution to a problem that I thought my clients deserved. So that was the cascading effect. And here I am.

Ryan (03:48): Here you are. So we’ve mentioned about what sort of leaders you’re dealing with at Strat Scale, but at what point are they calling you? What triggers that call?

Adileh Mountain (04:03): So there are typically three categories and the trigger point is usually the same thing, although those folks think that they’re different initiation points. I’ll go through them and bring that back around in a minute. For example, the CFO calls me when they have to stand in front of a board and either ask for approval for a new tranche of funding because the schedule has slipped, and the project is in serious trouble, but they can’t defend their position because the information that they have just isn’t complete or real. The programme team is telling them one story and the numbers are telling something completely different. That’s usually when I get the call from the CFO. Not because the project’s over budget, but because they’ve run out of runway to absorb the uncertainty themselves.

Adileh Mountain (05:00): The second example is a COO call. When the go-live date is just weeks away and the steering committee is hearing green or amber status, and they can see with their own eyes that the operational reality on the ground isn’t anywhere near ready. They know what a bad go-live can do to active projects. It creates mayhem. They need someone independent who can come in and walk into the room and give an honest assessment of the project so that the steering committee can listen to those points.

Adileh Mountain (05:35): And then the final one is not necessarily an executive position, but it’s the project director types. The ERP project directors calling from the loneliest position of the three. They’ve escalated their concerns already, but they’ve been ignored. The implementation partner has gone quiet and they’re not communicating properly. Their objectivity is questioned because they’re so close to the problem. So they’re not always trusted with their assessments, and they need someone who can voice their concerns without having to play the politics of it. Their position doesn’t give them the standing to say what they need to say, so they need somebody else to say it for them.

Adileh Mountain (06:10): But coming back around to it, what triggers the actual call is a moment of admission. The executive acknowledges, usually privately to themselves, that they don’t have all the answers and what they’re currently doing isn’t really working. These implementations are some of the hardest projects that organisations will ever go through. Most underestimate them badly. Most implementation consultants also don’t have deep understanding of the industries or the businesses that they’re serving, which creates gaps in the design that only become visible when something fails later down the line.

Adileh Mountain (06:45): That’s precisely where my background matters, because I can speak the language of both the field people and the language of the ERP team without having to be translated for me. They’re almost crossed — their conversations are crossing each other. They’re not speaking the same language to each other, even though they may recognise the same problem. They don’t explain it to each other in the language that lands.

Ryan (06:53): They almost need that outside guidance, don’t they, coming into it?

Adileh Mountain (07:15): And so what is common across all of these issues, most of the time, is the internal narrative that has collapsed. It’s either miscommunication, talking across each other, or just not acknowledging the reality. The decisions have been sitting, piling up, unmade, unresolved. The project’s drifting towards a crisis, and nobody’s been empowered to stop that. They haven’t been empowered to speak out about it. What I’ve noticed is by the time someone picks up the phone, they’ve known something was wrong for a long time, but they weren’t able to or willing to admit it. And once they acknowledge that the problem isn’t going to resolve itself, they pick up the phone and they give me a call.

Adileh Mountain (07:55): But I just want to do a plug here. If you’re an executive listening to this and something in what I’ve described resonates with you, I’ve actually built a couple of tools. The first one I’m going to introduce here is called Radar. It is specifically for that moment when you’re not sure what to do next. It’s an executive-level diagnostic that gives you objective data that will assess if your project is safe, at risk, or legitimately in crisis. It only takes five minutes to complete, and you can access it by going to erpplaybooks.com.

Ryan (08:38): Of course, Adileh, of course. Thank you very much. So Adileh, this episode we’re talking about ERP recovery, the planning that goes into it. Prior to that, I’d like to get your opinion on how you define ERP failure today. I’ve had a lot of conversations, a lot of people saying ERP implementation failure sits about 70 to 90 percent. Some others say it’s lower. What’s your opinion on that? How do you define it and where do you think the failure rate sits?

Adileh Mountain (09:05): The 70 to 90% number is real to me, I think. It depends entirely on how you define failure. And I think most people define it too narrowly. If failure means that the system never went live, the number is much lower. There aren’t many projects that actually abandon. But if failure includes go-lives that happened on time, on budget, with a launch and congratulatory email from the CEO, and yet delivered none of the promised outcomes that the programme has set out to achieve, then the number is much, much higher.

Adileh Mountain (09:40): I’m talking about adoption rates sitting at 30% in the field, executives quietly keeping the old system floating because they’re worried about turning it off, so they’re using it as a backup, or the finance teams reconciling reports outside of the system manually because the data can’t be trusted. Those implementations are counted as successes because they went live, but most industry statistics don’t count them as failures. They’re not real successes.

Adileh Mountain (10:10): So here’s my definition. An ERP failure is when the organisation spends the money, completes the implementation, and doesn’t fundamentally change how the business runs. The technology runs, but the business transformation doesn’t. And the reason why this matters for the executives in this type of conversation is that the moment most organisations declare victory is at go-live. The project closes, the implementation partner packs up and leaves, the business moves on. But the real measure of success is six to twelve months down the line when the CFO can actually make decisions faster, the COO has clear visibility of the cash flow at the project level, and the field adoption averages above 80%. Those questions are rarely asked later after implementation is closed and almost never answered honestly. So the statistics, I don’t think, are true in the industry.

Ryan (11:02): Excellent. And so when you’re called into an ERP programme that’s starting to fail, what do you go and diagnose first? What’s your first process?

Adileh Mountain (11:25): Well, so in the first 48 hours, for me, it’s about reading the organisation, not the system itself. Anyone can look at a programme plan, a steering committee status report and tell you what the official narrative is. That’s not the hard part. What I need to understand is the gap between that version of reality and what is actually happening on the project. It’s the unspoken reality.

Adileh Mountain (11:50): And so the three questions that I try to answer in that first week are: number one, is the leadership getting an honest picture — not the version that’s been prepared for them, not the sanitised version, but what’s genuinely happening on the ground? Number two, does anyone on the team have authority to actually define what good enough looks like for go-live, and has the standard been held throughout the project? Are those metrics being held to as they execute the implementation? And the third one is, what’s the organisational politics situation? Does a single person have a vested interest in the current narrative and are they trying to hold that tightly, which is causing distrust amongst the rest of the team?

Adileh Mountain (12:30): And here’s the thing about the technical issues. Almost never is technology the problem. Data migration problems, integrations, testing defects — those types of things are solvable. What makes them unsolvable is when the organisation can’t admit honestly that they actually exist or they’re just ignoring them.

Adileh Mountain (12:50): So I work through 10 dimensions of implementation health using a structured assessment playbook I’ve created that’s called Sonar. I want to introduce this to your listeners as well. If you’re an executive, start with Radar, which I introduced previously, which is my five-minute executive diagnostic. Sonar is what comes next. It goes 94 questions deep across 10 dimensions. Those dimensions are governance, process configuration, data readiness, technical development, testing, infrastructure, change management, vendor accountability, go-live readiness, and most importantly, organisational honesty.

Adileh Mountain (13:30): It’s built for the project team to work through together to get a scored, honest picture of where things actually stand, not what’s being reported. Each dimension gets its own score. The severity of that score is what drives the recovery roadmap that I then propose. Where the gaps are largest is where we focus first, and the roadmap is structured around closing those gaps in the right sequence. If you want to get your team started on a diagnostic now, it’s available as a free download at erpplaybooks.com.

Ryan (14:04): And that process, Sonar, that’s in your first week, that first four weeks?

Adileh Mountain (14:09): Yes, exactly. It’s the 94-question-deep diagnostic that I go through to score every dimension of the project, and it informs what’s the biggest driver of the failure.

Ryan (14:24): What is the most common root cause you see behind a failure? You mentioned that it’s not necessarily technology. It could be a handful of things, but is there one common thing that you see that is causing these ERP failures?

Adileh Mountain (14:37): Yes, one common thing I would say — I could give you a full list of them, but the most common one is lack of leadership direction. If leadership is absent, the ERP implementation gets handed over to a project manager or the PMO, and the executives aren’t accountable for the outcomes. They sit through the kickoff, and then they become hands-off after that. They treat the steering committee as a status update rather than a decision-making forum. And when that happens, ownership is eroded and that direction from the top down is lost. So that, to me, is the number one driver.

Adileh Mountain (15:20): I could go on, but I would touch on a couple more very quickly. Incomplete requirements is a big driver as well. If you don’t know what you’re designing and what your outcomes need to be, then you’re going to have huge gaps in what you’re implementing. And most likely, it’s the vendor who’s filling those gaps with their own interpretation of what the business process needs to look like. And they don’t necessarily have the knowledge of that kind of business in detail. Construction is complex.

Adileh Mountain (15:55): Which brings me to the next one: when the operations teams are not involved in the design decisions that are made. Operations are complex, and when things break in the field, they’re catastrophic in a lot of cases. So your design has to include the point of view of the operating people who will be the end users of the system ultimately.

Adileh Mountain (16:20): And then what I’ve touched on before is politics — the games that people play because they have a vested interest in the outcome. They’ve made decisions and they want to hold to those decisions because their reputation is dependent on it. When a problem surfaces, it gets brushed aside if it’s related to decisions that have already been made. And so the steering committee ends up hearing a sanitised version of the story instead of the true position. And that’s the most dangerous pattern — it isn’t even visible until things go really wrong.

Ryan (16:58): Something you touched on there which is really interesting, Adileh — requirements. So if they haven’t set the requirements, the vendor fills in requirements for them. It’s such a critical part of setting what is actually needed from the system. How do you recommend businesses sit down and work out what requirements are actually needed to fill these gaps and to address the challenges they’re facing?

Adileh Mountain (17:25): Yes, I would highly recommend that they start, in fact, three to six months before an implementation kicks off. While they’re selecting their vendors, they have to have an idea of what those requirements are because their business goals, ideally, should be drawn out five years ahead of time. And so what their implementation needs to capture is those business goals. They need to design their requirements around those long-term goals of the business. So they work their way backwards. And then that drives the decision on what vendor they end up going with.

Adileh Mountain (18:00): Having those requirements documented up front makes sure that everybody’s aligned. I’ve been on implementations where the implementation partner has said, if there weren’t any requirements, they basically pointed to the test scenarios that they got from other projects from other clients. They say this is a list of test scenarios for this specific module, this is generic and this is what your requirements should be fulfilling. But that’s not the full picture of how a business maybe truly differentiates itself. Maybe they have a secret sauce that they want to maintain. That doesn’t get built into the process at all. So they need to have that defined up front.

Ryan (18:50): That’s really interesting. And then obviously you’ve got to have that pushback if the vendor’s saying, we’re going to fill the gap with these requirements. You’ve got to have that pushback as well.

Adileh Mountain (18:59): You definitely have to. You need to be armed with your requirements so that you can have those informed conversations and even challenge your implementation partner to create the configuration in the system to match what you want your processes to look like, not go with the generic solution. And if they can’t do it, then you have to have an honest conversation with your vendor and understand if they have a roadmap for developing that type of process nuance in their system, potentially come to an agreement if they can implement that on a faster track for you, if your relationship with them is going to be something long-term that you want to truly value.

Ryan (19:49): So one ERP recovery project that you’ve worked on really stood out to me, Adileh. You achieved $4 million in avoided costs, 85% field adoption on an ERP programme that was six months behind schedule, over budget, and headed for failure. Could you set the context here? What was the current state of this organisation’s ERP programme and what was truly broken about it?

Adileh Mountain (20:15): Yeah, I’m excited to talk about this case because it’s near and dear to my heart. The project had several causes, but the leadership absence was not one of them. The lack of requirements and business operations people not being involved in the design decisions, and politics, were the biggest drivers of the initial failure. I’ll set the scene for you.

Adileh Mountain (20:45): On the project, the timeline had already been extended by six months because the original timeline just didn’t work. It wasn’t practical for the volume of work that needed to be done as a true transformation. And then the project was in their second system integration cycle. This was probably 15 months into the project. The second integration testing cycle is one before UAT, user acceptance testing. So that tells you how deep into the project it was.

Adileh Mountain (21:10): But only at that point, it was the first time that the client was getting to see their custom-developed solution that the consulting team had built. Three weeks into a six-week testing cycle, the custom objects were failing every single test scenario. And the data conversions weren’t meeting the exit criteria that had been agreed by the business. So the response initially was to extend the testing cycle by four weeks and then by another two weeks. So it ended up being three months long. And finally, it stopped abruptly at the end of December when the holidays forced it to pause.

Adileh Mountain (21:50): So the pause actually turned out to be a blessing in disguise. It was an opportunity. The implementation lead was absent for a few weeks over the holiday period. I was able to have an honest conversation with a trusted counterpart on the client side. I put forward three options on the table to discuss. The first two were course corrections of varying degrees. And the third option was a full replanning scenario, which was the most disruptive path, but also the one with the highest chance of delivering the ROI as the business had originally intended and committed to.

Adileh Mountain (22:37): The executive didn’t just go through the last 18 months or so of pain to end up with a system that nobody trusted. So he decided to go with option three, which was the hardest one — and an honourable decision on his part to make. So we moved into a recovery. For the first two to three weeks, we started to make the plans, and then another seven months of the execution of that plan.

Adileh Mountain (23:00): And the go-live was the smoothest go-live I’ve ever been a part of. No fires, no crisis calls. The system stabilised within a month. We saved four months of costly iterations and landed at over 85% adoption across the organisation. And that last number is what I’m really proud of, because in construction, 85% field adoption doesn’t happen by accident. It’s the result of every decision made in those seven months being made with the field in mind. It was basically a 20-year-old system that needed to be replaced with new technology and cloud infrastructure. So the transformation was really significant for that company.

Ryan (23:41): And where did you see the first shift in trajectory? Was it during that recovery or was it starting in the seven-month plan? What was the first sign of, okay, we’re onto something here?

Adileh Mountain (23:53): The first shift was the courage to select that most disruptive option. I think that changed the trajectory of the outcome of that project entirely, and those days immediately after that decision was made. So the first thing that we actually did was establish a new project baseline that everyone was accountable to — not a negotiated version of it, not a sanitised version of it. It was actually the true current state of the project with new exit criteria that was set for every workstream. There were task forces that were formed to address the most challenging design gaps. And then a formal accountability structure was put in place with the implementation partner and the client owners in mind, documenting performance expectations instead of having those relationship conversations that had been going on for months.

Adileh Mountain (24:50): What that did, organisationally, was reinvigorate the team. It was like overnight, the change. Because it gave people permission to tell the truth again. The project team, who’d been exhausted and demoralised and worried and nervous about telling any kind of truth, suddenly had a baseline that they could report against without it reflecting badly on them. Because the ownership was then distributed across the entire team.

Adileh Mountain (25:17): The field teams were brought in as a task force to help build the solution with genuine intent. They became really invested in the outcome. And then the steering committee were able to receive an honest picture that matched what was actually happening on the ground. So for any CFOs, COOs listening out there, the moment that shifted everything wasn’t a technical fix. It was the moment that the leadership had a genuinely honest conversation and made a decision based on that conversation, rather than a managed narrative that they’d been receiving. Every technical problem in a project is solvable. I’ve said this before — they’re always solvable. What was blocking the solution wasn’t the capability of the team, it was the inability to distinguish between what was real and what was perception. And once that changed, everything else followed after that.

Ryan (25:54): I’m seeing a very common theme of communication and leadership here, the importance of both of those. It’s also quite interesting how if that break, that holiday break hadn’t come about, where they would have gone in four or five months’ time. What would that operation have looked like if you hadn’t intervened?

Adileh Mountain (26:31): Yes, we did talk about that actually post-mortem. And honestly, the biggest challenge that they would have faced there would have been the field adoption, without a question. Because the adoption is the one thing that is almost impossible to recover once it goes away. Because for construction specifically, the field users — site managers, project accountants, superintendents — all of those people, they’re not desk people. They’re not sitting around waiting for the new system to be implemented. They’re out there running active projects under real pressure.

Adileh Mountain (27:10): They watch what happens at go-live very closely, and they make a judgement call in that first week of go-live. If the data comes in wrong, if the reports don’t reconcile, and if the system creates more work than it actually solves or removes for them, they make a decision. They decide that the new system can’t be trusted. And once that decision is made, you’re not just fighting an implementation adoption battle anymore. You’re fighting human nature. You’re asking someone to trust the system that already let them down, and that’s an entirely different battle to fight.

Ryan (27:47): And if a business is hypothetically in month six of a struggling implementation and they don’t have the luxury of a holiday break coming up where they can rest and have a look at it, what’s the first thing that they should really be putting in place now on the road to recovery?

Adileh Mountain (28:06): I would say just get an independent view. Don’t ask your implementation partner or your vendor or your internal team to do an assessment of the programme. Get a truly independent view. And do it now, before the next milestone. Don’t wait for another 30 days or so. And month six matters because at that point in the programme, you still actually have an opportunity to make a change and make some decisions that will impact your outcomes.

Adileh Mountain (28:35): In month 10, 11, 12, decisions have already been locked down. The cost of having to make any adjustments at that point will be astronomical. The change will be too severe to implement, and it narrows your opportunity completely. So the decisions that you make, once you are at the six-month point and you have an issue, if you uncover that you have an issue, the decisions you make in those first 30 days matter a lot. You can still change the trajectory of your entire programme, but that window doesn’t stay open forever.

Adileh Mountain (29:05): And so I would recommend again, the specific thing you can do in those 30 days is to run an honest diagnostic across the 10 dimensions of implementation health. Those are governance, process configuration, data readiness, technical readiness and development, testing, infrastructure, change management, vendor accountability, go-live readiness, and whether your organisation is actually getting an honest picture. That last dimension is the one most implementations never examine. I haven’t actually been on any implementation where that was part of their framework introduced initially. And it’s almost always where the real problem lies.

Ryan (29:55): Excellent. So Adileh, much of your experience lies in construction and operations. We’ve touched on that. What are the drivers for these firms and project-based businesses to first implement an ERP? Is it they want to get a handle on their cost control, they’re looking at cashflow visibility, subcontract management, anything else like that?

Adileh Mountain (30:16): Yeah, well, with construction, these firms don’t typically implement ERP because they woke up one day and had a clear strategic vision. It’s typically because they’ve outgrown their old systems or something’s broken, something’s about to break, and they can’t keep going the way that they’re going. So they’re forced into it most of the time.

Adileh Mountain (30:44): The triggers that I see fall into several categories, like you mentioned. Cash flow visibility is one of them because the CFO can’t get a reliable project-level cash position, for example, without having to wait two weeks for a manual consolidated report. The second one is subcontract management, because hundreds of subcontractor relationships are being managed through disconnected spreadsheets, and that’s a very easy way for projects to lose money quietly without having that visibility.

Adileh Mountain (31:15): The third one is change control, because every construction project has change without a question. And the question is whether those changes are being captured with financial impact tracked from day one, or reconciled at the end when the damage is already done. And then finally, for companies that are growing, especially in the public sector work, auditing compliance is a big issue. Having everything traceable and auditable becomes really important and you can’t do that in manual systems.

Adileh Mountain (31:46): The capability that’s most consistently underweighted in selection of an ERP is the field data capture. Firms spend enormous energy evaluating financial modules and dashboards and very little of their evaluation time asking whether the system can actually capture accurate data from a live construction site, from the people running the work. And that matters because everything downstream — all the forecasting, the cash position, the cost of completion — all of those are only as good as the field data. A world-class financial module fed by incomplete data from the field isn’t transformation. It’s just an expensive way of producing unreliable reports faster.

Ryan (32:39): Would you say that collection of field data, that analysis and reporting on field data, is the most successful part of a go-live for a construction firm — their biggest return on investment?

Adileh Mountain (32:53): I would say yes, and that only comes about by adoption. It’s the adoption in the field that will be the reason for that data entry to be accurate. And therefore the business being greased — the wheels of the business being greased by the data that is put in by those people in the field — so that everybody across the board has visibility. The CFO can make informed decisions. The COO knows exactly what their cash position is or where the risks in their projects lie, instantly. They can see that in their system if that data is captured accurately on a day-to-day basis and centralised.

Ryan (33:34): So field adoption tends to be the make-or-break factor then, in construction ERP?

Adileh Mountain (33:40): For construction, undoubtedly, field adoption is the most important part. And it’s sometimes the most under-invested part of ERP implementations. As I touched on before, finance and accounting are centralised modules. They use those systems because they have to, because their processes are typical across the board, regardless of business type. And so their adoption is relatively straightforward to achieve.

Adileh Mountain (34:08): The value of a construction ERP doesn’t come from the finance module — it comes from the site. The cost capture, the progress reporting, the subcontract management, the change documentation. All of that happens on the field. If your field adoption is low, your finance team is working with incomplete or outdated information, regardless of how well the system is configured.

Adileh Mountain (34:30): And so what drives field adoption in construction comes down to trust and simplicity of the system. The system has to work on site where connectivity issues are rampant. I remember experiencing those when I was on site. And the people using it aren’t desk workers. They’re wearing hard hats and steel-toed boots, walking the site with a clipboard.

Adileh Mountain (34:55): Critically, the system has to give them something back. If the system is taking data from the field and returns nothing useful to the project team in return — to the people who are entering that data — adoption will fail regardless of how thorough the training programme was or how many sessions they held and successfully completed. Field teams adopt systems that actually make their lives easier. So that 85% statistic of adoption that I mentioned in the field previously that we achieved — it came directly from listening to those users before go-live, making deliberate decisions about how the system would work for them, not just for the finance teams. And that investment of time and intent is what most implementations skip. And it’s almost always where they fail.

Ryan (35:41): You were bringing in those users in the decision-making process and that’s helped create that field adoption.

Adileh Mountain (35:48): Yes, absolutely. Because even when I’ve talked to many people in the finance side of these construction companies, they don’t know the nature of operations. They’re on the finance side — they don’t get the operations part of it. So it has to come from the mouth of operations people. And yes, they’re busy, they’re buried in projects and they’re actually serving their clients and making money for the company. But getting them to step away from that and leaving a void in that project, and bringing in good people who can inform those business process decisions, is one of the biggest challenges on any ERP implementation — getting those quality people in the room to have those conversations and bring those insights. But it’s absolutely necessary for success.

Ryan (36:32): So Adileh, we’d like to save these last few questions for sharing your insights and advice for listeners. If a CFO or COO suspects their ERP programme is drifting right now, what should they be doing in the next 30 days?

Adileh Mountain (36:49): Great question. I would recommend three things that they take on. The first one is try to get an independent view of what your project health looks like before your next steering committee meeting, so that you can be honest with what your status is. Not from the implementation team, not from your internal programme office — just someone with no stake in the game who doesn’t have to follow the narrative that is being floated. That single step will tell you more than six months of status reports.

Adileh Mountain (37:25): The second recommendation I’ll make is to ask the questions that matter based on your own observations, not from the latest status report. I’ve built that five-minute diagnostic that covers those ten dimensions of implementation health, and it tells you where you’re on track, at risk, and in crisis.

Adileh Mountain (37:45): And then the third is to have the conversations that you’ve been avoiding. This is one of the most important things. There is almost always a conversation that you’ve been avoiding. For example, a vendor commitment that hasn’t been documented, or a go-live date that everyone knows is wrong but nobody is admitting to out loud. And the cost of avoiding that conversation is everything we’ve just been discussing.

Ryan (38:03): Excellent. Now this might be contrary to the services that you provide, but if you could leave listeners with one principle that prevents ERP programmes from needing rescue in the first place, what would it be?

Adileh Mountain (38:15): Yeah, definitely not plugging my own service, because the reality is that what I would recommend is to build the conditions for honest accountability before you ever need someone like me. Get ahead of it by building out a team that you can trust. You need to assemble the people from your organisation who will tell you the truth, give them the authority to tell you the truth and act on the decisions that they make, and protect them when they do.

Adileh Mountain (38:43): It means building a governance structure where the steering committee is a decision-making forum, not a performance. It means empowering your project director with real organisational standing and power, not just a title. And it means creating an environment where a site manager or project accountant or a key user can raise a concern without it being managed away before it reaches the leadership, without being silenced.

Adileh Mountain (39:10): Every failure I’ve described today had the same root cause. It’s an environment where the honest picture couldn’t reach the people who needed to act on it. The organisations that get this right don’t need a recovery. They course correct in real time because honesty is the path of least resistance, not the most dangerous one.

Adileh Mountain (39:35): An independent advisor, which is what I do, is what you need when that internal system breaks down and fails, or was never built in the first place. But the principle that prevents you from ever needing one is this: never let the official narrative become more important than the actual truth. Protect the people who tell that truth and what is real. That’s where everything else starts from. And your problem-solving will grow exponentially from there.

Ryan (39:57): Adileh, you’ve been a brilliant guest. Thank you so much. You’ve given such a practical view of what it takes to regain control, especially in project-based environments, and what construction firms should be prioritising to make that ERP stick in the field and in the back office as well. Thanks so much again for joining us. You’ve been brilliant.

Adileh Mountain (40:15): My pleasure, Ryan. Thank you so much for having me. This was a really good conversation. I appreciate it.

Ryan (40:21): Excellent, and thank you all for listening. We’ll see you on the next episode.

Adileh Mountain (40:25): Thank you.