Choosing a CRM system, the easy way. Or, not...

Every businesses goes through it to some degree– spending money to buy (and presumably implement?) something to help their business deliver…improvements. CRM systems; back-office systems; process management systems – in fact, IT systems in general all fall into this category. 

What to do?

This posting explores the pitfalls of buying process-based systems, and passes on some thoughts born of successful and failed projects. Your choice is whether to read, or learn from others experiences. And mistakes…

Over the last few years, I’ve been involved as a client and as a Project Manager, and have seen both sides of that relationship. In my time as Practice Manager, Practice Director, Operations Director and Project Manager of various professional and financial service firms, and more recently, Not for Profit and retail organisations, I’ve project managed several software implementations…

…and am constantly amazed at

how often an organisation will make major capital, organisational and cultural change decisions based on inadequate information, poor decision-making processes, and at times, a complete lack of understanding of the requirements of the organisation. And without any forethought about the ultimate costs of such decisions; or taking the time to review the plethora of systems available; or assessing the risk involved; or ensuring the right (and experienced!) resource is available; and sometimes without realising that what is sold is not always what is delivered!

It’s a well-known phenomenon, highlighted by Dilbert…

Like buying a house, buying software is more than just listening to the estate agent or software salesman. We’re not being disrespectful to salesmen, although some have to be heard to be believed… You’ll know the picture…

Some things clients should do before making a decision whether to buy a technological solution at all:

• Decide on the problem they’re looking to solve. That is as straightforward as agreeing the strategic need, leading to setting expected objectives. And making them measurable. It's always a good idea to start with the end result - what you want out determines what should be put in...
• Specify exactly what they want any new system to deliver – the requirements of the business from the system: which means talking to those who will use it, by the way... Really good Project Definition documentation includes a requirement to review current practice, measuring it against expected performance, to inform a business case. You do have a business case?
• Put it in writing. Not to protect yourself from future problems (although it can do that too!), but to remind yourself of your original intentions before making any commitment. Too many buy even, and continue to buy, even when it is painfully obviously not delivering
• Review the market and comparing what is available. Preferably after being honest enough to ask whether those specifying the requirements know enough about the solutions available

• Select a supplier from a short-list, if necessary of required. I’d stay away from a bespoke system, unless you have pots of money and infinite patience! Our preference is to have minimum adaptation to the ‘out of the box’ system, and even better, configuration only.
• Be clear that buying will mean change; to existing processes; reports; workflows; and outcomes.
• Have a plan before you start, and a detailed confirmation of what is on offer. Something to use when/if the technicians can’t deliver what the salesman has promised…
• Get testimonials – accepting that you won’t get given the ‘bad’ clients; and accepting that the web is a great source of information and opinion
• Get expert help – and absolutely someone other than the supplier. They may be impartial… Someone inside your business if available; outside if not
• Make sure that you have a means to implement – which means making this implementation a project – see here for some thoughts around planning a project. Before you incur costs…

There are very many 'solutions' around, so you have a wide choice. Oddly, that makes things more difficult, simply because there is so much choice. And be warned: it's unusual for any system to deliver a perfect solution in any event, extraordinarily unlikely for any system to be delivered straight out of the box, without some configuration. Be prepared to adapt the system to you, or for you to adapt to the system's constraints.

Above all, keep your eye on the main objectives, continue to review those and the risks throughout implementation - and measure results! Make sure you get what you need from the pain and costs involved.

Good luck...