Vetting your implementation partner: how to tell in time whether your ERP project will deliver

Series "ERP Decision Confidence", article 3 of 3 · By Dr. Harald Dreher · Last updated on 4 August 2026

What happens once the ERP contract is signed?

With the signature, the selection phase ends and delivery begins. At that moment, the buyer gives up its strongest negotiating position. Before signing, several vendors competed for the contract. After signing, there is only one partner left, and switching would write off time and budget already invested. The balance of power shifts within a single day.

Why the delivery team is rarely the sales team

During the proposal phase, implementation partners deploy their most experienced people. These individuals win the pitch, resolve critical technical questions and build trust. Once the contract is signed, those same people are needed for the next sales process. A different team moves into the project, often with less experience and running in parallel across further projects.

This handover is standard practice in the industry and not dishonest in itself. It becomes problematic when it is not announced and when nobody on the customer side notices it. The commitments from the proposal phase remain in the contract. The people who were meant to deliver them are no longer in the room.

Why your own project organisation often fails to notice the handover

A mid-market company implements an ERP system once every ten to fifteen years. The internal project lead usually has no benchmark for comparison. They cannot judge whether a three-week slippage in the fourth project month is normal or alarming. The implementation partner has that benchmark but does not share it.

Why do ERP projects go off the rails after signing?

After the contract is signed, ERP projects rarely run into trouble for technical reasons. The more common cause is a structural incentive asymmetry: the implementation partner is paid for work delivered, not for the accuracy of its original forecast. An effort estimate that is too low does not harm the partner in the proposal phase; it helps.

Change requests as a second revenue model

A change request is a subsequent order for work that was not included in the original proposal. Many implementation partners price the initial proposal tightly in order to win the contract. The margin then comes from add-ons, billed at day rates with no competitive pressure. By that point, the customer can no longer switch.

Here too the mechanism is structural, not personal. A partner acting in good faith ends up in the same incentive position. Whoever does not measure add-ons will not control them.

Why the incentive asymmetry does not disappear after signing

Before signing, the vendor produces the documents on which the buyer bases its decision. After signing, the same vendor produces the status reports on which the buyer bases its steering. The source of information remains the same party, whose economic interest benefits from an optimistic presentation. An independent second view of the same facts closes this gap.

How we solved this challenge

Dreher Consulting supports ERP projects during the delivery phase as an independent authority alongside the customer and the implementation partner. Two project examples show what matters in practice and where we ourselves were initially wrong. Both examples are anonymised.

Both practice cases follow the same pattern

Practice case 1: A wholesaler noticed the team handover only after four months

A technical wholesaler found that its ERP project was noticeably behind plan in the fourth month. The cause was not the one all parties assumed. The sequence below shows what we found, what we did, and where we initially got it wrong.

1. Situation. Technical wholesale, around 350 employees, four sites in Germany and Austria. ERP implementation with a regional systems integrator. In the fourth project month the schedule was around three weeks behind, and the delivery budget was being consumed faster than the plan allowed for that stage.

2. Findings. The solution architect from the proposal phase had not appeared in the minutes since week six. His successor was technically qualified but was working in parallel on two further projects. The time bookings showed considerably fewer weekly hours than the capacity committed in the proposal.

3. Approach. Reconciliation of the named team staffing from the proposal against the actual time bookings for the first sixteen weeks. Analysis of all change requests by trigger. Introduction of a monthly steering meeting with seven fixed metrics. Renegotiation of the team staffing on the basis of the contractually committed capacity.

4. What changed. The customer got a set of facts it could steer on. Team staffing was renegotiated against the capacity the contract actually committed. Every add-on to date was attributed to a cause. From that point the project was measured monthly on seven fixed metrics, independently of the partner's own status report — so the next deviation was visible to the customer before it appeared in a status meeting.

5. Misjudgement. At first we took the delay to be purely a capacity problem on the implementation partner's side. Analysing the change requests by trigger showed a different picture. A substantial share of the add-ons arose because decisions about process variants had been left open on the customer side. The partner had not caused the delay on its own.

6. Consequence. Since then, in our project oversight we consistently separate change requests by trigger: vendor side, customer side, shared ambiguity. This separation changes the conversation with the partner. It takes the question of blame out of the discussion and makes it steerable.

Practice case 2: A medical technology manufacturer wanted to prove the benefits after go-live

A medical technology manufacturer had to demonstrate to its advisory board, six months after go-live, whether the business case had materialised. The task proved harder than expected, though for a different reason than assumed.

1. Situation. Manufacturer of medical technology, around 400 employees, predominantly export business. The ERP system had gone live six months earlier. The advisory board demanded reliable proof of the effects promised in the business case.

2. Findings. The business case named three benefit promises. For none of these three promises did documented baseline values from before go-live exist. The relevant metrics were recorded for the first time only after going live. A before-and-after comparison was not possible on this basis.

3. Approach. Reconstruction of the baseline values from the legacy system and from accounting data for the twelve months before go-live. Definition of five measurable metrics with clear calculation logic. Establishment of a benefits statement on a quarterly cadence. Separation of effects by cause.

4. What changed. The advisory board got a benefits statement that survived questioning. Baseline values were reconstructed from the legacy system and the accounts for the twelve months before go-live. Five metrics were defined with explicit calculation logic, measured quarterly, with the effects separated by cause. Two of the three original promises could be substantiated on that basis; the third could not, and was reported as unproven rather than quietly dropped.

5. Misjudgement. We took reconstructing the baseline values to be the hard part of the task. The harder part was attribution. Two of the three improvements could be traced in part to a parallel increase in office staff. Without this separation, the benefits statement would have come out too positive and would have fallen apart at the first critical question from the advisory board.

6. Consequence. Today we record baseline values before go-live, as a fixed part of project oversight. A benefits assessment that begins only after going live is not a measurement but an estimate.

How do we assess an implementation partner's ability to deliver?

At Dreher Consulting, assessing the ability to deliver follows a repeatable sequence of six steps. The sequence starts after the contract is signed and ends with the benefits statement after go-live. All six steps produce written results that remain with the customer.

Steps 3 to 6 belong to the project oversight and benefits assessment building blocks of the "ERP Decision Confidence" model.

Seven review questions: is your ERP project still on plan?

The following seven questions can be answered without external support. If you cannot clearly answer three or more of them, you lack the information base for reliable project steering. The questions target early indicators that typically become visible several months before an escalation.

1. Are the consultants named in the proposal actually working on the project, and at what weekly proportion of their time?
2. What share of the original contract volume do all change requests to date account for?
3. Are your milestones slipping, or does the date stay fixed while the associated scope shrinks?
4. How long do open technical questions remain in the status "under clarification" before a decision is made?
5. Does the implementation partner answer technical questions about the process, or does your own team answer them for the partner?
6. Are the test cases available in writing before testing begins, or do the test cases emerge during the test?
7. Do documented baseline values exist for every benefit promise in your business case, measured before go-live?

Question seven has the greatest consequences. Whoever does not record the baseline values before go-live cannot later prove the project's benefits, only claim them.

What can software and AI do in project control, and what can they not?

During the delivery phase, analysable project data is abundant: time bookings, ticket histories, change request records, test logs. Software identifies patterns in it faster and more completely than any human. Among other tools, Dreher Consulting uses its own model SCOReX® for this. The analysis provides indications, not decisions.

What cannot be automated is the judgement of whether a project lead is overloaded or out of their depth. What cannot be automated is the weighting of conflicting objectives, for instance between meeting deadlines and process quality. What cannot be automated is the responsibility for the recommendation to pause a project.

We do not automate the consultant's judgement. We improve the information base on which reliable management decisions are made.

Where this approach reaches its limits

Project oversight and benefits assessment do not work equally well in every constellation. We name four limitations before the project begins, because they constrain the achievable effect. Whoever knows these limits can decide realistically whether external oversight is worthwhile.

• Without contractual leverage, control has no consequences. If the contract contains no stage gates, no acceptance criteria and no exit options, a bad trajectory can be measured but hardly corrected. Project control does not replace contract design.

• Missing baseline values can only be partly reconstructed. The longer ago the go-live was, the less accurate the reconstruction from legacy data becomes.

• Missing internal capacity cannot be replaced externally. If your own department has no time to participate, external oversight shifts the problem rather than solving it.

• Below a certain project size, the effort is not proportionate. The practical threshold is not a budget figure but a staffing one: where the company cannot assign a dedicated internal project lead, external oversight has nobody to hand its findings to. In that situation we recommend accompanying project management rather than oversight.

How we are paid

Dreher Consulting is paid exclusively by the client, on the basis of agreed advisory work. We receive no commissions from ERP vendors, systems integrators or implementation partners. We generate no revenue from implementing the systems we assess.

This arrangement is the reason we can recommend that a customer pause a project. An advisory firm that also earns from the continuation ends up in a conflict of interest when making that recommendation.

Next steps

If your ERP project is in delivery, an independent second view is worthwhile before a delay turns into an escalation. You can find more information on our approach in our overview of our ERP advisory services.

The "ERP Decision Confidence" series:

Part 1 – Why ERP projects fail before the first line of code is written

Part 2 – On what basis do you sign an ERP contract spanning ten years?

We encounter the patterns described here particularly often in wholesale and in medical technology.

Sources: "Reasons for the failure of ERP projects", Springer Gabler, 2025 · "Why ERP projects fail", Computerwoche, 2025.

Dr. Harald Dreher

Managing Director, Dreher Consulting · Over 33 years of advisory experience in the DACH mid-market · Over 1,200 ERP and digitalisation projects · 100 % vendor-independent · Available in person for an initial conversation with company leadership.

Arrange a meeting with Dr. Dreher directly →