Why the last ERP failed

The real reason a firm's first attempt at proper software collapsed, and why it was not the reason everyone remembers.

When I first spoke with a high-rise practice in Lagos about their operations, the first thing that came up was not what they wanted. It was what they had already been through.

They had tried before. A proper system, chosen with care, meant to pull the whole firm together. It got as far as go-live. And then, at go-live, the contract was repriced. The number that had been agreed was no longer the number. The firm looked at what it would now cost to run, year after year, and walked away. Years later, the memory of that was still the loudest thing in the room. Not "we want software." Rather, "we tried, it burned us, and we are not sure we want to try again."

If you are going to sell a firm like this anything, you have to understand that failure properly. And the honest version is not the flattering one.

It did not fail because the software could not do the work

It is tempting to tell the story as: the old system was wrong for architecture, it could not handle construction, so of course it failed. That is the version a competitor would love to sell. It is also not true.

The system they tried was Odoo, and Odoo is a capable platform. It has genuine construction and project capability, natively and through its add-ons. Plenty of firms run on it well. If you claim it simply cannot do the work, any principal who has actually looked at it will know you are selling rather than telling the truth, and you will lose them at that sentence.

The failure was not capability. It was two other things, and both are easy to repeat with any system if you are not careful.

What actually failed

The first was the shape of the deal. Odoo is priced per user. Every person you add to the system carries a fee. For a firm that wants everyone, the architect, the quantity surveyor, the site team, the finance office, working in one system, per-seat pricing turns "get the whole firm on it" into a bill that grows with the firm. When the contract was repriced at go-live, that structure was what made the new number frightening. The firm was not refusing software. It was refusing a cost that scaled against the very thing it wanted, which was everyone using it.

The second was subtler, and it is the one that matters most. The project tried to fit the firm into the software's idea of how a business works. Most business software carries a built-in picture: you sell products, you buy materials, you hold stock. An architecture firm does not live in that picture. It bills a fee agreed as a percentage of construction value. It has a quantity surveyor who prices and certifies. It issues interim payment certificates against a builder's payment applications. It runs a variation register. It keeps a drawing register where revisions matter as much as the drawings themselves. Ask a firm to squeeze those into fields built for selling goods and the system will technically run and quietly fail to describe the business. Staff will keep their real records in the spreadsheets they trust, and the expensive new system becomes a second place to type things.

Fitting the software to the practice, not the reverse

The lesson from a failure like this is not "pick a different brand." It is a change of direction. The software should be shaped to the practice, not the practice to the software.

That means starting from the objects a firm actually runs on and making the system hold them: the project as the spine, with the agreed fee and the construction value on it; the three people who lead a project, the architect, the quantity surveyor, and the project manager, as real roles; the interim payment certificate, the variation register, and the drawing register as real records with the standing they carry in practice. On a flexible platform like ERPNext, the open-source business system, these can be built as first-class objects rather than forced into fields meant for something else. And the commercial shape matters as much as the technical one: a model where getting the whole firm onto the system does not punish you for every seat you add.

The insight

When a firm tells you their last system failed, listen past the brand. The failure that scarred them is almost never "the software could not do it." It is usually a deal that punished them for growing, and a system that asked them to become a different kind of business than they are.

The firms that get burned twice are the ones who fix only the brand. The firms that get it right the second time fix the two things that actually broke: they choose a shape that lets everyone in without a rising toll, and they insist the software bend to the practice, because a practice that bends to its software slowly stops being itself.