Making technology changes in any business is an uncomfortable process; financial advisory practices are no exception. Over the years I’ve come across lots of FSPs changing software, for a variety of reasons, but I’ve come across very few that have approached the exercise with solid planning. Large institutions often embark on a formal process of requirements gathering through RFI, RFP, analysis and vendor selection, but smaller businesses typically don’t have the time or the specialist resources for any of that. Making the right technology choices is equally important to a smaller business, though.
Whether you’re looking to change because your current solution has been discontinued, or because your needs have changed or simply because there are newer, greater products on the market, it’s never a good idea to make snap decisions or to implement a new system without a thorough investigation.
In my experience, many practices follow a process something like this when choosing new software:
- Find out from peers what they’re using and whether they’re happy.
- Contact all the peer-recommended providers and arrange for demonstrations.
- Ask questions during each demo centering primarily on list of gripes with the current solution.
- Make a decision based on (a) vague recollection of the functionality and interface, (b) the quality of the demonstration and (c) cost.
- Gasp at the business interruption, the database migration, the implementation, the support, the absent functionality, the unexpected limitations, the lack of similarity to the discarded solution and, of course, the cost.
Out of the thousands of reasons this really isn’t a sufficient analysis, here are a handful to chew on:
- Business interruption is guaranteed – there’s no such thing as a painless transition – so you need to make the right choices to avoid having to do it all again changing to something else a few months later.
- By the time you’ve seen the last vendor’s demo, the first one is but a hazy memory and a few scribbled notes.
- Your fondness of the presenter has absolutely no correlation to the suitability of the software.
- A pretty interface isn’t a good indication of functionality or usability.
- The fatal error of assessing a solution for its ability to clear your list of gripes with your current tools instead of analysing it for suitability to your requirements.
- The fact that your peers love it does not necessarily make it a foregone conclusion that you and your staff will love it too.
- Poor analysis results in nothing other than poorly aligned expectation and reality.
- A software demo is an overview and a sales pitch, not a training session. What you see in the demo will not sufficiently prepare you for your daily operational life following implementation.
Some guidelines for adding a bit of objectivity to your selection process:
- Run a quick survey throughout your business, asking a few probing questions about what’s currently working, what’s not working, what the expectations would be of a new piece of software and so
on. This will not only provoke thought and encourage a sense of team effort but will also help you to drill down to the real issues as well as keep in mind the areas that are actually working well in your current system in order to maintain those standards.
- Talk to as many peers as possible, not just those closest to you, asking for details about their experiences of both software and support, and make notes. Research vendors and their products online wherever possible.
- Document a list of business requirements, asking as many staff members as possible to contribute. Think about practical things, not just a list of CRM fields (which, by the way, are all pretty much standard across any CRM package throughout the world). Consider topics such as integration with other systems (such as Astute or Outlook), desktop vs web, customisability, predefined workflow processes, output reporting, management information, investment value data feeds, manipulability of financial planning calculators, user-friendliness, mobile capability and so on.
- Create a diagram of all your other internal systems and tools (including spreadsheets and manual processes) when compiling your requirements and consider whether any of those could be replaced by or integrated with a new
system, bearing in mind that chances are slim that you’ll find a single product that can replace absolutely every other disparate system or process in your business. Think about everything from your new business register to your leads management, advice process and commission reconciliation to your document storage and task management. Ideally, you’d need as many systems as possible to be able to ‘talk to each other’.
- Prioritise your requirements and decide which are critical, important or just nice to have so that you don’t get bamboozled by the amazing things you will see in the upcoming demos and have something to help you stay grounded and realistic.
- Use your list of requirements during every demonstration to make sure that you don’t forget to ask any questions and also to rate and score each listed requirement for suitability
- Make sure that key staff members attend demonstrations and that the decision is not just left to one individual – it’s important that needs are met across the breadth of the business and each person will view the solution from his or her own specific perspective
- Ask vendors about more than just functionality, making sure that you gain a fair understanding of the implementation and ongoing support processes as well as the stability of each vendor and any pcoming strategic changes they might be planning
- Create a case study or two, using a familiar and complicated client or process, and either get demo access to each system or ask the vendor to spend some time running through the scenario with you. This will enable you to assess each solution quantitatively for its ability to produce a result from the same set of criteria.
- If you’re out of your depth, call in some expert advice! Engage with consultants who are familiar with the industry, have experience with multiple software vendors and products and are practiced in eliciting business requirements and managing a rigorous selection process.