Why CIOs Get Fired After ERP Implementation

Hershey Foods lost about $100 million in Halloween candy orders in 1999 because their brand new SAP system could not ship product. Nike bled more than $100 million in lost sales in 2000 when their i2 supply chain system generated demand forecasts that had no relationship to reality. Levi Strauss wrote off a similar fortune when their ERP project stalled years later. And every time, the postmortem read the same way: the software was fine, the change management was inadequate.

That phrase, "the software was fine", should bother you more than it does. Because if the software was fine, what exactly failed? The answer sits in the gap between what enterprise systems are designed to do and what organizations are willing to let them do. ERP systems enforce process standardization. They demand that marketing and logistics and manufacturing all use the same data structures, the same workflows, the same definitions of a customer. That is the whole value proposition. And that is exactly what the organization fights, because standardized processes threaten local autonomy, professional identity, and political power.

I keep coming back to DeSanctis and Poole (1994) when I think about this. Their Adaptive Structuration Theory gives a clean language for what happens during technology appropriation. A technology arrives with structural features (the rules, resources, and capabilities embedded in it) and a spirit (the general intent or official line for how it should be used). Groups then appropriate those structures, and the appropriation can be faithful (consistent with the spirit and feature design) or unfaithful (departing from that spirit). The spirit of ERP is standardization. The structural features enforce integration. When a division manager demands thirty custom fields in their order screen so their department can keep doing things the way they always have, that is unfaithful appropriation. And it is not a technical choice. It is a political choice dressed up as a technical requirement.

What makes this hard is that nobody in the organization thinks they are resisting change. The logistics director genuinely believes their process is unique. The finance VP genuinely believes their reporting requirements are non-negotiable. They are not lying. They are defending their professional identity, which is built on expertise in their particular way of doing things. Standardizing that way of doing things means admitting that a significant portion of their expertise was just local custom, not essential competence. Most people cannot do that. So they fight the standardization by pushing for customization, and the customization destroys the integration logic that was the reason for buying the ERP in the first place.

This is not a technology problem. Markus and Robey (1988) argued thirty years ago that the emergent perspective is almost always the correct IS answer, because technology does not determine outcomes alone and humans do not fully control technology. Outcomes arise from the recursive interaction between technology, organizational structures, and human agency. An ERP rollout is a textbook case of emergence. The software arrives with a configuration. The organization pushes back. The configuration is modified. The organization pushes back again. The go-live date arrives. Nobody has gotten what they wanted, and nothing works as anyone expected. The technology did not fail. The emergent process did.

I wrote recently about why the same technology succeeds in one department and fails in another, and about what sociotechnical theory actually means for organizational design. Both posts circle the same point from different angles: technology and organization cannot be designed separately and then bolted together at go-live. They co-evolve. The ERP failure cases are extreme demonstrations of what happens when organizations refuse to accept this.

Hershey's SAP implementation in 1999 is usually described as a scheduling error. They cut over too fast, the narrative goes. They compressed a four-year timeline into thirty months and launched right before Halloween. But the scheduling was not the root cause. The root cause was that Hershey's tried to simultaneously replace every legacy system across every business unit in a "big bang" go-live because nobody wanted the political fight of telling certain divisions they had to wait. The compressed timeline was a symptom of the organizational conflict, not a standalone project management mistake. The software processed orders correctly. The integration points between the old systems and the new system, and between divisions that had never shared data before, were where things broke. Those integration points were organizational long before they were technical.

Nike's i2 supply chain disaster is even cleaner as a case. The demand forecasting software worked exactly as it was told to work. Nike configured it with forecasting parameters that made sense for their old business model (stable, predictable demand) but not for their new reality (short product lifecycles, fashion-driven volatility). The system faithfully executed the assumptions Nike gave it. The failure was not in the algorithm. It was in the gap between how the organization understood its own business and how that business actually operated. No amount of software testing catches a problem that lives inside the organizational assumptions the software is asked to encode.

The CIO gets fired in these cases for a predictable reason. The board needs a story that makes sense. "Our organization lacks the political will to standardize its own processes" is not a story a CEO can tell investors. "The CIO failed to manage the implementation" is. Someone has to take the blame, and the person whose title literally contains the word information is the structurally convenient target. But the CIO did not fail to implement the software. The software implemented just fine. The organization failed to standardize its processes, and nobody with the authority to enforce standardization was willing to spend the political capital required. The CIO cannot fire the CFO for refusing to change their chart of accounts. The CIO cannot fire the VP of operations for demanding custom workaround screens. But the board can fire the CIO. So they do.

I am not arguing that these CIOs were blameless. Plenty of ERP implementations crash because of genuine incompetence in vendor selection, project scoping, or data migration. But the pattern in the famous cases is different. The pattern is an organization that bought a standardization technology and then systematically resisted standardization, leaving the implementation team with a Frankenstein system that satisfied nobody's local demands and delivered none of the integration benefits. DeSanctis and Poole (1994) would call that unfaithful appropriation at scale. Organization theory would call it structural conflict between centralized process design and distributed power. The postmortem calls it "inadequate change management." I think that phrase is a euphemism.

What real change management would have looked like in these cases is executive leadership willing to tell division heads that their local processes were not special, that the standardization was happening whether they liked it or not, and that their job was to adapt their teams to the new reality, not to protect the old one. That is a political act, not a project management technique. Most organizations cannot do it because executives at that level owe their positions to the same political coalitions that resist standardization. The CIO is the one executive whose authority comes from expertise rather than coalition-building, which makes them the only person who can be safely sacrificed when the coalition refuses to cooperate.

The lesson that keeps getting missed is that ERP implementation is not a technology project that requires change management. It is an organizational restructuring that happens to involve software. The software is the easy part. The restructuring is where everything breaks, and the restructuring cannot be delegated to a CIO because the CIO cannot restructure the company. Only the CEO can do that. When the CEO declines to do it and the implementation still goes forward, the failure is inevitable, and the CIO's firing is just the ritual that closes the loop.