Everyone wants CRM implementations to succeed in the first attempt. Yet, a surprising percentage of them face huge delays or failure.
Having spent two decades implementing CRM solutions globally, and having learnt much working on various implementations with customers and other partners, it is time to share key learning which will help customers and partners embarking on new CRM initiatives.
In this series of videos and blogs titled ‘A peek into a CRM implementation’, we will cover various topics.
The topic today is ‘Is it possible to avoid the ”Oh Shucks, this is not what we expected” moment when Business sees finalised system for the first time?’
We face this in varying degrees where Business expectations are totally different from what has been built by the project team.
There is a point in every CRM implementation after which things settle down and the project starts delivering the desired value. We call this the ‘project inflection point’. This is crucial; the project success largely depends on how quickly this point is reached.
This is the point when the implementation partner genuinely understands customer business and the business team providing the requirements to gain an appropriate understanding of the emerging software solution. This fact is often missed and becomes a major problem.
Once this point is reached, assuming that the implementation team has the right skills and intent and the business representation from the customer team has right executive support and is sufficiently empowered, the project accelerates and the team adds value rapidly.
Delays in reaching this point pose the risk of miscommunication on what customer envisaged and what the implementation partner assumes needs delivering. The reason is most of the initial scope is captured in written words, subject to interpretation by both parties. This causes conflict as the customer tries to protect the budget and the implementation partner tries to protect margins.
The project inflection point can be reached quickly with the right implementation methodology.
Upfront investment on the project, training the core team of business users on the new software so they understand its architecture, data model and transactions will work well to improve this issue. Promoting familiarity with the look and feel of the software is crucial for user adoption. This is also the right time for the change management team to emphasise adherence to standard solutions if implementing a packaged software solution.
At the same time, it is worth investing time, getting the partners’ consultants to understand the business, interact with the business, almost to the level of understanding daily tasks and activities.
This substantially bridges the understanding gap and sets the boundaries for the project.
Furthermore, with increasing adoption of Agile methodology, the project teams can now validate build regularly with the customer team. Business representatives and key stakeholders must be involved in this validation.
Project teams are often reluctant to spend substantial time in training upfront since projects are always constrained for time. But consider this – when the consultants deeply understand the business and the Business team genuinely understand the software, it will reduce delays down improve acceptance of the software once delivered.