Tool Vendor or Third Party?

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:

  • The big plus is to have one responsible party for the entire project, both software and implementation. It's certainly possible for a CRM project to fail while the tool vendor is handling the implementation, but it's a big relief to avoid the potential finger-pointing that can arise when multiple parties are involved. The simplicity of working with a single owner is often the main reason why customers choose to work with the tool vendor.
  • The tool vendor should be able to provide well-trained consultants. This particular benefit may fail to manifest itself if you are working with a fast-growing or brand-new vendor, or a vendor that subcontracts carelessly. Ask plenty of questions about exactly who will work on your project and how much experience each individual brings to the project. I'll cover how to do this later in the chapter.
  • On the other hand, tool vendors may be biased. Their direct objective is to get the software installed and working to meet any deliverable requirements in the contract, and they may cut corners in the process. A third-party integrator can be more objective in analyzing issues and may be more motivated and effective at getting problems addressed with the vendor, as upside-down as this may seem.
  • As mentioned above, the tool vendors' capabilities are often limited outside the technical arena per se, whereas with a properly chosen integrator there is no limit to the variety of skills and services available.
  • Tool vendors may lack experience with specific integrations. After all, they know their product best, not other vendors'. Here again, an integrator with the appropriate experience is preferable.

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 downloaded. 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.

  • Certification should include some training requirements so that the developers can maintain their technical edge. Certification programs that require neither training nor testing are simply marketing programs with no bearing on the technical capability of the integrators. Substituting on-the-job for classroom training is just fine since many useful skills can be picked up through working on implementation projects, sometimes above and beyond what classroom instruction can do.
  • Certification should include some level of testing, and the testing should be hands-on as much as possible. Many smaller vendors do not have the resources to create formal testing programs, but an informal program can be very effective if based on real-life conditions. For instance, the vendor may award certification based on a certain number of successful implementations. That's just fine, and, provided the implementations are audited, should provide a more meaningful guarantee of success than a contrived classroom-based test.
  • Certification should cover all staffers at the integrator. This is a tricky issue, since integrators need to hire new staffers over time and since they often use subcontractors. Most certification programs apply to the organization rather than to the individuals, so check how new employees or subcontractors are included in the certification. If only a few core individuals are certified and other people are living off that reputation, you may not get much for the certified label.

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 Scenarios

Let's consider some typical scenarios and the corresponding options for selecting integrators. (They match the examples given in , "The CRM Team.")

Simple Tool, Simple Implementation

A 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.

  • If appropriate technical resources are available in-house, the implementation may not require an integrator at all. The primary candidate would be the IT group, at least if it has properly qualified people available. If the tool is as simple as the vendor says it is, an individual from the technical support group (a super-user) may even be able to handle the implementation.
  • If internal resources cannot be found, the tool vendor does offer a two-day, fixed-priced engagement to perform the implementation, although it is not pushing professional services and is actually recommending that customers do their own implementations. (By the way, the mere existence of such a small-scope implementation offer is a sure sign that the product is really simple to configure.)

    This vendor implementation package is technically focused and assumes that all business issues have been settled ahead of time. For instance, the consultant may ask how the customer wishes to route issues, but will not spend time advising on an appropriate routing scheme for the organization. In a situation like this one where processes are already established, it should work just fine.

  • Even for a small project like this one, it's important to have a project manager in place. If no one from the support organization is available, a consultant that specializes in tool implementations from a business perspective is a great choice. That individual should be able to guide the organization through the business and process choices that also need to be made.
New Tool, New Processes

This 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.

  • The tool vendor maintains a roster of certified partners to do the implementations and generally does not provide comprehensive implementation services. A selection will be made among experienced, local candidates. To supplement the integrator and provide an additional level of confidence, the vendor will be asked to provide an audit of the code and of the deployment plans to ensure quality. (Vendors almost always provide audit services even when they do not provide complete implementation services.)
  • The integrator will also be asked to drive the process definition effort so the ability to conduct such a project will be a critical piece of the selection requirements. The integrator will be asked to guide the process definition exercise towards processes that can be easily implemented with the tool.
  • Participation from the organization itself is very important, both on the IT side (to ensure that the system is properly integrated and will be supportable for the long run) and on the business side (to ensure that the processes can and will be implemented). All members of the CRM project team will be participating in the implementation.
Integrated System, Politically Charged Organization

This 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.

  • The tool vendor provides implementation services and is proposing to take on the implementation to ensure its success because it correctly senses the political tensions within the company and does not wish to be associated with a failure. However, the vendor's strength is mostly on the technical side and it's not clear that its consulting team will have the political savvy to navigate the expected pushback from the business owners.
  • The other option, and the better one in my mind, is to engage a third-party integrator, and indeed a third-party integrator with a good record for managing politically charged implementations should be able to carry off the project very well. Also, a third-party project manager is often better accepted by the business owners than one internal to the organization when it comes to making process changes because that individual is seen as being unbiased. That could be very useful with the sales team.
  • The tool vendor will be asked to provide audit services for the deployment part of the project. There will be synchronization required for the mostly field-based sales team and synchronization is always a tricky item, so it's worth getting the vendor involved for that piece. Audits for the project plan and the code review are always useful but they could be skipped here if the budget is tight since the project is quite straightforward from a technical perspective, with minimal customizations and no integrations.
  • It's essential that the teams involved be kept well informed and optimistic about the project throughout its course because of the political concerns. The communication piece of the project is particularly critical and should be carefully considered in the project planning.
Large System, Merger Situation

After 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.

  • The tool chosen is a high-end, complex tool with a long implementation period. However, the strategy is to keep customizations to a minimum. Only a handful of integrations are planned, the main one being with the bug-tracking system.
  • The project is large enough to be of interest to the tool vendor so the organization has a choice to either use an integrator or work directly with the vendor. Beside price, the decision hinges on the tradeoff of the desirability of working with a single vendor versus the ability of the vendor to provide process definition assistance. Since most vendors focus on the technical side, a third-party would be a better choice if significant process definition assistance is required.

    If the tool vendor is under consideration to handle the implementation, it should be vetted through the same process as any other third party integrator would be.

  • Because processes are being merged, the business owners will need to be involved intimately with the project at least at the beginning, to ensure the success of the process side.