Special Report-Buy Build or Rent
May 1, 2001 Tim Mills Groninger
Information management has become increasingly important in running an effective nonprofit organization. At the IT Resource Center in Chicago, we have been part of a quiet revolution in how organizations think about this core corporate asset.
Nonprofit constituencies have become a complex amalgam of clients, customers, funders, peer agencies and other individual and organizational stakeholders. The ability to match information management with specific business practices is critical to success.
A key component of good information management has become a good database infrastructure. There are major options for nonprofit database software.
First, you can use generic databases, such as Microsoft Access, to development custom applications in house. Second, both commercial and nonprofit developers have created “ready-to-wear” vertical market solutions for fundraising, information and referral, case management and other vertical markets. You can even rent applications, getting the database you want over the Internet with no more technology infrastructure than a good Web browser. Finally, there are a wide variety of consultants offering highly customized solutions to any problem.
How to choose between the options of building your own, buying (or renting), or contracting for custom development? What staff skills are required and what size of check has to be written? The right choice can help staff work smarter and be more effective. The wrong tool can slow work, frustrate staff, and create a general distrust in the quality of information.
Picking the best option for your organization depends on the problem, your human and financial resources, and the opportunities that exist in your sector.
Before talking about choices, let’s examine expectations. The first expectation that many managers bring to database selection is that there is a simple commodity solution. At the IT Resource Center, we often see requirements documents or requests for proposals for database software that are more about what the agency doesn’t want than about specific deliverables. They frequently contain references to “flexibility” and “ease of use” and “can’t restrict actions or new activities.”
In the technology support community, these documents are referred to as BVD RFPs because they are more about selecting underwear than database software. These kinds of requirements documents stem from an expectation that by using marketing language to describe how users should feel about the product, they are excused from having to list specific and testable deliverables. In short, by limiting the requirements to “anything I want to do,” the responsibility for any future problems resides with the software because it failed to meet the specified performance level. A database can manage any task, but it can’t manage every task.
The next expectation is in buying the best software product available. The reality is that there is no perfect software application. Different products, and more importantly, different approaches, are appropriate only where there’s a good “fit.” What works for one agency may well be a disaster for another.
There is also a frequent desire to buy database software that will teach staff the business process, whether it is accounting, fundraising, case management, or enrolling students in art classes. It is unrealistic to hope for a database that is smarter than the user. Databases are tools that can help staff do their jobs better; but to do that, to begin with they need to know their jobs.
The biggest factor in whether users regard a product as easy-to-use or difficult is in training, both in job function (accounting) and software (the accounting database). Training allows users to match how their jobs will change with how the new database will help them in that change.
The reality of nonprofit technology is that there is a diverse market and that the best choice is for a tool that fits the hand and can do the job. The steps are to determine specific needs and requirements, identify resources, select an approach, and then develop an evaluation matrix or project plan to manage the process.
That the same database solution can be seen by one organization as a canvas on which is painted the happy past and bright future of the agency and by another as a grim, rigid, and wrathful taskmaster is quite common. The reason for this disparity in attitude when the technical details are identical is that the technology is less important than human and operational issues.
Good database requirements focus less on field and report specifications and more on describing how information flows through an organization. Understanding how data are collected, knowing which decisions can be made manually and which require the oversight of a smart human are critical issues. Laying out all of the operational and human issues is called defining the problem space. The problem space is made up of the rules, tasks and outcomes necessary to solve the problem at hand. In some cases, the problem space includes tasks and rules mandated by funders. In the human service arena, for example, funders often require demographic information or residency history that plays no part in quality of care. However, if that information is not included in reports submitted to the funder, the agency will not be reimbursed for services provided.
There is no one right way to create a database requirements document. The better ones tend to be written in plain language and to describe the problem space and the specific operational and reporting deliverables. Typically, they tend to place the description of the problem before the solution.
A good Request For Proposal (RFP) is more likely to say “We are a multi-funder/multi-program agency, and we need to track individuals and families across those programs” than “We seek an Internet-based solution to…”
Before you look for a database solution, make sure that you understand the problem space occupied by your agency.
A problem space is converted to a working solution through the application of agency resources. The most critical organizational resources are money, staff, and time. True, staff and time do have a financial component, but for this discussion, consider them as sunk costs or boundaries, and the use of both affects what can be accomplished.
Database software selection should involve an evaluation of all three components and how they can be leveraged during the next three to five years.
One way to look at the balance of resources is to imagine a pie chart of money, time and staff. The size of the pie represents the size of project; a bigger pie requires more resources. The wedges represent the proportions of resources. A surplus of staff technical skills reduces the need for out-of-pocket expenditures. Reducing the time frame requires more staff or money. For a given project size, the reduction of one resource requires more of another.
If the problem space is larger than the total resources, you will need to either scale back the project or get more resources. Keeping the project scope small can save large amounts of money. The accompanying graph indicates the general trend comparing cost and complexity of any database project. The curve denotes the overall relationship of cost to overall sophistication (complexity of the problem space). The shaded areas mark the general boundaries for the different options. Note that costs escalate at a much higher rate than sophistication. Small increases in power can involve a major resource investment.
An important concept to keep in mind is that the cost complexity curve represents the best case. It is rare to have a highly sophisticated system built from a smaller resource pie. However, it is easy to pay more than the best case cost of any given system.
Selecting an approach
Arrayed with an understanding of the agency resources available and the problem space, you can evaluate the options of building your own database, selecting an existing commercial or vertical market solution, or contracting with a consultant.
Build your own
Generic database products offer the potential to create a custom application specifically tailored to the development needs of an agency. Microsoft Access in particular often comes pre-installed on new computers, making the dollar cost of this approach almost negligible.
Software donation programs such as CompuMentor can provide licenses for around $25 for each user. However, for every powerful and flexible custom self-developed application, there are scores of unworkable solutions dragging agencies down.
The good news is that we have found that both professional and support staff can be trained as database developers. Prior technical aptitude is not a prerequisite. Understanding the business process and information management deliverables, as well as an enthusiasm for the project, are more important qualifications.
While management involvement is important to any automation project, it is particularly important in homegrown applications. There is often a tendency for management to underestimate the contribution of the system (both the actual application and the staff who keep it running) to operations.
Self-developed databases can be an invaluable way to solve simple problems and expand institutional experience with the automation of key business systems. As information management needs change, this experience can be used to expand the current system or select another option. One of the best features of modern database software is the general ease with which data can be converted from one system to another.
Building your own database solution generally works best when the problem space is not very complex and staff are given time and training to do the project well. Our experience in Chicago is that simple case management and annual giving databases can often be built by one or two staff spending six to eight hours per week on the project over about a three month period.
Buy it/Rent it — Vertical market options
As the name implies, vertical market solutions focus on one specific (vertical) nonprofit business application. Vertical market applications exist for accounting, fundraising, client and case management, information and referral (InR), volunteers, ticket sales, attendance and just about any other nonprofit task.
Accounting and fundraising are the most mature vertical markets. These applications automate business practices common to a wide range of nonprofits. Recording deposits or soliciting donors are similar activities, whether your organization is a theater company or a refugee services provider. One solution, eBase, is free. Most mid-level products cost between $3,000 and $4,000. Slightly more on the cost/complexity scale is a clustering of products in the $8,000 to $10,000 range. Finally, the most advanced fundraising database can cost as much as $250,000 to fully implement. Client and case management solutions tend to lack the economies of scale and standardized business practices of accounting and fundraising. Smaller markets and a more complex problem space means that even simple systems can start at $20,000.
While vertical market solutions involve a more significant cash outlay than the self-developed system, the true cost to the agency can often be much less. Selecting a vertical market solution is essentially outsourcing application development and support costs. Because they are essentially off-the-rack solutions, they are known quantities and it is easier to evaluate functionality prior to implementation. While self-developed or consultant-written applications will result in a more customized solution, the development process starts with a leap of faith that the final product can be realized.
The traditional approach to vertical market software has been to license the application for installation on the nonprofit organization’s computers. In the best situations, there is a balance between the vendor’s responsibility to ensure that the application will run on the organization’s computer and the nonprofit’s responsibility to have the right equipment and install the software properly.
In the worst situations, there is a clash between software vendors, hardware vendors, and the organization’s technical or operations staff on where responsibility for problems resides. The complexity of desktop computers, networks and database software makes smooth installations and operations problematic.
The Application Service Provider (ASP) option tries to eliminate local support problems by keeping the database off of the agencies’ computers. With an ASP solution, the software publisher places the database on a secure Internet site and users can access the system from any Worldwide Web-connected computer through a standard web browser. Where a traditional vertical market database outsources application development responsibilities, the ASP solution extends that to include ongoing storage and operations.
The ASP solution also extends the possibility of system failures outside of the agency to include the Internet connection and database host. Any break in that chain means that no data is available until the connection is restored. Whether a solution is located on the Internet or on your local area network, the operational considerations are identical.
The most important issue with vertical market solutions is in adequately predicting costs. In addition to the initial licensing cost, other first-year costs include planning time, conversion of existing data, hardware and Internet upgrades, staff training and downtime.
After the first year, there will be ongoing support and training costs. ASP solutions tend to have lower licensing startup costs, but more expensive ongoing charges. The three-year total for ASP and traditional vertical market solutions are similar.
Another issue with vertical market software is that, while an application can do an excellent job of managing its core subsector business process, it can be a bad fit if other processes need to be integrated into one unified system. A fundraising package, for example, can identify volunteers, but the most sophisticated aspect of volunteer skills tracking and assignments may be missing. The solution in this case may be to use multiple vertical solutions, one for each area, or to hire a consultant to create a custom application.
Predictable costs, rapid implementation, and standardized tasks are the big pluses of vertical market solutions. If your agency’s operations are standardized and there are products available, it is worthwhile to evaluate the vertical market option.
The primary value of using a consultant is to create high-level custom solutions. Because the requirements are more sophisticated, the costs can be extreme. The benefits of this approach can likewise be extreme – a custom application that is completely integrated with every agency activity. Using the consultative process requires good specifications and a major commitment of staff to the project. Specifications keep the scope of the project under control, and staff keep the project focused.
The single biggest complaint with consultant-created applications is runaway costs. This is almost always due to scope-creep, where the specifications for the application are increased after the project starts, either through being added on the fly or as the result of poorly defined specifications being clarified at the hourly rate of the consultant.
One or more staff assigned as liaisons to the consultant is an important safeguard in this area. Staff who have become familiar with the consultants can facilitate change orders or other enhancements to the scope of work, and help both management and the consultants understand priorities and costs. Good consultants welcome this level of involvement because it helps them do a better job. At the conclusion of the project, the staff liaisons with the consultant often function as a resource for how the application is intended to function. Questions can be answered by walking across the hall instead of calling the consultant.
Even the best staff liaisons can become carried away in the application development process. By establishing project milestones, management can stay involved in the process and invoke go/no go approval at the completion of each phase. Milestones reduce risk by compartmentalizing the project. Typical milestones in a software project include phases for requirements, design, interface and reports, testing, conversion and training. The consulting contract or letter of engagement should include a description of each and a listing of specific deliverables.
Database software selection is not about the best product, it is about the best approach for your particular agency. Only someone from within the agency is going to have the insight to make the proper choice.
Effective information management is a complex combination of human and process considerations. By an analysis of requirements and a comprehensive understanding of resources, staff can select the most beneficial approach from among the choices defined in this article. Once that approach is determined, resources can be committed and final decisions can be made.
However, it is important to remember that no decision is final. Most software publishers are releasing upgrades to their software every 18 months to two years. It is unreasonable to imagine that a database in use today, whether it was built or bought, will necessarily be appropriate in three years. That is why we recommend that an organization re-evaluate the software in use every several years and consider the cost/benefit of switching to an alternate solution. With this approach it’s OK to make a small mistake in selecting an approach because that mistake can be corrected in a few years.
Tim Mills-Groninger is associate director of the IT Resource Center in Chicago and an NPT contributing editor.
NPT staff writer Jeff Berger also contributed to this story