This chapter is from the book
This chapter is from the book
This chapter is from the book
Maintain Control of Product Uniqueness
IBM forgot a key business tenet: identify and protect that kernel that makes your products and services unique. Why did people want a PC? They did not want simply to have a pretty box. They wanted to do something, often something that no one had imagined. The power of computers is their flexibility, and the PC put this flexibility in the hands of the public. This flexibility was due entirely to the software.
When IBM realized that ceding control over the PC software to Microsoft was a mistake, it sank many millions into developing the OS/2 software system. OS/2 was an excellent system, but it was too late. Microsoft was too far ahead and the PC software business was moving too fast. IBM could not catch up.
IBM did not realize that the uniqueness of the PC product was in what it could do, and what it could do was almost entirely determined by the software. IBM got no software revenue from the PCs it sold, and the hardware soon became a low-profit commodity. The real tragedy is that IBM is no longer even a major force in the PC hardware business. That is now a commodity business, and whoever controls the PC software controls the PC business. Today, that is Microsoft, not IBM.
The Lesson of Principle Number One
With modern sophisticated products, the unique functions are increasingly embodied in the software, and a product's uniqueness is what makes it profitable. Therefore, if you do not recognize that you are in the software business and do not own the software in your products and services, you will lose control of your product's uniqueness. Then you will likely lose control of business revenue and profit.
Quality Is More Important Than Schedule
Ashton Tate did not appreciate software management principle number two: that software quality must be the top priority. Their experiences illustrate the dangers of this mistake. The Ashton Tate business started in 1980 with the introduction of the Dbase database management program. This program was soon the market leader, and Ashton Tate was one of the software industry's big three. In 1987, Ashton Tate had sales of $215 million, only slightly behind Lotus at $283 million and Microsoft at $260 million. The Dbase product accounted for 65% of Ashton Tate's business.
When competitors started offering faster and easier-to-use database products, Ashton Tate developed an enhanced version called Dbase IV. In February 1988, it announced that Dbase IV would ship in May. In May, it announced a delay of two months, and in August it announced another two-month delay. In late September, Ashton Tate announced that the new Dbase product would ship by the end of October, when it was finally sent off to customers.
Unfortunately, Dbase IV had so many defects that, after it had been used for a few months, Ashton Tate had to withdraw it. In September 1989, when I met with Ashton Tate's CEO, the engineers were still testing and fixing Dbase IV. When the CEO asked for suggestions, I asked if he had any data on the product's quality problems. My suggestion was to look at these defect data and identify the most troublesome of the system's modules, or parts. Then they could focus on repairing the most defective modules. Since software defects typically cluster in a small percentage of the modules, Aston Tate's engineers could clean up most of the problems in about four months. However, because the CEO was committed to ship Dbase IV in two months, he did not follow my advice.
The Ashton Tate engineers continued testing Dbase IV, and they kept finding and fixing more defects. They did not ship in two months, and they were still testing and fixing problems a year later. By February 1991, Dbase IV was still in beta test and the CEO was replaced. Because of its quality problems, Ashton Tate reported a $5.6 million quarterly loss. It was soon bought by Borland. Ashton Tate, once the third largest company in the software industry, no longer exists.
The root cause of this problem was poor quality management. Ashton Tate had announced its Dbase IV product in February 1988 for delivery in May. The schedule kept slipping until finally, in October 1988, management said, "Ship it; we'll fix it later." This converted a schedule problem into a quality disaster. Instead of being late and inconveniencing their customers, they were now betting the company. Sadly, they lost the bet.
The Lesson of Principle Number Two
Ashton Tate's engineers and managers viewed software quality as a testing problem. As described later in this book, there are better ways to manage quality. However, these better ways all start with you. If you do not insist on quality from the very beginning, people will rush through their work, expecting somebody else to fix it later. Testing is enormously expensive, often taking half of the software development schedule. By using proven quality methods, these costs can be cut by ten or more times and schedules accelerated by many months or even years. Teradyne, in just two years, saved $5.3 million. That is why quality is important, and that is why you must make it the top priority. Everybody else can defer quality problems, but you must live with the consequences. Quality is an economic choice: pay a little now or a fortune later.
Another important lesson from the Ashton Tate experience concerns time-to-market. Most businesses quickly learn the importance of getting a product into the market at the right time. However, many make the assumption that time-to-market and quality are mutually exclusive. If you must get to market quickly, they reason, you will have to skimp on quality and ram products out fast as you can. As the Ashton Tate experience shows, this quick-and-dirty strategy is often slow and very expensive. To truly accelerate development work and optimize time-to-market, your people must do their jobs the right way the very first time. This reduces testing time and minimizes rework. Accomplishing this requires a corporate commitment to quality.