Five Challenges of CRM Projects

When implementing an off the shelf, CRM solution, organisations carry the mind-set of purchasing a product, much like buying a car. Whilst you are indeed purchasing a tangible product, the journey is completely different. Here are several misconceptions which disrupt the implementation of a CRM solution in an organisation.

Note: Data migration has deliberately been omitted from this list, I will explain in a later post.

Estimates are deadlines: CRM solution providers are expected to provide quick estimates, for delivery timeline, right from the start. This forces the solution providers to make assumptions around complexity, functionality and usability. To win the bid, solution providers assume the simplest solution and provide a competitive estimate. However, when implementation process starts, every aspect of software development is engaged, and detailed analysis reveal complexity that was unaccounted for in the original estimates. Nevertheless, solution providers are expected to deliver according to their estimates, treating them as deadlines.

estimate2.png

We know what we want: At the start of a CRM initiative, organisations build a list of requirements. These requirements or list of features highlight what is considered necessary, at that time, for a successful implementation. Some features do not necessarily aid the user journey, reduce complexity and consider the importance of the requirement in relation to the overall organisations goal. Additionally, when solution providers dive into the details of each requirement they uncover several system and project dependencies. These features often, not aligned with the overall goals of the project, pull the project towards a new direction.

 

Automation improves efficiency: Organisations want more automation at a reduce cost with an expectation to improve efficiency and output. Automation does improve efficiency where lengthy processes, cause delays, derail the flow of information and stretch the decision-making process. Automation is justified where there is a high cost of human error. However, automation for the sake of automation, makes the user journey more difficult to manage, takes control away from the end-user, and consumes a lot of development effort and time.

 

automation.png

Management is always right: Management compiles a feature set based on a “To Be” vision. However, daily responsibilities do not allow end users to be fully engaged in the compiling process for requirements. When these users are eventually engaged, in implementation of the “to be” vision, gaps are discovered. Additionally, lack of awareness of the “to be” goals also derails the information flow and creates additional work for the developers. In these situations, organisations tend to quickly jump to the path of least resistance, and try to build a solution which retains legacy functional behaviour and the developers are forced to build on top of existing functionality. Alternatively, the business ends up adding new high priority stories or features to the product backlog which adds to delays in releasing the software.  In the end the developers are left to blame for delays.

Users will do as told: Management is usually busy with removing conflicts to business, increasing productivity and making decisions. This leaves little time to fully appreciate the pains of customer engagement. Emphasis is placed on reporting, analytics, data capture and structure of the application. Ignoring the true driver of those elements i.e. the process associated with the capture of this information therefore, leaving user experience and user journey as somewhat of an after-thought. This builds an impression amongst the users and stakeholders that, the business is leaning to accommodate the applications functionality.