Chapter 4 - The Business Value of IT

4	The Business Value of IT

Very often when we have found ourselves forever separated from what we had intended to achieve, we have already, on our way, found something else worth desiring.

—Goethe, Maxims

If I were to wish for anything, I should not wish for wealth and power, but for the passionate sense of the potential, for the eye which, ever young and ardent, sees the possible. Pleasure disappoints, possibility never.

—Søren Kierkegaard, Either/Or

In 1995 the Standish Group released a report, known as to as the Chaos Report, with the spectacular claim that only 16.2% of software development projects are fully successful, finish on time, and stay on budget. They said that 31.1% are cancelled before they finish, and 52.7% cost 189% of their original estimate.1 Standish has since repeated the study, tracking projects from 2003–2012, this time finding that only 6.4% were successful.2 Compared to that, an IBM study was positively encouraging—it found that 41% of projects meet schedule, budget, and quality goals.3

Standish’s startling results set off spasms of anxious rethinking regarding IT practices. The initial reaction was to double down on the classical project management principles. Organizations had to do a better job of documenting requirements, planning more carefully, estimating schedules more precisely, reporting more frequently on the status of each project, and being prepared to cancel projects ruthlessly if they appear to be going out of control.

Shocking as Standish’s results appear, there is a very different way to interpret them. Perhaps they’re really just a confirmation of uncertainty, telling us that early estimates are invariably unreliable, that success can’t be measured by reliance on an estimate made before enough information is available. In this interpretation, the Chaos Report is simply a confirmation of Figure 6: The Cone of Uncertainty in the prior chapter. Standish’s study errs in imposing a value judgment on neutral data.

But another set of studies raises different and more serious concerns, since they aren’t about schedule adherence but about value delivery. According to a KPMG study, “50 percent of respondents indicated that their project failed to consistently achieve what they set out to achieve.”4 A McKinsey study found that “17 percent of large IT projects go so badly that they can threaten the very existence of the company.”5 McKinsey also said that large IT projects deliver 56% less value than predicted.6

Again there is a question of how to interpret these results, though another set of studies gives a clue. Apparently, 75% of project participants lack confidence that their projects will succeed7 and 70% have been involved in a project they knew would fail from the start.8 In other words, people knew their projects weren’t going well but were unable to change course. Well, of course they couldn’t—the plan was already locked in! To be successful, a project team needs to make course correction an everyday part of its activities.

In 1995 Tom DeMarco, one of the more provocative early IT thought leaders, published the book Why Does Software Cost So Much? We can all probably understand his question. Software is intangible; in a sense, it’s just a simple translation of a desired computer behavior into a language the machine can understand. Yet creating it usually takes teams of highly paid developers, testers, and database administrators. It can take months or years. It is never finished, and always costs more than expected.

Accepting DeMarco’s insinuating premise, we might indeed be tempted to say that software indeed costs too much. And taking the Standish findings at face value, we would have to conclude that most IT projects fail, while the rest are highly challenged. Yet we know very well that businesses—rational actors on the whole—keep investing in IT. You’re reading this book because you believe in the power of IT to drive business outcomes. So why invest in guaranteed failure?

The answer is that technology is delivering business value, and boatloads of it—despite the fact that IT projects seem to fail. Projects have a fixed scope and schedule and are driven by a plan, but IT’s value is primarily in the operational use of the capabilities it delivers. As DeMarco says, the flip answer to his question (and one that he rejects as being too simple) is, “Compared to what?”9 Software is what runs our businesses today: it’s what lets us compete in markets. Surely the value of that is high.

The real question for those leading digital transformations is how to maximize the business value they get from IT, not how to make projects finish on time. Here we run into a number of tricky issues and misunderstandings. This chapter will look at what exactly business value means and what it means for IT to deliver it, and how that might change as we enter the digital world.

DeMarco’s cynical answer, by the way, is that IT isn’t really expensive—just as it isn’t really failing. Asking the question, he says, is a way of trying to put maximum pressure on the technology organization to lower costs.10 I see it more as a way that enterprises have wishfully tried to gain control over highly variable costs they felt powerless to manage.

Imagine going to a crafts market in a country where bargaining is the norm. You’re uncomfortable with bargaining and unfamiliar with prices in that country. You spot an artisan bobblehead you really want to buy. The vendor assures you that it’s a particularly fine specimen, undoubtedly worth the one hundred Napoleonic livres* he says it’ll cost you. You’re sure that this price is absurd because, after all, you’re a tourist and the vendor can see that.

But what is the normal price, you wonder? After turning the bobblehead over a few times, frowning at it, and trying to look like you’re no fool, you offer half—fifty livres. After some back and forth you finally wind up bargaining a price of seventy-eight livres. No doubt you’re being ripped off, but what else can you do?

Now imagine The Business early in its encounters with Gerald and his platoon of technologists. How much will it cost to fix the ephemeral ramifier, Gerald?

CIO: We think that if we can simplify a few things in the requirements, it’ll be about sixteen months.

CEO: What? Sixteen months? That’s way too long. We need this to respond to the Evil Empire’s new competitive product. We can’t go sixteen months without a Bobbling Bear!

CIO: That’s impossible. The Bridge at Borodino feature alone will take six months.

CEO: OK, well let’s say ten months, then. But no later! If your team can’t handle it, then outsource it.

CIO: Well . . . if we can simplify the Borodino Bridge feature and if the Bobbling Bear business unit sets aside a team of three people to help us, maybe we can do it.

CEO: Very good. That’s good, creative thinking. OK, then, it’ll be done by next June, right?

I didn’t say whether I was the CEO or the CIO in this scenario. I’ve been both. This conversation is natural when no one has a good basis for predicting the cost. They might as well be arguing about the number of grains of sand on the beach in a science fiction novel that takes place in an invented universe.

Notice how the exchange moves subtly from an estimate to a commitment. An estimate is an estimate—you can’t negotiate an estimate. But that’s exactly what happens here. Both parties implicitly take the estimate to be a plan, and then the planned time is negotiated to a lower number. But that doesn’t change the estimate, which is still the CIO’s best educated guess as to how long the project will take. The CIO believes the project will take sixteen months, but is now committed to doing it in ten. If it winds up taking fourteen months, is that good or is it failure? In Standish’s definition, it’s failure.

Also notice that the original estimate is a point estimate. If we were honest with ourselves, we would give our estimates with confidence ranges, something like “I’m 60% confident that it’ll take between twelve and twenty-four months.” We don’t like to admit to the uncertainty and therefore hide it by giving a point estimate. In this case, the CIO probably feels like it’s part of his job to know how long an IT project will take, and the CEO expects a precise estimate (is that perhaps an oxymoron?) for planning purposes. How much uncertainty is there? Much. That’s what Standish’s IT project failure rate tells us.

What are some of the uncertainties? First of all, every IT project is different—there is no applicable historical data. Technology often doesn’t work the way you expect: interactions between one part of the system and another surprise us. No matter how careful the business unit is when writing the requirements, they will change significantly. In short, this is a complex and uncertain endeavor.

The requirements begin at a high level of abstraction and later, when the details are known, it’ll become clearer how much time is actually required. An IT project is a journey from abstract to concrete—while the project starts with a high-level vision, code is its concrete and detailed interpretation. When the requirements finally have become concrete—in other words, when the code is already written and tested—it will become easy to estimate how long the project has taken, so a point estimate with 100% confidence is appropriate. But at any earlier time, an estimate should have a wide confidence interval. That’s the message of Figure 6: The Cone of Uncertainty in the prior chapter.

Business leaders were once tourists in the crafts market when it came to IT spending. It’s natural when a tourist, having no idea what the right price for a traditional bobblehead might be, turns to another tourist and asks, “How much did you pay for yours?” But the problem is that there is no “right” price—prices depend on the workmanship, the vendor, the buyer, and the moment.

Similarly, some businesses try to benchmark their IT spending against that of other companies to determine how much they “should” be spending—often comparing the percentage of revenue spent on IT. But IT spending really depends on what the company is trying to accomplish; that is to say, it depends on the company’s strategy. It depends on how the industry and its customers’ tastes are changing; whether the company is planning for an IPO, an acquisition, or another exit; and what ideas the CEO, CFO, CMO, and COO have that require technology support.

Even if you buy into the idea of benchmarking your IT spending, what is the right target? Spending at the average rate? Is the company’s goal to be average? Using this type of benchmark suggests that the company considers IT to be only an unavoidable and unfortunate cost of doing business rather than an element of competitive strategy.

On the other hand, not all IT spending is good spending. An enterprise that wants to get the most value from IT must distinguish good spending from bad. What we really need to know is, given a particular intent, is our IT spending cost effective for realizing that intent, or is it wasteful?

You can set any IT spending target you want. If it seems that spending at the industry benchmark percentage of revenue is a good idea, then there is no reason why you can’t hit that number. Virtually any CIO can cut the IT budget by 15%, 35%, or even 75% by doing less IT work or reducing its services to the rest of the company. But what is the impact of doing so? It’s probably a feeling that IT can’t meet the company’s needs. It might mean cutting corners and incurring technical debt, which will then make it harder and costlier for the company to accomplish its IT objectives in the future. That doesn’t mean it’s wrong; just that it will have consequences, particularly in the digital realm.

It’s important to look at marginal impact: an incremental one hundred livres of spend in IT might increase revenues or decrease costs in another part of the business. IT spending affects the whole of the business, even if the budget and capital plan are specific to IT.

I would rather reframe the IT spending discussion this way: Is there waste in the IT costs? If so, it should be located and eliminated. If there isn’t any, then budget cuts will have an impact on the IT estate, the capabilities produced, and consequently on the rest of the organization (which may or may not be acceptable). If the IT organization is running leanly and the budget is boosted, then the increase will have the optimal positive impact. It’s then a matter of choosing what impact you want IT to have.

IT should be measured by the amount of business value it creates; its initiatives should be prioritized based on the amount of value they are expected to return. Ummm . . . but what exactly do we mean by business value? I’m not sure this is clear to everyone—I’ve seen the definition shift as employees try to make the case for what they believe is most important.

At USCIS, for example, I had a team working with the Service Center Operations (SCOPS) business unit. I had appointed a lead from the IT side, while the head of SCOPS appointed a lead from the business side. Together the two had created a list of priorities to guide IT work. I periodically checked in and was assured that the business case for each listed item was sound.

One day I was in a senior leadership meeting where there was worried discussion about the growing backlog on processing I-90 forms (the application for green card renewal or replacement). This was deeply troubling to the agency and, it turned out, a major concern of the head of SCOPS. I knew that there was plenty IT could do to help. But when I asked the two project leads about it, they told me that it wasn’t in their plans. Yes, the leads answered me, they were working on things that would produce the highest business value: improving I-90 processing just wasn’t one of them.

How was it possible that they were prioritizing the work that would yield the highest business value, yet weren’t doing anything about the agency’s highest priority? This was a puzzle that drove me to a deeper inquiry regarding business value.

Authors Jeanne W. Ross and Peter Weill, in IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, raise the question of how to measure business value:

Enterprises have struggled to understand the value of their IT-related initiatives because IT cannot always be readily demonstrated through a traditional cash flow analysis. Value results not only from incremental process improvements but also from the ability to respond to competitive pressures . . . [and] it can be difficult to determine in advance how much a new capability or additional information is worth.11

Discussions of IT prioritization often refer to return on investment (ROI) or internal rate of return (IRR) as the basis for decisions. It’s true enough that ROI is often used as a simple way to make capital investment decisions, or at least to compare investment options. But there are a number of problems with ROI, beginning with the vagueness of its definition. ROI is certainly a return divided by an investment. But which return should be used in the calculation?

Typically, it’s incremental profit. But profit, as we know, is a financial accounting concept, not an economic one. It may depend on factors such as how inventory is valued and how capital assets are depreciated. And how many years of profit should you include? Are future years discounted?

If you’re trying to make decisions about which individual features to include in a product or in the maintenance activity flow for a system, then ROI becomes especially difficult to assess. How much will profit increase if we let users sort a data table by any column they want? In theory, we can measure these things,† but now that we can deliver IT capabilities at high speed and low cost, it becomes harder to justify spending the time.

We also have to admit that we don’t actually know ROI when we’re making investment decisions—we can only project it. Perhaps when IT was primarily a way of reducing costs, we could reliably project returns. But in the uncertain digital world, where technology is the enterprise’s basis of competition, revenue generation, compliance, and customer service, returns are difficult to project. Can you estimate the return on an analytics platform, the purpose of which is to discover which product changes might increase consumption? Or estimate revenues from a product that a competitor might quickly copy?

I’m not saying that it’s impossible to create business cases, just that estimates have a high cost to prepare, a very low precision, and a high expected variance—to the point where basing decisions on them can be misleading. Yes, enterprises need to make the best capital investment decisions they can, but I’ll show later that there are better ways to do so than relying on low-fidelity estimates. IT now has surprisingly few of the typical capital investment characteristics.

Some Agile writers suggest using cost of delay as a way to prioritize features. For each proposed feature, they say, calculate how much the enterprise is losing by not having it (in terms of revenues foregone or costs not avoided). Then select the feature that has the highest cost of delay. That’s not bad as a way to foster agility, but unfortunately it still depends on very uncertain projections and is subject to the same lack of clarity when we try to estimate cost. What is the cost of delaying an information security initiative? How can you compare the cost of delay of a feature that would help prevent malaria with one that would reduce operational costs?

Remember too that incremental profits are not necessarily what an organization values. Sure, for a publicly traded company, we can agree that profit is a goal. There are about 5,000 publicly traded companies12 out of about twenty-seven million businesses in the US—that’s 0.02%. Or to be more reasonable, make that out of about six million businesses having more than one employee—let’s say .08%.13

What are the others? Family run businesses are 70%–90% of global GDP and one-third of the global 500.14 According to Associate Professor Belén Villalonga of NYU Stern School of Business, “Most companies around the world are controlled by their founders or founding families, including not only private firms but also more than half of all public corporations in the US and Europe, and more than two-thirds of public corporations in Asia.”15 Add to that the number of other businesses that are closely held private companies. In all of these the owners decide what is business value—and it’s not necessarily related to profit. Business value is simply . . . what the business values.‡

How about the 3,500 companies funded each year by venture capitalists (VCs)?16 Private equity investors also have their own priorities as owners. Perhaps the most valuable result for a series A investor is that series B financing be raised at a high valuation. That often doesn’t depend on profit. A VC’s idea of what is valuable might also depend on where they are in the lifecycle of their fund.

There are 1.5 million nonprofits in the US, accounting for 5% of GDP.17 What is business value in a nonprofit? Or in a government agency? Business value in DHS probably has something to do with averting terrorist incidents in America. How would you measure ROI? Even if you could, how would you make value judgments, such as whether saving ten lives is worth spending $100 million?

The point is that there is no universal currency in which business value is measured, or at least no currency that is helpful in deciding how to prioritize or fund IT investments. If there were—say ROI—then we would be able to translate all proposed investments into that currency and compare them. But there is no preordained way to compare the investment in a security device, such as a firewall (a device that protects a network), to an investment that will save ten people from malaria.

Actually, let’s look more closely at that firewall investment. To estimate its ROI, we would have to make assumptions about:

It’s especially hard to calculate ROI for technical IT investments such as a firewall because IT touches so many other business areas, and because it’s so deeply affected by uncertainty. To make matters worse, organizations often think of such an investment as addressing one of IT’s needs, rather than a business need (because IT isn’t the business, right?).

Interestingly, ROI doesn’t really capture the value of agility itself. If we build a first tranche of capabilities with an initial investment installment, then we have the option (but not the requirement) of investing future tranches if we later decide they have value. That is, we’ve bought a call option on the remaining tranches.

Furthermore, in developing IT capabilities we can often create latent value—the potential for value that can be harvested later. If we build capabilities that enable others, even if we have no immediate plans to follow through, we have also bought an option. If we build or buy a flexible, reusable piece of technology, even if we don’t know exactly how else we might use it in the future, we’ve bought agility—again, an option. If we design agility into our systems, making them cheap and fast to alter, then we have purchased an option that can reduce future costs.

Real options is the strategy concept perhaps most directly applicable to the valuation of IT investments under uncertainty. . . . Like financial call options, for example, a real option may give the firm the ability to acquire a rent-generating resource (such as a new technology) if the resource were to become valuable, without needing to commit fully to the resource before its value-creation potential is fully known. Like financial put options, a real option may give the firm the ability to discontinue an unprofitable activity, divest a losing technology investment, or recover money invested in a past technology resource even though its current market value had dropped below its historical cost. Both options substitute for the organization’s imperfect ability to predict the future when it must make strategic decisions such as market entry, positioning, or value chain configuration.18

Another hard-to-identify, intangible source of value is information. Agile teams deliberately structure their efforts to maximize learning; the Lean startup approach carefully makes hypotheses explicit and tests them. Every bit of learning improves our ability to cost-effectively deliver the outcomes we want, and in the process reduces our risk. In the traditional waterfall world this value was negligible, as learning wouldn’t be used to change the plan, but today information value is vital.

When we consider investing in an analytics or business intelligence (BI) system, or a data warehouse or data lake we’ll use for analysis, rather than painfully trying to compute a vastly imprecise ROI, we would be better off seeing the return as a combination of information value and options made possible by having that information.

What if we put resources into improving the internals of an IT system to reduce technical debt (see Chapter 5)? Perhaps we can value it as an investment to reduce future costs of development, though that will be hard to model since we don’t know what we’ll develop in the future. We could instead think of it as creating options (it will make us more Agile later) or mitigating risk (it will reduce the likelihood that any change made later to the system will break it). And how about the value of compliance controls? Perhaps some of the value is in the form of a risk reduction, while some of it may be seen as a portion of spending on a compliance program that in total will increase revenues or reduce costs.

A common theme runs through these alternative value sources: they become more valuable the more uncertainty there is in the environment. The value of an option increases with uncertainty. The value of risk-mitigating investments—including security investments—increases with uncertainty. Information value is higher under uncertainty. The ROI-based-on-profit approach, I’m suggesting, is progressively less applicable as we move into the digital age—an age dominated by uncertainty.

Many of these problems spring from setting up IT as an order taker, which in turn requires that the value of proposed projects be compared. But there is a different way to frame the business value discussion. Enterprise-wide objectives can be set by senior leadership, then IT can work with other business leaders to translate them into specific initiatives. They would need little business case justification, since they’re based on those high-level objectives.

This cascade of objectives may be the only practical way to interpret business value, given that we can’t translate different types of investments into a single currency of value. The senior leadership team turns the enterprise’s ultimate goals—increasing shareholder value or curing malaria—into a set of concrete objectives in the strategy-setting process. These then become the organization’s definition of business value—that is, what is valuable to the business—to be used when making lower level prioritization decisions.§ By cascading objectives in this way, the enterprise helps make IT, alongside the rest of the business, responsible for business outcomes.

In the earlier SCOPS example, this was precisely the missing element. The projects being considered were dreamed up by the software users; none of them advanced the objectives of senior leadership. Nevertheless, each had a business case that demonstrated “business value” by some definition of the term. Perhaps it would reduce costs or eliminate time-wasting activities for the employee who proposed it. Each appeared to be individually justified. But because all of the available IT capacity was being used up on those work items, the organization couldn’t accomplish what really mattered to it.

IT investments don’t just produce operational capabilities. As you embark on the digital transformation, it’s important to consider their strategic benefits as well. This is difficult if you consider only the immediate cash flows the investment generates. IT investments made to cultivate new growth opportunities, for example, will be hard to fund because they’ll never seem to have as good a business case as those that increase profit in existing business lines.19 Clayton Christensen shows in The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail that the traditional best-practice approach to valuing investments has resulted in the demise of a number of leading companies by causing them to miss the emergence of new market categories.20

To Drnevitch and Croson, IT adds value by changing the tradeoffs between different possible strategies:

Our premise is that investments in IT and complementary (digitally connected) organizational capabilities fundamentally alter the set of business-level strategic alternatives and value-creation opportunities that firms may pursue, as well as change the relative attractiveness of pursuing those options on both a risk and reward basis.21

They note that IT’s contributions are not only (in some cases) balance sheet assets, but also enablers of capabilities; they only become actual when combined with other unique capabilities of the company.22 As a result they are difficult to copy, and through them the company can gain competitive advantages.

Ultimately, IT can provide us with the strategic value of flexibility to respond to opportunities that arise by letting us react quickly, try out innovative responses, and reconfigure our business activities.23 It is precisely this strategic use of IT that we must focus on in our digital transformations.

* For history buffs: the French franc was created in 1794, before Napoleon’s campaign in Russia, but livres continued to be used until the 1830s.

† See, for example, Douglas Hubbard’s How to Measure Anything. I think many of us are inspired by Hubbard’s book but then sheepishly have to admit that we don’t actually have the time or energy to actually measure everything.

‡ Long story—I learned my lesson on this. Don’t advise owners to divest a business unit that they like but that is losing lots of money. You heard it here.