“Tell me: why are we doing this ERP project?”
- 4 hours ago
- 5 min read
An ERP project can absorb substantial investment, demand time from some of the organisation’s most experienced people and shape how the business operates for years. Yet many organisations begin by asking which system they should buy before leadership has agreed what the project is meant to achieve.
Before beginning ERP software selection, the leadership team should be aligned around clear answers to these key questions:
Why are we doing this?
Why now?
What must the organisation be able to do in the future that it cannot do today?
What is distinctive or valuable about the organisation that the project must preserve?
If leadership cannot agree on those answers, the ERP selection process may be starting too early.
A Challenge to the Leadership Team
Ask each member of the leadership team, independently, to complete these sentences:
“We are investing in a new ERP now because…”
“As a result of this project, the organisation must be able to…”
“Whatever solution we choose, we must preserve…”
Then compare the answers. If they are materially different, stop and talk about it before talking to ERP vendors. Your ERP selection process will not resolve a split leadership agenda; it is more likely to expose it.
Three Types of “Why”
I anticipate that the answers will often fall into a few broad themes.
Ambitious: the organisation is looking to capitalise on an opportunity or prepare for future growth. It may be entering new markets, making acquisitions or seeking a platform that can scale with its ambitions.
Defensive: the organisation needs to reduce risk or respond to changing requirements. Its existing systems may be ageing, approaching end of support, difficult to secure or increasingly dependent on a small number of people who understand how they work.
Transformational: the organisation wants to operate differently. It may want more efficient processes, greater standardisation, better reporting and information to support decision-making, or a fundamentally different way of working.
Most ERP projects contain elements of all three. The point is not to assign the project to a category, but to agree which outcomes matter most.
That distinction becomes important later. If growth is the primary objective, scalability and speed may carry more weight in the selection. If risk reduction is the driver, resilience and supportability may matter more. If transformation is the goal, the organisation may need to be more explicit about the processes and behaviours it is prepared to change. The agreed “why” should guide these decisions, not simply justify a decision that has already been made.
Making the "Why" Practical
Leadership should define the “why”: the outcomes the organisation is seeking and why it is prepared to make the investment and absorb the disruption required to achieve them.
This is what makes ERP a business project, not simply an IT project.
Technology is central to the solution, but the outcomes, trade-offs and people implications are business decisions.
The executive sponsor, project lead and relevant business and technology leaders must then translate that strategic intent into the “what” and the “how”. This means defining and testing the scope, phasing, application and data strategy, technology approach, resources, timescales and investment required.
The application landscape needs early attention. Most organisations rely on a mix of core systems, specialist applications, spreadsheets and informal workarounds. Some may sit outside formal governance, but still support important business processes. Before selection begins, the organisation should be clear about what the ERP is expected to replace, what is likely to remain, and which decisions will need to be tested through the selection process.
This is not just a judgement about whether an existing system is good or bad. Retaining it may protect valuable functionality and user adoption, but preserve complexity, integration effort and fragmented data. Replacing it may create greater standardisation, but require compromise and significant change.
Not every application decision needs to be made upfront. But the initial strategy, the open questions and the criteria for resolving them should be explicit. Independent advice and subsequent market engagement can help the organisation understand what is possible and test its assumptions, without allowing external perspectives to define the application strategy by default.
Some trade-offs will need to be escalated and resolved at leadership level. But the starting point should be a clear strategic rationale, not a project whose purpose is gradually inferred from the choices made along the way.
Creating a Clear Starting Point Before ERP Selection
Before vendor engagement begins, I would want the organisation to produce a short document that captures what it has collectively agreed about the ERP initiative.
Different organisations use different names for this. It may be a project charter or form part of a business case, Project Initiation Document (PID) or similar governance document.
This is not a detailed project plan, requirements specification or implementation design. It should be proportionate to the scale and complexity of the project: clear enough to explain why the investment is being made, what the organisation expects to achieve, what it needs to preserve, how success will be measured, the initial boundaries of scope, the main assumptions, risks and dependencies, and the early expectations for timescales, resources and investment.
The document records alignment; it does not create it. What matters most is not the document itself, but the conversation required to produce it.
Once agreed, it provides a north star for the decisions that follow, helping choices about scope, priorities, trade-offs and vendor capability remain connected to the outcomes leadership originally agreed.
The organisation is unlikely to know the full cost at this stage. Software licensing, implementation services and other external costs will vary according to the solutions considered, their commercial models, the eventual scope and the proposed delivery approach. The initial document should therefore identify the cost categories that will need to be included, record any budgetary expectations or constraints, and make clear which assumptions must be tested through the selection process.
The internal cost of the project must also be considered. ERP projects depend on the best people from across the business being available to make decisions, redesign processes, prepare data, test solutions and support adoption.
Leadership should challenge any assumption that those people can deliver the project alongside unchanged day-to-day responsibilities. The organisation may not yet know the precise capacity or backfill required because that will depend partly on the project approach and duration. The important thing at this stage is to recognise the requirement, identify the roles likely to be affected and ensure that the resulting internal costs and opportunity costs are included as the plan develops.
Wider technology investment may also be required, including infrastructure, warehouse data-collection devices, printers and other operational equipment. Again, the precise requirement may not be known before selection. It should be identified as an area to investigate rather than omitted from the investment case.
The document is not intended to create false certainty. It records the organisation’s starting position: what is agreed, what is assumed and what still needs to be tested. Relevant content can then inform the Request for Proposal (RFP), so vendors respond to the organisation’s objectives rather than defining the project through the capabilities of their proposed software.
An Independent View Can Help
An independent perspective can be particularly valuable at this stage, before the organisation has committed to a particular solution or implementation approach.
A focused leadership-alignment session can provide a structured way to challenge assumptions, surface differences and translate the agreed “why” into practical boundaries for the project and subsequent ERP selection. The purpose is not to make decisions for the organisation, but to help leadership understand the choices and make them deliberately and with confidence.
If your organisation is considering an ERP project but has not yet aligned on the case for change, talk to Goodison Advisory about a facilitated leadership-alignment session.
Comments