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 \n\nstaffing decisions were pretty straightforward: There might be implementation consultants, but the system needed an ongoing team of your own staff. In \n\none of these classic on-premise implementations I came across just last year, the CRM "permanent staff" was 1 development\/operational person for every \n\n100 users.CRM Definition and SolutionsThat'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 \n\nvictim to a serious case of "happy ears," because SaaS CRM is still an information system needing architecture, integration, data maintenance, and system \n\nadministration.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 DeploymentWhen 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 \n\nfor 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 \n\n\u2014 the CRM system, the data manipulation tools, the integration server \u2014 there's still hard work to do in architecture, planning, data \n\ncleansing\/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 \n\nmajority 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 \n\nneeds 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 \n\nteam will likely be outsourced as well. No matter how small you are, the project management and requirements prioritization must be done in house \n\n\u2014 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 \n\nmuch more likely to evolve than any other type of enterprise application. The business requirements will change, the competitive landscape will get \n\ntougher, 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 \n\nworks. 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 \n\norganization 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 \n\ndon'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 \n\ntime-consuming. Consultants also bring valuable lessons from other implementations, and they can help you develop best practices in areas such as sales \n\nprocesses or Agile project management. Ongoing EvolutionYou'll notice I didn't say "operations" here \u2014 if your CRM is at all successful, there will be demands to expand its footprint, integrate across a \n\nwider range of systems, or just bring on more users. Almost inevitably, the CRM system will need to be developed well beyond its original deployment. \n\nAnd 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 \n\nbusiness 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 \n\ndevelopment\/evolution team will probably be of a corresponding size. However, if you go through a major corporate restructuring (merger, \n\nreorganization, product-line consolidation, etc.), expect the size of the CRM team to jump significantly. We believe that this is an ideal situation for \n\nbringing 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 \n\nno 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 \n\nsure there's a budget item somewhere for this inevitable demand.System AdministrationThis 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 \n\nimplemented 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 \n\nmore 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. \n\nSalesLogistix clients are in North America, Europe, Israel, and India, and David has over 25 years experience in high tech, including 10 years at the VP \n\nlevel or above. Follow everything from CIO.com on Twitter @CIOonline.