By David Herron and David Garmus

Date: Nov 20, 2000

Return to the ar cle

This ar cle describes common uses of the func on point metric by the so ware development organiza on. To

demonstrate the versa lity of the func on point metric, we have selected two scenarios; each represents the use
of the metric at a different level in the organiza on. Func on points are used at the IT management level as the
key normalizing metric in establishing performance benchmarks used to iden fy and track improvements.
Second, func on points are o en used at the organiza onal level as the base metric for establishing quan fiable
service levels (seen primarily in outsourcing arrangements).

This ar cle describes common uses of the func on point metric by the so ware development organiza on. To demonstrate the

versa lity of the func on point metric, we have selected two scenarios; each represents the use of the metric at a different level in the
organiza on. Func on points are used at the IT management level as the key normalizing metric in establishing performance
benchmarks used to iden fy and track improvements. Second, func on points are o en used at the organiza onal level as the base
metric for establishing quan fiable service levels (seen primarily in outsourcing arrangements).

In each of the two scenarios, func on point analysis has its greatest value when used in conjunc on with other metrics. For example,

simply knowing the average size of your so ware deliverable (expressed in func on points) is of li le value; however, by incorpora ng
other data points, such as deliverable cost, dura on, and defects, you can create and report on value‐added measures such as the cost
per func on point,  me to market, and defect density.

It is true that the func on point metric is not a panacea for so ware development ills; however, it does afford the development team and

IT management an opportunity to measure and evaluate key elements in the development environment to make more informed
decisions.

IT Management Level: Establishing Performance Benchmarks
Baselining an organiza on's performance level has become a standard industry prac ce, par cularly in companies whose IT
organiza ons are required to track and improve their delivery of products and services rela ve to improved  me to market, cost
reduc on, and customer sa sfac on. Crea on of an IT performance baseline (o en referred to as benchmarking) gives an organiza on
the informa on it needs to properly direct its improvement ini a ves and mark progress.

Performance levels are commonly discussed in terms of delivery—for example, produc vity, quality, cost, and effort. In each of these
categories, func on points are used as the denominator in the metrics equa on. By using func on points as the base measure, the
organiza on benefits in two ways. First, because func on points are applied in a consistent and logical (not physical) fashion, they are
considered a normalizing metric, thus allowing for comparisons across technologies, across business divisions, and across organiza ons,
all on a level playing field. Second, there is an extraordinary amount of industry baseline data, which can be used to compare
performance levels among various technologies and industries and to compare internal baseline levels of performance to best‐prac ce
performance levels.

Noted in Table 1 are some examples of industry data points for produc vity levels. The values are expressed in hours per func on point

as a rate of delivery. These data points are from the Interna onal So ware Benchmarking Standards Group (ISBSG), one of the
numerous sources of industry benchmark data. The ISBSG data displayed in Table 2 depicts similar rates by business area.

Table 1

ISBSG Industry Data
 Func on Point Size Mainframe Client‐Server Packaged So ware Object‐Oriented

225 9.1 11.4 7.6 12.5

400 10.4 13.0 8.7 14.3

625 12.2 15.2 10.1 16.7

875 14.6 18.3 12.2 20.1

1125 18.3 22.8 15.2 25.1

Note: All values are expressed in hours per func on point as a rate of delivery.

Table 2

Rates of Delivery by Business Area

Business Area Rate of Deliverya

Accoun ng 11.3

Manufacturing 6.3

Banking 12

Telecommunica ons 2

Insurance 27.4

Engineering 8.1

aExpressed in hours per func on point.

The data points shown in tables 1 and 2 make obvious the advantage of using func on points. Representa ve industry performance data

using func on point‐based measures and data points is available for organiza ons to use as the basis of their cost and performance
comparisons to industry averages and best prac ces.

For an organiza on that has been engaged in the collec on and analysis of its own metrics data, crea ng baseline informa on similar to

the industry views displayed in tables 1 and 2 is a rela vely easy task. However, most organiza ons do not have the advantage of readily
available metrics data; therefore, they need to create a baseline of performance data from the ground up. Fortunately, a baseline can be
developed rela vely economically, depending on the level of systems documenta on and project management data available.

The baselining process includes the quan fiable measurement of produc vity and quality levels. Performance is determined according

to measurements collected from a representa ve sampling of projects. The selec on of projects is commonly based on unique criteria:

The project was completed or was undergoing development during the previous 18 months.

The labor effort to complete the project amounted to more than six staff‐months.

The project represents similar types of projects planned for future development.

The primary technical pla orms are represented.

The project selec on includes a mix of technologies and languages.

Project data is collected (when available) on the func on point size of the deliverable, level of effort, project dura on, and number of

defects. These measures are analyzed, and performance levels are established on a project‐by‐project basis. These data points can then
be used to create a quan ta ve baseline of performance (see Figure 1). In Figure 1, data points for all projects are recorded during the
baselining process. These data points create one view of an organiza onal baseline. The data points include an expression of func onal
size and rate of delivery. For our purposes, rate of delivery is expressed in terms of func on points per person‐month.

Figure 1

Rate of delivery during baselining

Figures 2 and 3 have sorted the baseline projects rela ve to the type of development. Figure 2 shows all enhancement projects; Figure 3
shows all new development projects. Note the difference among the various views for a baseline project of 400 func on points. The
advantage of looking at this baseline data from different viewpoints is to be er understand the impact of different development types
on performance levels. It would not be reasonable to expect future enhancement projects to perform at the same rate of delivery as
new development projects.

Figure 2

Rate of delivery for enhancement projects

Figure 3

Rate of delivery for new development projects

Obviously, project size and complexity are contribu ng factors that influence produc vity. However, numerous other factors also affect

the capacity of an organiza on to define, develop, and deploy so ware. Assessing an organiza on's capacity to deliver represents the
qualita ve por on of the benchmarking process. A capacity analysis reveals the influence of current so ware prac ces on performance
levels. Using the informa on from the capacity analysis, it is possible to recommend improvements in current prac ces, to suggest new
prac ces, and to emphasize exis ng prac ces that have already demonstrated posi ve influence on produc vity.

For example, we can observe from figures 1 through 3 that our capacity to deliver is influenced by size and type of development. If we
hold these two variables constant while analyzing our baseline data, we can observe that there are s ll varia ons in performance data.

Figure 4 shows data from several projects that are closely related in size. Four data points fall in the range of 400 to 550 func on points.
Their corresponding rates of delivery are from 8 to 18 func on points per person‐month. That is a significant difference in performance.
The challenge now becomes one of determining the contribu ng factors that caused these projects to perform at different levels.

Figure 4

Rate of delivery by func onal size

We have completed many of these types of process performance assessments on the basis of our own proprietary assessment method.
The method of collec on consists of selected interview and team survey sessions with each of the project teams. Data is collected on
key influence factors, such as project management capabili es, requirements and design effec veness, build and test prac ces, skill
levels, and other contribu ng environmental factors. Individual projects are analyzed, and project profiles are created. This data is also
analyzed in aggregate and may be used as the basis for determining overall organiza on process improvements.
The results are somewhat predictable. Typical influence factors include skill levels, effec ve use of front‐end life cycle quality prac ces,
tool u liza on, and project management. These findings parallel, in part, those of the ISBSG database analysis, which revealed that
language complexity, development pla orm, methodology, and applica on type were significant factors influencing produc vity.

Analysis of the qualita ve data leads an organiza on to the discovery of certain process strengths and weaknesses. As performance

profiles are developed and contrasted with quan ta ve levels of performance, key so ware prac ces that are present in the higher‐
performing projects tend to be missing from the lower‐performing projects. These prac ces differen ate between success and failure.

The real value of the benchmarking ac vity results from iden fying performance levels, analyzing process strengths and weaknesses,

monitoring process improvements, and comparing to industry data points. There is much to be learned from comparisons to industry
data. An IT organiza on can see at a glance the overall effec veness of its performance in contrast to industry benchmarks. In addi on,
there is an opportunity to iden fy industry best prac ces and to evaluate how these best prac ces will affect your organiza on's
performance levels.

Organiza on Level: Establishing Service‐Level Measures
Service‐level measures are most commonly associated with outsourcing arrangements. They are established as a means to measure the
performance of an external provider of so ware services. In addi on, as organiza ons become increasingly sensi ve to the needs of
their customers, and as IT goals and objec ves become more aligned with business performance and customer sa sfac on levels,
internal service‐level measures are becoming more popular.

Func on points play a key role in the establishment of applica on development and maintenance (AD/M) service‐level metrics. There

are three typical outsourcing scenarios in which func on points can play an important role: single projects or applica ons, applica on
maintenance, and the outsourcing of an en re AD/M environment. The decision to outsource a par cular project rather than an en re
development shop, of course, will vary significantly. Some of the typical reasons for outsourcing may include any of the following:

To allow companies to focus on "core competencies"

To convert rela vely fixed allocated costs to direct variable costs

To take the IT func on to the next level of capability

To improve  me to market

To facilitate the best possible implementa on of new applica ons

To change the culture and re‐skill the IT func on

To convert legacy system resources to new development resources

An effec ve set of measures is mandatory to monitor performance trends and improvements. These measures should link to and
provide informa on on performance as it relates to stated organiza on goals and objec ves.

Project and Applica on Outsourcing
Outsourcing of a project or applica on involves contrac ng a third‐party vendor to perform the work, either on‐ or off‐site. The
comple on of the contract is the delivery of the project or applica on so ware.

For service levels to be established in the case of a project or applica on scenario, three basic ques ons need to be answered:

1. What is the outsource provider's responsibility?

2. What standards or development prac ces are required?

3. What defines the "goodness" of the deliverable?

Answers to these ques ons will guide us in outlining and defining which service levels are most appropriate.

First, defining the areas of responsibility provides an opportunity to define hand‐off or touch points where deliverables are passed
between the provider and the customer. The most obvious hand‐off point is the final deliverable, but other hand‐off points may include
specifica ons, design, test plans, test cases, code, and so on. Each hand‐off point is an opportunity for measuring the level of service.
What will be delivered to the provider, and what will the provider in turn deliver?

Func on point analysis has an obvious role here. For example, the ini al deliverable to the provider may be a requirements document.

Here's an excellent opportunity to size the requirement and to establish a service level that measures the size of the final deliverable. As
scope changes are introduced, they will be sized using func on points, thereby iden fying to both the provider and the customer a
specific quan fica on of the end deliverable.

Second, knowing what standards or development prac ces are required typically leads to the establishment of one or more compliance‐
related service‐level measures. The opportunity to use func on points is limited in this aspect of the outsourcing arrangement.
However, there may be a desire to monitor produc vity, measured in func on points per unit of  me or cost. The proper use of
development tools and techniques during the development process will influence produc vity, of course, and the func on point‐related
metric can be used to measure the effec veness of the selected tools and techniques.

Finally, the "goodness" of the deliverable is the most basic of the service‐level measures. Here func on points would usually be the
denominator in a variety of metrics equa ons measuring such things as rate of delivery, dura on, cost, and quality.

Maintenance Outsourcing
The outsourcing of selected applica ons to be maintained by a third‐party vendor requires a much different set of measures from those
used in the project or applica on outsourcing arrangement. The key elements involved when one is considering the measurement of a
maintenance outsourcing arrangement include the following:

Monitoring customer expecta ons

Maintaining an acceptable response  me

Limi ng bad fixes

Limi ng the volume of fixes

Monitoring the decrease or increase in applica on func onality

Establishing effec ve hand‐offs

Ensuring applica on exper se

Monitoring smooth customer interfacing

All of these factors are measurable, although not all of them require the use of func on points. Let's examine several situa ons and see

how func on points play a role.

Monitoring customer expecta ons is an opportunity to use func on points as a means to monitor the growth of the en re applica on

por olio, as well as to maintain an overall view of the costs associated with each applica on. Monitoring the increase or decrease of
func onality in any given applica on allows the development organiza on to monitor the cost of func onality supported.

AD/M Outsourcing
The final outsourcing scenario that we will review is the outsourcing of an en re applica on development and maintenance
department. Such outsourcing usually extends over mul ple years and may be linked to a much larger outsourcing ini a ve, which
could include the outsourcing of the en re IT organiza on. Once again, we observe a much different measurement dynamic from what
we encountered with the first two scenarios.

In this scenario, the customer con nues to monitor the management and performance of individual projects and the maintenance of
the applica on por olio. However, usually a much higher or broader performance view is taken when the service‐level measures for an
en re IT department are being considered.

The issues driving AD/M outsourcing engagements include the following:

Assessing the impact of new technology

Increasing profitability

Reducing costs

Improving customer service

Improving  me to market
 Increasing financial control

Service‐level measures that are formulated to support an AD/M outsourcing arrangement are usually mul layered. The contract may
require a primary set of service‐level measures that measure overall performance on an organiza on‐wide basis. In addi on, the
contract may require a set of service‐level measures to monitor specific project deliverables.

This scenario is similar to an agreement that you might have with a contractor building your house, in which there are specific measures
rela ve to the details of the house such as room dimensions, electrical capaci es, and the like. However, the overall performance is
more likely to be monitored as  me to market, final cost, and overall quality of workmanship.

A well‐defined process should be followed to establish the proper service‐level measures for an AD/M arrangement. This process
requires an understanding of the goals and objec ves of the outsourcing arrangement, iden fica on of the measures that will monitor
the performance or the achievement of those goals, and determina on of the proper level of service to expect ini ally and on a
con nuing basis.

The goals and objec ves of the outsourcing ini a ve are developed at a senior management level and are documented in a strategic

business document. The iden fied business drivers express the expected outcomes of the outsourcing arrangement in terms of
increased profitability, market posi oning, and improved service. The challenge is to derive a set of service‐level measures that will
effec vely monitor how these elements are affected—posi vely or nega vely—by the ac vi es being executed at the so ware
development level.

In addi on to defining or discovering the business drivers, it is cri cal to consider the performance of the so ware prac ces within the

development organiza on itself. For example, any exis ng problems with the ability to deliver clearly stated and accurate requirements
need to be iden fied when service‐level measures are being established. The introduc on of a third‐party provider that has taken over
the exis ng development staff will not immediately improve the development organiza on's capability to provide clear requirement
specifica ons.

Through analysis of the business drivers and the performance considera ons of the development environment, a set of applicable
metrics is derived (see Figure 5). For each service‐level metric iden fied, a metric profile is created. Each profile includes a defini on of
the metric, its stated purpose, the data elements required, and the formula to calculate.

Figure 5

Metrics derived by analysis of business drivers and performance considera ons

The next step in the process is to establish the actual values or levels of performance that must be assigned to each service‐level metric.
We must determine reasonable values for the established service levels. If we have established  me to market as a service level, we
need to determine the proper interval of  me to be expected. If cost is going to be measured, what is a reasonable cost? When quality
is integrated into the set of service measures, what are the defect density levels? We can determine these values best either by
establishing organiza onal performance benchmarks or by relying on industry data.

Summary
The use of func on points as part of a comprehensive baseline performance measurement ini a ve demonstrates the versa lity and
many uses of func on points. Specifically, func on points permit an organiza on to compare internal performance levels in a more
consistent fashion. In addi on, the use of func on points allows for a wide range of comparison opportuni es outside the organiza on.
An ever‐increasing amount of industry performance data uses func on points as the base measure. An organiza on that can express its
produc vity in terms of func on points can compare those performance values with industry‐related benchmarks and determine the
rela ve posi on of its performance. In addi on, some industry data goes a step further in that it can iden fy and quan fy best‐prac ce
performance levels.

When func on points are incorporated into the service‐level metrics for an applica on development outsourcing arrangement, their

value to the organiza on increases. They have o en been described as the currency or unit of work that is at the core of the service‐
level metrics. Once again, we can see the dual role that func on points can play in servicing both the IT organiza on and the business
community. In the case of outsourcing, the business is paying for func onality delivered. That func onality can be quan fied best by the
func on point metric.

Source
This ar cle has been excerpted from Func on Point Analysis: Measurement Prac ces for Successful So ware Projects (Addison Wesley,
2000), by David Garmus and David Herron.
© 2019 Pearson Educa on, Informit. All rights reserved.
800 East 96th Street, Indianapolis, Indiana 46240