PRODUCTION AND OPERATIONS

MANAGEMENT

PRODUCTIVITY MEASUREMENT

TEAM MEMBERS:
Apoorva Jain
Tarun Daga
PRODUCTIVITY

Productivity refers to measures of output from production processes, per unit of

input. Labour productivity, for example, is typically measured as a ratio of
output per labour-hour, an input. Productivity may be conceived of as a measure
of the technical or engineering efficiency of production. As such quantitative
measures of input, and sometimes output, are emphasized. Productivity is
distinct from measures of allocative efficiency, which take into account both the
value of what is produced and the cost of inputs used, and also distinct from
measures of profitability, which address the difference between the revenues
obtained from output and the expense associated with consumption of inputs.

Purposes of productivity measurement

Productivity is commonly defined as a ratio of a volume measure of output to a
volume measure of input use. While there is no disagreement on this general
notion, a look at the productivity literature and its various applications reveals
very quickly that there is neither a unique purpose for, nor a single measure of,
productivity.

The objectives of productivity measurement include:

 Technology. A frequently stated objective of measuring productivity

growth is to trace
technical change. Technology has been described as “the currently known ways
of converting resources into outputs desired by the economy” (Griliches, 1987)
and appears either in its disembodied form (such as new blueprints, scientific
results, new organisational techniques) or embodied in new products (advances
in the design and quality of new vintages of capital goods and intermediate
inputs). In spite of the frequent explicit or implicit association of productivity
measures with technical change, the link is not straightforward.

 Efficiency. The quest for identifying changes in efficiency is conceptually

different from
identifying technical change. Full efficiency in an engineering sense means that
a production process has achieved the maximum amount of output that is
physically achievable with current technology, and given a fixed amount of
inputs (Diewert and Lawrence, 1999). Technical efficiency gains are thus a
movement towards “best practice”, or the elimination of technical and
organisational inefficiencies. Not every form of technical efficiency makes,
however, economic sense, and this is captured by the notion of allocative
efficiency, which implies profit-maximising behaviour on the side of the firm.
One notes that when productivity measurement concerns the industry level,
efficiency gains can either be due to improved efficiency in individual
establishments that make up the industry or to a shift of production towards
more efficient establishments.

 Real cost savings. A pragmatic way to describe the essence of

measured productivity change.Although it is conceptually possible to
isolate different types of efficiency changes, technical
change and economies of scale, this remains a difficult task in practice.
Productivity is typically measured residually and this residual captures not only
the above-mentioned factors but also changes in capacity utilisation, learning-
by-doing and measurement errors of all kinds. Harberger (1998) re-stated the
point that there is a myriad of sources behind productivity growth and labelled it
the real cost savings. In this sense, productivity measurement in practice could
be seen as a quest to identify real cost savings in production.

 Benchmarking production processes. In the field of business

economics, comparisons of
productivity measures for specific production processes can help to identify
inefficiencies. Typically, the relevant productivity measures are expressed in
physical units (e.g. cars per day, passenger-miles per person) and highly
specific. This fulfils the purpose of factory-to-factory comparisons, but has the
disadvantage that the resulting productivity measures are difficult to combine or
aggregate.

 Living standards. Measurement of productivity is a key element

towards assessing standards of living. A simple example is per capita
income, probably the most common measure of living standards: income
per person in an economy varies directly with one measure of labour
productivity, value added per hour worked. In this sense, measuring
labour productivity helps to better understand the development of living
standards. Another example is the long-term trend in multifactor
productivity (MFP). This indicator is useful in assessing an economy’s
underlying productive capacity (“potential output”), itself an important
measure of the growth possibilities of economies and of inflationary
pressures.

Main types of productivity measures

There are many different productivity measures. The choice between them
depends on the
purpose of productivity measurement and, in many instances, on the availability
of data. Broadly,
productivity measures can be classified as single factor productivity measures
(relating a measure of
output to a single measure of input) or multifactor productivity measures
(relating a measure of output to a bundle of inputs). Another distinction, of
particular relevance at the industry or firm level is between productivity
measures that relate some measure of gross output to one or several inputs and
those which use a value-added concept to capture movements of output.
Table 1 uses these criteria to enumerate the main productivity measures. The
list is incomplete in so far as single productivity measures can also be defined
over intermediate inputs and labour-capital multifactor productivity can, in
principle, be evaluated on the basis of gross output. However, in the interest of
simplicity, Table 1 was restricted to the most frequently used productivity
measures. These are measures of labour and capital productivity, and
multifactor productivity measures (MFP), either in the form of capital-labour MFP,
based on a value-added concept of output, or in the form of capital-labour-
energy-materials MFP (KLEMS), based on a concept of gross output. Among
those measures, value-added based labour productivity is the single most
frequently computed productivity statistic, followed by capital-labour MFP and
KLEMS MFP.

These measures are not independent of each other. For example, it is possible to
identify various driving forces behind labour productivity growth, one of which is
the rate of MFP change. This and other links between productivity measures can
be established with the help of the economic theory of production.

Once productivity measures are conceptualised on the basis of economic theory,

there are several ways to go about their empirical implementation. From a broad
methodological viewpoint, parametric approaches can be distinguished from
non-parametric ones. In the first case, econometric techniques are applied to
estimate parameters of a production function and so obtain direct measures of
productivity growth. In the second case, properties of a production function and
results from the economic theory of production are used to identify empirical
measures that provide a satisfactory approximation to the unknown “true” and
economically defined index number. The growth accounting approach to
productivity measurement is a prominent example for non-parametric
techniques.
A short guide to some productivity measures

The following will give the review of the five most widely used productivity
concepts. They point out the major advantages and drawbacks and briefly
interpret each measure.
Labour Productivity (based on gross product)
Labour Productivity (based on value added)
Capital-Labour MFP (based on value added)
Capital Productivity(based on value added)
Economic Growth and Productivity

Activity can be identified with production and consumption. Production is a

process of combining various immaterial and material inputs of production so as
to produce tools for consumption. The way of combining the inputs of production
in the process of making output is called technology. Technology can be
depicted mathematically by the production function which describes the function
between input and output. The production function depicts production
performance and productivity is the measure of it.

By help of the production function, it is possible to describe simply the

mechanism of economic growth. Economic growth is a production increase
achieved by an economic community. It is usually expressed as an annual
growth percentage depicting (real) growth of the national product. Economic
growth is created by two factors so that it is appropriate to talk about the
components of growth. These components are an increase in production input
and an increase in productivity.

The figure presents an economic growth process. By way of illustration, the

proportions shown in the figure are exaggerated. Reviewing the process in
subsequent years (periods), one and two, it becomes evident that production
has increased from Value T1 to Value T2. Both years can be described by a
graph of production functions, each function being named after the respective
number of the year, i.e., one and two. Two components are distinguishable in
the output increase: the growth caused by an increase in production input and
the growth caused by an increase in productivity. Characteristic of the growth
effected by an input increase is that the relation between output and input
remains unchanged. The output growth corresponding to a shift of the
production function is generated by the increase in productivity.
Accordingly, an increase in productivity is characterised by a shift of the
production function and a consequent change to the output/input relation. The
formula of total productivity is normally written as follows:

 Total productivity = Output quantity / Input quantity

According to this formula, changes in input and output have to be measured

inclusive of both quantitative and qualitative changes. In practice, quantitative
and qualitative changes take place when relative quantities and relative prices
of different input and output factors alter. In order to accentuate qualitative
changes in output and input, the formula of total productivity shall be written as
follows:

 Total productivity = Output quality and quantity / Input quality and quantity

MAIN PROCESS OF A COMPANY

A company can be divided into sub-processes in different ways; yet, the
following five are identified as main processes, each with a logic, objectives,
theory and key figures of its own. It is important to examine each of them
individually, yet, as a part of the whole, in order to be able to measure and
understand them. The main processes of a company are as follows:
 real process

 income distribution process

 production process

 monetary process

 market value process

Productivity is created in the real process, productivity gains are distributed in

the income distribution process and these two processes constitute the
production process. The production process and its sub-processes, the real
process and income distribution process occur simultaneously, and only the
production process is identifiable and measurable by the traditional accounting
practices. The real process and income distribution process can be identified and
measured by extra calculation, and this is why they need to be analysed
separately in order to understand the logic of production performance

Real process generates the production output, and it can be described by means
of the production function. It refers to a series of events in production in which
production inputs of different quality and quantity are combined into products of
different quality and quantity. Products can be physical goods, immaterial
services and most often combinations of both. The characteristics created into
the product by the manufacturer imply surplus value to the consumer, and on
the basis of the price this value is shared by the consumer and the producer in
the marketplace. This is the mechanism through which surplus value originates
to the consumer and the producer likewise. Surplus value to the producer is a
result of the real process, and measured proportionally it means productivity.

Income distribution process of the production refers to a series of events in

which the unit prices of constant-quality products and inputs alter causing a
change in income distribution among those participating in the exchange. The
magnitude of the change in income distribution is directly proportionate to the
change in prices of the output and inputs and to their quantities. Productivity
gains are distributed, for example, to customers as lower product prices or to
staff as higher pay. The measurement of productivity shall be developed so that
it “will indicate increases or decreases in the productivity of the company and
also the distribution of the ’fruits of production’ among all parties at interest”.
The price system is a mechanism through which productivity gains are
distributed, and besides the business enterprise, receiving parties may consist of
its customers, staff and the suppliers of production inputs.

The production process consists of the real process and the income distribution
process. A result and a criterion of success of the production process is
profitability. The profitability of production is the share of the real process result
the producer has been able to keep to himself in the income distribution
process. Factors describing the production process are the components of
profitability, i.e., returns and costs. They differ from the factors of the real
process in that the components of profitability are given at nominal prices
whereas in the real process the factors are at fixed prices.

Monetary process refers to events related to financing the business. Market

value process refers to a series of events in which investors determine the
market value of the company in the investment markets.

Productivity Model
The Challenge of Productivity Measurement
(in context to the software industry- case study)
Abstract
In an era of tight budgets and increased outsourcing, getting a good measure of
an organization’s productivity is a persistent management concern.
Unfortunately, experience shows that no single productivity measure applies in
all situations for all purposes. Instead, organizations must craft productivity
measures appropriate to their processes and information needs. This article
discusses the key considerations for defining an effective productivity measure.
It also explores the relationship between quality and productivity. It does not
advocate any specific productivity measure as a general solution.

Introduction
A productivity measure commonly is understood as a ratio of outputs produced
to resources consumed. However, the observer has many different choices with
respect to the scope and nature of both the outputs and resources considered.
For example, outputs might be measured in terms of delivered product or
functionality, while resources might be measured in terms of effort or monetary
cost. Productivity numbers may be used in many different ways, e.g., for project
estimation and process evaluation. An effective productivity measure enables
the establishment of a baseline against which performance improvement can be
measured. It helps an organization make better decisions about investments in
processes, methods, tools, and outsourcing. In addition to the wide range of
possible inputs and outputs to be measured, the interpretation of the resulting
productivity measures may be affected by other factors such as requirements
changes and quality at delivery. Much of the debate about productivity
measurement has focused narrowly on a simplistic choice between function
points and lines of code as size measures, ignoring other options as well as
many other equally important factors. Despite the complexity of the software
engineering environment, some people believe that a single productivity
measure can be defined that will work in all circumstances and satisfy all
measurement users’ needs. This article suggests that productivity must be
viewed and measured from multiple perspectives in order to gain a true
understanding of it.

International Standards
One might hope to look to the international standards community for guidance
on a common industry problem such as productivity measurement. While some
help is available from this direction, it is limited. The most relevant resources are
as follows:

• IEEE Standard 1045, Software Productivity Measurement [2] describes the

calculation of productivity in terms of effort combined with counts of lines
of code or function points. It recommends variations to address software
re-use and maintenance scenarios. It provides a project characterization
form, but does not discuss how different characteristics might lead to
different productivity measures.
• ISO/IEC Standard 15939, Software Measurement Process [1]. This
standard is the basis for the Measurement and Analysis Process Area of
the Capability Maturity Model – Integration [4]. ISO/IEC Standard 15939
contains two key elements: a process model and an information model.
The process model identifies the principal activities required for planning
and performing measurement. The ISO/IEC information model defines
three levels of measures: indicators, base measures, and derived
measures. Figure 1 illustrates these different levels of measurement. The
counts of inputs and outputs used to compute productivity are base
measures in this terminology. Each base measure quantifies a single
measurable attribute of an entity (process, product, resource, etc.)
Multiple values of base measures are combined mathematically to form
derived measures. A base or derived measure with an associated analysis
model and decision criteria forms an indicator.

• SEI technical reports discuss how to define effort [12] and size measures
[13], but give little guidance on how they can be combined to compute
things such as productivity. Thus, the SEI reports discuss considerations in
defining base measures (using the ISO/IEC Standard 15939 terminology),
while IEEE Standard 1045 suggests methods of combining base measures
to form derived measures of productivity. Note that none of these
standards systematically addresses the factors that should be considered
in choosing appropriate base measures and constructing indicators of
productivity for specific purposes.
Figure 1: Levels of a Measurement Construct
The Concept of Productivity

Many different approaches to measuring productivity have been adopted by

industry for different purposes. This section discusses the common approaches
and makes recommendations for their application. The basic equation for
productivity is as follows:

The simple model of Figure 2 illustrates the principal entities related to the
measurement and estimation of productivity. A process converts input into
output consuming resources to do so. We can focus on the overall software
process or a sub process (contiguous part of the process) in defining the scope
of our concern. The input may be the requirements statement for the overall
software process and for the requirements verification sub process, or the
detailed design for the coding process (as another example). Thus
(requirements) input may consist of initial product requirements or previous
work products provided as input to a sub process. In this model the
“requirements” are relative to the process or sub process under consideration.

The (product) output may be software or another work product (e.g.,

documentation). Resources typically have a cost (in the local currency)
associated with them. Usually, effort is the primary resource of concern for
software development. The output has a value associated with it (typically the
price to the customer). The value is a function of capability, timeliness, quality,
and price.
Figure 2: Simple Model of Productivity

Using this model, the numerator of productivity may be the amount of product,
volume of requirements, or value of the product (that is, things that flow into the
process or sub process). The denominator of productivity may be the amount or
cost of the resources expended. The designer of a productivity measure must
define each of the elements of the model in a way that suits the intended use
and environment in which the measurement is made.

The product of software development is complex. In addition to code, other

artifacts such as data,
documentation, and training may be produced. If the resources expended in the
production of each artefact can be distinguished, then separate productivity
numbers may be computed for each. However, the most common approach is to
use a broad size measure (such as lines of code or function points) with a
consolidated measure of resources.

Figure 2 is a generic model. The designer of a productivity measure must

address the following issues in defining a precise productivity indicator:

• Scope of outputs (product) – which products get counted?

• Scope of resources – which resources get counted?
• Requirements (or other input) churn – what if the target changes during
development?
• Quality at delivery – how are differences in quality accounted for?

These issues are discussed in the following sections.

Size Measurement

This section describes the two most common methods for measuring size – the
numerator of the productivity equation. These are Function Points and Lines of
Code. Function Points is a functional
(input) size measure, while Lines of Code is a physical (output) size measure.

The amount of functionality (requirements or input) satisfied usually

corresponds to the amount of product delivered. However, the value of a
product from the customer perspective often does not track closely to its size.
Reuse and code generation tools affect the effort to produce a given quantity
software. That is more requirements can be satisfied and more output produced
with less effort. Consequently the effects of these technologies must be
considered in determining productivity either by weighting the size measures or
defining multiple productivity measures for different development scenarios.
More than one size measure may be needed to capture all of the information
needed about the quantity of product delivered. That is software produced by
different methods may need to be counted separately.

Software size, itself, has an effect on productivity. The phenomenon of

“Diseconomy of Scale” has long been recognized in software development. This
means that the productivity of larger software projects is lower than the
productivity of smaller projects, all other factors being equal. Thus, comparisons
of projects of different sizes must take this effect into account. This effect is non-
linear so that as the range of software sizes increases, the differences in
productivity become larger.
Function Points
The Function Point Analysis (FPA) approach has been widely accepted for
estimating human-computer interface, transaction processing, and management
information systems. FPA involves a detailed examination of the project’s
interface description documents and/or prototypes of user interfaces. Usually,
these are developed early in the project’s life cycle. When they are not
available, similar materials from previous projects may be analyzed to obtain
analogous data. The FPA approach rates the complexities of interface elements
in a systematic way. Nevertheless, this approach still exhibits a significant
element of subjectivity. Many different FPA counting algorithms have been
developed. The following discussion is based on the Function Point Counting
Practices Manual. Different, but similar, measures are required for each of five
types of interface elements that are counted. The complexity of each interface
element is quantified by considering the presence of three specific attributes.
Separate counting rules are applied to each interface type.

FPA was originally developed and promoted as an estimation technique.

Because it is based on
information that is available relatively early in the life cycle, it can be quantified
with greater confidence than physical size measures (such as Lines of Code)
during project planning. However, one of the disadvantages of FPA is that even
after the project is complete, the measurements of Functions Points still remain
subjective. Key contributors to the accuracy of this estimation approach are the
skill of the measurement analyst conducting the function point count, as well as
the completeness and accuracy of the descriptive materials on which the count
is based.

Lines of Code
Perhaps, the most widely used measure of software size is Lines of Code. One of
the major weaknesses of Lines of Code is that it can only be determined with
confidence at project completion. That makes it a good choice for measuring
productivity after the fact, however. The first decision that must be made in
measuring Lines of Code is determining what to count. Two major decisions are
1) whether to count commentary or not, and 2) whether to count lines or
statements. From the productivity perspective, comments require relatively little
effort and add no functionality to the product so they are commonly excluded
from consideration.

• The choice between lines and statements is not so clear. “Line” refers to a
line of print on a source listing. A statement is a logical command
interpretable by a compiler or interpreter. Some languages allow multiple
logical statements to be placed on one line. Some languages tend to
result in long statements that span multiple lines. These variations can be
 amplified by coding practices. The most robust measure of Lines of Code
is generally agreed to be “non-comment source statements”.

A major factor in understanding productivity, especially in product line

development, is taking into account the sources of the software that go into a
delivery. Usually, at least three categories are used:
• New – software that is developed specifically for this delivery
• Modified – software that is based on existing software, but that has been
modified for this delivery
• Reused – pre-existing software that is incorporated into the delivery
without change
The resources required to deliver these classes of software are different.
Modified software takes
advantage of the existing design, but still requires coding, peer review, and
testing. Reused software usually does not require design, coding, or peer review,
but does require testing with the other software.

These differences can be taken into consideration by weighting the Lines of

Code of each type or by
computing a separate productivity numbers for each type. The latter approach
requires recording resource (effort) data separately for each type of software, so
it tends to be less popular. The result of the weighting approach often is
described as “Equivalent Source Lines of Code”. Typical values for weighting
schemes are as follows:

• New – 100%
• Modified – 40 to 60%
• Reused – 20 to 40%

Ideally the weights are determined by the analysis of historical data from the
organization. The concept of Equivalent Source Lines of Code makes it possible
to determine the productivity of projects with varying mixes of software sources.
Alternatively, some general adjustment factor can be applied to the software
size as a whole to account for reuse and other development strategies.
However, that captures the effect less precisely than counting the lines from
different sources separately.

Other Size Measures

Many additional size measures have been proposed, especially to address
object-oriented development. These include counts of use cases, classes, etc.
Card and Scalzo [11] provide a summary of many of them. However, none are
widely accepted in practice. That doesn’t mean that they should not be
considered. However, their use in productivity measures does not eliminate
concern for the factors discussed here.

Resource Measurement
The denominator, resources, is widely recognized and relatively easily
determined. Nevertheless, the
obvious interpretation of resources (whether effort or monetary units) can be
misleading. The calculation of productivity often is performed using only the
development costs of software. However, the magnitude of development
resources is somewhat arbitrary. The two principal considerations that must be
addressed are 1) the categories of cost and effort to include and 2) the period of
the project life cycle over which they are counted.
Four categories of labour may be considered in calculating productivity:
engineering, testing, management, and support (e.g., controller, quality
assurance, and configuration management). Limiting the number of categories
of labour included increases the apparent productivity of a project. Calculations
of productivity in monetary units may include the costs of labour as well as
facilities, licenses, travel, etc. When comparing productivity across organizations
it is essential to ensure that resources are measured consistently, or that
appropriate adjustments are made.
Requirements Churn and Quality at Delivery
Figures 3a, 3b, and 3c illustrate the effect of the period of measurement on the
magnitude of the resource measure. These figures show the resource profile
(effort or cost) for a hypothetical project broken into three categories:
production, rework, and requirements breakage. Requirements breakage
represents work lost due to requirements changes. This may be 10 to 20 percent
of the project cost. Rework represents the resources expended by the project in
repairing mistakes made by the staff. Rework has been shown to account for 30
to 50 percent of the costs of a typical software project [5]. Usually, rework effort
expended prior to delivery of the product is included in the calculation of
productivity, while rework after delivery usually is considered “maintenance”.
However, this latter rework is necessary to satisfy the customer.

A comparison of Figures 3a and 3b shows the effect of delivery date on

productivity. The overall resources required for the two projects to deliver a
product that eventually satisfies the customer is assumed to be identical.
However, the project in Figure 3a delivers earlier than the project in Figure 3b.
Consequently the development effort of the project in Figure 3a seems to be
smaller, resulting in apparently higher productivity. However, this project will
require more rework during maintenance than the project in Figure 3b.

The project in Figure 3b is similar in every other respect except that it delivered
later and had more time to fix the identified problems. This latter project would
be judged to have “lower” development productivity, although the total life cycle
costs of ownership would be very similar for the two projects. Thus,
development cost (and consequently apparent productivity) are affected by the
decision on when and under what conditions the software is to be delivered. The
true productivity of the two projects is essentially identical.

Comparing Figures 3b and 3c show the impact of requirements churn. While the
two projects deliver at the same time, and so exhibit the same apparent
productivity, they may experience different amounts of requirements breakage.
The project in Figure 3b, with the larger requirements breakage actually has to
produce with a higher “real” productivity to deliver the same output as the
project in Figure 3c where requirements breakage is lower.
Figure 3a – Apparent “High” Productivity Project

Figure 3b – Apparent “Low” Productivity Project

Figure 3c – Highest Effective Effort (Lowest Productivity)

In summary, when determining what value to put in the denominator of the

productivity equation, the resources required for rework after delivery should be
added to the development cost, while the resources associated with
requirements breakage should be subtracted. Obviously, tracking the data
necessary to do this is difficult, but such data helps to develop a more precise
understanding of productivity.
Typical Productivity Calculations
Measures of size and resources may be combined in many different ways. The
three common approaches to defining productivity based on the model of Figure
2 are referred to as physical, functional, and economic productivity. Regardless
of the approach selected, adjustments may be needed for the factors of
diseconomy of scale, reuse, requirements churn, and quality at delivery.

Physical Productivity

This is a ratio of the amount of product to the resources consumed (usually

effort). Product may be
measured in lines of code, classes, screens, or any other unit of product.
Typically, effort is measured in terms of staff hours, days, or months. The
physical size also may be used to estimate software performance factors (e.g.,
memory utilization as a function of lines of code).

Functional Productivity
This is a ratio of the amount of the functionality delivered to the resources
consumed (usually effort). Functionality may be measured in terms of use cases,
requirements, features, or function points (as appropriate to the nature of the
software and the development method). Typically, effort is measured in terms of
staff hours, days, or months. Traditional measures of Function Points work best
with information processing systems. The effort involved in embedded and
scientific software is likely to be underestimated with these measures, although
several variations of Function Points have been developed that attempt to deal
with this issue.

Economic Productivity
This is a ratio of the value of the product produced to the cost of the resources
used to produce it. Economic productivity helps to evaluate the economic
efficiency of an organization. Economic productivity usually is not used to
predict project cost because the outcome can be affected by many factors
outside the control of the project, such as sales volume, inflation, interest rates,
and substitutions in resources or materials, as well as all the other factors that
affect physical and functional measures of productivity. However, understanding
economic productivity is essential to making good decisions about outsourcing
and subcontracting. The basic calculation of economic productivity is as follows:

Economic Productivity = Value/Cost

Cost is relatively easy to determine. The numerator of the equation, value,

usually is recognized as a
combination of price and functionality. More functionality means a higher price.
Isolating the economic contribution of the software component of a system can
be difficult. Often, that can be accomplished by comparison with the price of
similar software available commercially.

Ideally, the revenue stream resulting from a software product represents its
value to the customer. That is, the amount that the customer is willing to pay
represents its value. Unfortunately, the amount of revenue can only be known
when the product has finished its useful life. Thus, the value must be estimated
in order to compute economic productivity, taking into consideration all the
factors affecting the customer’s decision to buy. Thus,

Value = f(Price, Time, Quality, Functionality)

Poor quality may result in warranty and liability costs that neutralize revenue.
Similarly, time must be considered when determining the economic value of a
product - a product which is delivered late to a market will miss sales
opportunities. Thus, the amount of revenue returned by it will be adversely
affected. Consequently, the calculation of value for economic productivity must
include timeliness and quality, as well as price and functionality.

Note that this definition of economic productivity does not take into
consideration the “cost to the
developer” of producing the product. Whether or not a product can be produced
for a cost less than its value (expected sales), is another important, but different
topic.

Comparing Productivity Numbers

Having chosen a productivity calculation along with appropriate definitions of
resource and size measures, productivity numbers can be produced. Comparing
productivity numbers from a series of closely related projects (e.g., members of
a product line) is straightforward. However, making comparisons across different
projects or organizations requires greater care.

Many factors affect the productivity achieved by a project. Most estimation

models provide adjustment factors to account for many of these factors.
Generally, these influencing factors fall into two categories: controllable and
inherent. These two categories of factors must be handled differently when
comparing productivity across projects or organizations.

Controllable factors can be changed by management. They are the result of

choice, although not always desirable choices. Examples of controllable factors
include personnel experience, development environment, and development
methods.

Depending on the purpose of the productivity comparison adjustments may be

made to account for these factors, especially when using productivity to
estimate project effort. However, productivity comparisons of completed
projects often are made specifically to evaluate the choices made by an
organization, so usually no adjustments are made for the controllable
factors when comparing productivity results from different projects.
Inherent factors are those that are built into the problem that the software
developers are trying to solve.
Examples of inherent factors (beyond the control of the software development
team) include:

• Amount of software developed (diseconomy of scale)

• Application domain (e.g., embedded versus information systems)
• Customer-driven requirements changes

The software development team cannot choose to develop less software than
necessary to do the job, build a different application than the customer ordered,
or ignore customer change requests in the pursuit of higher productivity.
Consequently, adjustments must be made for the inherent factors when
comparing productivity results from different projects. While quality at delivery
is a controllable factor, the eventual quality required by the customer is not, so
adjustments also should be made for post delivery repair, too.
Summary

Measures of product size and resources must be carefully selected in deciding

upon the construction of a productivity indicator. It is not simply a choice
between Function Points, Lines of Code, or another size measure. Many other
factors also must be considered. Table 1 summarizes the reported impact of
some of the factors previously discussed, as a percent of the project’s effort.

Table 1. Factors in Productivity Measurement

FACTOR TYPICAL IMPACT(%) REFERANCES

Requirement Changes 10 to 40 8, 9, 10

Diseconomy of Scale 10 to 20 8

Post Delivery Repair 20 to 40 5, 9

Software Reuse 40 to 60 8, 9

Left unaccounted for, the variable effects of these factors on measured

productivity can overwhelm any real differences in project performance. Even if
an organization finds itself unable to measure all of these factors, they should be
excluded consciously, rather than simply ignored.

No single measure of productivity is likely to be able to serve all the different

needs of a complex software organization, including project estimation, tracking
process performance improvement, benchmarking, and demonstrating value to
the customer. Multiple measures of productivity may be needed. Each of these
must be carefully designed. This article attempted to identify and discuss some
of the most important issues that must be considered. In particular, it did not
attempt to define a universal measure of productivity.

Use and interpretation of productivity measures

(on the basis of the study)
 Labour productivity is a useful measure: it relates to the single most
important factor of
production, is intuitively appealing and relatively easy to measure. Also, labour
productivity is a key determinant of living standards, measured as per capita
income, and from this perspective is of significant policy relevance. However, it
only partially reflects the productivity of labour in terms of the personal
capacities of workers or the intensity of their efforts. Labour productivity reflects
how efficiently labour is combined with other factors of production, how many of
these other inputs are available per worker and how rapidly embodied and
disembodied technical change proceed. This makes labour productivity a good
starting point for the analysis of some of these factors. One way of carrying out
further analysis is to turn to multifactor productivity (MFP) measures.

 Multifactor productivity measurement helps disentangle the direct growth

contributions of
labour, capital, intermediate inputs and technology. This is an important tool for
reviewing past growth patterns and for assessing the potential for future
economic growth.

 However, one has to be aware that not all technical change translates
into MFP growth. An
important distinction concerns the difference between embodied and
disembodied technological change. The former represents advances in the
design and quality of new vintages of capital and intermediate inputs and its
effects are attributed to the respective factor as long as the factor is
remunerated accordingly. Disembodied technical change comes “costless”, for
example in the form of general knowledge, blueprints, network effects or
spillovers from other factors of production including better management and
organisational change. The distinction is important from a viewpoint of analysis
and policy relevance.

 Further, in empirical studies, measured MFP growth is not necessarily

caused
technological change: other non-technology factors will also be picked up by the
residual. Such factors include adjustment costs, scale and cyclical effects, pure
changes in efficiency and measurement errors.

 MFP measures tend to understate the eventual importance of productivity

change in
stimulating the growth of output. In static models of production such as the one
used in this manual, capital is an exogenous input. In a dynamic context, this is
not the case and feedback effects exist between productivity change and
capital: suppose that technical change allows more output to be produced per
person. The static MFP residual measures just this effect of technical change.
However, additional output per person may lead to additional savings and
investment, and to a rise in the capital-labour ratio. Then, a traditional growth
accounting measure would identify this induced effect as a growth contribution
of capital, although it can be traced back to an initial shift in technology. Thus,
the MFP residual correctly measures the shift in production possibilities but does
not capture the induced effects of technology on growth (Rymes, 1971; Hulten,
2001).

Accounting is not explaining the underlying causes of growth. Growth

accounting and productivity measurement identifies the relative importance of
different proximate sources of growth. At the same time, it has to be
complemented by institutional, historical and case studies if one wants to
explore the underlying causes of growth, innovation and productivity change.