Communications of the ACM

Technology strategy and management

Company Character and the Software Business

By Michael Cusumano
Communications of the ACM, October 2003, Vol. 46 No. 10, Pages 21-23
10.1145/944217.944231
Comments

Microsoft's continuing battles with antitrust authorities in the U.S., Europe, and elsewhere, as well as the myriad stories of problems of inflated or restated revenues from software companies (Baan, Peregrine Systems, Computer Associates, i2 Technologies), suggest a topic every manager in every software company should think about: company character. Do you want to be known as a firm that goes after sales, profits, or market share at any cost, and that books revenues improperly in the process? Or do you maintain a line that prevents the company from crossing into unethical behavior that may get you into trouble not only with the antitrust authorities and the Securities and Exchange Commission, but also with customers, employees, industry analysts, investors, and business partners?

Back to Top

Market Performance and Revenue Recognition

Companies that are true platform leaders and market leaders, like Microsoft and Intel, rarely have to resort to accounting shenanigans to improve short-term financial performance. But companies that are struggling to maintain or improve their finances can be much more vulnerable. In fact, many if not most software companies and other high-tech firms at one time or another find themselves guilty of treating revenues in misleading ways. The Financial Accounting Standards Board (FASB), the American Institute of Certified Public Accountants (AICPA), and the Securities and Exchange Commission (SEC) all have rules that contribute to what are called Generally Accepted Accounting Principles (GAAP). These rules supposedly govern how software companies and other firms may treat revenues, expenses, and other accounting data, but there is too much room to maneuver. In the Enron, Tyco, and WorldCom debacles that unfolded during 2001–2003, we saw how bad and lax some accounting procedures have become.

One problem, even among companies that do not intentionally try to mislead analysts or investors, is that the rules are subject to aggressive or conservative interpretations. For software, the rules for revenue recognition depend on vague terms such as when there is "evidence of an arrangement," or when "the product has been delivered" and "the related receivable is deemed probable." Different folks can interpret these words and issues—such as whether or not the product is finished—differently.

For example, companies are not supposed to declare preproduction or beta software as "finished." But some 70% or 80% of all software projects are late. And stock market pressure on companies to show strong or growing revenues is relentless. Most software companies run out of time and many take shortcuts in development and testing. They may deliver a product that requires a lot of work to complete features or fix defects. An ethical company will notify the customer of changes in the deliverables and then withhold or adjust revenue recognition. An unethical company will recognize the full revenues anyway and then try to finish or debug the product in the field, often at its own expense. Not only is this practice against the rules and unprofitable financially, but customers can become angry when they realize they have paid for a product that doesn't work as promised. Refunds, lawsuits, and permanently lost customers can result.

Another problem occurs when software companies immediately recognize revenues from maintenance and upgrade contracts when they should recognize these revenues as they deliver the products or services, which usually occur over years. Still other firms may not recognize product revenues when the sale is made and then declare these in the next fiscal period in order to make revenues look more even and recurring—a practice that deceives investors and analysts. (Some analysts believe Microsoft has become a master at this smoothing of revenues, although most sales and nearly all its profits come from Windows and Office, which are sold on a fairly regular basis as customers upgrade their personal computers or buy new machines.)

Some software firms that rely on sales subsidiaries or "channel partners" to sell software are vulnerable to another type of revenue-recognition problem: declaring transfers of products to other firms but not end users as revenues, even though these "sales" may never come to pass. This type of machination drove the former high-flier ERP software company Baan into bankruptcy and then a takeover by Invensys PLC in September 2000. Baan relied heavily on sales of software to distributors or resellers, some of which it owned directly. When poorly thought-out acquisitions and problems with its product line led to a drop in sales, managers devised a virtual shell game with inflated "sales" to distributors. Faith in the company collapsed after customers realized Baan had been wildly inflating revenues.

Peregrine Systems, a software company founded in 1981 that provided technology infrastructure management software, also declared bankruptcy in 2002 for similar reasons. An SEC investigation concluded the company overstated revenues by $250 million between 1999 and 2001. The result was a massive decline in sales to new customers, and a huge wave of layoffs and resignations.

Perhaps the most famous example is that of Computer Associates (CA). The SEC is currently investigating the company for possibly back-dating and forward-dating contracts to move revenues between quarters; bundling software products with maintenance contracts to justify more up-front revenue recognition than is normally permitted under accounting rules; and changing accounting procedures in a way that made it possible to recognize the same revenues twice and inflate sales. The investigation was ongoing when this column was written, and company executives claimed to have valid reasons for making these changes in contracts and accounting procedures. But CA has also had to work hard to reestablish trust with customers and investors, such as by creating a new department of corporate governance and adding several independent directors to its board.

Back to Top

Lose Credibility and You Lose Customers

Besides accounting chicanery, there are other ways for software companies to lose credibility and, in the end, lose customers. For example, software companies usually announce release schedules and product road maps. How often do these companies deliver what they said they would when they said they would? A well-managed organization takes into account that the vast majority of software projects are routinely late, and all software contains bugs. Managers should build discipline into sales agreements and product specifications, and add buffer time to schedules and protect debugging and testing time, so that the company does not appear to overpromise and under-deliver. Too many firms, however, simply rush a product to market or to a particular customer, and then endure the consequences. They may have to finish products in the field after they have booked the revenues, and then absorb the remaining development and testing costs themselves, as well as face the ire of a frustrated customer.

Few companies are powerful enough to manipulate markets and customers through a monopoly position. While this occasionally occurs, more often we see other types of character problems in the high-tech world, particularly related to revenue recognition and product development and delivery. Individuals, corporations, and governments put their trust in computer systems, many of which are mission-critical. Software producers are in unique positions of trust because what they produce—computer code—is difficult to see and even more difficult to test. Customers, therefore, need to evaluate the character of the vendor they are dealing with, as well as the products being offered.

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2003 ACM, Inc.

---

No entries found