December 3, 2018December 3, 2018 Richard Boardman

Seven things to consider before you sign a CRM contract

The following article sets out my thoughts on the things that you need to consider when you’ve reached the point of contracting with a CRM implementer.

So, at this stage you know what CRM technology you’re going to use and who you would like to implement it, and it’s a case of signing on the dotted line to get the project underway.

Before you sign any contracts though, here are seven things I suggest you check you’ve got covered:

Is there a clearly specified deliverable? – in other words, are you crystal clear what the deliverable from the project is? And, more importantly, does the implementer share the same expectation. If you think they’re going to build you a palace, and they figure they’re building you a bungalow, there’s a crucial mismatch and a major problem.

The answer is to have a detailed specification before the project starts. If you don’t have one, my advice is simple – don’t contract to the whole project until such time as there’s a specification that’s understood by both parties, and for which there are a firm set of costs. A guide about to how to create a CRM specification and what I think should go into one can be found HERE.

Don’t buy ‘stuff’ until you need it – I was speaking at a conference a little while ago and was chatting to one of the other speakers whose company was midway through a lengthy CRM implementation. It turned out that his chief executive had done a deal two years previously to buy several thousand CRM subscriptions, which they’d been paying for ever since, but no one had been using, and were unlikely to be using for some time yet.

The reality is that CRM implementation projects are rarely brief, so there’s no point wasting money on software when you’re still building the system. Buy the licences when people need them.

Agree delivery and payment milestones – breaking a project into a series of deliverables, with payments being made on satisfactory receipt, is a powerful way of ensuring an implementer delivers what they need to, when they need to.

CRM projects are generally billed by implementers on a ‘time and materials’ basis. In other words, they bill you for the time they spent working on the project in the previous month, rather than by tangible output. I’ve found that implementers billing on a time and materials basis can lose focus as they drain the available budget, which can significantly impact the timeliness and quality of their subsequent deliverables.

Have a break out clause – I see a lot of organisations commit a lot of money to CRM projects, with no contractual escape route unless the implementer significantly under-performs. The reality is that things can change, and can change suddenly. Wars, economic melt downs, legislative changes, mergers and acquisitions, competitor activity, financial issues, the loss of a key customer, changes of management, are just a few of the things that could suddenly impact the desirability of completing a CRM project. Having a break out clause, where you get to choose if a project continues can be a very useful insurance policy.

Manage the intellectual property rights – the relationship between buyers of CRM technology and its implementers is often a fragile one. Partly because the quality of implementation partners is very varied, and partly because buyers sometimes have unrealistic expectations about the performance of their implementers (and partly because implementing CRM technology can be a very fraught process where relationships can quickly sour).

It’s generally best therefore to approach the contracting part of a project with the expectation that the relationship may well end, and that managing that potential ‘divorce’ must be a key contractual consideration.

One of the principle elements of this relates to intellectual property rights. Let’s say you’ve decided to implement Salesforce.com, for example, and you’ve selected an implementer to customise the system to meet your needs. It’s important that your contract establishes that you have a perpetual licence to use any intellectual property that’s generated during that customisation project, so that should the worst happen, your able to continue using those system capabilities after any break up.

Ensure you have access to the code – this is an important extension of the previous point. Having the right to use intellectual property is one thing, but it’s also important to be able to access any coding that the implementer has generated, so that if you, or a new implementation partner, needs to make changes, perhaps to enhance or improve a capability, or because it no longer works as the result of an upgrade, you’re potentially able to do so.

It’s very easy for an implementer to lock down or ‘black-box’ the code they write, so while you might contractually have a perpetual licence to use the intellectual property, it’s important that this is married up with the ability to get your hands on the code if you need to and amend it as required.

Make sure it’s all documented – this is particularly key for more complex projects. It’s important to document what work has been done on a system, particularly in terms of ‘hidden’ capabilities such as custom-coding, scripts, workflows, and integrations. Without this understanding of the mechanics of your system it’s difficult to manage ongoing change, because you can otherwise unwittingly cause problems – ‘wow, I didn’t realise when we removed that field, it would take our website down’, or you end up freezing development because you don’t know what’s likely to break when you change things.

My advice, if there’s any great complexity in your system, is to ensure your implementer documents their work. This documentation should happen post go-live, rather relying on initial requirements and design specifications, because things can often change during development. I would also make sure it’s a defined project milestone, and, as discussed earlier, linked to an associated payment. Otherwise it becomes one of those important, but not urgent things that never quite seems to get done.

In conclusion, it’s generally best when it comes to implementation contracts to assume the worst, particularly in terms of the likely longevity of the commercial relationship, because the worst surprisingly often happens. Taking the trouble to ensure that you’re covered for the future, rather than just signing what’s put before you, might take a little more time, but in can save you plenty of trouble and expense in the long term.