Database Evolution: Avoiding Costly Mistakes

The definition of insanity is doing the same thing over and and over again and expecting the results to be different.  In my experience charities generally follow four main evolutionary steps in managing their data and database software...  And oddly enough the results are generally the same for all those charities!  Here are the outlines for the four stages, and some tips on how to avoid some costly pitfalls.

PAPER:
The first step for most charities, often because they're small and don't need much more, or because they're trying to be really thrifty, is to use a manual or paper-based system.  This can actually work pretty well, unless the charity grows or until the sticky-notes and hanging files get out of control.  So eventually someone takes the time to migrate to...

SPREADSHEETS:
The next phase of database development is to use a spreadsheet (like Excel) or if there's a technically competent staffer or volunteer, some kind of pivot table.  Again, not a bad option for the right size organization with limited demands on its database, but usually someone (the Fundraisers, Board members, etc.) start wanting to actually use the data, and this forces the next evolutionary step.  This often leads to a...

PROPRIETARY SYSTEM:
Every charity is unique.  So it follows that each one needs its own unique database to meet its needs, right?  Wrong!  And yet so many charities spend loads of money pursuing their own special database path, sometimes creating unique campaign and fundraising events just to get started, or to build the next version.  Yet with few exceptions (e.g. large charities with the resources to keep up with costly code-writing and upgrades) these stand-alone systems rapidly become outdated, expensive to maintain, and very hard to use.  My strong advice is to avoid this step if at all possible and, if your charity needs this level of database support, move straight to...

OFF THE SHELF:
There are countless options for charities of all sizes and budgets to manage their databases effectively and efficiently.  And if you need something unique to support your specific needs, most of these packages can have modules "bolted on", or even new code written, for far less cost than sustaining a proprietary system.  And you get the benefit of thousands or even millions of other users helping to spread out the costs of upgrades and tech support, generating a truly robust system.  My other tip would be to not necessarily go with the best known brand: like many major purchases and little research and solid advice can go a long way to save money and provide better options.

Avoid costly mistakes by thinking carefully about your database needs, or else you could wind up owning a dinosaur or even facing an evolutionary "dead end"!