SOFTWARE PROJECT MANAGEMENT

IN THE TWENTY-FIRST CENTURY

January 27, 1999

Capers Jones, Chief Scientist

Artemis Management Systems

Software Productivity Research, Inc.

(An Artemis company)
1 New England Executive Park
Burlington, MA 01803

Phone 781 273 0140

FAX 781 273 5176

Abstract

As the start of the twenty-first century approaches, software project managers are facing
interesting new kinds of projects that did not occur until the last decade of the twentieth
century. Chief among these are “mass update” projects such as those involving the Euro
and the Year 2000. In addition, the rise in lawsuits alleging project management failure
is leading to a need to expand the project management body of knowledge with a number
of legal issues.

For successful software project management, many activities must be supported

including process assessments, estimating, quality control, sizing of deliverables, and
technology selection. A new generation of software project management tools are
approaching that will eliminate many of the gaps in current project management tools.

Copyright {SYMBOL 227 \f "Symbol"} 1999 by Capers Jones, Chief Scientist,

Artemis Management Systems.
All Rights Reserved.
 SOFTWARE PROJECT MANAGEMENT
IN THE TWENTY-FIRST CENTURY

INTRODUCTION

Software project management is a new occupation that did not have more than a handful
of practitioners until the 1960’s. Yet as the 20th century ends, software project managers
in the United States number more than 250,000. The global total is more than 1,000,000.
These numbers are growing at about 10% per year.

Software project management has been one of the most demanding jobs of the 20th
century. In the 21st century, there are indications that the difficulties of project
management will grow even more taxing.

At the end of the 20th century a new class of software project emerged more or less
unexpectedly. This class might be termed “mass-update projects” because the work
involves making updates to hundreds of software applications simultaneously. The
launch of the Euro in January of 1999 and the year 2000 problem in January of 2000 are
prime examples of mass-update projects. However, they will not be the last such
projects. By about 2010 telephone numbers will need expansion, and eventually social
security numbers will need expansion.

Another form of mass update, although based on a very different technology, is projects
associated with deploying enterprise resource planning (ERP) packages. These massive
tool suites approach or exceed 250,000 function points in size. The ERP packages are
designed to replace scores or hundreds of existing applications and unify corporate
financial and business data.

But the deployment of ERP applications is a major project in its own right, and can take
more than 24 calendar months and involve hundreds of personnel and scores of
consultants. Further, if this work is not done well, the impact of moving to ERP
technology can be harmful rather than beneficial.

Another new aspect of software project management is that of managing “virtual teams.”
These teams operate out of different cities or countries, and communicate via using the
Internet, intranets, and the World Wide Web augmented by information-sharing tools.

Up until the availability of global networks such as the Internet, software projects of
almost every type assumed close physical proximity of most of the workers. Indeed,
projects where workers were not in close proximity had significantly lower productivity
levels than teams working face to face.

Since about 1995, network and information-sharing capabilities have become powerful
enough so that joint projects can now be undertaken by teams of workers located
thousands of miles apart. The internet and intranets plus powerful groupware tools now

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
make it possible to construct major software projects using at least three locations located
eight time zones apart. This would allow software projects to be developed around the
clock using 24 hour days, which could lead to major reductions in elapsed time to market.

Up until 1999 large software were among the least productive and had the longest
development schedules of any major industrial artifacts. In the twenty-first century,
virtual software teams with 24-hour a day development periods could make software one
of the most productive industries instead of the least productive industry as it was in the
twentieth century. However, the project management body of knowledge needs to be
expanded to encompass virtual teams in multiple countries and cities.

Software project managers are responsible for the construction of some of the most
expensive assets that corporations have ever attempted to build. For example, large
software systems cost far more to build and take much longer to construct than the office
buildings occupied by the companies that have commissioned the software. Really large
software systems in the 100,000 function point size range can cost more than building a
domed football stadium, a 50-story skyscraper, or a 70,000 ton cruise ship.

Not only are large software systems expensive, but they also have one of the highest
failure rates of any manufactured object in human history. The term “failure” refers to
projects that are canceled without completion due to cost or schedule overruns. Table 1
illustrates an overall pattern of software project successes and failures.

Table 1 uses six size ranges each an order of magnitude apart. Table 1 is taken from the
author’s book, Patterns of Software Systems Failure and Success (International Thomson
Press, 1996).

Table 1: Software Project Outcomes By Size of Project

PROBABILITY OF SELECTED OUTCOMES

Early On-Time Delayed Canceled Sum

1 FP 14.68% 83.16% 1.92% 0.25% 100.00%
10 FP 11.08% 81.25% 5.67% 2.00% 100.00%
100 FP 6.06% 74.77% 11.83% 7.33% 100.00%
1000 FP 1.24% 60.76% 17.67% 20.33% 100.00%
10000 FP 0.14% 28.03% 23.83% 48.00% 100.00%
100000 FP 0.00% 13.67% 21.33% 65.00% 100.00%

Average 5.53% 56.94% 13.71% 23.82% 100.00%

As can easily be seen from table 1, small software projects are successful in the majority
of instances. The risks and hazards of cancellation or major delays rise quite rapidly as
the overall application size goes up. Indeed, the development of large applications in
excess of 10,000 function points is one of the most hazardous and risky business
undertakings of the modern world.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
The significant numbers of failures for large software projects explains a disturbing
phenomenon that will grow worse in the twenty-first century. There are an ever-
increasing number of lawsuits that involve allegations of project management failure.
This means that software project managers are at some personal risk. The anticipated
deluge of lawsuits involving the year 2000 problem will make the litigation situation
much more common than it has been in the past.

Given the costs and difficulty associated with software system construction, one might
think that software project managers would be highly trained and well equipped with
state of the art planning and estimating tools, with substantial analyses of historical
software cost structures, and with very thorough risk analysis methodologies. These are
natural assumptions to make, but they are unfortunately not the case.

Many software project managers are either untrained or poorly trained for the work at
hand, and also severely under equipped. Using data collected from consulting studies
performed by the author’s company, Software Productivity Research, less than 25% of
U.S. software project managers have received any formal training in software cost
estimating, planning, or risk analysis. Less than 20% of U.S. software project managers
have access to modern software cost estimating tools; less than 10% have access to any
significant quantity of validated historical data from projects similar to the ones they are
responsible for.

By comparison, the software technical personnel who design and build software are often
fairly well trained in the activities of analysis, design, and software development although
there are certainly gaps in topics such as software quality control.

There are 15 basic topics that must be solidly embedded in the project management body
of knowledge in the twenty-first century. Each of these 15 topics is an issue of
importance to professional software project managers:

Table 1: Key Topics for Twenty-First Century Software Managers

1. Software “mass update” projects

2. Software “enterprise resource planning” or ERP projects
3. Software “virtual teams” using the internet
4. Software sizing methods
5. Software estimating methods
6. Software project planning methods
7. Software methodology management
8. Software technology selection
9. Software quality control
10. Software progress tracking
11. Software measurements
12. Software risk analysis
13. Software value analysis
14. Software process assessments

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
15. Software process improvements

Following are summaries of the implications of these fifteen software project

management topics. The project management body of knowledge requires rapid
expansion for dealing with all 15 of these software topics.

Software “Mass Update” Projects

The last five years of the twentieth century witnessed a new class of software work
involving simultaneous updates to hundreds or thousands of applications are
approximately the same time. The largest examples of this class of project were the
introduction of the unified European currency or Euro, and the efforts devoted to date
field repairs or expansion in order to fix the well-known year 2000 problem.

In every company that was impacted by these two projects, they were the most expensive
software projects history. Outside of software, these updates are among the most
expensive business projects in human history.

For large enterprises such as Fortune 500 companies, year 2000 repairs will average more
than $250,000,000 per company. For companies dealing heavily with currency and
finance such as banks and international conglomerates, updating applications in behalf of
the Euro will average more than $50,000,000 per company among the Fortune 500 set.

The costs will continue for many years. After the year 2000 problem all of the missed
dates will require emergency repairs. Worse, many of the missed dates will trigger
litigation that can run on for years. Further, some of the methods used to deal with the
year 2000 are only temporary. For example the “windowing” solution and the
“encapsulation” solution will require replacement and permanent repairs by about 2025.

Problems with the Euro can also lead to litigation, although to date many more cases have
been filed about the year 2000 problem. For example a significant error in currency
conversion to the Euro could lead to potential losses with values of millions of dollars for
major corporations, who might be inclined to sue.

Now that this class of project has surfaced, a continuing stream of similar projects will
occur for at least the next 50 years. Some of these similar projects will include the need
to expand the need to repair dates under UNIX, the need to repair dates pushed into the
next century via windowing, the need to expand telephone numbers, and the need to
expand social security numbers.

Software Enterprise Resource Planning (ERP) Projects

Business software has some of the attributes of businesses themselves. Specific business
units such as marketing, sales, manufacturing, or human resource organizations have
funded software applications.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
Many companies are somewhat feudal in structure. That is, the executives of the major
business units may be rivals as often as they are colleagues. As a result, scores or
hundreds of corporate software applications have a very narrow focus and support only
the business unit that funded them.

When top corporate management or the board of directors want a consolidated picture of
corporate finances, sales, personnel, or other topics of business information, it has been
difficult to extract overall data from these localized applications.

The concept of enterprise resource planning (ERP) software such as SAP, Oracle, J.D.
Edwards, and Baan is that the costs of linking scores or hundreds of aging applications is
too great to generate a positive return on investment. Instead, it would be more cost
effective to install and deploy enterprise-wide packages that are already integrated.

However, the path to ERP deployment is complex and requires very careful planning if it
is to be accomplished without encountering cost and schedule overruns. The project
management role in ERP deployment shares some of the attributes of other mass-update
projects. ERP is often a corporate decision, and will affect multiple business units
concurrently.

ERP deployment also shares some of the attributes of other kinds of software projects.
ERP deployment is often under-estimated and under-budgeted. Discussions with ERP
clients indicate that almost as much must be spent on training and migration costs as on
the ERP package itself. In addition, some ERP deployments stumble and are not
successfully completed, just as some software projects are terminated without
completion. Also, some ERP projects end up in court when schedules are overrun or
when the ERP packages fail to deliver the promised benefits.

Successful ERP deployment requires project managers who can handle not only the
technical challenges, but the political and social challenges as well. Here too, the project
management body of knowledge is in need of expansion based on solid empirical data.

Software Virtual Teams and Electronic Commerce

The emergence of intranets, the Internet, and the World Wide Web as business tools has
generated some of the most profound changes in business operations in all of human
history. One of the major project management challenges of the twenty-first century will
be to take advantage of the power of these new capabilities to create new forms of
business operations.

For most of history, the fundamental concept of project management tacitly assumed
physical proximity of the workers. Now that the Internet and high bandwidth
communications are common, it is possible to carry out major projects where none of the
participants ever see each other face to face. Indeed, the participants do not even need to
be in the same country.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
The implications of this profound change in business operation are not fully realized as
the twentieth century ends. There is an urgent need to expand the project management
body of knowledge to deal with the new reality of dispersed workers and global supply
chains.

The significance of the Internet is so great that a major new company, Amazon, has
appeared that does not even have conventional retail stores or sales personnel. Amazon’s
entire business is built upon utilization of the Internet and World Wide Web. The
appearance of Amazon is triggering hundreds of attempts to replicate the same approach,
with varying degrees of success.

Although much of the literature on electronic business centers on marketing and

merchandizing, there are many other domains where electronic communication, the
Internet, and the World Wide Web are already generating substantial savings and a very
positive return on investment. For example, electronic commerce is now the preferred
medium for:

• Defect reporting from customers to vendors

• Customer-support activities by vendors
• Releasing maintenance upgrades
• Communication among specialists such as year 2000 researchers

Although there are some concerns about web security for business transactions involving
large amounts of money, the ease of using the web for service and support has been
extremely effective, and no doubt will grow even more effective in the future.

From a project management point of view, the real significance is the expansion of
projects so that virtual teams of workers located across multiple countries and cities can
act as a unified whole. Indeed, even telecommuters or employees who work at home can
now be full team participants. Software is uniquely suited to using virtual teams because
software products involve no physical objects.

Software Sizing

The term “sizing” refers to methods for predicting the volume of various deliverable
items such as source code, specifications, and user manuals. Sizing is the precursor to
cost estimating, and is one of the most critical software project management tasks.

New sizing technologies based on function point metrics have begun to transform the
task of sizing from a very difficult kind of work with a high error rate to one of
acceptable ease and accuracy. Sizing has long been regarded as among the most difficult
of all software project management tasks, and yet it is a logical precursor to many other
activities such as planning and estimating.

The task of sizing is concerned with predicting the quantity of deliverable items, which
must be produced in support of a software project. Three major kinds of deliverables are

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
of primary concern: 1) paper deliverables such as plans and specifications; 2) source
code; 3) test cases and test materials.

Now that function points are the most widely used software metric in the world, there are
thousands of projects that have been measured well enough to extract useful sizing data
for all major deliverables: paper documents such as plans and manuals; source code; and
test cases. Table 2 illustrates typical document volumes created for various kinds of
software:

Table 2: Number of Pages Created Per Function Point for Software Projects

Systems MIS Military Commercial

Software Software Software Software

User Requirements 0.45 0.50 0.85 0.30

Functional specifications 0.80 0.55 1.75 0.60
Logic specifications 0.85 0.50 1.65 0.55
Test plans 0.25 0.10 0.55 0.25
User tutorial documents 0.30 0.15 0.50 0.85
User reference documents 0.45 0.20 0.85 0.90

Total document set 3.10 2.00 6.15 3.45

Table 2 illustrates only a small sample of the paperwork and document sizing capabilities
that are starting to become commercially available. Full sizing tools such as
KnowledgePlan{SYMBOL 226 \f "Symbol"} can handle more than 50 discrete kinds of
document, and automatically adjust the sizing assumptions to match military and civilian
norms. Sizing logic can also be adjusted to match other factors such as paper size and
type size. The most recent advance in documentation sizing includes the ability to
predict the sizes of documents translated into other languages, such as translating help
text into Japanese, French, and German for international markets.

For sizing source code volumes, there is now fairly good data available on about 400
programming languages and preliminary data on another 200. Some commercial
software estimating tools can handle multiple languages in the same application, such as
a mixture of COBOL and SQL, or Basic mixed with Assembly language.

Sizing logic is now available for many other forms of software work product, including
test cases and test scripts. One major aspect of sizing, although the artifacts are
unintended, is the ability to predict the numbers of “bugs” or defects that will be found in
software work products.

On the whole, as the twenty-first century begins software sizing is far more sophisticated
than it was only 10 years ago.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
Software Cost Estimating

The phrase “software cost estimating” is an umbrella term that includes several major
kinds of estimation:

1) Cost and resource estimation

2) Schedule estimation
3) Quality and reliability estimation
4) Maintenance and enhancement estimation.

Software cost estimating is concerned with predicting the schedules, resources, and costs
of producing and maintaining the major deliverables of software projects. It is important
to understand that the phrase “major deliverables” refers to more than just source code.
For many large systems and for all military software projects, the effort devoted to
production of paper documents in the form of requirements, plans, specifications, and
user manuals is far more expensive than the code itself.

Moreover, the most expensive kind of activity for software development is the effort
devoted to finding and fixing bugs. Therefore accurate software cost estimating must of
necessity include accurate quality estimating too.

For an expanded discussion of software estimating tools and techniques, refer to the
author’s book Estimating Software Costs (McGraw Hill, 1998).

The normal sequence of software estimation as practiced in the most successful

enterprises is as follows:

Step 1: Start With Sizing

Sizing is concerned with predicting the volumes of major kinds of software deliverables,
including but not limited to:

• Paper documents
Specifications
Plans
Manuals
• Source code
New source code
Reusable source code
• Test cases
New test cases
Reusable test cases
• Defect potentials
Requirements
Design
Code

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
 Documents
Bad fixes or secondary defects

Step 2: Identify the Activities to be Included

SPR's estimating method supports a standard list of 25 software development activities

including requirements, analysis, internal and external design, reusable code acquisition,
package acquisition, new code development, existing code modification, integration,
design and code inspections, 12 forms of testing, user document production, etc.

A critical aspect of accurate estimation is to identify which activities and tasks will be
performed. For example, small client-server projects only use about eight of the 25
activities in the SPR list. Large mainframe applications use about 15 activities. Large
system software projects use about 20, and military software projects use all 25.
Accurate estimation is impossible without knowledge of the activities that are going to be
utilized.

Step 3: Estimate Software Defect Potentials and Removal Methods

The most expensive and time-consuming work of software development is the work of
finding bugs and fixing them. It is not possible to create an accurate software cost
estimate without also predicting defect potentials and knowing the effectiveness of
various kinds of reviews, inspections, and test stages that are planned.

Project managers should look for estimating tools that include full defect estimation
capabilities, and support all known kinds of defect removal activity. This is necessary
because the total effort, time, and cost devoted to a full series of reviews, inspections, and
multi-stage tests will cost far more than source code.

Step 4: Estimate Staffing Requirements

Every software deliverable has a characteristic "assignment scope" or amount of work

that can be done by a single employee. For example, an average assignment for an
individual programmer will range from 5,000 to 15,000 source code statements (from
about 50 up to 2000 function points).

However, large systems also utilize many specialists such as data base administrators,
quality assurance specialists, technical writers, testers, and the like. Identifying each
category of worker, and the numbers of workers, is the 4th step in software cost
estimation.

Step 5: Adjust Assumptions Based on Capabilities and Experience

Software personnel can range from top experts with years of experience to rank novices
on their first assignment. Once the categories of technical workers have been identified,
the next step is to make adjustments based on typical experience and skill factors.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
Experts can take on more work, and perform it faster, than novices. This means that
experts will have larger assignment scopes and higher production rates than average or
inexperienced personnel. Other adjustments include vacations and holidays, unpaid and
paid overtime, and assumptions about the geographic dispersal of the software team.

Step 6: Estimate Resources and Schedules

Resource and schedule estimates are closely coupled, and often performed in an iterative
manner. Accurate resource estimation requires knowledge of the numbers and
experience levels of the software team and the sizes of the deliverables they are expected
to produce.

Accurate schedule estimation requires knowledge of the activities that will be performed,
the sizes of various deliverables, the overlap between activities with mutual
dependencies, and the numbers and experience levels of the software team.

Step 7: Estimate Costs

Costs are the last stage of software project estimation. Costs will vary due to these
causes: 1) The average salaries of workers vary from company to company, region to
region, and industry to industry; 2) The burden rate or overhead rate applied to software
salaries varies even more than basic compensation; 3) For long-term projects inflation
rates must be considered; 4) For international projects currency conversion ratios must be
considered.

There are also special costs that may be incurred that will have to be dealt with
separately: 1) Licenses for any acquired software needed; 2) Capital costs for any new
equipment; 3) Moving and living costs for new staff members; 4) Travel costs for
international projects; and so forth; 5) Contractors and subcontractors costs.

Step 8: Maintenance and Enhancement Estimation

Software projects can continue to be used and modified for many years. Maintenance
and enhancement estimation are special topics, and are more complex than new project
estimation. (Project managers should look for estimating tools that handle both
enhancements and maintenance for a minimum of 5 years and maximum of 20 years after
initial deployment.)

It is obvious that software estimating and software planning are logically related. This
relationship is becoming evident to management tool vendors as well, and as a result a
number of mergers and acquisitions have occurred between companies that develop
planning tools and those that develop estimating tools.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
Software Project Planning (Project Management)

The phrase “project management” often refers to a class of tool that can handle very
complex scheduling problems involving hundreds of activities and personnel. The
Artemis tool suite is a prime example of an enterprise-level project planning tool. Many
other similar tools exist as well.

Planning for software projects often requires working out complex networks of
dependencies and critical path sequences. The state of the art of software project
planning requires a combination of specific software knowledge coupled to general
scheduling and critical path analysis.

Examples of specialized software knowledge include the impact of various design

methods, programming languages, and defect removal operations on the projects being
planned. Examples of the specific kinds of project management knowledge include the
ability to create Gantt and PERT charts, handle resource balancing, overtime, and critical
path analyses. These two forms of knowledge must be melded together to successfully
plan the outcome of a software project.

As the twenty-first century approaches project management companies such as Artemis

and software estimating companies such as Software Productivity Research (SPR) are
merging and pooling technologies. The results are leading to unified tool suites for
software project managers.

These software planning and estimating tool suites are accompanied by “templates” that
contain rules and knowledge for software projects in various industries such as banking,
telecommunications, defense, or insurance.

By the early years of the twenty-first century, planning and estimating tools for software
project managers should be as sophisticated and powerful as they are for older and more
mature forms of management.

Software Methodology Management

In recent years a new kind of project management tool called “methodology

management” has entered the market place. The word “methodology” refers to a well-
defined set of standard techniques for stepping through a software development cycle
from requirements until deployment. Examples of typical software methods are those of
structured development, rapid application development (RAD), information engineering
(IE), and a host of others.

Prior to the advent of methodology management tools, formal software methodologies

were described on paper in the form of rather massive books. A typical software
methodology required from 500 to more than 1500 pages of descriptive materials, and
often included more than 50 forms and checklists.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
The bulk and inconvenience of such massive volumes of paper explains why many
methodologies were only used for very large systems. The methodology management
tools, as a class, have put the information on line in flexible applications that give project
managers and technical personnel an easy way to access and customize the methods.
This class of tool should become more powerful and handle a wider range of
methodologies in the twenty-first century.

Software Technology Selection

One of the most difficult aspects of software project management is technology selection.
The software industry lacks the equivalent of a “Consumer Reports” that provides truly
objective testing of various software tools and methods. Software tool and methodology
vendors tend to make highly exaggerated claims of increased productivity, shortened
schedules, or better quality. They manage to ignore topics such as steep learning curves
or types of projects for which their approaches may not be suitable at all. The result is
that software technology selection is carried out in a protracted and expensive trial and
error basis.

Somewhat surprisingly, the function point metric is beginning to have a place in

technology selection. Function points can be used to examine tools and tool usage.
Table 3 illustrates some of the variations in project management tool capacities,
expressed in function points:

Table 3: Numbers and Size Ranges of Project Management Tools

(Size data expressed in terms of function point metrics)

Project Management Lagging Average Leading

Project planning 1,000 1,250 3,000
Project cost estimating 3,000
Statistical analysis 3,000
Methodology management 750 3,000
Year 2000 analysis 2,000
Quality estimation 2,000
Assessment support 500 2,000
Project measurement 1,750
Portfolio analysis 1,500
Risk analysis 1,500
Resource tracking 300 750 1,500
Value analysis 350 1,250
Cost variance reporting 500 1,000
Personnel support 500 500 750
Milestone tracking 250 750
Budget support 250 750
Function point analysis 250 750
Backfiring: LOC to FP 750
Function point subtotal 1,800 5,350 30,250
Number of tools 3 10 18

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
As can be seen, leading companies deploy many more project management tools than
laggards, and also tend to deploy the more robust enterprise-level tools. In addition, the
leading companies tend to use more of the features of the tools that are available.

Thus the function point metric can be used in two distinct but complementary ways
during technology and tool selection decision making: 1) Function points can be used to
judge the completeness of tool suites; 2) Function points can be used to measure and
validate claims of improved productivity, schedules, or quality.

Software Quality Control

Historically, the costs of finding and fixing bugs have dominated software cost structures.
Defect removal operations have also exerted a major impact on software development
schedules. The topic of quality control is so important to cost and schedule control that
the author regards it as impossible to make substantial improvements in software
productivity without first improving software quality. Every software project manager
should understand the basic technologies associated with software defect prevention and
defect removal.

Software quality is on the critical path for staying within bounds in terms of both
software schedules and software costs. Unfortunately, software quality control is a topic
about which many software project managers know little or nothing. Many of the most
severe defects enter software projects via the requirements. Table 4 summarizes current
U.S. norms in terms of software defect levels.

Table 4: U.S. Averages in Terms of Defects per Function Point

Defect Origins Defects per

Function Point

Requirements 1.00
Design 1.25
Coding 1.75
Document 0.60
Bad Fixes 0.40
Total 5.00

These numbers represent the total numbers of defects that are found and measured from
early software requirements throughout the remainder of the life cycle of the software.
The defects are discovered via requirement reviews, design reviews, code inspections, all
forms of testing, and user-reported problem reports.

Software Progress Tracking

Once a software project is underway, there are no fixed and reliable guidelines for
judging its rate of progress. The software industry has long utilized ad hoc milestones

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
such as completion of design or completion of coding. However, these milestones are
notoriously unreliable.

The simultaneous deployment of software sizing tools, estimating tools, planning tools,
and methodology management tools can provide fairly unambiguous points in the
development cycle that allow progress to be judged more or less effectively. For
example, software sizing technology can now predict the sizes of both specifications and
the volume of source code needed. Defect estimating tools can predict the numbers of
bugs or errors that might be encountered and discovered. Although such milestones are
not perfect, they are better than the former approaches.

Software Measurements

The software industry has long suffered from a severe shortage of valid historical data on
software schedules, resources, costs, and quality. Software project managers are the
primary beneficiaries of good historical data, and should be on the leading edge in
collecting and providing such data. However, measurement has long been a project
management weakness. This section discusses the kinds of software measurements that
are valuable, and also the economics or return on investment in software measurements.

Software Risk Analysis

Software projects are subject to a variety of risks such as creeping requirements,

inadequate tool deployment, missed schedules, cost overruns, poor quality, and the like.
However, these risks are so common that risk-management consultants are now able to
identify the risks that are most likely to occur for any particular size and kind of software
project. Risk analysis automation is now starting to occur in the form of either stand-
alone tools or as components of other kinds of project management tools such as cost
estimating tools.

Software Value Analysis

Software value analysis is a difficult but not impossible project management technology.
Software projects generally return “value” to users in one or more of six different forms:
1) Software can generate direct revenues; 2) Software can generate indirect revenues; 3)
Software can reduce operating costs; 4) Software can offer competitive advantages; 5)
Software can benefit human safety or health; 6) Software can benefit national defense or
security.

Each of these general categories of software value can now be explored, although some
are more difficult than others. In addition to the intrinsic value of software to the
organizations that use it, software is also an asset from the point of view of the Internal
Revenue Service in the United States and the tax bodies of other countries and states.
This means that the taxable value of software is now an important topic. Here too,
methods and tools are starting to be available that can deal with the tax implications of
software.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
Software Process Assessments

A software process assessment is roughly analogous to a complete medical examination

for a human patient. Both process assessments and medical diagnostic studies should
find everything that is right, and whatever is wrong, in both cases. Hopefully, not very
much will be found that is wrong. However, it is better to know about things that are
wrong, and to find out as early as possible. Several forms of process assessment are
discussed, including the method of the Software Engineering Institute (SEI) and of
Software Productivity Research (SPR).

Software Process Improvements

Continuing with the previous analogy with medical diagnosis, once problems have been
identified the next step is to prescribe an appropriate therapy program. Once a software
process assessment has found problems or weaknesses, the next step is to begin to
alleviate those weaknesses. These software therapy programs work best if they are
carefully planned, and if the expense levels are balanced against their value and return on
investment.

The project management level is the lowest rung in most corporate hierarchies with
spending authority for tools, and some input into the selection of methodologies and
software processes. Therefore it is important for project managers to know how to
evaluate tools, methods, and processes and determine which might be helpful, and which
might not be suitable. Here too, the topics are important but not readily available to
project managers.

SUMMARY AND CONCLUSIONS

The occupation of software project manager did not exist until about 1960. In the 39
years since the position first appeared, the number of software project managers has
expanded to more than 250,000 in the United States alone, and more than 1,000,000 on a
global basis.

Software project management is one of the more difficult forms of management. The
project management body of knowledge is still incomplete for software, in part because
the software industry grew faster than our ability to expand the body of knowledge.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
SUGGESTED READINGS IN SOFTWARE PROJECT MANAGEMENT

Boehm, Barry Dr.; Software Engineering Economics; Prentice Hall, Englewood Cliffs,
NJ; 1981; 900 pages.

Brooks, Fred; The Mythical Man Month; Addison-Wesley, Reading, MA; 1995; 295
pages.

Brown, Norm (Editor); The Program Manager’s Guide to Software Acquisition Best
Practices; Version 1.0; July 1995; U.S. Department of Defense, Washington, DC;
142 pages.

Charette, Robert N.; Software Engineering Risk Analysis and Management; McGraw
Hill, New York, NY; 1989; ISBN 0-07-010719-X; 325 pages.

Charette, Robert N.; Application Strategies for Risk Analysis; McGraw Hill, New York,
NY; 1990; ISBN 0-07-010888-9; 570 pages.

DeMarco, Tom; Controlling Software Projects; Yourdon Press, New York; 1982; ISBN
0-917072-32-4; 284 pages.

DeMarco, Tom and Lister, Tim; Peopleware; Dorset House Press, New York, NY; 1987;
ISBN 0-932633-05-6; 188 pages.

DeMarco, Tom; Why Does Software Cost So Much?; Dorset House Press, New York,
NY; ISBN 0-932633-34-X; 1995; 237 pages.

DeMarco, Tom; Deadline; Dorset House Press, New York, NY; 1997.

Department of the Air Force; Guidelines for Successful Acquisition and Management of
Software Intensive Systems; Volumes 1 and 2; Software Technology Support Center,
Hill Air Force Base, UT; 1994.

Dreger, Brian; Function Point Analysis; Prentice Hall, Englewood Cliffs, NJ; 1989; ISBN
0-13-332321-8; 185 pages.

Grady, Robert B.; Practical Software Metrics for Project Management and Process
Improvement; Prentice Hall, Englewood Cliffs, NJ; ISBN 0-13-720384-5; 1992; 270
pages.

Grady, Robert B. & Caswell, Deborah L.; Software Metrics: Establishing a Company-
Wide Program; Prentice Hall, Englewood Cliffs, NJ; ISBN 0-13-821844-7; 1987;
288 pages.

Grady, Robert B.; Successful Process Improvement; Prentice Hall PTR, Upper Saddle
River, NJ; ISBN 0-13-626623-1; 1997; 314 pages.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
Howard, Alan (Ed.); Software Metrics and Project Management Tools; Applied
Computer Research (ACR; Phoenix, AZ; 1997; 30 pages.

Humphrey, Watts S.; Managing the Software Process; Addison Wesley Longman,
Reading, MA; 1989.

Humphrey, Watts; Personal Software Process; Addison Wesley Longman, Reading, MA;
1997.

Humphrey, Watts; Managing Technical People; Addison Wesley Longman, Reading,

MA; 1997; ISBN 0-201-54597-7; 326 pages.

IFPUG Counting Practices Manual, Release 4, International Function Point Users Group,
Westerville, OH; April 1995; 83 pages.

Jones, Capers; Applied Software Measurement; McGraw Hill, 2nd edition 1996; ISBN 0-
07-032826-9; 618 pages.

Jones, Capers; Assessment and Control of Software Risks; Prentice Hall, 1994; ISBN 0-
13-741406-4; 711 pages.

Jones, Capers; New Directions in Software Management; Information Systems

Management Group; ISBN 1-56909-009-2; 150 pages.

Jones, Capers; Patterns of Software System Failure and Success; International Thomson
Computer Press, Boston, MA; December 1995; 250 pages; ISBN 1-850-32804-8;
292 pages.

Jones, Capers; The Year 2000 Software Problem - Quantifying the Costs and Assessing
the Consequences; Addison Wesley, Reading, MA; 1998; ISBN 0-201-30964-5; 303
pages.

Jones, Capers; Software Quality – Analysis and Guidelines for Success; International
Thomson Computer Press, Boston, MA; ISBN 1-85032-876-6; 1997; 492 pages.

Jones, Capers; Estimating Software Costs; McGraw Hill, New York; ISBN 0-07-
9130941; 1998; 725 pages.

Jones, Capers: “Sizing Up Software;” Scientific American Magazine, Volume 279, No. 6,
December 1998; pages 104-111.

Kan, Stephen H.; Metrics and Models in Software Quality Engineering; Addison Wesley,
Reading, MA; ISBN 0-201-63339-6; 1995; 344 pages.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.
Multiple authors; Rethinking the Software Process; (CD-ROM); Miller Freeman,
Lawrence, KS; 1996. (This is a new CD ROM book collection jointly produced by
the book publisher, Prentice Hall, and the journal publisher, Miller Freeman. This
CD ROM disk contains the full text and illustrations of five Prentice Hall books:
Assessment and Control of Software Risks by Capers Jones; Controlling Software
Projects by Tom DeMarco; Function Point Analysis by Brian Dreger; Measures for
Excellence by Larry Putnam and Ware Myers; and Object-Oriented Software
Metrics by Mark Lorenz and Jeff Kidd.)

Rubin, Howard; Software Benchmark Studies For 1997; Howard Rubin Associates,
Pound Ridge, NY; 1997.

Strassmann, Paul; The Squandered Computer; The Information Economics Press, New
Canaan, CT; ISBN 0-9620413-1-9; 1997; 426 pages.

Stukes, Sherry, Deshoretz, Jason, Apgar, Henry and Macias, Ilona; Air Force Cost
Analysis Agency Software Estimating Model Analysis; TR-9545/008-2; Contract
F04701-95-D-0003, Task 008; Management Consulting & Research, Inc.; Thousand
Oaks, CA 91362; September 30 1996.

Symons, Charles R.; Software Sizing and Estimating – Mk II FPA (Function Point
Analysis); John Wiley & Sons, Chichester; ISBN 0 471-92985-9; 1991; 200 pages.

Thayer, Richard H. (editor); Software Engineering and Project Management; IEEE Press,
Los Alamitos, CA; ISBN 0 8186-075107; 1988; 512 pages.

Umbaugh, Robert E. (Editor); Handbook of IS Management; (Fourth Edition); Auerbach

Publications, Boston, MA; ISBN 0-7913-2159-2; 1995; 703 pages.

Wiegers, Karl A; Creating a Software Engineering Culture; Dorset House Press, New
York, NY; 1996; ISBN 0-932633-33-1; 358 pages.

Yourdon, Ed; Death March - The Complete Software Developer’s Guide to Surviving
“Mission Impossible” Projects; Prentice Hall PTR, Upper Saddle River, NJ; ISBN 0-
13-748310-4; 1997; 218 pages.

Zells, Lois; Managing Software Projects - Selecting and Using PC-Based Project
Management Systems; QED Information Sciences, Wellesley, MA; ISBN 0-89435-
275-X; 1990; 487 pages.

Copyright {symbol 227 \f "Symbol"} 1999 by Capers Jones, SPR, Inc. {PAGE }
All Rights Reserved.