Buying a database system is probably the biggest investment (after salaries) that an institution makes in development activities, so it is important to get it right. You need to have a good understanding of what you already have and what else you require, including:
- Interface with other databases. Can any of the current databases that your institution runs be adapted to your purposes? Is this an opportunity to merge several databases into one integrated system? What technical specifications will your new database need to be able to interface with existing databases?
- Input. What information do you need the database to hold and will this change overtime? Consider the number of individual records needed, whether fields follow set patterns or need to be free text, differences in addresses formats from country to country, the level of connectivity between records, etc.
- Output. What information do you want to be able to retrieve from the database and in what formats? What kind of reports do you want? Do you want to be able to print mailing lists and generate briefings directly from the database?
- Stakeholders. Talk to the potential users of the database and get a good idea of their needs. What the gift processor needs will be different from what the fundraiser needs. How will these stakeholders be accessing the database – from the office or different locations?
- Populating the database. How will you import information and/or merge with existing databases? Will there be user-generated content (e.g., should alumni be able to update their own records)?
- Your budget. Separate your budget so that it covers initial purchase, training, data import (often from numerous sources), ongoing support, software updates and any annual fee.
- Supporting a database. What is your in-house capacity for technical support, data management and data entry? Will you have to hire external support? Is your current hardware/server capacity sufficient?
- Planning for the future. Do you need a state-of-the-art database from the beginning or will a less complex version be sufficient for your needs at first and will it be able to evolve at the same pace as your activities evolve?
By thinking through your requirements and recording your answers to the above questions, you will end up developing a proposal-like document, which you can share with potential suppliers. Through this process, you are likely to also have identified a small group of people with the insight and technical expertise needed to help you make the right decision about your database (e.g., colleagues in IT support and Purchasing). Keep them engaged throughout the process.
A good exercise is to develop your ideal dummy record so you can build up a picture of the level of detail and functionality that would be ideal for your purposes. This will help you when you write the suppliers’ brief.
Do your research
Ask institutions similar to yours about their database solutions. Visit technical forums, fundraising forums and other online review sites for firsthand information about database software. Look at the top suppliers and compare and contrast the characteristics of their products and pricing structures.
Making the purchase
Once you have determined a short list of possible suppliers, talk with them. Share the proposal you have put together and get their responses. The more detailed you can be with the information that you provide and your anticipated needs, the easier the process.
Ask suppliers to be very clear about what they include with their product – software, installation, training, updates, helpline, transfer of existing data, data cleaning, etc. Be wary of hidden costs.
This dialogue with suppliers, combined with your own research and budget constraints, will enable you to choose the right database for your needs. It may be that you do not need a ‘top of the range’ model at first but that you can invest in a basic model that can be expanded in the future.