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.
0 comments: