Transitioning to CiviCRM
This chapter outlines the parts that typically make up a CiviCRM project and should be read by people about to embark on a CiviCRM project. Some of this information may be obvious to experienced project managers. A comprehensive guide to project management is beyond the scope of one chapter but we have outlined things that are typically encountered in a CiviCRM project and provided pointers on some things to watch out for.
First, some pop philosophy courtesy of Cynthia Tarasco:
"Life is a series of making decisions. Some decisions are easy because they do not require a substantial investment of time or money. Deciding which flavor ice cream to buy fits into this category: if you get vanilla today you can always get chocolate tomorrow. Other decisions are much more difficult because they require substantial investments of resources, and you will be living with your choice for the foreseeable future. Adopting a new CRM fits into this category, so planning and project management are vital".
When you start out on a new CiviCRM project you should spend time thinking about:
- the people who will be involved in the project
- what the business goals of using CiviCRM are
- how you will approach the initial development
- what ongoing support you will need
- the costs associated with hosting and your IT infrastructure
- training and documentation
- change management
People and the project team
Including a wide range of people that represent the different parts of your organisation will help with delivery of your project. A mixture of management and day-to-day staff helps the team to keep an eye on the big picture as well as ensure that the project is ultimately useful to frontline staff.
You'll be exploring new territory with your CiviCRM installation and this can sometimes be stressful. It might be helpful to share project management of the project with others who can give you a different perspective and moral support when you need it!
Managing a CiviCRM project will require a major time investment from people within your organisation, even if you employ an external consultant. Organisations often under-estimate the amount of time that will be required from their staff in implementing an IT project - such as training, modifying existing processes and providing new or updated information to relevant people. It's not something that can be tacked on to the end of an already busy schedule and this should be taken into consideration.
You should have a good idea of the goals for implementing CiviCRM. This could be something like: reduce administrative work in managing events by 25% or manage 25% more donations with the same staff. The goals should be SMART (specific, measurable, attainable, relevant, timely)!
These business goals will help you in directing and managing your project. For example, if the project group for example want some customization that requires budget and effort, your business goals will help you decide one way or the other. The business goals will help you to focus on why you are implementing CiviCRM and what you want to achieve in the long run.
It often makes sense to break development up into smaller more manageable sections, which can be implemented in discrete stages or iterations. A common first phase of development is to choose something simple to implement in CiviCRM, or specific functionality for a team who can then act as CiviCRM evangelists within the organisation.
Implementing in stages allows staff to get used to changes gradually without feeling overwhelmed, and gives the developer or implementer the ability to be responsive to feedback from users during the development process.
Another reason that people choose to develop iteratively is that it is very hard for users to correctly or fully articulate their requirements at the start of the project. Giving users hands-on experience of an early version of the system helps them understand how it works and what is possible. They can then provide valuable feedback and might articulate requirements that they haven't thought of previously.
Implementing your CMS (Drupal or Joomla!) either before or after implementing CiviCRM is another convenient way to split up a CiviCRM project. As well as the normal advantages of breaking up the development into manageable chunks, this helps staff understand the important differences between a CMS and a CRM.
Pilots help to reduce risk during a project implementation. For example, rather than moving your organisation's entire event management infrastructure to CiviCRM, run one pilot event using CiviCRM and evaluate it. You can then incorporate the learning back into the development process.
Ongoing support and development
It is a mistake to think about a CiviCRM project as a one-off development that will meet the needs of your organisation for the foreseeable future. Organisations constantly change and evolve and your CRM should evolve with you, otherwise it will eventually become out-of-sync with the organisation.
Once you have been using CiviCRM for a while and staff are comfortable with it, you will likely want to take advantage of other functionality. Each improvement or new piece of functionality that you decide to implement in CiviCRM will take resources, so you'll need to plan for these.
Even if your organisational needs don't change, there are ongoing support implications, including:
- keeping your site up-to-date with security patches
- upgrading to the latest version of CiviCRM (not necessary, but CiviCRM is improving all the time and your users will thank you for the improved usability and functionality each time you upgrade)
- upgrading the CMS (Drupal or Joomla!)
Training is a significant aspect of most CiviCRM projects. Your training could take many shapes and sizes depending on your users, but it often makes sense to spend resources on formal and reusable training resources (user guides, lesson plans and so on).
CiviCRM's range of functionality can be overwhelming at first (especially to the less technically-minded). Remember that staff who were not involved in the project's early stages will need to have concepts explained clearly to them - things that are obvious to you may be quite foreign to others.
Trying to cover everything in one training session probably won't be effective; your staff will need time to digest the new ideas. Instead, hold smaller training sessions that introduce concepts and specific functionality, followed by periods of testing, piloting and feedback. Tailor your training for your audience: not everyone needs to sit through a two-hour training session on how to manage events if there is a single person responsible for event management and planning. And where possible, involve staff in training other staff members as this increases the sense of ownership and helps to embed learning.
Training is also ongoing. New staff will need to be trained, users familiar with the system can benefit from learning about more advanced topics, and staff will need further training when there are significant upgrades or new functionality added. If you plan to use CiviCRM for any large or mission-critical events, allow adequate time for additional staff training and testing.
Hosting and infrastructure
Hosting is a key aspect of any CiviCRM project. You will need to provide maintenance of the server on which CiviCRM is stored, and have someone available to fix problems that inevitably occur from time to time. If your site needs to be accessible 24 hours a day, you should have a support agreement with your ISP that covers this. Ensure that your budget is sufficient for appropriate hosting, and that effective backup procedures and policies are in place.
Keep in mind that in the hosting provider world, you get what you pay for. In many cases, cheap hosting providers keep their prices down by limiting the services or flexibility they provide. CiviCRM doesn't work well on poor hosting, and under-budgeting for hosting may lead to other problems. Similarly, make sure that the computers your staff are using are powerful enough to provide a good experience with CiviCRM.
Introducing a new (or the first) CRM will cause changes in work flow and processes at your organisation. These changes may be "political", practical or technical. Either way, a lot of change at the same time can be difficult and stressful.
To mitigate this, give staff time to accept and support each change so that they share in ownership of the new system rather than feeling as if something has been forced on them. Focus on simple tasks at the beginning of deployment and introduce more difficult tasks as staff understanding of the system grows. Show staff how the new system will make their work easier and where their feedback has been incorporated.
Good planning can minimise the risks around change, but it is important to be flexible within your plan; unforeseen things often occur, and a rigid plan could prevent you from reaching the best solution.