Is the End of Man-Day Consulting Near?

Every executive requesting an ERP proposal faces the same question: "How many man-days is this project?" Yet failure rates that have not moved in decades suggest the real problem lies not in the duration, but in the question itself. This article examines why man-day pricing is economically breaking down, and which questions belong on the proposal table instead.

ERP Failure Rates That Refuse to Change

Gartner's research projects that by 2027 more than 70% of newly implemented ERP initiatives will fail to fully meet their original business goals, and up to 25% will fail severely. McKinsey's transformation research paints the same picture: roughly 70% of large-scale transformation efforts miss their targets; in "Unlocking success in digital transformations" only 16% of organizations said they made performance gains stick.

What stands out: these rates have barely moved across technology generations. Software moved to the cloud, interfaces modernized, AI arrived — the failure rate stayed put. If the problem were the technology, it would have improved with the technology. It doesn't — so the problem is the model.

The Structural Contradiction of Man-Day Pricing

The contradiction fits in one sentence: the vendor's revenue grows as the project gets longer; the customer's interest is in it getting shorter. The two sides of the same contract are structurally pushed in opposite directions.

Three mechanisms amplify it:

• The economics of scope ambiguity: every requirement left vague at the start returns months later as a "change request" billed in extra man-days. Ambiguity is not a cost for the vendor — it is a revenue line.
• Information asymmetry: the customer has no instrument to check whether "this takes 40 man-days" is realistic. There is no benchmark; negotiation rests on trust, not data.
• Input–output disconnect: a man-day is an input measure. The invoice counts hours, but inventory accuracy, delivery times, error rates — the outcomes the customer actually wants to buy — are usually absent from the contract.

Field observation (anonymized): a manufacturer's ERP project that started with a 120-man-day proposal had passed 200 man-days by month 14. The overrun wasn't laziness — nobody had measured the existing processes at the start. Every duration promised without a diagnosis is a guess; and the bill for the guess always goes to the customer. We wouldn't trust a surgeon who commits to an operation time without an X-ray; in ERP, that commitment is made every day.

The Economic Break in ERP Consulting: What Bain and McKinsey Signal

The break started at the top of the consulting market. According to industry reports, AI is forcing McKinsey, BCG and Bain to rethink their fee models; McKinsey disclosed that roughly a quarter of its fees are now outcome-based. The model is simple: agree on a measurable target — revenue growth, cost reduction, an operational metric — and tie the fee to hitting it.

The logic transfers to ERP one-to-one: AI is making the repetitive share of consulting work (documentation, configuration plans, test scenarios) cheaper. As the repetitive work gets cheaper, every hour priced by the man-day comes under scrutiny. What remains is the consultant's real value: the right diagnosis, the right prioritization, and ownership of the outcome. Our assessment (a labeled prediction): the pricing shift that began in top-tier consulting will reach the SME ERP market within a few years — and proposals arriving with a man-day table will be defenseless against proposals arriving with an outcome commitment.

5 Questions to Ask When Evaluating an ERP Proposal

At the proposal table, these five questions expose the weak points of the man-day model. If the answers don't satisfy, the risk is high — whatever the price.

1. What measurement is this proposal based on?

A man-day figure quoted without measuring current processes, data quality and organizational maturity is a guess. "We know from similar projects" is not a measurement — ask for a written, company-specific current-state assessment.

2. How does the price change when scope changes?

Are the unit cost of a change request, the approval mechanism and the cap written into the contract? If the bill for scope ambiguity isn't defined up front, your bargaining power shrinks as the project drags on.

3. How is success defined, and who measures it?

"Go-live" is not a definition of success; systems launch and nobody uses them. Agree up front on business metrics — inventory accuracy, closing time, delivery performance — measurable independently of the vendor.

4. Which part of the work is standard, and which is real expertise?

Documentation, standard configuration and test-scenario generation can largely be automated today. If these items are still billed at the full man-day rate, the automation savings stay with the vendor — not with you.

5. How much of the payment is tied to the outcome?

Is the vendor willing to tie part of its fee to the outcome it promises? A proposal that leaves all the risk with the customer is saying it doesn't trust its own estimate. Even a small outcome-linked share aligns incentives.

Conclusion: The Shift to Value-Based Models

The man-day model was the product of an era when measurement was expensive and slow. As measurement gets cheaper — as processes digitize and diagnosis automates — models that price the outcome instead of the input become inevitable. The strongest tool in an executive's hand is to sit down at the proposal table demanding measurement: first the X-ray, then the diagnosis, and only then the treatment.

This is the first article in a 4-part series. Next: an X-ray of AI promises · the mechanism by which AI changes ERP projects · what the new way looks like in practice.

As a starting point, you can see your project's risk profile with the 2-minute ERP Risk Score assessment. To not miss the rest of the series, follow our LinkedIn newsletter.