After the Project is Deployed

In Best Practices, Change Management by Andy Yang

When beginning a new initiative, project leaders get all excited about what and how it should be built.  Teamembers also get excited about architecting the system and implementing the solution.  Yet, project leaders are rarely enthused about what happens after the system is launched — who is going to maintain and support the system and ultimately, who truly owns it.

In today’s world, no organization stays static for long.  New people come in, competitors come up with new challenges and the customer base’s needs change often.  This environment requires a nimble approach on a constant and ongoing basis.  It’s almost guaranteed that once you launch a new Salesforce process, you’ll want to change it — it’s expected, it’s inevitable, it’s unavoidable and should be planned for.

Once a Salesforce initiative has been launched here are a few things that you should consider:

  • Does it still have executive sponsorship (meaning an executive owner) who is vested in its success?
  • Is there a qualified resource who can own the management and administration of the system.  Does this person (or persons) know Salesforce well (have they been certified?)?
  • Are there proper steps in place to increase the adoption of the system?  Are there processes in place that get people to use the system (e.g. reports that drive compensation, status meetings, etc. that require data to be in the system)?
  • Is it ingrained in your process in a way that it would be be painful to not use?
  • Is there a roadmap in place – a vision of where it needs to get to (so that future changes to the system align to the overall goal)?

Executives are busy and “hope” is not a strategy.  It’s a given that:

  • Adoption will be an issue.  Once people are trained, do not expect full adoption.  Increasing and maintaining proper use of the system is an ongoing process.
  • Requests for changes to the system will be needed. These will include the usual administration type of requests as well as more significant functionality/process changes that will occur.
  • The business will continue to morph quickly and the infrastructure will lag.
  • The system will be continuously evaluated – should we buy versus build, should we rearchitect, should we evaluate a new system?
  • New opportunities can be pursued.  Once the fixed investment has been made, the incremental investment in other areas seem more attractive.  For instance, once a company invests in automating their sales team with Salesforce, the incremental cost of putting the Customer Service/Support team on Salesforce is more attractive both financially as well as from a feature/function/visibility/business value perspective. Wouldn’t it be great for Sales teams to instantly be able to see all the support cases their customers are logging?  In addition, the information collected during the sales process can seamlessly be accessible to the Customer Service team.

When planning change, make sure that you are also planning for the “post change” process.  Many companies clearly underinvest in this area which can create the situation where the project launch is highly successful but the project ultimately fails.  It’s not cheap either.  Some companies have tried to cobble this together last minute, for example:

  • Making the VP the Salesforce administrator.
  • Taking an already fully loaded team member and make them the admin even though they don’t have much training in Salesforce nor have the time to do any administrative tasks.
  • Paying a consultant to lead and complete the project but not investing any hours in any post launch activities.
  • Removing executive sponsorship and giving ownership to an under-empowered sales operations team-member.
  • Having a “if we build it they will come” attitude fails in both the marketplace and also for internal systems.