CRM projects can have some very tricky technical elements, particularly when it comes to integrating with other customer-facing and internal systems. \n\nThey can also be quite labor intensive when it comes to normalizing, deduping, cleansing, and converting data. But in many CRM projects, those issues \n\naren't the biggest contributors to schedule slips. Look closely: the larger the CRM project, the more likely that the delays are coming from outside of IT. \n\nNo, it's not time to beat up your vendors. It's time to engage more closely with your users and project sponsors.Why? Because a key problem in CRM projects is getting permission to proceed. The team is waiting for user feedback, executive policy decisions, \n\nor management approval. CRM projects are much more vulnerable to this issue than most enterprise applications because the requirements and business \n\nprocesses are much more variable than, for example, an accounting or HR system. Since CRM systems provide the most business benefit when they are \n\ntightly aligned with business policies and personal preferences of the sales and marketing VPs, fit really matters. Organizational politics really matter. And \n\nsome of the priorities will change with every reorg...which in sales and marketing can happen pretty frequently.So, approval cycles \u2014 quick, definitive, and broadly communicated \u2014 are a key success factor for tight CRM projects. There are two \n\nlevels of approval cycle \u2014 and the project lead can only do one of them by him\/herself. The second one, senior management has to help \n\nwith.User FeedbackUser adoption is a key metric for CRM systems. You don't have to believe in Agile to know that engaging users early and collecting their feedback \n\non a regular basis are the best ways to avoid waste and rework. In our CRM projects, we want users to try out features-in-progress at least once a \n\nweek.Why so often? Because users are busy people, and they tend to forget what they told you. Further, as their personal goals and priorities shift over \n\ntime, it can be tough to even keep the users on topic (sometimes they'll give you feedback on a different system than the one you're working on). Asking \n\nfor feedback incrementally, and publishing user feedback in a Wiki, will improve the quality and relevance of their input.It's also important to get feedback from the right users. Sometimes, the people who have time to spare for a functional usability session aren't the \n\nones who matter. Other times, people who just love to be critics aren't setting realistic standards. Choosing the right users is something of an art, but an \n\nart that the project lead must learn.Even though the characteristics of the review users will vary by organization, we use the following guidelines:\u2022 The feedback team should be selected at the start of the project, and explicitly authorized by their managers to spend an hour a week (or \n\nwhatever you need) for however many weeks the project needs them. Try to keep the team stable for at least one release cycle.\u2022 The team should be about equal thirds: power users\/computer sophisticates, luddites\/passive-resisters, and people who work closely with \n\nanother system in addition to the CRM.\u2022 The team should be reasonably centralized. Even though much of the review should be done over the Web (and in some cases must be \n\nremotely to be realistic), it's easier to coordinate and schedule the sessions when the team isn't on the road or scattered across several time zones.\u2022 The team should be comprised of people who have the bosses' ear. Decisions and approval cycles go faster if the boss trusts their \n\nrepresentative, better yet if the boss delegates the authority on small decisions to the team member. Beware fake delegation, where the boss overrules or \n\ncontradicts their delegate!It is typically much faster to collect user review feedback in individual meetings. Of course group sessions would be a better use of engineering's \n\ntime, but the scheduling impact of a single meeting can be far worse. It's easy to lose a week's time just trying to coordinate a 5-way meeting, and the \n\nresulting traffic jam effects can stall parts of the project and idle your engineers.Management DecisionsIn CRM projects, management decisions about the four Ps (priorities, policy directives, people, and process) can be pivotal to CRM project \n\nsuccess. The more important the decisions, the longer it takes to get the meeting...and the bigger the schedule impact of decision changes.So it's critical that the project lead be able to tap the political power of the CRM executive sponsor as well as top IT leadership. The specifics \n\ndepend on your corporate culture, but it's generally better to have short, quick decision cycles and avoid the "summit meeting" impulse. Of course, \n\nsometimes a big meeting devoted to CRM is required, but too often these are non-productive because the focus tends to wander away from the specifics \n\nof what you need decided. We've all lived through meetings like this where decisions from previous meetings were overturned, almost invariably \n\nclobbering the schedule.No matter how executive decisions are made, it's best if there is a signoff sheet at the meeting, and the decision published on your Wiki to reduce the \n\nchances of misinterpretation and eliminate plausible denial. Trust me, your schedule will thank me six months from now.David Taber is the author of the new Prentice Hall book, "Salesforce.com Secrets of Success" and is the CEO of SalesLogistix, a certified \n\nSalesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, \n\nEurope, Israel, and India, and David has over 25 years experience in high tech, including 10 years at the VP level or above.Follow everything from CIO.com on Twitter @CIOonline.