In some professions, there are metrics that one can use to determine an individual’s productivity. If you’re a widget maker, for instance, you might be measured on how many widgets you can make in a month. If you work in a call center – how many calls did you answer, and what’s your average handle time? These are over-simplified examples, but even if you're a doctor, you may be measured on how many operations you perform, or how many patients you can see in a month. Whether or not these are the right metrics, they offer a general picture of how an individual performed within a set timeframe.
In the case of technology, however, it becomes almost impossible to measure a person’s productivity because there is so much variability. For example, it may be tempting to measure a developer's time by lines of code built. But, depending on the coding language, one line of code in one language versus another might be significantly more or less time consuming or difficult.
Has it always been this nuanced? Many years ago, you might have heard about or experienced IT measurement in terms of function points. These measurements were about the critical features that developers were able to create. But that, too, is becoming harder to do in today’s environment, where developers are often encapsulating logic that may already exist, such as integration of function points through a vendor. This makes it harder to measure productivity based simply on the number of function points built.
These two examples shed light on why CIOs sometimes struggle when we talk to our peers about IT productivity. Consider this hypothetical conversation:
IT leader: “Wow, I think this developer is great.”
HR: “Really? What do they do?”
IT leader: “They built this excellent application.”
HR: “Well, are they better than the other developer who built ten applications?”
IT leader: “That depends on what you mean by 'better.'”
Typically, when in the midst of a conversation like the above, there is so much subjectivity involved that it's difficult to answer the question. This is just the tip of the iceberg when it comes to measuring IT performance in a meaningful way. And it doesn't just make conversations harder – it makes it harder for CIOs to showcase the value of their organization to the business.
This certainly isn't a new problem. I’ve been trying to figure this out for the last 30 years, and I’ve mostly come to the conclusion that we really shouldn’t bother with productivity – we'll never get there.
I believe we need to change the conversation and stop trying to speak in terms of throughput and cost and productivity but instead, focus on measuring the overall business value of IT. Again, it won't be easy. Business value realization is a hard thing to do. But if CIOs can partner with the business to figure that out, then attributing real value can become more of a science than an art form.
