The Peak of CRM Implementation – Why the Decline Starts Immediately
Introduction
I’ve spent the last 34 years working for the same large IT vendor. A highly complicated global environment with multiple lines of business, spanning the full gamut of IT products and services and many different complex scenarios. Working inside operations teams to develop process, understand user requirements and translate those into software solutions to execute business needs. Watching and experiencing what happens as the decisions about what to build, and very importantly, what not to build, accumulate over time. I’ve done that across multiple silos across the breadth of a company structure from both the CRM and ERP side. In the same business framework and systems. Seeing how the effects of decisions and the prioritization of change and, ultimately, what has been built and delivered has accrued over time.
I’ve watched and participated in the process as software to support siloed business functions was built. From the first systems developed in the 80’s (I didn’t see those, I’m not THAT old) and 90’s and refined through the 21st century via expanded functionality and integration of niche functions through aggressive acquisition policies and from meeting customer demand for specialization. I’ve seen how integrations were built between silos to enmesh these into functioning systems supporting specific business areas like CRM and ERP. And then the integrations between those to form a holistic whole to support the full business. Now we have these systems of systems that almost any company can purchase and configure to their own needs. I am very used to working within this complexity.
With this series of posts, from the perspective of that experience, I’m going to articulate how I see these systems, while functional in the current paradigm, do have drawbacks and downsides to them. To do this I’m going to concentrate on the CRM area that I spent the last 10 years or so working within. I’m then going to further frame this to use the Revenue Engine silos of Marketing and Sales in my explanations. However, I believe as you read this you will be able to apply the same logic to other functional areas and see that these issues apply universally across a business.
The Analogy
We all know the analogy of the tail wagging the dog. It is now my conjecture that the business systems we use today have become that tail. I’m going to provide my evidence for this, but first I want to expand the analogy a little. As these systems have grown, they have become a ‘one-size-fits-all’ solution for anything the business wants to do. ALL of the functionalities are available to every business, regardless of the size. This means the tail in my analogy is always the same size, regardless of the size of the ‘dog’. From the business’s perspective it’s always a Great Dane’s tail but the ‘dog’ can range from a Yorkshire Terrier to the Great Dane itself. Picture that in your head, comedic when visualized, but when applied to the real world that has become a problem, especially for the Yorkie! But even the Great Dane is still being wagged by its tail.
Implementation – when Sales pitch meets realitY
Let’s start with the purchase and implementation of these modules. The Sales pitch promises everything; effortless adoption, 360-degree customer view, productivity boosts, scalable, future-proof, “transform your sales process and close more deals”. Sounds good, don’t get me wrong, you can realize these benefits from buying, installing, configuring, customizing and using these modules. IF they are implemented with the care and attention that is required to get this right. You can buy all modules from one supplier and realize the benefit of the pre-configured integrated nature of the modules. Alternatively, you can purchase from different suppliers and using integrations and middleware develop the way these work together within the whole. With either route taken the gap between modules, from what I’ve seen, is often where a lot of work and issues are generated, requiring integration across different data structures and ‘industry standard’ functions. The setup and configuration is complex and the interactions between objects and functions must be understood and considered when developing solutions. When specific industry requirements are needed such as Healthcare, Government or Finance bringing legal compliance rules then the work increases to implement these.
In all cases you are configuring down from the full suite of functionality to a subset that fits your business model, removing or configuring out anything you don't need. A significant amount of work is required before you can start the real effort to specify and set up the items you do want.
The implementation process itself depends on you having the business mapped through process flows, governance, policies and procedures, and very importantly data quality. However, in reality this is hard and time consuming to do. Then there is the change management work of adjusting the business to the software or the software to the business, using localizations or even customizations to fit the two often disparate states, to create a unified whole. A project scheduled for 6 months can expand to double or even triple that time to ‘get it right’. Or the work can be forced into that constrained timescale; “We’ll go live and then fix the rest later” or an approach of Minimum Viable Product (MVP). When done correctly this works well, but often in my experience it means some parts of process or procedure are de-scoped to fit the timeline leaving the users underwhelmed. This can be especially true if the implementation is across regions and countries with local requirements. If you are migrating from an existing set of modules there is also the work of cleaning and updating data, decisions around historical data to migrate, re-shaping data (often in a less-than-clean state) to fit new constructs and data models enforced by the software.
Configuration, localization and customization and the necessary iterations of this work that are required are just the build part of the project. Operations teams must go through the change management process; understand the changes, analyze impacts, develop workarounds where items are descoped or reserved for future development, update process and internal documentation, test, and then create training materials and ultimately train every affected user on the new system and process. Often external consultants are required, from the vendors themselves, or from consulting firms experienced in doing this type of work. New employees may also need to be hired who have that experience of the process to do this and the landscape of the products purchased.
After months of elapsed time, many thousands of person-hours, from very smart people, both internal and external; a lot of tough decisions from sponsors, department heads, process owners, functional experts and operations teams; the consumption of large budgets; the communication to and training of all affected users; until finally, ‘Go-Live’ day is here. Champagne corks are popping, high fives all around, the external consultants shake hands and say goodbyes, leaving a mountain of documentation that nobody will likely ever open again. And now the whole team breathes a sigh of relief and can relax and get some much-needed rest and step back from the stress - for about a minute and a half.
The team participates in after action reviews and decides and documents the lessons learned. Outside that process the slowly creeping hand of inevitable business change makes itself felt. The backlog of undelivered items gets opened and prioritized; the documentation for the next release from the vendor(s) gets downloaded to see the latest changes to the core product; teething troubles become apparent, a team selling a specific low revenue product can no longer function as their needs were descoped; bugs start being added to the existing queues; change requests start being discussed on divisional ops calls; Corporate HQ announces an exciting new acquisition; Product Development and Marketing decide to change some service definitions; the new SVP of Sales joins with some fantastic new ideas to re-structure to a model they know works. The planning for the next available production patching window begins.
The system stays rigid as it was defined in the project, the business reality of day-to-day operations and identified change slowly begins to drift away from the beautifully configured reality of yesterday.
The point I’m making
Even at its inception, at the time of likely maximum convergence to the business reality, the system is not 100% supporting what the business wants. There is already a backlog of de-scoped items planned for a future release, bugs may be awaiting fixes, manual workarounds in place developed by the Operations teams. But to me the most invisible piece is contained within a statement I made earlier “Then there is the change management work of adjusting the business to the software or the software to the business”. That first part, adjusting the business to the software, is key. Often the business itself must change to be in line with an ‘industry standard’ way of working that is pre-coded into the software and so intrusive to change, that it simply cannot be done effectively without huge effort and cascading effects across multiple downstream areas. What happens if your way of working a specific flow is more efficient than the ‘industry standard’? This is forced change and is already applying constraints. Efficiency and productivity are affected; the dysfunction slowly becomes accepted as normal.
This isn’t just anecdotal observation from my own experience. Industry analysts and practitioner discussions confirm the scale of the issue. According to Gartner and Forrester, a majority of CRM initiatives fail to fully deliver expected ROI, with users typically adopting only a fraction of available functionality and significant drop-off after go-live. Studies show that nearly 70% of companies report their CRM systems are not being used to their full potential, with roughly 43% of features remaining unused, particularly among SMBs (Cyberlobe). Less than 37% of sales reps engage with the platform daily, while as much as 79% of opportunity information gathered by reps never makes it into the system, leading to unreliable forecasts, lost productivity, and estimates of up to 27% revenue impact from incomplete or inaccurate customer data (Vantage Point). These patterns underscore how the configure-down model and post-implementation realities create systemic drag, turning what should be a productivity engine into a source of accepted dysfunction.
The tail is now very firmly attached to the dog and is already starting to send low amplitude ‘wags’ through the business.
In the next post we will discuss what happens after go-live, how the systems are changed in response to the items like those I listed previously, how the nature of the systems further constrains the business and insidiously prevents innovation and adds costs both seen and unseen.
About 90 Degree Circle
Dysfunctional CRM is a money pit. How much is yours costing you?
I advise enterprise and scaling B2B revenue teams on CRM architecture, system drift, and the structural issues that create dysfunction in their revenue engine. With 30 plus years at the intersection of business process and IT systems across ERP and CRM environments, I help organizations diagnose and resolve root cause problems, restoring functionality, operability, data quality, and process flows, so you can finally realize the full ROI your CRM system was built to deliver.
