Should Nonprofit Agencies Build or Buy a Database?

Build or Buy?

At CompassPoint Nonprofit Services, our mission is to increase the effectiveness and impact of people working and volunteering in the nonprofit sector. We provide nonprofits with the tools, training, concepts, and strategies that help manage their organizations and shape change in their communities. One of our core technology areas is helping people navigate the forbidding waters of database applications and find the right tools to manage their organization's information. In that process, we often have to weigh whether the organization should build a custom database or purchase an off-the-shelf tool. This article discusses the issues that we've encountered in this process.

Are You Identifying the Right Issue?

One of the benefits of being at CompassPoint is that I am able to tap expertise about other functional areas of nonprofits. In my many years as a database consultant, I've often found that issues from other aspects of an organization surface while working on technology issues. This is usually because the introduction of a new tool impacts the organization as much as it is impacted by the organization. For example, if the tool is meant to enable two staff members to share information and they don't collaborate regularly, the personnel issue will need to be resolved before the sharing tools can be put into place. Or, say an organization hopes to solve its financial management issues by purchasing new accounting software. While the new software will be more sophisticated, it will not be very useful unless the staff understand and can support the underlying accounting practices and conventions built into the tool.

If organizational issues are not resolved, they will be designed right into the new tools and become part of institutional habit. Then, instead of complaining that the paper application forms don't make any sense, it's the database that won't make any sense. Too often, I find people hope technology will be the "magic" elixir that will cure all their organizational ills or, at the other extreme, blame technology as the root cause of its woes. The answer is usually somewhere in between. Sometimes finding a good resolution is more often tied to the underlying organizational issues and practices than replacing the technology. In other words, one has to understand the context and content as much as the technology in order to identify the right issue and in turn the right solution.

Thus, the first step in identifying whether to build or buy is to be sure you have identified the right issue at the outset. When I am approached about building a database, I first want to understand what led them to think that a database is the solution and talk about what issues they are facing. Sometimes, a database is what is needed, and I can start identifying the next steps. Other times, the conversation reveals a range of technology challenges such as: the reports aren't working because the information in the database is incorrect because volunteers are entering data and no one had time to train them; there is no manual; the one person who knew everything about the database just moved to Florida; the server crashed so the database is corrupted anyway but there was no backup because no one checked it to discover that it hadn't been working for 3 months; the network consultant doesn't return phone calls, but if we can just get a state of the art donor package everything will be better. Here, before introducing a new software application, we need to stabilize the network, organize the work flow, and set in place procedures for proper network management - otherwise the new software will likely face the same fate.

A Database or a Way to Manage Information?

We get a lot of calls from people asking for help building a database in Filemaker or Access. In some cases, they have a specification or plan written up and just need either training for their staff or a referral to a developer. In most cases though, the caller is focused on the end product of a database and hasn't really established how the database will fit into his/her agency. A database is really just a repository for information that the organization stores for later retrieval, aggregation, or analysis. It is there to support a larger process, such as client intake or donor processing. The database is really just a temporary repository since the information is flowing into and out of the database as it journeys through you organization. It may come in as a phone call, fax, or paper form before it is entered into the database. It may print out on a report, be sent as an email, or electronically transferred to another database such as an accounting system or donor management tool. The quality of the information going into the database may be greatly affected by how it is originally collected. If information is initially collected on paper and the staff is not properly trained on how to fill it out, the database will not help improve the quality of that information.

It is important to see the database as part of the overall process or system for managing the information that supports the process. This means looking at where information comes from and where it goes, who is collecting the information and how, what training, equipment, and other support is required, etc. Organizations often point to a database or application as "badly designed," when in reality, their staff is not aware of all the functions or has not been properly trained in their use.

Do I Buy It or Build It?

Once you've figured out where the database fits in, the next question is often whether to build a database yourself or buy an off-the-shelf application from an established vendor. The marketing material of database development tools, such as Filemaker and Access, make it seem like a snap for anyone with basic computer skills to set up a database. While this can be true for a simple database such as a contact list that prints mailing labels and a phone list, as the amount of information or number of functions increases, so does the complexity of the tool. For some functions like accounting, donor management or contacts management, there are well-developed "off-the-shelf" tools available for purchase. Often just learning how these tools work is challenging enough, let alone figuring out how to build a bullet-proof accounting package from scratch.

Buying a Database

An organization can define its requirements and then comparison shop to find the right tool. The advantages of this approach are numerous:

• The tool exists and already has many of the functions the organization needs or may need.
• The tool can be tailored to the specific needs of an organization.
• The tool is largely debugged.
• The vendor can provide training, user manuals, and ongoing support.
• The vendor is regularly updating and improving the tool.
• There is often a user community around the product which can be a resource for solving problems.

Despite these advantages, organizations often get "sticker shock" when they see the price because their perception is that they can build it cheaper themselves. In part, this is a budgeting issue, because a consultant or vendor is viewed as an expense, whereas staff costs are seen as already in the budget and thus "paid for." But a database is more than just building a set of screens and a few reports. One needs to consider the costs of defining what is needed, training staff, writing documentation, debugging issues, implementing future changes, and what to do when the key database person leaves the organization. The question to answer here is "how do I want my staff to spend their time?" - learning how to become a software vendor or managing information so that we can improve the quality of our service programs?

A good first step is to identify the various tasks and cost out the "total cost of ownership" ( TCO) for the database. In doing so, you'll need to identify the task, who will do it, what it will cost, and the expected timeline for completion. Here is a sample grid of some of the elements of a database:

Task	Who	Cost	When Complete?
Defining the requirements for the tool
Developing a working tool
Testing and debugging the tool
Developing training materials for staff
Training staff
Implementing the database as a daily tool
Monitoring data quality and assurance
Providing support and maintenance to staff
Writing documentation

While vendors often provide dollar estimates for these areas, you will need to translate staff hours into a dollar cost so you can effectively compare the two. You may need to gather a group of people who can help identify these tasks and estimate the resource requirements. In estimating staff time, it is important to take into account learning curves in order to derive a full estimate. Once you have this comparison, you may find that the total cost of ownership (TCO) of a vendor's product will be less and that the application will be operational sooner. In addition, rather than spending time resolving software issues, staff can dedicate themselves to ensuring the database has quality data.

Building a Database

Unfortunately, many nonprofits have needs that can't be easily met by an existing package and thus have little choice but to create their own database. The market for accounting, donor development, information and referral, and membership management is well developed. Tools for client case management exist, but may be focused on a particular area such as senior care, housing, AIDS, etc. When there isn't a perfect match, the organization has to decide whether to customize an off-the-shelf tool to fit its needs or start from scratch to develop its own. The advantage of customizing an existing tool is that it has some basic functionality that you can already use and will be customized (and supported) by professional developers. The main advantage of developing your own software is that it is designed to fits your needs without any extra features. The downside is that you in essence become the vendor of your own software application. In other words, your organization becomes responsible for many of the tasks provided by a vendor:

• Define the specifications for the database: List the requirements of what you need the application to do. A specification takes that list of requirements and translates it into the specific components of the database: the fields, tables, data entry screens, reports, queries, functions, etc. that will need to be created.
• Create the software (or hire a developer): Take the specification and turn it into a working database will all the defined bells and whistles.
• Write the manuals: A database often needs three kinds of supporting documentation: a user manual that instructs users how to operate the system; a procedure manual that explains how the agency uses that database, in other words, how to process a donation or set up a membership; and lastly, technical documentation that explains how things work "behind the TV screen" so future developers can make sense of the internals.
• Develop the training materials: The manuals are usually developed to support the classroom or one-on-one training sessions to help new users operate the database.
• Provide ongoing support: Despite the best trainings, users will have questions as they encounter new wrinkles or even the best of databases will have bugs that need to be resolved. Someone will need to be available to answer questions and troubleshoot issues.

How Long Does a Database Project Take?

The development time varies greatly depending on the complexity of the requirements and the experience of the developer. A "simple" database with one or two entry screens and one or two reports may require 40-50 hours. A more complex tool could take 200-300 hours of time. However, these estimates assume that a) the specifications are clear, well thought through, and not subject to change; b) the developer is well experienced in the tool s/he is using to create the database and isn't learning by doing; and c) the developer really understands your content area and business processes. And the process may only achieve a "first draft", otherwise known as version 1.0, which will need to be refined, debugged, and improved over the course of a year or more.

If I Build, Do I Train My Staff or Hire a Developer?

If an organization decides to build its own database, the question becomes whether staff can do it or whether the organization needs to hire an outside developer to do it for them. To save money, organizations often think they can just train staff and have them do it. The advantage here is that the staff person understands how your organization works and thus can effectively define the needs for the database. However, staff members are not necessarily schooled in good database design techniques or up on the latest features in a given software product. This means they may be able to complete the task, but it is likely they will have a sizeable learning curve and thus take more time. By contrast, a developer is often well experienced in database development and can identify how best to implement a function in a particular tool, but s/he doesn't know your organization and will need to spend time learning how it works.

Hiring a Database Developer

One solution is to pair a developer with a knowledgeable staff person as the design team. The staff person can help identify needs and write the specifications while the developer can speed the creation using his/her practiced techniques. In addition, the staff person can use the development process to learn how to use the new tool. Ideally, the developer can "tutor" or "coach" the staff person in how to manage the database and develop screens, reports, and functions.

How to Handle Ongoing Management of a Database

A key issue is ongoing management of the database once it is set up and running. The primary issue is ensuring the quality of the information put into the database so that reports come out correctly and numbers add up. While the database application can facilitate some of this quality assurance, often a staff person needs to regularly monitor and audit the data for quality. Many organizations have a "database manager" who is in charge of making sure the database continues to work properly. S/he will setup and train new users, keep the values in drop down lists consistent with changes in your operations, run maintenance routines as needed, and help develop reports out of the database. The last issue is key because people put information into a database in order to get it back out. If no one on staff understands how the information is organized or how to run the report writers, the database quickly becomes useless.

Conclusion

Databases are machines designed to serve precise needs within an organization. No matter which option a nonprofit agency adopts - building or buying a database - the machine will only be as good as its builder. Earlier in this article, I discussed the issue that the introduction of a new tool impacts the organization as much as it is impacted by the organization. This synergistic relationship between machine (the database) and builder (nonprofit agency staff) is an important element of success. I encourage nonprofit agency staff to continually explore how the two will work in harmony together, constantly evaluating each other's needs, and finding the common ground that leads to effective results.