Why ERP Projects Fail: 6 Staffing Root Causes

Last updated: August 20, 2026

By Tom Kenaley, Senior Partner and President, KORE1

ERP projects fail because the seats that matter go unfilled, not because the software is wrong. Six staffing gaps cause most of it, and every one of them is visible before kickoff if you know where to look.

Somebody usually invites me to the post-mortem. The slide deck always blames change management. Sometimes data migration gets a bullet. Occasionally somebody says the vendor overpromised, which is often true and never the whole story, because a vendor who oversells still has to be managed by someone on your side whose job was to notice they were overselling.

Nobody ever puts up a slide that says we never filled the seat.

That’s the pattern I keep running into after fifteen years of placing ERP people. We run an ERP consultant staffing practice, so I make money when the answer is “hire someone.” Take the obvious discount on my opinion. I’m going to argue it anyway, because the failures I get called into are rarely technical, and the ones that are technical usually trace back to a seat nobody filled six months earlier.

The Failure Numbers Are Real. The Reasons Given for Them Usually Aren’t.

Gartner has more than 70% of recently implemented ERP initiatives missing their original business goals by 2027, with as many as a quarter of them failing outright. That’s Gartner, not me. The number gets repeated everywhere, usually flattened into “70% of ERP projects fail,” which is a different and scarier claim than the one Gartner made. Falling short of a goal and collapsing are not the same event. Both hurt. They hurt differently.

The two biggest independent studies of large IT project failure are more useful, partly because they count things.

Here is the part almost nobody quotes. When McKinsey and Oxford looked at what separated the projects that landed from the ones that didn’t, they named four dimensions. Two of them are staffing. Securing technical talent. Building effective teams. Not tooling, not methodology, not the size of the change management budget.

The Flyvbjerg and Budzier analysis is bleaker and more specific. Their one-in-six “black swan” projects don’t drift. They detonate, at 200% over cost, and the authors point out that these have ended executive careers and in a couple of documented cases taken whole companies down with them, which is worth sitting with if you are the person whose signature is on the statement of work. A 200% overrun is not a change management problem. Something structural was wrong from week one.

So what’s structural? In my experience, six things, and all six are people you did or didn’t put in a chair.

Root Cause 1: A Sponsor Is Not an Owner

Every failed ERP project I’ve been called into had an executive sponsor. Usually a CFO. Sometimes a COO. Genuinely engaged, genuinely wanted it to work, genuinely had eleven other things on their plate.

A sponsor removes obstacles and signs things. An owner makes the fifty small decisions a week that nobody else can make, and lives with them. Different jobs. The second one is full-time work for the duration, and it does not compress into the gaps between someone’s existing responsibilities no matter how capable that person is at their existing responsibilities.

What happens when it’s empty is predictable and slow. Decisions queue. Then they stack. The partner asks a question on a Tuesday, the answer requires two departments to agree, nobody has authority to force the agreement, and three weeks later it’s still open. Multiply that by forty open questions. That’s your schedule, gone, without a single technical problem occurring.

The tell is simple. Ask who on your side gets fired if this goes badly. If the answer is “well, all of us really,” the seat is empty. Companies that get this right either promote someone internal into a genuine ERP implementation project manager role and backfill their day job, or they rent one. Both work. Splitting the role across a committee does not.

Root Cause 2: SME Time Got Assumed Instead of Scheduled

This one irritates me. Your controller, your warehouse manager, your order-to-cash lead. The people who know how the business genuinely runs. Their participation is the single largest client-side input to the project, and in most SOWs it appears as a sentence: “Client will provide business subject matter experts for workshops and UAT.”

Not a plan. That’s a hope with a signature under it.

I pulled the numbers from a serialization integration proposal for a mid-market pharma manufacturer, a document written by a consultancy that clearly had been burned before. Their client-side dependencies were contractual and timed. Ten business days for document review turnaround. Five business days for pre-execution approval on test protocols. Written down. Dated. Binding. And this line, which I’ve since started quoting to clients: the phase duration includes an allowance for review cycles, but not for review latency beyond those windows.

Then they did something I’d never seen written down. They separated the two ways a client delay costs money. Waiting earns you schedule relief. Rework earns cost. If your SME is unavailable for three weeks, the timeline moves and the invoice doesn’t. If your SME is available, approves a design, then changes their mind in UAT, you’re paying for the rebuild.

Almost every client-side blowup I’ve seen is rework wearing waiting’s clothes. The SME wasn’t absent. They were half-present, approved things they hadn’t really read because they had a quarter close running, and caught the problem in UAT at the point where fixing it cost roughly eight times what it would have cost in design.

Twenty percent of an SME’s time is the number people commit to. During design and UAT the real draw is closer to half, in bursts, and it lands exactly when your finance team is busiest. Plan for the burst or backfill the day job. There’s no third option that works.

Root Cause 3: The Schedule Runs Through One Person’s Calendar

Nine months. One irreplaceable person. No named alternate.

You’d be amazed how often that’s the actual plan, on both sides of the engagement. The partner has one senior architect who knows your industry. You have one person who understands the legacy chart of accounts. Neither has a backup, and the risk register says “resource availability” with a yellow dot next to it.

The same proposal I mentioned handled this the way I wish more did. Roles are named in the plan before work starts, with a named alternate for each one. Work product lives under version control as a firm deliverable rather than in an individual’s head, so a replacement inherits a working document set instead of starting over. And there was a sentence I keep coming back to: we will not hold a schedule commitment that depends on one person being available every week for nine months without saying so.

Worth reading twice. It’s a vendor voluntarily surfacing their own single point of failure during a competitive bid. That’s what a serious staffing plan sounds like.

The mid-project version of this is uglier. Somebody resigns in month five. It happens constantly. On a NetSuite or Dynamics 365 build, our average time-to-hire for IT roles runs 17 days, and that’s fast for the market, but 17 days is only the search. Add ramp on your configuration, your data, and your customizations, and a mid-build replacement costs six to eight weeks of real velocity. That’s if the replacement sticks, which is its own problem, and why we track 12-month retention at 92% rather than time-to-fill alone.

Root Cause 4: The Builders Are Also the Testers

Ask who executes the tests. Not who writes the test plan. Who sits down and runs them.

On a distressing number of mid-market ERP projects, the answer is the same consultant who built the thing. They configured the revenue recognition rules, then they wrote the test that proves the revenue recognition rules work, then they ran it, and it passed. Of course it passed. They built the test around what they built.

Independence isn’t a process. It’s a staffing decision, and it costs money on the org chart, which is precisely why it disappears from budgets. In the regulated world people are explicit about it. On that pharma integration, the validation lead was engaged specifically as someone who took no part in the build, and validation execution was a separate role again, staffed with people who had not built the functions under test. That separation had a price attached. The blended rate across delivery roles was $215 an hour. The independent validation lead billed $275, the only rate differential in the entire proposal.

They paid a 28% premium for one thing: the person checking the work had no stake in the work being right.

Validation on that engagement ran about 30% of base build hours. Not 10%. Not “we’ll do UAT in the last two weeks.” Thirty percent, staffed with different people. Most mid-market ERP buyers I talk to are budgeting somewhere between 8% and 15%, and the gap between those numbers is where go-live weekends go bad.

You don’t need pharmaceutical-grade validation to borrow the principle. You need one person whose name is on testing and who did not configure the module. One name. That’s the bar.

There’s a labor-market wrinkle here worth naming. The Bureau of Labor Statistics doesn’t even track quality assurance analysts and testers as their own occupation. It bundles them in with software developers, projecting 15% growth and about 129,200 openings a year through 2034 for the combined group, which tells you something about how the profession itself gets categorized long before anyone sits down to write a project plan. When the federal statistical agency treats testing as a subcategory of building, you can see how a budget ends up doing the same thing.

Root Cause 5: Nobody Sits Between the Process and the Configuration

This is the seat almost nobody knows to staff, and it’s the one I’d fill first if I could only fill one.

Your ERP consultant knows the system. Your controller knows the business. Neither of them speaks the other’s language well enough to catch the expensive mistakes, and the expensive mistakes live exactly in that gap. Functional consultants are supposed to cover this. Some genuinely do. Many are configuration specialists with a business-sounding title, and you don’t find out which kind you hired until month four. We wrote up the distinction separately in functional versus technical consultants, because the titles are close to meaningless across firms.

On that same pharma project, the initial design tracked serialization at the individual unit level. Reasonable-sounding. Clean data model. It would have generated roughly 1,350,000 API calls a year against a licensed allowance of 130,000.

Over by a factor of ten. Not a rounding error.

Batching at the transaction level instead, around 141 documents a month at four to six calls each, used less than a quarter of the allowance. Same business outcome. Same compliance posture. One design decision, caught during discovery because somebody was doing arithmetic against real volumes instead of accepting a design that looked correct.

Nobody in that story is a bad engineer. The technical people would have built exactly what was specified. The business people had no way to know that a data model choice mapped to a licensing cliff. The catch required a person whose actual job was translating between the two, and that engagement had discovery scoped as its own funded phase, 182 hours and $44,110, before anyone touched a keyboard.

Second example from the same document, and this one is the sort of detail nobody warns you about. A NetSuite RESTlet will not accept a plain API key. External systems calling in need OAuth 1.0 token-based authentication or signed OAuth 2.0 requests. So if your vendor’s integration only supports API-key callbacks, which plenty do, you need an authenticated relay in front of it. Small technical fact. It’s also a scope item, a schedule item, and a budget item that shows up as a nasty surprise in week nine if nobody with a foot in both camps asked the question in week two.

Root Cause 6: You Staffed a Go-Live Instead of a System

Go-live is not the end of the project. It’s the beginning of the part that determines whether the project was worth doing, and it is routinely staffed by people who are already rolling off.

The pattern: contractors ramp down the week after cutover, the internal team goes back to their day jobs exhausted, and the system enters year one with nobody’s name on it. Six months later somebody notices reports are wrong, workflows have been quietly disabled, and three people are maintaining spreadsheets alongside the new ERP because a process never got finished.

That failure gets attributed to user adoption. It isn’t. It’s a staffing gap with a nicer name.

Real numbers again, because they’re clarifying. On the pharma engagement, keeping the system in a validated state across the platform’s twice-yearly releases was scoped at 120 hours and about $31,000 a year. Ongoing. Forever. A line item that never closes. Your non-regulated build won’t carry validation overhead, but the underlying fact holds: your ERP has a permanent annual labor requirement, and if it isn’t on somebody’s job description it comes out of everyone’s evenings.

Two things separate the companies that handle this well. They name the day-two administrator before UAT, not after go-live, so that person learns the system by testing it rather than by inheriting it. Naming them early also forces the prior question of whether the seat is an administrator seat at all, which is what these seven signs you need an ERP consultant are built to settle. And they treat knowledge transfer as a deliverable with a due date instead of a courtesy at the end. The best version of that I’ve seen was an administrator runbook written to a deliberately awkward standard, which was that somebody who had never met the implementation team should be able to pick it up and maintain the system without calling anyone. That’s a testable bar. “We’ll do a handoff session” is not.

For the cutover window itself, most mid-market teams underestimate by half. We staff ERP go-live and hypercare support as a distinct engagement for exactly this reason, usually on contract, because the need is real, intense, and genuinely temporary.

The Six Seats, Side by Side

None of these are exotic hires. Four of the six can be filled internally if you’re willing to backfill day jobs, which is usually cheaper than it sounds and always cheaper than the alternative. If you want a sanity check on which seats you’re missing before you commit, our ERP readiness assessment walks the same six.

Where This Usually Gets Argued

Isn’t this just what a staffing firm would say the problem is?

Fair hit, and I’d think the same thing reading it. What keeps me arguing it: the two largest independent studies of IT project failure both land on team and talent as primary dimensions, and neither McKinsey nor Oxford has recruiters to sell. I found the framing after the fact. The projects I get called into are the ones already on fire, and the fire is almost never in the software.

We already signed an implementation partner. Why staff anything ourselves?

Wrong split, slightly. A partner owns the build, but nobody outside your company can own the decisions, the data, or the year after go-live. Partners are also explicit about this in their own paperwork. Read the assumptions section of any serious SOW and you’ll find your obligations listed with turnaround times attached. We covered the full comparison in implementation partner versus staffing agency.

Which seat breaks first?

Seat two, almost every time. SME availability is the first commitment to slip because it’s the only one that was never written down anywhere with a date on it. It also fails quietly. Nobody reports a missed review; the design just sits, and by the time it surfaces on a status call you’ve lost a month.

Our SMEs are committed at 20% of their time. Is that enough?

No. Not for design and UAT weeks. Twenty percent is roughly half of what a mid-market build genuinely draws from a core SME during those phases, and it arrives in bursts that collide with month-end and quarter close. The fix isn’t a bigger percentage on a slide. Backfill the day job for the two or three people whose input the design actually depends on, and leave everyone else at 20%.

When should we hire the day-two administrator?

Short answer: before UAT. Someone hired after go-live learns the system by inheriting problems, which takes about three times longer and teaches them the workarounds instead of the design. Bring them in early enough to run tests against the build and they arrive on day one already knowing why things are configured the way they are.

The project is six months in and sliding. What’s the first move?

Audit the seats before you replan the schedule. Rebaselining a timeline that’s failing for staffing reasons produces a second timeline that fails the same way roughly two quarters later, at which point you have burned a year and still have not named the person who was supposed to be making the decisions. Walk the six above, mark each one filled or empty by name rather than by title, and you’ll usually find two or three empties that explain most of the slippage. Fix those, then replan.

The Org Chart Is the Risk Register

I’m not claiming software never fails. It does. Integrations break, data migrations surface twenty years of accumulated mess, and some vendors genuinely oversell.

But when I read a risk register on a struggling ERP project, the technical risks are all documented, owned, and dated. The staffing risks are a yellow dot labeled “resource availability.” That asymmetry is the whole problem in one image.

Six seats. Write a name next to each one before kickoff, and write a second name as the alternate. Where a name is missing, you’ve found your risk, and it’s a hiring problem with a known price attached rather than a mystery that surfaces in month seven with no obvious owner and no obvious fix.

If you’re staffing an ERP build now and want a second opinion on which seats you’re actually missing, talk to one of our ERP recruiters. We place these roles across more than 30 U.S. metros, and the conversation is usually shorter than you’d expect. Sometimes it ends with us telling you to promote someone internal instead.