Every business must adapt quickly to adjust to market conditions.  Change is always afoot and must be managed carefully to minimize disruption and to enable your organization to capitalize on new avenues for improvement.

The Salesforce platform is ideal for such an environment because it can be constantly tweaked to provide continuous advantages to the organization when they need it most.  Salesforce’s rich feature-set also enables companies to turn on the pieces they need when their organization is prepared to take it on.  At the beginning you may not need fancy, automated quoting but it’s there when you are ready.  In addition the AppExchange enables customers to use third party provided technologies that specialize in certain areas where Salesforce native features hit a limit.

Change can be very disruptive and can hinder progress if not managed carefully.   There are whole books written on change management – it can be an incredibly complex process with many paths to success and failure.   Suffice to say everyone wants it done right the first time.  There’s only so much political capital that one has to spend.

Here are a smattering of ideas to consider before instituting any change in the system and process:

  1. Always line up executive support in any change management endeavor.  The executive sponsor can help ensure you get the resources you need and run cover for you on all of the dependencies you will need to manage.  Executive leadership
  2. In assessing any change, always measure the level of complexity of the change.  How technically difficult is the change?  What changes to the process are required?  Always strive for simplicity as it is a common mistake to over-engineer a solution.  Document the steps needed and have a plan with every participant that may be affected.  There are lots of tools used to track and manage change management processes.  Some changes can be categorized as minor and others as major – they each need to have a different type of plan associated with it.
  3. Test.  Releasing a system into production without testing is a recipe for failure.  Testing is a critical part of being prepared.  Testing works out most of the technical bugs and helps you exercise any changes to the process so that it minimizes disruption.   Salesforce has sandboxes that enable you to test changes in a safe environment – where you can try to break the system before your users do.  It’s always a best practice to test in the sandbox before rolling out to production.  Various sandboxes are available.  While it costs more, a full sandbox enables you to perform testing on a copy of your real data.  If you don’t test on real data you can expect that a problem might arise once the changes hit real data.  If you don’t test for scale, you can expect that a problem might arise when faced with production level traffic.  It’s all a matter of trading risk with cost.  Of course you can never test for every scenario but there can be a level of risk that you feel comfortable with.
  4. Create a pre-release group.  You always know who your best users are.  They are the ones that use the system the best and most frequently.  Not coincidentally they make great testers that can help you not only optimize your system further through their feedback, but also to help be your champions as you roll the changes out.  They can help answer questions and be your supporters in any of the under the radar communications that are going on during the change management process.
  5. Create a back up plan.  Examine what steps you can take to roll back changes if a curve ball is thrown in the situation.  Data is typically the most dangerous area.  If you are merging data or modifying in such a way that you can’t turn back, then create a “rollback” plan.  Back up data so that you can easily return back to the original state.
  6. Training – when the switch is turned on, it is difficult and costly to turn back.  Make sure all users are trained properly.  Ideally, if the changes are significant enough, users can be trained onsite or remotely.  Training can be recorded and made available.  A quick reference guide can be a quick and easy way for users to get up to speed and be a resource for training new people who may come on board afterwards.
  7. Create a communication plan.  People affected should know what is planned to happen, when it will happen and also documenting issues as it happens.  Make sure a central point of contact is established – it can be an email alias, it can be a specific person.  Establish expected response times  and an escalation procedure.
  8. Line up your help – and when you need the help.  During the rollout various people need to be “on call” for issues that may arise. Make sure that if a rollout is after hours that you have the right support lined up.  This support should continue after the rollout as well for some time period.  As users start to bang on the system, expect use cases that could not have been envisioned during testing to occur which may cause problems.  Make sure there are no holes in coverage.
  9. Rollouts must be planned.  In many cases, there needs to be a specific stopping point where data must be “frozen.”  This enables data migrations to occur without compromising data integrity.  It’s not uncommon to have the sales team stop inputting data on a certain day (Thursday night) and have the team not input or modify any data until Monday.  Rollouts should also occur during less sensitive times.  Making a system change, no matter how small, a day before the quarter ends is usually not a wise move.  Usually the best time is the few days right after a quarter ends or sometime during the quarterly sales kickoff meeting where team-members are usually not expected to be online as much.

Change management can be very risky but is a necessity in enabling a business to adapt to its changing environment.  Not surprisingly, many of the most successful companies are the ones who can capture opportunities through change most effectively and efficiently.