The business of software cusumano download

Includes bibliographical notes p. There are no reviews yet. Be the first one to write a review. Books for People with Print Disabilities. Internet Archive Books. We have seen this phenomenon of rapid growth and dramatic decline as well in the telecommunications equipment and services industries e. 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. 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.

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 s and s.

Microsoft struggled mightily in the s and came up with more flexible but still structured "synch-and-stabilize" techniques that worked well during the s and early s. Another giant, Oracle, in the early s 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 I am not a programmer, but I have been fascinated by computers since first using an IBM mainframe in college during the mids.

But my first recognition that software was a special business with special problems in strategy and management came in 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 s, 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 , 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 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 to announce the results of my research on Japanese 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. 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. 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. 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. 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 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. Challenging the disruptive technologies and forming a tech-savvy generation is the ultimate goal.

Anyway, the software industry is approached differently based on the culture, and the resources available.

The U. Service-rendering software companies are focusing on outsourcing, integration, training and so forth, while the product-based organizations are trying to create a comprehensive output. Unlike other industries, the prosperous software market allows companies to absorb substantial profit margins, thanks to low costs when it comes to distribution and sales.

However, he tries hard to demonstrate why a prosperous and well-organized software company can be a gold mine in the digital era by using a vocabulary that can be understood by a high school kid. Furthermore, the Business of Software clarifies the best methods in the software development industry coherently and transparently. Cusumano offers plenty of real-life examples and case stories also that add a little more fire to it.

Entrepreneurial adventures are an indispensable element of an this all around software book, professionals and investors would find them as the most intriguing and engaging sections of the entire work.

The digital age is compiled out of hardware and software services so is no wonder that futurologists, experts, and investors are currently advising people to invest their capital in those two industries.

You probably have heard this saying: In Japan, everything requires time, and everything is a process, while in the U. At the very end, it all comes down to choosing the right software products and services for your needs. Research in software business: implications of the special qualities of software as a good.

In a number of ways, software is a special economic good. It has some familiar characteristics of both information and physical goods, and the characteristics come in combinations that are unique to … Expand. Business value of software reuse in the digital enterprise : an industry perspective. Many companies are accelerating investments in digital technologies to streamline internal operations and create new business models. To achieve these goals, digital enterprises are adopting … Expand.

View 2 excerpts, cites background. Customer perceived value in software business relationships Competitive paper for IMP Conference. This paper addresses perceived customer value in the context of software business.

Customer perception of value is a complex phenomenon not only theoretically, but even so in practice.