The Five Decisions That Decide Your ERP Destiny

You can tell how an ERP implementation will end before a single module goes live. Not by watching the project plan, or the steering committee slides, or the vendor’s demo. You tell by watching five decisions — made in the first few weeks, often informally, often by people who don’t realise they’re deciding anything at all.

Most organisations think ERP success is determined during delivery: how well the consultants configure the system, how disciplined the testing is, how smooth the cutover goes. That’s the comforting version. The truth is less comfortable. By the time delivery starts, most of the outcome has already been written. What’s left is execution of a decision that was made — or avoided — months earlier.

Here is the framework, in the order the decisions actually need to be made.

1. Alignment

Before anything else, the organisation needs to agree on the future it’s actually building toward — not the one it’s currently operating in.

• Business architecture — how the organisation is structured to deliver value, decided independently of what any vendor’s system makes easy.
• Operating model — how work actually flows day to day, and whether that’s the model worth preserving or the one worth replacing.
• Support for future business needs — tied explicitly to business goals, vision, and strategy, not to next quarter’s pain points.

A council I worked alongside ran their entire requirements process around how things were done in 2019. The system they built was excellent at replicating a structure they were already trying to leave behind. Alignment isn’t a workshop. It’s a decision about direction, and it has to be settled before requirements are written, not discovered afterward.

2. Needs and Requirements

This is where most projects quietly fracture into chaos, because “requirements” gets treated as one job when it’s three.

• Systems architecture — what integrates with what, where the system of record sits, who owns master data. Decided structurally, not negotiated feature by feature.
• Functional requirements — the visible layer. What the system does, screen by screen, process by process.
• Non-functional requirements — the layer almost nobody fights for in the room: performance, security, reporting, auditability.

The third category is the one that surfaces as “unexpected problems” eighteen months after go-live, when they were never unexpected at all. They were simply undecided.

3. Business Expectations

Budget and timeline get plenty of attention. The third expectation gets almost none.

• Budget — the number everyone scrutinises before signature, and almost no one revisits structurally once delivery starts.
• Timeline — the constraint that shapes every later trade-off, usually set before anyone fully understands what the project actually requires.
• Cultural fit with the vendor’s team — not the methodology on the slide deck, but whether the actual humans assigned can be worked with under pressure for the next eighteen months.

Organisations that select on price and capability slides alone often find themselves locked into a multi-year relationship with people they fundamentally cannot work with. By the time that becomes obvious, the contract is signed.

4. Forming the Project Team

This is a staffing decision dressed up as an organisational chart.

Client-side roles:

• Project manager
• Change manager
• Business analysts
• Testing lead
• Data migration lead
• Reporting owner
• Technical / system administrator

Vendor-side roles:

• Project manager
• Functional consultants
• Technical consultants

The mistake isn’t usually failing to fill these roles. It’s filling them with whoever was available rather than whoever was right — handing data migration to someone with no data background, or change management to someone with no organisational standing to actually drive change. The org chart says the role exists. It says nothing about whether the person in it can carry it.

5. Project Governance

A project board exists on almost every program. Clarity about what that board is actually for exists on far fewer.

• Project board with clarity on its role — not a status-reporting ritual, but a body with defined decision rights.
• Direction from each department — input that shapes the project, rather than instructions issued downward into it.
• Departmental ownership — each department accountable for its own corner of the implementation, rather than treating it as IT’s problem to solve on their behalf.
• Sponsor accountability for the investment — accountability that continues past sign-off, not a signature that ends it.

Sponsorship that ends at sign-off isn’t sponsorship. It’s a signature.

Lay these five out in sequence and a pattern becomes visible: each one is a precondition for the one after it. You can’t get requirements right without alignment. You can’t staff the team correctly without knowing what the requirements actually demand. You can’t govern a program without a sponsor who’s still in the room past the kickoff meeting. Skip a step, and the project doesn’t fail at that step — it fails three steps later, in a place that looks completely unrelated to the decision that was actually never made.

Most ERP retrospectives ask what went wrong during delivery. Almost none ask which of these five decisions was never properly made before delivery began.

Which one was skipped in your last project?