You would never appoint your IT Manager to run a civil construction project.
They’re technically capable. They understand contracts. They can read a schedule. But the moment you picture them on site — managing subcontractors, reading soil reports, making structural decisions — something feels wrong. The domain expertise required is different. The risk profile is different. The consequences of getting it wrong are physical, visible, and immediate.
So why does the same logic disappear when the project is an ERP?
The Assumption That Quietly Kills ERP Programs
The assumption that runs through most organisations — rarely spoken, almost never challenged — is that someone who knows the software, or knows the finance chart of accounts, is naturally equipped to manage the ERP program. The IT Manager understands the system. The Finance Manager knows the business rules. Between them, surely they can handle it.
What this assumption misses is the difference between subject matter expertise and program leadership.
Knowing the software does not mean you know how to manage a vendor who is three months behind and still reporting green. Knowing the chart of accounts does not mean you know how to hold a steering committee accountable when scope has quietly expanded and no one has told the sponsor. These are different skills. And in an ERP program — where the budget is large, the timeline is long, the vendor has done this a hundred times before, and your team is doing it for the first time — the gap between subject matter expertise and program leadership is where most of the damage happens.
There is a concept in psychology called the Dunning-Kruger effect: the less you know about a domain, the less you understand what you don’t know. Applied here, it works at two levels simultaneously. The person appointed to lead the program doesn’t know what they don’t know about program governance. And the executive who appointed them doesn’t know enough about ERP programs to recognise the gap. Both are operating with confidence. Neither is equipped to see what’s building.
This is not about competence in the ordinary sense. The IT Manager and Finance Manager in your organisation are probably excellent at their jobs. The mistake is not in their capability — it is in the assumption that their capability transfers.
Think about what an ERP program actually demands from the person leading it. They need to know when a vendor’s progress claim doesn’t match what’s been delivered. They need to understand the difference between a delay that’s recoverable and one that will compound. They need to read a risk register and know which risks are real and which are decoration. They need to run a steering committee in a way that produces honest reporting rather than managed optics. They need to push back on scope changes without derailing the relationship. They need to know when to escalate and when to absorb.
None of this is in the IT Manager’s job description. None of it is in the Finance Manager’s training. And yet we hand them the program and assume it will work out.
The consequences when it doesn’t are not abstract. They show up as failed go-lives, cost overruns absorbed quietly into the capital budget, key staff who were stretched past their capacity and left, and vendor relationships that turned adversarial because no one managed them from the right position. They show up as steering committees that met every month and received reports that said everything was on track right up until the moment it wasn’t.
The organisations that navigate ERP programs well are not luckier. They understand — usually because someone told them directly, or because they learned from a previous failure — that this class of program requires a different kind of leadership. Not smarter people. Not harder-working people. People with the specific experience to know what the program actually demands and to lead it from that knowledge.
Recognising that early enough doesn’t just protect the investment. It changes what’s possible on the other side of go-live.
