In many procurements, the majority of time is spent on product selection. But when ERP or CRM projects fail to deliver as expected, it is usually less about the product and more about the implementation. And the implementation is largely determined by the partner.
Which ERP system fits best? How does Dynamics 365 stack up against alternatives? Which modules are needed? Which features are critical, and which are really just nice-to-have?
Demos are booked. Comparison matrices are completed. Reference visits are carried out. It is not the wrong work. But that is rarely where the biggest risk lies.
Two organisations can choose the exact same platform and still end up with completely different outcomes. The difference lies in the implementation: who asks the right questions early on, who dares to push back when scope creeps for the wrong reasons, and who has actually delivered this type of project in this type of business before.
Partner comparisons are made, of course. But often too late. And often too shallowly. Once the product is selected, two or three partners are usually compared, primarily on price, sales presentations, and the feeling in the room. It is a comparison, but not always an evaluation that makes partners genuinely comparable.
And that is where the risk begins.
1. Costs spiral out of control
In larger ERP and CRM projects, budget and timeline overruns are rarely marginal once scope, integrations, data migration, and customisations start to grow.
The drivers are well known:
- requirements that were not sufficiently clear when signing the contract
- a bid based on an underestimated scope
- weak change management on the buyer's side
- a partner organisation that does not staff the project as understood during the sales phase
- too many customisations creeping in before standard processes have even been tested
Here, price comparisons in procurement can easily be misleading. A low bid may look attractive in the decision proposal, but turn out to be expensive when the project is underway. A higher bid might actually be cheaper in practice if it is built on a better understanding of scope, risks, and necessary staffing.
Engagement in the sales phase also does not always say much about delivery capability. What matters is not just what the partner promises. It is how the partner works when reality begins to disrupt the plan.
There are ways to protect yourself even before the project starts. Clearly defined scope. Phased deliveries with decision gates. A change management process where both parties have incentives to stick to the framework. And a partner who dares to say no to requests that do not belong in the initial release.
The contract sets the boundary. But it is the partner's working method that determines whether the boundary holds.
2. The system is implemented – but not used as intended
The most expensive system is not always the one with the highest licence cost. It is the system that is purchased, implemented, and then not used as it was intended.
It is not always visible right away. The sales team continues keeping their own notes alongside CRM. Finance is still running reports manually. Customer service builds its own exceptions outside the process. Operational data becomes fragmented. Management does not get the overview that the investment was supposed to create.
Adoption is rarely a technical issue in the first instance. It is a consequence of how the project was driven from the start.
Has the partner understood how the business actually works? Have processes been challenged, or merely redrawn? Have end users been involved early enough? Has training been tied to real workflows, or just to features in the system?
A partner treating adoption as an activity at the end of the project has already lost too much ground. Adoption is not built at go-live. It is built in every decision made long before that.
3. The decision becomes difficult to defend
This is the dimension that is rarely visible in a business case template. But it is always in the room.
The CFO who approved the investment. The CIO who recommended the architecture. The CEO who pushed the decision through. The project owner who stood behind the partner recommendation.
When an ERP or CRM project fails to deliver, it has to be explained. To executive management. To the board. Sometimes even to shareholders. Then the question is not just about what went wrong. It is also about how the decision was made.
Was there a structured evaluation? Were there relevant references? Was there a clear link between the partner's experience and the organisation's needs? Was there neutral supporting data, or was the choice mainly based on price, relationships, and pitch decks?
A thoroughly researched decision that still goes sideways can be explained. A choice that in practice relied on the lowest price and the best sales pitch is significantly harder to defend.
That is why partner selection is not merely a procurement issue. It is a leadership issue.
How risk is reduced
The point is not to choose the "right" partner on gut feel – but to make partner selection comparable early on. Risk in an ERP or CRM selection cannot be eliminated. But it can be managed. Three things make the biggest difference.
Buyer-side guidance early in the process
The partner landscape is difficult to navigate for anyone who only makes this kind of selection once every ten or fifteen years.
Which partners are strong in Business Central? Which truly know Finance & Supply Chain? Who has experience in manufacturing, distribution, retail, professional services, or the public sector? Who is strong in CRM, Customer Service, Field Service, or Contact Center?
When the mapping is carried out by someone who does not want to win the implementation themselves, the picture often becomes clearer. Not perfect. But less biased.
The right questions in the sales process
It is not enough to ask for price, timeline, and references. You need to understand how the partner actually works.
What does their methodology look like? Which individuals are assigned to the project? What experience do they have with similar organisations? That says something about delivery capability.
How are scope changes handled? What is excluded from the proposal? When does the partner advise the customer against customisation? That says something about how the partner operates when reality meets the plan.
It is often in the answers to those questions that the difference between partners becomes visible. Not in the standard pitch.
Structured evaluation
A good evaluation is not about scoring matrices for the sake of scoring matrices. It is about forcing comparability. Between partners. Between ways of working. Between experience. Between actual delivery capability and sales promises.
Without structure, decisions easily drift towards what feels easiest to justify in the moment: lowest price, strongest relationship, or most convincing pitch. But ERP and CRM projects are not won in the presentation. They are won in the execution.
Product selection is important. But partner selection determines what comes of it.
Dynamics 365, Business Central, Finance & Supply Chain, Sales, Customer Service, and other modern business platforms can create great value. But the platform does not realise value on its own.
That is achieved through the right scoping, the right methodology, the right staffing, the right change management, and the right understanding of the business.
Therefore, partner selection should not be treated as the next step after system selection. It should be a central part of the decision from the start.
On d365 Guide, we offer buyer-side support to structure the selection of a Dynamics 365 partner – based on solution area, industry, experience, and actual delivery setup.
The goal is for the decision not only to feel right during procurement, but also to be possible to explain and defend when the project meets reality.