By Paul Murphy, author of The Unix Guide to Defenestration
Before your company does a deal on some major piece of software, check the supplier's history and SEC or other public financial information filings.
Your boss probably thinks establishing a vendor's financial strength in terms of its liklihood of survival for the duration of your contract suffices, but there's a lot more to it than that.
For example, you can usually find out from SEC filings what percentage of a vendor's annual revenue comes from new sales versus support, customization, or other services. If the new sales percentage is low or has been decreasing for a number of successive quarters, alarm bells ought to start going off. There may be a good reason for this, and if so the vendor should be willing to tell you --and the company's R&D budget should show up in its financials as relatively large. In most cases, however, this kind of revenue imbalance suggests a vendor business strategy based on leveraging maximal service revenue from a fixed code base --meaning that buying in will probably cause your company to fall behind the curve while being extra-billed every time someone sneezes.
Similarly, it usually pays to check the company's history to see where the product came from. Generally you can use google to get some idea of what to look for and then the SEC's edgar database for the details. If the product your vendor wants to sell you came their way through the acquisition of the company which originated it, you need to check to see what happened to the original developers. Good software companies buy others to get their people; rip-off artists buy other companies to get their products. So did your vendor lay-off the staff they got with the product? if so, they're much more likely to see their customers - you - as cash cows than as partners in moving the technology forward.
A qite different, but also valuable, step involves looking for, and then at, discussion or user group archives if these exist for the product your company is looking at. A vibrant discussion with lots of complaints about new features being difficult to implement is a good sign; one in which relatively few participants mutter mostly about change in the PC client or Wintel load procedures a very bad one. The thing to look for is substantive change --change that goes beyond cosmetics to address external change in the business environment because if that's not there, your company will probably not get long term benefit from its commitment to this product.
There are exceptions, of course, and you shouldn't let one or two negative indicators turn you against a vendor --but you should always investigate, think about what you find, and then ask the right questions before deciding on a software product purchase.