A few weeks ago, I met the head of the California Legislative Data Center Project Office: an impressive guy named Alex Chompf. He was giving a talk about IT portfolio management and metrics he found useful tracking projects in the portfolio he is responsible for overseeing.
His talk was polished and the metrics he used were interesting, but one of his side comments really caught my attention. He pointed out that, in the private sector, the CIO (chief information officer—head IT guy) often reports to the CFO (chief financial officer—head bean counter). CFOs are often formally trained MBA types who have strong theoretical and practical knowledge about finance and how to evaluate investments (net present value, discounted cash flow, decision model analysis, etc.). Alex said, “Unlike most business investments, IT investments ‘remember’ prior investments.”
He went on to point out that if an organization invested in gold mines last year, it might be reasonable and appropriate to balance its portfolio by divesting itself of gold and moving its investment to petroleum this year. The organization’s portfolio is not offended or disrupted by the change. Contrast that with investing heavily in building a data center in Colorado last year, then switching this year to a cloud strategy.
This was a good point and worth sharing. It is dangerous to describe or assess IT investments without context. Part of this relates to how sloppy some of us IT geeks can be at describing IT investments. As a computer scientist, I was writing compilers and operating systems in college with the other computer nerds while the business nerds were learning to describe tangible and intangible consequences of a proposed investment. It’s a skill...just like compiler construction, and, like compiler construction, it is not a skill you are likely to teach yourself casually. As a result, it’s easy for my IT nerd brothers and sisters to gloss over abstract business concepts like economies of scale and total cost of ownership when building an IT project proposal so that these factors—both positive and negative—are excluded from decision making. This often results in poorly informed decisions.
Part of this is the fluid and uncertain nature of IT; we are a disruptive technology. It is more difficult to forecast the return on investment (ROI) of an IT system investment than a cement factory. The assumptions about the build cost, throughput, life expectancy, and operating costs of a cement factory can probably be estimated to within plus or minus 10 percent for a five-year ROI calculation—maybe tighter than that for experts in the industry. Anyone who tells you that they can predict those attributes that precisely for a large IT system is lying or foolish. There are too many moving parts in technology that are moving too fast in different directions for us to credibly assert costs five years out with unflinching confidence.
The other problem with our approach is that we often fail to explain the implications of an investment because we are trying to “stay out of the weeds” for our unwashed masters who couldn’t build a compiler if their lives depended on it. But there is a difference between staying out of the weeds and doing sloppy analysis.
For example, if we invest heavily in ERP system A it might be tempting to downplay the significant investment required to understand our organization’s business processes to configure the system as a one-time investment, as if the work wouldn’t need to be revisited if someone later decided to swap products. As a consequence, the marketing guy for a competing ERP product B might try to compete and ultimately displace system A by pointing out that the annual licensing fee for B is lower, glossing over the huge cost of swapping out the current system. While your system “remembers” that investment in A, the whole business case for system A may unravel if you swap it out too soon, given the huge up-front investment often required.
These “hidden” costs of reconsidering prior choices can be substantial, and they often get omitted because they are embarrassing or not well understood by many IT managers. I think the only defense, and the meaning I made of Alex’s talk, is to work with accounting subject matter experts and take the time to develop more robust business proposals for your IT system that are explicit about costs and assumptions. A difficult challenge, but one that we must embrace as IT managers if we are going to support informed business decisions in the executive suite.
