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.

1. All staff intro:  the CiviCRM developer came to the office and gave a ‘tour’ of the database to all staff.  He covered basic and shared tasks like searching for, recording or editing a contact, entering a contribution, or creating an event.  This happened shortly after migration was complete.
2. Restricted exploration: with some admin privilege restrictions in place, staff took time to ‘explore’ CiviCRM and attempt to complete their normal database tasks.  In the process, they documented questions that came up along the way.
3. One on one: after individuals had spent some time familiarizing themselves with the CiviCRM, one on one trainings were set up with the primary database staff liaison.  Specific questions were answered and the ability to complete core competencies was confirmed.  In some cases, the CiviCRM developer was asked to come in to train on more complicated tasks.
4. Documentation: Staff was asked to document step by step instructions for completing their specific tasks in a shared in-house CiviCRM ‘manual’.  The process of writing out the steps helped solidify their new understanding of each Civi processes and provided a helpful reference for more infrequent tasks.
5. Ongoing support/training:  As staff became more comfortable with the platform over time, their interest and curiosity increased as did their desire to explore and utilize the bells and whistles that Civi offered.  Additionally, annual and seasonal events/work projects that came up over the course of a year required continued training, tweaks and customizations.  

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.