Resisting the Urge to Automate Everything

The 80/20 Rule of Software Implementation - Resisting the Urge to Automate Everything by 

Andrew Schultz (15/10/11)

The rule: customize for the most common 80% of scenarios, leave flexibility for users to manually address the other 20%.

I’m certainly not claiming to be the origin of this little piece of wisdom, but I haven’t seen it written or documented anywhere. Maybe I just haven’t looked hard enough, as I learned it myself through experience rather than research. The rule’s validity has been demonstrated again and again for me, both as I’ve worked with customers to clean up implementations that were over-customized, or seen implementations I’ve been involved with getting too customization-heavy.

This rule often goes against the grain of a customer’s expectations. Customer implementation teams with inexperienced members often erroneously expect that a CRM system should and/or must account for every process and every scenario that occurs in their front office.

The most difficult part of following this rule is trying to communicate to such an internal implementation team the negative results that come from over-customization. This conversation inevitably comes at the point when you wisely push back on a request for custom functionality. When they don’t understand, they may think your implementation team is lazy or (worse) chicken, lacking confidence or unable to deliver on a particular request. It’s hard to effectively communicate that by simply giving them everything they ask for, you’d probably be doing them a disservice.

Why Not? You Write Code, Don’t You?

First of all, I’ve worked with customer implementation teams (those made up of the customer’s employees, just to be clear) with varying levels of technical experience. It’s not uncommon to have people on these teams that think the capability to write code means that anything and everything is possible. These people may be the business leaders who are accountable for the project, or they may be end-users who, from your consultative perspective, have no place being in these meetings, and who are going to fight tooth and nail for a feature that doesn’t make sense but would address a personal pet peeve of their own.

The first step in these scenarios is to explain that there are indeed limitations to what we can do with CRM, and that those limitations exist with any software product, not just the one you purchased for this project. These limitations aren’t simply technical; they’re operational and strategic as well, meaning that even without a software application supporting this process, there are certain uncommon scenarios in a business that just shouldn’t be locked into a standardized process, because they are so many and so various that the process would have to expand to an unsopportable size and complexity to incorporate each of them.

Paul Greenberg, a recognized authority in CRM strategy, wrote about staying flexible here. He notes that “Companies that have the flexibility to ‘break’ the process when they need to and the empowered employees to do the breaking will be more successful than those that rigidly adhere to the processes despite the problems it causes their own customers.” I believe this is true. That means that the job of the implementation team (consultants and internal employees) is to define the procedures that are both :

- simple enough to be understood, followed, and supported by the CRM application, and

- robust enough to address 80% of the scenarios that occur in the business

Some partners don’t do that well - or perhaps they don’t try at all. (Well, actually, I believe that many partners don’t try at all, because they don’t understand this principle, and then some of them are unwise enough to take the opposite course, actively pushing projects for more and more customization, probably to drive the project revenue up). I can name at least two Microsoft partners in my city that seem to never say no to customization requests. I’ve been involved in re-implementation or remediation projects for former customers of these partners, and I’ve been horrified at the mess of customizations that were implemented without, it would seem, any central, guiding intelligence – a massive volume of utterly a-la-carte customizations, some of them very complex and expensive, but implemented seemingly without any effort to make them a cognizant, integral piece of the solution comprised of the other customizations in the system, which were probably implemented at different times.

Why This Happens?

There are, presumably, a multitude of causes of this unfortunate result. I’ll point out two here from my experience. I’m going to use the headings ”The Company is Too Big” and “The Company is Too Small” because they effectively summarize the factors I’ll discuss in each section,but these headings would be far too simplistic on their own. These headings are not meant to imply that large or small companies are doomed to make the same mistakes, either; in each case, I’ll describe decisions which led to the result of over-customization, and which were typical of a small or a large company, but which could easily have been made differently to better effect. My purpose here is to use these situations for educational purposes; I understand and sympathize with each company’s situation and don’t mean to set them up as scarecrows for stone-throwing here.

The company is too big

During a project for a large, global company’s CRM implementation, I saw the requirements list grow and grow. The time allotted for requirements definition in the project plan was at least doubled in reality. Each time a certain piece of functionality was discussed, it would become more and more complex, often for the purpose of accomplishing objectives which were questionable in my mind, because they were very minor considerations. But this was also true of major objectives – out-of-the-box functionality that would have accomplished the purpose alone or with minor customization was passed over for complex, code-intensive options that expanded the complexity of the final solution and, therefore, the complexity of its administration and of future customization projects.

In this case, a major influence in driving this complexity was a certain part of the company that operated in a different country. This part of the business had been acquired, and was used to operating in a certain way. Their influence in the decisions made by the implementation team was almost always to add complexity. Due to situations like this one, this company’s internal systems were already very complex as a rule. This CRM project was not big enough or important enough to be a rallying point for greater simplicity, especially since the CRM system was to integrate with these very complex pre-existing business systems.

The company is too small

Another experience involved a smaller company with a need for a very robust CRM system. My involvement with this company was during a re-implementation project. My first task was to review the existing customizations in place. I couldn’t even do it in the time allotted, because of the volume and complexity of those existing customizations. Integration software, CRM plugins, workflows, scripts, and custom web pages were implemented indescriminately - and without clear documentation. For no apparent reason, functions very similar to each other were sometimes housed in different types of customizations, rather than keeping like functionality grouped together. There was even an integration running that took data out of CRM and put it back into CRM without touching any other system—not to stage and transform data, but simply to check a value and update another value.

There are various reasons that this occurred at this particular company. While not every company with fewer than 500 employees would necessarily have the same problems, smaller companies are less likely to have IT staff that have been involved in multiple, serious software implementations where proper project management guidelines were followed. They often have a hard time differentiating between ”must haves” and ”nice to haves.” The mentality is sometimes one of moving out of the basement into a world where everything is automated. With this mentality, it’s difficult for them to understand the need to pick and choose the customizations are most relevant to the core businesses.