Hope your job is treating you well and believe everyone is in pursuit of new project /business opportunities. In this article I like to cover the purchase of right CRM software at the right price:
As I set out in the previous article on requirement gathering, the key to selecting the right CRM software is to have a detailed set of requirements. Only having high levels requirements – or none at all – makes it difficult to distinguish between the various offerings, because the functional needs are unlikely to be fully known, and pricing proposals will be indicative estimates which may prove to be very different from what you end up paying. Having detailed your requirements, the first step in the vendor selection process is to identify a good initial list of potential technologies and suppliers.
The start list
Not surprisingly, you’re likely to make better choices if you are selecting from a group of top-flight technologies and suppliers. Conversely, if you start off with a list which is largely inappropriate for what you are looking to achieve, then you simply end up selecting the best of a bad bunch. You may note that I mention both CRM technologies and suppliers. Generally – though there are exceptions – CRM software is sold or implemented through a network of independent resellers or implementation partners, rather than the company that developed it. The selection of the reseller or partner is at least as important to success as the choice of technology itself. It’s therefore important to think in terms of these two dimensions when researching the market. And, as the ability and professionalism of resellers and implementers varies very significantly, this should be an area where you take particular care.In this respect I’d be wary about recommendations from the software vendors about which resellers they think you should use. A lot of buyers will treat these recommendations as gospel, however they are invariably based on factors that suit the software vendor rather than the purchaser, for example, if the reseller is likely to make a quick sale (rather than implement the software well), or if you happen to sit in a reseller’s designated ‘territory’.
I generally look to get six to eight suppliers lined up to respond to a request for proposal (RFP). This gives a little leeway in case a few fail to respond. We also work hard to reassure the vendors that it’s an open contest (which it always is). If vendors harbour any suspicions that the decision might already be made and that the purchaser is just going through the motions, then they are unlikely to bid. Good vendors are generally very busy vendors, and responses to RFP’s are time consuming, so it’s worthwhile making the effort to promote the opportunity to them. This may sound a little counter intuitive, after all surely they should be doing the selling, but the value of working with a great vendor over a mediocre one, massively outweighs the effort.
The request for proposal
The next step is to prepare and distribute a request for proposal (RFP) document in order to better evaluate the available options. While some purchasers are inclined to skip this stage and start directly auditioning potential suppliers, getting written submissions from vendors gives you the opportunity to compare and contrast the offerings in a much more structured and analytical way, and gives you a better basis for action should disputes over what was promised arise in the future.
The goal with the RFP document is to strike the balance between getting the information you need to make a decision, while making it as easy as possible for the vendor to respond. If you make the RFP too onerous then there is a risk of potential suppliers deciding not to bid. As I mentioned before, a good vendor is likely to be a busy vendor, and they will weigh carefully the potential for successfully winning the business against the time and cost involved in preparing the response. So it’s best to keep the latter element as light as possible.
The RFP document should set out how and when the vendor should respond, and then prompt the would-be supplier to answer questions on the following areas:
• The profile of the software and its developer.
• The profile of the software vendor/implementer, particularly in relation to support capabilities, implementation approach, and experience with similar projects.
• Cost structure, including a detailed breakdown of both vendor supplied elements, such as software, services, training, and support and maintenance, as well as any other relevant costs such as hardware and database software.
• The final element is a table referencing the detailed requirements document, asking potential vendors to explain how they deliver each identified requirement, and provide man-day estimates for any that will require customisation/development to deliver.
While some of the vendors we work with may choose to disagree, we find this approach is light enough not to discourage responses, while providing us with sufficient information to make informed judgments about suitable candidates for the next stage: creating the short-list.
The short-list
Having received the responses, the next step is to review them and reduce them down to an appropriate short-list. I tend to grade them based on the following six questions:
1. How good is the functional fit?
2. How does the purchase price compare?
3. Can this vendor deliver a quality implementation?
4. Does it appear they want this project?
5. Are they going to be easy to work with?
6. Will they still be a strong supplier in five years time?
It’s worth noting that the information supplied to you shouldn’t be unquestioningly relied upon. There will be a lot of half-truths in tender responses along the following lines:
RFP question – ‘Does your software perform function xyz’.
Response from vendor – ‘Yes’,
The truthful answer – ‘Yes, though it involves using a third party module the price of which I haven’t quoted, it will also involves a considerable amount of customization, and it only works with the enterprise version of the software (and I’m quoting you the entry level version) and actually, while the module does do what you want, it’s not the best designed piece of software and your users will soon abandon it because it is unfathomably complex to use.’
So, if you have any suspicions that you may not have been given the whole truth, particularly if it’s in relation to a key capability, don’t hesitate to question it carefully with the prospective vendor.
The demonstration stage
Having determined a suitable short-list of prospective vendors – I’ve generally found four candidates to be a reasonable number – the next stage is to arrange for the vendors to present their products and credentials, normally in the form of a software demonstration and presentation.
This demonstration phase should be treated with a little caution. I know well from my time working for vendors how easy it is to script a demonstration in a way that showcases the offering’s strengths and skates over key weaknesses.
Software demonstrations, rather like job interviews, are a somewhat flawed process. A candidate may be great for sixty minutes in an interview, but it’s no guarantee they will perform over the long term. The demonstration produces its own distortions; I’ve seen excellent products from highly capable vendors culled from candidate lists for seemingly trivial reasons, and products I knew couldn’t do the job, from vendors who I wouldn’t trust to mow the lawn, end up winning the day.
So, while demonstrations are important, the polish of the presentation or the charisma of the salesperson should not unduly influence the decision making process. In fact over the years I’ve often found that there is an inverse relationship between the slickness of the sales process and the quality of final delivery.
To counter the presenter’s ‘slight of hand’, I’ve found it useful to inject as much structure as possible into the presentation/demonstration process, in terms of what to cover, and how long to cover it for. I’m also a great fan of giving prospective suppliers specific demonstration scenarios which reflect how the system will be used in due course. This makes it a lot easier to gauge how well the software fits the processes it will potentially support in real life.
Also, given that the successful salesperson is likely to disappear to the Caribbean for a ‘well earned’ holiday when the real work needs to be done, it’s a good idea to meet the people who will be involved in the implementation, particularly the project manager. You will be dealing with this team, not the salesperson, on a day to day basis, so it’s important to check they are capable and, perhaps more importantly, people you feel you can work with over the duration of the project.
At the conclusion of the short-list presentation stage you ideally want to be in the position where you feel comfortable that you could work with any of the vendors. This gives you more options moving forward. Hopefully at this point though you can identify a preferred potential supplier, though if it’s close this could be two, and move forward to the next stage.
It’s important though that the preferred supplier isn’t allowed to become too confident about their chances of being successful, because this can significantly impact your negotiating position in due course. It’s also not that unusual to reach a dead end with a ‘preferred’ supplier and need to revisit the original short-list again. Therefore it’s important that all the candidates understand that it remains an open contest.
The next step is to verify whether the preferred supplier is indeed the right choice. As part of this, I like to visit the vendor and get a better feel for how they run their business. This is also the opportunity to discuss any outstanding queries, meet other project team members, and discuss any potentially ticklish contract terms. It’s also a good idea to establish contact with relevant members of the supplier’s executive team, as you may need these lines of communication later if issues crop up on the project.
Many people will follow this up with reference calls, though this should be treated with caution. Even bad vendors will be able to rustle up a few positive references. However, as most suppliers like to showcase their customers during their sales presentations, a more insightful alternative is to take notes and make your own enquiries without going through ‘official’ channels. This is likely to give you a much truer picture as to a vendor’s reputation.
Assuming things progress satisfactorily, you now need to finalise the price for the project. In general it’s better to get the vendor to commit to a firm price, rather have them working on a time and material basis where they are effectively incentivised to take as long as they can.
If your requirements have been defined in detail as previously described, this should be a fairly brief process. The vendor should be able to review the requirements, and, with a relatively small amount of discussion and clarification, arrive at a fixed price. If you haven’t been able to get to a suitable level of detail, then more work is likely to be involved. The prospective vendor will need to undertake their own requirements analysis work which will generally be a chargeable exercise.
The key though is to only pay for the requirements work at this stage, and not to commit to the project as a whole. If a vendor is working on finalising a price for the project, and you are already committed to them because you’ve already bought the software for example, then you have very little leverage if they decide to take advantage of the situation and ramp up their estimates.
In general I tend to be very uneasy if there’s any significant difference between the price provided in the original RFP response and that provided at the end of this process. Unless there’s a reasonable explanation, I may elect to back track a little and conduct a similar process with other suppliers, which, again, is why it makes sense to keep your options as open as possible during the vendor selection phase.
Negotiation
As a final part of the process you may wish to negotiate pricing and terms. While it’s in your interests to structure a project so the vendor can make money on it – otherwise they may try and cut corners later – trimming out any unnecessary fat can make a big difference to the final purchase price.
While this may involve negotiating down software prices or day rates for implementation work, it’s the amount of implementation work that you need to be careful of because it’s easy for vendors to pad this out if they wish to. So, if the vendor is quoting ten days to perform development work that should only take two days, you are going to be significantly overpaying, even if you’ve successfully negotiated down the day rate.
When you are looking to negotiate pricing, here are a few tips:
• Look at timing – vendors are much more likely to offer discounts at key points in their financial year, such as quarter and year ends.
• Don’t show your hand – the tendency to discount will reflect the degree of confidence the vendor has of securing the deal. If they are confident, they tend to discount less than if they feel there is a realistic chance they may lose the opportunity.
• Have options – you are in a much better position to negotiate if you have three or four viable suppliers, than if you have just one.
• Research - a little knowledge about discounts a vendor has offered in the past can go a long way to help secure a satisfactory conclusion.
• Get outside help – if you are unsure if the number of days you are being quoted for development work is fair, get independent advice from someone familiar with working with your preferred technology.
• What can you offer? – vendors are much more inclined to negotiate the greater they see the value of you as a customer. Could you be a reference for them? Might the system extend to other parts of your business? Is your decision likely to persuade other companies to buy? Is this a new market or a new application of their product? If you can communicate your full value as a customer, the keener the vendor is likely to be to secure your business.
• Don’t get pressurised – vendors love to make pricing concessions based on you ordering by a certain date i.e. 10% off if you order by 31st December. These are generally artificial devices designed to force a quick decision. A quick decision may not be in your interests however, so progress things at your own pace, the discounts will almost certainly still be there when you are ready to move forward.
Contractual terms
Getting the right price is important, but meaningless if the contractual terms are not right as well. Be aware that anything involving contracts has the capacity to take a very long time, and, if you are working to tight time-lines, the earlier you can begin the process the better. So, it’s worth making sure that both parties have visibility of any contentious terms during the RFP stage.
With respect to negotiating terms, I’m not intending to offer any specific legal advice, but the following are few areas you may wish to be mindful of when finalising an agreement:
• What does the software agreement allow you to do? – It’s important to be clear as to how many users are allowed to access which capabilities of the system. For example, most vendors have different versions of their software from say entry level to enterprise, and it’s important to understand which version you are licensed to use and what the associated restrictions are. It’s also worth checking whether you have the right to run a separate instance of the software for training or testing purposes.
• Are all the costs known? – there can be a lot of hidden costs when purchasing CRM technology. Additional storage costs can be an example in a hosted environment, or maintenance agreements that are free of charge when you buy the software but kick in heavily in future years, for on premise software. Make sure these costs are fully disclosed in the agreement, and it can also be worth negotiating a cap on a vendor’s ability to raise prices to unreasonable levels in future years.
• What are the payment milestones? – I generally prefer contract payments to be built around the achievement of specific project delivery milestones, rather than the vendor invoicing on a weekly or monthly basis. This helps focus vendors on delivery rather than billing. In terms of software, when do the licenses need to be purchased? Vendors like to invoice on order, but if the implementation time-lines are likely to be lengthy and no one is using them before they go live, then this can unnecessarily tie up capital. Equally support and maintenance agreements should ideally start from ‘go-live’ rather from the order date.
• What’s the basis for payment? – In general I prefer fixed price contracts where the costs are known in advance and there’s less scope for cost overruns, rather than time and materials contracts where there’s no incentive to the vendor to complete the project in a timely fashion.
• Who owns the intellectual property? – By default a supplier will own the intellectual property rights to any customisation or development work they perform on your system. If you subsequently fall out with them, you may find that you no longer have the right to use the software, therefore it’s important that the contract addresses this ownership issue. There are a number of options which range from you owning the copyright, which the vendor may be reluctant to grant, to having a perpetual license to use it. In working this through you may also want to consider how you would feel if your chosen vendor offered the customisation work they had performed for you to your closest competitor!
• How can an agreement be ended? – Whether the agreement is for support services, or a software as a service (SAAS) contract, it’s important to be clear how the agreement can be terminated. Ideally you are looking to have as much flexibility as you can, whereas it’s generally in the vendor’s interests to restrict you as much as possible. I particularly dislike contracts that are automatically extended unless the vendor is notified by a certain date. If a vendor is unduly focused on locking you into a contract, it’s generally a red flag in terms of their confidence in their ability to deliver a quality service.
SUMMARY
The combination of a comprehensive set of CRM requirements, and a well structured approach to the vendor selection process, helps ensure that you choose the most appropriate technology for your needs, and purchase it at a fair price. I estimate that it’s on average 30 – 40% cheaper to purchase technology with the ‘front-loaded’ requirements led approach set out above, than the more traditional approach where poorly defined requirements mean prospective vendors are unable to provide firm pricing. This approach also speeds up the implementation phase and reduces the risk of later overruns.
Loving P&C
DC*
No comments:
Post a Comment