When an implementation Go-Live Date Becomes More Important Than Readiness
ERP implementations rarely fail because of a single bad decision. Many times, they struggle because organizations slowly stop responding honestly to operational reality. I saw this firsthand during a large ERP implementation for a national nonprofit organization.
Long before the project started struggling, the warning signs were already there.
Our team escalated concerns repeatedly. Internal leaders raised issues around testing, training readiness, unresolved dependencies, and the growing instability caused by losing a key subject matter expert midway through the implementation.
Still, the go-live date never changed.
At the time, I couldn’t understand why leadership continued pushing forward when the organization was clearly losing operational stability.
Later, I realized the implementation was no longer being managed around readiness. It was being managed around a commitment that had already been made to the board.
The Risk of Concentrated Institutional Knowledge
The departure of the organization’s primary SME became a major turning point in the project.
She held years of operational knowledge that extended far beyond documented processes:
manual workarounds, reporting nuances, department-specific exceptions, and critical downstream impacts that were never fully captured in process documentation.
After she left, confusion spread quickly.
Teams started providing conflicting answers about workflows. Testing slowed down. Decision-making became fragmented. Processes that previously seemed stable suddenly became uncertain.
The ERP implementation exposed a deeper organizational issue:
too much operational knowledge was concentrated in too few people.
Losing one person should not destabilize a critical transformation initiative that significantly.
But it did.
How Organizations Normalize Dysfunction Under Pressure
As the go-live date approached, the culture around the implementation changed.
Earlier in the project, concerns were raised openly and debated honestly. Later, conversations became more cautious.
Nobody wanted to be perceived as slowing the project down. Nobody wanted to walk into another steering committee meeting explaining why something still wasn’t ready.
So the organization adapted. But not in a healthy way.
Teams started forcing progress through workflows they no longer fully understood. Bad data was carried forward because cleansing it would delay testing. Operational concerns became temporary workarounds instead of signals to pause and reassess.
Over time, standards shifted.
Concerns that would have triggered major escalation earlier in the project slowly became accepted as manageable compromises.
Leadership Pressure and Organizational Effectiveness
Looking back, I do believe leadership pressure played a significant role in how the implementation unfolded.
Once the go-live date became tied to executive credibility, the organization’s ability to evaluate readiness objectively became increasingly compromised.
But the implementation also revealed broader organizational effectiveness issues that likely existed long before the ERP project itself:
dependency on tribal knowledge
undocumented operational processes
weak cross-functional alignment
limited operational redundancy
pressure-driven decision-making
The ERP system didn’t actually create those problems but it DID expose them.
Final Reflection
One of the biggest lessons I took away from that implementation is that organizational dysfunction rarely appears all at once.
More often, standards erode gradually under pressure while people convince themselves the compromises are temporary.
That pattern extends far beyond ERP projects.
It shows up in leadership teams, operational strategy, change management, communication culture, and organizational decision-making every day.
