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

Without policies, procedures, training, management, and ongoing attention, databases will become filled with inconsistent, unusable data, and data will be scattered hither and yon in spreadsheets, shadow databases, and desk drawers.

Some tips: Make sure someone is overseeing training and user support and watching for (and fixing) data entry errors. Pay attention to confidentiality and security: give staff and volunteers access to the data they need to do their jobs, but no more. Do all you can to prevent staff from downloading sensitive data to laptops and memory sticks. And run backups religiously.

NOTE: This post is part of a collaborative effort organized by Convio. Other participating blogs include:
• Judi Sohn www.momathome.com/
• Michael Cervino beaconfire.com/blog/
• Beth Kanter beth.typepad.com/beths_blog/
• Tad Druart www.connectioncafe.com
• Jeff Brooks www.donorpowerblog.com/donor_power_blog
• Roger Carr everydaygiving.typepad.com/
• David Neff www.fispace.org/
• Matt Wilson mcommons.com/blog/
• NTEN www.nten.org/blog
• Peter Deitz www.blog.socialactions.com
• Wendy Covey www.trewmarketing.com/spotlight/

The resolutions are collected at www.convio.com/resolve2009, where readers can vote on their favorites. And you can also link your own resolution posts to www.connectioncafe.com

1. Left unattended, databases will turn into piles of mush. Therefore, develop data entry policies and procedures, and train everyone who enters data.
2. Excel is not a database, and is one of the leading causes of dirty data. It is difficult to enforce data entry standards in Excel. (like only allowing legal U.S. state codes). And anyone who can update your spreadsheet can see and change anything.
3. Someone needs to be in charge of training, user support, and data quality (see #1). At a small organization, this might be a small part of someone's job. At a large organization, it might need to be a whole department.
4. Run backups religiously. Be sure to test them periodically to make sure you can recover data.
5. Keep a copy of your data off-site. This can be done by using an online backup service, a vendor that provides offsite storage and retrieval, or even by sending a backup home with a staff member. The latter is risky, however. Data taken off site is subject to theft, loss, copying, and malicious acts by disgruntled employees.
6. Do all you can to prevent staff from downloading sensitive data (like social security numbers or credit card data) to laptops or memory sticks. Use encryption on your laptops and memory sticks. Tools like Identity Finder, Proventsure, SENF, and Spider will scan your computers for sensitive data.
7. Require strong passwords. Do not share passwords. Change passwords regularly.
8. Monitor your data entry. Run reports that look for common errors. Identify staff members who repeatedly make errors and provide additional training. If the errors continue, take away their data entry permissions.
9. Run your database on a need-to-know basis. Give staff and volunteers access to only the data they need to see or change to do their jobs -- but make sure that they do have access to the data they need.
10. Make sure your database has enough security options. You should be able to provide read-only access. You might want to have the ability to provide read-only access to just a portion of your data, like names and addresses but not gifts. You should be able to provide update access to only certain portions of your data, like updating addresses but not entering gifts. You should be able to restrict access to functions like posting a gift batch or importing online donations. And you should be able to restrict the ability to run mass updates or delete records.

The database is now called Common Ground, and is moving out of beta. The release event will take place on Wednesday, September 17 from 4:00 pm - 5:00 pm ET at the National Press Club Murrow Room in Washington, DC. It will also be webcast. The registration form is at http://www.visualwebcaster.com/event.asp?id=51074