The Software Rarely Fails. The Reason Does.

A conversation with Faheem Usmani at Devsinc, on why so many ERP projects fail, the one sentence leaders should be able to say before they buy, and why change management is the real work.

I sat down with Faheem Usmani for the third episode of Beyond The Code to talk about ERP deployments. Faheem has spent 15 years in Microsoft Dynamics and ERP projects, and he has seen both the best and the worst an ERP can do to an organisation. I am not an ERP person, and I said so on the day. I went in wanting to understand how to plan a deployment that works. I came out convinced the hard part comes before the software: being able to say, in one sentence, why you are doing it.

First, what an ERP is

Early on, I stopped him. For a layperson, almost anything that changes how a business runs gets called an ERP, and I wanted the word pinned down.

His answer: Enterprise Resource Planning, though it goes well beyond planning and well beyond the accounting core. Finance, supply chain, manufacturing and HR are the main modules. It reaches every department and every user, and it changes how they plan and do their jobs.

He had already given me the line that frames the rest of this piece. “It’s not just a technology project,” he said. “It’s a business transformation project.” Most organisations, in his experience, still go in with a technology mindset.

Accounting software changes how one team records numbers. An ERP changes how everyone works.

Two or three years

I asked the question I suspect plenty of CEOs want to ask and don’t: what kind of software takes two or three years to implement? Faheem called it a million dollar question. His answer had very little to do with software.

He has watched companies start projects with no strategy behind them. Someone in a department asks what is in it for them, and the sponsor and the CEO cannot say in one sentence why the company is doing it. The answers he hears are vague. The old systems need replacing. We need technology.

My reading: the long timeline is a symptom. A project without a reason has no finish line. It just keeps going.

The $100 question

I put it to him the way I would frame any investment. Even for a small accounting application or a CRM, we ask why we are doing it and what the outcome is. Say we are investing $100: what do we get for that $100? An ERP is not $100. It can run into millions. So why does the question get skipped?

Faheem thinks many decision makers commit without understanding the benefit, or the time and patience it will take. A real problem statement, in his examples, sounds specific: a company losing revenue every year to poor order fulfilment because its applications work in silos. When the decision maker is that clear about the problem, “then that becomes the North Star.” Without it, “the project becomes free for all”, and every department brings its own wish list.

I would go further. A problem statement is what lets you say no to the next request. Without one, nobody can.

Buying what the competitor bought

I suggested a planning exercise before the actual project. Faheem liked the idea, then gave me the less flattering reality: most decision makers don’t have the patience. They go with buzzwords. If a competitor has implemented a particular system, they want the same system. The reasoning he hears is roughly: we are a fashion apparel business, we also manufacture, so we need what they have. I asked whether people still do that. They do, he said.

A competitor’s system was chosen for the competitor’s problems. Copying it skips your own question.

The warning signs

I have seen experts predict, quite reasonably, that a project is going to fail. I asked Faheem what they are seeing.

He named two signals. The first is the people who signed the contract (the CEO, the CFO, the project sponsors) no longer paying attention or reviewing the plans and the progress. The second is departments that never give the project their time: each one, from finance to warehousing, has to name a dedicated person. If that doesn’t happen, he said, “they must be ready for the failure.”

I called that person a champion: someone who knows how the department actually works and can make decisions on its behalf. Faheem agreed. His reason was human. When an ERP goes live, processes change all at once, and people resist change by default. They need to feel part of the project.

If a department cannot spare one person, it has not agreed to the project.

Change management, again

Later on I noticed we kept coming back to the same words: change management, change adoption, engagement. So I asked whether there is any structure behind it.

Faheem pointed to Success by Design, a Microsoft framework that sets out how each phase rolls out and who needs to be involved at each stage, starting with executive management. He also expects the implementation partner to tell the client, before signing, how much effort the project will need from their side.

Change management isn’t the soft part of an ERP. Most of the time, it is the project.

The sentence first

Right at the start, Faheem had put the downside plainly: “we have seen multi-million projects collapse under their own weight due to the reason they were unable to plan it properly.”

Almost nothing he described after that was a software problem. Leaders who could not say why. A competitor’s choice, copied. Sponsors who stopped looking. Departments that never sent anyone.

So my advice is unglamorous. Before you choose a product, write the sentence: the problem this project exists to solve. Then hold every request against it. An ERP is a business decision wearing a technology label. When it fails, the label takes the blame.

Thanks to Faheem Usmani for the conversation, and for being so direct about the warning signs. Watch the full episode on YouTube.