CRM Implementation “Quick” ees, Just Do it Faster and Better

Dears,

CRM projects can have some very tricky moments, particularly when it comes to integrating with other customer-facing and internal systems. They can also be quite labor intensive when it comes to normalizing, deduping, cleansing, and converting data. But in many CRM projects, those issues aren'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. No, 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, or management approval. CRM projects are much more vulnerable to this issue than most enterprise applications because the requirements and business processes are much more variable than, for example, an accounting or HR system. Since CRM systems provide the most business benefit when they are tightly aligned with business policies and personal preferences of the sales and marketing VPs, fit really matters. Organizational politics really matter. And some of the priorities will change with every reorg...which in sales and marketing can happen pretty frequently.

So, approval cycles -- quick, definitive, and broadly communicated -- are a key success factor for tight CRM projects. There are two levels of approval cycle -- and the project lead can only do one of them by him/herself. The second one, senior management has to help with.

User Feedback

User 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 on 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 week.
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 time, 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 for feedback incrementally, and publishing user feedback in a Collaborate Site or Portal, 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 ones 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 art that the project lead must learn.

Even though the characteristics of the review users will vary by organization, I recommend to use the following strategies.

• 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 whatever you need) for however many weeks the project needs them. Try to keep the team stable for at least one release cycle.

• The team should be about equal thirds: power users/computer sophisticates, luddites/passive-resisters, and people who work closely with another system in addition to the CRM.

• The team should be reasonably centralized. Even though much of the review should be done over the Web (and in some cases must be remotely 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.

• The team should be comprised of people who have the bosses' ear. Decisions and approval cycles go faster if the boss trusts their representative, better yet if the boss delegates the authority on small decisions to the team member. Beware fake delegation, where the boss overrules or contradicts 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 time, 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 resulting traffic jam effects can stall parts of the project and idle your engineers.

Management Decisions - four Ps (priorities, policy directives, people, and process)

In CRM projects, management decisions about the four Ps (priorities, policy directives, people, and process) can be pivotal to CRM project success. 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 managers and track leads be able to tap the political power of the CRM executive sponsor as well as top IT leadership. The specifics depend on your corporate culture, but it's generally better to have short, quick decision cycles and avoid the "summit meeting" impulse. Of course, sometimes 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 of what you need decided. We've all lived through meetings like this where decisions from previous meetings were overturned, almost invariably clobbering 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 Collaborate Site or Portal to reduce the chances of misinterpretation and eliminate plausible denial.

Trust me, your schedule will thank me six months from now.

Your P&C
DC*