Methodology for Both Large and Small Businesses
The Challenge
Implementing CRM is not quite the same as implementing web sites, ecommerce, ERP or other enterprise class business applications. It is unique and such projects have characteristics that reflect the primary stakeholders: sales, account management, customer service, reseller managers, and direct marketers. These are the rainmakers, the people who face the brands, marketplace and customers on both a 1-1 basis and “en masse”. They are a special and needy audience. They are under a lot of pressure, often highly performance compensated (I am one and it takes on to know one).
So, what are the characteristics of CRM that cause it to need a special framework to implement it in a way that creates a kind of plurality of acceptance and critical mass needed for success? And just what are the first principles that give shape to the project, including a structure for ongoing governance?
Characteristics
Sales processes are necessarily flexible and pragmatic. They are subject to the whims of the competitive marketplace, the culture of the industry and the ideas of the revenue-generation leadership. These approaches can vary dramatically between businesses using the very same technologies and be assured the same tool will need to embrace inevitable changes in any one business over time—your business. But the system must accommodate any mix or change in these ideological influences over time. This is not true of ERP, SCM and HCM. These concepts are reflected in web development and to some extent in ecommerce.
Modern CRM is complex: It covers a lot of ground. CRM systems have been mature for over 20 years, well before Salesforce conquered the world with cloud CRM, followed closely by Microsoft Dynamics and SAP’s lineup. Since Rome wasn’t built in a day, you need to be careful about priorities, and yet again flexible.
CRM is perceived as risky and intrusive: The user community will be disinclined to allow too much transparency and scrutiny. They reason that their end results are all the business needs to inspect, not all the work, conversations and transactions leading to ultimate conversion. They are suspicious of mechanics that restrict or automate their natural impulsiveness and the subjectivity that make them great. Bundle this all up, and you undertake risky business when you try to deliver a unifying technology.
CRM is political: Because it is subject to conformations as determined by the audience, who wish to protect their “special sauce” in terms of how they do their work, their opinions about CRM, its functionality, project priorities, the data model and business processes run strong. This creates a more chaotic and dynamic project environment. People don’t want to be seen as wrong about the way they make it work, and they don’t want one team’s configuration decisions to force their hand.
First Principles
CRM is not seen as indispensable to the intended users. Therefore, unless it contains both benefits and obligations, it will either be seen as a bit of an intrusion and data entry drain on the users who must interact, or as an optional, occasional ad hoc source of information. Nobody who achieves their quota without properly using their CRM will be fired. Use of the system is more of a negotiation between management and the user community. Users rightly ask: “what’s in it for me?”
The excellent is the enemy of the good. Don’t try to perfect the initial deployment. There is simply too much subjectivity in its form and function to make chasing each user’s whimsical requirement profitable. Instead, seek consensus on what is “good enough” and zero in on that. Clearly this rules out waterfall approaches.
CRM is about unifying the business around the notion of the marketplace. This means there is a need to scope enough goodies for all participants. There is a level of both necessary and sufficient functionality that must be baked into the deployment in order to give the business escape velocity from the old systems and conventions that they rely on in the current state. This clearly rules out pure Agile.
Get technology advice from beyond your solution provider/partner. Not only do they need to make a profit on you—and will avoid some difficult use patterns that the application does not do well, but in case you haven’t noticed, IT consultants are classic victims of the cobbler’s show syndrome: they rarely take their own advice. Seek outside management/IT advice for helping both business constituents and vendor/suppliers.
Well, that all sounds like the project to end your career!
Don’t worry; there’s hope. Take stock in your methodology. It is necessarily hybrid in nature; not waterfall but is like a fabric with both holistic and Agile threads.
I've implemented CRM for many companies large and small, across most industries and business models, and around the world on 6 continents. I’ve seen both good and bad approaches; and I’ve witnessed various degrees of cooperation from the entire delivery team. I’ve settled on one methodology that works every time, regardless of your choice of application software. It works for implementations, upgrades, acceleration projects, integrations and roll-outs. But the business needs to understand how it works and why. All stakeholders need to embrace the process, or there will be needless misunderstandings.
To begin at the beginning (or before it), the business leaders at the VP level, coached by IT leadership must be engaged and they need to have a common understanding of CRM. This is executive envisioning; and don’t underestimate the need for this. It’s not fluff. The business needs to set strategic priorities and agree to what is possible and what is currently now working that needs fixing. IT’s direction must fit the business strategy and agreement on ROI. The outcome of this is strategic scope. This critical document will inform the subsequent projects and their scope, which will make it easier to bring in technology vendors.
With that in place, you need a 3-staged delivery process, supported by deliverables that ensure “best-practice”. There are three gates and they are necessarily sequential. Don’t move on until you are finished with the previous gate. If you are tempted to do that, cut the scope of the entire project, but stick to the methodology. Bend it, don’t break it.
The three gates are:
1. Discovery: first seek to understand. There are 2 aspects:
Current state documentation: as-is business process and work rules, screen shots that represent source documents.
Business requirements gathering. This is Agile story-based: what is needed? What do you not do that you should? What do you do now that you shouldn’t? Cast a wide net., and rationalize the list of stories, kicking some out for future scope and removing duplicative requirements.
This gate takes allows the entire business to throw-in and work out their differences. It’s the first step toward acceptance.
2. Design: The future state. It is strictly dependent on the business requirements list. It covers all accepted requirements and creates new data model, user interface and process flow, using guidance from the solution partner. There is some creativity in this blueprinting effort, and some measure of trust. When the designing architect can show the project steering team that the new functionality covers the requirements, you are ready to execute.
This gate allows the design to trace to the requirements but gives the architect wiggle room to innovate and apply new technical features to the solution.
The right design will be both practical and fit for purpose, not seeking to boil the ocean or seek perfection.
3. Execution: Execution is configuration, development, integration, data migration, testing and training. This is where Agile kicks in. Execution should be done in time-boxed Sprints, complete with Sprint demo, release memo, user acceptance feedback and in the Sprint timeline, and traceability to the design. Stakeholders get to see it coming into existence incrementally and there is time to adjust if the design does not meet the test of “the good”, not “the excellent”. Execution is done in a development environment and acceptance in a stage environment. Launch is done in the production instance when all contingencies are met.
Execution in this Sprint pattern ensures the user representatives can step up and agree to the nature and spirit of the build, and allows PM's to manage scope, while gaining incremental acceptance. By the last Sprint, by definition the solution has been accepted and the remaining task is to sell the sellers with strong communications, training, and support.
A note about governance. Be ready to rinse, repeat from ideation and scoping through the 3 gates again for each defined project. CRM never sleeps. CRM is never done.
A note about phased and staged rollouts, including global deployments: There will be a need for overlapping regional releases with new functional components, and there are best-practices in how to coordinate this in an enterprise/global setting.
Ascendant Group Inc. has the experience and tools to drive project success and adoption at all levels in your business. Contact us for ways we can reinforce your next CRM project with methodology, advice and project management.
Comentarios