Planning Your CRM Implementation Using CiviCRM

Barriers to success

Constituent Relationship Management initiatives can be difficult. At their best, they involve changing external relationships and internal processes and tools. Externally, the experiences that the constituents have of your organization need to change, so that they provide more value and fewer barriers to involvement. Internally, business processes and supporting technological systems need to change in order to break down departmental operations' silos, increase efficiencies, and enable more effective targeting, improved responsiveness, and new initiatives. The success of the CRM projects often depends on changing the behavior and attitudes of individuals across the organization and replacing, changing, and/or integrating many IT systems used across the organization.

Succeeding with the management of organizational culture change may involve getting staff members to take on tasks and responsibilities that may not directly benefit them or the department managed by their supervisor, but only provide value to the organization by what it enables others in the organization to accomplish or avoid. As a result, it is more challenging to align the interests of the staff and organizational units with the organization's interest in improved constituent relations, as promised by the CRM strategy. This is why an Executive Sponsor, such as the Executive Director of a small or a medium-sized non-profit organization, is so important.

On the technical side, CRM projects for reasonably-sized organizations typically involve replacing or integrating many systems. Configuring and customizing a single new software system, migrating data to it, testing and deploying it, and training the staff members can be a challenge at the best of times. Doing it for multiple systems and more users multiplies the challenge. Since a CRM initiative involves integrating separate systems, the complexity of such endeavors must be faced, such as disparate data schemas requiring transformations for interoperability, and keeping middleware in sync with changes in multiple independent software packages.

Unfortunately, these challenges to the CRM implementation initiative may lead to a project failure if they are not realized and addressed. The common causes for failure are as follows:

• Lack of executive-level sponsorship resulting in improperly resolved turf wars.
• IT-led initiatives have a greater tendency to focus on cost efficiency. This focus will generally not result in better constituent relations that are oriented toward achieving the organization's mission. An IT approach, particularly where users and usability experts are not on the project team, may also lead to poor user adoption if the system is not adapted to their needs, or even if the users are poorly trained.
• No customer data integration approach resulting in not overcoming the data silos problem, no consolidated view of constituents, poorer targeting, and an inability to realize enterprise-level benefits.
• Lack of buy-in, leading to a lack of use of the new CRM system and continued use of the old processes and systems it was meant to supplant.
• Lack of training and follow-up training causing staff anxiety and opposition. This may cause non-use or misuse of the system, resulting in poor data handling and mix-ups in the way in which constituents are treated.
• Not customizing enough to actually meet the requirements of the organization in the areas of:
  • Data integration
  • Business processes
  • User experiences

• Over-customizing, causing:
  • The costs of the system to escalate
  • The best practices incorporated in the base functionality to be overridden in some cases
  • User forms to become overly complex
  • User experiences to become off-putting

• No strategy for dealing with the technical challenges associated with developing, extending, and/or integrating the CRM software system, leading to:
  • Cost overruns
  • Poorly designed and built software
  • Poor user experiences
  • Incomplete or invalid data
  Unlock access to the largest independent learning library in Tech for FREE!
  Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
  Renews at £15.99/month. Cancel anytime
  START FREE TRIAL

However, this does not mean that project failure is inevitable or common. These clearly identifiable causes of failure can be overcome through effective project planning.

Perfection is the enemy of the good

CRM systems and their functional components such as fundraising, ticket sales, communication with subscribers and other stakeholders, membership management, and case management are essential for the core operations of most non-profits. This can lead to a legitimate fear of project failure when changing them. However, this fear can easily create a perfectionist mentality, where the project team attempts to overcompensate by creating too much oversight, too much contingency planning, and too much project discovery time in an effort to avoid missing any potentially useful feature that could be integrated into the project. While planning is good, perfection may not be good, since perfection is often the enemy of the good.

CRM implementations risk erring on the side of what is known, somewhat tongue-in- cheek, as the MIT Approach. The MIT approach believes in, and attempts to design, construct, and deploy, the "Right Thing" right from the start. Its big-brain approach to problem-solving leads to correctness, completeness, and consistency in the design. It values simplicity in the user interface over simplicity in the implementation design. The other end of the spectrum is captured with aphorisms like "Less is More," "KISS" (Keep it simple, stupid), and "Worse is Better". This alternate view willingly accepts deviations from correctness, completeness, and consistency in design in favor of general simplicity, or simplicity of implementation over the simplicity of user interface. The reason that such counter-intuitive approaches to developing solutions have become respected and popular is the problems and failures that can result from trying to do it all perfectly from the start.

Neither end of the spectrum is healthier. Handcuffing the project to an unattainable standard of perfection, or over-simplifying in order to artificially reduce complexity will both lead to project failure.

There is no perfect antidote to these two extremes. As a project manager, it will be your responsibility to set the tone, determine priorities, and plan the implementation and development process. Although it is not a perspective on project management, one rule that will help achieve balance and move the project forward is "Release early, release often." This is commonly embraced in the open source community where collaboration is essential to success. This motto:

• Captures the intent of catching errors earlier
• Allows users to capture value from the system sooner
• Allows users to better imagine and articulate what the software should do through ongoing use and interaction with a working system early in the process

Development methodologies

Whatever approach your organization decides to take for developing and implementing its CRM strategy, it's usually good to have an agreed upon process and methodology. Your processes define the steps to be taken as you implement the project. Your methodology defines the rules for the process, that is, the methods to be used throughout the course of the project. The spirit of the problem-solving approaches just reviewed can be seen in the Traditional Waterfall Development model and in the contrasting Iterative and Incremental Development model.

Projects naturally change and evolve over time. You may find that you embrace one of these methodologies for initial implementation, and then migrate to a different method or mixed-method for maintenance and future development work. By no means should you feel restricted by the definitions provided, but rather adjust the principles to meet your changing needs throughout the course of the project. That being said, it's important that your team understands the project rules at a given point in time, so that the project management principles are respected.

The conventional Waterfall Development methodology

The traditional Waterfall method of software development is sometimes thought of as "big design upfront". It employs a sequential approach to development, moving from needs analysis and requirements, to architectural and user experience, detailed design, implementation, integration, testing, deployment, and maintenance. The output of each step or phase flows downward, like water, to the next step in the process, as illustrated by the arrows in the following figure:

The Waterfall model tends to be more formal, more planned, includes more documentation, and often has a stronger division of labor. This methodology benefits from having clear, linear, and progressive development steps in which each phase builds upon the previous one. However, it can suffer from inflexibility if used too rigidly. For example, if during the verification and quality assurance phase, you realize a significant functionality gap resulting from incorrect (or changing) specification requirements, then it may be difficult to interject those new needs into the process. The "release early, release often" iterative principle mentioned earlier can help overcome that inflexibility. If the overall process is kept tight and the development window short, you can justify delaying the new functionality or corrective specifications for the next release.

Iterative development methodology

Iterative development models depart from this structure by breaking the work up into chunks that can be developed and delivered separately. The Waterfall process is used in each phase or segment of the project, but the overall project structure is not necessarily held to the same rigid process. As one moves farther away from the Waterfall approach, there is a greater emphasis on evaluating incrementally-delivered pieces of the solution, and incorporating feedback on what has already been developed into the planning of future work, as illustrated in the loop in the following figure:

This methodology seeks to take what is good in the traditional Waterfall approach— structure, clearly-defined linear steps, a strong development/quality assurance/roll out process—and improve it through shorter development cycles that are centered on smaller segments of the overall project. Perhaps the biggest challenge in this model is the project management role, as it may result in many moving pieces that must be tightly coordinated in order to release the final working product.

Agile development methodology

Agile development methodologies are an effective derivative of the iterative development model that moves one step further away from the Waterfall model. They are characterized by requirements and solutions evolving together, requiring work teams to be drawn from all the relevant parts of the organization. They organize themselves to work in rapid one to four-week iteration cycles. Agile centers on time-based release cycles, and in this way, differs from the other methodologies discussed, which are oriented more toward functionality-based releases.

The following figure illustrates the implementation of an Agile methodology that highlights short daily Scrum status meetings, a product backlog containing features or user stories for each iteration, and a sprint backlog containing revisable and reprioritizable work items for the team during the current iteration.

A deliberate effort is usually made in order to ensure that the sprint backlog is long enough to ensure that the lowest priority items will not be dealt with before the end of the iteration. Although they can be put onto the list of work items that may or may not be selected for the next iteration, the idea is that the client or the product owner should, at some point, decide that it not worth investing more resources in the "nice to have, but not really necessary" items.

As one might expect, this methodology relies heavily on effective prioritization. Since software releases and development cycles adhere to rigid timeframes, only high priority issues or features are actively addressed at a given point in time; the remainder issues falling lower on the list are subject to reassignment for the next cycle.