5 mistakes to avoid when building the business case for IT

At Nucleus we’ve been working with clients to build the business case for their technology projects for the better part of two decades. Early on, we issued our “ROI Manifesto,” which outlined the concept of developing business cases around current and planned IT expenditures—ultimately, to align CIOs and IT executives with their peers in finance. While this concept has become more accepted today, at the time, it was radical thinking:

Now, more than ever before, companies are looking closely at the impact of IT spending on their bottom line. Economic pressures, coupled with years of heavy IT spending without clear returns, have driven corporate demands for a tighter rein on IT expenditures and clear justification of every dollar being spent. Technology and finance decision makers need metrics and measures they can trust to ensure that they are making IT decisions that will have a positive impact on the corporate bottom line.

Although the buzzwords may have changed and the expectations for payback and risk have become more precise, the path to a credible business case hasn’t changed. Building a business case for a tech investment isn’t difficult, it’s just structured: identify the top areas of benefit, quantify the costs and benefits, and calculate the metrics. Here are five key mistakes to avoid when pulling your business case together.

Mistake No. 1: Death by spreadsheet

Many companies have their own internal business case templates for justifying IT projects, and we’ve reviewed hundreds with varying degrees of detail: multiple colors and tabs, links to detailed calculations and assumptions, and so much granularity that the actual development of the business case took more time than the deployment itself.

The problem with this approach is not only that it’s painful and time consuming, it’s that it focuses on the individual trees instead of the forest. The best business case typically is driven by 2 or 3 benefits—the worst ones have five or more. When you focus your business case on the few benefits that actually matter, you can use your time more wisely by estimating the actual value of those benefits and outlining how you plan to achieve them. You can find more details on how to winnow out those top areas of real benefit here, but, in short, look for benefits with a great deal of breadth and repeatability and focus your efforts there.

Mistake No. 2: Seeking the perfect ROI

The goal of a business case is to justify a project and provide a roadmap for achieving value—but not necessarily in that order. Rather than focusing on the percentage ROI or the precise payback figure, focus instead on having a structured understanding of the costs and benefits, and the big moving parts where you want to spend more time on those estimates and understanding how much variability (how far off could you potentially be) they have.

Mistake No. 3: Ignoring internal personnel costs

Project champions often ignore or understate the internal personnel time devoted to a project’s success, because those employees are “already paid for.” Unless you’re planning on hiring additional staff to do your deployment team’s job during the project, or have free labor at your disposal, you need to account for the internal time spent on the project for a number of reasons. First, it shows financial decision makers you have a clear business view of the impact on the project on internal resources. Second, you have estimates you can manage to during the project and realistically evaluate the disruption the project may have on team members’ other responsibilities.

Finally, and perhaps most importantly, you can communicate to the team what’s expected of them and that you recognize the additional responsibilities you’re adding to their plate—which can be critical at crunch time when team morale may be at its lowest. Stating upfront what internal time you expect will be devoted to a project shows you recognize the effort it will take, and sets you up to give the team the kudos they deserve at performance review time.

Mistake No. 4. Double-counting benefits

Most IT projects today deliver either direct benefits (clear cost savings or profit increases) or indirect benefits (like productivity increases). Many projects we look at today in areas like CRM, for example, expect that a productivity increase in sales, marketing, or service is going to deliver increased sales, leads, or case resolutions, respectively. If you can credibly estimate the end result as a direct benefit, great. If you can’t, you can credibly estimate the productivity savings (more on that here)—but you shouldn’t be counting both. In many cases we look at, growth (in customers or margins) is a key justification. In these cases, estimating the number of additional hires you would need to achieve the same result is a reasonable strategy.

Mistake No. 5. Thinking you’re finished

By far the biggest mistake IT leaders make with business cases is in submitting their business case—and then archiving it. Rest assured that the ROI you estimate for a project will never be the ROI you actually achieve—but that’s not a reason to bury it forever. Financial decision makers use their business case as a tool not just to justify a project but to build milestones for measuring and adjusting their deployment strategy when the unexpected arises.

Keeping your business case as a roadmap can help you to determine when costs are coming in higher than expected, or delays are keeping you from achieving the ramp up of benefits you planned for—and what adjustments you need to make to maximize the value from your project. Depending on the timeline of your project, monthly or quarterly check-ins on key cost and benefit milestones are more powerful project management and negotiation tools than any Gannt chart.

If you’re tasked with building or evaluating the business case for a project, you can download Nucleus’s free ROI tool here, which will give you a good starting point. Avoiding these key mistakes can help ensure you devote the time needed to business case efforts and move on to using that case as a roadmap for success.