Balanced Scorecard for IT

The idea of applying a balanced scorecard to measure IT effectiveness is not new, but not many IT organizations have put this idea into practice successfully.

The key to operationalizing this idea is the ability to clearly see the linkage between IT objectives (as seen by a CIO) and overall business objectives (as seen by a CEO). This linkage is not always apparent.

In this post, I present a theoretical case to illustrate how such a linkage can be detected and measured using a balanced scorecard.

Consider a health insurance company. The following strategy map illustrate a cause-effect linkage between tactical IT objectives and corporate strategic objectives :

 

This strategy map shows three of the four perspectives of a balanced scorecard (for the sake of brevity the learning perspective is ignored).

• The finance perspective encapsulates the corporate strategic objectives of increasing market share and increasing margins.
• The customer perspective translates these finance objectives into customer-facing objectives.
• The internal process perspective has been depicted from the viewpoint of a CIO (i.e. these relate to the internal processes of an IT organization). It is envisaged that each business unit will have its own internal process objectives.

By linking these IT internal process objectives to the corporate customer and finance perspectives, a clear link has been established between the CEOs objectives and what the CIO has to achieve in order to enable to CEO to succeed!

The internal perspective effectively says that in order to support the customer and finance perspectives, the IT department has decided to embark on a program than consists of three projects:

• modernize the member portal
• modernize the EDI channel
• rollout an Enterprise Service Bus

Now we proceed to the measurement of the IT internal process perspective. In order to measure, we need KPIs and measures for each KPI.

Now we proceed to show the balanced scorecard which maps these KPI and measures to the various objectives:

The numeric gauge displays the measures (weighted measures actually) in a visual form. The snapshot shown above is as of the end of the program.

Note that this score-card illustrates the performance of one vendor used by the IT department (I am using IBM as an example here). In other words, this mechanism can be used to compare the performance of various vendors against each other and it has the advantage of being aligned with corporate goals.

The numeric gauge looks nice, but there is still too much data here to form any conclusions. Hence, we export this data to a spreadsheet and do a pivot table analysis on it to see if we can draw some conclusions.

Overall, the vendor gets a score of 83 on 100, considering all perspectives, all objectives, and all KPIs. Looks fine. Doing good on all three perspectives too!

Next we analyze how the vendor did on each of the KPIs:

Now we see that on Architecture and End-User Satisfaction the vendor has fallen below the 80% threshold. This requires further analysis. We need to find out which specific objectives they fared poorly:

Now we can see that the vendor has fared poorly on:

• the architecture of the new EDI channel as well as on the ESB architecture
• end-users were not very satisfied with the new, simplified enrollment process

In addition, we notice another lacuna – on the quality of the ESB roll out (overall quality score was 83% and hence gave no indication of this problem).

These are clear, quantitative measures of the performance a vendor around which constructive dialog can be initiated. That is the power of a IT balanced scorecard.

What are the key success factors for such a scorecard?

1. The objectives and KPIs should be carefully chosen. In this case Architecture was chosen as a KPI because three new technology initiatives were being rolled out by the IT department – EDI channel modernization, member portal modernization and ESB roll out.
2. Effective and quantifiable measures should be identified for each KPI. For instance “fitness for purpose” was identified as a measure of the Architecture KPI. Clear rules for quantifying “fitness for purpose” must be established and all concerned parties should agree to those rules. This is often the hardest part of a IT balanced scorecard exercise. In this case, “fitness for purpose” could be a score assigned by an architecture committee which reviews the architecture. The vendor should be given the opportunity to explain and defend their architecture in front of this committee. In other words, this is kind of like an examination which the vendor is graded on!
3. True “balance” should be ensured by combining leading and lagging indicators. Architecture is a lead indicator to Quality of Software. Measures related to responsiveness are a lead indicator for end-user satisfaction.
4. Once measures have been identified and agreed upon, metrics collections should be open and transparent, i.e. vendors should not question the accuracy of the measures post-facto.