The number on the PeopleSoft contract was never the number that mattered.

Three developers, full-time, for eighteen months. That's the number nobody put in the business case. Not because anyone hid it. Because nobody decided, module by module, what deserved to be different. The cost showed up later, everywhere - not as a decision failure, but disguised as a staffing problem.

I watched this happen at an athletic specialty retailer, and it's the clearest example I've got of a truth most ERP conversations skip past: total cost of ownership doesn't live in the contract. It lives in the people - the ones building the customizations and the ones who have to survive using them. And it compounds. A differentiation call you skip early doesn't just cost money later. It sets the sequence that decides how badly change management fails.

The differentiation failure

The retailer was big enough that "we need an ERP" had become obvious to everyone. Inventory pushed hardest for the project, and inventory had a real case - complex allocation rules, multi-day pick cycles, wave picking through the distribution center. PeopleSoft didn't understand any of that out of the box. Customizing it was the right call, even though it was a brutal one.

Here's what didn't happen: nobody made that same call, on purpose, for finance and procurement. Nobody ever asked whether those functions were differentiators at all. So they got dragged into the same "bend it until it matches exactly what we had" posture by default. Consultants wrote code inside PeopleSoft - replacing core executables - to preserve old processes exactly: the POs, the exceptions, the deals nobody wanted written down. The system of record for inventory was never actually accurate on its own. Internal code had to reconcile it just to produce a number anyone could report.

VP after VP asked the obvious question: what's the point of running PeopleSoft if we've rewritten PeopleSoft? The project kept moving anyway. By then nobody was making decisions. They were maintaining momentum.

The bill: implementation ran three times the license and support cost, in services and build alone. Years later, two things finally forced finance and procurement back to standard: a new PeopleSoft version the business couldn't adopt without unwinding the custom layer, and new leadership asking why they were paying for support they got no benefit from. Inventory stayed customized. Correctly. It was the one place the differentiation call had actually been made.

The change management collapse

Because inventory pushed for the project, inventory went live first. In hindsight, that's the worst possible sequencing. The most complex, most custom module, touching every other system, set the tone for everyone who came after.

Change management ran as a punch list: training manuals, training classes, key updates. All of it aimed at the stuff that was changing, none of it aimed at the people who had to change. Leadership had already lived through the whole decision arc - doubt, debate, resolution, cheerleading - months before a single frontline user touched the new screens. Users start at zero. Anger, confusion, and then the part nobody plans for: they're visibly bad at the new system for a while, in front of their coworkers, while leadership is upstairs talking about long-term benefits nobody on the floor can feel yet. Nobody cares about a faster month-end close when they can't close today's sales day.

Inventory's rollout was rough, publicly, and it set the emotional baseline for everyone watching. By the time finance and accounting took their turn, there was nothing left to draw on. Nobody chose to burn goodwill on the hardest module first. It just happened, because the only sequencing question anyone asked was who wanted to go first, not who could survive going first.

What to actually do differently

Before you sequence anything, find your cranks - the people already frustrated by the current system's real limits, for real reasons, not the loudest voices in the room. Go find three of them this week, in whichever function is closest to going live, and ask them directly what breaks worst about how things work today. That's the fastest, cheapest diagnostic available to you, and it's cheaper before rollout than after. If no cranks exist in a given function, that's information too - build executive air cover instead, openly, so people know why this is happening before it starts happening to them.

Then sequence by readiness, not by who pushed hardest for the project. Before you scope anything, rate every module one to five on how genuinely different it needs to be - not how loud its champions are - and let that score decide who goes live first, not politics. The most custom, most disruptive module should never go first by default. It should go where the organization can absorb the worst version of the rollout and still recover.

Once you're live, plan on the people running it being visibly bad at their jobs for a while, in front of each other, instead of pretending it won't happen. Leaders worry people will bail when it gets ugly. They almost never do, as long as the room feels safe enough to be bad at something for a while.

None of this shows up on the ERP contract. All of it shows up on the bill.

The module you roll out first isn't a scheduling decision. It's an emotional bet on the whole implementation - and most companies place that bet without ever realizing they made one.