Performance Measurement and the IT Balanced Scorecard

Performance measurement and the I-T balanced scorecard. This lesson is about the difference between measuring how busy I-T is, and measuring whether I-T delivered, and the exam tests exactly that gap.

Picture the quarterly I-T report as a wall of big numbers. Five thousand tickets closed, three hundred servers patched, ninety nine per cent of changes on schedule. Leadership nods. Then a director asks whether any of it made the business run better, and the room goes quiet.

Because those numbers measure how busy I-T was. They do not measure whether I-T delivered. Good performance measurement ties to business outcomes, not to the volume of activity, and that distinction runs through the whole lesson.

Two indicator types appear constantly, and questions turn on telling them apart. A key performance indicator, a K-P-I, is a lagging measure. It tells you how well an objective was met, after the fact. Availability achieved, projects delivered on time. It looks back at outcomes. A key risk indicator, a K-R-I, is a leading measure. It warns that exposure is rising before the risk materialises. A growing backlog of unpatched vulnerabilities, rising turnover in a critical team. It looks forward at emerging danger.

So here is the shortcut. A K-P-I tells you how you did. A K-R-I tells you what is coming. A good measurement programme has both, because K-P-Is alone let you discover problems only after they have already cost you.

Now, measuring I-T purely by cost and financial return misses most of what I-T is for. The I-T balanced scorecard corrects that by measuring I-T from several perspectives at once, so that I-T is judged on the value it delivers and the capability it builds, not on cost alone.

The point is balance. Financial measures sit alongside non-financial ones. It is a management and governance tool, not a regulatory report, and it does not replace financial measures, it frames them among others. So what are those perspectives.

First, business contribution: the value I-T delivers to the enterprise’s objectives. This is the perspective that keeps I-T pointed at what the business is trying to achieve.

Second, user or customer orientation: how well I-T serves the people who depend on it. The best-run system in the world still fails if its users cannot work with it.

Third, operational excellence: how efficiently and reliably I-T runs day to day. And fourth, future orientation: the capability, skills and architecture I-T is building for what comes next. Business contribution, user orientation, operational excellence, future orientation. Four views, held together.

Which brings us to the trap, and it is the activity metric. Tickets closed and servers patched are counts of effort. They say how busy I-T was, not whether services were reliable or the business got what it needed. Adding cost to them gives an efficiency ratio, but still measures activity. Good measurement ties to outcomes: not, we patched three hundred servers, but, critical systems had zero exploitable vulnerabilities open beyond the agreed window.

So carry this away. When a metric counts what I-T did rather than what the business got, it is measuring the wrong thing, however impressive the count. Ask always whether the measure connects to a business outcome.