The Pledge for CRM Success, Part 2

In Part 1 of this series, I outlined the qualifications of the three-point pledge and described in detail the first pledge and promise, which can be summarized as follows: Don’t adopt new technology without a clear understanding of how it can generate economic benefit given potential risks and rewards and an understanding of your organization’s design, strengths, and weaknesses.

Promise number two further illustrates criteria needed for customer relationship management (CRM) success: Pledge 2: Use a portfolio management matrix with quantitative performance criteria to prioritize, coordinate, consolidate, and streamline CRM initiatives across different business groups within your organization. Respect the fact that different businesses have different needs, and understand what technical and business processes can be shared, standardized, or both and which ones cannot.

I promise to embrace a portfolio management approach to my CRM initiatives from my various business units and operating groups. I will integrate and consolidate these efforts to avoid overlapping, duplicative, and contradictory technology development efforts. Moreover, I promise to evaluate these initiatives on the basis of solid, short-term and longer-term performance metrics and will assign the highest priority to those initiatives that offer the greatest economic benefits relative to cost and ease of implementation.

At most large, multidivisional corporations, the problem is not a lack of CRM strategy. The problem is dozens of CRM strategies and initiatives, many of which are duplicative, overlapping, or both.

Some run contradictory to the organization’s IT strategy and architecture. For example, the IT division of an organization is committed to open standards and Internet-based technology to ease integration and global deployment and to lower maintenance costs. But the business groups buy a CRM package based on a proprietary data model and business objects.

Many organizations recognize this. Their other problem is how they “solve” this difficulty. There’s the low-tech “workshop” approach, in which egos, tribal instincts, and pecking orders determine which priorities get established, which initiatives get funded, and how they’re rolled out.

A more high-tech approach involves a corporatewide effort to gather all business requirements and cram them into a single, enterprisewide solution framework. This forces different groups to adhere to the business process design and workflows of the software application. In many cases, different operating groups have very different ways of conducting business (some for good reasons, some for not-so-good reasons).

A common result is the notorious “user adoption” problem — the system isn’t used, or users use only a small subset of features (e.g., deploying a full-featured CRM system as a ridiculously expensive contact management database). Another bad result is different business users customizing the package so much that the company winds up with the worst of both worlds: an expensive, upfront investment for a fully supported commercial package with all the higher long-term maintenance, integration, upgrade, and support costs of a custom application.

A better way is to use a performance matrix to measure expected return relative to investment required. Those initiatives in the quadrant representing the highest return for the lower investment and risk win.

For the expected return use solid, quantitative performance goals. No, I don’t just mean return on investment (ROI), often a lousy short-term performance metric, to serve as the criteria for expected economic benefit relative to the estimated cost, ease of integration and implementation, or both.

In this scheme, commitment and accountability to making specific, measurable performance improvements in business processes (lower servicing costs, reduced inbound customer call waiting, higher hit ratios, higher conversion ratios, higher average revenue per target account, etc.) establishes criteria against which projects are judged. Not corporate rank, ego, or who shouts the loudest at the staff meeting.

For the investment required, use realistic, well-founded estimates on not only software licensing fees but also expected costs of integrating and implementing the package. Include change management, training, and communications expenses.

In the third and final installment, I’ll cover pledge point three.