Activity Based Costing for Component-Based Software Development

Information Technology and Management 3, 137–160, 2002
 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.
Activity Based Costing for Component-Based
Software Development
ROBERT G. FICHMAN
fichman@bc.edu
Boston College, Wallace E. Carroll School of Management, 452B Fulton Hall,
140 Commonwealth Ave. Chestnut Hill, MA 02467-3808, USA
CHRIS F. KEMERER
ckemerer@katz.pitt.edu
University of Pittsburgh, 278a Mervis Hall, Pittsburgh, PA 15260, USA
Abstract. Component-based software development is a promising set of technologies designed to move
software creation from its current, labor-intensive, craft-like approach to a more modern, reuse-centered
style. However, a lesson learned from previous radical software process innovations is that a strong tech-
nology alone is generally insufficient for successful adoption. In order for gains to be realized from such
technologies the management practices surrounding the implementation of the new technology must also
change. It is with this view that we propose the adoption of a complementary management approach called
activity based costing (ABC) to allow organizations to properly account for and recognize the gains from
a component-based approach. ABC enables a management environment where appropriate incentives are
created for the development and reuse of software components. Data from a large software vendor who has
experience with ABC in a traditional software development environment are presented, along with a chart
of accounts for a modern, component-based model.
Keywords: activity based costing, ABC, activity based management, ABM, component-based software
development, object orientation, objects, expert services, software factory
1.
Introduction
The nature of software development is undergoing a dramatic change, one that strikes at
the core of how the industry will build software systems in the coming decade. Tradi-
tionally, large systems have been custom-built, using a “waterfall” approach to develop-
ment. Under this approach, a project begins with a requirements or needs analysis, then
proceeds linearly through stages of design, coding, testing, documentation, training and
implementation.
This custom-crafted approach to software is very expensive, as each project devel-
ops a custom product. This, despite the fact that many applications contain numerous
opportunities to rely on work products created for previous systems, including not only
program code, but analysis and design artifacts as well. While this issue has been widely
recognized, until recently modern software technologies made re-use possible on only
an ad hoc or local basis. Large-scale component reuse was typically not accomplished.
In response to this, a new approach has been proposed for the development of these
systems. Using object-oriented or other modern development tools many observers have

---

138
FICHMAN AND KEMERER
proposed what amounts to a manufacturing process for software development [5,6]. This
enhanced delivery capability should simultaneously result in cost savings and a higher
level of quality, as this approach allows for the reuse of proven components [21].
However, this new approach to software delivery creates a significant number
of managerial challenges. The development of reusable components for later assem-
bly into potentially many systems is a radical departure from the current, single-
use, project based approach that predominates in today’s systems development activi-
ties [19,20,22,25]. Many barriers stand in the way of adoption of this new approach, in-
cluding: an absence of technical infrastructures to support component reuse; an absence
of managerial guidelines for running component reuse projects; uncertainties about the
best ways to structure the work of reuse; lack of standard approaches for how to handle
ownership, coordination and versioning issues related to reusable components; and is-
sues related to reuse economics, costing and incentives [10,12,15]. Of these, we believe
that barriers related to economics, costing and incentives will figure especially promi-
nently in the ultimate level of adoption of large-scale reuse because these barriers are
not likely to be addressed through the ordinary course of technological progress in reuse
methods and tools.
In a typical software development environment, project managers have very lim-
ited incentives for investments in reuse, and, in fact, often have strong disincentives, in
terms of the likely negative impacts on project budgets and schedules that investments in
reusability often entail [26]. An approach that emphasizes the development of reusable
components, on the other hand, will require strong management of incentives for com-
ponent development, perhaps even to the point of creating separate reuse teams [3,9,15].
This, in turn, raises critical issues for project costing. In the current environment of
single use, the cost of software is simply the cost of the direct labor hours that went
into its development. With multiple use, this direct relationship breaks down because
an organization must devote considerable resources to reuse activities (e.g., maintaining
reuse infrastructures, developing and maintaining components, locating and evaluating
components, adapting and integrating components) that may be performed by – or on
behalf of – other project teams [24] or may occur outside of traditional project teams
altogether [3].
Given that when component-based software development is discussed an analogy is
often drawn with hardware manufacturing, it is not surprising that manufacturing should
also be the source for tools to assist with some of the management challenges offered
by this new approach. For guidance in how to manage issues related to costing and cost
management we look to work that goes under the rubric of “activity based costing,” or
ABC [4,17,23]. This is an approach originally designed as way to improve the allocation
of overhead costs in manufacturing settings in order to develop more accurate product
costs. With this approach, overhead and indirect costs are allocated to products based on
the degree to which those products actually “consume” the repetitive production activi-
ties of the firm, rather than being based on a single factor, such as the number of direct la-
bor hours associated with the product. Conventional methods of manufacturing product
costing have relied on assumptions about the labor-intensive manner in which products

---

ABC FOR COMPONENT-BASED DEVELOPMENT
139
were developed years ago, assumptions which have changed with increasing automation
and which today can produce startling anomalies in actual vs. standard costs [16, ch. 1,
23]. Similarly, the introduction of large-scale component reuse creates the potential for a
disconnect between the results of current software costing methods and the actual costs
involved with a reuse-intensive software process, because it likewise decreases the dom-
inance of direct labor costs in the total costs of software products. Without ABC or some
other new approach to costing, the substantial costs of developing reusable components
and maintaining an environment conducive to reuse will be misallocated. If the project
teams themselves perform the activities related to reuse, then the costs will end up hid-
den in the direct costs of different projects, and the project teams will operate under
major disincentives to invest in components for subsequent reuse. If, on the other hand,
separate reuse teams are created, there will be no way to properly allocate what could be
very substantial overhead costs associated with reuse teams back to individual project
teams.
As a result it appears that the application of ABC principles to component-based
software development could lead to a greater understanding of this new process of de-
veloping software. Such an understanding should eventually lead to:
• reduced cost of software development, as costly activities are identified and rational-
ized;
• greater control over delivery dates and schedules;
• reduced risk of budget over-runs;
• improved alignment of incentives related to reuse;
• more effective pricing of systems and system components.
The remainder of this article is organized as follows. Section 2 introduces the
ABC concept and applies it to the case of component software development. Sections 3
and 4 then describe research work with and descriptive empirical data from a major
commercial software vendor that has applied ABC to a traditional software development
process. Section 5 then extends this analysis to develop a proposed set of ABC accounts
for a component-based software development organization. Section 6 provides a brief
summary and conclusions.
2.
ABC for software
In a systematic component reuse environment, indirect costs and overhead associated
with reuse can become a significant portion of software development costs, possibly
exceeding 50% [3]. Traditional methods of accounting for indirect costs and overhead
(e.g., based on direct labor hours) are not an effective means of allocating costs in such
an environment, as these methods will tend to under-cost projects that are comparatively
heavy consumers of reuse activities, and over-cost projects that are light consumers of
reuse activities, thus leading to inappropriate conclusions about the true cost of those
projects. To see why, let us suppose we have two projects, both with 5000 h of direct

---

140
FICHMAN AND KEMERER
labor and an overhead allocation for reuse support of $30 per direct labor hour. This
overhead allocation is required because this hypothetical organization has developed a
large team of dedicated reuse specialists tasked with assuming most of the burden of
developing reusable components and making them available to project teams, as per
the “software factory” model of reuse [3]. These specialists analyze software domains
for reusability, develop and document reusable components, assist project teams in as-
sessing reuse opportunities, find and adapt components for use by project teams, certify
and document components offered by project teams and many other activities (as will
be described in section 5 in the ABC chart of accounts for software reuse). None of
these specialists is actually a part of either project team, whose members are tasked
only with developing software for their own project’s application. Now, assume that
the first project had little opportunity for reuse, and, in fact incorporated only one half
the average percent of reusable components as part of the final work product, while the
second project was a heavy consumer of reuse with double the average percentage of the
final work product being deriving from reused components. Despite this, each project
would be charged $150,000 (5000 × $30) to allocate the reuse overhead activities. In
this example, the net result of using traditional overhead allocation methods would be an
overcosting of the first project on the order of $75,000, and undercosting of the second
project by about $150,000. With ABC, by contrast, the indirect and overhead costs of
reuse would be apportioned based on the extent to which these projects actually “con-
sumed” the reuse related activities performed by the reuse specialist team, with the result
being much more accurate project costing.
Furthermore, traditional methods provide no systematic means for assessing and
improving the efficiency and effectiveness of reuse activities. ABC methods and associ-
ated Activity Based Management (ABM) principles provide a means to address both of
these shortcomings of traditional approaches.
ABC and ABM were originally developed to address product cost anomalies in a
manufacturing environment [16,17,23]. Beginning in the 1980’s it was observed that
indirect costs and overhead were comprising an ever growing proportion of true product
costs, yet traditional product volume-based cost allocation methods did not properly
distribute those costs. The result was that relatively complex, low volume products,
which were bigger consumers of overhead on a per unit basis, were under-costed, while
high volume, simple products were over-costed. Such costing anomalies can lead to
poor decisions in any domain where accurate knowledge of product costs is key, such as
for product pricing and product mix decisions.
ABC was developed to provide a more accurate approach to allocating overhead
costs to products. The basic insight underlying the ABC approach is that the repetitive
activities employed in the actual work of an organization can provide a sounder basis for
allocating costs. With the ABC approach, rather than viewing work products as being
direct consumers of overhead resources, the repetitive activities required to actually pro-
duce products are introduced to stand in between products and costs. These activities are
viewed as the consumers of resources, and in turn, products are viewed as consuming

---

ABC FOR COMPONENT-BASED DEVELOPMENT
141
activities. ABC provides a systematic method for mapping resource costs to activities
and from activities to products.
Although ABC was originally developed for repetitive manufacturing environ-
ments, it has since been generalized as a means to map true resources costs to any cost
object of interest not just products, but also services, customers, branch offices, and
projects [17, ch. 12, 27, p. 85]. However, ABC does not apply to every situation. For
ABC to apply well, three conditions should be met:
(1) indirect and overhead costs must be significant, and must be poorly accounted for
by traditional means;
(2) objects must exist for which management wishes to know true costs (products, cus-
tomers, projects, etc.);
(3) repetitive activities must exist that can serve as the basis for mapping indirect and
overhead costs to cost objects.
The first two criteria go to the relative pay-off from ABC, i.e., the pay-off will be
highest to the extent that these two criteria hold [8,17, pp. 100–101]. The third criterion
is self-evident, since the whole point of ABC is to use repetitive activities to better
account for the costs associated with cost objects.
A systematic reuse environment that relies on component-based software meets
these three criteria. First, such environments are often characterized by high overhead
costs associated with centralized reuse teams and infrastructure [3,19], and these costs
need not be highly correlated with direct project hours or costs because the amount
of reuse can vary widely from project to project [11]. Second, management typically is
quite concerned with the cost of software development projects and/or software products.
For example, at ComputerCo (the site of our empirical work) one major new product was
priced very aggressively based on the observation that, since reuse was substantial on the
project, it would be possible to have a high return on investment even with aggressive
pricing. Third, repetitive reuse related activities do exist (as will be explained below)
that can serve as a mapping between overhead costs and projects (or other cost objects).
ABC can provide two kinds of benefits to organizations practicing systematic
reuse. First, because it supports more accurate allocation of overhead costs, it can lead
to more accurate conclusions about the cost effectiveness of individual projects. In those
instances where the result of a project is a product sold to others, it can provide the basis
for pricing and for judging profitability.
Second, and perhaps equally important, ABC can provide the basis for assessing
and improving the productivity and effectiveness of reuse activities. Prior work model-
ing the economics of reuse provides a means to predict and judge whether the benefits of
systematic reuse can be expected to outweigh the costs in the aggregate [13]. However,
this work has not been intended to provide guidance for how to actually lower the costs
of reuse for any given level of benefit. In today’s business environment, management
has developed a low tolerance for overhead work even when it does, in fact, contribute
to the health and profitability of the organization. We believe this low tolerance stems,

---

142
FICHMAN AND KEMERER
Table 1
ABC terminology (adapted from [27]).
Term
Definition
Activity-based costing
A method of measuring the cost and performance of activities and cost objects.
Assigns costs to activities based on their use of resources, and assigns costs to
cost objects based on their use of activities.
Cost assignment view
Shows how costs are assigned to cost objects.
Resources
Economic elements applied or used in the performance of activities (e.g., la-
bor, equipment, materials, and floor space).
Resource cost driver
The link between resources and activities. Determines an activity’s unit cost.
Activity
A repetitive unit of work performed within an organization.
Activity cost driver
A factor that measures the extent of activity consumption by a given cost ob-
ject.
Cost object
The reason for performing an activity. Cost objects include products, services,
customers, projects and contracts.
Process view
Provides operational information about an activity.
Causal cost driver
Determines the overall effort required of an activity and the resources needed.
Performance measure
An indicator of the work performed and the results achieved in an activity.
at least in part, from a perception that overhead work tends to be performed inefficiently,
and has no clear mapping to the value producing activities of the organization. A well
run ABC/ABM program can counter this perception by showing where overhead costs
come from and where they go, and can also counter the possible reality underlying this
perception by providing a means to assess and improve the performance of activities that
are, in fact, heavy consumers of overhead resources.
We use the term ABC Model to refer to the overall structure of activities, resources,
resource cost drivers, cost objects, etc. comprising an ABC implementation. In this
paper we have chosen to standardize on the view of ABC articulated by Turney [27] (see
table 1).1
ABC takes two alternative views of the activities performed in an organization, as
illustrated in figure 1 below. This diagram, developed by Turney [27], was first presented
to the Consortium for Advanced Manufacturers-International, and thus is commonly
referred to as the “CAM-I Cross” [4, p. 54]. The first of the two views is called the
cost assignment view. This view (depicted vertically in figure 1) shows the flow of costs
through an activity, and consists of resources, resource cost drivers, activities, activity
cost drivers and cost objects. The second is called the process view. This view (depicted
horizontally in figure 1) shows the flow of performance-related information through the
1 However, to better conform to emerging consensus on ABC terminology, we use the terms resource cost
driver, activity cost driver, and causal cost driver, in place of the terms originally used by Turney, i.e.,
resource driver, activity driver, and cost driver, respectively.

---

ABC FOR COMPONENT-BASED DEVELOPMENT
143
Figure 1. Structure of an ABC model [27].
activity, and consists of causal cost drivers, activities, and performance measures. The
purpose of the first view is to support more accurate allocation of costs; the purpose of
the second view is to guide cost reduction efforts. (Definitions of all highlighted terms
are provided in table 1.)
The cost assignment view of an ABC model is developed according to the follow-
ing seven step procedure (see [4,27] for more detailed guidance):
(1) identify the repetitive activities within the scope of the ABC effort. This is often
referred to as developing the Activity Dictionary [17, ch. 8];
(2) group the activities into activity centers (collections of activities that share the same
overhead cost pools);
(3) identify the resources used in overhead work and aggregate them in to pools by
activity center;
(4) identify resource cost drivers, e.g., drivers that determine the relative share of each
overhead cost pool attributable to each activity;
(5) determine the basis for calculating unit costs of each activity;
(6) identify cost objects, e.g., products, customers, products;
(7) determine the activity cost drivers, i.e., drivers that define the extent of consumption
of each activity by cost objects of interest.

---

144
FICHMAN AND KEMERER
The process view of an ABC model is developed according to the following two
step procedure:
(1) identify causal cost drivers, i.e., what drives the level or volume of each activity;
(2) identify performance measures, i.e., measures that can be used to determine how
efficiently and effectively each activity is performed.
Once the structure of an ABC model has been defined, the next step is to set aside
a period of time for collection of data about the activities, and to use these data to deter-
mine standard values for resource cost drivers and activity cost drivers to be used in cost
allocation.
3.
Research approach
To examine the feasibility of this approach, we worked closely with a major software de-
veloper who had a number of recently completed projects that could be evaluated using
an ABC approach. Through a series of on-site interviews and review of contempora-
neous documents, we documented a set of completed projects using a prototype ABC
approach. These results are presented below. Based on this experience and a survey of
the reuse literature, an ABC model and chart of accounts were further developed for a
future component-based software development approach.
3.1. Methodology
The primary research approach was to investigate a set of field based cases of a ma-
jor software developer, which we will refer to as ComputerCo. The selection crite-
ria for the study favored projects thought to represent successful current examples of
reuse and those that were using object-oriented tools and methods. A total of fifteen
projects were included in the study, of which four are highlighted here merely to illus-
trate various approaches. The primary data collection approach was a series of semi-
structured interviews with project managers and team members from a set of completed
or nearly completed object-oriented projects. The focus in these interviews was to cap-
ture project management differences developed in the field to aid management of these
modern projects. More structured data were also gathered using a standard question-
naire. Altogether we gathered data on staffing, project size, activities performed, alloca-
tion of budgeted costs by activity, software development technologies used, the nature of
the software being developed, extent and nature of software reuse achieved, budget and
schedule conformance, perceived reuse facilitators and inhibitors, and details regarding
how reuse was managed (processes, tools, measures, economic models, funding mech-
anisms, etc.). Of this, the data related to activity costs are most pertinent to the present
study.

---

ABC FOR COMPONENT-BASED DEVELOPMENT
145
4.
Results
4.1. Prior and new management models compared
A natural starting point for thinking about ABC analysis for software is in the work
breakdown structures (WBS) related to specific systems development activities in the
lifecycle. To this end our data-site, a developer of packaged software, created a list of
27 activities to track. This list is shown as table 2. A description of each appears in
appendix A.
Note that on the list there are many traditional overhead activities that are neces-
sary functions for the sale and support of software products. These overhead activities
(most notably activities 20, and 24 through 27) need to be properly allocated to prod-
ucts. Therefore, they would represent candidate activities to be analyzed using an ABC
approach. In addition, there are many “overhead” style activities relating to software
development activities (including activities 5, 17, 18, 21). The development of this type
of detailed work breakdown structure is a useful first step for software development or-
ganizations who wish to better manage their costs, whether or not they perceive a need
to allocate these costs appropriately to software products.
Special note might be taken of Activity #5, Reuse Planning and Acquisition. While
in part addressing how the current product might reuse existing components, it also
investigates how components developed for this product might be created in such a way
as to increase the opportunities for their reuse in other products. In a traditional software
development project, this may be all of the activity devoted toward reuse. Note that
for these four examples (and for the set of 15 projects generally) the amount of effort
devoted to this task was relatively small. This is consistent with much of the literature
on software reuse in terms of the limited amount of reuse that often takes place when
projects are managed in the traditional way [19,22].
In examining the data for these earlier projects, it is clear that they differ markedly
in their use of resources. Product 1, a relatively older and largely traditional-style project,
had a considerable amount of time in Activity #2 Plan And Project Management and
Activity #6, Code And Unit Test, versus later projects. This is a product that was man-
aged in what might be termed a “project style”, rather than a “product style” approach,
whereby the focus is on planning and executing this project in relative isolation to other,
either predecessor or successor projects. Product 2, of similar vintage as Product 1,
differs mainly in how resources were devoted to design activities rather than testing
activities. One use of such data may be in determining the relative efficiency of such dif-
fering strategies. For example, projects with relatively higher percentages of resources
in the design phase could be analyzed to determine whether they had consistently lower
than average costs for other activities (such as testing), or for subsequent projects (such
as to develop later versions of the product). Project 3, a newer vintage project, demon-
strates how a significant amount of resources can be devoted to overhead activities (e.g.,
39% in Activity #24–27, SG&A) in software development, and therefore how critical to
managerial decision making it can be to properly account for overhead costs. Finally,
Product 4, a recently completed product, reflects a somewhat different pattern, even

---

146
FICHMAN AND KEMERER
Table 2
WBS distributions for traditional projects.a
Product
Product
Product
Product
1%s
2%s
3%s
4%s
Systems development and maintenance
1. FUNCTIONAL REQUIREMENTS ANALYSIS
3
2
1
5
2. PLAN AND PROJECT MANAGEMENT
13
2
1
5
3. PRODUCT DESIGN
0
2
3
10
4. INTERNAL DESIGN
0
8
2
10
5. REUSE PLANNING AND ACQUISITION
0
0
1
2
6. CODE AND UNIT TEST
38
23
19
25
7. OTHER PROGRAMMING SUPPORT
8
0
1
1
8. TEST PLANNING
3
2
3
2
9. COMPONENT TEST AND PRODUCT
VERIFICATION TEST
4
0
2
8
10. SYSTEMS TEST
9
3
2
10
11. PERFORMANCE ANALYSIS AND MEASUREMENT
2
1
1
3
12. OTHER VERIFICATION AND VALIDATION
ACTIVITIES
0
1
1
2
13. CONFIGURATION MANAGEMENT AND QUALITY
ASSURANCE
1
2
0
1
14. INFORMATION DEVELOPMENT
5
5
3
5
15. MAINTENANCE, Direct Support of Customers
0
10
2
NA
16. MAINTENANCE, Fix Correction
17. MAINTENANCE, Support Coordination
13
17
3
NA
18. MAINTAINING DEVELOPER WORKSTATION
0
0
2
1
Program-products management and planning
19. PROJECT OFFICE FUNCTIONS
0
0
0
2
20. PRODUCT AND MARKET PLANNING
0
3
7
1
Program supervision and general
21. COMMON GENERAL DEVELOPMENT
ENVIRONMENT/TOOLS AND SUPPORT
0
1
0
0
22. MANAGEMENT SUPERVISION
0
5
4
3
23. ADMINISTRATIVE SUPPORT
1
4
3
2
Sales, general and administrative
0
10
39
24. MARKETING SUPPORT
0
25. DISTRIBUTION
1
26. MARKETING COMMUNICATION
0
27. MARKETING DEVELOPMENT
0
a Disguised data. Cells show the budgeted cost of the activity as a percentage of the total budget for the
project. Some columns may not add to 100% due to rounding. A value of zero represents a true value
between 0.0 and 0.4. Some prior projects not measured at lowest levels of detail.
when allowances are made for the fact that full maintenance has not yet begun. This
product was developed using object-oriented techniques, and the distribution of activi-

---