Critical Indicators for MBO in Software R&D

Reading time: 3 minutes

Most executives agree that bonuses and variable compensation plans are great to motivate and engage people to get more accomplished. Discussions and different opinions pop up when the question “How will we establish goals and assess if they were achieved or not?” is asked. HR executives and functional managers know that metrics impact behavior, and establishing wrong goals will potentially promote unwanted results. That is why I am so frequently asked by HR and management teams how to establish goals for research and development, the area in a software company for which they have most difficulties in defining measurable objectives. Hours, days, and sometimes months of discussions usually end up on conclusions close to what follows, so, if indicators for your variable compensation plans (or simply goal setting) are not in place, read on.

With so many involved variables and the close relationship between product management and “production” (product development and maintenance), it is important to first clearly define what the objectives of these parts of R&D are. Once those objectives are clear, then a concise set of performance indicators can be developed to both communicate the established goals and allow managers and teams to check on their performance on an ongoing basis.

Let’s start with the objectives. For product development, they can be summarized as quality, productivity, and punctuality (yes, punctuality, because a software company will orchestrate other actions around development schedules). It is important that all objectives are addressed together; otherwise, you may get one thing at the expense of others. Product management should share some of these goals, but due to its strategic and business focus, additional measures from a business perspective will provide the teams with better alignment and drive; therefore, for balance and cohesion, we can say its objectives are: growth, profitability, competitive sustainability, costs reduction, and customer retention. Now we can move on to the indicators, creating a carefully balanced set.

We all want a simple set of indicators, and that is good. That set, however, cannot be simpler than what is required, or you will not get the results you want. The following indicators for “production” will provide a proper drive, avoid undesired manipulations, and promote good interaction between developers and product management:

  1. Cost per produced unit of software volume (I recommend function points. Simply add all costs incurred for development, and divide it by the number of function points produced in the period).
  2. Percentage of maintenance costs over total “production” costs (development + maintenance).
  3. Variance of project schedules (establish schedules only after all requisites have been detailed).
  4. Defect density (customer-reported defects by volume of code, e.g. million lines of code), as a critical aspect of quality that is internally quantifiable. Note: consider variances created by new version releases.
  5. Customer satisfaction (topics related to products), as the ultimate quality indicator.

For product management, these indicators will remind the involved people (product managers / POs / business analysts) of the importance of promoting productivity and quality in product development, while keeping their eyes on their business mission:

  1. Revenue.
  2. Product contribution margins.
  3. Market-share (optionally, growth in relation to some specific competitors).
  4. Cost per produced unit of software volume (same as above).
  5. Percentage of maintenance costs over total “production” costs (same as above).
  6. Customer satisfaction (same as above).

There are many other metrics and indicators required for proper process management, but they all fold into the ones above when analyzed from the perspective of business results. Some effort is required to put these indicators in place, but after more than twenty years working closely with performance of software organizations, I found that the organizations with measurement mechanisms in place perform better, whereas I have never found a highly productive organization that does not measure performance.

[For more details on this subject, I suggest you read this white paper I wrote on Metrics for Software Development:]