Full disclosure

Software Magazine, July, 1998 by Joshua M . Greenbaum

Due diligence is a polite way to say cover your ass, but the truth is that no matter how much due diligence CIOs do on their software vendors, there's just too much really important information that they can never get their hands on. Imagine what life would be like if the software industry were under the same level of scrutiny as the tobacco companies: Secret documents, subpoenas for internal research, evidence of (gasp!) misleading the public. Or worse. Aside from the public spectacle, it sure would make it a lot more interesting to be buying software in today's market.

The following is a list of my fantasy documents. Some actually exist, some should but don't, some had better not exist at all. Feel free to E-mail yours to me.

* Bug reports. Wouldn't it be great to know how lousy the software was performing for current customers? You could match up the sales pitch with the bug reports and get a pretty good idea of who's telling tales about features and functionality. The only problem is that you'd have to wade through a thicket of bug reports for each vendor in your A-list and try to figure out which one was less buggy. It could take weeks.

* Bug fax plans. As good as a bug report would be, it would be even more informative to know what bugs were planned to be fixed in the next version. That would help with the comparative bug analysis mentioned above. If the bug you need fixed wasn't on the list, you'd have a nice reason to buy from someone else. More likely, you'd spend a lot of time comparing bug fix plans too.

* ROI or Total Cost of Ownership studies. Imagine if every software vendor had to show you the exact relationship between the cost of procurement, implementation, and maintenance of their product and the value it brought to the first five customers who bought it. Imagine if you could just skip the whole Painful RFP and vendor qualification Mess and go right to the bottom line: Spend X, save (or lose) Y. While you're at It, why not wish for a winning lottery ticket

* Lost account post-mortem. This has always been a favorite -- what if could get the software equivalent of the reports the Federal Aviation Administration does every time a plane goes down? Why the implementation failed, how many projects died, who was at fault, and how to prevent it next time. Again, like the bug reports, reading all of these for each vendor could take a little time.

* Employee worksheets. Imagine the salesperson in your office is promising you 24-hour turnaround on your implementation problems, and a team of dedicated engineers at headquarters for your project, and then you whip out a report that showed 400 hours of overtime, two homicides, and a birth in the vendor's support organization last week. For good measure, you show them a copy of the bug report before they catch their breath.

* Strategic planning group meetings. Actually, what you want is a videotape of the meeting, so you can see the beads of sweat, notice the looks of panic, and hear the screams from the CEO as it becomes evident that Microsoft is about to eat their lunch. Okay, maybe you'd see a bunch of calm, collected people dispassionately discussing golf. Either way, you'd be able to see the trouble coming.

* The marketing/engineering memo log. Dilbert fans all dream about this one. Engineering is working on X, marketing wants to sell Y, and the focus group customers --well, they're happy with their CP/M machines. Then the memos start to fly. Will the product ever get released? Will anyone really use it? Inquiring CIOs would like to know what people were thinking when the project first got off the ground.

* Internal consulting white papers. Wouldn't it be great to read all the reports that outside consultants crank out for software companies? Strategic planning, competitive positioning, magic quadrants. Does the software company know what it's doing? Does it know how to hire consultants? A good CIO could probably trace the evolution of industry analysis, correlate that with the strategic planning meetings, analyze these issues relative to the marketing/ engineering memo logs, relate the whole mess to the bug reports and fixes, postmortems, employee worksheets, ROI reports, and come up with a good analysis of what a software vendor was really up to.

The question is, would any CIO ever buy software again? Maybe a little ignorance is bliss after all.