ERP projects fail. Not occasionally, not rarely, they fail at a rate that should give any organisation pause before signing a contract. Research from various industry analysts over the years has consistently placed ERP project failure rates somewhere between 50 and 75 percent, depending on how you define failure. Some of those projects go over budget. Some go over time. Some deliver a system that technically works but that nobody in the organisation actually uses properly. And some fail catastrophically — going live with a system that brings operations to a halt, triggering financial losses that make the original project cost look trivial by comparison.
The causes of ERP project failure are well documented. Poor requirements gathering. Inadequate change management. Scope creep. Underestimating the complexity of data migration. Choosing the wrong software. Insufficient testing. Going live too early. All of these are real and common problems. But running through almost every failed ERP project, if you trace the root causes carefully enough, is a more fundamental issue: the organisation chose the wrong consultancy to guide them through it.
This is the part of the ERP story that does not get told often enough. The software vendor gets scrutinised carefully. The licensing costs get negotiated hard. The technical specifications get reviewed in detail. But the consultancy — the firm that will actually run the project, configure the system, manage the change, and ultimately determine whether the whole thing succeeds or fails — often gets selected on the basis of a slick presentation, a familiar name, or simply because they were the cheapest bid. That is a mistake that organisations tend to make only once, because the consequences are severe enough to ensure they never make it again.
This article is about how to avoid that mistake. It is about what the right ERP consultancy actually looks like, what questions to ask, what red flags to watch for, and why the decision about who you partner with matters more than almost any other decision you will make in the entire project.
What an ERP Consultancy Actually Does
Before getting into how to choose a consultancy, it is worth being precise about what a good one actually does, because there is a significant gap between what organisations expect from an ERP consultancy and what they sometimes get.
At the most basic level, an ERP consultancy helps an organisation select, implement, and optimise an Enterprise Resource Planning system — software that integrates core business processes like finance, procurement, supply chain, manufacturing, HR, and customer management into a single platform. The major ERP platforms include SAP, Microsoft Dynamics 365, Oracle, NetSuite, Sage, Infor, and a range of more sector-specific solutions.
But the work of a consultancy goes well beyond software configuration. A genuinely capable ERP consultancy will do all of the following:
- Help the organisation understand its own processes before designing a system to support them
- Facilitate requirements workshops that capture what the business actually needs, not just what individual stakeholders think they want
- Advise on which ERP platform is the right fit for the organisation’s size, sector, and strategic direction
- Design the system architecture, including integrations with other software the organisation uses
- Configure the ERP to match the organisation’s processes, applying best practice where appropriate and customising where genuinely necessary
- Manage the data migration from legacy systems, which is almost always more complex than expected
- Design and deliver a training programme that prepares users at all levels to work effectively with the new system
- Lead the change management work that ensures the organisation’s people are ready for the transition
- Support the go-live and the post-implementation stabilisation period
- Provide ongoing optimisation as the organisation’s needs evolve
That is a substantial scope of work. It requires technical depth, business process knowledge, project management capability, communication skills, change management experience, and a genuine understanding of the sector and context in which the organisation operates. Finding a consultancy that does all of this well is not straightforward, and the consequences of choosing one that cannot are serious.
The Most Common Ways ERP Consultancies Let Organisations Down
Understanding how consultancies fail their clients is useful context for understanding what to look for when choosing one. The patterns of failure are remarkably consistent across industries and project sizes.
Selling the project and then deploying juniors to deliver it
This is one of the most common and most damaging patterns in the consultancy industry. The sales process involves the firm’s most experienced and impressive people — senior partners, solution architects, sector specialists who clearly know their subject. The contract is signed. Then the project team arrives and it is mostly junior consultants, fresh from training courses, working from a methodology template they do not yet fully understand. The senior people make occasional appearances on steering committee calls but are not meaningfully engaged with the day-to-day work. The organisation gets a very different service from the one it thought it was buying.
Configuring the software without understanding the business
Some ERP consultancies are essentially technical configuration houses. They know the software deeply but they approach the project as a software installation exercise rather than a business transformation. They configure the system to match what they find — the existing processes, the existing data structures, the existing workarounds — rather than helping the organisation think through what its processes should be. The result is an ERP system that replicates the inefficiencies of the previous way of working in expensive new software.
Underestimating data migration
Data migration is the part of an ERP project that consultancies most consistently get wrong, either through inexperience or through deliberate underestimation during the sales process to make the project look cheaper. Moving data from legacy systems into a new ERP requires cleaning, transforming, mapping, validating, and reconciling data that has often been accumulating for years in inconsistent formats with varying levels of quality. Organisations that are not warned about this find themselves facing a massive body of work in the final weeks before go-live, rushing decisions that should have been made months earlier.
Treating go-live as the finish line
An ERP system does not deliver value at go-live. It delivers value when the organisation’s people are using it effectively, when the processes are bedded in, when the reporting is trusted, and when the ongoing management of the system is sustainable without continuous external support. Consultancies that treat go-live as project completion and then move their team onto the next engagement leave organisations in a vulnerable state — technically live but operationally fragile, without the knowledge transfer that would allow internal teams to manage and develop the system independently.
Poor change management
Technology projects fail because of people, not because of technology. An ERP implementation requires people to change how they work, often significantly. Some of those changes will be welcomed; many will not. Resistance to ERP implementations is normal, predictable, and manageable — if it is managed. Consultancies that focus entirely on the technical delivery and treat change management as an optional extra, or as something the client should sort out themselves, are setting projects up to fail. A system that works technically but that users route around or use incorrectly is a failed implementation.
What to Look for in an ERP Consultancy: The Key Criteria
Given the ways consultancies can fail, here is what to look for when evaluating potential partners.
Sector experience that is genuine, not claimed
ERP requirements vary significantly by sector. A manufacturing business has very different needs from a professional services firm, a charity, a retailer, or a housing association. Sector experience means the consultancy understands the regulatory environment, the typical process flows, the reporting requirements, the integration landscape, and the cultural characteristics of organisations in that sector. When evaluating a consultancy’s sector experience, go beyond the logo reel on their website. Ask for specific case studies. Ask to speak with reference clients in your sector. Ask the consultants who will actually work on your project what sector experience they personally have.
A methodology that is structured but not rigid
Good ERP consultancies have a methodology — a defined approach to how they run projects — but they apply it with judgement rather than mechanically. They can explain their approach clearly, tell you what each stage involves and why, and adapt it appropriately for the specific characteristics of your organisation and project. Be cautious of consultancies whose methodology sounds like a sales document rather than a practical guide to how work gets done. And be equally cautious of consultancies who cannot articulate a methodology at all, because structured project management matters enormously on complex ERP implementations.
Honest conversations about risk and complexity
One of the clearest differentiators between good and poor consultancies is their willingness to tell you things you do not want to hear. The good ones will tell you early if your timeline is unrealistic, if your data quality is going to be a serious problem, if a particular customisation you want is going to create long-term technical debt, or if your internal team does not have the capacity to support the project alongside their day jobs. The poor ones will agree with whatever you say during the sales process and let the problems emerge during delivery. Ask prospective consultancies directly: what do you see as the biggest risks in a project like this? Their answer will tell you a great deal about their honesty and their competence.
A team you will actually work with
As mentioned above, the sales team and the delivery team can be very different in some consultancy firms. When you are evaluating a consultancy, ask to meet the project manager, the lead consultant, and the solution architect who will actually be assigned to your project. Understand their experience, their approach, and how they will interact with your team. The relationship between your internal project team and the consultancy team will be intense and often stressful. The personal qualities of the individuals involved — their communication style, their patience, their willingness to listen — matter enormously alongside their technical skills.
References that you actually check
Reference checking in ERP consultancy selection is often cursory. A list of client names is reviewed, a couple of references are called and give broadly positive feedback, and the box is ticked. This is not adequate for a decision of this significance. When checking references, go deeper. Ask reference clients specifically about:
- How the consultancy handled problems and setbacks during the project
- Whether the final cost and timeline matched the original estimate and if not, why
- How effective the data migration work was
- What the go-live experience was like
- How the relationship changed after go-live
- What they would do differently if they were selecting a consultancy again
- Whether they would use the same consultancy for future work
The answers to these questions will tell you far more than a standard reference call.
Knowledge transfer as a stated commitment
The goal of a good ERP consultancy should be to make itself progressively less necessary, not more. From the beginning of the project, there should be a clear plan for transferring knowledge to your internal team — about how the system works, how it is configured, how to manage it, and how to develop it further. This knowledge transfer should be built into the project methodology, not treated as a nice-to-have. Ask prospective consultancies specifically: what does your knowledge transfer programme look like, and at the end of this project, what will our internal team be able to do that they cannot do now?
Questions You Should Ask Every ERP Consultancy You Evaluate
Here is a practical list of questions to use in your evaluation process. The questions themselves are important, but pay as much attention to how the consultancy responds as to what they say. Vague, sales-oriented answers to direct questions are a warning sign.
- Who specifically will be working on our project, and what is their experience with implementations of this type and scale?
- Can you walk us through your methodology for this type of project, stage by stage?
- What are the most common reasons ERP projects like ours run into problems, and how does your approach address those risks?
- How do you handle scope changes during a project, and what is your process for managing scope creep?
- What does your data migration process look like, and how do you assess and address data quality issues?
- How do you approach change management, and what involvement do you expect from our internal team?
- What happens at go-live, and what support do you provide during the stabilisation period?
- What does your knowledge transfer programme look like?
- Can you provide three references from clients in our sector who have completed projects similar to ours in the last two years?
- What is your process if the project runs significantly over budget or over time?
- Have you ever recommended to a client that they should not proceed with an ERP project, or should choose a different platform? If so, can you tell us about that?
That last question is particularly revealing. A consultancy that is genuinely acting in its clients’ interests will sometimes recommend that a client pause, reconsider, or choose a different path. A consultancy that always recommends proceeding with the solution it sells is prioritising its own revenue over your outcomes.
Red Flags to Watch for During the Selection Process
Beyond the positive criteria, there are specific warning signs that should give you serious pause about a consultancy, regardless of how impressive the rest of their proposition appears.
They give you a fixed price before they understand your requirements
ERP projects cannot be accurately priced without a thorough understanding of the organisation’s processes, data, integrations, and organisational complexity. A consultancy that provides a detailed fixed price quotation based on a brief initial conversation is either guessing or has made very optimistic assumptions that will not survive contact with reality. Expect a credible consultancy to want to conduct a discovery or scoping exercise before committing to a price, and be cautious of those that do not.
They downplay the importance of data migration
If a consultancy tells you that data migration is straightforward, or gives you a very low estimate for the data migration workstream without having assessed your data, treat that as a significant red flag. Data migration is almost never straightforward. It requires time, resource, and careful management. A consultancy that minimises it during the sales process is either inexperienced or is deliberately lowballing the estimate to win the deal.
They promise you the world on timeline
ERP implementations take time. The factors that determine how long include the complexity of your processes, the quality of your data, the number of integrations required, the size and capacity of your internal team, and the complexity of the change management challenge. Consultancies that promise aggressive timelines without robust justification are setting you up for a go-live that happens before the system is ready. A rushed go-live on an ERP is one of the most damaging things that can happen to an organisation.
Their proposal is full of jargon but light on specifics
A well-written consultancy proposal should be clear, specific, and directly relevant to your organisation. It should demonstrate that the consultancy has listened to and understood your situation, and should describe in concrete terms what they will do, how they will do it, and what the outputs of each stage will be. Proposals that are full of generic consulting language, framework diagrams, and impressive-sounding methodology names but that do not clearly explain what will actually happen on your project are a warning sign.
They are reluctant to provide direct client references
Some consultancies manage the reference process very carefully, steering you towards clients who have been briefed and prepared. Insist on being able to choose from a broader list, and if a consultancy is reluctant to provide references or wants to control the process too tightly, ask yourself why.
The chemistry is wrong
This is the softest criterion but it is a real one. ERP projects are long, intense, and often stressful. You will spend a lot of time with the consultancy team. You will have difficult conversations with them. You will need to trust them when things are not going well. If the chemistry between your team and the consultancy team is not right from the beginning — if there are communication style mismatches, if they talk over you, if they seem more interested in demonstrating their knowledge than listening to yours — that is not going to improve under project pressure.
The Role of Your Internal Team in a Successful ERP Project
Choosing the right consultancy is essential, but it is not sufficient. The consultancy cannot make your ERP project succeed on its own. The internal resource and commitment you bring to the project is equally important, and a good consultancy will tell you this clearly and early.
Here is what a successful ERP project requires from the client side:
An empowered project sponsor
Every successful ERP project has a senior leader who is genuinely committed to it, who has the authority to make decisions, and who actively removes obstacles. The project sponsor is not just a name on a governance document — they attend key meetings, resolve conflicts between departments, make the difficult prioritisation calls when scope needs to be managed, and signal to the rest of the organisation that this project matters. Without a strong sponsor, even the best consultancy will struggle.
Dedicated internal project resource
ERP projects require significant input from people within the organisation who understand its processes deeply. These people — typically called business analysts, process owners, or subject matter experts — cannot do this work as a side activity alongside their normal jobs. They need dedicated time, and in many cases dedicated secondment to the project. Organisations that try to run ERP projects without giving their internal team the time to engage properly will pay for it in requirements that are poorly understood, configurations that do not fit the business, and a go-live that surprises and disrupts the people it was meant to help.
A realistic attitude to change
ERP implementations require organisations to change how they work. Sometimes the changes are relatively minor. More often they are significant. Some long-standing processes will be replaced by the way the ERP does things. Some manual steps will be automated. Some roles will change in scope. An organisation that enters an ERP project with the attitude that everything should work exactly as it always has, and that the system should be configured to match every existing process without question, will either end up with a system that replicates its inefficiencies or will rack up expensive customisation costs fighting the software.
Strong data ownership
Data migration requires decisions. Decisions about what data to migrate and what to leave behind. Decisions about how to handle inconsistencies and gaps in legacy data. Decisions about data standards and naming conventions in the new system. These decisions require people within the organisation who understand the data, know what it means, and have the authority to make calls about it. If nobody owns the data internally, data migration will become a crisis.
Commitment to training and adoption
The best-configured ERP system in the world will underperform if the people using it are not properly trained and supported in changing their habits. Training is not something that happens once at go-live. It is an ongoing process, and it requires the organisation’s leadership to set clear expectations about how the system will be used and to hold people accountable for using it correctly.
How to Structure the Selection Process
Given the stakes involved, the ERP consultancy selection process deserves rigour. Here is a practical framework for running it well.
Stage 1: Define your requirements before you go to market
Before you approach any consultancy, spend time internally defining what you need. This does not mean specifying every functional requirement in detail — that is part of what the consultancy will help you do. But it does mean being clear about your organisation’s strategic goals, the key challenges the ERP is meant to address, your approximate scale and complexity, your timeline drivers, your budget parameters, and your internal capacity to support the project. Going to market with this clarity will help you have more meaningful conversations and will make it easier to assess whether prospective consultancies have genuinely understood your situation.
Stage 2: Build a longlist based on sector experience and platform expertise
Start with a longlist of four to six consultancies that have demonstrable experience in your sector and with the ERP platform or platforms you are considering. Sources for this longlist include:
- Recommendations from your professional network
- ERP vendor partner directories
- Industry association resources
- Analyst reports
- LinkedIn research
Stage 3: Issue an RFI or initial briefing document
Send each longlist consultancy a brief document describing your organisation and the project you are planning, and ask them to respond with an overview of their relevant experience, team, and approach. This initial response will quickly differentiate those who engage thoughtfully with your specific situation from those who send back a generic brochure.
Stage 4: Shortlist to three and issue an RFP
Select three consultancies to proceed to a formal Request for Proposal. The RFP should ask for their proposed approach and methodology, their team composition with CVs, their relevant case studies, a high-level project plan, and an indicative cost range. It should also include the specific questions listed earlier in this article.
Stage 5: Conduct detailed presentations and workshops
Invite each shortlisted consultancy to present their proposal and to run a working session — not just a presentation — with your team. A working session, even a brief one, will reveal how the consultancy actually engages. Do they listen? Do they ask good questions? Do they challenge your thinking constructively? Do the consultants who would work on the project participate actively, or is it all done by the sales team?
Stage 6: Check references thoroughly
As described earlier, reference checking should go beyond a perfunctory call. Speak to multiple references from each shortlisted firm. Ask the specific probing questions about how problems were handled, whether estimates were accurate, and what the post-go-live experience was like.
Stage 7: Make the decision on value, not price
ERP consultancy selection decisions that are made primarily on price almost always cost more in the long run than decisions made on value. The difference in fee between the cheapest and the most appropriate consultancy on your shortlist will be dwarfed by the cost of a project that fails, runs significantly over time, or delivers a system that the organisation does not use effectively. Price matters, but it should be the last criterion you consider, not the first.
Ongoing Partnership After Go-Live
The relationship with your ERP consultancy does not end at go-live, and organisations that treat it as if it does miss a significant opportunity. An ERP system should evolve as the organisation evolves. New processes, new reporting requirements, new integrations, new modules, regulatory changes, platform updates — there is always work to be done, and having a consultancy that knows your system and your organisation deeply is valuable.
The nature of the relationship does change after go-live. The intensive project engagement transitions to a more advisory and supportive model. Some organisations manage this through a formal managed service or application management arrangement with their consultancy. Others build sufficient internal capability during the project to manage day-to-day system administration themselves, calling on the consultancy for more strategic work. The right model depends on your organisation’s size, internal technical capability, and the complexity of your ERP landscape.
What matters is that the relationship is planned and structured, not left to drift. Organisations that lose touch with their ERP consultancy after go-live often find themselves struggling with a system that is slowly falling out of alignment with their needs, without the knowledge or relationships to address it effectively.
The Cost of Getting This Wrong
It is worth being concrete about what is at stake if you choose the wrong ERP consultancy. The consequences are not abstract. They include:
- Project overruns of 50 to 200 percent against original budget estimates
- Timeline extensions of six months to two years beyond the original go-live date
- Operational disruption at go-live that affects customers, suppliers, and staff
- Data quality problems that undermine trust in the new system for years
- Low user adoption that means the organisation is paying for an expensive system it does not really use
- Technical debt from poorly designed customisations that make future upgrades difficult and expensive
- Loss of key staff who are burned out or demoralised by a failed or troubled implementation
- Reputational damage with customers and suppliers caused by operational failures during go-live
- In extreme cases, financial losses significant enough to threaten the viability of the organisation
These are not theoretical risks. They are documented outcomes from real ERP projects. Haulage companies have had to manage deliveries on paper because their new system was not working. Manufacturers have stopped production lines because the new system could not process orders. Retailers have lost stock visibility during peak trading periods. Public sector organisations have faced regulatory scrutiny over data handling failures during ERP transitions. The common thread in most of these cases is a consultancy that was not capable of managing the complexity of the project it had taken on.
Making the Right Choice: A Summary
Choosing an ERP consultancy is one of the most consequential decisions your organisation will make. The software you choose matters. The internal commitment you bring matters. The timing and phasing of the project matters. But the consultancy you partner with runs through all of it, and getting that choice wrong undermines everything else.
The right consultancy will challenge your thinking constructively, tell you things you do not want to hear when necessary, bring a team that is experienced and engaged, manage the complexity of your data migration with rigour, lead your organisation through genuine change, and stay with you through the difficult post-go-live period until you are genuinely stable and able to grow.
The wrong consultancy will dazzle you in the sales process and disappoint you in the delivery, underestimate the hard parts, overestimate their team’s experience, treat go-live as the finish line, and leave you with a system that works technically but that your organisation cannot operate effectively.
The difference between those two outcomes is not mainly about the software. It is about the people guiding the project, the quality of their work, and the integrity with which they engage with you throughout. Do not rush the selection process. Do not let price dominate the decision. Ask the hard questions and pay close attention to the answers. Check the references with real rigour. Meet the team that will actually do the work.
An ERP project done well is transformative. It creates clarity, efficiency, and capability that compounds over years. An ERP project done badly is expensive, demoralising, and sometimes existentially damaging. The decision about which of those you experience starts with who you choose to partner with.
