The simple approach is to rank order the vendors of the specific product by market share. There is little risk in selecting the top three products in a market and limiting your selection to those products. This reduces risk because the “institutional knowledge” of all of the clients in the marketplace are generally embodied in these products.
These products will be coming from vendors who are also more financially stable and better able to extend these products to adapt to the ever changing market conditions we face today. Unfortunately, they also tend to be the most expensive, but not always.
You should be very careful about this step though because there are a lot of vendors with old “legacy” products, which have lots of installs, but are basically old and tired, which leads many companies selecting very expensive or complex products to seek out help with this process.
There are a number of good research firms with deep knowledge of the marketplace and, although this does complicate this part of the process, it does significantly reduce the risk.
There are good new products coming out every day, but I don’t like to be at the cutting edge for most processes, I’d rather have a lower risk proven product with a commitment from the vendor to continue development and expand the capabilities of the product.
Step 6 – Selection Parameters
Once you’ve completed your models and have a good understanding of the requirements, you can draft a request for proposal (RFP) based on those requirements and send it to the vendors you’ve identified in Step 5.
This is a straightforward exercise much like the selection of many capital goods. You will then rate the requirements in terms of their importance to your particular situation, so you can “weight-average” the answers from the vendors.
Vendors should answer each requirement with one of four answers:
Clearly you are shooting for answer No.1, but knowing that a particular feature will be available in a future release may also meet your requirements — depending on your implementation schedule. Or that a third-party vendor can provide the functionality, while less desirable, may also meet your needs.
Once you’ve rated the packages against the requirements, you will want to pare it down to a very short list, perhaps only two vendors and begin site visits and reference checks. In general, the vendors will try to steer you to their “pre-qualified” references, but I urge you to spend some time on Google searching for other users of the software and making some calls on your own.
Ask specifically what they use the software for, how difficult it was to implement, the quality of the support they’ve been receiving, and focus on the problems or limitations of the software. Even if the specific problems don’t seem to affect you, you may want to keep them in your back pocket for negotiating leverage.
Insure you are speaking about the save version of the software you’re going to purchase, because the problems someone might tell you about may have been fixed in subsequent releases. If possible, visit sites not selected by the vendor, but ones you’ve found yourself.
Site visits are generally a nuisance for most companies, so try to be as unobtrusive as possible, and remember how valuable site visits are when someone asks you.
Step 7 – Implementation Considerations
Selecting a package is just the first step in longer process that involves actually getting the benefits you’ve identified. So, you’re going to have to get the package running, and that means the “I” word: Implementation.
While this article discusses the steps necessary to select a product, it really represents 40% or less of the effort involved in obtaining the benefit — 60-80% of achieving the benefits defined in the business case depend on a successful implementation. And discussing how to implement a COTS package is well beyond the scope of this article.
Most projects fail, not because the wrong software was selected, but because the implementation was poorly managed. In large-scale projects, you will need to bring in help to implement the software. This is the realm of the “system integrator” and selecting the right SI is another secret of the successful project.
Generally, you should ask the vendor of each system on your “short list” to recommend their Top 5 implementers. Again, this is simply the triangulation of knowledge in the marketplace, thus reducing the risk. Certainly talking to other companies who have implemented the package you’re leaning towards would also be of value.
Step 8 – Negotiation and Contracts
This is a straightforward process, much like the negotiation of any acquisition of capital goods. It’s a good idea to get the “standard contract” from each vendor early in the process for legal review. This can shorten the process later on, and sometimes you might find a clause in the contract which would be a deal breaker, thus eliminating one of the potential vendors early on.
Knowing the fiscal cycle of the vendor is also a good piece of intelligence because deals at quarter end and year end, as salesmen reach to make their quota, are legend. Here again, you can bring in an expert to help you negotiate, and there are a number of consulting firms with expertise in negotiating complex software agreements.
Step 9 – Implementation Issues and PMO Formation
Once you have the software selected, your work has just begun. Selecting the system integrator is as important as picking the right package, particularly in big implementations, because you are going to commit to using a specific methodology, or approach to the implementation.
A small package may actually be implemented by the vendor, but in general, we’re really discussing major packages in this article and major package are generally not implemented by the purchaser or the vendor.