Chapter 1

The Business of Software: A Personal View

If the software business were like other businesses, there would be no need for this book. But software is not like other businesses. First of all, the technology consists of a digital "soft" good -- usually English-like programming commands eventually translated into zeros and ones -- that provide instructions to a computer. These instructions form products that companies can standardize for many users, customize for individual users, or do something in between. Companies that rely on this highly malleable technology for their livelihoods must be unique in many ways, particularly in how they deal with business models, product strategy, people (especially software engineers), and management of a core activity: software development.

There are many examples of how software technology and software companies differ from what we see in traditional manufacturing and service industries. In how many businesses does making one copy or one million copies of your product cost about the same? How many businesses have up to 99 percent gross profit margins for their product sales? In how many businesses do many products companies eventually become services or hybrid companies (that is, providing some customization of product features and technical services such as system integration and maintenance), whether they like it or not? In how many businesses is there frequently a ten- or twentyfold difference in productivity between your best employee and your worst one? How many businesses tolerate some 75 to 80 percent of their product-development projects routinely being late and over budget, with "best practice" considered to be 20 percent on time? How about a company where the people who build products often consider themselves artists rather than scientists or engineers and have the mercurial temperament to go with it? In how many businesses are customers "locked in" to a particular vendor because of product decisions someone made a decade or two ago that can't easily be reversed?

The software business also differs from conventional industries because it is not really one kind of business. Software becomes whatever function or application it addresses. This means that the range of possible products and services is almost infinite. Software can help you write a report, calculate your taxes, build a bridge, navigate an automobile, control the space shuttle, or dial your telephone. Not surprisingly, there are many categories and even layers of software products and customized programs that work with one another to form complete systems (such as networking software with operating systems, and operating systems with applications). The definitions of these categories and layers are relatively well accepted, though Microsoft and other companies have been blurring the traditional distinctions for many years.

These and other observations describe aspects of software technology, software companies, and the software business. They also describe some other high-tech markets, such as telecommunications and various types of businesses heavily dependent on information systems and digital content. But surely these observations describe an unusual type of business.

As I discuss in Chapters 2 and 3, get the strategy and the management side right, and the software business can be like having a license to print money. Just ask Bill Gates of Microsoft or Larry Ellison of Oracle, among many other software billionaires and multimillionaires around the world. But get the business model wrong, and -- to borrow a metaphor from Frederick Brooks's The Mythical Man-Month -- software companies can resemble dinosaurs futilely trying to escape the death grip of an ancient tar pit. The more you struggle -- that is, the more time, money, and people you pour into product development, sales, and marketing in the hope of a turnaround -- the deeper you sink and the quicker you die. In the software business, this is not only because the more people you add to a late software project, the later the project can become -- a rule of thumb now described as "Brooks's law" (and not always true). But the broader downward spiral can accelerate for a whole company and become self-fulfilling as present and potential customers flee from software producers unlikely to survive long enough to deliver, support, and upgrade their products.

In bad economic times, or when there is bad corporate news, we can see the sales of once high-flying software companies suddenly drop as if they had fallen off a cliff. Billion-dollar companies can shrink to half their peak size (e.g., i2 Technologies), declare bankruptcy almost overnight (e.g., Baan), or turn suddenly from modern-day gold mines into investment nightmares. SAP, Oracle, Siebel Systems, Business Objects, and many other blue-chip software companies lost 80 to 90 percent of their value at one time or another during 2000-2002, depending on when an investor bought the stock -- despite having solid products and businesses. Even Microsoft dropped about two thirds of its value during this period of boom and bust. We have seen this phenomenon of rapid growth and dramatic decline as well in the telecommunications equipment and services industries (e.g., Lucent and WorldCom), businesses that are also heavily based on software technology but even more distressed in terms of profits and sales.

Since software technology, software companies, their people, and their markets have unique challenges and opportunities, I believe that the business requires a unique approach to strategy and management. For example, software managers, programmers, and entrepreneurs need to encourage innovation wherever and whenever they can, but they have a special need to contain it as well; otherwise projects and plans can spin out of control. Perhaps most important, a large number of software companies -- those selling "enterprise software" to other companies and large organizations -- have to be nimble enough to tailor their products and their strategies to the needs of individual users and particular kinds of customers. Often they must survive the transition from selling high-margin products to selling low-margin services, especially in bad economic times and as their products and customer bases age.

This last idea -- that many software companies need to sell both products and services to maintain a successful business -- is a central theme throughout this book. I argue in Chapter 2 that there are basically three business models that fall along a spectrum: On one end are software products companies, which get all or most of their revenues from new product sales (called "software license fees"). On the opposite end are software services companies, which get a majority of their revenues from IT consulting, custom software development, integration work, technical support, systems maintenance, and related activities. In the middle are what I call hybrid solutions companies -- software firms that have some new product sales but derive as much as 80 percent of their revenues from services and "maintenance" (incremental product updates or special enhancements sold through long-term contracts to the purchasers of the initial software license).

I also argue that even companies trying to emphasize products eventually end up selling more services and incremental maintenance upgrades to their existing customer base than new products to new customers. They often fall unwittingly into the services or hybrid business models and are not prepared for the change. Bad economic times can accelerate this transition as customers postpone purchases of new software products. It also seems an almost inevitable transition for software companies that sell to corporate customers (enterprises): their revenues increasingly consist of sales of services and maintenance upgrades to existing customers, rather than new product sales to new customers. It can be devastating to a software company to find its new-software-product sales collapse, but it happens frequently. This is why managers, programmers, and entrepreneurs need to understand what the future usually holds for enterprise software companies, and how to manage and adapt to that future as effectively as possible. Accordingly, because of the potential for rapid change in the marketplace, software companies must combine extraordinary levels of structure with flexibility. Companies must pay constant attention to strategies and business models as well as continuously evolving their technical skills and core technologies. They must often experiment with new-product development while preventing projects from running years behind schedule or devolving into chaos.

Software as a Technology

How a software firm manages the technology to create and deliver products and services is usually central to its long-term success. Almost any firm can have a onetime hit product. But following this first product with multiple versions for different customer segments or with compelling updates and new services that meet future customer needs requires thought and careful management. But what does "managing the technology" mean in the context of a software producer? In this book, I treat the question in fairly straightforward terms, separating "the technology" from "technology management."

Technology Versus Management

Software technology is many things. I have already described it most directly as code -- programming instructions or algorithms, eventually translated into zeros and ones. But for practical reasons, we must also include system architectures, program designs, the data or digital content that computer programs need to do anything useful, user interfaces, application programming interfaces, programming support and testing tools, test cases, documentation, and other physical and nonphysical artifacts. Software technology also includes the effects of what programs do -- how one module of code interacts with other programs, modules, and computers, and what the whole system enables users to do.

Managing the technology in a software business primarily refers to overseeing the process of designing a software product or information system for a particular customer need and then building, testing, delivering, supporting, and enhancing that software product or system over its lifetime of use. Chapter 4 contains a lot of what I have learned about managing this chain of activities. In addition, though I do not talk much about managing the science, managing the technology should include facilitating communication between scientists pushing the state of the art and engineers building real-life applications.

From a business point of view, managing software technology well should imply knowing how to go through the phases from design to delivery at a cost that is less than the revenues generated from selling the resulting product or service. This may be common sense, but it is not always common practice. Here is where marketing and sales -- and financial discipline -- become as important as anything else in the software business. Managers, programmers, and entrepreneurs need to understand how to build or package technology and price it in a way that both makes people want to buy it and earns them a profit. Selling software and services at enormous losses (and I will discuss many examples of this, ranging from start-ups to established firms) is not a business. Many software companies waste millions and billions of dollars on development efforts, acquisitions, or marketing campaigns that generate no profitable results.

As a researcher and consultant, I have found that managing the technology well becomes a serious problem at one time or another in the lifetime of nearly all software businesses, including dedicated software companies and firms that do a lot of software development for in-house use. As I discuss in Chapter 3, IBM went through the pain of building OS/360 in the 1960s and eventually created a structured process that worked, despite a great deal of variation within the company and without much concern for flexibility or innovation. The Software Engineering Institute (SEI) at Carnegie Mellon University, to a large degree, has disseminated the best practices of IBM for large-scale systems development. The Japanese also attempted to solve problems in large-scale systems development by incorporating many practices similar to IBM's approach into their software factories of the 1970s and 1980s. Microsoft struggled mightily in the 1980s and came up with more flexible but still structured "synch-and-stabilize" techniques that worked well during the 1990s and early 2000s. Another giant, Oracle, in the early 2000s was still figuring out how to build high-quality applications the first time around. And these firms are all success stories! There are many other examples of start-ups and established firms wasting years and millions of dollars on software development, with little or nothing to show for it.

I also know of many cases (such as some of the start-ups described in Chapter 6) where the software engineers knew very well what they were doing but still failed anyway. They were able to create a prototype or small-scale system without spending too much time or money. But then problems almost always set in as these firms tried to build a commercial-grade product with more sophisticated features, or as they took on hybrid-solutions projects that rose quickly in complexity and then overwhelmed their management skills or financial resources. And even where managing development of the technology was not a major problem, understanding how to market and sell the technology they were creating was a major factor in their struggles or demise. As Chris Peters of Microsoft once said, it is just as important in software development to decide what you are not going to do as it is to decide what you are going to do.

Because software can perform an almost infinite number of functions, the challenges of managing the technology well continue to be enormous, especially for inexperienced start-ups or established firms where software development is not the primary business. Managers, programmers, and entrepreneurs have to accommodate different kinds of projects and customer requirements, as well as anticipate changes in the technology and market needs. What do you have to think about if you are working on software for the space shuttle? It is very different from what you must think about if you are working on a video game. What software producers must do well may be the same at a high conceptual level -- they need to design, build, test, deliver, support, and maintain a product or a custom-built system. But the demands vary considerably depending on how customers will deploy the software technology in their particular applications or markets. In short, the requirements of managing software as a technology vary with the requirements of managing software as a business.

My Involvement with the Software Business

This book is very much a personal view of the software business, seen through the lens of nearly two decades of research on the industry, professional involvement with dozens of software companies and organizations, and teaching a class titled "The Software Business" at MIT since 1997. I am not a programmer, but I have been fascinated by computers since first using an IBM mainframe in college during the mid-1970s. But my first recognition that software was a special business with special problems in strategy and management came in 1985. That is when I started studying how Japanese companies built large-scale industrial software systems and were trying to add sophisticated software skills to their already formidable hardware skills. Since the late 1970s, I had been studying Japanese production and quality management techniques, particularly in automobile design and manufacturing. But I had tired of looking at this one industry and thought that the next great challenge for Japan after automobiles would be computer software.

I began the new research by reading about the history of the computer industry in Japan as well as some articles on Japanese software engineering practices. One fact immediately got my attention. Since 1969, the major Japanese computer manufacturers had been concentrating their people with software expertise in relatively large facilities and had been trying to apply the same disciplined approach to software production and quality management as they had done in "hard" manufacturing businesses. I then began to write case studies and conduct surveys of software projects and development practices at Hitachi, Toshiba, NEC, Fujitsu, NTT, and several other Japanese firms. I also studied IBM, DEC, System Development Corporation, and Andersen Consulting, among other U.S. firms, for comparisons. I learned a great deal about process and organization in mostly custom or semicustom software development for mainframe computers. But I ended up wondering why process excellence and "zero defects" did not necessarily make a company successful in software as a business.

I remember giving a press conference for the American Electronics Association's Tokyo chapter in February 1991 to announce the results of my research on Japanese software. I began with the statement that the "$60-billion-dollar question" people had been debating for years was whether or not the Japanese could write software. I said that I finally had an answer, though I divided this into "good news" and "bad news" from the point of view of American firms.

The bad news was that the Japanese could write software. In fact, they wrote a lot of software, and they wrote it as well as or better than U.S. firms in terms of reliability (few "bugs" or defects) and crude measures of productivity (code output per programmer, including large amounts of reused and semiautomatically generated code). The "factory-like" approach that the Japanese computer manufacturers used for software development also differed from the approaches common in the United States. The Japanese emphasized incremental innovation in feature design, standardized development techniques, common training programs, reusable component libraries, computer-aided support tools, rigorous quality assurance techniques, and statistical data to manage projects. The Japanese also tended to staff projects with a combination of experienced people and relatively low-skilled programmers who had merely a few months of training.

But there was also good news, again, from the perspective of U.S. firms: the Japanese approach seemed well suited for building certain kinds of software systems but not others. Moreover, Japanese companies didn't seem to know much about how to make money from software or compete outside Japan, except for software embedded in products such as programmable machine tools, VCRs, and microwave ovens. The Japanese were focused mainly on labor-intensive custom or semicustom information systems built to sell mainframe computers and targeted to Japanese customers. They had limited innovation capabilities and ambitions, although Fujitsu, NEC, and Hitachi routinely beat U.S. competitors in the Japanese market because of their quality, service, and reliability. The Japanese economy would continue to modernize through the introduction of more computers and new PC-based or workstation-based information systems. But there was no dominant global software player likely to come from Japan, except perhaps in niches such as the video game industry. (This was an area of software that the Japanese excelled in, perhaps because of their fascination with comic books from childhood through adulthood.)

After studying Japanese software factories, I decided to "follow the money," so to speak. I decided to look at the company that made the most money and seemed to care the least about the process of product development: Microsoft. As it turned out, I soon learned that Microsoft managers and programmers did care a lot about process. But compared to the approaches followed by traditional U.S., Japanese, and European software organizations, they cared in a way that was much better suited to the fast-paced and somewhat unpredictable world of PC software and, later, the Internet. Microsoft people also cared more about strategy and money than they did about following textbook processes. They were interested in dominating markets -- albeit too interested at times, so much so that the company ran afoul of antitrust laws. My new interest in Microsoft turned into another book published in 1995 with Richard Selby. In subsequent research, I continued to follow the evolution of Microsoft through the Internet age and competition with Netscape as well as into the world of .NET and Web services.

My research also created opportunities to work with approximately fifty software producers in Europe and Asia as well as the United States, beginning in 1987. These organizations include software products and services companies; computer hardware and semiconductor companies with large software businesses; financial services companies heavily dependent on software technology; and telecommunications equipment and services companies. I am also fortunate to have served on approximately a dozen boards of directors and advisers for software companies and venture capital firms in New England, Silicon Valley, and London. What I have written in this book, consequently, is colored not only by my experiences with the Japanese and Microsoft, but also from studying and working with a wide variety of software producers around the world.

Some International Generalizations

My international experiences (including residing in Japan for about seven years) have often led me to compare people and organizations in different parts of the world. Here I would like to offer some generalizations about how the software business might differ in three regions I know reasonably well: Europe, Japan, and the United States. Like all generalizations, there are exceptions. I also think these generalizations were more applicable a decade or two ago than they are today. But I believe that they still contain more than a grain of truth. They also reflect a key motivation for me to write this book: the conviction that software is too important to be treated simply as a technology, or as part of the field of computer science. Software has the power to change the world, especially when treated as a business by managers, programmers, and entrepreneurs who also want to change the world.

The Europeans

The Europeans, along with the Americans, pioneered a lot of the inventions in computer design. But too many European companies I have encountered tend to treat software as a science. The reason is not hard to understand. The Europeans have excellent university-level education in computer science, especially programming languages and principles of design. And so, from Europe, we get things such as formal methods (a way of specifying requirements for software systems in mathematical terms that can be verified and validated mathematically) and object-oriented analysis and design (a clever way of breaking up software programming instructions and data into small, reusable objects, based on certain abstraction principles and design hierarchies).

We also get from Europe enormously rich but complex applications remarkable in their detail and structure, like those the German company SAP has produced. In addition, we can find elegant but simple applications that enable nonprogrammers to query databases and generate useful reports, such as those the French company Business Objects created a decade ago around object-oriented technology. Europe has also produced stunning innovations such as the World Wide Web, invented by Tim Berners-Lee, an Englishman, while he was working at the CERN physics research lab in Switzerland. But I have often found that many European software producers place more attention on achieving elegance in software design than on shipping products for mass markets and making the most money they can from their excellent technical skills.

The Japanese

The Japanese, for much of their history, have followed IBM and a few other American companies in designing and building mainframe computer systems. Japan's computer manufacturers and software firms have shown significant skill in writing programs for all sorts of applications, ranging from real-time banking systems, to fault-free bullet train control and reservation systems, to video game software. But most of these systems are custom-built for specific customers in Japan and contain relatively few innovative features, by design. The largest Japanese producers of software mainly write code to sell hardware and services, as IBM has done for decades. The country has also underinvested in basic research and higher education. Not surprisingly, Japan has had relatively weak university training in computers and information systems. Japan has also lacked the broad diffusion of computers, knowledge of English typing, and programming expertise among young people that has led to a strong "hacker" tradition in the United States and, to a lesser extent, in Europe.

Accordingly, the major Japanese producers of software -- Fujitsu, Hitachi, NEC, Toshiba, and NTT -- have had to train most of their own people on the job and have ended up treating software development mainly as a problem in production. With some exceptions, such as game software and some more creative consumer electronics applications, the big Japanese companies I know well have tackled large-scale systems development with heuristics (engineering rules of thumb), process discipline, some capital (e.g., computer-aided tools), and manpower. Hence, we have software factories. The factories were and remain good at cranking out multiple versions of custom or semicustom applications that follow standardized design patterns and evolve little from their original parameters. Software built in this way is useful in selling hardware and performing basic tasks or making construction of third and fourth versions of similar custom systems a bit easier and cheaper. But it doesn't change the world or make anybody a billionaire.

The Americansar

And then we have the Americans. People in the United States are unmatched in treating software as a business. That is, they see software technology as a vehicle for creating dedicated software companies that produce at least "good-enough" products and try to set industry standards as well as make lots of money in the process. And so, in the United States, we have companies like Microsoft and Netscape, both of which tried to and succeeded in changing the world. Bill Gates, who cofounded Microsoft with Paul Allen in 1975, wanted to see a personal computer on every desktop and was determined that those PCs run Microsoft software. Today more than 90 percent do. Gates also had the great insight in 1975 to conclude that the future value of computing would be in software, not hardware. Marc Andreessen, who cofounded Netscape with Jim Clark in 1994, felt that an easy-to-use browser that ran on Windows as well as other software platforms would make usage of the Internet ubiquitous, for both individuals and organizations. It now is. Microsoft and Netscape went on to introduce products that were no more than "good enough" from a technical point of view: MS-DOS, Windows, and Netscape Navigator.

Of course, software programming can still be science for Americans. Like the Europeans, we have great universities and computer scientists. It most certainly can resemble disciplined engineering practice, especially in the U.S. defense industry and mainframe software worlds, but also in the commercial operations of companies such as IBM, Sun Microsystems, Hewlett-Packard, and, yes, even Microsoft, when it comes to building products such as Windows NT/2000. But many American companies, and the occasional European company that operates like an American company, at least in marketing (witness Business Objects and SAP), have found ways of generating oodles of revenues and profits, and tremendous excitement for their employees and investors, by treating software as a business. This book is about how to do that, whichever country you are from and whichever part of the software industry you are in.

Basics of the Business: Two Case Studies

There are many issues of strategy and technology management that managers, programmers, and entrepreneurs in the software business need to understand in order to have successful companies in both good times and bad. To illustrate some of the key issues here, I introduce the stories of two companies I have worked for over the past several years: Business Objects and i2 Technologies. Both are public software companies. Business Objects (NASDAQ stock symbol: BOBJ) is based in Paris with a second headquarters in Silicon Valley, and i2 (stock symbol: ITWO) has its headquarters in Dallas and much of its development organization in India.

Business Objects is a clear-cut success story of a business intelligence company selling horizontal software to enterprises and institutions. From the beginning, it demonstrated a very focused strategy as a complement to Oracle and then other database products. It has benefited from superb leadership by the founder, disciplined operations, clever product development, and fast and profitable but not un-wieldy growth. The company passed $450 million in revenues in 2002.

i2 Technologies, on the other hand, had a meteoric rise in the market for factory planning and supply chain management software. It went from $2 million in sales in 1992 to almost $900 million in 2001, but also lost nearly $8 billion that year, although most of these losses were write-offs of devalued acquisitions. Though it has made dramatic improvements in the past few months, i2 remains an example of a company that grew too fast during the height of the Internet bubble. The company nearly lost its focus and ability to serve customers. It has a founder and new senior management team with great determination to change, however, and that may be enough to turn the company around.

Business Objects

I was sitting in my office at MIT one day in April 1996. The phone rang, and it was Bernard Liautaud, the CEO and cofounder of Business Objects. He had read Microsoft Secrets and asked me if I could help him make his rapidly growing company work as well as Microsoft. I agreed to try. This led to a weeklong visit in May, a series of reports and recommendations over the next five years, and laudable efforts by Liautaud and many other people in the company to make Business Objects into what became one of the fastest-growing and most consistently profitable software companies in the world. In 2002, the company was the market leader in revenues for business intelligence software, a segment that the International Data Corporation estimated to be about $8 billion in 2001 and expected to double in size by 2005.

Liautaud and a partner, Denis Payre, had founded Business Objects in August 1990. Both men were French nationals who had worked at Oracle France in sales or marketing. The original idea for the company's main product came from another Frenchman, Jean-Michel Cambot, an independent engineer and consultant who worked with Oracle database products. Cambot had approached Liautaud in the late 1980s with a concept for a new decision-support tool based on the latest object-oriented design technology -- software as science leading to a commercial innovation. His product (actually, a short program or set of computer instructions) made it possible to generate SQL (Structured Query Language) statements from a simple user interface, without the user having to know SQL or any other database programming language. Cambot wanted Oracle to make his prototype into a product and distribute it for him. Oracle management declined, even though the response from a sample of Oracle customers to the product idea was very positive. Liautaud and Payre decided to create a company around the product. They secured some funding and bought the software from Cambot in exchange for royalties. After three years of successful sales, Business Objects went public in 1996.

In an interview for this book, Liautaud recalled that, from the beginning, Business Objects went after a big "horizontal niche" rather than a "vertical" market. It attempted to "cross the chasm" separating early adopters from mainstream users by riding on the backs of Oracle customers (more on horizontal versus vertical niches as well as chasm crossing and its alternatives in Chapter 2). Liautaud noted that the company was not trying to create a new platform to work with all database technologies, but rather was positioning itself as a "complement" to Oracle:

We viewed our market as Oracle customers, period. We said we were not going to go after Sybase, Informix, or Microsoft customers. We were going to stay pure Oracle at the beginning. And the main reason was that by doing this we would be able to work with the salespeople at Oracle. We would not be a danger to the Oracle sales force...We were a complement. It would improve their product. They didn't have anything comparable. It would make them win deals more. And, by the way, the very first deal we won with an Oracle France sales guy was a deal where he had lost against Sybase. We came back, and we managed to get a last-minute meeting with the decision maker in the company. We showed our product on top of Oracle, and the guy said, "I'm switching my database, because if that product doesn't work on Sybase, then I want Oracle because that's exactly what I want. I want that product and I will pick the database that works with that product." I can tell you we advertised that to all the Oracle France sales force, and they went crazy....Our crossing the chasm was not a vertical strategy, like going retail. Our strategy was Oracle customers....It was a big niche.

The innovative technology alone was sufficient for leading-edge customers. The product was also attractive because it worked on DOS computers (the most popular business PCs at the time) with an extremely small memory requirement, about three hundred kilo-bytes. Windows was not yet available widely. As for pricing, the company ended up going with a high-end strategy -- $15,000 for eight users as the minimum contract. It used as a pricing benchmark what Oracle was charging for its own query tools. Two years later, in 1992, Liautaud and Payre decided to extend the product to work on other databases.

The two entrepreneurs grew the business from nothing in 1990 to more than $60 million in revenues by 1995, with impressive profits -- surpassing $10 million in 1995 alone. (For financial data on Business Objects, see Appendix Tables 1 and 2.) This is the beauty of software product sales, usually called "software license fees." Software is a digital good, so making one copy or a million copies costs about the same. There is, as a result, tremendous potential in the software products business for economies of scale and rapid, profitable growth. Product sales accounted for more than 80 percent of the company's revenues during 1993-1995, with minimal costs compared to services such as product customization, maintenance, and technical support. In recognition of their performance, Business Week named Liautaud and Payre among the "best entrepreneurs of the year" for 1995.

Business Objects did not do it all alone. The company reached an agreement in 1994 for IBM to resell its core product bundled with IBM's data-warehousing package as well as some industry-targeted vertical solutions. IBM quickly became the company's biggest reseller, a position it still had in 2002. Most of the company's revenues have been through direct sales channels, rather than resellers, although Liautaud commented on the benefits of the ties with IBM: "The [IBM] sales were not huge. It was probably five percent of our revenue per year, not much more. But it gave us the credibility. The marketing leverage was very important. It still is."

The company also had to overcome the usual problems of a rapidly growing start-up. For example, Business Objects' 1997 Form 10-K report to the U.S. Securities and Exchange Commission, with surprising candidness, detailed the difficult state of product development during the spring of 1996. The comedown from the banner year of 1995 was dramatic. The new 4.0 release was a year late -- it had planned to ship the update in June 1995. Moreover, the company admitted that the product code was still riddled with bugs. When I first visited the company, I learned that engineers and managers severely doubted they would ever get the defect level low enough to ship the new version of the core product. In the meantime, sales were dropping as customers waited for the new release. The problem was not easy to solve. Business Objects had redesigned the core product to run on Microsoft's new 32-bit operating system, Windows 95. But this new version (BusinessObjects 4.0) did not run well on the older 16-bit Windows, version 3.1, which was still the most common PC operating system used in corporate settings. Most customers had switched from DOS but had not yet upgraded to Windows 95 or Windows NT (which was also a 32-bit operating system with interfaces similar to those of Windows 95). Managing software design and development better and dealing with platform issues were only some of the hurdles facing the young company, though they were central to survival.

Business Objects did tail off in growth during 1997 ("only" 34 percent over the prior year) due to the delay of the new release, before returning to a more familiar pace (46 percent) in 1998. The company then grew about 45 percent annually, even as license fees (new product sales) declined as a percentage of revenues to about 60 percent in 2001. The company was not immune to the bad times that hit the entire software industry after the bursting of the Internet bubble. Nonetheless, in 2002, Business Objects topped $454 million in sales with operating profits of more than $47 million -- excellent numbers in a bad year for most software companies. As of mid-2003, it had millions of users at more than 17,000 customer sites in eighty countries. More than half the company's sales were from North America, Business Objects' fastest-growing market, and about 40 percent from Europe.

Liautaud has presided over the growth of the company alone since 1996. Payre, who initially had taken the title of president and headed sales, left the company at the end of 1996 to become a venture capitalist in Brussels. It is also significant that Liautaud moved to the United States in July 1997 to give more priority to the U.S. operations. Increasing sales in the biggest software market was critical to making Business Objects a worldwide brand. In recognition of the company's success as well as his leadership, many awards have continued to come to Liautaud personally and to his firm. Of particular note, in 2002 Business Week called Liautaud "France's most successful software entrepreneur" and Time magazine listed him as one of the twenty-five most influential business leaders in Europe.

Business Objects had a clear strategy in the mid-1990s, but the company faced many hurdles in building more capabilities into the product, making the technology rock-solid for the mainstream enterprise market, and upgrading internal processes for software design, development, and testing. At the same time, the young French company had to figure out how to manage highly talented but temperamental French computer scientists, and transform a start-up French organization into a global corporation that could operate equally well in the United States and Europe. It was apparent in the first e-mail Liautaud sent me in 1996 how well prepared he was to tackle hard problems -- the software development process, organization structure, task and project management, viability of the executive team, recruiting, employee morale -- before the company and its challenges got any bigger:

Subject: Re: Consulting

Date: Tue, 16 Apr 96 10:06:30 WET

From: "Bernard LIAUTAUD"

To: "Michael Cusumano"

Yes, I am confirming. I would like to agree on the process and the deliverables for that week.

The way I see it is the following:

1. Short audit of our current software development process

2. Build a set of recommendations, with an emphasis on

• organization (product teams, roles and responsibilities of managers,...)
  
• reporting methodology and tools (to follow up progress of tasks and projects at the different levels of the org)
  
• specific assessment of the potential of one or two current managers to fulfill senior positions in future organization
  

3. Discuss and refine the recommendations at two levels, first with me and one other manager, then to a larger group.

4. Plan future action items and progress review checkpoints.


...

In general, my goal for this quarter is to rebuild the software development process, get a clear picture of what the organization should be, start recruiting high level position (SVP Products?) if there is a need for it, and boost morale of the organization. I would also like to get recommendations from you on recruiting.

...

Thanks in advance

Bernard

I will have more to say on Business Objects in the next chapter, when I compare the strategies and financial statements of several software companies. Some of the material I present later on software design and development also draws on my experience in working with Business Objects, as well as with Microsoft, Netscape, the Japanese software factories, and many other companies. But let's now look at an even more striking case of a software business, with higher highs and lower lows.

i2 Technologies

Sanjiv Sidhu and Ken Sharma founded i2 Technologies in 1988. The firm quickly became known worldwide for leading-edge software products that analyzed and solved problems in factory planning, logistics, and supply-chain management. Sidhu had been working in the artificial intelligence lab at Texas Instruments when he came up the idea of creating a planning and optimization tool that incorporated realistic constraints by relying on a selected, limited number of variables. Sidhu was joined by Sharma, and the two entrepreneurs created their first product in a two-bedroom Dallas apartment. Similar to Business Objects, they positioned i2's product not as a stand-alone

offering but primarily as "a complement...to existing MRP [materials requirements planning] and ERP [enterprise resource planning] solutions" used by large manufacturing companies.

Sidhu and Sharma started selling a few software licenses and providing a lot of consulting -- services accounted for 89 percent of revenues in 1992. (For financial data on i2 Technologies, see Appendix Tables 3 and 4.) But by 1994, i2 had grown to more than $11 million in revenues by becoming much more of a products company; software licenses accounted for 75 percent of sales in that year. i2 was growing extremely rapidly, averaging about 160 percent a year over a five-year period (1993-1997). But it was still a small company.

Then the market explosion happened. The Internet suddenly provided a means to link suppliers to producers over easy Web connections, making supply-chain analysis and optimization tools even hotter items for manufacturing and retail companies. Dot coms started to buy billions of dollars worth of software and hardware to create online marketplaces for purchasing and selling components for all sorts of industries. Because the year 2000 was also approaching, companies allocated additional "Y2K" budgets to buy new software to streamline planning and procurement or improve management of factories and suppliers.

i2's growth rates slowed as the company became bigger. But in this new market environment it continued to grow very fast, mostly through internal growth but also through acquisitions. To fill in gaps, the company bought a variety of firms that helped it meet all the

supply-chain needs of high-tech and other manufacturing firms. The long-term goal of management was to combine i2's factory planning and analytical software with new transaction software that would serve as a platform for linking thousands of buyers and suppliers in an enormous value chain. Initially reported revenues topped $1.1 billion in 2000 (later restated as $672 million) as the company became one of Wall Street's new high-tech darlings. Sidhu became a billionaire many times over.

And then the bubble burst. i2's stock price had gone from $20 in 1996, when the company first went public, to $111 in 2000, and then to 41 cents in October 2002. The company also failed to submit its 2002 10-K report on time and was delisted from the NASDAQ market and investigated by the Securities and Exchange Commission (SEC). Writing off the value of acquisitions that never lived up to their promises caused i2 to lose nearly $8 billion in 2001, which included some hefty operating losses (about $278 million). Apart from Ken Sharma, who had died in 1999, much of the management team (below a few senior executives) when the company had a billion-plus dollars in revenues remained the same as when it had been a start-up.

I first visited the company as a consultant in April 2001, on the recommendation of a former MIT student of mine, Charles DeWitt. He was working at i2 in strategy and was trying to get the company back on track. We discussed my experiences at various companies, including Business Objects. I recall thinking at the time how different i2 was from the French company. Business Objects had grown quickly, too, but at nowhere near the pace that i2 had experienced. Liautaud had had much more time to think about and anticipate critical issues before the company and its problems became too large.

By contrast, Sidhu and key executives such as Greg Brady, a former sales executive at Oracle who rose to the CEO post during 2001-2002, focused on riding the Internet and Y2K boom in technology spending. They grew i2 at a torrid pace by selling bundles of software licenses almost as fast as they could write contracts. In sales, truly, the i2 team did a remarkable job. But companies facing once-in-a-century opportunities like the Internet and Y2K rarely have the time to confront the basic organizational, process, personnel, and product problems that inevitably emerge as a company passes beyond the start-up stage. Not surprisingly, by the year 2000, i2 had run into problems as enormous as its near billion-dollar revenues, and it took some strong action by Sidhu and other people to bring the sales process and software development operations back under control.

In retrospect and as reflected in a restatement of 1998-2000 revenues in the 2002 annual report, the numbers show that i2 never really had a billion-dollar business. Like other companies that rode the Internet wave, its revenues reflected aggressive sales made possible by the short-lived bubble economy. Moreover, at its peak, the company's revenues quickly became far from profitable. In 2001, according to the restated financial information, it cost i2 about $1.32 for every dollar in revenues, excluding the cost of amortization and writing off the value of acquisitions, canceled software projects, and restructuring charges. Including all operating charges and expenses, in 2001 it cost i2 $9 for every dollar of sales. In 2001-2002 the company also sold more servicelike items (maintenance, including special product enhancements and upgrades, as well as customized contract software, consulting for system implementation, and technical support) than new-product licenses. In fact, the major change in i2's restated financial results was to reclassify about $950 million in software license fees as "contract revenues" between 1999 and 2002. This new category reflects that the delivered software requires the company "to perform services that are essential to the functionality of our product."

Most of i2's products, like those of competitors such as SAP and Oracle, were actually complex hybrid solutions that required time and expertise to install, tailor, and integrate into customers' information systems. The software was very difficult to sell in high volumes "off-the-shelf," unlike Microsoft Office or even Business Objects' products, without extensive customization and support. i2 consultants, who took charge of implementing systems, often underestimated just how difficult it would be to get systems up and running at customer sites, and i2 often had to bear the extra costs itself. On the other hand, customers that successfully installed the software to run their manufacturing and supply-chain operations, such as Dell Computer, claimed to realize major cost savings and large returns on investment.

It will be interesting to see which of these two companies ends up with the larger revenues over the next few years. Business Objects was continuing to grow consistently and generate steady profits, even in the bad times of 2001-2002. i2 Technologies, by contrast, had its last net profit in 1998, and software license fees were declining rapidly. In 2002-2003, i2's management was working hard to simplify product offerings, reduce head count, and return to profitability. As chief financial officer Bill Beecher noted in a November 2002 interview with The Wall Street Journal, "i2 grew up being a profitable company. This has just been going on too long. You need ultimately to get your business to run on a positive margin."

i2 had one advantage over U.S. competitors in that a large part of its technical organization was located in India, where costs are much lower. Sidhu, who reclaimed the CEO position in June 2002 after relinquishing it to Brady for a year, was leading the effort to restructure the company. Even in the 2001 annual report (prior to the restated results), he felt it necessary to offer this sobering message:

2001 was the most challenging year in the history of i2. Economic, geopolitical and market events combined to rapidly change not only the general climate of growth, but also to reverse i2's momentum. For the first time in our history, revenues fell and profits turned to losses. After growing by 97 percent in 2000, total revenues fell 12 percent in 2001 to $986 million, and in the second quarter, i2 reported its first quarterly pro forma loss. It would be easy to lay the blame for a disappointing year solely on outside forces, but we also feel our performance should have been better, and we accept that responsibility. Yet in every challenge lies an opportunity. We are seizing this opportunity to strengthen i2 and create a more operationally efficient and effective company. We are leveraging our industry-leading solutions, exceptionally talented and committed people, and a strong customer base to position i2 for a return to profitability and growth. As customers slowed spending, we reduced our quarterly cost structure by more than $100 million from the first to the fourth quarters. We reorganized our operations, reduced our workforce, refocused sales forces, consolidated offices, reduced discretionary expenditures and began transitioning more research and development to India, where we have a 3:1 cost advantage over development in the U.S.

I will say a bit more about i2 in the next chapter, as well as relate other company stories that I find useful to understand basic issues of strategy and management. But the cases of i2 and Business Objects should be enough to suggest that there are many complex strategic, technical, and organizational challenges that managers, programmers, and entrepreneurs in the software business need to confront. Software companies must have a strategy and specific organizational capabilities to support that strategy and carry them through both good times and bad times. When times are good, it is easy for software products companies to grow revenues -- perhaps to a billion dollars or more within a few short years. But when times are bad, revenues can collapse like a stone falling to earth because customers can simply stop buying new products. The companies most likely to survive the down times are those with a solid base of loyal, satisfied customers who pay "recurring" fees over long-term contracts for product updates, bug fixes, customization, and other services. I must add that these service and maintenance fees are also directly tied to new-product sales in most cases and also will drop soon enough if product sales do not recover or if companies do not replace these revenues with service offerings.

How to think more strategically about products and services, as well as customers, business models, and other issues essential to creating and managing a software business, is the subject of the next chapter.

Copyright © 2004 by Michael A. Cusumano