Phone: 020 3397 4870 | Email: email@example.com
Perhaps not entirely intuitive, but thinking about the analytics you will need the system to produce should take place early on in the project during the requirements gathering phase. Defining reports and dashboards is often left out or bolted onto the end of a requirements workshop which only captures cursory details.
The power of a well-designed CRM lies in its ability to provide you with answers to specific questions at the click of a button.
Considering analytics early on goes further than simply identifying the individual pieces of information you will store in the system.
Thinking about how to group, summarise and aggregate your information and how to highlight trends and exceptions should feed into the design process and influence how data is organised and inter-connected.
Looking at analytics towards the end of the implementation may lead to the solution having to be redesigned and rebuilt which is both time consuming and expensive.
This step may not be obvious but it’s really important. Clarifying terminology can be critical to the success of a project.
If stakeholders, users and consulting partners are using the same words but thinking different things, it is clear that work will progress down the wrong path and the end result can be a solution that does not fulfil its intended function.
For example, sales professionals usually request a report they can use for Forecasting purposes. However, Forecasting for one sales person may not mean the same thing as it does to another.
On the one hand, it could simply mean “what open Opportunities do we have in the pipeline”?
Alternatively, it could mean assessing which Opportunities are likely to close this month and evaluating predicted revenue against targets. Quite a difference in meaning. And a significant difference in the solution required.
Taking the time to check meaning in the context of the project can make the difference between going down the right path or the wrong one.
Sometimes one word has different meanings within the same company! Marketing may deem a Lead to be “Qualified” once certain criteria have been reached at which point they pass it across to Sales. If Sales have a different view of Lead Qualification, this can be a source of friction.
Stay alert and listen out for situations where people are talking at cross purposes.
Clarify key terminology at an early stage and keep this information up to date. Run through scenarios to check that everyone is using terminology in the same way.
Breaking up projects into bite sized chunks (ie phases) is a tried and tested way to increase your chances of CRM success. And yet, I have seen lots of requirements gathering workshops used as a brain-storming exercise to dream up as many ideas as possible. These ideas get written down and become deliverables within the specification document.
The result is a comprehensive list of requirements that cannot realistically be achieved and the project can be compromised before it has even started.
Clearly, if you are only delivering a relatively small piece of functionality, you can’t go too far wrong.
There are other benefits though.
Firstly, the initial chunk of work serves as an opportunity for the project team to get to know each other and gel. If you are using external resources, bonding as a team is doubly important.
Secondly, as the project progresses, priorities may evolve and new requirements may emerge. Small steps give you the chance to alter direction between phases.
Thirdly, users can start using the system sooner which gives them the opportunity to feedback ideas for further phases.
In part 4 of this series, we take a look at the topic of data. The importance of analysing, planning, preparing and testing.