We’ve all experienced the pain of developing something—whether it be a report, system upgrade, or process—waiting a few months, then realizing no one is adopting it.
Everyone said they needed the work done.
Clearly, they didn’t.
Getting involved from the outset of a project allows you to build a business case for (or against) changes. It gives leadership concrete reasons why they should back the project. Last but not least, it gives you a preview of who will fight the change so you can determine whether their objections are reasonable or stemming from a natural resistance to change.
When you understand more about the problems an issue is causing, you can form a stronger argument to address the issue and find the best solution for your business.
We’ve all got a to-do list a mile long in Revenue Operations. So I understand that meeting with people to talk through the issue and then sitting down to crank out a multi-page document doesn’t sound appealing.
It’s not practical to create a business case for every issue. To justify the time spent on a business case, you should have a suspicion that the solution will lead to one or more of the following:
Minor tool purchases, reports, or process updates have no place in a business case document. Unless the problem is causing a significant disruption between teams, and you need an executive to settle a debate that has reached a stalemate.
In these cases, I write the document and have the opposing team review and provide feedback to make sure I’m accurately representing the issue and their stance.
The business case should be written as part of your change management process before you start working on the project. It will help you communicate critical benefits in a way that makes sense to your stakeholders and make getting buy-in much more effortless.
There are many sections in a business case, but some can be one to two sentences long. It’s unnecessary to cover every detail, but you must capture the key points and communicate them in a way that makes sense to the rest of the business.
Your outline will look something like the following (don’t worry, we’ll go into more detail about each):
Stepping back from a problem and measuring how much it’s impacting the business (through time trail studies or reporting) will give you a better understanding of whether or not the project justifies consuming a great deal of your time. It also helps you understand how other people feel and think about the issue.
Building a business case gives you greater perspective and empathy. It ensures all the impacted participants are identified and communicated to during the project. And it also reduces the pushback you’ll receive when you propose the project to a broader audience.
For example, proposing a database integrity project may seem like a waste of time to the executive team. If you can give them the percentage of duplicates and missing data, it’s not meaningful on its own. People won’t get why it matters.
How data issues impact marketing and sales execution when it comes to digital personalization and account-based marketing, and the amount of money you are missing out on because your competitors offer a better experience…
That will get the C-Suite’s attention.
The executive summary concisely outlines the problem, why it’s necessary to solve it, and what you’ll gain from undertaking the project. Your first sentence should include the problem and the current impact it’s having on the business. Shortly after that, you should state the gains your business will see after the project is complete.
Assume people won’t read any further and use the space as effectively as possible.
This section outlines the problem in terms that anyone will understand. Try to avoid acronyms and terminology only known to your department. Instead, focus on revenue impact, productivity, and wasted money. The executive team cares about the bottom line, so make sure that’s what your project is tied to.
If your project doesn’t have a tangible impact on the bottom line, it may not be a suitable project.
There are several ways to tie meaningful numbers to your project:
If you think your project isn’t tied to the bottom line, reach out to your network to see how they’ve successfully argued for the same project. What are some benefits they’ve seen?
This section is less about the risks involved in not taking on the project. Instead, those risks should be converted into benefits or what can be gained if the change occurs.
The risks are what could go wrong during the project. What could break if the change isn’t done well? What will you and others not be able to work on while you’re working on this project? Are there limitations to implementing a process or system that may cause issues years down the line?
The section should also include the projects that will be delayed by focusing on solving this problem.
Important: Be sure to speak to how these risks compare to doing nothing. Add up the costs of doing nothing and compare them to the costs of the project.
There is always more than one way to solve an issue. Outline each of the solutions, the benefits and drawbacks of each, and the perceived impact to end-users.
For example, if one solution is cheap, but it will add time to using the system, the cost-benefit may be outweighed by the pain it causes.
Only go into enough detail to explain the improvements and gaps you will have after implementing the solution. People won’t want to know details beyond whether or not you’ll need additional resources, applications, or time and how end-users will perceive the change.
This section should be short. You’ll simply state your solution preference and offer a couple of reasons to back up your opinion, focusing on benefits and costs.
If you have additional revenue-impacting projects on your list and too few resources to address them, consider asking for a temporary contractor or resources from additional teams. This could include someone from the data science team, a project manager, or end-users for solution review and testing.
Also, call out if you will need to purchase additional technology.
We recommend estimating timelines across multiple scenarios.
The best-case scenario would look like dedicating your time to this project while maintaining critical day-to-day responsibilities. The worst-case would look like tackling multiple projects simultaneously or not getting access to someone with niche expertise needed for the project.
After your document is complete, send it to internal stakeholders for review and feedback. Once you get the green light and speak with your manager about who should be included in a project proposal meeting, develop a deck that follows your document outline (with WAY fewer words).
If you sense resistance despite your work outlining the project's benefits, work with your manager to determine a strategy. Sometimes this is simple as having an earnest one-on-one with the manager, asking if they have concerns, and explaining why their buy-in is critical.
Don’t stop communicating once your project launches. Read our best practices for change management for more details.
