In an earlier post, I introduced this series of posts about the role an Executive Director might play in the develpoment database-a question I ‘m asked often. This post addresses perhaps the most common and dangerous comment I hear:
-
“I don’t use the database for that; I do all that in Excel.”
Excel is NOT a database!
The difference between a spreadsheet and a database can be likened to the difference between a sheet of paper and a cube. A sheet of paper is flat and one dimensional; it is what it appears to be. A cube, by contrast, is three dimensional; it has width, depth, and height. The same is true of a good database.
Most Executive Directors these days are at least computer literate enough to be comfortable using and manipulating an Excel spreadsheet to get the information they want in a format that makes them happy. If the end product makes them happy, then why rock the boat? The evils inherent in this are too many to list here, but I’m going to hit some of the highlights.
A spreadsheet provides no permanent record of said “manipulation” to the information (i.e. “data”), so it must be recreated for each “list”. This is extremely time consuming and rampant with opportunity for errors. For example, the Executive Director knows that a particular board member likes her board packets to be sent to her office. Each time the board list is presented to him for final approval, he changes her address to her office for that particular mailing. Oh, and while he’s there, he changes the way it should be addressed: to Ms. Bonnie B. Member, instead of the current Mr. and Mrs. John Board Member. A month later, when gala invitations are mailed, the development assistant interprets that as a directive from the Executive Director (regarding Bonnie’s preferences), and feelings are hurt because Mr. wasn’t invited. A database can manage both of those situations, allowing certain types of material to be sent and addressed one way, while others are done differently depending on the circumstances.
Another common pitfall of “we do everything in Excel” is that of Excel “silos”-everybody has their own “lists”. What happens when we want to do a mailing to everybody on everyone’s list? Do you suppose that there might be some duplication in those lists? Do you suppose that some staff may have her listed as Bunnie, while others have her as Bonnie, and still others have them listed as a couple? Now what??? Again, a solid, healthy database would effectively manage this scenario and allow the ORGANIZATION to track these wonderful folks as a couple, and address them individually when appropriate. Furthermore, what happens next year? Can anybody find the final, final, final list? Is there any record of who was invited, came, or gave last year? The list goes on and on.
Okay, Sandy, this all sounds familiar, so what’s my role here? Your role is to lead from the top. Make it your policy that, while it is okay if the information ultimately ends up in a spreadsheet, it must start in the database. So in our examples above, if Bonnie wants her board packets mailed to her office address, addressed to her only, while invitations are mailed to her home and include her husband, then those changes need to be made in the database, not in Excel. Your role is to insist that changes be made at the source, not the destination. Why ride a tricycle when you’ve got a Harley?
