Software Technologies - Home
Measuring Productivity
Christof Ebert, Managing Director, Vector Consulting Services
JUL 01, 2013 09:39 AM
A+ A A-

You cannot control what you cannot measure. This holds especially for software productivity, where many companies struggle how to measure and improve it. Often we in software and IT fail to understand that productivity relates to delivering value – as opposed to collecting features and increasing complexity. This blog will provide some guidance and hints for measuring productivity. Let me know of any further question or stimulus arising from this blog.

Measuring productivity is mandatory to understand and improve your cost drivers. Only your own productivity measurements and analyses can provide concrete efficiency levers to improve your specific situation. Measuring productivity is difficult – especially for software and IT, where value is often difficult to grasp.

Productivity measurement is used on the macroscopic level such as for benchmarking organizations or projects. And it is applied to the microscopic level, such as for estimating work packages, identifying overheads or analyzing what product components are overly expensive. Productivity improvement needs precisely defined productivity measurements – which are based on SMART improvement goals, that is specific, measurable, attainable, relevant and timely goals. Do not measure before you have specified your overarching improvement goals.

Here are a few guidelines on measuring software productivity:

1) Take a value perspective when determining output. Productivity is output over input. Output is about delivering value and doing the right things. It has to do with perception of your stakeholders - macroscopically and microscopically. It is about being effective. Input is the way you create this output. It relates how well you are working. It is about efficiency. Therefore I strongly advocate taking a value-oriented perspective for productivity measurement and improvement. Don't simply measure your "output" by what you physically deliver, because down the line clients don't buy software. They always look for solutions to needs.

2) Measure productivity to achieve improvement goals. It is of no added value due to its many facets. Imagine you have a Function Point driven productivity baseline. Does it tell you anything where and how to improve? Does it allow to benchmark? Hardly. Therefore take an objective-driven approach to measurement and first clearly understand and define what you really need to do. If it is about reducing cost, your baseline will analyze cost (e.g., Cost of non-quality, rework, variant management, etc.). If it is about evaluating tenders of competing teams, solutions or suppliers, you ought to consider quality or SLA levels, schedule impacts, etc. which all impact productivity. If it is about improving the productivity of your engineers, you need to look to work environment, time pressure, competences, etc.

3) Consider context and environment when setting up measurements. As a first shot we are using for clients' productivity baselines, longitudinal studies, benchmarks and supplier evaluations our tools to provide a defined and repeatable "Productivity Indicator”. We are setting up models, often based on function points or similar tangible outputs, which take into consideration the relevant environmental factors. Environmental factors include for instance the desired quality of the software, distribution of locations, reuse degree, etc. Comparing and benchmarking organizations or projects without considering such factors means comparing apples with pears.

With these rules in mind you can derive your own productivity baseline. In our client projects we often use Function Points (as output) by person weeks (as input). Alternatively in industry we are using normalized requirements, such as feature count, etc. On the microscopic level we look to work time for comparable results such as FP, test cases, engineering change requests, etc. Make sure the input measure is a real effort figure, including overtime and excluding holidays. You can later always normalize to calendar time, but never catch up if you did not consider all effort and time which was invested as input. Looking to trends and outliers, rather than to the absolute figures, typically provides more insight to improving productivity.


Our book "Software Measurement" at Springer further details the productivity measurement concepts with best practices, concrete productivity improvement proposals, many industry case studies, hands-on measurement examples, and benchmarks both for IT and engineering organizations.


Jack Welch's "Winning", from HarperCollins, is a great insight from the macroscopic level as it tells us how business leaders are using productivity benchmarks to evaluate organizational units. He underlines the people factor and how to align strategy with operational management and performance measurement. The chapter on Six Sigma is a must-read for all in process improvement and change management.

IEEE Software theme issue on “Software Analytics”:

Free white papers and resources:


Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world to sustainably improve product strategy and product development and to manage organizational changes. Software measurement and productivity improvement are one of his focus areas, with which he appears as a frequent keynote speaker and evangelist with many companies. An IEEE senior member, he serves on a number of advisory and industry bodies, teaches at the University of Stuttgart and has authored several bestselling books including his reference book “Software Measurement” published by Springer.

Contact him at




[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment: