Most ERP programs start at Step 4. That’s Why It’s Hard.

A medium-sized construction and services company. Fourteen hundred employees. Operations across three states. Revenue growing, but the business starting to creak under its own weight.

The CFO flags that financial reporting is taking too long. The COO can’t get a clear picture of project margins until weeks after close. The CEO is preparing a board paper on technology investment.

So they hire a systems integrator. Run a selection process. Sign a contract for a new ERP.

Eighteen months later, the program is over budget, the go-live has been deferred twice, and three senior people have left the business. The system works. The business isn’t sure it got what it needed.

Nobody asks the obvious question until it’s too late: What were we actually trying to become?

The real problem wasn’t the system. It was the sequence.

What that business needed before it engaged any vendor — before it wrote a single requirement — was clarity on four things. In order.

Not as an IT project. As a business transformation.

Step 1: Self Discovery — Who are we, and what do we actually have?

This is harder than it sounds for a medium-sized enterprise, because the honest answer is often uncomfortable.

The construction company thought it had standardised project management processes across its three operating divisions. It didn’t. Each division had evolved its own way of working — different cost codes, different approval hierarchies, different ways of defining project completion. Nobody had documented this because nobody had needed to until now.

It also had fourteen years of data across three legacy systems, much of it inconsistent and some of it irreconcilable.

Self Discovery is not a technology audit. It is the business looking at itself clearly — its processes, its data, its people, its constraints, its history — before asking a system to serve it.

The SWOT here is not a strategic planning exercise. It is an honest inventory. What have we built? What actually works? What are we carrying that we shouldn’t be? Where have previous attempts at change landed, and why?

Organisations that skip this don’t know what they’re buying for. They discover it during implementation — at full cost.

Step 2: Objective — Where do we want to go, and what are we trying to achieve?

The CFO wanted faster reporting. The COO wanted margin visibility. The CEO wanted a scalable platform for growth. The board wanted ROI.

These are not the same objective.

Until they are reconciled — until the business has agreed, at executive level, on what it is actually trying to achieve and why — every downstream decision is contested. The selection criteria become a negotiation between competing priorities rather than a clear brief. The steering committee debates scope instead of steering. The program becomes a proxy war for unresolved strategic questions.

Objective-setting is not visioning. It is alignment work. Hard, specific, sometimes political alignment work that asks executives to agree on what success actually looks like — before anyone has spent a dollar on technology.

For that construction business: Is this program about operational efficiency? Geographic scalability? Margin intelligence? Acquisition readiness? The answer changes what you select, how you configure it, and what you measure at the end.

Without a written, agreed objective, you don’t have a program. You have a procurement exercise dressed as one.

Step 3: Endstate — What does the business look like when this succeeds?

This is where most medium enterprises have the least patience — and pay the highest price for skipping.

The Endstate is not a system specification. It is a picture of the business at a defined future point. What does the organisation look like? How does it operate? What can it do that it cannot do today? What is the Target Architecture — not just of the technology, but of the business itself?

A services business in this position needs to ask: In three years, what does a regional GM’s Monday morning look like? What decisions can they make that they can’t make today? What reporting reaches the board without a team of analysts behind it?

That picture — painted before selection, agreed before contracts — is what every technology decision should be tested against.

Without it, you are selecting a system for a future you haven’t defined. You are building a roadmap to a destination you haven’t agreed on. And when the program delivers something that doesn’t fit, you won’t be able to explain why — because you never said what fit would look like.

Step 4: Roadmap — The strategy and the sequence

Only here — after Self Discovery, Objective and Endstate — does a roadmap become meaningful.

Not just a project plan. A sequenced strategy. What initiatives, in what order, dependent on what, leading to the defined Endstate. This is where Portfolio, Program and Project Management discipline engages — not as an administrative function but as the mechanism that holds the transformation together across time.

The construction company had a roadmap from day one. Gantt charts. Milestones. A detailed project schedule.

What it didn’t have was the three steps that make a roadmap coherent. So the roadmap became a document that tracked activity without tracking progress toward anything agreed. Green status reports. Drifting scope. A program that looked like it was moving and wasn’t going anywhere.

The four disciplines that run across all of it

Change, Governance, Architecture, Project Management.

Not workstreams. Not phases. Disciplines — running continuously, from the first conversation to the last hypercare session, in both directions across the entire program.

Change is not a training plan. It is the ongoing work of understanding how the business will absorb what is being asked of it — and actively managing that gap. For a fourteen-hundred-person business operating across three states, change is not a communications exercise. It is a structural challenge. Who are the people this transformation depends on? What are they being asked to give up? What does adoption actually require, at each level of the organisation?

Governance is not a steering committee meeting. It is the definition of how decisions get made, at what level, with what authority, and what happens when the program surfaces a question the original brief didn’t anticipate. In a medium enterprise, governance failures are usually not about structure — they are about the executive team avoiding the hard decisions the program keeps surfacing.

Architecture is the discipline that keeps the business design and the technical design aligned as the program moves. Every significant decision in a transformation program has an architectural consequence — for data, for integration, for future capability. Someone needs to hold that picture continuously. When nobody does, the program accumulates technical debt that doesn’t show up until post-go-live.

Project Management starts at Step 1. Self Discovery is a project. Objective-setting is a project. Endstate design is a project. These phases drift and stall without structure. The discipline of managing the ground work is not less important than managing the delivery — it is more important, because the ground work is where the decisions that determine everything else get made.

What the framework is actually saying

This is not an IT methodology. It is a model for how a business navigates transformation at enterprise scale — whether the catalyst is an ERP, a restructure, a market expansion, or an acquisition.

The sequence is the point. Self Discovery before Objective. Objective before Endstate. Endstate before Roadmap. Not because it is tidy, but because each step is the foundation the next one stands on. Skip one and the ones above it are built on assumptions you haven’t tested.

The construction company didn’t fail because of its system. It didn’t fail because of its integrator. It failed because it started the visible work before it had done the invisible work — and by the time that became clear, the cost of going back was higher than the cost of pushing forward badly.

That calculus — push forward badly rather than go back and do it right — is how most transformation programs drift into outcomes nobody wanted and nobody can fully explain.

The discipline is in the sequence. The sequence starts with self-knowledge.

Everything else follows from that — or doesn’t.

SP Singh provides independent ERP oversight and advisory to WA local government and Aboriginal corporations. Founder, Bhani Consulting — bhaniconsulting.com

Customer Experience

DOWNLOAD THIS EXCLUSIVE EBOOK!

Learn why awesome Customer Experience Is Necessity?

Struggling To Win New Customers? Revealing No.1 Culprit!

Exposing Hidden Complexities Of PreSales

5 Step Process To Improve Customer Experience

You have Successfully Subscribed!

Share This