Does it make sense to select a third party to do the implementation rather than to ask the tool vendor to do the job? Let's start by stating that this is not always a real dilemma since many tool vendors cannot or will not handle entire implementation projects. After all, vendors are in the software business, not the consulting business, and therefore prefer to spend their resources and energies on their core business rather than on services. Don't get me wrong, vendors almost always offer implementation services, but they target the technical aspects of implementations , only rarely addressing either the process definition or the change management components . If your project requires a comprehensive scope you may not be able to get all the necessary resources from the tool vendor. Moreover, tool vendors leave the smaller-size implementations to third-party integrators and choose to focus almost exclusively on the larger, more strategic implementations. They handle the larger implementations because the larger clients demand it. They also fear potential negative publicity for themselves if such projects were to fail, believing (correctly) that their involvement reduces the risk of failure. Even on the projects the tool vendors take on, they frequently contract out the tactical coding pieces and concentrate on the strategic areas of the project. The ASP vendors are an exception to the rule, in that they always provide implementation services. ASP vendors also focus on the technical aspects of the job rather than on process definition. This may not be as large an issue in this case since ASPs limit the customization options so you pretty much have to follow a predefined business process. Although you may not have the option of having the tool vendor perform the implementation, here are pros and cons of going with the vendor rather than with a third-party integrator:
If you are considering asking the tool vendor to handle the implementation, put the vendor through the same evaluation process as you would a third party integrator. Do not assume that the vendor's implementation team has handled projects similar to yours before, or even that the team will be technically competent just because it's on the vendor's payroll. (If nothing else, a vendor with a lot of new consultants will have to put some inexperienced individuals on the project.) The other reason to perform the same evaluation is that vendors are often more pricey than third-party integrators, and cost should be an important component of your evaluation. Mix and Match?A mix-and-match approach to staffing implementations is perfectly reasonable. Actually, leaving all the implementation work to the integrator would be a disaster, and we will come back to this point in the next chapter. Start by assessing the resources that you either already have in-house or are planning to acquire, perhaps to provide support for the tool. It makes no sense to hire a contractor to do a task for which you have appropriate talent already ( assuming said talent is not fully consumed by other tasks .) Mixing your own team with hired guns is perfectly reasonable. What about mixing and matching resources from multiple parties, and in particular getting some resources from the tool vendor and some from an integrator? When does it make sense to do that? It's important to realize that mixing and matching is likely to occur in the background if the tool vendor is responsible for the implementation. Most tool vendors subcontract widely, especially the non-strategic, coding part of the job. In that situation, since the vendor is taking ownership for the job, you may not care too much about the subcontracting , but it is happening anyway. (By the way, third parties almost never subcontract back to the tool vendor.) That being said, because of the complexity of the coordination required when using multiple parties and because of the potential for finger pointing, it rarely makes sense to divide up the project between the vendor and a third-party integrator. Stick with just one player for the implementation. However, if you are working with an integrator you should seriously consider getting two things from the vendor. One is a list of implementation guidelines that spells out how to minimize maintenance issues and that the integrator should follow. There should be no additional fee for this. The second thing is to request that the tool vendor come in for audits at crucial junctures in the project such as validating the project plan before the actual development starts, reviewing customizations before they are deployed, and confirming the deployment architecture before hardware is purchased. You will have to pay the vendor to get the audit services, but audits are short and therefore not that expensive. View them as insurance that the project is on the right track. If they should uncover a problem you have an opportunity to make changes before the consequences are too serious. Purchasing audit services from the vendor should bring you guru-level technical expertise, which may not be available from a third-party integrator, however experienced . Providing audits also forces the tool vendor to put a larger stake in the game. Audits help decrease frustrating and fruitless finger-pointing between the integrator and the vendor and they provide a solid start for the long- term support that the tool vendor will be providing. Are Certified Partners Better?Many tool vendors have a partner certification program through which third-party integrators can receive training and assistance and get a seal of approval in return. If the vendor has a certification program, it's best to seek out a certified partner, more because serious integrators seek out certification than because certification by itself is a badge of quality. In other words, serious integrators are certified, but not all certified integrators deliver quality. Certification programs run the gamut from bare-bones programs focused on information delivery to sophisticated setups that include a serious testing component. Many certification programs are amateurish and do not include any testing component. Most programs do not include any hands-on testing. Your first concern should be to get a description of what the certification means from the vendor's Professional Services or Partnerships manager. Here's what to look for.
Even if you find that the certification program is rigorous and includes meaningful testing, you still need to evaluate the integrator to make sure it meets your standards. In particular, no certification program can tell you whether the integrator has been successful with implementations similar to yours. If you find that the certification program is a bit of a joke, you may disregard the label when evaluating integrators. Serious integrators may not bother getting certified if they think the program is a waste of time. Also, with a weak certification program, you will need to perform a particularly thorough check of the candidates, including their technical abilities , since the certified label is meaningless. Implementation ScenariosLet's consider some typical scenarios and the corresponding options for selecting integrators. (They match the examples given in Chapter 4, "The CRM Team.") Simple Tool, Simple ImplementationA small support team (15 people) is implementing a new support-tracking system with an integrated knowledge base and customer portal. The new tool replaces an existing system that only provided case-tracking features. Little disruption to the existing case resolution process is planned. The tool that was selected is a mid-range tool with a particularly easy implementation, so much so that the vendor reports that many customers are able to do the installation themselves with the assistance of a couple of conference calls with support personnel. This is a straightforward project, certainly from the technical side, since the customizations are minimal and no integration is planned at this point. The process definition side is potentially more complex since knowledge management processes can be intricate , but with an organization this size nothing should get too complicated. The choice of the integrator depends mostly on what technical resources are available.
New Tool, New ProcessesThis medium-size sales organization (120 people) is global and is implementing a sales-tracking system to replace manual processes, contact managers, and forecasting spreadsheets. The tool that is being selected is a traditional, client-server tool with significant implementation requirements, even for a relatively straightforward implementation like this one. There is some amount of process definition to be done before implementing the tool, since nothing is automated at this point.
Integrated System, Politically Charged OrganizationThis medium- sized organization is implementing a unified system for sales and support tracking to improve communications about customers throughout the company. There will be about 300 users altogether. The tool chosen is a mid-range suite that will minimize integrations, and indeed none are planned for the initial integration. There is some skepticism and pushback from both the sales team and especially from the support team against implementing a new tool. The support team already has a tool in place that is functioning adequately, although providing only barebones functionality, so it's not an overwhelmingly attractive proposition to have to switch to a new one. The sales team has no unified tool in place so there's a clear benefit to the new system, but also concerns about having to follow a set, potentially rigid process.
Large System, Merger SituationAfter a merger, two support groups are merging to a combined size of 400 people dispersed around the world. Both teams have used traditional support-tracking systems that need to be replaced for various business reasons.
|