Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Selection Process
Force-fitting a package into a reluctant customer organization is often a pyrrhic victory. You may win the battle, but lose the mind-share war with your customer.
The essential challenge is to involve the functional customer groups to gain their buy-in, while not confusing them with technical issues. More importantly, you need to keep your credibility and customer focus so that you can counteract the impact of "gee whiz" features and clever vendor selling. This process can be daunting and time-consuming. However, if you don't have the time, but do have some money in your budget, every major consulting firm has a package-selection practice that can help you and your customers buy wisely. If you want to do it yourself, the following sections provide a simple roadmap of the steps in package selection.
Determine the Initial Requirements
Setting functional and performance goals for any new data system is the most difficult task. It's axiomatic that customers always interpret their needs in terms of what they know, and I've seen customers drive decisions toward packages that look like their existing systems but with the rough edges knocked off. It quickly becomes IT's job to intervene to be sure that the enterprises needs are being met and that the new system has the functionality and flexibility to be integrated into the corporate architecture.
In setting requirements, make sure that all participants understand the reasons for shopping for a new package. Are there functional deficiencies that will no longer support the business model? Is the existing system too old and too costly to maintain? If you're replacing a package, is it because the existing vendor is failing to keep up with evolving technology? Each of these reasons can lead to a different selection criterion and different level of customer satisfaction. Functional issues often must be reengineered into the customer organization, while technical issues can often be left to specialists.
Selecting Candidates
When the requirements have been decided, a Consumer Reports–style chart should be produced for each candidate vendor, summarizing how well each vendor's capabilities maps into your requirements. At this step, disqualify any vendor that has clear deficiencies. Don't be swayed by vendors selling futures or spreading junk. Your goals are to reduce the number of packages to two or three candidates worthy of serious consideration. The more you allow into competition, the harder the evaluation and selection process will be. Complexity grows exponentially with the number of vendors. Now is the time to be tough. Weed out weak or inappropriate vendors early.
Scripted Functional Demonstrations
Scripted demos have become a popular way to allow your functional customers to become familiar with the capabilities of the package, while learning more about their own needs as well. Scripting, the act of creating a roadmap for the demo, is essential. Scripting captures the requirements of the customers and inhibits the vendors' natural inclination to play to their strengths and avoid discussion of weak or missing features. Every customer has a wish list of needs, but as they run through the scripted demos customers begin to learn the tradeoffs that vendors have made, and they also learn which features are "must-haves" and which features they can live without.
This is also the time for you to begin learning about the vendors. You're going to be making a long-term commitment to the vendor's people, organization, and product, so now is the time to find out how knowledgeable their support staff is, how responsive they are to issues, how technically sound their product is. This discussion even goes to chemistry issues. How does their organization approach problems? Are their people empowered? Do you have access to management when you need it? If they don't impress you now, they won't likely impress you later.
Technical Evaluation
While the functional customers are going through the demonstrations discussed above, a technical team needs to carefully evaluate the package architecture using the criteria discussed above. The goal of this process is straightforward—determine whether you can live with the package in light of your architecture and technical vision. If not, don't touch it.
Business Discussion
In deciding on a package to become part of your enterprise setup, remember that you are not buying a point solution—you're buying a long-term relationship. Be sure that you clearly understand purchase costs, maintenance fees in future years, training costs, upgrade costs, technical support costs, and what insurance you have in the contract to enable you to control those costs. Get all the costs on the table, including upgrades to your infrastructure, before you decide. Going back to management with a bunch of "gotchas" later is not career-enhancing.
Decision
Once the decision is made, check to see how loud the screaming is from those in your organization. If people are comfortable with the decision and anxious to move ahead, the decision is right. If you're going to have to drag some departments kicking and screaming, then either ensure their support or the willingness of the executive sponsors to push with you, or don't move forward. If you're out too far in front of your organization on the issue, you might think about investing more in helping your customers prepare for the future. IT management is difficult enough without dragging your customers as well.