About a month ago we had some people over for dinner and the discussion, at least on my side of the table, drifted to top-10 lists of the Letterman variety. What had happened to make that topical was that Canada’s entry into the late-night talk-show format had just been cancelled and the local papers were snitting about an American talk show host whose “insult puppet” had taken a round out of some walking embarrassment from Quebec.
As part of that conversation, I got challenged to name the top 10 worst IT decisions ever — something I couldn’t do then and still can’t do now, which is why I’m asking for your help in defining the criteria needed and then identifying examples.
The “rules,” as I made them up, are that the technology component of the decision must have been subordinate to the business decision, the decision makers must have had a clear choice, the outcome must have been a business disaster, and the documentation supporting the story should be reasonably clear and comprehensive.
Thus the story about Kmart’s top executive deciding to stop an early and successful supply-chain pilot from going to full implementation — thereby handing the chain’s market to Wal-Mart simply because Kmart was unable to see supply chain as more than an expensive inventory management tool — would be a perfect example if the documentation for it were strong enough for us to be sure it really happened that way.
Unfortunately, the conditions surrounding business IT decisions big enough to make the list are usually underreported relative to their real complexity. In most cases, we don’t really understand what went on and so can’t fairly judge the quality of the decision. For example, a lot of people I talked to about this immediately nominated IBM’s decision to use Microsoft’s MS-DOS instead of CP/M as the worst such decision ever made, but the evidence on that is at best inconclusive.
In fact, I think there’s a better case for considering the decision to license a new — and very limited — OS from Microsoft a brilliant example of creative corporate maneuvering, rather than a mistake.
Technically Indefensible Decisions
The key factor driving many of the decisions made by the PC development team at IBM was fear that their project would meet the same fate as the “future systems architecture” had in 1972.
Now sold as the iSeries but introduced seven years late as the System 38, the database architecture had been developed as a replacement for the card-based transactions model enshrined in the System 360 and was clearly better, smarter, faster and less expensive. Unfortunately, IBM’s System 360 customer base rejected absolutely everything about it, and IBM’s board caved in, almost literally at the last minute, to order the product shelved.
Eight years later, in 1980, the System 360 architecture was even more deeply entrenched. Knowing this, PC developers believed that anything perceived as powerful enough to threaten the mainframe would be impossible to get past the board.
As a result, they picked the 8088 — an eight-bit compatible downgrade to Intel’s already uncompetitive 8086 — instead of the MC68000, turned down both BSD and AT&T Unix for their machine, omitted both real graphics and a hard disk from the design, killed an internal effort to port the original PC client software from the IBM 51XX series, and contracted for a very basic OS from Microsoft to gain the support of William Gates II, father to the version 3.0 we all know and at that time an influential advisor to the IBM board.
In other words, their decisions, while technically indefensible, almost certainly have no place on a top 10 list of the worst-ever business IT decisions. Weakening the product in these ways got IBM into the game and may well have been required to get the company’s PC to market at all.
Destruction of DEC
The destruction of Digital Equipment Corporation (DEC) at the hands of its own management might be a much better bet, despite the ambiguities in the record. By about 1988, the company had grown to be IBM’s biggest competitor by building high-quality hardware and leaving software development mainly to the research community and its commercial spin-offs. At about that time, however, some of the company’s most senior executives fell victim to their own success and started talking about becoming IBM by leveraging their proprietary software to grow services revenues.
What this really meant was that they just didn’t understand their own markets: Commercial VAX users simply didn’t behave the way IBM’s mainframe community does and were fundamentally uninterested in buying support services for packaged applications that generally already worked as advertised.
As a result, when DEC started the Open Software Foundation — an organization founded with IBM and seven others in an attempt to bring Unix development under proprietary control — and cut off new development funding for Unix users, it effectively cut its deepest roots and left itself with no place to go once the services experiment failed.
By the time DEC’s executives understood this, however, the situation had changed. On the positive side, the Alpha CPU was an emerging success, but most of the innovators who had driven the company’s growth had switched to Sun- and Intel-based Unix, while AT&T’s adventure with NCR — itself a clear candidate for this top-10 list — had taken the strategic value out of the OSF.
In theory, the board could have admitted failure at that point and set out to rebuild developer loyalty, but instead it dithered for nearly two years before betting what was left of the company on Microsoft’s promise to take over for the research and other software innovators who had been driven off.
Coming Up with a Sensible List
As a business strategy, trying to outsource innovation to Microsoft turned out to be both naive and suicidal for DEC. But you can see how the people involved were led to that decision one mistake at a time. HP’s current executives, however, have no such excuse: With DEC’s example in front of them, they still chose to direct their company down the same path to oblivion — blissfully assuming that the combination of a hot new server CPU and Microsoft’s historic commitment to software innovation would open the road to IBM-like services revenues.
Wrong on all counts, of course, but it does have the virtue of nailing down HP’s “Itanic” partnership with Intel and Microsoft as the leading candidate for top spot on this list of the worst-ever business IT decisions.
Personally, I’d put DEC’s failure to recognize that commercial VMS users weren’t remotely like mainframers (in their spending or thinking) in solid second place, though I can think of some other contenders too — including AT&T’s purchase of NCR, American Microprocessor’s decision to lay off the first microprocessor design team, the Defense Department’s choice of staff and criteria in the development of ADA, and Intel’s decision to continue 64-KB block addressing in the i80286.
On the other hand, I’ll bet you have some ideas for both examples and criteria, and that’s what this column is about: asking for your help in coming up with a sensible list.
Paul Murphy, a LinuxInsider columnist, wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry, specializing in Unix and Unix-related management issues.