The maxim "Fast, cheap, or good--pick two" is true.

You want the technology to be forward-looking but also want to avoid shiny object syndrome.

You want to make a reasonably quick decision but also need to get input and buy-in from stakeholders.

You want to think big but don't want to neglect operational details.

The system needs to be intuitive for fundraisers but streamlined for data entry. 

It needs to be easy to get reports from the database but it also needs to support complex selection criteria.

How can you know what you don't know (e.g., what a new database can do when you only know what your current one does--or doesn't do, what you'll need in the future)?

There are literally hundreds of choices. How do you get down to one?

Have you experienced this "analysis paralysis"?  How have you solved it (or have you)?

What the Customer Wanted

It's a tough problem.  Here are a few approaches (other than locking down data entry):

1. Policies. You need clear data entry standards.
2. Security. You need to control who can make changes and what they can change.
3. Training. No one gets access to change data without training on your policies. Training should be targeted to role. You don’t need a week of training to enter a contact report.
4. Monitoring. Someone (or multiple someones) needs to review new and changed entries.
5. Retraining. When people make mistakes, bring it to their attention. Some organizations make that person fix the mistake. If they continue to make mistakes, you need to retrain them and be prepared to take away their data entry access.
6. Automation. You should at least run reports on a regular to look for errors. You may be able to automate some fixes. You might also use vendors to perform cleanups like merge/purges on duplicates.
7. Acceptance. Some things have to be fixed by your office or by Development Services. No one is going to fire an effective fundraiser because she’s bad at data entry (although they might get her an assistant who will handle the entry). Donors will give online and misspell their own names, or leave the caps lock on.

Decentralized data entry is efficient and is the only practical approach at some organizations. But the more people you have entering data the more problems you’ll have with quality control. If no one's in charge of quality control you're going to have a database full of garbage.  For more on this, see my posts:

New Year’s Resolution: Be Good To Your Data

Best Practices for Managing a Database

The Cloud offers you constituent relationship management (CRM) software that's less expensive, easier to maintain, more accessible, more intuitive, and with greater flexibility and capacity than you've ever seen before.

How much would you pay for such a system?

Would you believe me if I told you...you can get it for free? Yup, free.

When talking about "free" software I think it's important to define the limits of free. There's free-as-in-beer and free-as-in-puppies. Defining business rules, codes, and reports, converting data, configuring screens, and training users on the new system and policies are not simple tasks. I keep hearing of small nonprofits that chose a database because it was "free," became overwhelmed, and dropped it.  Donor databases need care and feeding during implementation and throughout their lifetimes.  This often requires hiring consultants who have experience with these systems free.  "Free" can quickly become expensive.

We’ve been involved with responding to many RFPs over the years and I have a general inquiry that is in your bailiwick. I often see RFPs that are quite lengthy and well-considered, and looking for a system that has huge strategic value to an organization, but the required turn-around time to respond to the RFP is very short – often only 2 or 3 weeks.  I then see software vendors, who are already busy with other prospects, scrambling to pull together responses and often (quite frankly) not able to deliver their best because of the timeframe. Finally, I’m often witness on the client side to the returned RFP information languishing for weeks beyond their own deadlines (and/or this being characteristic of earlier deadlines in designing the RFP). What’s the thought behind requiring quick responses from the vendors? Or do the clients often not understand that vendors are working with multiple other organizations at the same time? It seems to me that if response deadlines were less compressed, vendors could craft a more appropriate response in a less stressful manner and that organizations would get higher quality and value from the responses.

My response:

Hi Keith,

You know the office proverb: "Bad planning on your part does not constitute an emergency on my part." But if you're a vendor it often does.

In most cases I don't think nonprofits understand what they're asking of the vendors. I advise my clients to allow 2 weeks for a simple Request for Proposals and up to 6 weeks for a complex one. At the same time many nonprofits don't understand what's involved in reviewing RFP responses. They haven't thought about how they'll score each one, and may not have set aside staff time (or enough staff time) for the task. So even if the turnaround is driven by real deadlines on the client's side, they're too overwhelmed by the responses to turn them around quickly.

A more cynical possibility is the dark side of RFPs -- the winner was predetermined but the organization was required to get multiple bids. That could explain the unrealistic turnaround time--the organization knows the chosen vendor can meet the timeline (and the RFP may have even been created using a template supplied by that vendor). The delays in getting back to bidders could still be legitimate overwhelmedness. They could also mean that the other bids weren't that important to begin with so there's no rush to respond to those vendors.

What do you think?   If you're with a nonprofit, do you think your RFP deadlines are reasonable and realistic?  If you're with a vendor, how do you cope with these sometimes-artificial emergencies, and with the RFP process in general?  Are you one of the many who simply do not respond to over-the-transom RFPs?

Resources:

My article Finding the Perfect Fundraising Database in an Imperfect World includes a section called "To RFP or not to RFP"

Idealware article: The Perfect Fit: A Guide to Evaluating and Purchasing Major Software Systems

Techsoup article: The RFP Process: An Overview

Techsoup article: Nine Tips for Navigating the RFP Research Phase

What types of software should your nonprofit be using? It's hard to even know even what types exist, let alone what might work for you. Through a friendly, easy-reference format, this book helps you pinpoint the types of software that can help your organization based on your needs and your level of technology savvy, and provides user-friendly summaries to demystify all the possible options.

The 84-page Field Guide includes an overview of 35 different types of software, helping you to understand what each is, how it fits in with your needs, how much you might expect to pay, and some of the most common vendors in the area.

 

Full disclosure: I reviewed an early draft, but haven't seen the final version. It's likely to be a useful guide to nonprofits who are planning to purchase (or request donations) of a lot of software in the near future.

You can get more information and order a copy on their site.

read more

The nonprofit ecosystem is a way of thinking about how data is shared by and flows across the different departments and activities in your organization. Similar to the interconnectedness in natural ecosystems (for example: marsh, birds, plants), we think of the data ecosystem as the interconnectedness of software tools and the data they hold. Thus, in a well functioning data ecosystem, tools are connected so that the information gathered from online donations, for example, is easily commingled with the information gathered from an event which is commingled with the information collected about other supporters. In a poorly functioning data ecosystem, each pool of data stands alone with little or no interconnectedness.

read more

Keith urges nonprofits to look before they leap into new software, cautioning that "new software may not make anything better — in fact, it could make things worse." He then addresses what new software could do for your organization, as well as "Signs That a New System Wont Cure What Ails You," "Signs That a New System Would be Helpful," and the thorny topic of "How Much Will Switching Cost?"

His closing summary is right on target:

read more