While productivity is a simple calculation, there are a few mistakes organizations tend to make. The five most common mistakes reduce the usefulness of measuring productivity, or worse can cause organizations to make poor decisions based on bad numbers. The five most common usage and calculation mistakes are:
1. Calculating productivity using inputs as outputs. Productivity is the ratio of output created per unit of input. For example, if a factory created widgets then labor productivity would be calculated as widgets per hour. A common software productivity metric is function points per person. Inverting the equation would yield a metric of people per function point which make very little sense. Solution: Repeat after me, productivity is output divided by input (a bit of snark). Other metrics use an output as a driver to predict usage of resources. For example, we calculate delivery rate (answers how fast the process delivers) by dividing calendar time by output.
2. Using aggregate or average productivity for concrete planning. Productivity averages are often a useful tool for portfolio planning. Portfolio planning occurs when organizations know few of the details about a piece of work. Solution: In software development and maintenance, never use an organization-level productivity number to set specific goals for a project, sprint or feature.
3. Labor productivity is a loose proxy measure for some types of change. Not all process improvements have a direct impact on labor productivity. For example, Total Factor Productivity (TFP) would be a better measure to assess the impact of the adoption of Scrum. While we may see the echoes of the of changes in labor or capital productivity, we would be ascribing the impact to the wrong factors which could lead us to try other changes that may not have positive impacts. Solution: Most software development and maintenance organizations will not spend the time and effort needed to measure TFP. Continue using labor or capital productivity to evaluate changes, but in addition evaluate how directly the productivity measures the change. Understanding how closely the proxy tracks the changes will help the analyst judge the change or alert him or her to search for other impacts.
4. Productivity may only be loosely tied to delivered value. Productivity is a measure of raw, non-defective output, not whether that output useful or sellable. If a software team delivers a product that does not hit the mark or is not adopted in the marketplace, they may have been highly efficient even though their output is less valuable than anticipated. Solution: Measure both value and productivity to provide a complete view of performance.
5. Comparing productivity across teams undervalues technical complexity. One piece of software is often significantly more or less complex than another. Technical complexity often varies not only between applications but within sections of code inside applications. The more complex the code or business problem, the lower the productivity (complexity increases the amount of effort needed to create an output). Solution: Each application should evaluate and determine its own productivity based on measuring delivered results. When teams use productivity as a planning tool they should tune the anticipated performance based on the predicted level of technical and business complexity.
Faster, better, cheaper has been the mantra of many a CFO and CIO. Understanding and improving productivity is one of the tools available to improve performance. In order to effectively use productivity as a tool, we need to make sure we calculate it correctly and understand that the metric provides a single point of view. Productivity is a measure of how effectively an organization transforms inputs into outputs; no more, no less. Productivity metrics provide the most value when coupled with other metrics such as value, speed, and complexity to generate a holistic view of the value delivery chain.