Many organisations use numbers or measures as a basis for day to day decision making in the management of their I.T activity. These measures provide the objective information needed to make sensible fact-based decisions.

Making sense of all this information, however, may sometimes offer a challenge.  

I can easily imagine myself as the manager of a group of teams developing software and having to collate figures for my productivity report. Team A on Project A achieved a productivity rate of 7 hours per Function Point and Team B on Project B achieved 14 hours per Function Point.  On the face of it, Team A seems to be doing much better than Team B but I am aware that they work on different application areas and doing different types of work. Can I really compare these numbers?  

How do I hope to report to my superiors what I don’t really understand?  And how can I plan to improve what I don’t know where we are at?

Is this quandary a familiar scenario, for you or someone you know?

Finding the Lemons

This is a short case study showing a method for reporting productivity in a way which largely alleviates this problem. 

This is the experience of a large finance organisation with a diverse and complex software environment. This organisation has been measuring the productivity of its development teams using function point based metrics for a number of years.  Function Points are used to express the size of the Work Product delivered by the project and this is combined with Work Effort project hours as a measure of productivity.  The productivity as Work Effort / Work Product is expressed in Hours / Function Point.

Each year, productivity targets are set for each team.  These targets are provided as part of an annual benchmark audit provided by my organisation. Each target is derived from comparative industry data so it is set in a realistic context. The targets consider the type of work done (e.g. development, simple enhancements, complex enhancements, and so on), the nature of the software application itself, the development platform plus a number of other variables. There can be more than one target for each team, depending on the type of work done and other variables. The key point here is that each productivity target is custom tailored to the circumstance. 

At the end of each quarterly reporting period, the Project Office delivered a balanced scorecard to the organisation’s CIO. The Project Office wished to include the productivity rate achieved by each team as one of the reported KPIs.

However, they were reluctant to simply include the ‘raw’ metric on two counts:
•    Firstly, almost certainly the response from many parties would be “what on earth is a Function Point?”
•    Secondly, they were aware that the productivity rate cannot be taken simply on face value but didn’t want to have to include too many explanatory notes.

They know that due to the relative complexities of different technologies and platforms and the nature of the applications themselves, one project’s productivity rate of 12 hours per function point may actually be a better achievement than the 6 hour’s per function point achieved by another.

For example, the following chart is a simple plot of the raw average productivity of projects delivered each month. It would appear to indicate that the best productivity was achieved in June and the worst – by a very small margin - was May. 
 

Figure 1 - Looking Good in June - Perhaps!

However, it hides that fact that most of the projects delivered in June were simple Enhancements and, in reality, for the type of work, the productivity was not particularly good.

Other data points also need further explanations for proper interpretation.

What was needed urgently was a way to express productivity where the meaning is simply intuitive to senior management.

Normalised Productivity

We introduced our Productivity Index metric as a productivity indicator for standard use across all the teams. This Index can be very quickly assessed and understood by senior management.

The Productivity Index reports software delivery productivity using a single index scale.  It uses a comparison of the target productivity against the productivity actually achieved.

The following chart is based on the same raw data as the previous chart. However, the productivity reported is now normalised so

  
Figure 2 - May Looks Like a Bad Month

The index value is simple to understand:

• An Index value of 1 is represented by the blue line. This indicates the target productivity. A point plotted on this line means that the target productivity has been achieved.
• Expect the plot of productivity to show variation about the Target line. A project is unlikely to deliver at exactly the Target productivity.
• An Index value greater than 1 is described as above the line and indicates that the team is delivering at a better rate than the target.  An Index value of 2, for example, would indicate that the team is delivering twice as fast as the target rate.
• An Index value less than 1 is below the line and indicates that the team is delivering at a poorer rate than the target. 
• The Lower Bound red line indicates when to start further investigation. The Productivity achieved is not good enough. This Bound is decided though discussion.

The Productivity Index approach provides other benefits:

• It is an objective measure that can be calculated directly from the existing function point based metrics
• It is an easy-to-calculate measure requiring only a couple of minutes of an analyst's time.  The necessary calculations are easily implemented in a spreadsheet.
• At the summary level, it can be implemented as a traffic light report making it particularly effective for inclusion in a high-level balanced-scorecard.
• By tracking Productivity Index scores over time, productivity trends can be identified and factors that lead to unexpectedly better or poorer productivity can be identified and investigated.

Intuitive Productivity Reporting

Our client has integrated the Productivity Index into their balanced-scorecard reporting and has now used it to successfully measure productivity and drive process improvement for the last five years.  The CIO has on several occasions made direct reference to the productivity results demonstrated by the Productivity Index in her reports.

Since the Productivity Index is a simple concept, it is easy for new managers to adopt. No training is needed.

If you work in a diverse and complex software delivery environment and need a way to assess, report and compare your teams' productivity in a manner that is easy and intuitive, consider implementing a simple metric like the Productivity Index to report what happens in your organisation.