Introduction

Switching from one system of tracking information to another is much easier if you are properly prepared. This page describes some things to consider when planning to implement any database, including Metrix. Considerations that are specific to Metrix are also noted.

Getting started

You can start planning for your new database by asking yourself, and other people at your organization, some very basic questions.

What do my current systems do?
- What do I like/dislike about how my current systems work?
What do I want the new system to do?
- What tasks do we perform regularly that we think the new database would help us with?
Where is my data now?
- Excel spreadsheets, Outlook address books, other database systems, etc.
Should we build or buy the new system?

Each of these questions is explored in more detail below.

By answering these questions you help determine what the new system will need to do. This process is called gathering requirements. Once you have a basic sense of your requirements, you can work with a database consultant who can help further refine those requirements, so that the database developers know what to build. A good analogy is building a house: before the carpenters can build the house, they need a blueprint. Gathering requirements is how you create the blueprint for your database.

What do my current systems do?

One way to get a sense of what your new system needs to do is to look at what your current systems do. For example, the systems may help you keep track of contact information, distinguish clients from funders, track event attendance, and organize mailing lists. So, make a list of each of your systems, and what each of them does now.

Not only will this process help determine what the new system needs to do, it will also help you identify inefficiencies in your current processes. For example, you may realize that you are using two different systems to do the same thing, resulting in duplicate efforts in data entry. In fact, you are probably already aware of some inefficiencies in your current systems. Be sure to make a note of them, so they are addressed in the new system.

On the other hand, if there are some things about your existing systems that you really like, make sure to note those, as well. This way, the database developers will know not to change them too much.

What do I want the new system to do?

Just because your old system does something, it doesn't necessarily mean the new system has to do it, too. After you've identified the things that your old systems do, take some time to decide whether the new system will need to do it. For instance, you might be keeping track of some paperwork every week, but no one in your organization really knows why. The planning stage for a new system is a great time to take a look at some of the things your organization does and ask, "Why do we do this?"

It may also be the case that your current systems do not do something that you wish they did, and this is what is driving the need for a new system. Make a thorough list of these things, so they are included in the requirements gathering process. Your organization may even take the time to look at most, if not all, of the things it does, and decide if the new system needs to accommodate those tasks in some way. For example, you may not end up using the new system for all your accounting needs, but it may be able to perform some tasks that will make the accounting easier.

If you are not quite sure where to start in this process, begin with some broad areas like these, and think about how they apply to your organization:

Contact management
- Think in terms of roles that contacts have: students, board members, donors, etc.
Case management
Pledges and payments
Communications and mailing lists (fundraising appeals, newsletters, email lists, etc.)
Programs (afterschool, seniors, job training, etc.)
Events and ticketing (Annual gala, board meeting, etc.)
Membership
Volunteers
Grant proposals

During this stage, make sure to talk to a lot of your co-workers so that you really understand what they are using systems for, and what they may need the new system for. It is critical that you have feedback from a wide variety of people, so that you don't leave anything out. A group meeting after some initial requirements have been gathered is a great way to learn what you've missed. Just make sure that everyone understands that any requirements you've written down at this early stage are not locked in, and are subject to change. (You might present it like, "This is what we have so far, and we'd really like to see what you've identified as a need for the new system.") Make sure the conversations are broad and somewhat open-ended. Don't focus on details right now...if someone is talking about what what color the forms should be, you risk getting caught up in the details. Instead, talk about the larger processes that make your organization function. Work out the details later. If you feel uncomfortable leading such a meeting, consider bringing in a database consultant to help with this process. (The Metrix team is happy to help.)

At the end of this process, you might begin looking at existing software products that may meet your needs, not necessarily with the intention of buying them, but rather to see what kinds of functions are included in various software packages that are related to what you want yours to do. This process may help you realize some needs you hadn't previously identified.

Where is my data now?

Take a look at all the data sources you have – existing databases and spreadsheets you identified in the process above, business cards, file cabinets, etc., and look through it. Start to get a sense of what kinds of data you store and how much of it you want to bring into the new system.

For each of the items below, you can also ask, "How many, and where are they?"

Excel spreadsheets?
Outlook address books?
Microsoft Access databases or other databases like Donor Perfect or Raiser's Edge?
Business cards and files/loose sheets of paper?
Other sources?

The more organized this data is, the easier it will be to get it into the new system. The method of importing data into the new system varies, so don't worry too much about getting into a particular format just yet. Instead, just make a list of all your data sources, and identify the sources you will want to import into the new system. Once you start working with a specific product or database developer, you can work together to get the data into the specific format required by the new system.

Should we build or buy the new system?

Once you have some sense of your requirements, start looking around at existing products that may fit your needs. Arrange to use the software on a trial basis, or have an in-person demonstration of the software. (Demonstrations of Metrix are held twice a month, and can also be arranged by appointment.) Once you've read about and seen some products, you will begin to get a sense of whether existing "off the shelf" products come close to meeting your needs. One important thing to consider about existing products: Can they be customized to meet your needs? (Open-source products like Metrix are usually more easily customized than products which do not allow you to change or add to their source code or design.)

If you cannot find any products that meet your needs, or come close to meeting your needs, then you will probably have to hire a database developer to create the system for you.

Metrix was created after many years developing databases for non-profit organizations. We identified a common set of needs and built Metrix with the intention of meeting those needs. But we also know that even if 85% of those needs are common to nearly all organizations, we know that perhaps another 15% of those needs are unique to a given organization. Therefore, we built Metrix to be extremely customizable, so that we (or any other database developer) could customize Metrix to meet those remaining requirements.

Next steps

Once your organization has a preliminary sense of the new system's requirements, meet with a database specialist to review and clarify those requirements, discover new ones, and come up with a plan for moving forward. The requirements gathering process should be iterative. This means that you should meet with the database specialist several times to make sure that all your requirements have been discovered and clearly documented. When the requirements gathering process feels complete, you and the database specialist should prepare a formal document that outlines all the requirements. This document is called a functional specification, and should be reviewed and signed by the person in charge of the database project at your organization, and by the person managing the project for the database developers. This document will serve as the blueprint for those creating the database. As development on the database begins and continues, make sure that the requirements are being followed, and be very cautious about adding any new requirements to the system once development has begun. Carelessly adding new features carelessly greatly increases the risk to your budget and any deadlines/milestones you may established.

Conclusion

Switching to a new database system can be a complex process, but proper planning (through requirements gathering) is a key to reducing risk, frustration, and complexity.

If you'd like to talk to someone on the Metrix team about your database project, please call us at (212) 590-9400 or email us at metrix@fcny.org. You can also sign up for a free Metrix demonstration or Webinar. See http://metrix.fcny.org/support/foundationseminar.html for a listing of upcoming demonstrations.