Software Project Management In The 21st Century - Article

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 FAX

781 273 0140 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. All Rights Reserved.

{PAGE }

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

1 FP 10 FP 100 FP 1000 FP 10000 FP 100000 FP

Early 14.68% 11.08% 6.06% 1.24% 0.14% 0.00%

On-Time 83.16% 81.25% 74.77% 60.76% 28.03% 13.67%

Delayed 1.92% 5.67% 11.83% 17.67% 23.83% 21.33%

Canceled 0.25% 2.00% 7.33% 20.33% 48.00% 65.00%

Sum 100.00% 100.00% 100.00% 100.00% 100.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. All Rights Reserved.

{PAGE }

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 everincreasing 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. All Rights Reserved.

{PAGE }

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. All Rights Reserved.

{PAGE }

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. All Rights Reserved.

{PAGE }

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. All Rights Reserved.

{PAGE }

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 Software

MIS Software

Military Software

Commercial Software

User Requirements Functional specifications Logic specifications Test plans User tutorial documents User reference documents

0.45 0.80 0.85 0.25 0.30 0.45

0.50 0.55 0.50 0.10 0.15 0.20

0.85 1.75 1.65 0.55 0.50 0.85

0.30 0.60 0.55 0.25 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. All Rights Reserved.

{PAGE }

Software Cost Estimating The phrase “software cost estimating” is an umbrella term that includes several major kinds of estimation: 1) 2) 3) 4)

Cost and resource estimation Schedule estimation Quality and reliability estimation 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. All Rights Reserved.

{PAGE }

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. All Rights Reserved.

{PAGE }

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. All Rights Reserved.

{PAGE }

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 welldefined 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. All Rights Reserved.

{PAGE }

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 Project planning Project cost estimating Statistical analysis Methodology management Year 2000 analysis Quality estimation Assessment support Project measurement Portfolio analysis Risk analysis Resource tracking Value analysis Cost variance reporting Personnel support Milestone tracking Budget support Function point analysis Backfiring: LOC to FP Function point subtotal Number of tools

Lagging 1,000

Average 1,250

750

500

300

500

750 350 500 500 250 250 250

1,800 3

5,350 10

Leading 3,000 3,000 3,000 3,000 2,000 2,000 2,000 1,750 1,500 1,500 1,500 1,250 1,000 750 750 750 750 750 30,250 18

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

{PAGE }

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 Requirements Design Coding Document Bad Fixes Total

Defects per Function Point 1.00 1.25 1.75 0.60 0.40 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. All Rights Reserved.

{PAGE }

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 standalone 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. All Rights Reserved.

{PAGE }

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. All Rights Reserved.

{PAGE }

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 CompanyWide 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. All Rights Reserved.

{PAGE }

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 007-032826-9; 618 pages. Jones, Capers; Assessment and Control of Software Risks; Prentice Hall, 1994; ISBN 013-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-079130941; 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. All Rights Reserved.

{PAGE }

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 013-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-89435275-X; 1990; 487 pages.

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

{PAGE }