The real deliverable of an ERP project isn't the software

If you ask what an ERP project delivers, the obvious answer is the system itself — a working platform that records transactions, produces reports, and runs the workflows the business configured. That answer is correct and incomplete. The more valuable deliverable, the one that actually determines whether the project was worth doing, is quieter and much harder to see at the moment of go-live: a business that still understands its own decisions, two or five years later, regardless of who's still around to explain them.

Why the software is the easier thing to deliver

A working system is verifiable in the moment. You can test it, demonstrate it, sign off on it. It's a concrete artefact with clear pass-fail criteria, which is exactly why it's the thing every implementation gets measured against. Everyone involved — the business, the implementation partner, the project team — has a shared, testable definition of success sitting right in front of them at go-live.

Institutional understanding is not verifiable in the moment the same way. You can't test, at go-live, whether the business will still be able to explain its key decisions in three years, because that test can only be run once three years have actually passed — by which point it's too late to fix retroactively if the answer turns out to be no. This is precisely why it gets underweighted relative to the software itself, not because anyone thinks it doesn't matter, but because it's structurally harder to hold anyone accountable for at the point accountability is normally assigned.

Why this reframing changes what "success" should mean

If the real deliverable is durable institutional understanding rather than just a working system, the standard for a successful project shifts. A project that delivers excellent software and no lasting record of its own reasoning has delivered half of what it should have, even if every technical measure looks perfect. This isn't a small semantic difference — it changes what gets prioritised during the project itself, and what gets checked before sign-off — see before you sign off an ERP implementation, ask this.

Why this argument applies beyond ERP specifically

The same logic holds for any significant business system or process change: the visible artefact — the software, the new process, the reorganised team — is the easy half to deliver and measure. Whether the business retains genuine understanding of why that artefact looks the way it does, once the people who built it move on, is the harder, more consequential half, and it applies just as much to a new approval process or a restructured department as it does to an ERP rollout.

This cluster has made a version of this argument from many specific angles — see what your ERP does not record, why the best implementations still lose to turnover, a completed ERP rollout is not a finished business — and the throughline across all of them is this same, single point: recording a transaction and preserving the reasoning behind it are different jobs, and only one of them happens automatically.

What this means for how a business should actually evaluate its own implementation

Not "does the system work" alone, though that remains necessary. The fuller question is: if every person currently involved in this implementation left tomorrow, would the business still understand why its key configuration decisions were made the way they were? For most businesses, honestly answered, that question exposes real gaps — not because anyone did anything wrong, but because nobody was ever specifically asked to close them, and closing them was never treated as part of what the project was actually delivering.

Closing the gap between the two deliverables

Name the second deliverable explicitly, from the start of any significant project, rather than assuming it will happen as a natural byproduct of good technical execution. It doesn't, reliably, unless someone treats it as its own objective.

Build capturing reasoning into the project's definition of done, alongside the technical acceptance criteria, so it's checked with the same rigour as everything else on the sign-off list, rather than left as an informal hope.

Keep the discipline running well past the project's official end, since the need for it doesn't have a closing date the way the project itself does — the business keeps making judgement calls indefinitely, and each one carries the same requirement the original implementation did.

Common questions

What is the "real deliverable" of an ERP project, if not the software itself?

A business that still understands why its own key decisions and configuration choices were made, well after the people who made them have moved on. The software is the visible, easily tested output. Durable institutional understanding is the harder, more consequential deliverable that determines whether the investment actually pays off over time.

Why does the software get prioritised over institutional understanding in most projects?

Because a working system is verifiable immediately — it can be tested and signed off at go-live. Whether the business retains genuine understanding of its decisions can only be tested years later, by which point it's too late to fix retroactively, which makes it structurally harder to hold anyone accountable for at the normal point of project accountability.

Does this issue apply only to ERP implementations?

No — the same pattern applies to any significant business change, including new processes or organisational restructuring. The visible artefact is always the easier half to deliver and measure; whether the reasoning behind it survives the people who built it is the harder, more consequential half in every case.

How can a business make sure this second deliverable actually gets addressed?

Name it explicitly as an objective from the start of the project rather than assuming it happens automatically, build capturing reasoning into the project's formal definition of done alongside technical criteria, and continue the same discipline well past the project's official end, since the underlying need never actually stops.

Related: before you sign off an erp implementation ask this · why the best implementations still lose to turnover · a completed erp rollout is not a finished business