What to Read Next
Already a member?Sign in
Software is an increasingly pervasive part of the New Economy. As a result, today’s general managers need to be aware of the most effective methods for developing and deploying software products and services within their organizations. Delegating such decisions to a technical staff, however skilled, can be a risky strategy. A study completed last year contains a surprising insight for managers: Dealing with the software revolution requires a process that is not revolutionary but evolutionary.
Evidence of the increasing importance of software abounds. In the United States alone, sales of software products and services exceeded $140 billion during 1998, a gain of more than 17% from the previous year.1 In 2000, the software industry’s contribution to the U.S. economy was expected to surpass that of the auto industry and overtake all other manufacturing industry groups for the first time.2 Employment in software-related positions is growing, too. In 1998, the U.S. software industry directly employed more than 800,000 people, with an average salary twice the national figure.3 More than 2 million people are now employed as software programmers, showing that software is not developed at a Microsoft or an Oracle but within the information-technology departments of large, traditional organizations.4
Software also is playing a larger role in the content delivered to customers in many industries. Nowadays, the average family sedan or high-end coffee maker may contain more software than the first Apollo spacecraft. What’s more, the software features in those products may be the most critical differentiating factors. And even in industries in which software is not yet part of the products, it is playing a greater role in the products’ development. As companies adopt new computer-aided design technologies, the development processes for many products increasingly resemble those found in the software industry.
Developing Products on Internet Time
Given the importance of software, the lack of research on the best ways to manage its development is surprising. Many different models have been proposed since the much-cited waterfall model emerged more than 30 years ago. Unfortunately, few studies have confirmed empirically the benefits of the newer models. The most widely quoted references report lessons from only a few successful projects.
Read the Full ArticleAlready a subscriber? Sign in
1. “Forecasting a Robust Future,” www.bsa.org/statistics/index.html?/statistics/global_economic_studies_c.html.
2.Measured in terms of value added. Ibid.
4.“A Survey of the Software Industry,” The Economist, May 25, 1996, 14.
5. See, for example: M.A. Cusumano and R. Selby, “Microsoft Secrets” (New York: Free Press, 1995); and F.P. Brooks, “The Mythical Man-Month” (Reading, Massachusetts: Addison-Wesley, 1995).
6. A. MacCormack, R. Verganti and M. Iansiti, “Developing Products on Internet Time: The Anatomy of a Flexible Development Process,” Management Science 47, no. 1 (January 2001).
7. M. Iansiti and A. MacCormack, “Developing Products on Internet Time,” Harvard Business Review 75 (September–October 1997): 108–117.
8. The first two versions of Internet Explorer relied extensively on licensed technology.
9. W.W. Royce, “Managing the Development of Large Software Systems: Concepts and Techniques” (Procedures of WESCON [Western Electric Show and Convention], Los Angeles, August 1970).
10. J.L. Connell and L. Shafer, “Structured Rapid Prototyping: An Evolutionary Approach to Software Development” (Englewood Cliffs, New Jersey: Yourdon Press, 1989).
11. B. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE Computer 21 (May 1988): 61–72.
12. For example, in Boehm’s spiral model, the outer layer of the spiral contains the activities of detailed design, coding, unit testing, integration testing, acceptance testing and implementation. Those activities are carried out sequentially.
13. That does not preclude the fact that “throwaway” prototypes are used in such a process. Indeed, they are likely to be extremely important in establishing a direction for the initial design work.
14. See, for example: C. Wong, “A Successful Software Development,” IEEE Transactions on Software Engineering (November 1984): 714–727.
15. T. Gilb, “Principles of Software Engineering Management” (Reading, Massachusetts: Addison-Wesley, 1988), 84–114.
16. The survey was distributed to 39 firms, of which 17 responded with data on completed projects. The resulting sample of products is quite diverse and includes products and services targeted at both commercial and consumer users.
17. Quality was assessed on a seven-point scale, with level four indicating the product was at parity with competitive offerings.
18. H.A. Linstone and M. Turoff, eds., “The Delphi Method: Techniques and Applications” (Reading, Massachusetts: Addison-Wesley, 1975).
19. Projects in our sample differed significantly with regard to the number of lines of code developed. We therefore normalized the resources consumed in each project to reflect the development of an application of standard size. We adjusted the resulting measure for scale effects (larger projects were found to consume relatively fewer resources) and complexity effects (projects to develop Web-based services were found to consume relatively fewer resources, because of the specifics of the programming language used).
20. A beta version, as defined, is not a throwaway prototype. It is a working version of the system. The measure of the percentage of product functionality contained in the first beta was adjusted for scale effects.
21. We also examined the relationship an early beta release has with resource productivity. One might have imagined that in an evolutionary process there is a penalty to pay in terms of productivity, given the possibility that some early design work will be thrown away as customer requirements become clearer. However, our results showed no association between an early release to customers and lower productivity. The benefits from an early release appear to overcome the potential drawbacks of multiple iterations.
22. M. Iansiti and A. MacCormack, “Developing Products on Internet Time,” Harvard Business Review 75 (September–October 1997): 108–117.
23. As a result, the correlation between feedback time and product quality is not statistically significant.
24. See, for example, R. Katz and T.J. Allen, “Investigating the Not-Invented-Here (NIH) Syndrome: A Look at the Performance, Tenure and Communication Patterns of 50 R&D Project Groups,” in “Readings in the Management of Innovation,” eds. M. Tushman and W. Moore (New York: HarperBusiness, 1982), 293–309.
25. We used the term “generations” to distinguish between major “platform” projects (that is, those in which major changes were made to the previous version of a product) and minor derivative/incremental projects.
26. The measure of generational experience we used in our analysis was the percentage of the development team that had previously completed more than two generations of software projects. Note that the variation in generational experience explains more than 24% of the variation in resource productivity.
27. Note that there is a relationship between those two characteristics. Namely, a scaleable architecture is likely to be modular. A modular architecture, however, is not necessarily scaleable.
28. The measure we used, adjusted to control for scale effects, was a ratio of the resources dedicated to architectural design relative to the resources dedicated to development and testing.
29. Those investments explain more than 15% of the variation in product quality. We found no significant association between them and differences in resource productivity.
30. In our sample, measures of the parameters in combination explain almost half the variation in product quality and a quarter of the variation in resource productivity.
31. For example, consider attempting back in early 1996 to conduct market research into the features that a browser should contain. Most people would have had no clue what a browser was meant to do. Hence traditional market research techniques (focus groups, surveys and the like) would have had less value.
Readers interested in the general topic of managing product development are directed to a popular textbook, “Revolutionizing Product Development,” by Steven Wheelwright and Kim Clark, published in 1992 by Free Press. The most practical publication specifically on software development may be the 1996 Microsoft Press book “Rapid Development,” by Steve McConnell.
A deeper discussion of the open-source approach can be found at www.opensource.org/. To read more about Linux and one of the companies involved in its distribution, see the Harvard Business School case “Red Hat and the Linux Revolution,” by Alan MacCormack, no. 9-600-009.
For a discussion of Microsoft’s approach to developing software, see “Microsoft Secrets,” by Michael Cusumano and Richard Selby, a 1995 Free Press book. Harvard Business School’s multimedia case “Microsoft Office 2000,” by Alan MacCormack, illustrates that approach in detail (case no. 9-600-023), and the accompanying CD-ROM contains interviews with team members and a demonstration of Microsoft’s Web-based project-management system.
A new model of software development with similarities to the evolutionary model is “extreme programming.” Details can be found at www.ExtremeProgramming.org/. The Software Engineering Institute at Carnegie-Mellon University is a useful source of research on software-engineering management. See www.sei.cmu.edu/.