Volunteer Management Software – A Cautionary Tale
A friend recently asked for some quick advice on Volunteer Management software that a local Obama campaign could use.
I easily fall victim to this kind of request, just as my friend and many nonprofits fall victim to it: asking for a technology silver bullet for a specific problem prior to defining the problem in its larger context. As a victim, I did a quick Google search to find VolunteerHub, Volgistics, and Volunteer2, which all at first glance seemed to have surprisingly solid features and pricing.
Then BAM! I realized my error: my Silver Bullet Pill solution would cause more pain for this group down the road. I started thinking about the fact that many volunteers are donors…which meant that the organization would have a different donor database. Now that would be bad!! And then I thought, many of those volunteers may work for companies or community-based organizations that might be recruited to host issue-focused events. Would that cultivation process be stored in yet a third repository (or Excel sheet), because the Volunteer Management system isn’t built for this? Etc, etc, etc.
The result: A data quagmire that would impair the organizations’ effectiveness down the road. Well, for a campaign only in operation for a couple more months, maybe this is not the end of the world, but for an average nonprofit, it’s a big problem.
The message to nonprofits: When shopping for software, think about how the data in this particular application will interact with data living (really or potentially) in other places. Don’t buy an application that just focuses on one point of pain without thinking about the bigger picture. Like eastern medicine, look at the larger context. Sometimes a pill might be the best solution…but understand why.
The message for vendors: Get out of the data vacuum – it’s hurting nonprofits in the long run. Either: 1) build your best-of-breed application on top of an open, extensible platform like CiviCRM, Salesforce, SugarCRM, Microsoft CRM, etc.; or 2) build a open extensible platform with open APIs and develop a broader vendor ecosystem that provides plug-in components to create “whole solutions” for nonprofits.
I easily fall victim to this kind of request, just as my friend and many nonprofits fall victim to it: asking for a technology silver bullet for a specific problem prior to defining the problem in its larger context. As a victim, I did a quick Google search to find VolunteerHub, Volgistics, and Volunteer2, which all at first glance seemed to have surprisingly solid features and pricing.
Then BAM! I realized my error: my Silver Bullet Pill solution would cause more pain for this group down the road. I started thinking about the fact that many volunteers are donors…which meant that the organization would have a different donor database. Now that would be bad!! And then I thought, many of those volunteers may work for companies or community-based organizations that might be recruited to host issue-focused events. Would that cultivation process be stored in yet a third repository (or Excel sheet), because the Volunteer Management system isn’t built for this? Etc, etc, etc.
The result: A data quagmire that would impair the organizations’ effectiveness down the road. Well, for a campaign only in operation for a couple more months, maybe this is not the end of the world, but for an average nonprofit, it’s a big problem.
The message to nonprofits: When shopping for software, think about how the data in this particular application will interact with data living (really or potentially) in other places. Don’t buy an application that just focuses on one point of pain without thinking about the bigger picture. Like eastern medicine, look at the larger context. Sometimes a pill might be the best solution…but understand why.
The message for vendors: Get out of the data vacuum – it’s hurting nonprofits in the long run. Either: 1) build your best-of-breed application on top of an open, extensible platform like CiviCRM, Salesforce, SugarCRM, Microsoft CRM, etc.; or 2) build a open extensible platform with open APIs and develop a broader vendor ecosystem that provides plug-in components to create “whole solutions” for nonprofits.
Labels: CRM, data management
Subscribe through Feedburner
3 Comments:
Great points, Paul. I certainly can't argue the general idea. I do worry, though, that in practice this means that any new need means undertaking a huge new software selection, to now encompass the new need as well as all your other constituent data needs. And if it's a big effort, some orgs will likely opt to not it... and the data will be hidden in a spreadsheet on someone's desktop...
There must be some middle ground, no? I guess maybe looking for a point solution that fits in well with your existing system?
I don't think it has to lead to a huge new software selection. But it does mean asking the question about how a potential new piece of software will work with my existing systems. If you've got Blackbaud, call the company and get suggestions for alternatives for what the system doesn't do. If you're using Kintera, do the same. I like to look for "software ecosystems" -- groups of vendors that play nicely with one and other in terms of data exchange.
The concept of solutions that are simple should not be lost. I get concerned that we as a society are creating job security with the complexity of certain software applications...We have been designing software to manage volunteers and testing for about 1 1/2 years. There are two users to consider. The volunteer and the administrator or the volunteers. What drove me to create our own solution is that I was frustrated that too much staff time was spent doing data entry and that it took a ton of time to get someone comfortable to use the database, including trainings etc. Simplicity must become a higher priority. Cost must be another. Many of the business models assume that non profits can or will afford to pay for add ons, monthly or yearly fees. For non profits to be sustainable we must have technology, process and people in mind. This imperative means that the current approaches will soon be replaced...not because they aren't workable but that there will be simpler and more fluid solutions.
Post a Comment
<< Home