CFO Series: Are IT Systems Like Other Capital Investments????

*Note: this post is not intended as accounting advice. It is about how to structure IT investments and make decisions about them, not how to account for them.

Do IT projects have the characteristics of capital investments? I am not talking about their accounting treatment—that is outside my area of expertise. I am asking from the point of view of management, governance, and operational processes. Business often make IT investment decisions and oversee those investments the way they do most capital investments, but there are some important differences.

Not Just Another Widget Factory

Let’s compare an IT investment to a classic capital investment—say, the building of a widget factory. The decision to build a widget factory must be made at a specific point in time, before the land is purchased, the contractor is engaged, and the widget tooling is ordered. The business case for the investment includes projections of revenues and costs, and the investment decision is based on those projections, incorporating the time value of money through a risk-adjusted discount rate. Ultimately, the business must make a go/no-go decision: proceed with building the factory, or not.

Although the factory-building project can be cancelled before completion, any money spent up to that point is likely to be have been wasted. The full investment must be committed before any value is delivered. The factory cannot begin operating or delivering value until the roof is put on, the power is connected, the switch is flipped, and the first batch of widgets are delivered.

Now let’s look an IT investment—say, an investment in internal-use software to accomplish a particular business objective. For this decision a point-in-time business case might also be prepared, but—and here is a crucial distinction—there is no need to commit to the entire investment up front. Instead, an IT investment can be staged in increments. Parts of a software system can have value independently of the remaining scope.

Unlike a widget factory, software can now be developed in a way that delivers results almost immediately, with each capability deployed to users as it is built. The outcomes of the “minimal viable product” that is deployed can be measured immediately, and then additional features invested in based on those outcomes.

This gives the company the ability to constantly re-evaluate the business case as the project proceeds. It can stop investing—and declare success—at any time if it decides that enough value has been delivered; or if circumstances have changed and the objective of the investment is no longer important; or, if the company comes to believe that the investment cannot succeed, it can stop investing before the full investment is made.

In this way, the IT investment is actually a series of small investments tied together by an investment theme, where each increment of the IT spend creates both a (small) asset and the option to continue investing further increments of funds. Another way to think about it is the IT investment is creating an immediately usable asset and an information asset that helps the company decide whether to continue investing.

The business’s capital budgeting process should reflect this difference. For the factory, the business case contains all of the information available to make a decision at that given time, and the risk is consequently high; thus, the decision should be weighed carefully. For the IT project, the risk is low (the risk of just one increment of funding) and buying further information is cheap.

But When is it Finished?

Another difference is that, unlike a factory, IT investments never really result in a finished product. The IT investment can be put to use, and start delivering value, almost immediately, but features can continue to be added indefinitely, meaning the IT investment is never complete, even though the business is already receiving value from it.

I have had a CEO ask me, “Why do I have to keep spending money on this (IT) system even after the project to deliver it is over?” I understand his question—the ability to keep spending seems, at first, like a disadvantage, but it is quite the opposite. Instead of building a new IT system (a new factory) every time business needs change, the business can simply change current features or build additional features on top of the existing system. The IT system willkeep changing with the business’s needs.

Also, unlike a factory, the IT system does not require maintenance (despite the terminology often used). The IT system, if left alone, will continue to perform exactly as it did when it was created; the factory will not. The business constantly needs to spend money on maintaining the performance of the factory, even though this spending typically does not deliver more value for the business. The “maintenance” on an IT system is actually the alteration or addition of features as the business’s needs change, each with the potential to increase value delivered to the business. You can also simply let it become obsolete.

The useful life of an IT system therefore is in many ways undefined—it starts being used early in development and is expected to remain productive…how long? In theory, indefinitely, if the enterprise keeps changing it to remain consistent with the business’s needs.

Porous Boundaries

The boundaries of an IT system have also become harder to define. A factory has walls, within which is contained everything used to deliver value from that factory. A piece of software, in today’s best practices, actually comprises many smaller software components, called microservices, each operating independently behind the scenes of the larger system. You could say that the IT system is really just an orchestration of these smaller components.

But here’s the kicker: those microservices are designed to be reusable, so each microservice can become part of any number of different systems. Each microservice has its own life cycle and its own roadmap of features. So the IT asset itself, the system, is really an amorphous blend of building blocks that might have been developed specifically for it, or developed independently of it, and which might be part of other assets.

Working in the cloud breaks down the boundaries even further. The physical infrastructure that might before have been considered part of the IT system is now virtual. It can be scaled up or scaled down as needed, and often disposed of entirely (note that the case is somewhat different when the enterprise is using Amazon Reserved Instances). It is common for a company to use “autoscaling” features in AWS that automatically adjust the amount of infrastructure provisioned for the system, increasing its size and power when the load on the system is heavy and decreasing it when the load is light.

The cloud also offers services that can easily be incorporated into the system the company is developing. These building blocks are like the microservices I described before, except that they are fully managed by AWS. They include functions like machine learning, analytics, security, IoT, and databases. In the area of machine learning, AWS has been working to “democratize” what was previously available only to companies who invested heavily in artificial intelligence and had specialized employees with expertise in the subject. Now, all developers can include machine learning in their applications just as they would other microservices.

So the boundaries of a software system have become much harder to delineate. The system incorporates a number of building blocks that might be reused from other systems (or be intended to be reused in future systems), might be provided by AWS or another cloud provider, and might run on virtual infrastructure that might grow or shrink automatically or manually.

IT in a Box?

The idea that an IT system is similar to other capital investments—our widget factory—has led businesses to think of IT applications as “products,” with fixed boundaries and a fixed scope of features that could be specified in advance and purchased as a whole rather than developed in-house. This, in turn, has often led businesses to think that they were faced with a build-or-buy decision, as they often are in capital allocation decisions.

But off-the-shelf products still have to be integrated with the enterprise’s other systems. They must be configured and customized to fit the company’s needs. And, most challenging, they have to be enhanced and changed as the company’s needs change. With a third-party product, the business is left hoping the vendor’s roadmap will meet its future needs, while it continues paying licensing and maintenance fees. Or the business is forced to make in-house customizations or develop work-arounds to circumvent the product’s limitations.

Buying off the shelf still makes sense for certain types of systems—accounting and ERP, for example, where the rate of change is low and the feature needs are common across companies. But even in those cases, the need to integrate, manage, customize, maintain, enhance, and change the system—and the spending required to do so—makes it very different from other capital investments.

In Conclusion

So IT projects, whether they are about custom software development, infrastructure, or deploying off-the-shelf products, are unique among investments. The uniqueness stems from the malleability, or infinite changeability, of software. The “thing” invested in is not really a thing, but a set of options for additional investment. It can be delivered incrementally, through staged, lower-risk investments. It has porous boundaries, requires integration, and is composed of reusable building blocks. Its specifications can be changed on the fly before, after, or while it is being built.

These characteristics are all benefits to the enterprise. Staging investments reduces risk and takes advantage of additional information gained as the project proceeds. Treating IT systems as collections of smaller units, each of which can be included or not included, makes it possible to avoid creating unnecessary features.  And reusing microservices saves money and speeds up delivery. An organization should take advantage of these characteristics to reduce costs and risks and to get to market more quickly.

Making one-shot, monolithic investment decisions—that is, treating IT systems as if they are just another capital investment—leaves money on the table and adds unnecessary risk.

–Mark
@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value