Some say the biggest risk and pain point in a CRM implementation or migration project is training, others say it is executive engagement. Still others claim the pitfalls lie in the way the system is customized or integrated.
I’ve led CRM implementations for some of America’s largest companies and I’ve deployed CRM on six continents for a variety of business models and across many industries. I feel I can confidently say that the biggest challenge and risk is in the area of change management and in particular, the methodology used to implement the solution. There are many technical and non-technical issues that are unique to CRM deployments, but the approach and sequence of work, and how the company’s resources are focused on the project makes all the difference in the world. This is true regardless of which technology you choose, or which technical partner helps you implement.
If you have an IT or enterprise success methodology that you found successful for ERP or web site or data warehouse, or ecommerce, throw it out. CRM is unique, and you don’t want to take chances.
What methodology is best overall and what works? While there are tweaks to the framework that can be built to meet the business scale/complexity and the culture, the one methodology always stands out, and sometimes rubs CIO’s and executives the wrong way if another approach was used for ERP, etc.
Let’s call the project and work structure, “CRM-Agile”. It borrows heavily from Agile frameworks but aligns to a set of key business focus areas that the business has identified as important to them. This means, it deviates from pure Agile in that it must hit all high-level process and focus areas in the initial release, which feels more like waterfall in principle.
Here are the keys to CRM-Agile in a nutshell:
What follows must be understood and embraced by the CIO and key business executive sponsors before the work begins. This is an important first step. Agreement to the methodology at the corporate level is important. The framework is received from the top down. The solution definition from the bottom up.
Governance: the process of implementing CRM is not a one-time event. It will be an ongoing evolutionary program to continuously manage. Therefore, a governance process must begin and end all projects. This is a steering team of executives and the CIO. CIO should not run it, but often must glue the executives together and keep them engaged. The steerco is responsible for the roadmap and budget. Likely they supported the software selection efforts.
Solution Scope: CRM as a solution should be empowered to impact and/or support all customer-facing business touchpoints. Maybe its complete mandate does not manifest on day-one, but as a software solution domain, it must be seen as a broadly capable application. Other applications may need to give it deference as the “system of record” for specific data and process. Yet it is meant to be shaped and designed to accommodate different business rules. So it is somewhat creative and flexible in its end state. Therefore, you need a coalition of thought leaders who can contribute in an atmosphere where the bases are covered, and each focus work group is represented. This should include all regions, all sales divisions, all customer care channels and marketing. CRM cannot be driven from one ego or mind. You cannot have one executive that runs over the rest, even if such a prominent leader exists. There must be balance and representation, so the requirements team cannot be centralized.
CIO’s Role: The CIO must be the resource driver but not the rule maker or architect. CIO’s make sure it meets the needs of security, performance, reliability, compliance and extensibility. They can supply the PM and technical resources, but the CIO should not dictate any other conditions or fit. The CIO’s resources are important to assuring delivery and in the case of several interoperating systems, the inter-application integration architecture.
Roadmap: The stakeholder’s broad business needs must be declared and scoped with CIO and partner consultation and an accumulation of scope demands for the initial release must be seen as what is both necessary and sufficient to succeed. No more and no less. This means there must be a roadmap, and the journey toward road-mapping needs wise counsel so the art of the possible meets the science of the practical. That scope for the first release is “Phase 1”, and that implementation project is holistic in its design. Getting there takes a little time to get everyone on the same page.
Discovery: After the roadmap is made clear to the organization and budgets and timing is shared/ accepted, the next project module is “discovery”, which is best done in process more closely aligned to the Agile model, the collection of user stories. However, this is not done in brainstorming workshops. All requirements begin with the current state and must either be expected to conform to a modern version of current practice, or perhaps drastically change things that are not working well today. The stories should not be written in such a way as to bind the architect to same-old. The requirements teams must be somewhat tolerant to more modern improved solution approaches. Discovery includes current state analysis and notation of deviations from best practice. Seek the counsel of your partner. This module ends with a rationalized list of widely sourced needs that fit the scope.
Design: this process is the generation of instructional documents that describe how the solution will meet the requirements in the future state. Often there are workshops to help conceive of the new data model, user interface, business logic and process definition. The design is aligned to scope and covers the items on the requirements list from the discovery stage. The functional design is collaborative but should proceed from the business architect. The technical design proceeds from there and prescribes how to make the solution work to satisfy the functional design. The work team the helps specify and agree to a design is a smaller core team, not as democratic as the discovery stage. Designs should be signed off. And only afterwards can be developed. Until this module is largely complete, don’t pin yourself down on the calendar.
Development: this stage is done on a schedule that conforms to Agile Sprints, which are time-boxed; usually 2 or 3 weeks. The core team uses a coalition of user-acceptance people who can agree to the executed configurations as the are completed in Sprints. This gives the execs and core team the ability to mark progress. You will need a minimum of three technical environments, dev, stage and production. Dev is for authors of code and configs (including unit testing), stage is for user acceptance team including regression analysis, and production is used for final accepted efforts for the full user community (unused until launch). Data usually goes straight into prod. Development includes configuration and customization as well as integration. Begin development only on work that can be worked on while other aspects of the design are still being defined. Do not hyper-Agilize this. CRM must be coherent; overlapping development and design will produce asymmetry in many unexpected places, which will cause conflict and rework.
Acceptance: Development is presented in a Sprint demo and a release to Stage. It is reacted to by the user acceptance team-- a small group of resources who are trained to use CRM to accept CRM. Developed functionality is accepted by use of the principle of “Qui tacet consentire videtur”, Silence is Consent. The reason this is so important is, nobody will have incentive to sign-off because they are afraid to put their name on the line, and then you have to abandon Agile and the schedule and move toward waterfall in order to get a sense of perfection. This is a huge mistake. At the end of the Sprint, what was not noted for change is assumed to be good enough for now (in Agile if you goofed a bit here, you iterate and adjust in a later Sprint). Misunderstanding this will likely be disastrous. For acceptance you will need a feedback tool that is certain and the PM’s (client and partner) need to rule on which feedbacks are in bounds and which are not.
The Stage environment will accumulate solution files until the time of go-live (the launch sequence time period). At this time, a code/config freeze must be established, data moved and training logistics/curriculum prepared. The final Sprint usually includes user-security (roles) testing.
Launch is a full-court press, with communications, executive reinforcement, and tracking of who is being trained and how they are doing. A support team will work side be side in-person as needed, and a tech support team will be ready to modify any break-fix issues and rush them to production. The period of time that is 2-4 weeks after launch is stabilization, learning curve, and data conformations by the user community. Much of the customer data will need fine-tuned improvements and new data should be introduced and validated by those who govern data and process. This can be a project of its own. During the post-launch break-in period, you will begin planning phase 2 on your roadmap, which begins with confirming and adjusting it to new realities. Go back to your steering team and repeat the process.
PM: All of this is guided by a weekly project manager’s tactical meeting, where client and partner PM’s meet and assure pace, cost, scope and resource harmony are being met, taking action as needed. They report to the steering team for assurance and guidance.
Ascendant Group has decades of experience with delivery frameworks, deliverables and project management approaches that win. We have a mature and time-tested delivery model that is proven to reduce risk and accelerate progress.
Please contact us for more information about our methodology and project management services.