At the request of our CiviCRM developer, I've typed up a 'case study' on our successful transition to CiviCRM with an emphasis on staff training.
In early 2012, Donate Life Northwest, a small Portland non-profit, made the transition from eBase (an outdated open-source filemaker database) to CiviCRM. Prior to this conversion, over a year was spent investigating new database options. Organizational needs were clarified and wish list items identified with extensive participation from the entire staff. The database would be used for managing contributors, volunteers, fundraising events and a large number of volunteer related outreach events. Staff documented the processes they were currently using for contribution management, event tracking and volunteer management. They identified what functionality was critical to keep and what they would like to improve or do differently.
The final database contenders were between CiviCRM and Salesforce. Both platforms were deemed capable of handling the organization’s core needs as well as improving overall database functionality. The massive user community of Salesforce was attractive, however CiviCRM was ultimately chosen for the following reasons: 1) it was conceived and designed for non-profits, compared to a for profit sales platform retrofitted for nonprofit use, 2)up front implementation and customization costs were significantly cheaper, and 3)the local CiviCRM developer being considered was more friendly, personable and able to communicate effectively with less tech savvy staff members than the local Salesforce equivalent.
Prior to migration, much emphasis was placed on setting realistic expectations for both staff and management. All staff clearly understood going into the process that not everything would translate perfectly. In some cases we would need to find new ways of doing things that wouldn’t necessarily be considered an improvement from the old ways. Additionally, a realistic training timeline was identified and supported by the management team, including planning and budgeting for continued support and training costs well past the initial migration date.
Throughout the migration process, one staff person acted as the primary communication liaison between staff, the CiviCRM developer, the eBase developer, and the Drupal site developers. This person was able to gain a holistic picture of the unique ways in which different departments would be using the database as well as the common uses shared across departments. Ultimately each staff person was asked to document all the ways in which their position interacted with the database -this was called their “core competencies.” Staff was then trained through a series of steps.
Almost a year out from adopting CiviCRM, staff sentiments continue to be almost entirely positive. The need for ongoing training or support has slowed significantly. “Bugs” or issues do pop up from time to time - maybe once or twice a month. Some are true bugs within CiviCRM, others are user errors/training gaps, but at the end of the day, CiviCRM has been a significant improvement from the previous database. Additionally, with the new staff members hired since the conversion to CiviCRM and it has proven to be significantly more intuitive and easy to learn than the old database.