Every technology investment starts with the same question from the finance team: what's the ROI? And every technology leader has had the same sinking feeling when they hear it, because the honest answer is almost always "it depends on what you mean by ROI, and the way you're probably measuring it will give you a number that's either meaninglessly optimistic or misleadingly negative."
The problem isn't that technology investments don't deliver value. Most of them do, eventually, if implemented well. The problem is that the standard ROI framework (invest X, receive Y, calculate the percentage return) was designed for capital equipment and financial instruments, not for technology programs that change how an entire organization operates. Trying to force technology investments into that framework produces numbers that satisfy nobody and inform nothing.
This article is about why technology ROI is genuinely hard to measure, why the standard approaches produce bad answers, and what to do instead. It won't give you a magic formula. There isn't one. But it will give you frameworks that produce useful analysis rather than fictional spreadsheets.
Why traditional ROI fails for technology
When the CFO asks for ROI on a new ERP system, they're expecting something like a capital expenditure analysis. Spend this much, save this much per year, break even in this many months. It's the same framework used for buying a new production line or a fleet of vehicles. The formula is simple: net benefit divided by total cost, expressed as a percentage or a payback period.
The first reason this fails for technology is that the costs are genuinely uncertain. A production line has a known purchase price, a known installation cost, and well-understood maintenance requirements. An ERP implementation has an estimated license cost that will change as you discover additional modules you need, a services cost that depends on how many customizations are required (which nobody knows at the start), a data migration cost that depends on how bad your existing data is (which is always worse than you think), a training cost that depends on how much resistance the organization puts up (which correlates inversely with how well the project is managed), and an ongoing cost that depends on vendor pricing decisions made years after the initial purchase.
Any ROI calculation that uses the vendor's initial quote as the cost input is fiction. The real cost of a major technology implementation is typically 1.5 to 2.5 times the original estimate, and that's for well-managed projects. For poorly managed ones, the multiplier can reach five or more. An ROI calculation based on the optimistic initial estimate will show the investment in a favorable light, which is why vendors love to help you build it. An ROI calculation based on the realistic total cost might not get approved, which is why technology leaders are tempted to use the vendor's numbers.
The second reason traditional ROI fails is that the benefits are even harder to quantify than the costs. When someone says a new system will "improve efficiency," what does that actually mean in financial terms? Will you reduce headcount? Usually not. The efficiency gains mean existing staff handle growing workload rather than hiring additional people. Will you reduce errors? Probably, but what's the financial value of an error that didn't happen? Will you make better decisions because you have better data? Almost certainly, but try putting a number on the value of a decision that was slightly better than it would have been otherwise.
These benefits are real. They're just not easily expressed in the language that finance teams use. And so what happens is that the technology business case gets stuffed with inflated, speculative benefit estimates to hit the ROI threshold that the approval process requires, and then nobody goes back to check whether those benefits materialized. The business case becomes a work of creative fiction that exists to get past the approval gate and is never referenced again.
The two types of technology investment
The ROI confusion stems partly from treating all technology investments as the same type of expenditure. They're not. There are fundamentally two different categories, and they require completely different evaluation approaches.
Cost-saving investments replace an existing capability with a cheaper one. Migrating from on-premises Exchange to Microsoft 365 to reduce server and administration costs. Consolidating multiple WAN circuits into an SD-WAN deployment. Replacing an expensive legacy application with a modern SaaS equivalent. These investments have a clear baseline (what you're spending now) and a measurable target (what you'll spend after the change). Traditional ROI works reasonably well here, as long as you're honest about the total cost of the new solution including migration, integration, and ongoing management.
Capability-enabling investments create new capabilities that didn't exist before. Implementing a CRM system when you previously tracked sales in spreadsheets. Building a data warehouse to enable business intelligence reporting. Deploying collaboration tools that allow remote working. These investments don't have a direct cost comparison because there's no equivalent current spend. The value comes from what the organization can do after the investment that it couldn't do before. And that value is inherently speculative at the approval stage.
The mistake is evaluating capability-enabling investments with cost-saving frameworks. When someone asks "what's the ROI of implementing a CRM system?" and the answer is framed purely in terms of cost reduction, it misses the point entirely. The CRM isn't about saving money. It's about giving the sales team visibility into the pipeline, enabling management to forecast revenue, allowing marketing to measure campaign effectiveness, and creating an institutional memory that doesn't walk out the door when a salesperson leaves. Those are capability benefits, and they're enormously valuable, but they don't fit neatly into a return-on-investment percentage.
Recognizing which category an investment falls into is the first step toward a useful evaluation. Cost-saving investments should be evaluated on cost reduction. Capability-enabling investments should be evaluated on strategic value. Mixing the two produces analyses that satisfy neither the finance team nor the technology team.
Total cost of ownership: the number everyone gets wrong
Total cost of ownership (TCO) is supposedly the standard approach for understanding the full cost of a technology investment. In practice, most TCO analyses are incomplete because they miss the costs that are hardest to estimate but often the largest.
Migration costs. Every technology replacement requires migrating data, configurations, integrations, and workflows from the old system to the new one. This is almost always more expensive than anyone estimates at the proposal stage. Data migration in particular is a black hole for time and money, because legacy data is invariably messier than anyone realized, and cleaning it up enough to import into the new system requires significant manual effort. A realistic TCO analysis should allocate 15-25% of the total project budget specifically for migration, and even that might not be enough for organizations with decades of accumulated data.
Integration costs. No technology system operates in isolation. A new ERP needs to integrate with the CRM, the HR system, the warehouse management system, the e-commerce platform, and the bank. Each integration has a development cost, a testing cost, and an ongoing maintenance cost as each connected system is updated over time. Vendor sales teams will tell you their product has "out-of-the-box integrations" with everything you need. What they mean is that their product has APIs that a developer can use to build integrations, which is not the same thing at all.
Training costs. Not just the formal training sessions, but the productivity dip that occurs while people learn the new system. For a major system replacement, expect two to six months of reduced productivity across the affected teams. That productivity loss has a real financial cost, even if it doesn't appear on any invoice. A finance team that takes twice as long to close the books for four months while they learn the new system is a real cost to the organization, even though nobody writes a check for it.
Opportunity costs. Every major technology project consumes management attention, IT resources, and organizational change capacity. While you're implementing the new ERP, you're not doing the CRM upgrade, the network refresh, or the security improvement project that also needs to happen. The resources consumed by a major project are unavailable for other priorities, and that has a cost. Most TCO analyses ignore this entirely, which is how organizations end up approving more projects than they can actually execute.
Ongoing management costs. The vendor license fee is the beginning, not the end. SaaS subscriptions need administration. Cloud infrastructure needs monitoring and optimization. Every system needs someone responsible for patching, configuration management, user provisioning, and vendor relationship management. These ongoing costs typically run at 15-20% of the initial implementation cost per year, forever. Over a five-year period, the ongoing management cost often exceeds the initial deployment cost.
Exit costs. What happens when you need to replace this system in seven years? How easy is it to extract your data? What format will it be in? How dependent are your business processes on this specific vendor's approach? The cost of leaving a platform is rarely considered at the point of entry, but vendor lock-in is a real financial liability. Ask anyone who's tried to migrate away from a deeply embedded ERP or CRM how much it cost.
A complete TCO analysis includes all of these elements, projected over the realistic lifetime of the investment (typically five to seven years for major systems). When you do this honestly, the total cost is almost always significantly higher than the vendor's headline number. Which is why vendors prefer to talk about license costs rather than TCO.
Building a business case the CFO will approve
Understanding the problems with traditional ROI is useful, but you still need to get the investment approved. Here's a framework that acknowledges the complexity while producing something the finance team can work with.
Start with the problem, not the solution. The most common mistake in technology business cases is leading with the product. "We need to buy Salesforce" is not a business case. "Our sales team has no visibility into the pipeline, we can't forecast revenue accurately, and we lose institutional knowledge every time someone leaves" is a business case. The solution comes after the problem is clearly articulated. This matters because it shifts the conversation from "is this product worth the money?" to "is this problem worth solving?". and the second question is usually easier to answer.
Separate the certain from the speculative. Instead of lumping all benefits into a single ROI number, categorize them by confidence level. Hard benefits are those you can measure with high confidence: reduced license costs, eliminated infrastructure, headcount reductions (if genuinely planned). Soft benefits are those that are real but harder to quantify: improved productivity, better decision-making, reduced risk. Strategic benefits are those that enable future capabilities: platform for growth, competitive positioning, regulatory compliance.
Present all of these, but be explicit about which category each benefit falls into. A business case that claims hard savings of a specific amount, acknowledges soft benefits that are real but unquantified, and articulates the strategic value of capabilities that don't have a number attached is far more credible than one that lumps everything into a single inflated ROI figure.
Use ranges, not point estimates. A business case that says the project will cost exactly one specific amount and deliver exactly one specific amount of benefit is either dishonest or delusional. Use three-point estimates: optimistic, realistic, and pessimistic. The realistic case should be the one that drives the decision, but showing the range demonstrates intellectual honesty and gives the approvers a sense of the risk.
The optimistic case assumes everything goes to plan, the vendor delivers on time, adoption is smooth, and benefits materialize quickly. The realistic case adds a contingency to costs (20-30% for well-understood projects, 50% or more for novel ones), extends the timeline, and reduces the benefit estimates. The pessimistic case considers what happens if the project runs significantly over budget or if some of the expected benefits don't materialize. If the investment still makes sense under the realistic case, it's probably worth doing. If it only works under the optimistic case, it's too risky.
Include the cost of doing nothing. Every business case has an implied alternative: don't do the project. But "do nothing" has costs too. Legacy systems become more expensive to maintain. Security vulnerabilities accumulate. The organization falls behind competitors who are investing. Staff who are frustrated by outdated tools leave for employers who provide better ones. Quantify the cost of inaction as explicitly as you quantify the cost of action. Sometimes the strongest argument for a technology investment isn't that it will deliver returns, but that failing to make it will cost more in the long run.
When the ROI is risk reduction
Some of the most important technology investments have no positive ROI in the traditional sense. Backup systems. Disaster recovery. Security controls. Network redundancy. These are insurance-like investments where the return is avoiding a loss rather than generating a gain.
Trying to build a traditional ROI case for disaster recovery is an exercise in absurdity. The benefit of DR is that when your primary data center fails, the business continues to operate. How do you put a number on that? You can estimate the cost of downtime per hour and multiply by the expected reduction in downtime, but the resulting number depends entirely on assumptions about how often disasters happen and how long the outage would last without DR. Assumptions that are inherently uncertain and easily manipulated to produce whatever answer you want.
A more honest approach is to frame risk-reduction investments as risk transfer decisions. The organization faces a quantifiable risk: the annualized probability of a specific event multiplied by the estimated financial impact of that event. The technology investment reduces that risk by some factor. The question for the board is whether the cost of the risk reduction is proportionate to the risk being reduced.
This is conceptually identical to buying insurance. You don't calculate the ROI of your building insurance by dividing the potential payout by the premium. You buy insurance because the potential loss is catastrophic enough that the premium is worth paying to transfer the risk. Technology risk-reduction investments work the same way.
For security investments specifically, the conversation should be framed around risk appetite. What level of cyber risk is the board comfortable with? What would the financial, operational, and reputational impact of a significant breach be? What does it cost to reduce the probability and impact to an acceptable level? This is a governance decision, not a financial calculation. Framing it as ROI produces meaningless numbers. Framing it as risk management produces actionable decisions.
The same principle applies to business continuity investments. What is the organization's tolerance for downtime? What would an outage lasting one hour, one day, or one week cost in revenue, reputation, and contractual penalties? What level of investment in redundancy and failover reduces the probability and duration of outages to an acceptable level? These are questions the business leadership should answer explicitly, with the technology team providing the options and their costs.
The hidden costs nobody budgets for
Beyond the TCO categories already discussed, there are several cost categories that repeatedly catch organizations off guard because they don't appear in any vendor proposal or project plan.
Change management. Implementing a new technology system is, at its core, a change management exercise. The technology is the easy part. Getting people to actually use the new system, follow the new processes, and abandon the workarounds they've built around the old system (that's the hard part. Organizations that budget zero for change management typically see adoption rates of 40-60% after six months, with significant pockets of resistance and shadow processes running in parallel. Organizations that invest properly in change management) communication, training, feedback loops, executive sponsorship (see adoption rates above 80%. The cost of poor adoption isn't just wasted license fees; it's the gap between the system you paid for and the system people actually use.
)Customization creep. The initial implementation plan calls for a standard deployment with minimal customization. Then the finance team needs a specific report format. Then the operations team needs a workflow that the standard product doesn't support. Then a regulatory requirement means a particular field needs to be added. Each customization seems minor in isolation. In aggregate, they transform a standard deployment into a bespoke system that's expensive to maintain, difficult to upgrade, and impossible to support without specialized knowledge. Five years later, the "standard product" has been customized beyond recognition, and the cost of those customizations (in implementation, in ongoing maintenance, and in upgrade complexity) exceeds the original license cost several times over.
Technical debt accumulation. Every shortcut taken during implementation creates technical debt that someone will have to pay back later. Temporary integrations that become permanent. Data quality issues that are deferred because cleaning the data would delay the go-live. Security configurations that are set to permissive during testing and never tightened for production. Manual processes that were supposed to be automated in phase two, except phase two never happens. This debt accumulates interest: the longer it goes unaddressed, the more expensive it becomes to resolve, and the more it constrains future investments.
Vendor pricing escalation. SaaS vendors in particular have pricing models that escalate significantly after the initial contract period. The first three-year term might be competitive because the vendor is buying market share. The renewal is where they make their money. Annual price increases of 5-10% are common, and some vendors have been known to increase prices by 30-50% at renewal, knowing that the switching cost means most customers will grumble but pay. Any long-term cost analysis needs to account for pricing escalation, not assume that the initial rate continues indefinitely. This is particularly important for cloud infrastructure, where the usage-based pricing model means costs scale with business growth in ways that are difficult to predict at the outset.
Practical frameworks for evaluating technology investments
Given all of these challenges, how should organizations actually evaluate technology investments? Here are four approaches that work in practice, each suited to different types of decisions.
Cost-benefit analysis with honest uncertainty. For cost-saving investments where the current cost and the future cost are both measurable, a straightforward cost-benefit analysis works. The key is honesty about the uncertainty. Use three-point estimates for both costs and benefits. Apply a discount rate that reflects the organization's cost of capital. And include all of the hidden costs discussed above, not just the vendor's sticker price. This approach works well for infrastructure refreshes, platform consolidations, and vendor replacements where the primary driver is cost reduction.
Options-based evaluation. For capability-enabling investments where the value is in future flexibility rather than immediate returns, think of the investment as purchasing an option. You're paying a known amount now for the ability to capture value later, if conditions are favorable. A cloud migration, for example, might not deliver immediate cost savings (it often increases costs in the short term). But it creates the option to scale rapidly if the business grows, to launch new capabilities faster, and to exit expensive data center leases. The value of those options depends on probabilities (how likely is rapid growth, how valuable is faster time-to-market) but framing the investment as buying options rather than generating returns gives the board a more honest picture of what they're approving.
Comparative benchmarking. Sometimes the most useful evaluation is not "what's the ROI?" but "what do comparable organizations spend on this?" If your IT spending as a percentage of revenue is significantly below industry benchmarks, that's a signal of underinvestment that's creating risk and limiting growth. If it's significantly above, that's a signal of inefficiency that deserves investigation. Benchmarking doesn't tell you whether a specific investment is worthwhile, but it provides context for whether your overall technology spending is in the right range. Gartner, Forrester, and industry-specific analysts publish benchmarks that, while imperfect, are useful reference points.
Strategic alignment assessment. For investments that are primarily strategic (enabling a new business model, entering a new market, meeting regulatory requirements) the evaluation should focus on alignment with the organization's strategic objectives rather than financial returns. Does this investment enable something the board has identified as a strategic priority? Is it a prerequisite for other initiatives that the organization has committed to? Does the lack of this capability represent a strategic risk? These are qualitative questions, and they should be answered qualitatively rather than forced into a quantitative framework that produces misleading precision.
The governance question: who decides and how
The technology ROI debate is often a symptom of a deeper governance problem. In many organizations, technology investment decisions are made through a process that was designed for capital expenditure: submit a business case, get it reviewed by a finance committee, approve or reject based on the projected return. This process works for discrete, bounded investments. It fails for technology because technology investments are increasingly continuous (subscription-based), interconnected (the value of one investment depends on other investments), and evolving (the requirements change as the organization learns).
Effective technology investment governance typically involves a portfolio approach rather than a project-by-project evaluation. The board or executive team sets an overall technology budget based on strategic priorities and industry benchmarks. Within that budget, investments are prioritized based on a combination of financial return, strategic alignment, and risk reduction. Individual projects are evaluated not in isolation but as part of a portfolio that balances quick wins with longer-term strategic bets, and cost reduction with capability building.
This portfolio approach has several advantages. It prevents the gaming that happens when every project needs to demonstrate positive ROI: instead of inflating benefit estimates to clear the approval hurdle, projects compete on a level playing field where strategic investments don't need to pretend they're cost savers. It enables trade-offs: if the budget is fixed, approving one project means deferring another, which forces genuine prioritization rather than approving everything and hoping for the best. And it creates accountability: the technology leadership is responsible for delivering value from the portfolio as a whole, not from each individual project.
The quarterly business review is more useful than the annual budget cycle for technology investments. Technology moves too fast for annual planning. A quarterly review of the technology portfolio (what's been delivered, what value has been realized, what's changed in the external environment, what should be reprioritized) keeps the investment decisions current and creates a feedback loop that improves estimation accuracy over time.
Post-implementation review: the step everyone skips
Ask how many organizations go back after a technology implementation to check whether the projected benefits actually materialized. The answer, based on extensive industry research, is fewer than 20%. This means 80% of organizations make technology investments based on projected benefits, never verify whether those benefits were achieved, and then use the same estimation methodology for the next investment. It's the equivalent of betting on horses, never checking the results, and continuing to use the same tipster.
Post-implementation reviews are uncomfortable because they often reveal that the projected benefits were overstated, the costs were understated, and the timeline was unrealistic. Nobody wants to commission a report that says "we spent twice what we planned and achieved half the benefits we projected." But without that feedback loop, the organization can't improve its estimation accuracy. The same systematic biases (underestimating costs, overestimating benefits, ignoring hidden costs) recur in every business case because there's no mechanism for learning from past experience.
A useful post-implementation review doesn't need to be a formal audit. Six months after go-live, answer five questions: Did the project cost what we estimated? Did it take as long as we estimated? Are people actually using the new system as intended? Have the projected benefits started to materialize? What would we do differently next time? Document the answers, share them with the people who will approve the next technology investment, and use them to calibrate future estimates. Over time, this creates an organizational memory that makes technology business cases progressively more accurate and credible.
The CFO who initially demanded ROI as a gating criterion may be the biggest beneficiary of this approach. Instead of receiving business cases full of optimistic projections that they know are unreliable, they start receiving business cases informed by actual historical data from their own organization. That's genuinely useful information for making investment decisions.
Stop pretending and start deciding
The technology ROI problem is, at its root, a problem of organizational honesty. Organizations pretend that technology investments can be evaluated with the same precision as financial instruments. Vendors pretend that their products will deliver quantifiable returns that justify the purchase price. Technology leaders pretend that their benefit projections are grounded in data rather than aspiration. Finance teams pretend that the ROI number they calculate means something precise.
The way forward is to stop pretending. Acknowledge that technology investments involve genuine uncertainty. Use frameworks that embrace that uncertainty rather than disguising it with false precision. Evaluate different types of investments with frameworks appropriate to each type. Build a feedback loop that improves estimation accuracy over time. And make decisions based on strategic judgment informed by the best available analysis, rather than waiting for a number that will never be precise enough to make the decision for you.
Technology investment is a judgment call made under uncertainty by people who understand both the technology and the business. No spreadsheet, however sophisticated, removes the need for that judgment. The role of analysis is to inform the judgment, not to replace it. Organizations that understand this make better technology investments than those that hide behind fictional ROI numbers. Because they're making decisions based on what they actually know rather than what they wish they could prove.