Deep Dive: Why ERP Implementations Fail

Olivia Carter

Good afternoon, Mark. Today, we’re unraveling why ERP implementations crash and burn so often—and, honestly, why the first six months of these projects can make or break everything else. Mark, how many stories have you heard where folks treat an ERP rollout like, oh, just flipping a tech switch?

Mark Putnam

Far too many, Olivia. There’s a misconception out there that ERP is just the next software upgrade: budget, buy, plug in. But, as I always say, it’s not just an IT installation. If you treat it like one, you’ll miss all the subtle, early signals that can doom the project before it ever gets off the ground. That lesson, unfortunately, tends to sneak up on leaders who are more comfortable with hardware than with organizational introspection.

Olivia Carter

You know, one thing that stands out to me—and Mark, stop me if I’m off—but it’s in those early months when leaders either engage for real or disappear, sort of hoping the IT team just “figures it out.” And that’s when you see all these rushed deployments that totally skip the groundwork. Case in point: that regional college that tried to save time by skipping process mapping? Cost them millions. Not just in consulting fees, but actual campus headaches—especially in undergrad admissions. They were trying to fix things on the fly once go-live hit and, surprise, it never quite worked.

Mark Putnam

That's exactly right. If leaders fail to recognize this as a transformation, not an upgrade, you end up with foundations that barely hold. And, as we’ve seen, the cracks start very early—often quietly—before anyone's even realized the mistakes are structural, not technical.

Olivia Carter

So, let’s set the stage a little. ERP systems aren’t what they used to be. Mark, you’ve watched this space evolve over decades—custom builds, vendor monoliths, the modular integration era, and now cloud-native platforms. What’s actually changed across those generations, and why do organizations still keep falling into the same traps?

Mark Putnam

Yeah, it’s been quite the evolution—and the patterns are pretty revealing. Each generation of ERP tried to fix what came before, but every fix came with new problems. The first-gen systems were hand-built in-house—custom-coded to fit the exact needs of the business. They were precise and tightly coupled to how the organization worked at the time, but that came at a price. They were brittle, hard to maintain, and almost impossible to adapt as the organization grew or changed. Within a decade, most were technical debt in disguise. Then came the second generation: vendor platforms, but with heavy customization. Institutions thought they could get the stability of off-the-shelf software and the flexibility of tailoring it to their own quirks. But all those customizations made upgrades a nightmare. You’d go to update the system, and half your workflows would break. What felt like control turned into lock-in.

Olivia Carter

And then the industry kind of swung the other way, right? Toward modularity?

Mark Putnam

Exactly. The third wave said, “Okay, let’s not customize the core. Let’s keep the base system clean and surround it with best-of-breed tools.” That gave you flexibility—but blew up your data architecture. Now you had ten systems doing what one used to do. Each had its own schema, its own update cycle, its own definitions for things like “employee” or “fiscal year.” Reporting became duct tape and prayer. Data warehouses tried to stitch it all together, but by the time reports were accurate, they were usually outdated.

Olivia Carter

And that brings us to now—cloud-native ERP platforms like Workday and Oracle Netsuite. These promise to fix all of that: no more custom code, real-time data, cleaner upgrades, and everything configurable through a UI. Sounds magical.

Mark Putnam

That’s the sales pitch. And to be fair, the architecture is better. These platforms are built for scale, with configuration instead of code, embedded analytics, and unified data models. You’re no longer paying for hosting or managing infrastructure, and upgrades happen continuously. It’s a real shift. But here’s the problem: organizations think they’re buying transformation when what they’re really buying is potential. And that potential only gets realized if you do the hard work—especially around process redesign.

Olivia Carter

Right. Even with all the slick SaaS tools and glossy dashboards, if no one’s rethought the core business processes, it’s still lipstick on a legacy pig. Like, the best reporting platform in the world won’t save you if the underlying workflows are broken. If you just lift and shift your problems from on-prem to the cloud, you’ve automated confusion at scale.

Mark Putnam

Exactly. That’s where the pain really sets in. Institutions treat cloud ERP like a silver bullet—it’s not. It’s a frame. If you bring old logic into a new system, you’re not transforming; you’re entrenching. You end up paying more money to carry more baggage into more visible places. Without reimagining how work should flow, the cloud just makes your inefficiencies faster and your dysfunctions more permanent.

Olivia Carter

Got it, that's easy to see.

Mark Putnam

Let’s dig into this, because I’ve watched it sabotage project after project. Institutions skip genuine process discovery—either to save time, cut costs, or just because they assume they already know how things work. Instead of deeply mapping how work actually happens across departments, they settle for generic flowcharts or out-of-date SOPs. It’s like trying to build a house by guessing where the pipes and wiring should go. Everything might look fine on paper, but the first time you turn on the faucet or flip a switch, things start to short out.

Olivia Carter

Yeah, and that makes all the downstream chaos feel inevitable, right? Bad data gets loaded. Testing fails. People get frustrated and start blaming the software. But the real problem is upstream—the team never took the time to define what success actually looked like, or how their existing processes worked to begin with. Expectations weren’t aligned, edge cases were ignored, and once those gaps surface in implementation, they’re expensive to fix. I feel like a lot of this happens when executives aren’t close enough to the ground to see how work really gets done.

Mark Putnam

Exactly. Executive distance poisons the discovery phase. When leadership assumes the org chart reflects the actual workflow—or delegates process mapping entirely to IT—they miss the messy reality: workarounds, unofficial handoffs, legacy tools still in play. That operational nuance never makes it into the design. And you can’t outsource what hasn’t been articulated. The IT team can’t fix what the business never defined. So when the system doesn’t behave the way people expect, it’s not a tech failure—it’s a planning and leadership failure. People want transformation, but too often they’re unwilling to invest in the discipline and clarity required to get there. And that trade-off almost never ends well.

Olivia Carter

Alright, let’s talk about phases—because ERP isn’t just one big leap, it’s a series of four. There’s Define & Discover, Design, Implement, Stabilize. And the first two—Design and Discovery—those are always the most at risk, right? If you compress or neglect them, everything else sort of tumbles after.

Mark Putnam

It’s like pouring a foundation and then deciding to redraw the architectural plans later—never ends well. Every adjustment has a cost, but, in ERP, late changes are more invisible and more expensive. Compressed design? That invites rework, frustration, and delays. Gaps only start to show during implementation—and by then, options are limited to cutting scope or biting the bullet on costs.

Olivia Carter

And, I mean, I’ve witnessed the data conversion scramble up close. I covered a university where they thought moving data would be a “simple lift.” But, wow, just before go-live, they realized how incomplete their mapping was. Suddenly, it’s triage—manually reconciling student records, re-testing every report, and praying you don’t miss something huge. Everyone’s in crisis mode because those small skipped details early on snowball into disaster during launch.

Mark Putnam

Yes, and those last-minute triage decisions—what to cut, what to defer—are only harmless if planned for in advance. Otherwise, it’s just damage control, and the trust you lose is hard to recover.

Olivia Carter

Leadership really shines—or sinks—here. Too often, leaders want to hand off the planning, or they’re pressured to rush discovery. But ERP isn’t something you can simply throw over the fence. Mark, you’ve seen firsthand how real executive engagement changes everything, right?

Mark Putnam

Absolutely. The difference is night and day. I once took over a project where collaboration and decision rights were unclear. Rebuilding the project meant creating a culture of shared governance, not just technical stewardship. That meant giving decision-making power to the right cross-functional leaders and making sure everyone understood, and bought into, the process. You can’t outsource planning, and you absolutely can’t delegate trust.

Olivia Carter

And it’s the visible, consistent engagement from top leaders that makes stakeholder buy-in real. People notice when leaders are in the room—asking questions, resolving tension, not just showing up for kickoff and then vanishing until the crisis.

Mark Putnam

Exactly. ERP success is an institutional achievement, not an IT victory. Getting there means respecting structure, valuing process, and investing time in clear communication—again and again.

Olivia Carter

This, honestly, is my favorite part. ERP projects are a leadership bootcamp—on steroids. I’ve reported on enough flameouts to appreciate what makes certain leaders stand out. Managing an ERP project, you develop—what, like—a cocktail of negotiation skills, governance fluency, narrative intelligence, and deep institutional literacy.

Mark Putnam

All of those, and more. You learn to craft narratives that move people, not just describe features. You become fluent in how decisions are really made—not through memos, but through committees, conversations, and persistent follow-up. Every day is about aligning interests, framing risks in terms everyone understands, and responding to human concerns, not just technical ones.

Olivia Carter

And that ability to connect the dots—translating tech-speak to mission and outcomes—that’s rare. I really came to recognize that when reporting on leaders who could keep teams focused and stakeholders confident, even when ambiguity or setbacks hit. I guess, to your point, it’s not about being the loudest voice but the steady, trustworthy one.

Mark Putnam

Right. ERP forces you to stretch those muscles—mentoring others, advocating for simplicity when complexity is the easy excuse, and learning to differentiate what’s urgent from what’s truly important. Those are the leadership skills that last way beyond any single project.

Olivia Carter

So, before we wrap, let’s talk about what ERP work really does to you—professionally. It’s kind of an accelerator for personal growth, isn’t it? You get thrown into ambiguity, communication pressure, non-stop decision fatigue—and if you do it right, you come out way more equipped for almost anything after.

Mark Putnam

Exactly. ERP tests your boundaries and your bandwidth. It sharpens your ability to coach others, hold internal clarity, and defend not just the process, but the intent behind it. The ones who come out thriving are those who mature into institutional stewards—not just technical survivors. Those are the leaders campuses need: adaptable, fluent in ambiguity, attuned to culture, and always working for the greater good rather than the short-term win.

Olivia Carter

I love that. ERP isn’t about survival, it’s about becoming the kind of leader that can handle real transformation—at scale, under pressure, in the messiness of real organizations. Which…feels pretty relevant no matter where tech—or higher ed—heads next. Mark, I could talk about this for another hour, but we’ll save the rest for a future episode. Thanks for sharing your war stories today!

Mark Putnam

Always a pleasure, Olivia. Looking forward to our next deep dive.

Olivia Carter

Thanks to everyone for listening. We’ll be back soon with more lessons learned, without quite as many scars. Take care, Mark.

Mark Putnam

Take care, Olivia. Bye for now, everyone.