Implementing a Donor Database by Guest Star Cheryl Gipson

Michelle Murrain at Zen and the Art of Nonprofit Technology is hosting a carnival on “Nonprofit Data Management: from slips of paper to CRM.” I think that’s a good topic, so I’ve asked my esteemed colleague Cheryl Gipson who is Network for Good’s Director of Nonprofit Services to contribute the following post.  When the full CRM carnival goes up on Monday, I’ll link to it so you can read what other folks think!

Before I turn things over to Cheryl, I’d like to cover the basics.  CRM means “customer resource management”—it’s software that allows you to centrally store and access information about donors or other constituencies.  Why do you need this?  So you can better organize fundraising data and more easily build a long-term, personalized relationship with donors.  You can learn more at TechSoup about why you might want to get a database.  If you’d like to get on Network for Good’s email list of free tips on CRM, email me at robinhood at networkforgood.org.

Here’s Cheryl on how to actually get your donor database in place successfully.  She offers a helpful checklist.

Steps to a Successful CRM implementation from Cheryl Gipson

Converting or implementing a CRM database is a big step for a nonprofit organization.  Generally a conversion or implementation represents a sea-change within the organization, brought on by management changes, fundraising need, programmatic expansion, or extreme discontent with current systems.  The data within a database is one piece of the data conversion pie, as the steps surrounding the data, and what the data represents (donors, money) are the life-blood of a nonprofit organization.

A successful data conversion/implementation has several component parts:

*If an implementation, a plan to establish workflow and data structures for processing incoming gifts and reconciling data with accounting

*If a conversion, an established plan for how to maintain current workflow and data structures while the data is being converted.
---Parallel processing:  two systems are run simultaneously (legacy/new) parallel to one another with duplicate gift processing
---Gradual Legacy Switch:  the new system is established and people work in the new system with new data after processes have been established, keeping the legacy system running for old data.  Legacy data is imported on a time-based plan
---Planned Legacy Switch:  a date is set for the new system to go live.  Legacy data and systems are re-worked, a cut-off time is established for the old system, several test conversions are conducted, and the new system goes live.

*A strong internal champion for the database project with a database administration background.  This individual will work closely with the implementation consultant to implement new procedures, train themselves in the new product, document the procedures within the nonprofit organization and train other staff

*A strong executive champion for the database project willing to understand the importance of investing time, money, and human resources into the success of the project

*A fundraising database implementer who understands fundraising strategies, gift processing workflow, nonprofit accounting laws, and best-practice coding structures for development reports.  They must also be technically savvy in multiple fundraising databases and understand how to write queries, import and export data, manipulate and “clean” data using tools such as Excel or Data Junction

*A mutual understanding between the nonprofit organization and the database implementer that converting a database involves organizational change, and this can be stressful and threatening for employees.  Both the database implementer and the nonprofit organization will need to establish in the project plan the metrics and deliverables that comprise success

*Detailed procedures/documentation on the part of the database implementer for contact and gift counts.  Verifiable data transfer is the metric that can be used for the client to understand the success of the conversion and helps to create confidence from both sides

*Training of new procedures and workflow.  This will be specific to each organization

It is also worthwhile to note that the size of the database or the size of the organization do not diminish the complexity of a database conversion, because the issues of coding structures, workflow, fundraising practices, and accounting reconciliation are all the same.  What’s different is scale.  Small nonprofits are in the uncomfortable position of having to handle these issues without the same level of human or monetary resources enjoyed by large nonprofits.

THE FULL CARNIVAL IS HERE if you’d like to read it.