You're Probably Throwing Money Down the Drain With Your Tech Projects

How can you know if your tech investment is going to pay off before starting?

This is not always easy to answer. You can’t just look at a project and say “This will help us double our sales,” but you have to do it anyway. Because if you don’t keep investing in tools to make your team more productive and to modernize your company you can be left behind.

The way to get more ROI from your tech investments is to do a business case.

A business case is just a pitch.

It’s the argument for why you should spend time, money, and other resources on this project and not on something else.

A business case will clarify if the project is worth doing. So this is not something that you only use to convince a committee. It prevents you from saying yes to bad ideas and helps you use your limited resources smartly.

Here’s the structure:

1. The problem or opportunity

Start with why this matters. This is the main reason and motivation to decide to put resources into this.

You can approach this from a problem or opportunity lens.

A problem is something painful for you, your team, or your customers. The more painful, the stronger the case and the why this project is the best for solving that issue. For example, your team (or even worse — you!) is spending two days manually gathering the data to create the monthly payroll sheet.

You can also decide to invest for leveraging an opportunity. For example, if you can be one of the first companies in your market to use AI in your product, that could put you ahead of your competitors. That opportunity might be worth pursuing even if there isn’t an obvious problem to fix.

Either way, try to answer clearly what’s missing or possible — and why it matters now.

2. The outcome

Once you’ve explained the problem or opportunity, describe what success looks like by answering where you want to be once the project is completed.

It can be a simple sentence like “We want to reduce the time spent creating a payroll sheet from 2 days to 2 hours.”

Here’s where you are. Here’s where you want to be when this is done. The gap between those two things is the project.

This will give you something to work towards. And it also helps you avoid getting distracted by solutions that don’t actually solve the original problem.

3. The budget

A budget is what you decide to spend before you start.

This includes more than money. You might also need to budget for:

• People’s time
• Hiring external contractors
• Training
• Equipment
• Software or subscriptions
• AI tools and tokens

Time, money, people. But also: tools. If you’re using AI for this project, add that to the budget. The tokens you use on one thing can’t be used on something else. That’s an opportunity cost, and it belongs here.

For example, you might decide that two people can spend two weeks working on the project and spend half the AI subscription usage on this project.

4. Potential solutions

Next, think about how you can get to your desired outcome, considering the budget constraints.

In technical or implementation projects, there’s often a lot of uncertainty. You may not know the exact solution yet, so you will have to list the options you’re considering, and stay flexible on scope.

For example, if the outcome is to reduce manual data entry, you might consider automating the process using your existing tools or redesigning the process completely.

The business case should help you compare these options and decide which one is worth trying. This will prevent deviating from your main goal, but still give you the flexibility to adjust the plan to achieve it.

5. Success and failure metrics

These must let you know if this project worked or not.

You must define those before you start.

For example, for a new ERP implementation, failure could mean that the system wasn’t launched, or simply that nobody is using it.

And a success metric might be that, within two weeks of going live, key people are using the ERP, and at least a few important processes are being tracked.

Not every result is visible right away. Define what you can measure now, and make a note on what you’ll check later.

6. What’s out of scope

It can also be useful to explain what the project will not include.

This helps avoid confusion and stops the feared scope creep: the project requirements and scope growing endlessly.

For example, for a project that will automate the delivery approval process, it can be as simple as “This will not redesign the entire workflow.”

It’s common to find these improvement areas while you’re doing the implementation work. But instead of trying to tackle them right away, make a note of those and add them to a separate improvement project.

The business case structure

A business case can include a lot more detail, especially when the project is expensive or uncertain.

But the basic structure is:

• Explain why this is worth doing.
• Describe the outcome you want.
• Define how much time, money, and resources you will spend.
• Consider the potential solutions.
• Decide how you will measure success.
• Clarify what is not included.

That’s it.

You can use a business case to decide which project should come first, to prioritize your team’s work, or to convince someone this should be done.

In any case, this makes it easier to work on things that matter, and with higher return on investment.

Want help deciding whether a project is worth doing? Send me a message and let’s build the case together.