The CIO-CFO Conversation: What to Include in the IT Snapshot
As I said in my last post, the way we’ve looked at IT investments and budgets has been missing some crucial context. It’s the current state of IT, the “balance sheet,” so to speak, that determines what spending and investments are necessary when considered alongside the company’s strategic imperatives. A conversation between the CIO and CFO about reducing technical debt can’t happen before a conversation about what technical debt exists, what impact it’s having or will have on the company, which technical debt is the highest priority to erase, and so on. That’s the “balance sheet” conversation.
I’m not referring to the GAAP balance sheet that’s part of the company’s required financial disclosures. I mean the economic balance sheet that accounts for the state of IT at the current moment—its strengths, its weaknesses, and the impact that these have on the future performance of the business. You can also think of the balance sheet as a snapshot or a SWOT (strengths, weaknesses, opportunities, and threats) analysis. The structure isn’t important; just focus on communicating the essential information.
The IT snapshot, although it’s a static, point-in-time view, should look ahead: home in on what the state of IT means for the business’s future rather than how you got where you are. And the snapshot should include only what is relevant to the business. It might be true that no one on the team knows much about quantum computing, but unless you think quantum computing might be relevant to the company’s reasonably medium-term future, you can leave it out.
What might the snapshot include? Here are some ideas on what questions I think the snapshot should answer, regardless of its format.
People are always a good starting point. Are IT employees knowledgeable, talented, passionate, and motivated? Do they have the skills you’ll need them to have in the near- to mid-term? It doesn’t really matter whether they have the skills you need today; we’re talking about assets that you’ll use to generate future profits. Is your team diverse and inclusive? Are employees empowered by process or bogged down by it? Do you have a talent pipeline? Is your branding as an employer sufficient to attract top talent? Are you paying enough? Are any of your employees so integral to your business that they would significantly hamper the company if they left? Given what we’ve learned from the COVID-19 pandemic, we also need to ask whether employees have the flexibility to work from wherever they’re most productive, and whether they’re equipped with the right tools. Considering all these questions together, what we’re really asking is whether you can get the maximum contribution from your people in the future.
Remember that your constraints are likely to be people rather than cash.
Systems and Functions
What are the key IT systems and services that support your business? Not all systems, just the vital ones—things that are material to the company’s future capabilities. To communicate this effectively, the CIO needs to do some selecting and focusing; this is an art. Are the current IT systems truly meeting today’s needs? (Hint: they are not.) Here, don’t just think about bespoke software. Are the off-the-shelf tools you’re using meeting your needs? (Are they really? Or have you just gotten used to them?) What ongoing cost burdens do your systems impose? Licensing fees? Maintenance fees? Is there infrastructure that you’ll need to refresh (hopefully not—you’re working in the cloud!)? What do your pay-as-you-go infrastructure costs look like?
This is a good time to look at whether you can reduce costs by moving to open-source software or cloud services, especially when it comes to databases. Are your systems highly available and resilient? Are you prepared for continuity of operations when a disaster strikes? Do you even know (have you tested)? Now project forward a few years. Do you have the capabilities you’ll need?
Looking at the company’s strategy and the evolution of its markets—and the competitive dynamics in those markets—in what ways will you not be able to meet its needs? A big mistake IT organizations sometimes make here is talking about the backlog of IT requests or requirements that have been floated, IT’s ability to “manage” its demand. If IT is a service organization accepting “demand” from internal “customers,” then it never has enough capacity to meet all that demand, and the CFO will probably view that as acceptable. Instead, the question I’d ask is: In the CIO’s judgment, will the current systems and the capacity of the IT department be able to meet the company’s critical strategic and operational needs for the coming years? What does the marketplace require? What do the C-suite’s strategic intentions require? And on the flip side, what strengths can the company take advantage of to build its future market position?
What risks and limitations does your current technology pose? I’m talking here specifically about the internals of your systems—the functional limitations are already addressed by the questions above. Are you using an operating system version that’s about to be deprecated? Are there bugs in your code that are likely to disrupt business operations? Is your availability adequate? Is your code written in a programming language that no one knows anymore? Will your infrastructure scale to meet next year’s plan for increasing market share? How will your current technology hold you back? What will you have to spend money on in the future? These are aspects of the technology asset that pose risks or affect future cash flows.
Everything I’ve said so far has pertained to “known knowns”—things we think we can foresee given our best judgment. But now we arrive at the true heart of the digital age. We don’t know plenty of things. How will your skills, systems, and technology prevent you from responding to change, disruption, crises, and so on? Agility is an asset with tremendous business value in the digital age. It will determine costs and revenues in the future. Yet we don’t know precisely how. What are the barriers to agility? Or what aspects of IT impair your agility? Perhaps IT has contracts with vendors. What commitments are in place? Is there flexibility? Is the company locked into specific sets of requirements long-term, or can it change them? Can costs easily scale up and down with the business?
Security is difficult, but essential, to treat in a snapshot view. In my experience, the Pareto principle applies. There are well-understood hygiene practices that prevent by far the greatest number of breaches. Others might have a different list, but I’d want to know things like: (1) How simple is the company’s IT architecture and code? Simplicity is good for security. (2) Is there good control over identity, authorization, and access? (3) Is there transparency into what’s happening on the company’s networks, and is there good logging and monitoring in place? (4) Are IT systems patched and up to date and do they stay up to date? (5) Are there business processes that promote security (e.g., deprovisioning accounts when employees leave the company)? (6) Is security largely automated? (7) Do too many people have privileged (administrator) access to systems? That is, is there insider threat, intentional or through error?
Everything I’ve talked about can also be seen through the lens of risk. For example, a lack of agility is a risk—if the unexpected happens, the company may not be able to respond to it. If systems are convoluted or based on old technology, there is a security risk. Which of these risks should be disclosed to investors? Which should you consider for potential investments to mitigate risk? The temptation in IT has always been to focus on IT project risk, but I’m talking about business risks posed by the state of IT. “The project may be delayed” is not a risk; the risk is that a critical capability (a materially critical one) will not be present when needed. In other words, the relevant risk is not an IT system risk, but a possible impact on business execution.
Opportunity Costs and Costs of Delay
Negatives have costs! Every day that you don’t have something that would increase business value is, well, destroying business value. Suppose you’ve learned that switching to a new call center would have a benefit on revenues and costs. Every day the company spends planning, vetting the business case, or simply not making a budget available is destroying business value. So where are the gaps in our “balance sheet” that will cost us opportunity dollars? What aspects of our governance, investment process, skills, and platforms will cause costly delays?
What I’m not including in the snapshot
You might notice that in this discussion I’m not really talking about which spending is for “keeping the lights on” (KTLO) rather than innovation; I’ve focused on meeting future needs versus not meeting them. KTLO spending that helps drive the business is, in a sense, positive, even if we want to reduce it when possible. The snapshot should make clear what drives that KTLO spending and where there are opportunities to streamline it, but KTLO is not bad in itself. I’m also not classifying potential spending as CAPEX or OPEX in this snapshot. In a sense, I’m implicitly capitalizing everything for the purpose of this exercise—for example, I’m treating people skills as an asset. The accounting treatment of spending is probably best left for a different discussion.
How This Focuses the Conversation
Instead of talking at budget time about remediating technical debt, you can use this snapshot or balance sheet to promote a discussion about what technical and functional delta currently exists, its impact on the business or its risks, and what might be done to remediate it. When budget time comes, most of the “business case” is therefore already in place.
The process of examining the snapshot and developing a strategy to oversee its evolution fosters collaboration between the CIO and CFO. They can agree on necessary investments and metrics to measure the success of those investments.
The CFO can walk away with a better understanding of risk and opportunity. By looking through the accounts on the IT “balance sheet,” they can see where the risks are. This is important for transparency—everyone, even investors in some cases, should know about the risks. It also opens the question of where there should be spending for risk mitigation.
The IT asset is owned by IT, but annual costs are not: the IT asset affects the entire company’s costs and revenues, and the snapshot should be viewed from that perspective. A decision to invest budget dollars in building an IT asset is a decision to recoup a company-wide benefit—a dollar spent in IT is a dollar spent to get a return elsewhere. Mitigating a security risk or a tech debt risk is not an IT risk mitigation; the risk is a risk to the whole company. In short, the IT asset is stewarded by IT but is used by the whole company. In this sense, there isn’t really an IT budget, but rather a number of IT spending decisions that affect the entire company’s budget. The snapshot should help make this clear.
The foundational CIO-CFO conversation is not about the IT budget. It’s about the IT balance sheet and what needs to happen dynamically to support the company’s goals. It’s about the economic assets and liabilities the company has as a result of its technology. The CIO does not “want” to invest in reducing tech debt or in particular technologies. Rather, the CIO is working with the CFO to make sure that tech debt does not unduly affect the future financials of the company, and that the right technologies are available to support the company’s strategy and operations going forward. The CFO and CIO together can identify investment opportunities that will earn a positive return and direct investment there.
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: Capturing the State of IT, Mark Schwartz