How to Write a Business Case for New Software [Includes Free Template]
You’re ready to invest in new software. You know the positive impact it will have on your business. You’re ready to get things moving. So what’s next?
It can be tough for decision-makers to justify the costs of a software investment without a clear understanding of the system’s merit. This is why writing a solid business case is your best bet.
In this article, you’ll learn how to build a business case for new software by identifying the benefits and costs of the solution and the return on investment. These recommendations and tips are compiled from my professional experience as an ITPMO leader, Gartner research, and best practices shared by the Project Management Institute.
Here’s a preview of the business case template provided for you. Click here to go straight to the template download.
What is a business case?
A business case is a formal document submitted to senior leadership requesting approval for a proposed project. It outlines the business problem being addressed and the proposed solution. The costs, benefits, risks, and project team are each identified.
The business case is then typically submitted for executive review and approval. The approval should serve as formal approval for budget, resource allocation, and scope agreement.
Why is it important?
Creating a business case serves multiple purposes:
Ensures alignment on the business problem and the solution.
Names the project team members and business owner.
Formalizes the budget approval; can also provide backup if the funds allocation is later questioned.
Shows that you’ve thoroughly analyzed the problem, potential solutions, and the risks to come up with the best possible solution.
Acts as the guiding light through the lifecycle of the project to keep the effort aligned with intention.
But what are the risks if you don’t submit a business case? Gartner states that goal-setting and stakeholder buy-in are two main challenges you’ll face if you don’t build a solid business case first. Let’s go over why. (Full report available to Gartner clients only.)
Misaligned goals: Without a clear business case, there may be no clearly defined and agreed-upon goals for the investment. This makes gathering requirements and selecting a vendor significantly more challenging, and could potentially result in the project stalling, or selecting a vendor that isn’t suitable.
Limited buy-in: Getting the support of stakeholders across the business may be challenging to get without sharing a robust case for doing so. It’s also possible that opposition to the investment could arise months after implementation, when stakeholders challenge you to justify the ongoing costs. This will be hard to do without an existing business case that includes a measure of the success/impact of the new software.
Before going through the steps on how to write a business case, let’s look at this video to understand the contents of a business case.
Step 1: Build the pieces of your business case
When constructing a business case for new software, it’s important to lay out the full scope of the project so leadership can feel confident that you’ve considered the full impact of your proposal. This is especially important when asking for the amount of money the new software will require for implementation and ongoing expenses.
Be sure your argument includes the following elements (we’ll follow the structure in the template provided below):
Executive summary: Provide an overview of the goals of the new software selection and implementation. Don’t forget to state that you want to buy new software—this may seem obvious, but sometimes that can get muddled after you’ve worked and reworked the wording of this section.
Be sure to answer questions such as:
What is the business problem this will solve?
Why do we need to solve this problem now?
Are there changes to rules or regulations that are making this investment mandatory?
And, include highlights of the business problems that will be solved with the new software.
Cost savings (e.g., software will reduce headcount/hours spent on manual tasks, reduction in costly errors).
Revenue enhancement (e.g., increase workflow speed, integrate with partner systems).
Notice that we’re not naming a specific software program in this section and that’s intentional. This is because you need to solve the business problem. Not just buy software.
Oftentimes the project manager or a department head is tasked with implementing a specific tool. For example, if your lead accountant used one program at their previous company, they could request that you invest in the same software. So the project would become, “let’s buy X software” as opposed to a more thoughtful approach such as, “we’ve outgrown our current accounting process and need a robust program to help us scale.”
Solution description: Describe how you plan to use software to solve business problems and/or achieve your goals. Outline what you’ll be able to do that you can’t do now and what requirements the tool should have to support your team or department’s ability to solve their problems and/or accomplish their goals.
In this section, you can also include the justification for how you determined to buy new software as opposed to developing a custom solution in-house or hiring an external software development team. (This might not be relevant for your company depending on your IT environment.)
Cost overview: In the template below, implementation cost, total cost of ownership, and the return on investment calculation are the numbers highlighted. But these can be intimidating and confusing numbers to calculate. Because of this, we’ve dedicated Step 2 in this process to gathering the numbers needed in order to provide accurate and relevant calculations.
Summary of software benefits: Highlight the expected benefits and tangible gains, such as time and money saved, as well as the intangible benefits, such as increased collaboration and improved risk management protocols.
This section should focus on the business benefits as opposed to the technical benefits. Your executives will have trouble valuing the need for new software if you focus on benefits such as reducing technical debt or streamlining system architecture. But they will see the value in, for example, increasing speed and accuracy across the sales and leads process.
Tip: If you’re a very technical person (as I tend to be!), partner with a business leader to write this section.
Execution timeline: Outline the timeline for implementing the software solution. This timeline can vary significantly based on where you are in the software selection process, so be clear on what actions will be taken and when.
Additional elements you can include:
Major milestones such as the project kickoff meeting, the go-live date, and dates for training.
Cadence for team meetings, status reports, and demos.
Project governance: Name each person and their role on the project. Yes, use names, not just job titles, in order to make sure everyone is clear on the resources needed.
Free business case template
If your business doesn’t already have a business case template (and be sure to ask before starting one), we’ve created one for you. Click here to download.
Step 2: Break down the costs
As promised above in the “cost overview” component, in this section you’ll learn about the typical costs business leaders want to see in a business case. For each, we’ll show you where to get the numbers needed for the calculations.
Total implementation cost
To calculate this number, break down the costs associated with the software purchase and implementation. This includes both the obvious costs, such as the number and price of the software licenses, as well as costs that aren’t so obvious, such as new hardware and training sessions.
Tip: Lay out the number of licenses needed and what types are needed. The type of user licenses you’re purchasing can impact cost. For example, a system administrator license typically costs more than an average user, but it’s likely you need only a few of them.
Total cost of ownership (TCO)
Finding the TCO is often the starting point for calculating return on investment (ROI) and comparing vendor price quotes. This involves totaling the upfront costs for each solution, calculating the net present value of recurring costs over the expected lifespan of the tool, and then totaling the upfront costs and present value of future costs.
It’s common for businesses to only think of the initial costs of new software when evaluating vendors and risks. But there’s a considerable number of factors that need to be included when calculating the TCO.
Think of TCO as an iceberg. There’s more than meets the eye:
Source: Gartner (full content available to Gartner clients)
Other numbers you may need to factor in include the salary for any new employees required to maintain the software (e.g., IT system administrator) and recurring hardware management, if applicable (e.g., handheld scanners for a new inventory tool).
Return on investment (ROI) calculation
True ROI is often hard to measure and even harder to guarantee. You can’t know for certain how the business will grow and change over the life of a tool, and it’s possible you’ll need to add new modules or build out integrations.
Business leaders understand the gray area around this number but will expect full transparency from you. Be sure to explain that these numbers are the best projection of the expected benefits and costs of the new software that you’ve made with educated estimates.
The formula for calculating ROI is:
(gain from investment – cost of investment) / (cost of investment)
Step 3: Get stakeholder support
Writing a business case isn’t a solo task. You need partners at every step in the process to help develop the plan. Here’s some tips on getting stakeholder support:
Communicate with accounting, marketing, and other department leaders before submitting the business case so they are at least aware of the initiative. Key leaders in other areas of the business will help identify your blind spots and can offer solutions.
Get agreement from all contributors on what is outlined in the document. Each person named in the document should see the final draft before it goes for executive review—no one wants their name assigned to work that they’re unaware of.
Don’t think of the presentation of the business case as an unveiling. Instead, whoever you’re getting approval from should be familiar with your proposal before the big meeting. Best case would be for the actual meeting to get approval is just a formality. The major details, such as the cost and type of software and high-level benefits, should all be previously understood by everyone in the meeting. To accomplish this, you’ll likely have to swing by their office or ask to go to lunch to discuss the proposal in the weeks leading up to your presentation.
What if your business case is rejected?
Rejection is a possibility and it’s important to be mentally prepared for this. Fellow PMPs Elizabeth Larson and Richard Larson share some of the best advice for rejection that I’ve come across. Here’s an excerpt from a paper Elizabeth shared at a PMI Global Conference.
Remember that we are advising the organization with our well-thought-out recommendation. Don’t take rejection personally. If your business case is rejected, ask:
Did I work closely with the business owner to develop the business case?
Do I understand the “objections?”
Can I address them to meet stakeholder needs? If I can, the final product will be even better.
Have I given stakeholders enough time to think about the proposal before asking for a decision?
How can I best support the business owner? Should I advise the business owner to walk away (at least for now), or, do we act like a pit bull that grabs on to a leg and won’t let go?
I feel more empowered and resilient just reading her advice again—hopefully you do, too!
Work through these questions and re-evaluate your proposal. Ask to re-submit your proposal at an agreed-upon time in the near future, involve more partners, and then strengthen your business case.
Next steps: Resources for comparing and evaluating software solutions
Now that you know how to write a strong business case, here are a few next steps you should take to help you compare and evaluate solutions:
Read user reviews: No matter what type of software you’re looking for, Software Advice has tons of user reviews for it. See how your peers have rated systems for qualities such as ease of use and customer support.
Schedule product demos: Discuss your needs with vendors and ask for “day-in-the-life” product demos rather than a reel of feature highlights. For more tips, check out this article on "How to Cut Through the Sales Pitch in Software Demos."
Download the free template: If your company doesn’t already have a business case template, we’ve made one for you. Click to download it now.