The Million Dollar Question Starts With ‘WHY’

The ERP industry today is worth over $50 billion USD globally — and that number is still growing. Organizations across every sector are putting significant money into enterprise systems with the expectation of generating business value and better outcomes. But before any of that money moves, before the contracts get signed and the programme kicks off, there is a critical phase that often does not get the attention it deserves. Someone has to stand up in front of the board or the sponsor and answer a simple question: why are we doing this, and what exactly will we get from it?

That process is what we call drafting the business case.

In over 20 years of working across ERP implementations — Oracle Fusion, SAP, Dynamics 365, across financial services, professional services, the public sector and the charitable sector — I am yet to come across what I would call a proper one. Not one that gives the sponsor enough detail and honest guidance to make a fully informed decision. Not one that genuinely answers the WHY before it starts talking about the HOW and the HOW MUCH.

The word value is at the center of this problem. Value is arbitrary. It means different things to different people in the same room. The CFO hears value and thinks cost reduction. The CIO hears it and thinks process automation. The operations director thinks it means headcount. The CEO thinks it means competitive advantage. None of them are wrong. But if nobody has agreed what value means before the business case is written, the programme will chase four different outcomes simultaneously — and usually deliver none of them properly.

This is what I call the wild goose chase. The technology gets implemented. The system goes live. And twelve months later, when someone finally asks whether the investment delivered what was promised, nobody can agree on what was promised in the first place — because the business case described value in a way that was broad enough to mean everything and specific enough to mean nothing.

What Usually Happens

In my experience, the question of why we are doing this is usually triggered by one of five situations. Each one is legitimate. Each one also comes with its own version of a business case problem — because the trigger shapes the motivation, and the motivation shapes what the document is designed to do.

The First Trigger — The Legacy System is Running Out of Road

This is the most common one. The existing system is old. The vendor has announced end of life, or support costs have become significant, or the internal team that knows

how to run it is slowly retiring. The organization does not have a burning desire to transform. It has a deadline.

 

But there is a variation of this trigger that is less about the system reaching the end of its life and more about the organization losing access to the system it has been sharing with someone else. This happens more often than people realize — and it is particularly common in corporate separations, demergers, and divestitures.

I worked on one of the more interesting examples of this. Stansted Airport was divested from BAA — the owner of Heathrow — following a Competition Commission ruling that BAA had to break up its airport portfolio. Stansted was sold as a standalone business. The problem was that it had been operating on a shared Oracle R12 instance with the rest of the BAA group. The moment the divestiture completed, Stansted effectively lost its ERP system. Not because the system was failing or reaching end of life — it was working perfectly well. But because it belonged to someone else now.

The programme we were asked to deliver had a very clear philosophy: Lift and Shift. Take everything Stansted was using within the shared BAA Oracle R12 instance, carve it out, and stand it up as a clean, standalone instance. No new functionality. No process redesign. No transformation agenda. Just replicate what was there and give Stansted a system it could own and operate independently.

In some ways, a Lift and Shift business case is the most honest type there is. The objective is stated plainly — we need our own system because we can no longer use the shared one. The scope is clear. The success criteria are simple: on the day the divestiture completes, Stansted should be able to run its finance, procurement and operations without any dependency on BAA’s infrastructure. The budget is driven by the technical work required, not by a benefits model that needs to reach a particular ROI.

But here is the problem I have seen in almost every Lift and Shift programme, including this one. The moment the programme is announced, scope starts creeping in. People who have been frustrated with how the shared system was configured for years suddenly see an opportunity. Now that we are setting up our own instance, can we fix the way the chart of accounts works? Can we change the approval workflow? Can we configure the purchasing module the way we always wanted it, rather than the way BAA set it up?

All of these are reasonable requests. Each one is relatively small on its own. But collectively they turn a Lift and Shift into something much more complicated — and much more expensive — than what the business case described. The timeline was built for a clean replica. The programme is now delivering a partial redesign. The go-live date that was set by the divestiture deadline is now at risk, not because of anything the technology did wrong, but because the scope of what was being built quietly doubled while the budget and the timeline stayed the same.

The honest version of this business case for the first trigger — whether it is legacy retirement or forced separation — is straightforward: we have to move, here is what we are taking with us, here is what we are leaving behind, and here is what it will cost to make that move cleanly. That is a business case a board can evaluate properly. What boards struggle to evaluate is the hybrid — part migration, part transformation, presented as one coherent investment — because nobody has been honest about which parts are which.

The Second Trigger — Client is Acquiring a New Business or Has Been Acquired

See, this one is very interesting because the pressure here is different from any other trigger. When a company acquires another business — or gets acquired itself — the first thing that happens is someone in the boardroom starts talking about synergies. Cost synergies. Process synergies. Technology synergies. And the word that almost always follows is standardization. One system. One way of working. One version of the truth.

Now frankly, that makes complete sense. I am not arguing with the logic. The problem is what happens next.

The deal has already been structured. The investors have already been promised a number. The new parent company wants to see integration moving quickly because it shows them that things are under control. And all of that commercial pressure — every bit of it — lands directly on the ERP programme. Which now has to deliver on a timeline that was decided in a deal room by people who have never run an ERP implementation in their life.

And this is where the business case starts becoming dishonest. Not deliberately — I am not saying anyone is lying. But the timeline in the business case is driven by what the deal needs, not by what a proper ERP implementation requires. The synergy numbers that appear as benefits are sometimes the same numbers the acquirer already told its investors it would deliver. So they have to be in the business case. Not because the programme is designed to deliver them. Because they need to be there.

I have seen this many times. But let me give you a real public example because it makes the point better than anything I can describe from my own programmes.

In 2016, Revlon — the cosmetics company — acquired Elizabeth Arden. Both companies already had working ERP systems. Elizabeth Arden was on Oracle Fusion. Revlon was on Microsoft Dynamics. So actually both platforms were live and working. The sensible thing would have been to pick one of them and consolidate onto it. Job done.

But that is not what happened.

Revlon decided to implement SAP S/4HANA — a completely new platform that neither company had any experience with whatsoever. Now I can understand why on paper this looked attractive. Fresh start. Modern platform. No legacy baggage from either business. Better story for the integration. But here is the thing — neither company knew SAP. And they were a newly merged organization still figuring out how to work together. And they had an integration timeline that was not built around implementation reality.

The system went live in 2018. One manufacturing facility could not fulfil orders. $64 million worth of products could not be shipped. $53.6 million had to be spent just to fix the damage. Stock price fell. Shareholders filed class action lawsuits. The root cause when you strip everything away — unreasonably short timeline for a newly merged company implementing a platform nobody in the organization had experience with.

Mind you — the business case had approved all of this. The numbers were there. The timeline was there. The board said yes.

And that is exactly the problem.

What I have observed — and this is consistent across every acquisition programme I have seen — is that there are two things sitting in tension with each other, and the business case pretends they are not.

First thing is the commercial timeline. The deal has a structure. Investors have expectations. The parent company wants to see integration happening. That is real and you cannot ignore it.

Second thing is implementation reality. A newly merged organization has no stable operating model yet. Processes are being harmonized. People are in new roles or worried about their jobs. Leadership is still being figured out. You are asking these same people to also learn a new ERP system and change how they work every single day.

These two things are pulling in opposite directions. And a proper business case needs to say that clearly — name the tension and ask the board to make a choice. Do we push back the commercial timeline and give the programme what it actually needs? Or do we accept the commercial timeline and be honest about the risk budget that comes with it?

What it cannot do — and what most acquisition business cases do — is pretend both things are achievable at the same time. Because they are usually not. And the organization’s that find that out the hard way, like Revlon found out, pay a very heavy price for that optimism.

Frankly speaking, the ERP business case in an acquisition scenario is often not really a business case at all. It is a document that makes the investors feel comfortable that the integration is being handled. That is a very different thing. And until organizations are honest about that distinction, the pattern will keep repeating itself.

The Third Trigger — PE Backed Business Playing on Valuation

Right, so this one is a bit different and I want to be honest about it because not many people say this openly.

A private equity backed business implementing ERP is not always doing it because it genuinely needs better operations. Sometimes — and I have seen this more than once — it is doing it because ERP standardization is a story that plays well when you are heading toward an exit.

Think about it from the PE sponsor’s perspective. They have a three to five year holding period. They need to show investors that the business has been professionalized. A company that runs on Oracle Fusion or SAP S/4HANA with standardized processes across all entities looks significantly more attractive to a buyer than one running on a patchwork of legacy systems and spreadsheets. Buy-side due diligence teams actually apply valuation discounts of 0.5x to 1.5x EBITDA for companies with unauditable financials or immature ERP systems. So the ERP is not just a technology investment. It is a valuation play. 

And frankly, that is a legitimate commercial rationale. I am not saying it is wrong to think this way. PE firms are in the business of creating and realising value. If implementing ERP helps them do that, fair enough.

The problem is what this motive does to the business case.

When the primary audience for the business case is a future acquirer rather than the internal management team, the language changes. The document talks about EBITDA impact, scalability, operational maturity, clean data. These are deal room words, not operational words. The benefits are expressed in terms that resonate in a transaction, not in terms that a finance director or a procurement manager would actually measure on a day to day basis.

And what often follows is an implementation that is optimized for appearance rather than operational effectiveness. The organization goes live — sometimes with only a fraction of the functionality actually configured — because the goal was to be able to say we run on Oracle or SAP, not to extract the real value from the platform. PE firms typically evaluate three major factors when considering an ERP investment: timeline, standardization of processes, and overall benefit to the companies. But in my experience, timeline and standardization get all the attention because those are the things that show up in a due diligence report. The benefit to the company — the operational improvement, the process efficiency, the data quality — gets less focus because the people driving the programme will not be there to see it.

I have worked on programmes where the PE sponsor’s investment horizon was three years and the ERP was being implemented in year two. Everyone in the room understood what the programme was really for. The business case talked about transformation and long-term value. The actual objective was to have something credible to show a buyer in twelve months.

There is nothing inherently wrong with that. But the business case should say it clearly. What are we actually trying to achieve and by when? If the goal is exit readiness in eighteen months, design the programme around that goal and be honest about what it will and will not deliver in that timeframe. Do not write a ten-year operational improvement business case for a programme that has an eighteen-month commercial objective.

Because if you do, one of two things happens. Either the programme runs over the holding period — which is expensive and embarrassing for the PE sponsor. Or the programme goes live on time but delivers something thin — a system that is technically live but operationally half-baked — which creates exactly the kind of implementation risk that the next buyer’s due diligence team will find and use to knock the valuation down anyway.

The honest business case for a PE-backed programme names the exit horizon. It distinguishes clearly between what will be delivered before exit and what will be picked up by the next owner. And it does not pretend that a programme being run to a PE timeline is the same thing as a programme being run to deliver genuine operational transformation.

The Fourth Trigger — The Original Programme Did Not Go Well

Okay so this one is the most uncomfortable one to write a business case for. And I say that from experience.

Because what you are essentially saying to your board is this — we came to you before, we asked for money, you gave it to us, the programme did not deliver what we said it would. And now we need more money to fix it.

That is a very difficult conversation. And what I have seen happen — almost every time — is that the organisation tries to avoid having it directly. Instead of saying the first programme failed and here is why, the business case gets written in a way that is slightly vague about the history. It talks about optimizing the platform, stabilizing the system, completing the implementation. What it does not say clearly is that significant money was already spent and the outcome was not acceptable.

The classic public example of this is Birmingham City Council. They had a working SAP system. They decided to replace it with Oracle Fusion. The business case was approved at £19 million. The system went live in April 2022. It experienced significant functionality and compliance issues almost immediately. By 2024 total costs had reached approximately £90 million and the council was estimating costs through 2026 could reach £216 million — more than eleven times the original estimate. The council declared bankruptcy in 2023. The Oracle Fusion implementation was named as a contributing factor. Lemon Learning

Now here is the thing. Birmingham did not set out to fail. The people who wrote that business case believed in what they were proposing. But the stabilization programme that followed — the one designed to fix what went wrong — also needed its own business case. And that business case had to answer a question the original one never had to answer: why should the board trust these numbers this time?

And this is where I see organization’s make the same mistake twice.

The stabilization business case looks very similar to the original one. Same kind of benefit assumptions. Same kind of cost estimates. Same kind of optimistic timeline. But what is missing is the one thing that would actually give the board confidence — a clear, honest account of what went wrong the first time and specifically how the new programme is designed to avoid those same problems.

If the first programme failed because the data cleanse was underestimated — show exactly how the data cleanse is being approached differently this time, with a realistic budget and timeline.

If it failed because change management was underfunded — show the change management investment that was missing before and explain why it is in the budget now.

If it failed because the organization did not have enough Oracle or SAP knowledge in-house — show what has changed on that front.

Without that analysis, the second business case is just a fresh optimism over a recent failure. And boards — rightly — are much harder to convince the second time around.

I have reviewed stabilization business cases where the honest conversation about what went wrong was nowhere in the document. The programme team was defensive about it. Nobody wanted to put it in writing. Which I completely understand on a human level. But it is exactly the wrong approach. Because the board already knows something went wrong. They approved the original business case. They have been watching the programme struggle. Pretending it did not happen does not make them more confident. It makes them wonder what else is being glossed over.

The one thing I would say to anyone writing a stabilization business case is this. Be the first person in the room to say clearly what failed and why. Do not wait for the board to ask. Put it in the document. Show that you understand the root cause. Show what is different this time. That is the only way to rebuild the credibility that the first programme damaged.

Hiding the failure does not make it go away. It just makes the second programme harder to govern.

 

The Fifth Trigger — Client is on a Growth Spree and the Systems Cannot Keep Up

This one on the surface feels like the most positive trigger of the five. The business is growing. New markets, new geographies, new products, more customers, more transactions. Things are going well. The existing systems were built for a business a third of the size and they are starting to show the strain. So the decision to implement a new ERP feels like a natural, logical next step.

And because the rationale is so obviously sound, the business case often does not get the scrutiny it deserves. Of course we need better systems. We are doubling in size. What else do we need to say?

Quite a lot, actually.

The problem with growth-driven ERP programmes is that the business you are implementing for is a moving target. The volume assumptions you put in the business case at month one may be completely different from the reality by go-live. The processes you are standardizing in the new system today may not be the right processes for the larger, more complex organisation you will be in two years. And the people who are supposed to adopt the new system are simultaneously dealing with the operational demands of a business that is growing fast — which means they have less time, not more, to learn something new

I want to give you a real example. In 2000 Nike was in the middle of aggressive global expansion. They committed approximately $400 million to a major ERP and supply chain transformation. The goal was to modernize, support global growth, improve demand forecasting. A completely legitimate growth-driven rationale. The critical mistake was deploying the i2 Technology demand-planning software alongside the existing legacy ERP rather than integrating it properly with the incoming SAP platform. The two systems operated with different data formats and business rules. The system began generating inaccurate demand signals — over-ordering some products and under-ordering others. The result was $100 million in lost sales and a stock price that fell approximately 20%.

Now to be fair, Nike eventually recovered and completed the full SAP implementation in 2004. But full recovery from the Nike i2 failure required roughly seven additional years and an estimated $500 million in further investment. The total cost of the failed first attempt dwarfed the original project budget.

The lesson here is not that growth-driven ERP is a bad idea. Cadbury went through the same challenge — rapid growth was straining their production and distribution — and they implemented SAP successfully by taking the supply chain redesign seriously and not rushing it. The difference between Nike and Cadbury is not the growth context. It is the quality of integration planning and the respect for implementation complexity.

A growth-driven business case has to answer one specific question that most of them avoid: are we implementing an ERP for the business we are today or the business we will be in three years?

If it is for today’s business, there is a real risk that by the time you go live the system is already slightly too small for what the organisation has become. You will be back at the board asking for more money to extend it before you have even finished stabilizing the first implementation.

If it is for the future business — the one you expect to be in three years — the implementation is more complex, more expensive, and takes longer. Because you are building for processes and volumes and geographies that do not fully exist yet. The business case needs to reflect that honestly.

What I have seen happen too often is a business case written for the future business but with a budget and timeline built for today’s business. The ambition is big. The investment is small. Something has to give. And it is usually quality.

The honest growth-driven business case says clearly: here is the business we are building for, here is what that implementation requires, and here is the realistic cost and timeline of doing it properly. If the board cannot approve that, the conversation needs to be about scaling back the ambition — not about squeezing the same ambition into a smaller budget and hoping it works out.

Because in a fast-growing business, a failed or half-delivered ERP is not just an IT problem. It is an operational problem that lands right in the middle of the growth itself. The very thing the ERP was supposed to support.

Chapter 2 — The Five Pillars of Benefits Realization

Before I talk about what a proper business case looks like, I want to introduce a framework that I have found genuinely useful over the years. It comes from a book called Achieving Business Value from Technology by Tony Murphy, who worked in Gartner’s consulting and measurement practice. He calls it the Five Pillars of Benefits Realisation.

The idea is straightforward. Any technology investment — including an ERP — should be able to answer five fundamental questions before the board approves the money. In my experience, most ERP business cases answer one of these properly. The other four are either missing, vague, or somebody’s problem to deal with later.

Let me go through each one and show you what happens when they are ignored.

Pillar One — Strategic Alignment

Will this investment actually help us achieve our strategic goals?

This sounds like the most obvious question in the world. Of course the ERP aligns to our strategy. Why else would we be doing it?

But here is the problem. Strategy in most organisations is a set of broad statements that everyone has agreed to and nobody has translated into specific, measurable targets. Digital transformation. Operational excellence. Single source of truth. These phrases appear in hundreds of ERP business cases as strategic drivers. And they are basically meaningless without a number attached to them.

 

I have reviewed business cases where the strategic alignment section listed five or six strategic objectives — all completely legitimate — and not one of them had a specific target the ERP was expected to contribute to. The alignment was decorative. It was there to make the document look credible, not to create accountability.

Research backs this up. Studies in ERP implementation show that organization’s lacking a clearly defined strategic plan before they start underperform on their expected outcomes the vast majority of the time. The research identifies leadership commitment and comprehensive change management as fundamental to ERP success, noting that organization’s lacking a strategic plan underperform 90% of the time.

The honest question to ask is this. If you took the strategy slide out of the business case and asked the business unit heads separately what the company’s top three priorities are — would the ERP investment appear in any of them? If the answer is not clearly yes, the strategic alignment in the business case is there for show

Pillar Two — Business Process Impact

What is the impact on our ability to actually change our business processes?

This is where most ERP business cases are the weakest. And ironically, it is where most of the value is supposed to come from.

The business case describes the future state beautifully. Streamlined processes. Standardized ways of working. Automated workflows. Clean data. It all looks very compelling on a slide. What it almost never shows is the journey from where the organization is today to that future state. Who will work differently? What will they have to give up? Where is the resistance going to come from?

The Lidl case is the most instructive public example of what happens when this pillar is ignored. Lidl implemented SAP for seven years and spent approximately $580 million. The core issue was a process decision — Lidl valued its inventory at purchase price, SAP worked on retail price. Rather than accepting the process change that the system required, Lidl spent seven years trying to force SAP to replicate how they had always worked. The Lidl case is a direct illustration of a critical failure factor: treating an ERP implementation as a software configuration exercise rather than an organizational change programme.

After all that time and money, they abandoned the whole thing and went back to their original system.

The lesson is painful and simple. When an organisation refuses to accept that implementing a new ERP means changing how it works, the implementation will fail. The system will be configured around the old way of working, and the old way of working will never produce the new outcomes. Every pound spent on customization to preserve a legacy process is a pound not spent on changing the process.

A proper business case for this pillar does not just describe the future state. It names the specific processes that will change, identifies who is affected, and — crucially — shows that the people responsible for those processes have actually agreed to operate differently. Not just been told about it. Actually agreed to it.

Pillar Three — Architecture

What is the real impact on our IT architecture and the systems around the ERP?

This is the pillar that always gets the least rigorous treatment. The business case shows a diagram — new ERP in the middle, arrows pointing to other systems, everything looking clean and connected. What it does not show is the real complexity underneath.

How many legacy systems are staying on after go-live? How many interfaces need to be built and maintained? What happens to the data sitting in systems that are being retired? Every interface between the ERP and another system is its own small project.

Every piece of customization built into the ERP is a maintenance cost that compounds every time the system is upgraded.

The Zimmer Biomet case — which I want to spend some time on because it is very recent and very instructive — illustrates this pillar clearly. Zimmer Biomet is a global medical device manufacturer. They engaged Deloitte to implement SAP S/4HANA with the goal of consolidating nine separate legacy ERP systems across North America and Latin America. The implementation was projected to deliver $197 to $316 million in benefits over ten years through inventory reduction and operational efficiency improvements

Nine legacy ERP systems. Each one with its own data model, its own processes, its own integrations. Consolidating nine systems into one is not an ERP implementation. It is nine ERP migrations happening simultaneously. The architecture complexity alone should have driven a very different conversation about timeline, budget, and risk.

The business case needs to show the architecture honestly — not as a diagram with arrows but as a real assessment of what it takes to connect, migrate and retire everything that the new system is replacing.

Pillar Four — Risk

What are the real risks — and what do they actually cost if they materialize?

The risk section of most ERP business cases is the one nobody reads properly. It has a table with risks listed, each one rated medium probability and medium impact, each one with a mitigation that sounds sensible but is never costed. The financial exposure is not shown. The board approves the business case and moves on.

And then reality arrives.

Let me stay with Zimmer Biomet. After three previous delays the system went live on the 4th of July 2024 — a public holiday in the United States. Court filings suggest that readiness concerns existed before the go-live, yet the company proceeded. Zimmer Biomet alleges that Deloitte pushed for go-live despite system unreadiness

The consequences were severe. Order fulfilment collapsed. Shipments could not be processed. Invoicing broke down. The company’s revenue dropped by 43% in the period following go-live. Once the company announced the problems, it lost $2 billion in market capitalization. Zimmer Biomet filed a lawsuit against Deloitte seeking $172 million in damages

And if that was not enough, this programme was running alongside a global restructuring that included a 3% workforce reduction and a CEO transition. Pairing layoffs, leadership transition, and a pending ERP cutover created a governance environment where attention was fragmented and the bias to just get it live was likely amplified

This is what happens when risk is managed as a register on a slide rather than as a genuine financial exposure. The risk of going live on a holiday weekend with known readiness concerns while simultaneously restructuring the business — that risk existed. It was visible. The business case should have quantified it and forced a decision about whether to accept it.

A proper risk section does not rate everything as medium. It shows a realistic worst-case scenario with a number attached. And it asks the board explicitly: can we absorb this outcome if the worst case happens?

In Zimmer Biomet’s case the worst case was $2 billion in market cap and a $172 million lawsuit. That number was never in the business case.

Pillar Five — Direct Payback

Will this investment actually deliver more revenue, cost savings, or better management information?

This is the pillar that gets all the attention. The ROI. The payback period. The net present value. The cost savings. In most ERP business cases this section is the most polished, the most detailed, and the most confidently presented.

It is also, in my experience, the most unreliable.

The reason goes back to something I said at the start of this essay. The ROI in most business cases is not the output of rigorous analysis. It is the input. Someone decides what number is needed to get the board to approve the investment, and then builds the rest of the document backwards from that number.

Zimmer Biomet projected benefits of $197 to $316 million over ten years. The actual outcome: $75 million in lost revenue, a $2 billion loss in market capitalization, and a $172 million lawsuit against the implementation partner. The system went live on July 4, 2024 after several postponements. Following go-live, the organization reported difficulties with core business processes including order fulfilment, shipment processing, invoicing and basic sales reporting

The projected benefit and the actual outcome were not just different in degree. They were opposite in direction.

Now I am not saying the $197 to $316 million benefit was invented. At the time it was probably a reasonable projection based on reasonable assumptions. But the

assumptions about architecture readiness, process alignment, risk and strategic timing — the other four pillars — were not properly tested. So the benefit calculation was built on foundations that turned out to be wrong.

This is the fundamental problem with Pillar Five when it is treated as the starting point rather than the conclusion. The ROI number is only as reliable as the four pillars underneath it. If Strategic Alignment is vague, if Business Process Impact is not planned, if Architecture complexity is underestimated, and if Risk is not properly quantified — the benefit number is fiction dressed up as analysis.

The board sees a compelling ROI and approves the investment. What they are actually approving is a set of optimistic assumptions that nobody has tested.

That is the pattern I have seen repeated across twenty years and more implementations than I can count. And it will keep repeating until organization’s treat the business case as the beginning of a rigorous conversation — not as a document designed to reach a predetermined conclusion.

The Closing — What a Proper Business Case Actually Looks Like

So what does a good one look like?

After everything I have described — the five triggers, the five pillars, the case studies, the patterns — the question I get asked most often is: okay, so what does a proper ERP business case actually look like?

Let me try to answer that as simply as I can.

A proper ERP business case is not a longer version of a bad one. It is a fundamentally different document. It is honest about why the investment is being made, realistic about what it will cost, specific about what it will deliver, and clear about who is responsible for delivering it.

That sounds simple. In practice it requires a different mindset from everyone involved.

It starts with the real WHY — not the polished version

The first thing a proper business case does is name the real trigger honestly. As I described earlier, every ERP programme starts for a reason. Legacy retirement. Acquisition integration. PE valuation. Stabilization. Growth. Each of these has a different shape, a different risk profile, and a different set of honest things to say to the board.

A proper business case names the real reason clearly. It does not dress a migration up as a transformation. It does not present a PE exit play as a long-term operational improvement programme. It does not hide a failed first attempt behind aspirational language about optimization.

The board can handle the truth. What they struggle with — as we have seen in Birmingham, in Zimmer Biomet, in Revlon — is discovering two or three years in that the programme they approved was not quite what they were told it was.

It answers all five pillars — not just the financial one

Every business case I would consider proper goes through all five pillars with genuine rigor.

Strategic Alignment — with specific, measurable goals that connect to what the organization has already committed to. Not digital transformation. Not operational excellence. A number. A target. Something you can check twelve months after go-live.

Business Process Impact — with a process-level analysis of what will change, who is affected, and documented evidence that the people responsible for those processes have committed to working differently. Not just been told about it. Actually committed.

Architecture — with a real picture of the current landscape, what is being replaced, what is staying, how many interfaces need to be built, and what the upgrade path looks like in three to five years.

Risk — with a realistic range of outcomes. Best case, expected case, worst case — with a financial figure attached to the worst case. And an explicit question to the board: can we absorb this if things go wrong?

Direct Payback — as the output of the analysis, not the input to it. The ROI should be the last thing written in the business case, not the first. It should flow from everything above it.

It has named owners for every benefit

This is the thing that separates a real business case from a document that looks like one.

Every benefit listed should have a named person responsible for delivering it. Not a department. Not a workstream. A person. With a title. Who was in the room when the benefit was agreed and who understood that their name would appear against it in the document.

A benefit without a named owner is an aspiration. I have never seen an aspiration spontaneously turn into a result.

Along with the named owner, there should be a baseline — what does this metric look like today? — and a measurement date — when exactly will we check whether the benefit has been delivered, and who will do the checking?

If these three things — owner, baseline, measurement date — are not in the business case for every benefit, the benefits section is decoration.

It lives beyond the board approval

This is the thing most organizations completely forget.

The business case should not be filed away the day the board approves the investment. It should be a living document. Updated as the programme progresses. Formally reviewed at significant milestones — design sign-off, go-live, three months post go-live, twelve months post go-live.

And at the end of the programme there should be a post-implementation review — a formal, honest comparison of what the business case promised against what was actually delivered. Not an internal exercise designed to show the programme in the best possible light. A genuine assessment.

In my experience this review happens in fewer than one in five ERP implementations. It should be a standard requirement. Not optional. Not something to be arranged after go-live if time allows. A committed date in the business case before the contract is even signed.

Because if the business case is the document that justified the investment, the post-implementation review is the document that tells you whether the investment was worth it. Without it, you are flying blind — and you will make the same mistakes in the next programme.

A final thought

I started this essay by saying the million dollar question starts with WHY. Having gone through everything above, I want to end with a slightly different version of that.

The WHY is important. Understanding the real trigger, being honest about it, building the business case around it — all of that matters. But what I have seen in twenty years of ERP programmes is that the WHY is only the beginning of the conversation. The real test of a business case is not whether it convincingly answers why we are doing this. It is whether it honestly answers what we are prepared to do to make sure it works.

What are we prepared to invest in data quality before go-live? What are we prepared to change about how our processes work? What level of risk are we genuinely prepared to absorb? What benefits are we genuinely prepared to be held accountable for?

A proper ERP business case does not just tell the board what the investment will deliver. It tells the board what the organisation is committing to do — in terms of behaviour, resources, and accountability — to make that delivery happen.

Because here is the truth that every experienced ERP practitioner knows and not enough business cases say clearly: the technology will do what you ask it to do. Oracle Fusion is a capable platform. SAP S/4HANA is a capable platform. Workday is a capable platform. They have all been implemented successfully by organization’s that prepared properly, planned honestly, and stayed committed to the right things throughout.

The ones that fail are not failing because the technology let them down.

They are failing because the business case was written to get an approval — and nobody built what the approval was supposed to be the beginning of.