In our last post (located here), we looked at how both management and users can view a CRM implementation that can encourage adoption. In this post we're going to focus on some real-world tips and traps that drive user adoption.

Early Involvement of the end-users is critical towards project success and adoption

Tip: Encourage (if not require) a client Project Manager - Involvement of the client is more than simply approving invoices - it is the early adoption and acceptance of the software and designed business processes. We occasionally see (but have not been involved in!) failed implementations because the client was sold on the idea of CRM and all its great features, but were either too busy to be involved in the project or simply wanted the software to just show up on their desk. It is critical to get a Project Manager/stakeholder involved in the process early in the process.

Additionally - the more end-users that can be involved early in the process can result in a higher earlier acceptance. 

Trap: Be sure the client Project Manager has an appropriate role in the organization - It is not enough to simply be a member of the organization - the Project Manager needs to have sufficient knowledge, experience and desire to be able to drive the project.

Additionally, be sure any early end-users have appropriate time and responsibility to work on the project (we normally recommend the creation of a checklist that allows users to go through to verify functionality and/or report issues during initial reviews).  

Be sure to include business processes that make users work smarter - not just because they are used to them

Tip: "Just because we always do something, doesn't mean we need to continue to do something" (however it might!) - During a recent implementation analysis, a user identified one of her business processes as 'printing the lead out and having A/R review it for credit worthiness'. She mentioned that this was a required step and one that absolutely needed to be included in the new software. When we suggested that instead of printing the lead, we could create a workflow that sends a review activity to the A/R department (without having to print), she thought for a minute and said that won't work. When questioned further about it, she identified that the A/R department was not scheduled to be included as users until the second phase, so their ability to review without the printout was not an option (at this time).

Her observation was correct, and we recommended either including the workflow in anticipation of when A/R receives their licenses (and still printing), as well as suggesting having at least one member from A/R in the initial phase to test the modified business process (they chose to go with the modifying initial requirements and include Stan from A/R in the intial phase).

Trap: Be sure to THOROUGHLY review existing business processes with CRM tinted glasses - When reviewing business processes, we always think about how the process can be improved with CRM, while not over-engineering a solution.

During a review/analysis phase, we are always careful to remember that it is easier for us to understand a clients business and business process then it is for them to understand CRM. 

Clearly establish and agree to the scope of the project, including the budget, timeline and resources required (both from the consultant and the client organizations) early - Be sure that all users are aware of what and when they will receive with each deliverable/phase 

Tip: Keep your eyes on the overall project, but focus on the phase at hand - It is rare that an enterprise application such as Microsoft Dynamics CRM isn't implemented in phases (these phases are usually broken down into the following:

1) Envisioning, 2) Planning, 3) Design, 4) Deployment, 5) Training, 6) Support *

(with several sub-phases as necessary given the requirements)), and users can be quite myopic about what they're exposed to. This can be both good and bad in that their expectations need to be managed appropriately (a good example is a user who won't see their customizations until after a later phase is forced to use the system without 'their' features yet).

The best way to succeed is to have full exposure as to what is happening and when. Phases are very important in that short-term obtainable goals are achieved and mutual objectives are accomplished over time. Additionally, when working with companies that utilize SCRUM project methodology (such as Webfortis), phases allow users to get in front of the product as quickly as possible - which generates feedback and involvement in the final product (early input can be incorporated into later design/customization phases). 

* Microsoft has a good link on these Milestones located here

Trap: Always set appropriate expectations at the beginning -Whenever we perform a Needs Analysis, we discuss the project, what CRM is and what it can do prior to discussing requirements. This is important to share so that the analysis is revealing about CRM type functions, however it is also important to mention that our goal is to improve existing processes by introducing CRM - and not everything discussed and/or reviewed will necessarily be approved by management, nor be feasible for initial implementation.

If users aren't aware of what they're involvement will be (or why), they will be less likely to contribute and share in the benefits during deployment.