Tip:
Highlight text to annotate it
X
Welcome to TechSoup Talks.
This webinar is Finding the Perfect Donor Database in an Imperfect World.
My name is Kami Griffiths.
And we would like to thank ReadyTalk for sponsoring this webinar series.
And I would also like to welcome Robert *** and Tracy Kronzak.
I'd like to have you introduce yourselves and tell us a little bit about about your organization.
So Robert?
Robert: Hi everyone, this is Robert ***. Kami, can you hear me?
Kami: Yeah, loud and clear.
Robert: Great. So I am a technology consultant and focus on donor management,
donor databases, member databases etc., and also the fundraising back office
which is often called development services, or development operations,
or advancement services depending upon the organization.
And those are the people responsible for the business processes that support the database.
And I've been in this field for about 25 years
and on my own as a consultant for the last eight or nine years.
Kami: Well, thank you so much. And for those of you who are new to this topic,
Robert is quite the expert in databases, and we are really lucky to have him here.
And Tracy, can you introduce your self?
Tracy: Sure, you can hear me okay?
Kami: Yep.
Tracy: Terrific. I am Tracy Kronzak. I am the technology manager
at the Applied Research Center in Oakland California.
In the interest of full disclosure I actually did work with Robert on one of our database searches,
and we will get to that a little later on in the presentation.
But I have been in this position about 3 1/2 years now,
and I've seen this organization through two database searches
and a major technology transition.
So I am really here today to share from some of my experience going through this process,
and also some of my observations having gone through this process in an organization
in itself undergoing a great deal of change.
Kami: Well thank you so much for taking time to join us.
And I would also like to thank Becky Wiegand who is answering chat questions.
If you have any issues with ReadyTalk, or have any questions,
send them via the chat and Becky will help you out.
So just to quickly go over the agenda today, we are going to first start out
by talking about why we are here, and when is a good time to change your database,
and what it will cost, how to choose, and then surviving the conversion.
So I would like to get started by asking, why are we here today Robert?
Robert: So we are here -- I love this quote from John Kenyon
who is a local San Francisco-based nonprofit technology consultant,
"After people, data is your most important resource."
It is very difficult these days to operate an organization of any degree of sophistication
without access to good data. And data is your institution's long-term memory,
otherwise when staff leave, when staff retire, when staff get promoted to new positions,
they take all that knowledge about your organization, and your donors,
and your prospects, and your supporters with them. And you don't want that to happen.
You want that to be available to future staff.
And then in general, a good database helps you focus, helps you manage your time,
helps you manage your resources and be smarter about the work that you are doing.
Kami: And so what should people expect from a database?
Robert: So I eluded to this in the previous slide. Your database should in general
help you work smarter. And what that means will vary from organization to organization.
If you are a fund-raising organization you should be able to track your income,
and who gave you that money, and what it is restricted for if it is restricted,
and how you used it. It should let you monitor and forecast the performance of the organization.
So you should if you are a good database user, be able to say,
well, based on historical trends or based on the initiatives we are launching this year,
we raised X last year. We expect to raise X plus X percent or X minus X percent this year.
And we are on track, or we are not on track. And if we are not on track
how can we refine our work so that we can get back on track.
And then keep the people who care both internally and externally informed
about what you are doing with the money you are raising, and what you are doing
with the money your donors are giving you. Are you doing what they think you are doing?
And then in general to keep in touch with the people who are your supporters
or you would like to be your supporters in the future.
Kami: So Tracy, can you tell us when it would be a good time to change it?
Tracy: Sure, you know we came up with this list of points on when to change.
And I was thinking about this last night even. And the overall theme for us
was when we needed to change it was because our database had no longer become an asset,
but had become a liability to our business processes.
So we were not able to get any sort of coherent viewpoint of the people who supported us,
and the people who really wanted to be engaged with us.
So obviously that includes every single department that you could possibly work with,
whether or not the development folks can actually get the reports they need in order to understand
how fundraising is going and report back to funders and donors.
When your data like it was in our case is spread out across the organization,
there is no central repository for that, and there is no ability for any staff member
to be able to go in and share their experience based on working with that data.
And you know, particularly in smaller organizations I've seen this be a challenge.
And that is if one person is carrying all your data and that person has their own system set up,
and that information is exclusively in their head,
that is a very difficult thing to enable organizational sharing.
And one of the things that we did organizationally is we changed our mission,
and we changed our focus, and [indistinct] we changed our constituents.
So you know, another choice that you might have or another decision that you might have
is whether or not you are changing your organization.
And when you are looking at changing you know,
we really had to come to terms with a lot of different constraints on our system.
I think one of the themes that you are going to hear through this
is that you are going to look for the perfect database and there is no perfect database.
But the ones that I really want to highlight off of here is that when you do make a change
that is as fundamental to the structure and the information sharing as the database
is to your organization, one of the things that you want to be sure of is that every one participates
and has buy-in to that decision. That when you have the moment to examine those databases
you do everything in your power to compare them as most similarly as you can.
So have your vendors go through the same demonstration scripts repeatedly.
And also make sure you understand the true costs.
And one of the things that organizations really grapple with
is whether or not to have someone administer their database,
and how that person's job should be structured. So know that when you take on change,
the principles of change tell you that there's really no perfect system,
and you are going to have to examine your organization not just in terms of its database,
but also in terms of its business processes, and it's internal efficiencies as you are using them.
Kami: So Robert I would like to throw it over to you. Let's talk about how much it will cost.
Robert: So the cost -- and there were a lot of questions supplied by the people as they register,
by the attendees that they registered, a lot of questions about cost.
And the cost is about as variable as you can possibly imagine.
There are a number of systems that are free. Although, some of them are free as in puppies,
so you can get the software for free, but then there is a lot of care and feeding required
after you get the software to understand your business processes
and implement those into the software and design reports,
and develop policies and procedures, and train your staff.
So there are a lot of hidden costs that are not simply software.
But they're are some really nice free, or very inexpensive databases.
And at the end there is a resource slide with a link to an Idealware report
examining 30+ inexpensive donor databases as they defined them
which was I think under $40 to $250 for the first user for the first year.
So there are a lot of systems in that price range.
In addition to software you are going to need unless you have online software
where the vendor is providing the hardware, you are likely to need hardware.
Even if the vendor is supporting the software you are going to need some kind of hardware yourself
to access the database from. So you are going to need desktop computers, or laptops,
or Netbooks, or iPhones or something in order to have access to your data.
So the price starts at zero, and I have a lot of clients who have spent more than $1 million
on their database. But there are a lot of excellent, excellent systems in the market
for well under $5000 aimed at small nonprofits.
In addition to the price to buy and implement the database
you have to count on annual ongoing support of the database.
And generally you are going to be spending something on the order of approximately 20%
of the retail price of the software. And that is the last bullet here.
It varies from company to company, and some companies
particularly if they have a free database, 20% of free is still free.
But for a product that you pay for, generally you are going to pay for ongoing support.
And not doing this is really playing Russian roulette with your database,
because if anything goes wrong at the software level you are not going to have the access
to anybody to fix it for you. Now a lot of the vendors will take pity on you.
Some vendors have a program where you can pay all of the back support
for however many years you skipped it and get current, but that can be a catastrophic expense.
So I strongly recommend paying for the ongoing support.
And if you can't afford the ongoing support of the database, or to train your staff,
and training is an ongoing expense. You are going to have new staff
and databases in general will have new capabilities you will need to learn.
If you can't afford the maintenance and the support you should not be using that database.
Then there are also some hidden costs here in addition to the ones I mentioned
on the previous slide. The middle bullet here is your own staff time.
And a lot of organizations don't take their own staff time seriously as a cost,
but it can be a significant cost. You may be taking a staff person out of their regular job
for some period of time, or taking out at least some big portion of their regular job
in order to support the database conversion, and perhaps the ongoing support of the database.
So you need to consider that as well.
So here is a sample budget for a system costing about $5000,
costing $5000 in the first year for the software itself.
And this could be $5000 divided in 12 payments, because it is an online system,
or $5000 because it is a purchase of software that you install on your own servers.
So I put in a budget line here, and this is a made up budget,
but it is pretty realistic in my experience. So I put in time for training five staff people.
Some vendors include that in the cost, some vendors don't.
I assume that you would have to buy or upgrade workstations for those staff.
I assume that you will probably need a new printer because you will printing
all of these brand-new reports. That's not a big part of the cost.
I assumed 20 hours of consulting in order to convert your data
and help you develop business rules and reports etc. And then I assumed ongoing support.
So this is really actually based on a single purchase of a $5000 product
as opposed to an online system where you are paying monthly.
So the support is 20% a year over the course of the next four years. And it is totaling out $4000.
Ongoing training as you have staff turnover and work station upgrades
somewhere within those five years. So at the end of those five years in this sample budget
you have spent almost $30,000 on this $5000 piece of software.
So you need to consider all of the costs when you go into this.
And I didn't put anything for staff time here because it is often a hidden cost.
And I have no idea how much you pay the person who would be supporting this,
but it is definitely something to keep in mind.
Kami: So let's move on and talk about the steps to buying a database.
Robert: So we're going to cover all of these steps as we go through this presentation.
But these are the big high level steps, and each of these break down into lots of sub steps.
But the first step is who should be making the decision,
getting the right people involved in making that decision.
And then the second is deciding what it is you need, and what are your top priorities,
and which of those priorities are mandatory. And then somehow identifying a pool of vendors,
an RFP a request for proposas or a request for information are pretty common ways to do that,
but there are many other approaches to doing this.
And then how do you test the vendors to make sure that they can actually do
what you have asked them to do in your list of top priorities.
And then getting a detailed proposal so that you understand all of those costs
that we were just talking about.
Tracy: So the first step really in this process is to convene your team.
And frankly, this is something that I've noticed in my experience now
going through a couple of searches, it is almost equal parts are [indistinct].
And I think that the real salient points of this is something I mentioned earlier
and that is your team are going to be the people who are going to help you move the system
throughout your organization. So it can't really be, even though it is very tempting
to have the most technically savvy person be the team leader decision-maker and evaluator
for the whole process. In fact what you really need to make sure is that that technical person
who may be approaching your database search from an extraordinarily informed perspective
on technology is going to be able to get real feedback from people in your organization
who are going to be doing it every day in the system.
So one of the decision-making processes that I have noticed is that you will come across
really unexpected allies in this process, and folks who will say the most insightful things
simply because they are not the team leader on the database search
and have to actually work with it every day.
And that kind of get into the question of what do you need to bring your team to a point of like
understanding where you want to move. So the thing that I want to highlight from this slide
is obviously one of the introspections that you will need to accomplish
is an examination of your business processes now, and all the points where you are feeling pain,
and all the points where you would like to see change.
But the point on here that asks what do you really need,
actually speaks more to a question of priorities for your organization.
One of the things that you will need to do is make a sheet of things that are absolute must haves,
things that would be nice to have but not necessary, and things that are simply
for your intents and purposes bells and whistles on a database system.
And I think it is really easy to get involved with vendor demonstrations.
And they will show you a lot of cool stuff because it is really the point of your vendor demo
to help make a sale for that organization. And you know, it is returning to your priorities
and continually asking what do you really need and what are our original goals
to come out of this search, are really the most salient points.
And one of those priorities may very well be what you can afford.
Because we were certainly faced with a choice of a $300,000 database
that would've done everything that we needed right out of our box,
and that was just not a good financial decision for us.
So I just wanted to show you quickly one of the frames that you can sort of consider
to help you prioritize your needs. And every member of your team should fill these out
so that when you pull them together there is a common understanding
of like these are the things that we absolutely must have in our system.
And this is one sort of illustrative tool to help you get to that point.
Robert: And this is just an example. These may not be criteria that are important to you at all
so they might not even be on your list to begin with. It could be that a few of these are.
and this comes from NPower's guide to Selecting Donor Management Software.
For me, a 10 means we cannot live without this one feature.
If the database could do absolutely everything else on our list, but it couldn't do this one thing
we could not use it. For instance, Mac support might be one of your deal breakers.
And if the system can't support a Mac, it doesn't matter how good it is at everything else.
So the deal breakers should be a small subset of the total, but you have to know what those are.
Tracy, anything more on this slide?
Tracy: Nope, I think we can go on to the next.
Robert: Great. So the next step after you know what you are looking for
is to identify a pool of vendors who look like they can meet those requirements.
And there are a lot of different approaches to those.
I talked earlier about request for proposals and we will get to that in a moment.
The easiest way to do this is to ask similar organizations.
So if you have allied organizations who you are connected with who do similar types of work,
that's a great place to start. You need to make sure that they are comparable organizations.
So it doesn't do you any good to be a little three-person office and find out
what your local Red Cross headquarters is using unless you are of a comparable size.
You can also ask on general purpose forums like TechSoup,
Charity Channel which is now a fee-based forum. It didn't used to be,
but they have a lot of different listservs for different kinds of nonprofits. And then there is one
called the Information Systems Forum which is a listserv for nonprofit techies.
So ask around.
The vendors ideally should have experience with your kind of organization
meeting the kinds of needs you have unless you are willing to take a chance.
Now it could be that no vendor or no vendor you can afford or trust
can do what you are looking for. So you might be willing to go with a vendor
who says well that will be in our next release, or we will custom-build that for you
because we think it is important and of course they want your money.
And you need to be willing to then work with them on that and pay them to do that.
But ideally the vendor has what you want out of the box, and they have experience
meeting needs of organizations that are similar to yours.
My goal is to have three demos. One demo is not enough to have any comparisons,
and two really isn't enough of a comparison. And if you do more than four,
you are brain dead by the end. You just can't remember who the first vendor was
despite taking notes which I would strongly encourage you to do. So three, maybe four
is the magic number. Too many choices is a bad thing. It becomes overwhelming.
It becomes hard to make a decision when you are faced with 30 or 300, you know.
If you are just starting out your search, too many choices you really need to narrow it down.
And also avoid what I call demo fatigue which is just sitting through too many of these
to the point where you can no longer think by the end.
So a common first step is to issue a request for proposals, and I am skeptical of RFPs,
because a lot of them really don't get at the right issues and turn out to be big wastes of time
for the organization and the vendors. But if you have very specific unambiguous questions
that can be answered yes or no, it can be a really good tool.
So, do you support Mac's, yes or no? That is an unambiguous question.
Can you process -- and I have actually had clients who needed this --
can you process donations in dollars, euros, pounds, and Yen.
If you need that that is an unambiguous question. But not, can your system track gifts?
That is just way too vague. Every donor database can track gifts,
but they probably can't track gifts in the way that you want gifts tracked.
And then you need to spend the time reviewing those RFPs responses
and assigning scores to them so that you know who did the best. And again, you need to know
what your mandatory deal breakers are, so if a vendor says no to one of them,
you eliminate them. But again, I am pretty skeptical of RFPs, because it is easy for a vendor
to say yes we do that, but not mean at all what you meant when you asked the question.
Tracy: And you know, leading -- when you are speaking with vendors in specific,
the software demonstration thing for us was so critical,
because what I really want folks to take away from this slide is comparing apples to apples
and keeping it real. And to both of those points when you have time with a vendor
that you have arrived at either through a letter of inquiry in an RFP process
or through your own research, your script is going to help you make sure that every vendor
you speak with absolutely touches upon all the points of importance to your organization.
And what should be contained in that script are the things that are extremely important
to your business process and operations every day. And when you're doing the demos
you are going to have your team with you. When we did ours we had roughly 5 or 6 of us
sitting around a computer monitor doing Web demos. We weren't able to get in-person demos
which is -- it is preferable to have someone there that you can speak with in real time.
But if you are not able to do that, Web demos are also good. And I encourage people
to stick with one path. So if you are doing them all in person, do them all in person.
If you are doing them on the Web, do them all on the Web,
because that will give you the most objective kind of background to each of these.
And encourage your staff to actually really ask the questions of like
well, when I am processing a donation and I need to make a credit to one person
but that person is affiliated with an organization that I am also getting a matching gift from,
show me how you do this in your system. And I think "show, don't tell"
is a very important principal for the vendor demos as well.
And you know if you want to know your demo script really and truly is that opportunity.
So here are a few examples of what you might want to conclude from your vendor demos.
And those examples that you come up with for your organization --
and one of the reasons why your team members are important
is because they will obviously give you your departmental kind of priorities in that area.
When you hand the script to the demo, what you also will be able to do is create your own rating
and comments on it for the staff who are watching the demo. And when you are doing this
everybody have a chance to sort of say, oh I really liked how this system handled one, or two,
or three different items, but I didn't like how it handled soft credits,
or a didn't like how events came in and were hard to sort by. So it's really a pairing of both a script
for your vendor, and also an evaluation form based on your script for your team
to use during those vendor demos that helps make them most successful
when you are going back and actually trying to make a decision.
Robert: So, after you have gone through all of these demos which you have graded,
and that has allowed you ideally to identify the top one, or two, or possibly three,
maybe the vendors all looked roughly comparable through the course of the demos.
I think it is really important to get your hands on the software and really test it.
And every vendor should be willing to give you access to a demo copy of the system.
Some vendors actually do have trouble with this, but it is becoming more, and more common
for vendors to have a way of doing this for you. So some vendors will send you a CD,
or allow you to download a single user limited time copy of the system, but a lot of vendors
particularly those who have web based systems will give you access to a demo account.
And essentially you are creating a mini version of that script that Tracy was talking about.
So we need to get in and enter some constituents and link them together, and add some gifts,
and some gifts of soft credits, and then design a report, or run an existing report in the system
so you will have a handful of things to test, and those tests will be based on the role
of the person who was on the committee. So someone doing gift entry would test gift entry.
And someone who is major gift officer would test filing contact reports, and logging actions,
and logging a proposal. Someone in annual giving might segment a list.
And it is hard to do these things when you haven't been trained,
you don't have experience with the software, so you are going to be fumbling around,
but that will tell you a lot about the usability of the system. Can someone with no experience,
and little or no training -- the vendors might be willing to give you some training
or be available to you as a help desk to answer questions. But how easy is it for you
to figure out the basics of the system with that small amount of experience with it.
And you should be grading those tests. So this is an example of a form that has been around
for I think a couple decades called the System Usability Scale. And it asks very straightforward
questions like, I think that I would like to use the system frequently; agree, disagree?
I thought the system was very easy to use; agree, disagree?
That will tell you a lot about how likely your staff are to really use the system in real life.
And then the last step in reviewing the vendors is reference checking.
And the vendors should all give you a list of references. They will only give you happy clients
if they know their clients well enough. I have had my vendors give my clients unhappy references,
but that is pretty rare. So you also want to reach out just like you did to identify the vendor pool,
reach out to other organizations who weren't referred to you by the vendors and find out
if they are using the software, and how well they like it. Does the vendor meet their commitments?
Do they do it on time and on budget? The caveat I have at the bottom here
is it can be difficult to distinguish client problems from vendor problems. And sometimes
the problem is a bad client. They chose the wrong software, or they didn't train their staff,
or they trained their staff 10 years ago, but those people no longer work there,
or they implemented incorrectly and their data is a mess and nobody is keeping it clean.
So if you hear that pattern over and over again, it is probably a vendor problem.
But if you hear it from one client you need to keep checking, because it may be a client problem.
And sometimes it can be really useful to visit other clients that are using the software.
If you are in an urban area and there are other organizations around that are comparable to you,
it can be really helpful to go look over someone shoulder and talk to them about face-to-face
about what it is really like to use the vendor. And you will instantly bond with them
and build your own little user group assuming that you choose that software. And then the link
at the bottom here is some sample reference check questions just as a starting point.
So we've gone through all of the steps of reviewing the vendors.
You know what you need. The vendors have shown you whether they can meet those needs.
You've done some hands-on testing. You've talked to their references.
And now we are down to where the rubber really meets the road.
And I talked earlier about the costs that might go into this. Vendors will give you cost proposals
at the beginning. And some vendors, their costs really don't vary, so their costs at the beginning
of the process will be exactly the same as at the end. But a lot of the vendors will learn a lot
about you as they go through the process of showing you the software and talking to you
that will let them develop a detailed cost proposal that is truly informed by your needs.
So some vendors sell by the module and you may not need all modules.
Some vendors price based on the number of records you will have.
Some vendors price based on the number of users you will have.
Some vendors price a combination of all of those. You might need some third party add-ins.
In addition, you are going to have that ongoing support cost. You are going to have training.
I think it is incredibly valuable to have someone who is experienced with the database
as your consultant -- and I don't do this, so I am not selling my own services here --
but either the vendor or someone who specializes in that kind of software
help you go through the conversion.
And then you might need help interfacing your software with other pieces of software
in the organization or that you are buying as part of the project.
So you need to understand all of those costs.
Kami: So how long is this going to take?
It seems overwhelming, so you can you break it down for us?
Tracy: Sure. You know it's funny we are two thirds of the way through the webinar
and I want to shake people a little bit and say, you will never be done!
And there is a real big caveat to that, because obviously you do have a time frame
that you are going to actually pull this system into implementation and have your users
up and running. And we have included some estimates of what we've seen organizations
of various sizes, how long it will realistically take to put your database
into a business process and into your organization.
But the thing I really want to highlight in this process is planning for the unplanned.
And what I mean by that is that for the folks that might be statisticians, I would say that
while you are doing your database search, hold your database search as constant
in all of the other processes in your organization. Meaning, don't try a database search
when you are undergoing a strategic plan. Or don't try a database search when you are
undergoing a management transition such as a very important Development Director
or Executive Director, because those things will actually change your priorities and viewpoints
on a database, and elongate the amount of time it will pragmatically take to implement it.
So as much as you can make your database search a discrete process
with significant support from your organization's management in order to actually
get it implemented and pushed out so that folks are using it comfortably
within a reasonable amount of time.
And then the other part of this and why I sort of said "Oh, you will never be done"
is because in fact, when you adopt something as important to your organization's operation
as a database system, you are going to have to remember that your users are going to need
constant refreshers, little tips on how to do things better and more efficiently with your system,
and systems in place for when staff matriculate and new staff come in to get them up
to the same speed that your organization is currently working at with your new system.
And that will help you both elongate the life span of your new system,
and also make sure that you have consistency of data going in and out of it
through the lie span that it has for you, be that three years or be that another five years.
Kami: Robert, can you give us an overview, a summary?
Robert: So, this is where we have been. You're starting by getting the right people involved
in making the decision, not just techies, and then prioritizing your needs and distinguishing
the mandatory deal breakers from everything else, and prioritizing everything else,
because some things will be almost mandatory but you could live without them if you had to.
You need to understand the potential costs, and then identify a pool of the potential vendors
who look like they can meet those top priorities, and then go through the steps
that we just talked through to test those vendors against your needs coming down at the end
to an actual in-depth cost estimate based on not just the software but what it is going to cost you
to get live on the software and support it into the future.
And the reason that we are here today isn't -- this is not a tech talk. This is a management talk.
Databases are management tools. The right data base should be able to help you work smarter.
It should be able to help you focus on the right prospects, and understand who your donors are,
and what they give you, and how they respond to different kinds of fundraising appeals.
Are they online donors? Are they off-line donors? Are they phone donors?
Are they face-to-face donors? What level of support are they giving you?
What level might they be prepared to give you in the future?
If you are running an organization with multiple fund raisers,
this should help the management understand what their staff are actually doing,
and are they really talking to donors, and are they really raising money?
And then the ultimate goal of fundraising, asking the right person for the right gift at the right time
for the right purpose. So if you can capture your data in a good usable database
that everyone shares and has access to, and can actually provide reports for you,
you should be able to do everything that is on this list.
Tracy: Go ahead Kami.
Kami: I just was asking you to tell us about this next part which is from my experience,
and people I know, this can be a big challenge.
Tracy: It can. And you know, I think that the important thing to note here is
to go all the way back to the beginning and that is you will be putting a lot of effort into finding
the most perfect database for your needs bearing in mind that there is no perfect database.
And if folks are familiar with sort of that age hold triangle of you know,
you can't have something that is done well, done cheaply, and done fast all at the same time.
You have to pick two of those.
And I think from our experience this also held true in a very similar way, and that is
when you find a system there are always going to be some trade-offs that you are accepting
when you choose a system. And that might be that it need customization.
It might be that you need to invest a little bit more time into staff training. It might be that
your adoption time and learning curve is either steeper or shallower depending upon the project.
So this is a reminder to say define your success when you start your project and say
we are going to get as close to these top priorities as possible and try to meet them.
And also remembering too that in fact, your database is your mission driven tool.
So another way of asking yourself your priorities is to say,
how well will this help us meet our mission if our database can accomplish XY or Z or AB and C.
And moving to sort of our organization's journey through this, we struggled a great deal with this.
And actually the first point on here is in 1998 we had a custom FileMaker database made for us,
and it was really great. And you know going on almost 8 years later we had hit a point where
our data simply wasn't connecting to anything else we were doing using the system.
So we went through a search, and we came up with a winner.
And addressing a point that I made earlier, we also concurrently went through a strategic plan
around the same time that we were doing our database search.
And we realized at the end of our strategic plan hey, we are changing, our needs are changing.
This system that we thought would work so well for us isn't going to work at all.
So finally this year we arrived at a new, new system which for us just as a point of reference
turned out to be SalesForce. And in fact, we've had to struggle with a lot of these questions
of can we meet this mission driven kind of agenda now with our new system?
And we finally arrived at a comfortable end. So for us this was a very prolonged process.
If you look at it as start to finish it was three years, and we are still looking at another good year
of looking at getting our staff and users up and trained.
My hope is that by sort of sharing some of this experience,
your search can be a little bit less than three years, and you can arrive at something sooner
by taking care around the parameters that you are building your search and the things
going on organizationally that happens with it. So that would be one journey, howbeit imperfect,
but it is how we arrived to where we are today.
Kami: Robert, did you have anything you wanted to add before we move to questions?
Robert: I didn't.
Kami: Okay, so we've got about 20 minutes for questions.
We have a bunch that Becky has been saving up so we are going to just start.
And these haven't been directed at anybody so either of you can jump in.
Michelle has a question. Is there a correlation between campaign size and software cost?
Robert: That's a really good question. In one of the earlier slides -- and let me flip back to it
on my computer -- I had a rule of thumb about database cost. And my rule of thumb --
and this is just a starting point -- is that if you are paying for a database it is going to cost roughly
a quarter of a percent to a half percent of the annual operating budget for the organization.
So it is not based on campaign size. It is based on organizational size which generally
tells me a lot about organizational complexity. So an organization with $1 million operating budget
-- that is what they spend, not what they raise, it's what they spend -- is generally looking
in the $2500 -$5000 range for a system. And you can add more zeros to all of those
as your organizations get bigger. For a campaign size it is more a question of does it have
the functionality that you need to manage a campaign which is generally based around
individual giving and large corporate and foundation asks. And can you track
all of the steps involved in building that relationship, and who has the ball,
and who is supposed to take the next step, and what did they say in response, and reminders
to follow up, and the ability to survive if the fund raiser who is managing that relationship
leaves the organization before the ask is brought to a close so that all of that data is recorded
and can be shared with others. And if you are a team fund-raising organization
that everyone on the team is kept informed and you are not tripping over each other,
stepping on each other's toes. So that is a general answer. I don't have a specific answer
for a rule of thumb for campaign size.
Kami: Okay, and I wanted to let folks know that we are streaming this webinar into Second Life.
So I wanted to address a question that came in from Second Life.
And I know this isn't a tool specific webinar. We are talking about the strategy,
but there are lots of questions about some of the tools.
And I'm wondering if you could just talk about one or two or three of the open source databases
that you know about?
Robert: Tracy, do you want to help on that?
Kami: Tracy, I think you are muted.
Well, I can speak for myself. I am also the Executive Director of a nonprofit that is
very, very small and we are using CiviCRM. It is free. And our challenges have been training.
I don't know how to use it. I don't know how to set it up. My Web developer is a board member.
She set it up and she doesn't know what she is doing. So I am looking for volunteers
and my staff is trying to get it to work. So we are kind of piecing it together and learning
as we go along, but I think I am missing a lot of opportunities and I don't really know what
all of the power that Civi has, but it also has this really great community of people and developers.
So if you have the time and you have a techie staff person who is willing to put the pieces
together, then I think you are in a pretty good position. That is the only one that I know.
Tracy: Kami, I dropped off for a second, but are we talking about SalesForce?
Kami: We are talking about open source, free open source, and I talked about CiviCRM.
So there was someone who wants to know some of the free tools that are out there.
Tracy: You know, I would just say that -- one addition to all of this, and I missed the first couple
of seconds of it, but we wound up with SalesForce which is also ostensibly
a free system. And one of the things that there is actually an interesting parallel with
is this sort of build versus buy question that I saw a few people asked during the course
of the questions. And I think any system really that you get into, but in my experience explicitly,
some of the free or open source systems enable you to build so much into them
that in some cases it becomes doubly important to be sure that what you are doing
is actually related to your mission and not just building for the sake of building.
So I can only returned to the axiom of free like puppies in some cases.
And unfortunately where a lot of smaller budget organizations land
is they wind up getting a puppy, because the puppy came with not a lot of strings attached.
Robert: On my Website which is on the resources slide RLWeiner.com,
I have a resources page there. And one of the resources is a link
to a list of open source donor management systems. But like Tracy said and I said earlier,
I think that they are free as in puppies.
Kami: Okay. So a couple questions that have to do with interfacing software.
Is it important for your packages to talk with your other pieces of software?
Some of the things are, should it talk to your Website?
What about it talking to your QuikBooks or accounting system?
Tracy: You know, I would actually turn that question around and say,
how important is it to your mission that it does these things?
Because each one of those is a different layer of complexity that you are adding to your system,
and another requirement that you are putting on it.
In our case it was extraordinarily important to our mission that we have a database system
that can easily cull from our Website, and easily cull through social networks.
So that was a priority. It was less of a priority for us to have it interface with something like
our organization's installation of QuikBooks. And frankly, our accountant prefers that it doesn't
to keep that as a separate business process. So you know, if you are going down this route,
I think the important things to ask when you're talking to vendors are,
do you have something called an API? And how accessible is it?
Do you charge more for it? How easy is it to program with?
And how many things have you made it play with so far?
So you know, it is important only to the sense that it is important to your mission to have this.
There are certainly ways of having your data base be at your organization's work stations
or hosted in the cloud as we like to say with something like SalesForce
where it doesn't have to interface with every aspect of your organization.
Robert: And there is interfacing, and there is interfacing, so a lot of organizations are
perfectly fine with an interface that is import-export. So you export the gifts
out of your donor database, and you import them into whatever your accounting system is.
And you do that once a day or once a week and that is perfectly fine.
Although as Tracy said, a lot of accountants prefer to manually enter all of their gifts.
It is also a matter of volume. So if you are getting 10 gifts online a month, it is pretty reasonable
to enter those manually. If you are getting 1000 gifts online a month,
you are not going to want to be entering those manually into your database. And you always
introduce the possibility of mistakes every time you have to retype something.
So in general it's worth avoiding, but it is not worth spending tons of time or money
to build an interface to something that hardly ever gets used.
Tracy: I just wanted to say I saw like five things come up on the chat that said API, API.
So, A as in Apple, P as in Paul, I as in interface. But it is an acronym for I believe,
application portal interface.
Robert: Application programming interface.
Tracy: Programming interface, thank you. So that is just how programs
that are either on your desk top or working online communicate with each other.
Robert: In real time. Generally APIs are for almost instantaneous integration
versus something that happens overnight or over a weekend.
Kami: I am going to move on to the next question.
We are very small with a member database as the backend of our Website.
How does a donor database need to interact with a member database?
Robert: So I think ideally -- and this is related to the question about integration --
ideally it is one database. I prefer to have all of the important constituents who you are cultivating,
or mailing, or communicating with, or inviting to your events in the same database
unless the needs are so specific that they are simply incompatible.
So if you need a system that can track people who attend classes,
and you need a whole class management system, it just might not be reasonable to expect
your donor or member database to do that. But whenever reasonable, I prefer to have
one big database that is the master contact management system. So I would try to find
a member database that can handle donations or a donor database that can handle memberships.
Kami: So there are a couple of questions that have to do with advantages, disadvantages
of software versus Web based tools, and the fact that some people aren't networked together
and is using an online service the only way for them to go if they are not currently networked?
Can you address that?
Tracy: Robert do you want to address that? This actually interfaces a bit with one of the panels
that I just spoke on at the Nonprofit Technology Conference about cloud computing.
And you know, this sort of idea that your database can sit somewhere not at your organization
I think is a very appealing thing for what's becoming this new class
of distributed organizations where everybody
works in Seattle, Washington DC, Los Angeles, and Chicago.
And those tools there are certainly -- and really this is an entirely other topic --
but there are certainly questions about security and accessibility, and the ability for people
to feel confident that their data is getting backed up. But I think that they are particularly
appealing to smaller organizations who can be much more nimble in making the jump
to using a tool that doesn't require sitting on a server in the back part of somebody's office
in your organization. And then taking on all of this sort of programming and kind of support
that that engenders. So that's my little spiel on working in the cloud per se.
Robert: And I will put this on the chat in just a moment. On my blog
a year, or maybe two years ago I posted a summary of best practices for hosted data.
I think for small organizations, generally I am very favorably inclined
particularly for smaller organizations to hosted data, because the vendors are in the business
of managing servers, managing back ups, managing the security of the database
whereas nonprofits generally aren't. And I see so many nonprofits that have had
catastrophic data losses because they don't have anybody responsible for making sure
that data gets back up on a regular basis. So given that kind of choice,
I would entrust the data to a vendor, but you are taking a risk there that the vendor could
in the worst case go out of business, but even without going out of business
that your Internet connection or the vendor's Internet connection could be down the day before
your big event. So I always want some kind of back up access to my data if it's in the cloud.
Tracy: And definitely going to what Robert said about -- when I look at smaller organizations
and I speak to them I think you know, there are also so many things that are happening online
right now so quickly in terms of new vendors and new organizations getting into the game.
And the one word of caution I say is that if you are looking at a cloud computing vendor --
and I keep using that jargonistically, but it means essentially somebody who is going to host
your database for you that you would access through a Web browser for example.
Try to get a sense at how established that business is. Try to get a sense of how long
they've been around and who is recommending them and why,
because that will give you some sense as to whether or not they are going to be there three
or four years from now. And don't be afraid to ask your vendor if you are considering one of them,
so what is the exit strategy if you guys need to close doors?
How do I get my information out of you as easily as I have hopefully put it into you?
Kami: So I'm going to move on to a question about new orgs.
What are the most common mistakes made by new organizations
that are like new 501(c)(3)s that choose a database?
Robert: Using Excel.
Tracy: Making your own.
Robert: Using Excel and building your own. And let me just flip to the resources page real quick.
On this slide the second to the last line is an article I wrote for NTen probably six years ago
on Why Building Your Own Donor Database Should Be Your Last Resort which means
"last resort," not as in don't do it under any circumstances, but don't start out that way.
And then something that is not on this slide is an article I wrote for Idealware a few months ago
called something like Friends Don't Let Friends Use Excel As Their Donor Database.
So those I think are the two most common mistakes.
And both those articles will go into a lot more detail about why those are mistakes.
Tracy: I also want to echo something that we were talking about not too long ago.
And that is there is this phenomenon of my board member's niece, or my board member's nephew,
or my executive director's cousin who is this person that just got out of college.
They are really Tech savvy. They are maybe a programmer or maybe know how to do stuff.
And that is another organizational mistake that I see young organizations making.
And that is there is definitely an appropriate use of your volunteers
when it comes to managing your data. But it's very hard if a volunteer comes in
and creates a system for you that is so critical to your organization's mission,
and when in a year's time that volunteer moves on and she or he may not be reachable
if you have support questions, or may not be reachable if you need to customize something
further on it. So that's sort of another kind of sub point to what Robert was talking about
as far as building your own. And that is it's really tempting to use those resources for that.
But consider first your mission, and I think you will realize that the longevity of that investment
as it relates to your mission is not necessarily very high in return.
Robert: And the sustainability of whatever you are doing,
will you be able to keep this database running if the person who built it moves on?
Kami: Well that is all the time we have for questions. And I apologize for those
whose questions didn't get answered, but we have a lot of great resources on the slides
which again, I will be sending in the follow-up message that has all of these links in it.
Robert: I'll just point out this one in particular.
And then of course in the Power Point you can always open up and use the links there.
And if you have additional questions and you want to post them to our community forums,
here is the link. I will be sending that in the postevent survey, or sorry postevent message.
And if you are new to TechSoup we have other things to available to you other than webinars,
so donated software, community forums, articles, blog posts, posting upcoming events.
And we have another free webinar happening next Thursday,
Social Media Listening Dashboard with two really great speakers presenting for us.
And we would like to thank ReadyTalk. This webinar is made possible by ReadyTalk
who has donated the use of their system to help TechSoup expand awareness of technology
throughout the nonprofit sector. ReadyTalk helps nonprofits and libraries in the US and Canada
reach geographically dispersed areas and increase collaboration
through their audio conferencing and Web conferencing services.
So I want to thank everyone for participating today.
And presenters, thank you Robert and Tracy. This was really really great information.
So I hope you all learned something new. And come back to a future webinar.
And fill out our postevent survey.
Thanks everyone.
Robert: Thanks Kami. Thanks for having us.
Tracy: Thank you Kami. Thanks for the opportunity.
Kami: Oh yes, this was fantastic, appreciate it.
Kami: Bye-bye.Robert: Bye-bye.
Tracy: Bye-bye.