Things to Consider for Your Salesforce Implementation

I’ve worked on many Salesforce implementations for many types of businesses and clients, here is what I have found is a pretty good recipe for implementation success. In this post I will discuss the various aspects of an implementation and things to consider if you are either embarking on a Salesforce project or are engaged in one now. While not all implementations are the same - clients, business processes, and project complexity can vary wildly - the “ingredients” listed below seem to work fairly well for a decent amount of small to medium size projects. (If you are an enterprise client with 1000+ users, you can stop reading now). Here is a high-level look at what your implementation might include.

Hire a Consultant or Take a Stab at it Internally?

Salesforce’s “clicks not code” configuration can often get people into trouble. It’s easier to engage a consultant as soon as (or even before) you secure your Salesforce licenses.  A mistake companies/organizations often make when using Salesforce for the first time is thinking they can just “turn it on” and start using it out of the box. Technically, that’s true - you could just login for the first time and start using the standard functionality. However, I don’t recommend it and here’s why:

• I’ve never met a company/org big or small that has such a generic business process that it can be met without any customizations.
• People often think they can start using the basic features and then, at a later point in time, engage a consultant when they’ve hit some limitation or need a custom feature. I can tell you, as a consultant, it is much more difficult and time-consuming (i.e., “expensive”), to fix a system that has been modified on an ad-hoc basis by an inexperienced admin then it is to do an implementation from scratch.
• If you roll out a system to users that isn’t ready and will need to be overhauled in a few short months, you’ll lose the buy-in and confidence of your users. Regaining their trust is no easy feat.

Before You Begin

As mentioned above, we recommend you engage an implementation consulting firm to discuss your business requirements. They will spend some time to understand your high-level needs and generate a scope of work. This will give you a sense of how much customization you’re process requires.  To find an implementation partner ask your Salesforce Account Executive, search on the AppExchange (*consider reviews), or just call Arkus (wink wink). Some partners specialize in different industries or verticals, so you’re better off with a consultant who has experience with companies similar to yours so that they can tell you how your competitors are leveraging the tool.

You’ll also want to get executive buy-in early on and you’ll want to put together an internal implementation team. The people on this team should be the most knowledgeable people about the day to day goings on of their business unit or department. This is very rarely the senior level people - what you want is the person who really knows the step by step process for the individual tasks. That’s not to say you don’t want executive leadership to share the vision of your desired future state, but high-level views are helpful to a point. This will make more sense when we dive into the next section - the requirements gathering.

Discovery Session(s) and Design

These sessions usually get the project rolling. You’ll hear Salesforce Consultants call these sessions different things - Discovery Sessions, Kickoff Meetings, Requirements Gathering - at the end of the day, they are the same thing: understanding the companies business processes.  As I mentioned above, not everything I discuss in this blog post will need to happen on every project, but *every* project should have a discovery session! This is where your consultant - if they’re good - will take off their Salesforce tech hat and put on their business analyst hat. These sessions typically involve the consultant(s) meeting with a member(s) of the different departments who will be using Salesforce and diving into the “day in the life of” to understand what it is the users do, how they do it, what they need to report on, what security is required, etc.  At the end of these meetings, you should a pretty good idea of the system requirements and desired workflow.

Once the functional requirements are captured the data model and general design will be laid out. This is where your project may go in two different directions. Sometimes a project requires the design to be documented outside of Salesforce, agreed upon, and then built. Other times you can start building directly in Salesforce and make adjustments to the model as needed. Both of these options work depending on the complexity of the business process, the timeline, and the consultants preferred method.

Building and Testing Your Salesforce Environment

Salesforce implementations are very iterative in nature. This means you’ll be shown several versions throughout the project and you’ll have a chance to test and provide feedback that will inform the next round of changes.

We recommend that you opt for simplicity in the initial rollout. Your consultant should help you understand when to build something custom, use a 3rd party tool, or hold off on a requested feature. As I mentioned before, Salesforce is a very iterative tool - it will evolve over time, way beyond your initial implementation so start simple.  Let users use the system and, after using it for a while, if they demand extra features, then consider it.

Data Migration and Reporting and Analytics

Data migration is a necessary step to rolling out Salesforce and can often be the most tedious and time-consuming deliverable for all parties involved. Historical data - clean historical data - migrated from your old system to Salesforce is one of the ways to ensure user adoption. However, it can often be a process of exporting from your legacy system or aggregating spreadsheets and other “tracking documents”, and mapping that data to the new Salesforce data model. You’ll need to decide how much historical data you want to migrate and whether the state of the data is decent enough to be valuable to your users.  Next, you’ll need to decide if you want to have your consultant do the cleanup and mapping, or if this is something you want to take on internally.

Because you own your data and know it intimately, it often makes sense for you to attempt the first pass at cleaning it up before passing it to your consultant. Often migration templates - an export of your Salesforce schema in an excel format - are helpful in guiding the cleanup and mapping.  Once the data is mapped, the consultant will load the data and have you do a thorough review to confirm everything was loaded to the proper place.

Reporting and Analytics are an essential part of viewing the data you’ve just loaded in a meaningful way. While the drag and drop reporting wizard is a powerful and easy to use tool within Salesforce, it can be one of the last things users feel comfortable with. So, having a library of pre-built reports and dashboards that users can access as they learn the system is a good idea.

Training

Training is often done over more than one session, as it is impossible to cover all of the functionality useful to the users while keeping the session duration at a length that keeps the users engaged and not overwhelmed.  I have found the most effective trainings are ones where the users themselves are moving the mouse themselves. This means a computer lab is required, or a conference room and individual laptops for each “student” so they can navigate the interface themselves.  However, this is often not possible and not always necessary. A follow-up training some weeks after the initial trainings is a best practice. After the initial rollout, instruct users to document their questions, requests, feedback and address them at a training or “lab hours” session at a later date.

After training, you might have “burn in support” or a service contract for additional hours of support post deployment. That is often a good idea, at least for the first few months and especially if you do not have an in-house system admin.  But, if not, at this point your users should be on the platform and the implementation complete. Although, as I mentioned before, the evolution of Salesforce is never “complete”. You will continue to tweak the configuration as using provide feedback and you’ll most likely add those extra bells and whistles.

If you have questions about your implementation or are considering embarking on this type of project, feel free to share them in the comments below in Discuss, on our Facebook page, or tweet them to me @StaciRiceNYC.