In a previous post we discussed the role of finance in measuring business function performance. We highlighted the need for finance to integrate more seamlessly with software development to enable more value add to the business. The major point is that for most functions there are well worn systems of financial analysis and metric norms that are easy to institutionalize, and with software’s rapid growth, finance is still catching up. Software development has always been a bit of a black box for objective, external analysis.
Going deeper on this topic, the ultimate goal is to establish a system of measurement and financial analysis that drives business insight and value. It’s incredibly important to note that this system is complimentary to business functional analysis. Software development teams have an increasing wealth of functional measurement best practices that many companies are beginning to institutionalize as they grow. But, the financial integration side of the equation is where improvement is needed. So, what should this system look like?
The Starting Point:
The single most important criteria in this process is to ensure that all KPIs are intimately linked to business objectives. Of course, this seems pretty straightforward, but it’s all too easy to set up measurement before there is even a paradigm set up to understand or leverage that information for strategic purposes.
The easiest way to do this is to reverse engineer from broad business needs. The specifics may differ from company to company, but there are some pretty generalizable buckets:
In looking at these four broad areas, the ‘quality’ area, while critical for finance, must ultimately be measured within the function itself, and then can be merged with other financial measurement. ‘Productivity’ will be both a functional specific metric as well as a corporate or finance oriented metric, and the two buckets squarely in need of finance integration are ‘cost’ and ‘business impact’.
Once the basic areas of measurement need are determined the next step is to essentially identify the relevant KPIs, determine how they would be used strategically and how they would be measured. The ‘how’ question is critical as there are two very important qualifying criteria to a good measurement system – it must be systemic and objective and it must be as simple as possible to limit the amount of overhead time spent managing. The goal is to have as much of it automated as possible to get to the important task of evaluating and making decisions.
KPIs to Consider:
Below are some sample metrics by key areas. There are many variants of the below, but a solid measurement scheme will include elements across all of these. The more seamlessly integrated finance and software development teams are, the easier these measures will be to obtain in systematic ways, and the more valuable finance will be to the business. These KPIs are for companies investing in software assets. For development companies who are really professional services firms, some blend of these metrics with more typical professional services metrics will be necessary (utilization, project profitability, win rates, etc.).
Cost:
| KPI | Overview |
| Spend by Product | Extremely basic, but important view of how much is actually being spent across products. |
| Spend by Type: Innovation vs. Development vs. Maintenance Spend | How much is the team overall (or by product) spending on innovation trial and error vs. new feature development vs. maintenance (ultimately components of R&D spend). This gives a sense of total cost of ownership for products. |
| Spend Variance | Spend to budget in total and by products and type. How effective is the team at budgeting efforts and delivering on target. |
| CAPEX vs. OPEX Ratio | Somewhat related to above, but crucial for product teams to assess TCO and quality of new development spend. |
Productivity:
| KPI | Overview |
| $ / Point (agile), points completed (blend), Hours utilization (time-based) per period | Depending on the basic accounting model employed, utilization can be measured in hours or $/point or avg. points completed. |
| Time to market | How long does it take to get features in market and how successful is the team at delivering on or ahead of time. |
Business Impact:
| KPI | Overview |
| Product Spend to Revenue (through time and by type) | For products spend through time by type (capex v. opex, etc.) linked to revenue for that product. Depending speed to impact, this can be measured as trailing 12 months or trailing 36 months to current revenue, etc. |
| R&D to Sales | Long-run ratio of R&D to sales. Can be in current period or R&D lagged. |
| Feature/Product Impact | Cost of development to ‘return’ (other goaled metric like pageviews, usage, etc.) |
| R&D Output | New product / feature sales to total. Can be in most recent trailing 12-months or with new product sales extended over 24 or 36 months. |
| R&D/CAPEX Success Rate | Impairment or lack of success to total. Easy to measure if CAPEX v. OPEX are managed appropriately. This gives a critical insight to asset development success rates and long-term ‘failure’ overhead for budgets and forecasts. |
