Why transformation projects keep repeating the same mistakes

Every failed ERP project leaves behind data, experience and causes. Yet companies repeat the same mistakes. Why this pattern persists and what helps in practice.

No sooner has one crisis been overcome than the next transformation begins, as if the previous one had never happened. That was the case after the pandemic, and it remains the case in industrial projects today.

Every failed ERP project, every unsuccessful digitalisation initiative, every abandoned change initiative leaves behind data, experience and causes. Yet in almost every new undertaking, we ask the same questions, make the same assumptions and repeat the same mistakes.

The question is why this pattern persists. And what a company can actually do differently.

What companies actually record after a project

In most organisations, project closure documentation is produced at the end of a project. It records what was achieved, how the budget was managed, which milestones were met and when, and which outstanding issues are being handed over.

This is diligent work, yet largely worthless for the next project. Because it documents outcomes. What is missing is the decisions that led to those outcomes.

Anyone reading afterwards that a production ramp-up was six months late knows no more than they did before. What would have been useful to know is who decided in January that qualification could run in parallel with series production, and on what basis. That information is recorded nowhere. It was the real turning point.

Why lessons learned rarely change anything in practice

Almost every company knows the format. A meeting is scheduled at the end of the project, those involved collect examples of what went well and what did not, someone writes it all down, and the file ends up on a drive.

Three things ensure that nothing comes of it.

First, the meeting happens too late. People sitting down together six months after the critical phase remember the outcome, but no longer remember what information was available at the time. In hindsight, every wrong decision seems obvious, and that is precisely why nobody learns anything from it.

Second, the wrong people are in the room. Those who completed the project attend, not those who planned it. But only the people involved in planning know the assumptions on which everything was built.

Third, and this is the real reason, the analysis turns into a question of blame. As soon as someone suspects that the review will reflect badly on them, explanation gives way to self-defence. From that point onwards, the meeting is effectively over in terms of substance, even if it continues for another hour.

The difference between documenting outcomes and analysing decisions

Documenting outcomes answers the question: What happened?

Analysing decisions answers a different question: On what basis did we act at the time, and which parts of that were assumptions rather than facts?

Those who simply close the book on mistakes repeat them. Those who understand them use them to build better processes, better organisations and better decisions.

The difference is substantial. It is not the software that determines a project’s success, nor the budget or the method. It is the ability to genuinely take something away from the last undertaking.

What an honest project review looks like in practice

The process is straightforward and requires no textbook method. Four steps are enough.

• List the decisions, not the events. Go through the project and note every point at which a direction was set. A supplier appointed, a deadline promised, a resource withdrawn, the scope expanded. In a medium-sized undertaking, there are rarely more than fifteen to twenty such points.
• For each decision, reconstruct what was known at the time. What was known at that point, what was an assumption, and what was a hope? This distinction is the very core of the exercise. Almost every failed project contains two or three assumptions that were never identified as such, but were treated as facts from the outset.
• Check whether the decision was justifiable based on what was known at the time. This is the question that prevents blame. A decision may have been right and still led to a poor outcome. And it may have been wrong even though things worked out well in the end. Anyone who fails to distinguish between the two learns from chance rather than from how events unfolded.
• Identify which question needs to be asked earlier in future. The outcome is not a thirty-point action list, but a handful of questions to be answered at the start of the next project. These questions are precisely the result that can be passed on.

This takes half a day. The session should take place within a few weeks of the critical phase, not after the formal project closure, and should be facilitated by someone who bears no responsibility for the outcome.

Why this still happens so rarely

Because honest analysis is uncomfortable. It reveals that a commitment was made without any basis for it. That a warning was raised and nobody wanted to hear it. That a deadline was tied not to the market, but to a presentation.

As long as mistakes are regarded as personal failures within an organisation, nobody will voluntarily help establish what happened. That is why the prerequisite for any useful analysis is not a method, but an attitude: it is about the decision, not the person.

This attitude cannot be imposed. It must be demonstrated by whoever has the most to lose, in other words, by the leadership itself. A managing director who openly puts their own first wrong decision on the table will then get an analysis that is worth something.

How we handle this

When we take on an assignment, the first question is not what should be planned now. It is what happened during the last attempt. In most cases, there was one, and in most cases, everyone in the organisation knows the unofficial version.

That version is more valuable than any closing documentation. It is simply not in any file. Instead, you hear it on the shop floor, in conversations with shift leaders and supervisors, usually after the third or fourth question.

This is precisely where we differ from a traditional large consultancy. A concept that describes the future without having understood the recent past repeats its predecessor’s mistakes at a higher level. We take operational responsibility and stay until things are running. The benchmark is not the report at the end, but whether things are still running after we have left.

Transformation therefore does not begin with the next project. It begins with an honest analysis of the last one.

About SMART iNTERIM

SMART iNTERIM Management supports manufacturing companies through operational transformation: restructuring, factory set-up, factory relocation, turnaround and process optimisation. We bring hands-on experience, not a remote perspective, and take operational responsibility rather than simply making recommendations. Head office in Switzerland, branch office in Dubai.