Depending on the survey, up to 2 in 3 CRM implementation projects fail to meet their goals. Way back in 2015 I wrote a couple of articles (People and Process) talking about common pitfalls to avoid in CRM implementations. I thought I would revisit the topic because a key part of avoiding those traps is how the Discovery phase is conducted (or Story Refinement/Grooming and Showcases in a pure Agile project).
Let us review some of the pitfalls mentioned.
People: Recognition of a Problem
If an implementation is not addressing a recognized need in the business, it will be seen as pointless. It is very possible the people in the room for Discovery are not the people who gave the nod for the implementation. Communicating and reminding those in the room of the identified need (and who is endorsing it in the organization) is important for them to commit to the project. As mentioned in “Buy-In By the Executive”, having the Executive attend the Discovery/Design to show their commitment goes a long way in giving the consultant referent power to drive the project.
As well as recognizing the problem, as mentioned in “Definition of Success”, defining early what the solution needs to do is important. It is natural for a client, as they start to understand the system, to come up with ideas for business improvements. These should be captured but, if they are not contributing to the success measures of the project, they should be held off for “Phase 2”.
People: Use the Workshop to Generate Buy-In at the Coalface
Before we start a workshop, the only interaction a client has had with your organisation is through sales. While the consultant officially conducts Discovery/Refinement to better understand the business processes and how to address them with the software, they are also there to align expectations with what can be achieved if it is different to what was sold.
Having a demo system on hand to walk the client through how common processes are managed in the system (as opposed to how they may be managed in their previous system or how the sales person promised they would be managed) is a conversation that needs to be tackled as early as possible. Showcases for Agile projects provide a similar platform for familiarizing the ‘new way of doing things’.
As mentioned in “Involve the Dissenters”, understanding the political landscape and dealing with the curmudgeons early will prevent delays and sabotage later on. Also, as mentioned in “Make Sure it is Practical for the Users” ensuring actual users are involved (or in the case of Agile making sure the Product Owner is truly representative of the users) is key for adoption.
Process: Process Re-engineering is Inevitable and NEVER Replicate an Old Process in a New System
New software means a new way of doing things. This will always be true. If it was not true, there would not be much need for a new system. It can be tempting for users to insist the new system be as easy to use as the old system in all ways. This is a mistake. While the new system should address the identified issues (See “People: Recognition of a Problem”) this does not mean there will not be compromises. Again, the promise of a “Phase 2” to address concerns is a very valid option, rather than promising to meet all needs as part of the implementation, leading to a raft of Change Requests/additional User Stories and a blowout in time and cost.
Something which can be useful and getting the client on board with the necessary compromises of a new system are establishing Design Principles early on. Design Principles ensure there are a common set of principles the implementation will follow. Getting all stakeholders involved (Executives, Users, and Consultants) to agree on these early provides a reference point when design issues are raised.
For example, in the old system, a button on a form may be used when moving to a new stage in a process. It may be necessary to tick a box and hit save in the new system: two actions, instead of one, and a slightly different process. Design Principles will help come to an agreement on the right approach.
Common Design Principles include:
- Out of the Box before Configuration before Code: Keeping the system simple will make it easier to maintain and extend in the future
- Cost vs Benefit: If the button mentioned above is only pressed once a year and will cost the annual salary of an employee to develop, the cost will never be recouped for the benefit it provides. For any development decisions, the cost vs the benefit should be considered
- Decide who you are Designing the System for – Is it Management (optimized for reporting), Users (optimized for usability), or the Customer (optimized to delight): The answer can have a significant impact on how the system is built
- Capture only what you need: Capturing information as a ‘nice to have’ can bloat forms (and be in violation of privacy laws such as GDPR).
- Keep Security Simple: Hiding information without a sound business reason is a poor idea as it can lead to duplicate record creation and prevents visibility of processes across the organization. Similarly, enforcing security through coding is a recipe for a slow, unusable system.
In the case where Design Principles clash e.g. Out of the Box vs Designed for the User, if there is need for extensive development or a decision cannot be made, the decision can be raised through the project governance layers, opening up room for Change Request discussions or deferment to a later phase. This speaks to the need for strong governance to ensure project success but that is a post for another day.