Productivity measurement in IT function has been debated and demanded over decades. Having made multiple attempts at solving this puzzle over many years, I have developed a point of view on productivity measurement. You may or may not agree but here it goes.
To measure productivity, one needs measures of output and input. Often business users want improvement in throughput without compromising quality. Management expects IT to deliver on that expectation with the same spending ($).
Let us consider measuring Productivity at team level and Business Unit (BU) level.
Team Productivity Measurement:
Measurement of team output has always been a challenge. In my opinion, scientific size measurements have never worked – either difficult to learn or difficult to apply consistently. FP-like or change-complexity-based measures have failed to deliver. Newer trends like relative sizing of stories are tools for teams to plan & execute better and not a common measure of output. All the above do not make sense to business users. Only one measure of output that would make sense to business users would be number of requirements. Users may be able to attribute business value to each of these requirements – however, at this level of detail, the business value can be used to prioritize but difficult to be considered as weights for summation of output.
Measurement of input in terms of actual effort has not been practical and difficult to sustain in spite of having good tools and management dictum. ‘Head-count’ is difficult to normalize given the varying levels of experience and salaries in team members. Best measure of input in my view is cost to company of the team members given the people-intensive nature of software work.
Overall, I would not recommend measurement of productivity at team level.
Sub-BU/BU level productivity measurement
There are three types of output (leaving out the infrastructure projects & support) – app development; app maintenance and app support (or production support).
For each app (or a group of apps) that produce an outcome, business can attach a BV (Business Value in $). The sum of the Business Value could be the business generated by that sub-BU or BU (or indicative of the business generated). Business can be broken by business product. However, mapping a business product to an IT app (or a group of apps) could be tricky but I believe it is possible to do this meaningfully.
Measurement of input is relatively easier at this level. $ spent on each app and broken up based on the output type – dev, maint & support. Again this break-up may not be straightforward in a complex organization but can be done meaningfully.
Productivity Index for an app (or group of apps) can be (i.e. Output over Input): (BV for app in $) / (Maint + Support spend for each app); This approach is in some way like calculating return-on-investment. To me, it is the efficiency with which the spend is generating value.
Dev-spend is indicative of future business value. This may have to be projected and most organizations would have made a business case for each development project when it was approved – that data could help. We can then measure Productivity Index for the development work being carried out in the IT organization.
Productivity Improvement:
When we measure productivity this way, we have multiple levers available for driving improvement without compromising quality.
Improvement Lever #1: App life cycle analysis
- Group apps in terms of their life stages. Look at the ratio of spends by output type – dev, maint & support. Variations in spend ratio by life stage would help the management identify apps where spend needs to reduced. Optimal ratios for each life stage could be based on industry benchmarks (if such benchmarks exist else figure out internal benchmarks). Nature of the app also could be another factor – mainframe, web, analytics & reports, mobile app, etc. in figuring out these ratios.
- Sunset apps that generate low business value
Improvement Lever #2: Increase business value
- Compare business value from current apps with potential initiatives that could generate greater business value. Move spend to the newer development projects
- Implement practices in teams (engineering & product management together) to ensure that higher value requirements are getting prioritized; Focus on reducing risks associated with these higher value items
Improvement Lever #3: Reduce direct cost of people
- Look at the mix of team members; there could be opportunities to reduce the actual cost of salaries – people with lesser qualifications & experience may be good enough; higher cost resources could be shared across teams.
- Look for moving spend to locations where cost of people is lower without compromising efficiency
Improvement Lever #4: Invest in automation
- Focus on appropriate tools & technologies to automate engineering practices like test automation; build automation; release management, etc.
- Review tool/technology portfolio and optimize
Improvement Lever #5: Enable & encourage teams to identify, measure & improve on factors that influence productivity (a few examples below):
- Application knowledge
- Business domain knowledge
- Multi-skilling
- Team level automation (e.g. scripting of repetitive tasks; population of test data)
- Waste reduction – re-work in development; Unsuccessful changes; App outage; etc.
- Self-organizing teams
- Softer aspects like: conflicts (unhealthy); gender diversity; product vision; Goal-focus; etc.
- Inter-team collaboration
All of the above 5 levers should influence the productivity index as we had defined earlier.
In summary:
- define & measure productivity at Sub-BU or BU levels (not at team level) in a way that is meaningful to business
- use macro-level means like app portfolio optimization, automation, focus on business value, etc. to improve productivity in collaboration with business
- enable & encourage teams to improve the underlying factors that influence productivity (not productivity directly)
