Today I was reading Wall Street & Technology and I stumbled into an interesting article by Howard Rubin, "How to Assess IT Productivity". It looked very interesting, but when I finished reading it, I had more questions than answers. The author makes a good point
Defining an accurate (an universally agreed-to) measure of information technology productivity is perhaps the 'holy grail' of IT measurement.That's absolutely correct. If you're a manager, or have been a manager, then you know that is true. He composed a list of "6 Core Assessment Areas for Measuring IT Productivity":
- Computer Technology Measures of Processor Economic Efficiency
- Supply-Side Measures of Reduce Economic Efficiency and Productivity
- Demand-Side Measures of Economic Efficiency And Productivity
- IT Portfolio Measures of "Run the Business" vs. "Change the Business"
- IT Budget Agility Measures of Fixed vs. Variable Costs
- Operational Leverage Measures
This is where I started doubting the article. The truth is that there is really not a right answer for "IT productivity." It is one of those subjective questions where you get many answers and probably all are correct. The answers will vary depending on the companies and/or its department. In other words, its all about context and domain. But, what if we go back to basics. How about the following measurements:
- Release cycles: how often we make deployments of new features or fixes
- How many bugs were introduced on the release/deployment
- Turn-around time on bug fixes: how fast do we find them?
- Performance and scalability of application: how fast is our application? How much can it handle?
- Hight Availability measurements. For example, what is the turn-around time for an event failure (going from primary to secondary)
These might not be "productivity" per se, but they are value added to our customer, and they should be monitored. You might even considered them as quality rather than productivity. But one might argue that they go hand-by-hand. Quality has a tremendous impact on productivity. In my industry (financial trading) we always go back to the 2010 Flash Crash which plunged the Dow Jones Industrial Average to about 1000 points due to an error on a high-frequency trading.
I really like what I read in Net Objectives:
Creating software is about delivering business value. Without some measure of business value, it's hard to determine whether the software has any.
Here are some examples of business Values:
- Increased revenue (sales, royalties, fees)
- Decreased expenses
- Using less resources
- More efficient use of resources
- Customer satisfaction
- Product promoters / satisfiers/ detractors
- Staying in business
- Avoiding risk
I like what Jonathan Rasmusson said in The Agile Samurai when wondering whether you are doing things the "agile way", instead ask yourself two questions:
- Are you delivering something of value every week?
- Are you striving to continuously improve?
At the end of the day, IT and productivity means what you and your company thinks it means.