The CIO-CFO Conversation: Capturing the State of IT

It’s important for CIOs to be able to convey the current state of IT, particularly in conversations with their CFOs. I’ve written before about the CIO-CFO dialogue and how it should change in the digital age. In the past, CIO-CFO conversations have generally focused on budget planning and execution, or on multiyear capital planning. But these funding conversations need context; really, it’s the current state of IT, when considered alongside the business’s strategic imperatives, that determines budget requirements. The state of IT also determines how effectively new investments can be deployed. And it’s the current state that determines what risks the company faces. All of these are critical pieces of information for the CFO and the rest of the C-suite.

This current-state description provides a kind of “balance sheet” view of IT, rather than the cash flow view in the budget or capital plan. Income statements and cash flow statements cover a period of time, generally a fiscal year. A balance sheet, in contrast, is a snapshot of a company at a particular moment. Just as the assets on a company’s balance sheet are used to generate future profits, IT assets can be used in the same way. I don’t mean assets in the formal GAAP-approved sense, but the real economic assets that include IT systems (considering both their functionality and their quality), as well as IT people and their skills, the IT architecture that ties it all together, IT processes and maturity, security…and whatever else might be important for the company’s future. Logically, a conversation about this current state of IT should precede budgeting and capital planning.

Perhaps we rarely have this conversation because at some level we believe it’s too technical for the rest of the C-suite. Or because it might reflect badly on the CIO (we know that the state of IT is never what we really want it to be, right?). But if the CIO and CFO are trying to build a relationship fit for the digital age, they’ll need to find the common language to communicate about the IT asset. The CFO must learn to speak some “tech” because tech is increasingly central to business, and from my experience, CFOs are generally happy to do so. And the CIO must frame this IT balance sheet in terms of its impact on the business.

When the CIO and CFO don’t share an understanding of the state of IT, poor business decisions can follow. It’s always been extremely difficult to make a business case for, let’s say, a piece of technology that isn’t directly related to developing a new business-facing IT capability. But it’s much easier to do so if everyone understands that the gap in the current state of IT puts the company’s business plans and security at risk. Or that the current systems hinder the company’s agility or the speed at which the company can seize revenue-generating opportunities.

This lack of shared understanding is at the root of miscommunications about what we call technical debt. In an earlier post I talked about how we use that term and why it’s irritating to CFOs. Another way to think about the problem is that technical debt sounds transactional: we incurred it in a transaction (taking shortcuts to get to a release more quickly) and we’ll have to pay it off in a transaction (refactoring). But the CIO-CFO discussion should really be about the state of the IT assets and how they differ from the ideal—what I called technical and functional delta—and what their consequences are for the enterprise. Usually these consequences include risks, a lack of agility, and increased costs for future IT work (or if IT budget and capacity are fixed, more constraints on what can be accomplished).

There’s an important law of IT to keep in mind: IT systems always need more changes over time than you expect. Businesses have often made the mistake of thinking of IT systems as something you buy or build and then simply “maintain” over time. But this is the wrong mental model: an IT system is more of a living thing that has to change as the company changes. And the company has to change as its customers, competitive environment, regulatory environment, and the technology landscape change. These forces for change have become all the more demanding in the digital age, when external changes are more or less continuous.

As a side note: the idea of “maintaining” an IT system never made much sense anyway. You maintain a car because if you don’t, its performance will degrade—it will be worse at doing what you bought it to do. But software doesn’t degrade. The problem is not that it stops doing what you originally bought it to do: the problem is the opposite, that it continues to do what it always did, even when the world changes. You need to advance it, not maintain it.

In any case, as I said in my earlier post, the company’s IT asset usually differs from what would be ideal for the business at any given moment. Perhaps the company’s IT systems lack certain capabilities, causing workarounds or forcing the company to forego business opportunities. Or maybe the IT systems have imperfections that reduce agility and resilience and make future IT work expensive and risky. This is another way of saying that company always has “legacy” IT. As soon as an IT system is implemented, it starts to diverge from what would be ideal, given changes in the company’s business or the technology landscape.

That’s OK, in the same sense that gravity is OK—we’re stuck with it. Not all “delta” needs to be eradicated. After all, companies operate despite their technical and functional deltas. Decisions about what delta to eliminate are decisions about the future; about how the company will generate future revenues and incur future costs, about risks the company bears. They may even be decisions about the very survivability of the company. In this sense they are very much decisions that the CFO and Board of Directors must consider.

The only way to address these crucial concerns is through a collaboration between the CIO and CFO. The CIO is in the position to know what delta exists and what its consequences are, and to be able to remedy it. The CFO is in the position to evaluate the impact of those consequences on the company’s financials, to communicate to the CEO, Board, and shareholders what risks exist and how they will affect future profits, and to finance the remediation. The CFO can’t place the responsibility for good decisions about risk and future returns on the CIO alone, especially since mitigating those risks or supporting those returns may require an allocation of resources. The CIO can’t avoid involving the CFO in the decision making by hiding behind technical mumbo-jumbo because the decision critically affects CFO concerns like risk and future cash flows. When it comes to reducing the company’s risk and getting the most out of future IT investments, the CIO shouldn’t need to beg for money. It’s the CFO’s job to invest in risk reduction and future returns.

But sharing this responsibility can only happen if the CIO makes clear the state of IT and its implications.

Incidentally, there’s no need to focus just on the negative aspects of the IT asset. Even if it’s imperfect, the company has a collection of IT capabilities that give it a foundation for future execution and a set of strategic options. The CIO-CFO conversation should also cover what competitive and execution advantages the current IT infrastructure presents. A company is wasting good resources if it doesn’t take advantage of its IT asset.

In my next post, I’ll talk about what aspects of the current IT assets are important to communicate in this IT “balance sheet” and how to communicate them.

—Mark

Twitter | LinkedIn | Blogs | Email

More on this topic

The CIO and CFO Conversation, Mark Schwartz

The CFO and CIO: Partners in Success, Mark Schwartz

The CIO-CFO Conversation: Technical Debt—An Apt Term?, Mark Schwartz

The CIO-CFO Conversation: What to Include in the IT Snapshot, Mark Schwartz