The crux of the selection process is the evaluation of the candidates. Evaluating candidates can be extremely time-consuming so it's important to make good strategic and tactical choices on how to conduct the evaluation so you can achieve a good decision in the length of time you allotted to it. The goal of this section is to discuss how to gather all the information that you need in the shortest amount of time. Keeping TrackEvaluations can be confusing, especially if you are evaluating lots of different vendors . Keeping good records avoids mistakes and saves time, and it doesn't need to take lots of resources. Record keeping is the project manager's responsibility. Since the end goal is to evaluate each aspect of the requirements matrix for each vendor, a good strategy is to summarize all the information in that matrix, keeping supporting arguments arranged by vendor and requirement number. Keep the records centralized so all team members can access them. To RFP or not to RFP?The traditional process for evaluating candidates is to use an RFP. The CRM project team prepares a detailed document (the RFP) that defines the tool or service being requested , what kind of information the vendor should provide, and how it should be packaged, and sends the RFP to all the vendors under consideration. The vendors prepare detailed responses to the RFP that are then evaluated by the organization. Based on the results of the evaluation the organization can create a short list of best-fit vendors. The RFP process is very useful in at least two ways. First, it forces the team to create a complete and detailed requirements list. If you are following the recommendations in this book that won't be a problem but I cannot over- emphasize the benefits of knowing what you want before you go shopping. Second, the RFP process naturally creates a formal record of promises made by the vendors. The results of the RFP are usually attached to the sales contract and can be referred to later on if there is a problem with the deliverable . RFPs are almost always used for government contracts and very large contracts for that reason. If you want to use an RFP process, you can refer to the RFP template at the end of this chapter for inspiration. The template may also be useful if you are not planning to use an RFP: you can use some of the questions as a guide when meeting with the vendors. Despite its strengths, I find that the RFP process often fails to deliver the benefits one expects, for a number of reasons.
Because of the issues with the RFP process, it's often easier and better to use instead a streamlined process through which you actually walk through the requirements list and score each item yourself, based on your experience with each vendor's product. One way of thinking about the streamlined process is that it's very much like the RFP process except that you gather the responses yourself rather than having the vendor write them down before the evaluation. Using a streamlined process has many advantages.
I very much believe in using a streamlined process but it does have a couple of drawbacks. One, the RFP process forces you to create a very clear and complete list of requirements. If you decide to use a streamlined process instead but you are not disciplined enough to create a strong requirements list, you may end up with a very poor fit because you never bothered to define what a good fit would be. Another situation in which an RFP process might be preferable is if you need to attach the formal results of the evaluation to the contract. If you want to use your scoring sheet for that purpose you will need to get it approved by the vendor, which will pretty much negate the time savings of the streamlined process. However, you will still benefit from the higher quality of information you obtain by doing the scoring yourself. Seriously consider using a streamlined process over a standard RFP. Setting Up Productive Vendor MeetingsRegardless of whether you use an RFP or a streamlined evaluation method, being able to orchestrate productive interactions with vendors will go a long way in shortening the evaluation cycle and, more importantly, in ensuring that you gather accurate and complete information. This important coordination work is usually performed by the project manager, although some delegation is appropriate, at least for larger projects. To create the long list you might have used conference exhibits and webinars to get a feel for the various tools and vendors. During the evaluation you will want to switch to personal meetings that require coordination and preparation. For high-end tools, the meetings will most probably be handled face-to-face. For the lower-end tools some or all meetings may be held through web meetings and conference calls. The contents and attendance issues are very much the same regardless of the channel, however. The number and the organization of the vendor meetings depend on the complexity of the project, the size of the team, and logistical considerations. A common approach is to start with an initial meeting of the whole team (perhaps preceded by a smaller-scope evaluation from a smaller group ) followed by a series of in-depth meetings attended by only those team members who are interested in the specific area being discussed. For instance, the business users (business owners and super-users ) will want to see detailed demos of the functionality. See Figure 6.1 for an overview of the meetings. The balance of this section describes recommended audiences and agendas and specifically describes how to get better demos. Figure 6.1. Vendor Meetings
Who Should Participate?It's very important to hold most vendor meetings with every team member in attendance. It's sometimes desirable or necessary to hold focused meetings for only a part of the team (for instance, an in-depth architectural discussion with only the technical staffers ). However, holding separate meetings as a matter of course makes for a disjointed and longer evaluation process, and eventually a poorer decision as each component is evaluated independently of each other. The project manager must orchestrate the various meetings. The process starts with the introductory meeting, a short meeting with the full team, branching off as needed into specialized meetings, and culminating in a longer group meeting for the final evaluation. The final meeting is almost always held face-to-face, often at the vendor's headquarter so all key staff members on the vendor's side can be present. Although it's certainly possible to include some team members through teleconferencing while others are physically in the same room, I find that such meetings quickly focus on the participants who are in the room and ignore the remote participants. It's very difficult to stay involved when one cannot hear all the conversation, cannot see what's being demonstrated, or cannot participate easily in the conversation. If you must hold meetings with some but not all participants on a teleconference, take great pains to ensure active participation from the remote participants. Send them materials ahead of time so they can preparefor the meeting and follow along during the discussion. Test the web conferencing connections and other tools that will be used during the discussion. Make a point to include remote participants in the discussions. If your project team is very large, it makes sense to have a core group do an initial evaluation of the vendors, bringing the entire team into the process only for vendors who pass the initial evaluation. If you choose to use a core group:
You may think that there is a tremendous burden placed on the project team at this point. Multiple meetings with all the vendors on the long list? That's not often the case. Many vendors can be eliminated after the initial meeting, at least if you use the initial meeting to focus on the critical requirements. Especially with a large project team or a long list with many vendors, a suitable core group should be able to handle the initial evaluation so that the entire team only has to meet multiple times with a handful of vendors. What Should Be on the Agenda?If you let the vendor set the agenda for the initial meeting, you can expect a rather lengthy presentation on the company, the CRM field, and the high-level product architecture, followed by a brief and slick demo highlighting the more clever features of the product. The demo is usually customized to your requirements to the extent that they are known by the sales rep. A "standard" initial meeting is slick and smooth. It also makes for a terrible way to evaluate the product. Since standard vendor presentations don't work, you should always set the agenda for vendor meetings. Define both the topics you are interested in and how much time to devote to each. Remember the five categories of requirements?
You should aim to cover all five categories in the initial meeting. Of course, you shouldn't bother to dig very much into implementation and maintenance topics until you are satisfied that the tool can deliver the functionality that you need, and you can't expect to get a final quote that early in the process. A typical first meeting can last an hour to an hour and a half (more is better if you want a meaningful demo) and can be structured as follows :
The project manager needs to spend time with the vendor to prepare for the meeting and to ensure that the vendor fully understands that deviations from the agenda are not acceptable. Otherwise you will find yourself veering back to the standard blend of 95% PowerPoint and 5% canned demo, a most unsatisfying use of the team's time. The project manager also needs to assertively redirect meetings that do not follow the requirements. Better set the stage in the first meeting than suffer through unproductive presentations. The project manager should conduct a feedback session with the team shortly after the initial meeting. If the meeting is held at the vendor's site, it can be difficult to convene right after the presentation, but try to hold the debriefing very quickly afterwards. The goal of the debriefing is to decide whether to continue evaluating the vendor, as well as to improve future meetings and presentations. Short debriefings should be conducted after each meeting. If only a core group participates in the initial meeting, assuming that they like what they see, repeat the meeting with the entire team in attendance. You can take advantage of the repeat to further refine the agenda to meet your needs. After a successful initial meeting with the entire team, you will want to set up follow-up meetings to discuss specific areas. Plan on several follow-up meetings, targeting functionality, architecture, and implementation. The follow-up meetings can be attended by only a subset of the team members. However, it's always desirable to have at least one representative from a non- targeted group in attendance as it helps with information sharing and group decision-making. For instance, ask a super- user to attend the architecture discussion even though it's mostly for the technical staffers. A good format, if you can arrange it, is to schedule parallel meetings for the various subteams and to allow individuals to move from one track to the other for full coverage. Regardless of how many meetings are scheduled and how they are arranged, they must be planned in advance by the project manager or a team member to ensure that the agenda and attendees are appropriate. One of the main complaints of CRM team members is that they waste time in unproductive meetings. There will be plenty of irritants down the road over which you have little control, so make sure meetings are well organized. Use the outcome of the debriefing sessions to make each meeting more productive than the last one. Getting a Meaningful DemoAlthough demos are invaluable to share what the tool can and cannot do, many demos are poorly planned and end up being either divorced from (your) reality or excruciatingly dull as each field and each screen is visited and commented on without an overall vision of how real tasks can be performed. Here are practical ways to turn demos into useful selection tools.
Tough Questions for CRM VendorsCleverly arranged demos are very powerful, and so are pointed questions to the vendor. I list here questions about the technical and functional aspects of the product. Pricing-specific questions are covered in Chapter 7, "Buying CRM Systems," and questions about integrators are covered in Chapter 8. For best effect, ask the tough questions several times during the evaluation from different individuals and compare the responses you get for consistency.
Another source of relevant questions is the RFP template at the end of this chapter. The questions are valid whether or not you are planning to use a formal RFP process. |