And what you can do about it

Happy families are all alike; every unhappy family is unhappy in its own way.

The first sentence from Leo Tolstoy’s masterpiece Anna Karenina tells us that many different factors are present in successful marriages, but that missing even one of them can spell failure overall. Some refer to this as the Anna Karenina Principle, meaning an “endeavor in which a deficiency in any one of a number of factors dooms it to failure.”

CRM implementations are like that: they’re complex, and a lot of things have to go right in a successful implementation. But failure in just one area can doom the entire project.

What has to go right in a successful CRM? Here’s a short list, loosely based on an excellent article, CRM Software Implementation Success, on the site www.CRMLandMark.com:

• Obtain executive sponsorship
• Consider corporate culture in software selection
• Align processes of key departments and stakeholders
• Clearly identify software requirements
• Be careful and deliberate in your choice of the CRM software platform
• Clearly define the implementation’s business objectives
• Take a phased implementation approach
• Build in change procedures
• Begin training before implementing
• Recognize that the sales function drives most CRM implementations

In this article I want to talk a little about #6, the importance of defining an implementation’s business objectives. In my experience, a failure to clearly define objectives is one of the most frequent contributors to overall “CRM failure”. Although it’s probably more accurate in this case to refer to it as perceived failure: after all, if you never defined success metrics, then you didn’t define failure metrics either! [You'll find an interesting discussion of this point in the article, The Truth About CRM Success & Failure.]

These issues come up frequently in discussions of low user adoption rates. In order for user adoption to be “too low” or “just right” (could it ever be “too high”?) there must be a quantitative measure of it. So what is it? Well, one way of measuring user adoption is the actual use of the CRM, in terms of how often users sign in and how many records of various kinds they create. Salesforce.com even has an out-of-the-box “Adoption Dashboard” that shows things like this:

Of course, the problem with defining the success of your CRM by the number of times users sign in and the number of activities they create is that those things are measures of effort rather than results. They may contribute to a result, but they aren’t results themselves.

So what might those results be? Higher sales? Higher margin? Faster case resolution? Improved lead effectiveness? Being able to measure the impact of marketing campaigns on sales? Improved customer retention? These kinds of things are obviously going to be quite specific, and different in important ways for every business.

User Adoption v. User Satisfaction

“User adoption” is one of those terms that’s used a lot in a general sense, when it’s actually something else that’s being referred to. For example, I’ve had several conversations with customers lately about low levels of user adoption on the part of sales teams. When I hear a sales team has “poor user adoption”, I assume it means that opportunities aren’t being entered, sales forecasts aren’t up to date, and the sales pipeline reports reflect incomplete information. But it turns out that is often NOT the problem. Opportunities are up to date and reports are correct…but users are dissatisfied because the process of entering and maintaining opportunities is inefficient and overly time-consuming!

A problem like this one ties back in a number of ways to the top-ten list above. For example, “user satisfaction” might be a valid and measurable success metric for a CRM implementation. You can imagine a pre- and post-migration survey, with questions like the following:

How satisfied are you with the process our CRM requires you to go through to enter and maintain your sales opportunity information?

• Extremely dissatisfied
• Somewhat dissatisfied
• About averagely satisfied
• Somewhat satisfied
• Extremely satisfied

You could survey salespeople three months before a migration, and then a month afterwards, and if your survey results looked like the following, you’d probably need to take some corrective action!

The good news is, in situations like this there often is corrective action you can take!

To continue the sales team example, suppose the problem is that the opportunity form is too complex and has too many required fields for some users, but that it’s just right for others. This is actually a pretty common problem. Imagine two users:

• User 1: outside sales rep, a heavy-hitter closer type, just wants to get the basic information entered and close deals; doesn’t want to be “hassled with all the details” in the form of an overly complex opportunity form.
• User 2: inside sales rep, specifically charged with entering all those messy but important details the outside rep doesn’t have time for.

Who should you design the opportunity form for? If your up-front design process is too heavily influenced by the inside sales team (which it’s likely to be, since the outside team is too busy for design meetings, being out talking to customers and closing deals!), you’ll likely end up with a happy inside sales team and an unhappy outside team.

And no corporate family wants an unhappy outside sales team!

Role-Tailored Customizations with Form Scripting and Security Roles

In Dynamics CRM, customizations to the opportunity form – like adding tabs and fields, making fields dependent on one another, making certain fields required – are so-called “entity customizations”, and the Dynamics CRM customization architecture exposes the same set of customizations to every user within a single CRM implementation.

Basically, the problem is that each entity in Dynamics CRM only has one form: form customizations are stored as metadata in the SQL database, and every user who has access to the form will see the same one by default.

But there’s a way around this limitation by using form scripting to create a more role-tailored user experience. Basically, the technique is to check the current user’s security role when a form is opened, and use JavaScript to selectively do things like the following:

• show or hide specific fields, sections or tabs
• change which fields are required
• change default settings for certain fields or enter default values to save data entry time

In order for this to work, you need to use security roles to model the different groups of users who need a tailored user experience. For example, suppose in our example we’ve got custom security roles called “Outside Sales” and “Inside Sales”.

When a user assigned to the Outside Sales role opens an opportunity form, she might see something like this:

Two required fields and user provided revenue. Nice and simple.

Suppose a workflow runs when the record is saved, and the workflow notifies the appropriate member of Inside Sales that a new opportunity’s been created and requires more information and perhaps some research to flesh out the important details. When the Inside Team member opens the form, he sees a more complex version of the form:

Now the Inside Sales rep gets to enter all the detailed information he could possibly want on this nice complex version of the opportunity form.

I’ll provide a more detailed explanation of the technical details behind this approach in a separate, appropriately role-tailored article. But here’s a snippet of code, from the opportunity entity’s OnLoad event, that will give you an idea of how to do something like this:

if (UserHasRole("Outside Sales"))
  {

  //hide the messy detail on tabs or sections they don't need to see:

  crmForm.all.tab2Tab.style.visibility = "hidden";

  crmForm.all.tab1Tab.style.visibility = "hidden";

  HideSection (0, 2, "none");

  //For new records, set other default values to make things simpler and quicker:

  switch (crmForm.FormType)

    {

     case CRM_FORM_TYPE_CREATE:

       var currentdate = new Date();

       //put the current date + 7 in the estimated close date field:

       crmForm.all.estimatedclosedate.DataValue = currentdate.setDate( currentdate.getDate() + 7) ;

       //set default pricing method to user-defined:

       crmForm.all.isrevenuesystemcalculated.DataValue = false;

       break;

     case CRM_FORM_TYPE_UPDATE:

       break;

   }

}

The way I wrote the code to implement this, you can test it by adding or dropping security roles to your own user profile. For example, suppose I’m already assigned to the System Administrator security role. I can test the “Inside Sales” user experience by following these steps:

1. Click Settings, Administration, then Users, and select my user record in the list.
2. Select Manage Roles from the More Actions menu.
3. Check the “Inside Sales” role and un-check “Outside Sales”, then click OK to apply the changes:

   

Then I can flip it back – selecting Outside Sales and deselecting Inside Sales – to see what the less detailed experience looks like.

So, you can actually create a nicely tailored UI for your users, simplifying the experience for people who need it simple, and providing as much detail as you need to the people who need it. Then, after you complete your post-migration three month survey, you’ll see your one big happy corporate family represented in survey results like the following:

Notes & Links

A few comments and references:

• In my example, it’s not important that the two security roles have different security privileges. I customized the “Sales Representative” security role by renaming it to “Inside Sales”, then copied it to create the “Outside Sales” role. This is a slightly different way of thinking about security roles than what they’re usually used for; in this approach the key thing isn’t the specific privileges associated with a security role…it’s whether a user has a particular security role or not.
• I realize the approach isn’t perfect. The JavaScript can get a little messy, and obviously the more complex your role-tailoring requirements the more messy it will need to get. But for lots of organizations, the improved user experience will be worth the effort.
• I mentioned I’ll cover the form scripting details more completely in a separate article. In the meantime, if you look in the code snippet I included you’ll see a call to a UserHasRole function. I took that function and a related one, unchanged, from an article by Jim Wang (http://jianwang.blogspot.com/2008/01/crm-40-check-current-users-security.html ). Jim’s blog (http://jianwang.blogspot.com/ ) is one of my favorite places to go for solid technical details on Dynamics CRM.

In this article I focused on a relatively specific problem – user dissatisfaction – with a relatively specific solution. In future articles I’ll discuss other variants of the Anna Karenina principle’s application to CRM implementations. If you’ve got any good examples, let me know!