Building your business case for new technology: Why your business case sucks 

You have identified a problem: you know your HR or payroll technology is creating unnecessary work. Your team is dealing with manual processes, spreadsheets, workarounds, errors or reporting that takes far longer than it should. You have seen the frustrations first-hand, and you know something needs to change. 

So you have done the work. You have researched the options, found what you think is a great solution and written it all up in a business case. You have explained what the technology could do, outlined the benefits and set out why you think the investment is needed. 

But then… nothing. 

Instead of the enthusiastic response you were expecting, you get a lukewarm reaction. Perhaps someone suggests putting it off until next year. Maybe you are asked whether the problem is really significant enough to justify the investment. Or perhaps the business simply does not seem to share your sense of urgency. You are left wondering what went wrong. You know there is a genuine problem, and you have put the work into finding a solution. So why is your business case not getting the response you expected? 

Well, it might not be what you are saying, but be how you are saying it. A strong business case for new technology is not just about explaining why your team needs a better system. It is about showing why the problem matters to the organisation and giving the people approving the investment a reason to act. 

That means acknowledging the problems your HR and payroll team are experiencing, but learning to translate those problems into the language of the wider business. 

You know exactly what the problem feels like. They do not. 

From your perspective, the problem is probably obvious. You know how many spreadsheets your team relies on. You know how much time is spent checking data, correcting errors and finding workarounds. You know which processes are clunky and which reports are painful to produce. 

You may also be dealing with the less visible consequences: a team that is spending too much time on administration, employees getting frustrated with processes, managers struggling to get the information they need or increasing concerns around accuracy and compliance. 

The difficulty is that the people approving your investment probably do not experience those problems in the same way. To them, “we spend too much time on manual processes” can sound like an operational inconvenience. To your team, it might be one of the biggest frustrations of the working week. 

That is why simply describing the problem is not enough. Your business case needs to connect the day-to-day frustration to its wider organisational impact. For example, instead of simply saying that your HR team spends too much time on manual administration, explain what that means for the organisation. Is valuable HR capacity being used for repetitive work instead of more strategic activity? Is the workload becoming harder to manage as the organisation grows? Are leaders unable to access the workforce information they need quickly enough to make decisions? 

Instead of saying that reporting is difficult, explain the consequence. The problem has not changed. You are simply making its significance clearer to the people who need to understand why solving it matters. 

Stop making the case for the system. Start making the case for change. 

This is one of the biggest shifts you can make when building a business case for HR technology. It is natural to focus on the technology. You have found a system that can solve your problems, so you want to explain what it can do. 

But your decision-makers are not necessarily asking, “What can this software do?” They are more likely to be asking, “Why should we spend this money?” That means the technology should come later in the story. 

Start with what is happening now. Explain why it is creating a problem for the organisation. Show what happens if the current situation continues. Then explain how the proposed technology could help address it. 

For example, “we need a new payroll system because our current system is outdated” is very different from explaining that the existing system requires increasingly manual intervention, creates additional workload for the payroll team and limits the organisation’s ability to improve processes as it grows. 

The second version gives your audience a reason to care before you start talking about the solution. 

Translate your team’s frustrations into business problems 

Your team’s frustrations are important. In fact, they are often where the business case begins. But frustration on its own is not always enough to secure investment. The important thing is to show what those frustrations mean beyond your own team. 

This does not mean dressing up problems to make them sound more serious than they are. It means putting them into context. The same principle applies when you describe the benefits of your proposed solution. 

Your benefits need to answer the question: “So what?” 

A business case can contain all the right benefits and still fail to convince people. “Save time” sounds good, “Improve employee experience” sounds good, “Reduce risk” sounds good, but a decision-maker is likely to ask what those statements actually mean. 

How much time could be saved? Where would that capacity go? What would improve for employees? What risk exists today, and how would the proposed technology reduce it? 

This is particularly important when thinking about HR technology ROI. Not every benefit will translate neatly into a financial figure, and you should not force it to. Improved accuracy, better employee experience, easier reporting or reduced operational risk can all be valuable. What matters is being specific enough to show why the benefit matters to the organisation and to the person reading your business case. 

Think about it from their perspective. If you are asking Finance to approve an investment, they may want to understand the cost implications and expected return. If you are speaking to IT, they may be more concerned with integration, compatibility and ongoing support. If you are speaking to senior leadership, the organisational impact and connection to wider priorities may matter more. 

You do not need to write a different business case for every audience. But you do need to anticipate the questions different stakeholders are likely to ask and make sure your case addresses them. 

Don’t just explain what change will give you. Explain what staying the same will cost. 

There is a tendency to focus heavily on the benefits of investing in new technology while giving very little attention to what happens if the organisation decides not to invest. That can make delaying the decision feel like the easiest option. If the current system is frustrating but ultimately manageable, why spend the money now? This is where the cost of doing nothing becomes important. 

Perhaps the manual workload will continue to grow. Perhaps the organisation is expanding and existing processes will become increasingly difficult to manage. Perhaps reporting limitations will continue to slow decision-making. Perhaps the current technology will continue to require workarounds or create avoidable risks. 

You do not need to make dramatic claims or suggest that everything will fall apart without a new system. You simply need to make the consequences of maintaining the status quo visible. 

The decision is not simply between buying new technology and spending nothing. It is between changing the current situation and continuing with it. Both options have consequences. 

Your business case should not pretend that change will be painless 

If you have ever been involved in a technology implementation, you will know that new technology comes with its own challenges. 

There will be costs. There will be implementation work. People will need to learn new processes. Data may need to be migrated. Integrations may need to be developed or changed. Your internal teams will need to contribute time. Trying to hide these things from your business case can actually make it less convincing. 

The people reviewing the investment already know that change comes with challenges. If your proposal makes everything sound effortless, they may start wondering what you have missed. Instead, acknowledge the awkward bits. 

Show that you have considered implementation, training, data migration, change management, integrations and ongoing costs. You do not need to have every risk completely resolved before you ask for approval, but demonstrating that you have thought about them gives decision-makers greater confidence in the proposal. A realistic business case is often more persuasive than a perfect one. 

Give them evidence, not just your professional opinion 

You know your processes. You may have spent years working with them. You probably have a very good understanding of where the problems are. But when you are asking for significant HR software investment, “trust me, this is a problem” is unlikely to be enough. 

Use the information you already have. How much time is being spent on manual processes? How many corrections are required? How long does it take to produce particular reports? What does the current process cost? How often do employees or managers raise issues? 

You do not need to turn every benefit into a complicated financial calculation. Some of the most important evidence may be qualitative. The aim is to show that your recommendation is based on evidence rather than personal preference. 

You do not need to pretend you have all the answers. You do need to show that you have done your homework. 

Make your recommendation feel like the conclusion, not the starting point 

There is one final shift in perspective that can make a big difference. If your business case reads as though you have already decided which system you want and are now looking for approval, decision-makers may naturally question whether you have considered the alternatives. 

You may genuinely believe that a particular system is the right answer. But your business case will be stronger if the recommendation feels like the logical conclusion of the evidence you have presented. 

Depending on the problem, you might consider whether there is scope to improve the technology you already have, add functionality or integrations, outsource part of the process or invest in new technology. 

The point is not that you must investigate every possible option. It is about demonstrating that you have considered the realistic choices and can explain why your recommendation makes sense for your organisation. When the recommendation comes after the evidence, rather than before it, your business case feels less like a request for approval and more like a reasoned decision. 

If you are trying to work out whether your current systems need replacing or improving, our guide to choosing integrated HR and payroll software covers some of the key considerations. 

So, does your business case actually suck? 

Probably not. 

You may have identified a genuine problem and found a sensible solution. The issue could simply be that you are explaining it from the perspective of the people experiencing the problem rather than the people responsible for approving the change. 

Before you send your business case back into the approval process, ask yourself: 

• Would someone outside HR or payroll understand why this is a business problem?  
• Have I explained what the organisation gains from solving it?  
• Have I explained what happens if we do nothing?  
• Are the benefits specific, realistic and relevant to my audience?  
• Have I supported important claims with evidence?  
• Have I been honest about costs, risks and implementation?  
• Have I considered realistic alternatives?  
• Does my recommendation feel like the conclusion of the evidence?  

If you can answer those questions confidently, you have moved beyond simply asking the business to buy new technology. You are giving it a reason to support the change.

In conclusion 

You are not wrong to be frustrated when you have identified a genuine HR or payroll technology problem, developed what you believe is a strong solution and still received a lukewarm response. 

The problem may not be your solution. It may not even be your business case. It may simply be the way you are framing the conversation. Your HR or payroll team already understands why change is needed because you are the people living with the problem.  

The challenge is helping everyone else understand why it matters to them too. When you can translate your team’s frustrations into business consequences, demonstrate the cost of doing nothing, support your claims with evidence and show that you have considered the realities of implementation, your business case becomes about more than buying new technology. You are making a case for why the organisation should change. 

For more information about check out our article on building a business case for HR or payroll system investment or read our guide on the 12 Steps to People Technology Success.