There are a lot of great blogs out there that focus on Salesforce.com. I know this because I actively read many of them. Most are written with a focus on development and administration, with technical code sharing and feature explanations. This type of information is certainly a great benefit to me and many others and I’ve personally learned a tremendous amount from the development community and will continue to do so. But what about the “softer” side of Salesforce consulting?
Anyone who has experience working directly with clients knows that it’s not always about the technology. Having a well-architected solution certainly may include the need for significant customization, or advanced VisualForce and Apex programming, or external system integration, but in my opinion most CRM implementations don’t live and die by the technology – they live and die by the client organziations’ ability to adopt it. And this has a lot less to do with the technology side of things than people often believe. It has a lot more to do with how the system is internally implemented and managed, and this can be tricky to deal with when you’re an external resource and you don’t actually work within the organization.
I decided that I will focus the next few posts on these issues that deal more with organizational behavior than they do with Salesforce technicalities. The following is based on my experience.
Tip #1 – Your Client Needs to Designate an Internal Project Manager for the Implementation
This is ground-breaking, right? Earth-shattering? Utterly profound? I know what you’re thinking. In reality, though, this is much easier said than done and quite often it isn’t said…or done.
Depending on the organization one of three things is likely to happen.
1. An internal project manager is never discussed.
Result: Mass chaos.
You will be caught in the middle of internal decision-by-committee. This is a highly unproductive place to be. For example, an hour long discussion with a manager will lead to a consensus on a decision. You or your team will make customizations accordingly to reflect the decision that was made. Tomorrow, that decision will be tossed out of the window by either another manager or the original decision maker’s supervisor.
2. A “lame-duck” is appointed as project manager.
Result: Deceptive Inefficiency.
A lame-duck scenario is typically seen when an executive designates one of his/her direct reports as the project manager but the designated project manager doesn’t truly have the authority to make decisions and is often hamstrung by having to run everything up the proverbial flag pole. In this case, you’ll often spend a significant amount of time with the lame-duck and their direct reports and feel that good progress is being made. In reality, there is a good chance that when this “progress” is run up the flag pole it will get sent back down with a plethora of changes.
3. A bona fide project manager is appointed to the project.
Result: Good times.
This is where things will start to click. The project has a high chance of success when an internal point person is designated who has a significant amount of decision-making authority, as well as a holistic understanding of who the project impacts and can coordinate actions between internal departments such as business units, IT, and executive teams. The result is that there is a clear and systematic approach to making decisions and executing the work. Everyone knows their role and can focus their efforts 100% without fear that their work could be easily undermined.
But I thought the client hired us to be the project manager?
They did and they didn’t. A very clear answer, I know. Let me explain.
I mentioned the term adoption above, and true adoption is the holy grail of any successful Salesforce (or any CRM for that matter) implementation. By adoption I mean a) Are the users actually using the system?; b)Is it being used correctly?; c) Is the data/reporting accurately reflecting what’s happening in the business?; and d) Is there a clear system for continuous improvements and enhancements? If so, the client is well on their way.
Yet true adoption is an ongoing process and it will require effort by the client long after you’ve left the scene. A good analogy is the saying, “Give a man a fish; you have fed him for today. Teach a man to fish; and you have fed him for a lifetime.” To answer the question, yes the client hired you for project management around helping them setup, customize, train users and rollout the system. And one of your first steps in this project is to help your client designate the right internal project manager.
To look at it another way. When you function as the project manager you essentially “own” the project. As an external resource your time with the client is limited and when you leave if you still own the project there is a high degree of likelihood that it will fall apart shortly thereafter. Immediately working with your client to designate the correct internal project manager (remember the 3 scenarios above) will ensure that there is internal “ownership” of the project. This will give your client a much higher likelihood of success, in terms of ongoing adoption. And after all, client success is what it’s all about.
As always, I would love to hear your feedback and personal experiences.