Frequently, IT shops have a difficult time convincing their business users of the value of IT. It is straightforward for a businessperson to look at the cost of IT, which is readily available but not have a good reference for the benefits and the overall value of IT. This lack of a good reference then leads to further concerns on IT budgets and investment. As CIO, it is imperative that you provide transparency on the benefits and impacts of IT so your customer and the business team can understand the value of IT and properly allocate budget and investment to make the business more successful. Yet frequently, IT does a very poor job of measuring IT impact and benefits, and when it is measured it is often done only in technical metrics which are not easily translated into understandable business metrics.

A good area to start to provide transparency to your business partners is with your production services. Typical IT metrics here are done only in technical terms not in business terms. For example, you often find availability measured in outage time or percentage or as the number of incidents per month. And while these are useful metrics to do some technical analysis, they are poor metrics to communicate business impact. Instead you should be providing your production metrics to your customer in business form. For example, you should report on the key service channels that are delivered to the end customer (e.g., ATMs, retail points of sale, call centers, etc) and the underlying metric should be customer impact availability. You derive this metric by counting the number of customer interaction or transactions that were successful divided by the total number of possible customer interactions or transactions for that time period.

Specifically, take an ATM channel as the example. Let’s assume there are normally 100,000 customer transactions in that month. If the ATMs were down for 1 hour that month and there would have been 1000 customer transactions that normally would have been completed in that hour then the customer impact availability was 99% (= (100,000 -1,000)/100,000). Just as importantly, your business also knows 1,000 customers were impacted by the systems issue. And if the outage occurred at peak usage — say 1 hour on a Friday evening rather than 3 AM on a Sunday, you may have 2,000 customers impacted versus 100. And your business-oriented metric, customer impact availability, would show this rather than the constant view that a system time availability metric would show. But this is critical knowledge, for you and for your business partners. You will have to collect information on how your customers use your service channels and understand daily, weekly, and seasonal variations, but you should know this anyway so you can better plan capacity upgrades and implement changes and releases.

You should apply the same criteria to your project delivery. Typically, IT shops only provide on-time and on-budget metrics. And these are often flawed because they either accept major changes through the project lifecycle (what I call ‘drawing the bullseye after the arrow is shot’) and they take no account of whether the project is ‘on-function’ or on-quality. Even worse, few shops track if the promised benefits were delivered or the expected revenue materialized. Thus making it very hard to assess if you are getting the expected return on investment. To remedy this, partner with the CFO office and tackle the large projects and big investments first. Insist on tracking with the CFO’s office the original cost, timeframe, benefits and and function and quality targets for this subset of the projects. If there is a major change to scope or requirements, note the change and track the additional revised cost, time, quality, etc. Then at project closeout, the project is not completed without a full assessment on how well you met the original estimates and any lessons learned on why not. It may also require a revisit of the benefits and revenues 6 months down the road to properly assess them. This information is extremely valuable to then have for assessing future investments. Is the business consistently over-estimating the revenue that will result? Is your team often underestimating the time to get projects completed? At the end of the year, you will be able to communicate not just these trends back to business but also you can outline that for X spend on large projects you delivered Y in benefits (with Finance’s backing). That should provide a compelling value statement if the projects were well-chosen. And if not, you now have the rationale to adjust the company’s investment process.

Similarly, for the ‘routine services’ of IT (delivering small systems, help desk services, desktop support, etc) you should provide metrics that are business relevant.  Provide the cost of the routine services as a cost per user (e.g. cost for desktop service per user per year) or cost per service (cost of a help desk call).  Go further and enable the business team to understand the impact of investment in the services by defining the number of staff hours of work saved. If you are implementing self service (e.g. password resets as an example) you may have a cost save (reduced help desk calls and thus fewer help desk staff, but you should really have reduced staff time to reset and less staff downtime as a result (improving staff productivity and engagement). Similarly, a new departmental workflow system should reduce both staff hours to process say an HR transaction but also substantially reduce the wall time of that transaction (again driving improved productivity and engagement). These are often neglected areas within a corporation that by translating into business metrics (staff hours saved, wall time reductions) will make visible the business benefits.

By routinely expressing what IT does in terms of business metrics, you will enable you business partners to understand the impact and value of IT on their customers and services. It will drive better decisions on how much and where to invest in technology. And it will also raise the level of business awareness of your team. When they know an outage impacted 32,000 customers, that comes across as much more material and important than a 40 minute router outage. You can adjust or denote the metrics as appropriate for your business. For example, if you are handling large financial sums then system outages may be expressed in terms of the sum of the financial amounts delayed or not processed. Further, several large Financial Services firms with robust shops report not just the customer impacts but also correlate if there was an industry cause and impact as well as if a portion of the functionality was available (e.g. you could access the ATM and withdraw cash but not see your balance).  The key is to put your primary measure in business relevant metrics.

What business relevant metrics have you used with success? What hurdles have you encountered?

I look forward to your thoughts and success with more transparent metrics.

Best, Jim