Must Haves vs. What’s Nice to Have for CRM Project Management, Part I
Having recently attended a CRM project management conference, I was struck by the convergence of recommended methodologies and practices that project management specialists propound for CRM implementations.
While I was encouraged by the fact that some many people in the project management field share the same views about the right prerequisites and the right approach to designing and implementing CRM, I couldn't help but feel that all the wonderful charts and buzzword-filled PowerPoint slides were less than realistic.
Most organizations need to do a better job at CRM implementations — as the industry statistics on its reportedly high failure rate so painfully testify. Therefore, one must also acknowledge that project managers, like everyone, can't always get everything they want.
Project managers must pick their battles carefully; and some things are more important than others are. In the interests of providing some real-world experience and common sense to CRM project management theory, I offer my opinion of what requirements are nice to have but not essential for success, and what CRM requirements are worth fighting for.
In the first part of this two part column, I will discuss what I feel are “nice to have” requirements for effective CRM implementations. In short, they are the things clearly worth advocating and pushing for, but not deal breakers.
In Part II, I'll cover the essentials that are truly elemental to the success of CRM in an organization.
Nice to Have: Enterprise-wide CRM
Some project management experts argue that to ensure success, CRM must be a coordinated, corporate-wide effort that includes all operating units and groups.
This approach clearly offers great possibility to maximize the potential return on investment by fully leveraging corporate assets and reducing duplicate, overlapping and conflicting initiatives. However, it is certainly not a prerequisite for success nor is it even practical in large, global organizations operating with vastly different organizational, geographic, and technical infrastructures.
This approach may even be counter-productive. For a highly fragmented organization characterized by highly autonomous and entrepreneurial divisions, insisting that all CRM initiatives be coordinated and integrated with each other is essentially dooming CRM to fail.
Nice to Have: Documented Business Requirements
Having clearly defined, documented functional specs is an essential strategy to ensuring that projects can be delivered on time and on budget. “Scope creep” — usually driven by changing business requirements — is often the culprit for cost overruns and slippages in deliverables.
But the real world fact is that business requirements are constantly changing. And CRM must contend with not only the changing requirements driven by global competition, shortened product lifecycles, and advances in technology, it also is driven by the most fickle and fastest-changing aspect of any business — the interests, needs and concerns of customers.
So while business requirements must be articulated, it is perhaps unrealistic to assume that you can have them cast in stone without some changes and shifts in strategy. Better start out by allowing for some degree of “scope creep” in business functional specs instead of insisting on rock solid requirements to be fully documented at the outset (which is usually at the time the business users have the least amount of insights and feelings for what they really want CRM do to for them).
Nice to Have: Detailed Financial Cost Benefit Analysis
While maximizing ROI (return on investment) is the ultimate goal for all CRM implementations, it may not be necessary, or even desirable, to invest management time and focus on developing elaborate forecasts to justify an investment in CRM.
In many industries, such as financial services, CRM is fast-becoming a prerequisite to compete, and will no longer represent a competitive advantage. Companies would be far better off devoting precise resources into designing the optimal CRM strategy and approach for their respective organizations, as well as establishing clear performance metrics to measure success.
In the short-term, these performance metrics should be based on direct outcomes of the new processes — such as lowering the number of late shipments or increasing the number of desired customers — instead of broader financial measures, such as revenue or profitability, which are a function of too many other independent variables.
In longer-term metrics, companies should consider designing performance criteria to customer intelligence criteria: are we attracting and retaining the right customers? Why and why not?
Stay tuned for the second part of this column, in which I'll identify the real make-or-break requirements for effective CRM project management.
Got an opinion on this stuff? Willing to share it? If so, please write me at [email protected].
Arthur O'Connor is one of the nation's leading experts on customer relationship management (CRM) and customer-facing IT systems and strategies. He's currently the national columnist for eCRMGuide.com and this year serves as the chairperson of the Institute for International Research's CRM Conference. Arthur has over 20 years leadership and management experience in the area of customer management, strategy and new business development, including 15 years as a senior corporate officer of two NYSE-listed inter national corporations, and over five years experience as an independent management consultant and Big 5 firm practice manager selling and managing large-scale IT engagements.
