The survival of most organisations nowadays is increasingly dependent on software. Whether it is for a board of a bank, a shipping company, in a high-tech industry or any other sector, this article will provide the ability to engage in valuable software governance conversations without getting bogged down in technicalities. This article will introduce the most important metric, functional size and show through examples of board- level questions and answers how boards should ask questions that can steer an organisation towards effective software management.

Quantification of software governance

Functional size is a way of determining software size that applies to all types of software, whether bought as a package or custom built. Functional size is a technology-agnostic measure of functionality. The unit of measure is the COSMIC Function Point (CFP) and is an ISO standard. A single CFP is defined as one of four data movements: an input, an output, a read, or a write of data. For example, the functional size of an ecommerce website is typically in the order of 1500 CFP, whilst a simple to do app on a smartphone might be just 20 CFP. Using CFP, you can measure a small change to an existing application right up to the entire size of a software portfolio.

The number of CFPs in a piece of software aligns well to the effort (and therefore cost) of building it. The typical costs for building custom software is £500–£1200 per CFP, whilst the typical cost to implement a package solution is generally £20–£200 per CFP.

Questions about a software portfolio

How much software are we managing?

Ask for a list of all the systems and their size in CFP.

How much innovation are we delivering?

What is the CFP of innovative software developments and what is their value contribution ( £) to the business?

Are we spending appropriately on software maintenance?

What is the spend per CFP per annum on each maintained system (excluding new features).

How much of our software is ready for retiring?

How many CFPs are more than 10–15 years old? And in which systems are these CFPs.

Questions about efficiency

How productive are our software teams?

CFP delivered per team per month.

CFP maintained per team per month. 

Are we managing our software development & maintenance vendors appropriately?
Spend per CFP of new functionality.
Spend per CFP of maintained functionality. 

Questions about risk and value 

Are we faster than our competitors at delivering innovative software?
CFP per month delivered.

Are we paying too much to suppliers for software?

Cost per CFP for acquired or built software.

Are we optimising our software projects for success?

Knowing that smaller projects are far more likely to succeed and very large projects have high failure probability, how many projects are over 1000 CFP and what is being done to break these down into smaller independent projects?

Are we allocating enough time to succeed with our projects?

Given developer productivity in CFP per month the likely duration of a project can be anticipated.

Are our staff productive?

Average developer productivity is around 10 CFP per month; yet can vary from very low (2 CFP / mo) to very high achievers (150 CFP / mo). Similar benchmarks are available for testers, project managers, system architects, product owners, business analysts etc.

What is the size (and cost) of replacing our most strategically critical systems that are not enabling our strategic plans?

Strategic CFP vs non-strategic CFP delivered p.a.

How much non-strategic development is happening on non- differentiating functionality?
CFP per annum, targeted for delivery.

How many of our software contracts are fixed price per CFP vs time and materials?
Fixed price per CFP is a proven means of controlling software spend on larger engagements.

Are we spending enough on cyber security?

Security related functionality should be around 15% of new systems, has the organisation invested in 15% of CFP on each publicly faced system? 

What is our total cost of ownership of each software system?

Implementation + post implementation + annual maintenance + cost of quality deficiency can all be standardised in £/CFP. 

Questions about quality

Do we know our software quality?

One of the best metrics for this is the defect removal efficiency which is the number of major defects per CFP that are being exposed to users in the first three months implementation. The US average is only 90%, which means that 10% of all defects are not found before delivery.

Do we know the cost of poor-quality software?

The total (including consequential) cost to the organisation of those defects, per CFP.

These are just some of the valuable questions that can be discussed at board level and they all rely on board members understanding just the one concept which is functional size. The answers to each of these questions can also be compared against industry benchmarks.

Unlike with other gameable metrics commonly used in the software community (story points, lines of code and others) the adoption of CFP-based metrics is unlikely to lead to negative behaviours. Boards can expect some resistance from the IT function within the organisation, as transparency is not always welcome.