Negotiating With Integrators

Once you have chosen your preferred integrator, it's time to negotiate the best possible agreement. Much as in the case of the agreement with the tool vendor, it's very important to negotiate the contract carefully, even if you are thrilled with your choice. It's true that the span of the contract with the integrator is limited, unlike the contract with the vendor that has consequences for the very long term through the support terms. However, surprises during the implementation have very negative consequences on the quality, date, and cost of the rollout, so it pays to scrutinize the contract.

Fixed Price or Time and Materials?

A fixed price contract promises to deliver a fixed scope for a given price. A time-and-materials (T&M) contract is a "pay as you go" arrangement, in which the final price is unknown and depends on what is required along the way, although T&M contracts often include a not-to-exceed price. Many people believe that a fixed price contract is the only way to contain costs and is therefore the only way to go. Whereas fixed price contracts are indeed alluring, the concept of a fixed scope creates its own dilemmas.

  • The critical issue is that they require that the scope be known upfront. This is not a trivial matter for larger CRM implementations, in which many issues need to be resolved prior to making any implementation-related decisions so that the scope is essentially unknown at the time the initial contract is negotiated.
  • Partially because the scope is rarely crisp from the start, fixed priced contracts tend suffer from the incredibly shrinking scope syndrome. The integrator keeps pushing features to the phase two list in an attempt to keep the scope within the originally agreed upon mold. As a result, the initial rollout can be unattractively skimpy and potentially derail the project as users are turned off by it.

This is not to say that T&M contracts are perfect. They offer little incentive for the integrator to contain costs and they therefore require a very hands-on project manager with good cost-control procedures to avoid wild bills. So what to do? If your project is small and relatively easy to scope, then go with a fixed-price project. You should be able to both define the scope properly and keep to it without problems. If your project is larger, try using successive fixed scopes. Start with a fixed-price implementation requirements definition phase. Although the scope of the entire project is not known at this point, the integrator should be able to define how long it will take to figure out the scope (and it should not take months, either). The outcome of the requirements definition project is a detailed list of requirements, which outlines the scope of the project. From the detailed implementation requirements list, the integrator may be able to define a fixed-price deliverable for the entire project. If you are still working out some of the details for the rollout, then perhaps a fixed-price bid can be created for the coding project only, with the rollout bid coming later. At the very least, even for the most complex projects, the integrator should be able to proceed to a fixed-price bid for the detailed coding requirements phase. Each successive subproject should have a clearly identifiable deliverable, theoretically usable even if the integrator doesn't participate in the next phase. Switching integrators almost never happens since the ramp-up time for a new team is prohibitive, but it's good practice to require deliverables that can stand on their own at each step of the way. In the end, don't worry too much about the way the payment is structured. As long as you have strong references and you are managing the project properly (we'll see how in the next chapter), you should be able to be just as successful—and just as thrifty—with a fixed price contract as you would be with a T&M arrangement.

Contract Checklist

Involve your legal team in the contract negotiation so it can catch any issues that may not be captured or are not sufficiently detailed here. Use this checklist as inspiration, not a replacement for legal advice.

  • What is the scope? It's often difficult to nail down the scope of the project right from the start, but attach the best requirement document that you have available to the contract. Assume that anything that's not specifically described in the scope is not included. Common areas of fuzziness include who will specify, purchase, and install the development, test, and production environments; who will provide training and documentation for the project, and what they may consist of; and how much rollout assistance will be provided, including fixing any bugs discovered during the rollout.
  • What are the milestones? They should be described as concrete deliverables whenever possible, and they typically require some kind of signoff process. Payments should be associated with milestones rather than be made on a fixed schedule. A modest deposit of 10-20% is fine, however.
  • Who will work on the project? Are any subcontractors used? The number and skills of at least the main players should be identified. It's best if the critical individuals are identified by name, including the project manager and the technical lead, although it's often impossible to get that kind of commitment in writing.

    You may want to request prior approval of all the members of the integrator's team, but the integrator will usually push back on such a request. In any case, expect delays in starting up the project if you insist on screening the team members.

  • When does the project start? You don't want to be kept waiting while the integrator lines up the team.
  • When does the project end? Are there any penalties associated with a late delivery? Because a lot depends on your team's ability to handle specific items and to approve deliverables, contracts very rarely include late completion penalties. You can try for an early completion bonus, however.
  • Who owns the code? It's crucial to check that code developed on the project actually belongs to you so you can use it and change it in any way that you see fit. If it's important to you that your code not be reused, specify that.
  • Are non-disclosure guarantees in place? The nature of CRM projects means that some or a lot of confidential information will have to circulate to the project team. Typically, non-disclosure agreements are in place even before a delivery contract is in place to allow the detailed discussions required to establish scope. Make sure that non-disclosure agreements also apply to subcontractors.
  • Is there appropriate liability insurance? Integrators typically decline responsibility for liability related to the project itself (that is, if the installed tool miscalculates commission payments, they won't be held liable for erroneous calculations) but make sure you are covered if an employee or a subcontractor slips and falls while at your site.
  • Who pays for travel costs? The answer is easy—you do—so the real question is actually what the travel costs add up to. With larger integrators, some team members may travel from afar to participate in the project. You may want to define reasonable costs for travel, for instance by requesting that the integrator adhere to your travel policy. Note that travel costs are often added to fixed-price contracts, so you need to ask about them regardless of the pricing structure.

Make time for a thorough evaluation of and negotiation with the integrator. Picking a strong integrator is very much worth the effort, as it will determine the fate of the implementation, which is the topic of the next chapter.