In the good old days of CRM, the software ran on your servers and needed heavy customization to really work with the rest of your business. The staffing decisions were pretty straightforward: There might be implementation consultants, but the system needed an ongoing team of your own staff. In one of these classic on-premise implementations I came across just last year, the CRM "permanent staff" was 1 development/operational person for every 100 users.
That's a sizable investment for application support, and it's part of the reason for the rush to SaaS CRM. But in that rush, companies may be a falling victim to a serious case of "happy ears," because SaaS CRM is still an information system needing architecture, integration, data maintenance, and system administration.
So let's look at what staffing modern CRM systems needs to look like, because the laws of physics haven't changed that much.
System Development and Deployment
When it comes to SaaS implementation, the configuration and custom coding work can be handled by a much smaller team than in the old days. And for a number of reasons, you'll want a good portion of those implementers in house.
The technical heavy lifting will be in data preparation, migration, and system integration. Even though most of the moving parts will be in the cloud -- the CRM system, the data manipulation tools, the integration server -- there's still hard work to do in architecture, planning, data cleansing/conversion, and integration coding/testing. That work needs the same sort of skills it always has. And it's typically a good idea to outsource the majority of this work.
While the decision whether to use in-house personnel or external resources for carrying out an SFDC project will depend entirely on the specific needs and availability of talent at your company, there are clear best practices for staffing. In small firms that outsource all of their IT function, the CRM team will likely be outsourced as well. No matter how small you are, the project management and requirements prioritization must be done in house -- typically by someone under the executive champion for the CRM system.
Generally speaking, however, the larger your firm is, the more of the CRM project team should be in-house. Why? Because CRM systems are much more likely to evolve than any other type of enterprise application. The business requirements will change, the competitive landscape will get tougher, of the channel will demand something different. Or you'll just get a new VP that wants to turn things around...including the way the CRM system works.
Given the likelihood of change, even if your staff is extremely constrained, no part of the CRM work should be done entirely by outsiders. Your organization will need internal capabilities to develop and manage the system going forward.
That said, it's also not a great idea to have major parts of the project done without any outside input. There are certain parts of the project that you don't really want to get good at: technologies that provide you no particular leverage, or processes (such as data cleansing) that are incredibly boring or time-consuming. Consultants also bring valuable lessons from other implementations, and they can help you develop best practices in areas such as sales processes or Agile project management.
You'll notice I didn't say "operations" here -- if your CRM is at all successful, there will be demands to expand its footprint, integrate across a wider range of systems, or just bring on more users. Almost inevitably, the CRM system will need to be developed well beyond its original deployment. And that's as it should be: CRM systems beg for Agile's incremental phases, so that you don't spend money on a "big-bang" of functionality that the business didn't really need in the first place.
Our experience is that ongoing development is somewhere between 10 to 30 percent of the initial project every year after deployment. So your development/evolution team will probably be of a corresponding size. However, if you go through a major corporate restructuring (merger, reorganization, product-line consolidation, etc.), expect the size of the CRM team to jump significantly.
We believe that this is an ideal situation for bringing in consultants for the duration of the peak workload (typically a couple of quarters, unless the system integration is big and ugly), because there's no point in beefing up your staff for a temporary need. I'm not going to go into the budgetary implications in this article, but obviously you need to make sure there's a budget item somewhere for this inevitable demand.
This is an area that couldn't be more different between SaaS and on-premise CRM systems. The number of administrators you'll need for a properly implemented SaaS system will be tiny. You'll need three (particularly if you're a 24/7 operation), but we actively discourage our clients from ever having more than 6 for a single SaaS CRM instance. Ironically, one of the biggest issues we see in large implementations is "too many admins."
David Taber is the author of the new Prentice Hall book, Salesforce.com Secrets of Success, and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.