Building a business case for a major project can be hard (and unfamiliar) work. If it’s your first experience with the process, it can even seem kind of unfair – like finding a batch of calculus problems on an algebra test. It can be hard to make the transition from planning a major project like an SAP S/4HANA migration, that seems to be essential or obviously required, to working out how to pay for it. How can you be expected to have so much data about other functions in your company?
The problem isn’t so much with the business case process itself, as it is with our (general) lack of education and understanding about the process. Building a good business case should be an integral part of almost every project. Understanding the business case approval process should be an early step in developing the project itself, because it ensures that you’ll be able to answer the question “why should this project be approved?” Your project will generally compete against other deserving projects, and your company’s finance and management team will almost always demand to know what the payback will be for any major project. It only makes sense to try to get it right the first time.
My last article ( https://www.ibm.com/blogs/insights-on-business/electronics/four-principles-for-building-your-s-4hana-business-case/ ) provided four principles for preparing a winning business case. In this note, I’d like to cover some of the ways the process can go sideways. The problems are almost always in the assumptions – and in most cases, the flaws are in the unstated assumptions.
You can avoid some faulty approaches simply by making sure you have a good understanding of your organization’s performance versus industry benchmarks. To illustrate, let’s consider three companies in the same industry: Acme, Baker, and Consolidated. They’re all roughly the same size; they’re all profitable; and they are all planning to implement the same new ERP package. Their performance varies in different areas.
Let’s say that the ERP provider has indicated that “on average, companies that implement our package see a 20% reduction in inventory.” First, let’s look at what the effect of a 20% inventory reduction would be at the three companies:
||Current Inventory Turns
||Current Inventory Value
||Cash Flow Value of a 20% reduction
At first glance, this all looks fine… but it isn’t. The unstated assumption of the calculation above is that the average improvement observed by the ERP software provider will be valid for a specific company. Let’s add one more piece of data: the average inventory turns for their industry is 6. Baker is performing at the industry average; Consolidated is outperforming the industry – at double the average turns for the industry; and Acme is underperforming. If the data from the ERP provider was actually based on companies with similar characteristics to their industry (another unstated assumption), then Baker can quite possibly look forward to achieving that $40M cash flow. What about Acme? They ought to be able to achieve much more than a 20% reduction in inventory. Maybe they can move close to the industry average (a $100M drop in inventory) or achieve close to Baker’s potential performance (which would represent a total of $140M in potential cash flow). But Consolidated is already outperforming the industry average – they may even be leading the industry in inventory performance. They shouldn’t even count on the $20M reduction that they calculated – at least, not without a thorough understanding of how other companies used the ERP software to reduce their inventory levels. To summarize:
Flawed Approach #1: The “Average Improvement” Fallacy. Don’t assume that your company’s benefits will be equal to the average achieved by a group of other companies. You need to understand where your company’s performance falls in relation to benchmark performance in your industry.
Let’s go back to our three companies and look at another metric: their customer service staffing. These are the people who process customer orders so that the company can ship and invoice their customers. The ERP software provider has indicated that their customer service process requires 10% less labor than before – not based on average improvement, but because the process is more efficient.
In this case, the three companies have roughly equivalent performance (number of order lines processed per staff member) but there is a substantial difference in activity level and cost:
||Customer Service Staffing
||# of Order Lines processed/year
||Cost of Customer Service Staffing
||Value of a 10% reduction
||$3M (avg $60K/FTE)
||$4.5M (avg $60K/FTE)
||$3M (avg $20K/FTE)
Can any of these companies simply apply the 10% figure to their current customer service costs and assume that they will achieve that benefit? Not without a deeper understanding of the process and the constraints under which it operates. For instance:
- Is an efficiency improvement in this process meaningful? Acme may have already built automation in their current process that accomplishes the same benefit as the efficiency improvement in the ERP software. That would translate to zero net improvement.
- Is the labor cost variable? Baker’s customer service organization may be salaried and overworked. A 10% reduction in effort won’t yield a 10% reduction in staff – it will just let the staff go home a bit closer to their theoretical regular end of shift. (Local labor laws may have an effect on this.)
- Where (in what part of the process) has the software provider made the customer service process more efficient? Consolidated may not even be using that part of the process. Or – more commonly – the improvement may only apply to 20% of their activity. So the 10% reduction may be real, but it will only generate a 2% improvement overall for Consolidated.
On the other hand, it’s also possible that some companies may see a much larger benefit from this improvement. That improved efficiency may reside in the core of the process used by Acme and could result in a 20% reduction in staffing. And it may solve a problem that causes rework for Consolidated due to lower-skilled staff… again, with the potential for a bigger benefit than just 10%. Thus, the second fallacy to watch out for:
Flawed Approach #2: The “small percentage of a huge number” Fallacy. Don’t assume that a small improvement will automatically apply uniformly to an activity that is done in very large volumes across your organization. It may not apply at all, or it may apply to only a portion of those large volumes. You need to understand the mechanism by which the benefit is produced, and confirm that that mechanism will be effective for your organization’s activity.
Did you notice that Consolidated’s staffing cost (per FTE) was a third of the other two companies’ costs? They were operating in a low-cost environment. What would happen if you were to bring a business case forward at Baker that (validly) assumed a 10% reduction in customer service cost (about $0.45M), but the company was already planning to move their customer service operations to a similar low-cost environment? They’d save $3M by doing that. Chances are good that your $0.45M benefit will be dismissed in light of those plans. That becomes the third fallacy to watch for:
Flawed Approach #3: The “everlasting benefit” Fallacy. The unstated assumption here is that benefits will continue indefinitely. Some benefits do last for years, but watch out for benefits that require the continuation of a situation that could change. It could be a cost or an entire process that is going away or can be worked around. It isn’t always an internal problem, either. I worked on a project in the early 2000s that was justified on the basis of capturing cost savings on components purchased by my company’s manufacturing partner. We were supposed to get a rebate from the component manufacturer for everything that the manufacturing partner purchased from them. It worked great, for about three months… until the manufacturer found a lower-cost source that locked us out of the rebate process.
A similar problem can arise from trying to extend a benefit in one part of a company to others. For example: if your division uses a high-volume continuous flow manufacturing process, you’re likely to benefit from implementing a Kanban/ pull process with your suppliers (perhaps using a 3PL-managed inbound ‘hub’). That will let you reduce the size of your on-site warehouse and reduce inventory levels. Thus, you could base some benefits on the potential to implement Kanban with your suppliers using the capability in your software provider’s ERP package. But you shouldn’t expect that benefit to apply to the division that manufactures a low-volume/ high-mix product, or that uses an engineer-to-order delivery mechanism. Thus, the fourth fallacy:
Flawed Approach #4: The “Company-wide benefit from a division-level improvement” Fallacy
Finally, there can be issues that have nothing to do with a mistake in logic or application, but are simply the result of (other projects’) past failures. For example, inventory reduction may be a perfectly valid improvement opportunity at your company. Your turns may be a third below industry average, and you may be able to see a way to achieve a third above industry average (like going from Acme’s current performance level to about 8 turns, in the first example). That would produce free cash flow of $150M, and an annual benefit of around $10-20M (depending on your inventory carrying costs). But when you present your business case based on inventory reduction, you discover that five earlier projects have used inventory reduction as their cost justification, and none of them delivered the promised results. This is the fifth fallacy:
Flawed Approach #5: The “Going back to a dry well” Fallacy. Your company’s executives may be naturally suspicious of a business case based on the same promise made (and discredited by) several earlier projects. This isn’t always a ‘fatal’ flaw: sometimes if you can show them how you’ll achieve the benefits, your management team may be willing to consider a well-structured business case that includes a previously unsuccessful benefit. After all, if you dig deeper under a dry well, eventually you’ll encounter water. Frankly, though, this is a risky proposition. Including a benefit that has previously been discredited as one element among several may be acceptable, but basing your entire business case on “finally getting it right” is not a prescription for success. Note also that this may expose your project to ongoing scrutiny, which can sometimes impede overall progress.
All this goes to show that understanding the requirements – in your organization, and in the present budget cycle – for business case approval is crucial. Understanding those requirements early will help you avoid missteps. Once you’ve done that, the process is reasonably straightforward:
- Identify the areas where the project is likely to produce performance improvements.
- In those areas, understand your organization’s performance versus benchmark performance levels in your industry.
- Assess the value of the gap.
- Identify the mechanism by which you can close the gap. Discuss and reach a consensus with subject-matter experts as to how much of the gap can be closed.
- Calculate the value of the portion of the gap you agree can be closed.