Productivity Measurement

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, learningby-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-labourenergy-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 nonlinear 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.