When we joined this project, it had already failed three times.
That kind of history changes the atmosphere in a company. People are tired. Trust is low. Everyone has an explanation for what went wrong, and most of those explanations sound reasonable on the surface.
Some say the requirements were not clear. Others say the data was messy. Some blame the software. Some blame the implementation partner. Some believe the business was simply not ready for change.
Usually, the truth is deeper than that.
Before starting anything new, we made a decision that shaped the entire recovery. We did not begin with another discovery workshop. We did not ask the team to repeat the story of what went wrong. Instead, we went back and reviewed more than two hundred hours of recorded meetings, workshops, and project discussions from the three previous attempts.
It was not the easiest path, but it was the right one.
When a project has failed multiple times, the organization often develops a shared explanation for the failure. Sometimes that explanation is accurate. More often, it is the version of the story that allows everyone to keep working together without reopening difficult conversations.
If we had started by asking the same questions again, we would likely have received the same answers the previous consultants received. And if we accepted those answers at face value, we would have repeated the same mistakes.
So we went back to the source.
We watched the same people, in the same discussions, across three failed projects. We listened carefully, not only to what was being said, but to what kept repeating. We looked for the pattern that had become invisible to the people inside the room.
Eventually, the real issue became clear.
The problem was not the ERP system. It was not only requirements. It was not only data quality. It was not only change resistance, although all of those challenges existed.
The real issue was leadership misalignment about the future state of the business.
Each department was describing a different company.
Sales was designing one future. Operations was designing another. Finance was designing a third. Each group had valid concerns, but there was no shared agreement at the leadership level about what the business was actually trying to become.
That meant every previous implementation team was placed in an impossible position. They were collecting requirements from different departments, treating them all as equally final, and trying to configure a system that could satisfy conflicting visions at the same time.
But software cannot resolve strategic misalignment.
An ERP system can support a business model. It can improve processes. It can enforce structure. It can create visibility. But it cannot decide, on behalf of leadership, what the business is supposed to look like.
That was the turning point.
Instead of pushing the team into another round of detailed requirements, we first brought the conversation back to the leadership level. We focused on the future operating model. We clarified how the business needed to run, where standardization was required, where flexibility was acceptable, and which decisions had to be made before the system design could continue.
Once leadership alignment was established, the project changed.
The requirements became clearer. The contradictions became visible. Decisions that had been avoided for years were finally made. Departmental priorities could now be evaluated against a shared business direction, rather than treated as separate wish lists.
That is what allowed the project to move forward.
The lesson from this experience is simple, but often ignored: when a transformation project fails repeatedly, do not rush to restart it. First, understand why the previous attempts failed at the root level.
Sometimes the issue is not technical at all.
Sometimes the project is failing because the system is being asked to build a future that leadership has not yet agreed on.
And until that alignment exists, every implementation partner will struggle, every workshop will create more confusion, and every project plan will look better on paper than it performs in reality.