When you are implementing new CRM functionality, stakeholders are looking to your leadership to ensure requirements and deliverables are met. The work needs to be done well –and there's often pressure to do it quickly to boot. There's often a looming deadline for go-live and a profound sense of the clock ticking.
For a good part of your CRM implementation, especially at the start, it will likely seem things are going too slow and you can't possibly imagine how you are going to meet your deadline. At other times, especially at the end, it will likely feel like time is going too fast. You may feel you need more training or have a general hesitancy about wrapping up the project. If you have a great consulting partner, you might wish to extend the project to continue to receive their support. We refer to the push and pull you are experiencing as the CRM implementation paradox. Understanding this paradox and its relationship to disruption in your organization will help you strike the balance needed to successfully implement a high performing CRM system.
The Implementation Paradox: Too Fast and Too Slow
Certain points of the CRM implementation are more likely to seem like they are going more slowly than others. In our experience, this includes requirements gathering and discovery. Folks are ready to get moving and actually see a system in action. Requirements gathering meetings can seem like they take forever! Even if you are using an agile methodology, and you skip full business and functional requirements gathering at the start of the project, you will still need to take time out for sprint planning, grooming your backlog, and retrospectives. All of those take time.
Then, almost before you know it, it's time for training and go-live. Time seems to be in warp-mode now! Maybe it feels like there are too many topics and too few training sessions. Or complex user security settings to adjust and too few days in which to accomplish all-the-things. You aren't alone - even in the best executed projects, there's often a scramble to the finish line.
Similarly, certain stakeholders may be more likely to feel or express frustration about how long the process seems to be taking. In our experience, this is usually board members or executive leadership. They need reports and analytics yesterday. Waiting for all systems to be go can be grueling. Other staff, usually program or fundraising staff and directors, are often frustrated because things are moving too fast. There's so much to learn and so little time!
One explanation for this is that executives and boards are looking at the outcomes or the metrics. For example, the burn rates or the percentage of the implementation completed. Meanwhile, staff and directors, who are still doing their very full-time jobs plus engaging in a technology build, experience almost immediate, and very significant, disruption in their day-to-day work.
The Relationship Between Disruption and Implementation When Adopting a New CRM System
Disruption is easy to underestimate but will have a direct impact on how your team perceives the pace of your CRM implementation to be, and ultimately, how they adopt that system, too. It's important to pay attention to the trend of disruption during your implementation. What do we mean by this?
During a standard implementation, disruption starts out low. Despite the time needed for requirements gathering, your team is not likely to experience radical changes to their workflow or daily tasks related to the implementation itself. Soon thereafter, though, the disruption increases and increases very significantly. The most challenging part is that the period of increased disruption lasts quite some time. Peak disruption is typically from 3-4 weeks before project go-live through go-live. Post deployment, disruption then begins to taper off during a period of ongoing support when new changes are not typically introduced.
Disruption, then, is in relationship to the percentage of the implementation completed. This is what it might look if we graphed the quantity of disruption and the quantity of implementation that has been completed over time.
The quantity for implementation is pretty straight-forward. What's the percentage completed? However, the quantity of disruption is much less simple:
Implementation = % of Technology Implemented
Disruption = Daily Responsibilities + Additional Meetings + Process Questions + Increased Communication from Consultants + Report backs to stakeholders + Learning new ways of doing things + Anxiety
The implementation line represents the point of view of those with the most decision-making power in the organization (e.g., Consultants, Executives and Board Members). The implementation line represents percentage completion; extending the line (i.e., extending the project over time) leads to higher costs. These costs are visible because they come in the form of a bill. Consultants eager to finish on time and under budget will focus on the implementation regardless of its effect on staff.
Disruption, meanwhile, is often an invisible cost. More disruption – and more work – for staff does not usually constitute an increased expense to the project budget. The first time this cost becomes visible is when the system isn’t being used because the rate of disruption was too high. By the time this cost is revealed, consultants may have moved onto another project because the technology they were paid to implement has met the functional deliverables.
Address Disruption by Increasing Capacity for Change
In order to address disruption head-on, you have to recognize the role it will play in your organization. Have candid conversations with your staff and with your consultant to assess the level of disruption at each stage of an implementation and plan for it accordingly. Your consultant should be well-versed in which aspects of a project are more likely to lead to increased disruption and to help you mitigate the negative impact on your team. Ask them directly if there are opportunities to decrease disruption, perhaps by extending a deadline, bringing on other resources, or similar approaches.
More importantly, however, your consultant should have a framework for increasing your team's capacity for change. This must include addressing current issues, accounting for contingencies or unexpected situations, and planning for future functionality or features. A framework like Now IT Matters' Digital GuidanceSM, which focuses on user adoption, system performance, and user feedback methodically increases your team's capacity for disruption and their ability to withstand change. In the long run, this benefits not only your CRM project but your team as a whole.
Tim Lockie
