successful crm rollout: from planning to implementation

Without knowing the system from an administrative perspective, it is easy to make an incorrect assessment and thus to implement requirements incorrectly. In many cases there are requirements that can be implemented by the standard administration or set-up of the system with just a few clicks.

 However, if this is not known, an unnecessary amount of resources is put into the programming of the requirement. Ultimately, it is possibly even implemented in such a way that other functionalities are thereby prevented or hindered. Depending on their roles, all project members should be required to attend trainings on the selected system to ensure that they have basic system knowledge – including from an administrative perspective – before the implementation starts. That way, unnecessary additional work can be avoided right from the start. To guarantee sufficient system knowledge, especially for more complex rollouts, it is advisable to bring an employee of the company of the selected crm system on board of the project team, who can be approached if questions arise and who supports the requirements assessment.

Within the implementation process, the individual stakeholders, e.g. different business units, market managers, end users, control the requirements for the system development. If there are no clear rules for the management of requirements, the individual stakeholders will make uncoordinated and wild contributions. In addition, short-term changes can occur within the requirements prioritization if no clear rules and responsibilities are defined. Sooner or later, this development not only leads to excessive demands and frustration of the development team, but also to dissatisfaction of the requester, because the requested functionalities are not implemented on time.

To avoid this, a central requirements management function must be implemented to qualify, quantify and prioritize the input of stakeholders. Furthermore, many of our customers have good experiences with the kernel approach, i.e.: 80 percent of the system functionalities are standardized and therefore cannot be changed. Whereas the remaining 20 percent leave room for market and user specific functionalities. This of course requires a certain basic understanding of user needs and system requirements. Because even with standardized system functionalities, it must be ensured that these cover the most important user stories (most important features from the end-user's point of view).

Agile requirements management offers promising approaches for this. These help, for example through user story writing, requirement breakdown and pre-definition of acceptance criteria, to describe the requirements in an understandable way. Furthermore, decisions regarding implementation and its planning or non-implementation are made easier through agile prioritization techniques (e.g. magic prioritization) and "definition of ready".

The involvement of stakeholders follows the motto of finding the golden mean: On the one hand, the stakeholders from the various areas concerned must be involved, on the other hand, they should not blow up the whole process by placing too many demands. Expectation management also plays a decisive role here, since the requirements management process is put under a lot of strain when there are too many different requirements. And after prioritization, implementation may only take place later or not at all. 

This must be communicated to the stakeholders within expectation management (we’d recommend this to be part of an overall change management function within this project). In other words, it is important for the requester to know the requirements management process and how to adequately place requirements, as well as to get transparency about the evaluation and timeline. If requesters only find out by chance that their demanded functionalities are not implemented at all, insufficiently or too late, the motivation for the project and consequently the use of the system decreases. In addition, completeness in the selection of stakeholders is a critical success factor, since excluding or forgetting important stakeholders can have serious consequences in retrospect. Often the mistake is made that stakeholders who either work with the system only rarely or only at a later point in time after the system has been implemented are not included in the definition of requirements. However, the required functionalities are often also related to the core functionalities of the main user group and therefore high costs can arise due to necessary ad hoc reprogramming.

Therefore, we for example recommend defining a stakeholder map in an interactive workshop with different project members right at the beginning of the project. With the help of this stakeholder map, different stakeholder groups can be identified and consequently the respective communication measures are defined and scheduled in a Communication Roadmap. The risk of project rejection is considerably reduced by keeping the relevant stakeholders informed and, if necessary, by involving them.

Many complex systems do not necessarily convince with an attractive and intuitive user interface (UI). New users are therefore often overstrained and unmotivated as soon as they open the system. Sometimes, however, it is small things that boost acceptance. For example, if possible, the company CI including logo should be used so that users identify with the new system more quickly. In many cases the system complexity can be reduced without much effort. It might only be necessary to ask whether click paths can be optimized or the UI can be simplified. It should only be possible to see on the screen what is really needed. Often a third address field or similar can be hidden easily. For an initial simplification, less frequently occurring cases and functionalities should only be tackled after the successful go-live.

In addition, if certain cultural aspects are taken into account for the intuitive use of the system, it is easier for users to become familiar with the system and thus use it more quickly and efficiently. Examples, such as the fact that in Spain the house number is always entered before the street name, or that in the Netherlands a name suffix such as "van" is entered, are relevant for the correct use of the system and ultimately also promote acceptance.

Haven't we all experienced this before? We just took part in an Excel training course, and we were able to use the formulas very well during the course exercises. Three weeks later we stare at the Excel spreadsheet and don't know how it works anymore. Why should we? We didn't need the formulas the last three weeks. That's why we recommend training the users on the new system immediately before the go-live. And first of all, the basic functionalities should be trained. Just like in the Excel training: What may seem simple during the training, will, after too much time between training and go-live, no longer be used or even remembered when working with the system. According to the "forgetting curve", about one week after the training we have a retention rate of only about 20 percent.

Therefore, what has been learned does not only have to be repeated and applied, but more sophisticated functionalities should only be trained after the go-live. And this advanced training should be based on the level of knowledge and the work area of the individual employees (or the different user groups). In our experience, the users of a new crm system learn the functionalities best and fastest by trying them out directly in the system. Of course, this only works if they can't "break anything", i.e. either in a test environment or in the productive environment only with appropriate guidance and ideally for real scenarios. The latter can be easily achieved with the help of digital adoption platforms such as WalkMe.

Now the users have just understood how to use the new system and then they wake up one morning and there are some changes in the system. Frustration and rejection returns. To prevent this, you should communicate new functionalities of releases in time and train them if necessary. Here, an integrated Digital Adoption Platform helps as well. Functionalities of new releases are stored there early enough, so that the users are not discouraged. On the contrary, thanks to Digital Adoption Platforms, they are simply guided through the respective new functionality directly while using the system. The times after new releases, when the support hotline is flooded, are over. Other possibilities for timely communication of the new features are, depending on their scope, webinars, short how-to videos, info e-mails with short instructions or the use of "change agents" as mediators and on-site support.

Through our partnership with the Digital Adoption Platform "WalkM" and our extensive experience in system rollouts and change management, we look forward to advising you on your questions and problems. Please feel free to contact us.