The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad - Rilegato

Cusumano, Michael A.

Rilegato

ISBN 10: 074321580X ISBN 13: 9780743215800

Casa editrice: Free Pr, 2004

Riassunto

The co-author of Microsoft Secrets links issues related to strategy and organization to those of managing technology, arguing that companies must chose a business model that will capitalize on good times and survive more difficult periods, and presenting the success stories of such companies as IBM, Toshiba, and Motorola. 25,000 first printing.

Su questo libro

L'autore:

Michael A. Cusumano is the Sloan Management Review Distinguished Professor at the MIT Sloan School of Management and one of the world's leading authorities on software development and the management of software companies. He is the author or coauthor of seven other books, including the bestsellers Microsoft Secrets and Competing on Internet Time, as well as Japan's Software Factories and most recentlyPlatform Leadership.

Estratto. © Riproduzione autorizzata. Diritti riservati.:

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 soft...

Su questa edizione

• Editore: Free Pr
• Data di pubblicazione: 2004
• ISBN 10: 074321580X
• ISBN 13: 9780743215800
• Rilegatura: Copertina rigida
• Numero di pagine: 368