Change Management is the very necessary process that your company uses to ensure growth without chaos. With Salesforce, change could result from any number of things, such as: organizational changes, business process changes, adding or removing processes, modeling modifications, new Salesforce releases, introduction of new custom applications, or integrations. Whatever causes the need for change, the change must be managed through the process of change management. Your Salesforce Administrators need to identify, prioritize, assign, execute, and communicate change to your employees to ensure orderly success.

Managing change in an on-demand environment is similar to a traditional IT client-server environment. However, there are some important differences to point out with respect to change management that Salesforce Administrators should be aware of. You must understand the key concepts and best practices around managing change within Salesforce in order to effectively and efficiently manage your organization’s application.

Defining a Change Management Program

A well defined change management program is about continuous improvement. Start with a well-defined vision and strategy that identify the overall goals that you are trying to achieve. After establishing your vision and strategy, you must continually initiate and plan various projects that support your program. The Salesforce application does some of this for you with feature releases; however, it’s important that you continually collaborate with your end users and executives to capitalize on opportunities to build new applications or customize functionality that improve the user experience and help drive adoption. Next, you must operationalize the key functional components and continually validate your results and correct the course if and when necessary. The main points for a successful change management program are:

  1. Vision & Strategy – Establish a change management program that defines a strategy to achieve objectives to ensure progress.
  2. Initiate & Plan – Identify key Salesforce capabilities required to tie capabilities to the change management program objectives and develop a roadmap to implement changes.
  3. Operationalize – Build, configure and deploy applications using the on-demand release management approach and drive adoption of new features and customizations.
  4. Validate – Continually monitor performance metrics, audit your data and use these results to drive behavior or process change within the organization where appropriate.

Implementing Change Management

Once you have established a change management program, you can use the following change management implementation steps to increase your success when implementing change requests for your Salesforce environment.

  • Collecting Change Request Ideas
  • Analyzing & Prioritizing Change Requests
  • Configuring, Implementing, & Testing Change Requests
  • Developing an End User Communication Strategy

Let’s explore each of these points in more detail.

Collecting Change Request Ideas

The first implementation step is to collect ideas and requests from your users on what functionality they would like to see in use with the Salesforce application. Creating an outlet for users to submit requests is a crucial part of adoption. Without an outlet, many users may look for other avenues to solve their problems and abandon your Salesforce implementation. Salesforce offers three best practice tools that I recommend for collecting change request ideas.

Salesforce Chatter

Creating a Chatter group, called Salesforce Change Requests, for example, to solicit feedback from your user base is another great method you can employ. Chatter is like Facebook for the Enterprise. Because Chatter is a real-time collaboration tool in the Cloud, it can provide secure and instant real-time information in a Facebook like user interface. It is built on top of the robust and secure infrastructure. Users can join your Salesforce Change Requests Chatter group and post change request ideas and comment on other posts. All message posts are available as a feed that your Salesforce users can subscribe to.

Salesforce Cases

Cases are another great way to collect feedback from your internal users. A user can submit a case with the details needed for their request. However, if you are to use this technique, I recommend that you create a Case Record Type for internal enhancement requests, so that external support requests aren’t intertwined with other case requests, such as external customer cases. Creating a Case Record Type also helps when filtering list views, as well as reports. With this technique, the administrator or the change management committee needs to appropriately evaluate the request using Salesforce’s built-in reports and dashboards to monitor the number, type, frequency, release schedule, etc. of the specific requests.

Salesforce Ideas

Depending on your Salesforce edition, the administrator can configure Salesforce Ideas to provide a quick and easy way for your internal customers to suggest enhancement requests. When a user submits an idea, other users can review and vote on the ideas they like best with the top voted ideas bubbling up to the top of the requests. Thus, you can use this as a means to have your users drive the priority of their requests. The administrator or change management committee can interact with the user by posting comments to the idea request. Having two-way interaction creates a collaborative environment and provides an avenue for the users to voice their needs. Salesforce uses this very technique on their IdeaExchange website to request product ideas and feedback for each release.

These are just a few examples you can use to help manage change for your Salesforce environment. Using the same tools to manage your internal user base as you do for your customer base will show your employees your company’s commitment to Salesforce. Users tend to adopt Salesforce quicker if their voice is heard though various communication channels, such as Chatter, Case, Salesforce Ideas.

Analyzing & Prioritizing Change Requests

Analyzing and prioritizing change requests should be done by a Salesforce change management committee which meets on a regular basis to discuss and schedule large, complex enhancement requests. The committee should be a cross-functional team with members representing both the administration and cross-functional business units that utilize Salesforce. A well-defined committee ensures that changes likely to impact the entire Salesforce environment, such as changes to global settings or organizational business processes, are discussed and assessed properly. Everyone involved should understand the impact to their individual business units or processes.

In addition to reviewing, prioritizing, scheduling and approving requests, the Salesforce change management committee should be responsible for monitoring the overall application usage, evaluating key metrics, and developing tactics to drive and maintain user adoption.

Configuring, Implementing & Testing Change Requests

Managing a client-server environment differs from managing an on-demand environment. In the old client-server model, companies and organizations spent a significant amount of resources and time to build out development, test and staging environments in order to develop and test their changes. Luckily, Salesforce provides an on-demand sandbox environment. Depending on your licensing agreement, you can configure one or more separate sandbox environments at the click of a button. Refreshing a sandbox environment is as simple as clicking a button as well. Salesforce permits sandbox refreshes every 30 days in order to keep your test environments synchronized with production.

I do recommend that all companies, large or small, use configuration or developer sandboxes for development and test environments and use full sandboxes for their staging or training environment. Configuration and developer sandboxes provide a copy of all production application and configuration information. Thus, records and data are not copied to your sandbox environments. Using configuration and developer sandboxes provides you with an extra security layer for your data to prevent unwanted eyes from viewing sensitive information during the development or testing phase of the project. In contrast, I do recommend that full sandboxes be used in the staging or training environments so that end users can validate the changes using their own user account and profile. Using full sandboxes ensures that the new functionality is developed and configured correctly and end users can complete any necessary training before deploying to a production environment.

You should follow the sandbox methodology when making changes to the following items:

  • Workflow and approval processes
  • Role hierarchy
  • Sharing rules
  • Territory management
  • Integrations through Web Services or Data Loader
  • Apex Code or Visualforce enhancements
  • Building custom applications

After all testing is complete, use the migration tools that are provided by Salesforce to migrate the changes – or migrate them manually if the changes are not part of the Metadata API or simple enough that a specific tool is not needed to help migrate.

The Eclipse Integrated Development Environment (IDE) delivers a fully integrated development environment that developers can use to interact with Salesforce application customizations and custom applications programmatically using the Metadata API. The IDE can be used to manage the process of migrating changes, customizations, integrations and custom applications between your development, testing and training environments. I also recommend leveraging Salesforce Change Sets to help automate the migration process for your environments.

Developing an End User Communication Strategy

The Salesforce change management committee must have a training strategy that includes new Salesforce users, as well as on-going training to support the evolution of new features and configurations as the company grows. Consider supporting multiple groups, different roles and learning styles (sales representative vs. technical consultant) in your training strategy as their needs will differ. Lastly, consider capitalizing on various media and vehicles to deliver training or information to the end user, such as instructor-led training, webinars, newsletters, tips & tricks notifications, or homepage messages and alerts.

It's only fair to share...Share on LinkedIn
Share on Facebook
0Tweet about this on Twitter
Buffer this page
Email this to someone