The grand-father is the CEO of a fast-growing midsize company. His daughter is the executive in charge of the software implementation, and her husband is the sales manager of the firm. The younger sons are its sales people. The daughter who flies home from college is its IT manager. The teenagers are the other employees and supervisors of the firm. The uncle who is called for help is a sales VP or a new sales manager hired after the fact.


So why is the minibus stuck in the garage?

Data clean-up and migration from legacy systems is a real budget killer. Midsize organizations tend to vastly underestimate the complexity of the task. By the time they have installed a system and migrated their data, their resources are depleted and momentum is lost. The executives who initiated the project abandon it to employees who can afford to spend time on details but who lack the authority to bring the project to completion. The implementation stalls. Technology has gobbled up all the allocated resources and time. Nothing is left for the two other pillars of any successful software implementation: Processes and People.

Trust is a double edged sword. Because CRM implementations live by trust, they also die from the lack of it. Here is why. Midsize organizations tend to invest in back-end systems (operations and accounting) before they invest in CRM. The managers who oversee the implementation of back-office systems are detail oriented. They are production managers or accountants whose job it is to craft processes and conform their employees’ activity to these processes (in a top to bottom fashion). Their procedures are the legal bond by which the organization runs. Companies invest in CRM when they realize that they must better control and integrate their front-office activities to become more customer-centric. CRM implementations decisions are made by Sales or General Managers whose job it is to process information that comes from their employees and from the market in a "bottom to top" fashion. Whereas their back-office colleagues were more detail oriented, Sales and General Managers are more relationship and bottom line driven. As against production managers or accountants who base their decisions on first-hand facts, they must base theirs on partial information and on trust. This is how trust plays an important role in the life and death of CRM systems. When Sales and General Managers initiate their CRM project, they do not foresee all the implications that their decision will have; they simply trust that CRM will help. They have limited information, limited experience and limited time. They have no choice but to entrust their CRM initiative to a vendor, an employee or a consultant. This trust carries the project until the end of the "technology" phase of the implementation. When the CRM system is in place, the very people that these managers rely upon to get their information and to get their job done start to react to the system and to the constraints that it imposes or may impose on them. If at this stage users are not trained and processes are not solidly defined, universally approved or firmly imposed, people voice their criticism and start to opt-out (explicitly or implicitly). The trust that Sales and General Managers have in their own staff weighs in against the trust that they had placed in the implementers and in the system. If by now, as is often the case, the consultant or implementer has moved on to another mission, the initiators of the CRM initiative are left with no other choice but to distance themselves from the system alongside its most powerful opponents.

Procedures are necessary but alien to the way Sales Departments operate.

Once the technology phase is complete, once resistance has built up and once the "implementer" is gone, success rarely materializes. Like any other enterprise software – and more so because CRM processes a lot of unstructured data, CRM systems can be used or misused in many different ways. For CRM information to be shared effectively and for reporting and automation to work, data must be entered and used with consistency; so procedures must exist to guide users, and users must be trained to follow them. The problem is that because procedures, integration and automation are usually alien to the way Front-Office departments operate, the initiators of the CRM project often fail to realize how critical it is to define processes and to formalize them in writing. So they do not. They assume that technology suffices and that using a CRM is akin to filling out web-forms or entering orders in an accounting system. With processes undefined employee support soon collapses.

Writing procedures and getting managers and employees to sign-up on them and on the new system is not an easy thing to do.

Sales and General Managers have neither the time nor the inclination to delve into the details of a complex system and to write lengthy instructions. Employees do not like to read instructions either. Managers usually "rule" by verbal communication and short memos, sometimes in a more re-active than pro-active manner.

Unlike back-office workers, sales, marketing, customer service, product managers and support employees are not used to procedures and to the rigor that enterprise software imposes on users. If anything, they are used to smaller, specialized, non-intrusive applications that they control individually or at the team level.

Integration is not a big concern for sales and Front-office employees.

Front-office employees do not depend on other departments’ data as much as their back-office colleagues do. When an R&D engineer modifies an engineering files, he knows that this will have an impact on other departments and employees: inventory, production, purchasing, QC, etc. There is no such awareness and domino effect in front office departments. Front-office employees process a lot of unstructured information and exchange little data with others. Integration is not a primary concern for them. Their knowledge of the needs of other departments is often limited. Their relations with their peers are generally informal, lightly structured, dependent on good-will and sometimes even competitive. Competition among employees, teams or departments is sometimes sought as a way to stimulate activity and to collect and verify information. As a corollary, secrecy can be used as a mean to protect oneself and retain power for both employees and managers.

Obligation to perform versus obligation to comply

Front-office employees are valued by their peers and managers for the results that they achieve individually, not for their adherence to set methods and their flawless contribution to the work of a team, not for the means that they employ or for what they do for others, not for their compliance to rules and recommendations.

Sales and General Managers will always tend to favor a salesperson who brings a lot of sales but bends the rules over one who is compliant but sells less. They will tend to be indulgent with the first, but not with the second.

Micro-management worries

If anything, Sales and General Managers are wary of interfering with the means employed by their staff because they fear being associated with their employees’ failures. The power of Sales and General Managers is dependent upon their ability to judge performance. If they cannot do it (because they share responsibility in their employees’ failure), they lose their ability to do their job; they lose their own relevance. Likewise, sales employees fear that management meddling in their activity could result in failure for which they might be unjustly blamed or sanctioned (be it because of management error or simply because they are wasting their time in front of a computer).

Contrat versus diktat

Managers and their teams are linked by contract-like understandings (objective-based) and positive motivation. They are not bound by instructions and monitored by a quality system as back office workers often are. Front-office employees are the link between an organization’s management and its market. Sales and General Managers tend to treat them as they treat their customers, with respect, openness, clarity and a measure of friendliness, through mutual commitments.

All this makes user adoption virtually impossible.

In effect, procedures, integration and automation are so irrelevant to sales and front-office departments and to their value system that it makes the adoption of enterprise software by these departments very difficult. Whatever the system and whatever its merits, Front-Office employees do not need it. They do not need a multi-user system to send email, log appointments, and track opportunities or tickets. They can do this with paper or single-user applications. Supervisors can benefit from a multi-user application, but they do not need a multi-department system to manage their teams. Front Office employees and their supervisors have no incentive to use enterprise software as it is at odds with the value and rewards framework in which they operate and which their management supports.

Unlike their Back-office colleagues, Sales and Front-office employees do not benefit directly from enterprise software.

Back-Office workers and accountants process structured data that is for the most part generated by other employees or departments and/or destined to be used by others. They benefit directly from the convenience and reliability delivered by enterprise software. Their work would be painstakingly slow without it. Their supervisors need software for compliance issues, and they use it to shape and enforce the processes that employees execute. Both Back-office workers and managers share the benefits of enterprise systems. This is not the case with CRM. Most of the new benefits that CRM brings are benefits for the top management of the company.

Those benefits are:

• Better market visibility and employee accountability through company-wide, real-time record sharing, reporting and alerts;




• The elimination of duplicate data entry among employees and departments and concomittantly, the reduction of errors: through the sharing, duplication and conversions of records (e.g.: a lead becomes a contact, a quote becomes an order etc…);




• The speed gained and the reduction of errors achieved through the automation of repetitive and complicated tasks previously performed manually (e.g.: quoting, expenses);




• The ability to easily collaborate on processes/records, documents, etc;




• The better retention of customers and the early identification of opportunities through the integration of departments, office locations etc.;




• The enforcement of better business practices through process automation within and across department boundaries;




• The retention of knowledge in a shared and exhaustive repository (rather than simply in the heads, hard disks or phones of employees who can switch jobs at any time);




• The centralization and easier access to information on a per customer or per category basis (notes, email, fax and other correspondence, cases, products, pricing, quotes, etc…);




• The manageability of workloads and schedules (e.g.: allocation of leads to be qualified, customer service tickets, project tasks, etc …);




• A single (as opposed to many smaller PC applications), safer, integrated web-based system that can be outsourced.Some CEO’s reckon that the advent of the PC shifted the complexity of computing from the mainframe to the desktop and yielded no productivity gain in their organization. (The Gartner Group estimated in 2002 that the TCO of a networked PC was $13,000 per year, most of it in hidden costs, such as the cost of the time spent resolving problems or on non-job-related PC activities.) CRM offers CEO’s a way to lower these costs and keep employees focused. …

The company and its top managers are the main beneficiaries, yet employees are asked to do the work.

The above are essentially general management benefits since they serve the company as a whole and managers in particular. They make the organization more efficient and more "customer-centric". They are not per se benefits for the employees. The CRM requires that they work differently, but it does not bring much efficiency and reliability to the way they work already. Nonetheless employees are the ones who must work with the system and load it with data. In doing so, they make themselves more accountable and they lose both valuable time and freedom. In comparison, and from their perspective, it seems that all that managers have to do to benefit from the system is to read the reports that it generates.

Left unchanged, roles and processes are at odds with the new technology.

The Sales or General Managers who initiate front-office software projects rarely realize that they are the ones who benefit the most from the new technology. They seldom foresee that what the technology enables is new processes and that employees will not adjust to the new system if those processes go against current practices and job descriptions. Overlooking this, Sales and General Managers do not adjust their company’s processes to their new system and objectives. Underestimating the importance of the task, how alien the software is to employees, and that their own methods must change, they do not formalize the new processes into written procedures and revised job descriptions. Goals are not defined. Fairness, effectiveness and costs are not verified. Change is not introduced. Employees are not properly trained, and rewarding schemes are not adjusted.

What it takes to succeed is a leader-driven and heartfelt revolution.

Integrating the activity of sales, marketing, customer service, and support personnel, together and with the rest of the organization, at all levels and in all company locations, is truly a revolution. Like any revolution, it can only work if new and higher values are embraced by the people whose lives must change to make the new order possible. For this to happen, a prerequisite is that leaders espouse these values, propagate them and set rules that protect "law abiding" employees against those who act against the common good.

Here is an example. Two sales managers from the same organization, each located in a different country, sell products to two different factories owned by the same multinational corporation. On a late Friday afternoon, one of the sales managers receives a quote request from the factory located in his territory. He immediately replies with a quote and receives an enormous order. On Monday the President learns about the sale and praises the successful sales manager before his staff. This all seems very normal; yet, the company just lost a million dollars. The successful sales manager, whose aggressive style the president likes, did not bother to check the company’s CRM to see where the sale was coming from – and why should he? He reports directly to the president, and the president does not care about the CRM system. He does not have a sales background and does not want to be encumbered with details. If the sales manager had been "scrupulous", he would have learned from the system that the product that he just sold had been "designed-in" by the manager of the other country. He would have known that months of work and tens of thousands of dollars had been spent on that sale and that the price originally quoted for the product was twice as much as what the customer finally paid (a price commensurate with the costs involved). The customer, a multinational company with a centralized purchasing database was simply shopping around. The company sales director later figured this out but he has no authority over the territory managers who historically report to the president. He also knows that his boss, the president, uses this situation to keep him and the territory managers in check. He knows that this is the culture of the company and he does not like some of the constraints imposed on him by the CRM system, so he does not say anything. The territory manager who lost the sale and has become unpopular because of his lack of results understands the situation and starts looking for another job.

If new processes had been formalized, signed-off, and universally accepted, this example would demonstrate how dangerous an employee who shows brilliant results but defies company standards or procedures can be (and much more so that an employee who bends the rules but is not successful). But this is not the case here. The technology that would prevent the company from bidding against itself exists, but no process is in place to enforce this. In this example, everybody conforms to the company standards which are implicitly enforced by the president of the company himself.

But the CEO cannot do this work.

The Sales or General Manager who initiate the front-office project SHOULD ideally redefine processes and formalize them in writing, but he CANNOT. He cannot because he is generally unaware of the crucial importance of his role and authority in the matter (nobody told him), because he does not know precisely what the system can do, and because it would take too much of his time to delve into it. Sometimes, he also lacks the knowledge of the unspoken dynamic that exists between departments and individuals and which can "make or break" the implementation. So what can he do? What happens next?

All the CEO can do is delegate and be prudent.

Well, the role of a good manager is to delegate, so he hands-over the task of "making things work" to a trustworthy subordinate. In face of uncertainty, his duty is to be prudent, so he starts on a small scale, usually with one department, generally with Sales. He may suspect that the new system could overlap and conflict with existing tools but he does not know precisely how, so this also is delegated. Let’s see how this works out.

This cannot work. A revolution can't be delegated to a lieutenant.

When the task of "making CRM work" is delegated to one or several executives or department managers, success is unlikely to materialize. Like his boss, the executive in charge usually lacks the software expertise and a sufficient understanding of what his colleagues do (and how and why they do it). He also lacks the time that would be required to handle the task. Unlike his boss alas, he lacks the authority and the stake in the game to succeed. He soon realizes that the goals of integration fostered by the new system can only be achieved if they are enabled at the human level first (something that he cannot do). He perceives that the procedures that he could write might upset people, could be foiled by influential employees and would not be enforceable. He worries that he could fail and disappoint his boss despite his best efforts and loyalty. So he does the best he can; he re-distributes parts or all of the task of "making things work" and writing procedures to users who know the system better and to managers who have the authority to alter their own departments’ processes (after all, this is also the best way to ensure that they get onboard). At best, this results in a patchwork of processes and a few documents that more or less reproduce the way things worked before the system was installed. In general this results in frustration for the people who were put in charge, finger pointing among managers, and puzzlement among regular employees. For lack of a proper policy, procedure and instruction framework, the system is under-used and its use becomes in part optional.

The implementation stalls and everybody is puzzled and disappointed

What is disappointing for the parties involved is that most of them would have welcomed the new technology if it had been accompanied by ad-hoc "enabling" processes and cultural adjustments. Once introduced to the system, employees can easily envision how better results could be achieved by their organization with a bit of automation and integration among users, departments, office locations and hierarchy levels. Good employees do care about their company.

There would have been "something in it for everybody"

• Sales people can see how the system could help them easily and rapidly access the customer information that their colleagues produce or collect in customer service, tech-support and other back-office departments (forewarned is forearmed – When you are called or will call a customer, it is always good to know all that there is to know about the relationship that exists between your customer and your company – If accessing this information is too complicated or time consuming, people cannot afford to use it).




• Sales managers look forward to being able to better track the whereabouts, opportunities and performance of their sales people (better than they could with paper and spreadsheets).




• Managers realize that the system could allow them to better allocate tasks to optimize throughput, work quality, speed, and cost. i.e.: Sales Managers see how customer service agents could be used to identify new customer needs and to qualify sales leads (and customer service agents can see that with a limited sales roles, they might be entitled to commissions or finder-fees in return). Quotes could be written directly by sales people instead of being written by a dedicated employee using a stand-alone application. Customers could access information and log requests directly into the system via a web-portal, etc.

• Sales employees from territory A perceive that commissions could now be split when their labor leads to sales in territory B. This would entice them to visit customers that they would otherwise ignore because there is nothing in it for them and because there is only so much they can do in a day.




• Some tech-support employees realize that, with the appropriate tool, their "intimate" knowledge of the needs of their customers’ could translate into new business and into more respect for their role. They could generate leads.




• Marketing employees appreciate the fact that the system could provide them with metrics that they could use to better identify trends and to better adjust pricings and products to the market (i.e.: competitive intelligence tool).




• They realize that they could easily use the accurate contact information maintained by their colleagues for their newsletters, events, surveys and other campaigns and thus would not need to maintain "parallel" lists by themselves.




• Accountants perceive that they could now rein-in the sales people who take too many liberties with price-lists.




• They also envision that they could extract forecasts from the system to build their budgets.




• Sales people understand that the system may allow them to better track invoicing and the commissions "owed to them" by "accountants".




• And then of course, there are the numerous tedious tasks that were performed manually and could now be automated.

The list could go on.

Employees and their supervisors can see how our "top management" benefits would be spelled out into efficiencies at their level. Some hope that the system will compel decision makers to solve issues that they had raised to no avail in the past.

So why doesn’t it work? Why can’t those in charge make it work?

The first and obvious reason why subordinates cannot make it work is that most of the efficiencies that could be gained are efficiencies that depend on others for their actualization. For integration to work, two or more parties must integrate something and therefore change or "exchange" something. The realization of these efficiencies is dependant upon people expressing their needs in light of what the technology can do. It is then dependant on the willingness of people in other departments or at other hierarchy levels to modify the way they work and to share information; to loose a little today to gain more tomorrow. The same reasoning applies to automation. For a software functionality to be used, you need managers to convene, and to research and evaluate the gain that could be achieved through the functionality (gain in increased throughput or in time saved).

It is hard to ask people to loose a little today so that others will gain more tomorrow.

Asking people to work or modify the way they work for benefits that would be gained in another department is a hard thing to do, especially when those benefits do not appear to be "mission-critical" (as is often the case with CRM). It is hard for a Sales-Manager to ask his peer in customer service to adopt a new system just so that sales people can faster access the information logged by customer service agents. The Customer Service supervisor will likely answer "if you need information, just ask" or "log into OUR system and find the information yourself". Sales managers know that being able to access information in a snap from a single contact record in a single database is a true benefit. Customer Service agents do not. For their part, they do not care much about the information logged by sales people.

Why would anybody sacrifice anything for a project that has already lost its leadership and momentum.

A second, and frequent reason why people cannot "make it work" is that many of the parties involved do not have to. They did not participate in the initial phase of the deployment and by the time they could be joining, the project has already lost its direction and momentum.

With a small scale implementation and a limited set of functionalities, very little gets accomplished in terms of integration.

This can happen when the project starts with a single department only. Again, It is hard to anticipate all the consequences of an implementation and it may be intimidating and risky to "re-engineer" multiple departments at once, so it makes sense to start small. But Ideally, the system should be first installed in an independent division or location of the firm. Instead Unfortunately, for most midsize organizations this is not an option. They do not have divisions, and/or their managers need to remain in control. They need things to happen locally, in their main office and with their staff. So instead of starting with the entire system in an independent location, they start in one department only and with a limited set of functionalities. They may initially limit the number of licenses that they purchase to the number of employees working in this department. Since the other departments are not yet involved, they adopt a "wait and see" attitude. As far as they are concerned, "they are not concerned". Since the implementation generally starts with Sales -- a department that many regard as unruly or privileged and in need of tighter monitoring -- many end up viewing the system as a sales tool only. In this context, with only one department onboard and with Customer-Service, Tech-Support, Marketing, Product Managers, and the rest of the company left out, very little gets accomplished in terms of Integration. All that may be achieved is the automation of a few key processes (quotations, order entry…) and a tighter control over the Sales team -- if sales people collaborate, that is.

The new system overlaps and conflicts with pre-existing tools. The old tools remain in use. Customer-centricity can't be achieved.

There are not that many things which are new in CRM process automation. This also thwarts the implementation. For the most part, CRM systems consolidate processes that could be handled by other tools: accounting systems (order fulfillment), dedicated applications (quotations, email, calendar, campaigns, bug tracking, project management…), back-end or legacy systems, intranet etc. The value created by CRM is not so much in the automation of these processes as it is in their integration into a coherent whole in which data can be reused and in which it is better organized "around the customer". What is new about CRM is that it treats these processes as what they truly are: customer-serving processes. Integrated Back-End systems (ERP, MRP) tend to treat them as "internal" processes. In good CRM systems, there is never more than one or two degrees of separation or "clicks" between a customer record and any other record that relates to this customer.

When the CRM project starts, many of these front office processes are already tied to other applications (quotations, order fulfillment, email, calendar, campaigns, bug tracking, project management…). Because it is hard to anticipate all the implications that CRM entails, and because the project does not yet involve all its potential users, many of these tools still remain in use after the CRM installation. This is the third reason why it is hard to federate people around the CRM project and to "make it work".

Users fervently fight to protect their tools and nobody stands for the CRM.

Some CRM functionalities are redundant and thus appear optional or unnecessary to many users. Since the benefits of automation are more obvious than the benefits of integration, they do not understand why they should switch tool. Again, they are accountable for the results that they achieve, and generally not for the means that they employ, so they may feel entitled to the privilege to pick their tools. As human beings (as any economic player), they fear uncertainty and resist change. They have invested time "equity" in their applications. They like to use the best tools available in their trade. The tools that they master may boost their professional egos and feature prominently in their resumes. They may also have "upgrades" in mind which may already have been approved by their managers. CRM is a turnoff for them. There are no bells and whistles in most CRM functionalities because things need to remain manageable in large applications; so people invariably find the CRM functionalities to be too basic. Nothing worth sacrificing anyway. Their argument against CRM is strong: "why fix it if it isn’t broken". If the CRM functionalities at stake prove too rudimentary, too different or too buggy, the argument usually holds sway. They do not need to know the CRM to make their point, and they rarely do.

The processes embodied in the pre-existing tools can conflict with those embodied in the CRM.

Even when there are legitimate reasons why a seemingly "redundant" application should remain in use, problems can arise from the processes embodied in this application. Those processes may not only overlap with those of the CRM system, they could also conflict with them. If those problems are not anticipated, discussed and solved before the implementation, they can become insurmountable and further contribute to the marginalization of the CRM system.

Here is an example: Email messages sent-to and received-from contacts via a CRM system can automatically be attached to the records of these contacts. Optionally, they can also be manually attached to other relevant records: quotes, opportunities, incidents etc. As they are attached to records, email messages become accessible to all (…who are authorized to access these records). This is a huge benefit. Messages are no longer kept hidden and inaccessible in individual email clients and Personal Computers. This is also a risk however. As people still use email clients like Outlook alongside the CRM system, they may not be aware of the fact that their email messages might now be read by people other than their intended recipient. Here, the email processes embodied in the CRM system and that embodied in personal email clients like Outlook conflict with each other. If a CEO were to discover this difference by accident, he would invariably regard it as a flaw and he would overlook the benefits brought by email integration. Asked for advice, IT specialists would prudently recommend that the CRM not be used for email. Thus, they would unknowingly deprive the CRM system of a big portion of its usefulness (as if someone decided that faxes and letters could not be stored in the customers’ manila folders in a company’s file cabinets because those cabinets can be opened by people other than the recipients of the document).

If this CEO and his/her team had been forewarned, they might have agreed to use a different set of IMAP email addresses/accounts for the CRM system. When a company decides to use a CRM, it should first design an email procedure to ensure, among other things, that personal, confidential or internal email messages are sent and received via personal email addresses/inboxes/accounts that would exist in Outlook and/or Smart-phones but NOT in the CRM system. The CRM email client would only be used for non-confidential business related correspondence. If handling multiple email accounts/addresses depending on the content of email messages was too much to ask or was still regarded as risky, the company could instead disable the automatic attachment of email to contacts. This would require that email messages be manually attached to records based on their value and content, but this would preserve email confidentiality. In any case, the inconvenience that any of these solution would have created would be very minor in comparison to the benefits it would have preserved. The situation did not justify that the baby be thrown with the bath water. This leads us to our next point.

The CRM is finally abandonned to the IT department.

When the implementation stalls with procedures, employee support, utilization and management oversight lacking, the responsibility of the CRM system generally falls onto the IT department. This also impacts the success of the CRM project.

Installing and securing a CRM system is a relatively simple process. With a little bit of experience, this can be done in a half day. The complexity and toil is elsewhere: in the system selection, data migration, process definition, training etc. IT personnel sometimes participate in the installation of the system, but they do not always participate in the other phases of the implementation which are non-technical in nature. Many software initiatives start in the IT department but this one generally does not. As a consequence, IT personnel are usually unaware of the "what, why and how" of the system and of its many intertwined functionalities. Since little or no procedures were written, it is hard for them to figure out what is important and what is not. All this can make them feel ambivalent or indifferent towards the application. They empathize with the employees for whom the system is a turnoff. They will not question their assumptions and will not consider the pros and cons of CRM because nobody is there to explain where and how the system creates efficiencies. They will more eagerly spend time trying to integrate the CRM with the tools that these employees like rather than try to understand how the system works and how to tweak it to accommodate their needs. Emboldened by dwindling management interest and now "in charge", they may take action and jeopardize the little of the system that is actually in use for the sake of the people who do not want to use it (the above example shows how this could happen). If they do, functionalities that worked will inevitably cease to work. More efficiencies will unavoidably disappear. Sales people will slowly abandon the system and return to their old tools. They will only use the system as an opportunity log and as a quote writer (if this task has not been re-assigned to a single employee).

Now the question is, how could this happen?

Why couldn’t anybody see this happening and intervene? What did the software implementer do or not do?

Now, lets have a look at the CRM functionalities listed earlier in this document. In a business in which CRM works, the removal of these functionalities would feel like death by a thousand cuts? How is it that here, it is the CRM system that died by a thousand cuts?