I just love all the time and attention that our clients and consultants are giving to user adoption these days. Ten years ago, we consultants used to have to describe user adoption to our clients, explain that it was their single greatest risk for project failure, and try to convince them that the efforts built into our budget and project plan to facilitate adoption were indeed vitally important to the success of their project.

But it seems we've turned a corner in the last few years, and I'm finding more openness to that conversation on recent projects. While this new openness is real progress - and it's comforting to find in our industry - the practical steps of assessing and addressing threats to solid user adoption remain obscure to many project teams.

Here are five data points that I think are worth evaluation for every CRM user audience. If we can assess and address each of these five issues early and often, building user adoption into our project lifecycle as a separate and distinct discipline, the total risk of CRM project failure will drop significantly.

1. Digital Natives vs. Digital Immigrants

A guy named Marc Prensky coined these terms back in 2001. Kudos to him! The "digital divide" is of primary concern to a CRM project team. If our users are totally comfortable with technology, our job in designing software that is easy to use, and training users to perform specific tasks, is that much easier. But let's not think in terms of black and white; it is useful to consider both the median, and the lowest reasonable or acceptable, techno-savvy represented among our intended CRM user audience. Next, let's allow that assessment to constrain and inform our design and training efforts throughout the project. (For more information on educating across the digital divide, see Marc's website at http://marcprensky.com.)

2. Collaborative and Virtual Workspaces

Has your user audience been working with data silos, or are they accustomed to the "pile on" nature of shared content and data? Facebook is a great example of a very pedestrian collaborative virtual environment. If your soon-to-be CRM users have lived their entire corporate careers working one user at a time on data stored in Excel spreadsheets, you may need to help them along the capability maturity model to realize that when CRM is introduced, they will be sharing data with many other users. How do they perceive that change? It may scare them, and it is your task to calm, soothe, and reassure them that a collaborative workspace is a positive change.

3. Relational Databases

Many of us take for granted the ability to watch as another colleague diagrams boxes and lines on a whiteboard, labelling the connections with one-to-many, many-to-one, and many-to-many tags that are in fact meaningless and complex to non-tecnical users. Your user audience may understand parent/child relationships within data sets when they are presented in the form of a report or print out, but may need your help translating that logical heirarchy onto the screen of a living, breathing, feature-rich CRM application. Don't take your own intelligence for granted. As CRM implementation consultants, it is our responsibility to close the gap between our soon-to-be CRM users and the nuances of the new software. Don't blame them if the relationship of a Contact to an Account is not second nature to them - they're new to the system. Look in the mirror - you built the thing.

4. Points of Pain

Moving away from the technical abilities of users, let's consider their expectations vs. what you are actually going to deliver. CRM users assume that you have made a promise to them - whether or not you have explicitly verbalized that commitment. They assume that if their company is investing time and money in this new system, that that same new system should make their lives substantially easier. It should provide a net gain in productivity for them. This is an entirely distinct user adoption risk that deserves serious consideration. For each user that will log into CRM, specifically which of their daily points of pain do you intend to eliminate in exchange for their daily use of the system? They assume there will be a quid pro quo. "I will use this system, keep the records up to date, track my stuff, and do my job using this tool. But, what's in it for me?" Can you answer that question, for each role you intend to support? The time to ask this question is before you begin to design the solution, while you are setting the overall direction for the project effort. A caution: Never bite off more than you are sure you can chew; ask for points of pain and priorities for them, and shoot for the low hanging fruit first. And another caution: Never assume that you know what the user would say without asking them; your arrogance would soon eclipse your ignorance.

5. Insight vs. Oversight

You know the Golden Rule, right? No, I mean this one, "The one with the gold makes the rules." Nothing could be truer in a CRM project. How often do we walk into design workshops for CRM, and the managers and executives in the room (the folks with the gold) begin driving our requirements towards improved reporting and data capture ("Those all should be required fields!") rather than focusing on removing bottlenecks and breakdowns for regular staff? When working with new CRM clients or delivering best practices seminars, I often point out that there are four types of stakeholders on any CRM project, and that their needs are often different, and sometimes conflict. Managers expect better data for reporting and forecasting; that makes sense, since a manager's job is to monitor and measure things. But end users expect real productivity gains from CRM, and they are far too often disappointed. In the heart of every sales rep I have ever trained to use CRM, they are begging, "Please... just help me sell more in less time." And for a support rep, "Help me resolve cases faster, with better customer satisfaction." Every CRM stakeholder could use better data, but we have to understand that data insight results in higher productivity, and data oversight results in more fields on every page in the software. There is an art to designing for productivity while still delivering data for measurement.

It is a mistake to consider user adoption as a late phase or effort in the overall project. No, user adoption is a thread that runs throughout the entire course of the implementation, influencing everything from hardware selection for users to cosmetic names of fields on forms.

This new and recent openness to proactively address user adoption during our CRM projects is comforting. But it is incumbent on us, as folks responsible for executing successful CRM projects, to leverage that openess and lead our teams to deliver substantial improvements on prior efforts. I'd love to hear your thoughts. Contact me here, at Webfortis, or online via LinkedIn at http://www.linkedin.com/in/crmconsulting.

Here's to your success!

Christopher Bates