The creation of shadow databases can result from many factors.

Availability and Marketing of Central Systems

In medium to large institutions, non development staff may now always be aware that there is a central system of alumni and donor records and what the official policy on shadow databases are. Coupled with this, advancement support staff may not always be the most knowledgeable about marketing techniques and how to promote the value and virtues of the central database throughout the campus.

Overall campus orientation practices may not include a discussion other than in a very general sense of development and advancement let alone any systems that support these activities.

Data Integrity Issues With Central Systems

One of the most common justifications for shadow databases is that "the data we have in our department is more accurate than that which is maintained in the central system."

You to be wary of this statement but also react to it. Make sure you are meeting industry accepted standards regarding addressable rates and that your data has integrity.

It can also mean that users may be actually storing data in a way that you don't store it on the central system such as they way they do their joint invitation names.

System Functionality

Systems that don't have adequate functionality for supporting all facets of advancement operations also lead to the creation of shadow databases.

Many departments will create shadow databases to maintain their donor recognition and naming information. Few advancement systems currently have a naming module which can adequately manage the data associated with naming such as the building, the rooms within a building, the plaque on the wall in the room and the name on the plaques.

Those With the Gold Make the Rules

Development of shadow databases can often be initiated in departments and schools that have more resources and the ability to focus resources on their "specialized needs".

The ability to make these types of departments cease using their shadow databases can also be subject to a greater degree of political considerations and maneuverings.

Training

A development system may also be difficult to use.

The writer of this article remembers very distinctly being at an institution where the records staff stated that in order to receive your password to the database you had to take a minimum of 2 days of training after which you were required to take an exam, where it was likely you would fail the first time.

While training is necessary, the above example clearly illustrates why someone might be more interested in just setting up a shadow database to keep a mailing label list for their department.

Report and Data Request Turnaround Times

What is your turnaround time for requests?

Users expectations are higher and if they have to wait 2 to 3 weeks to get a set of mailing labels, it's obvious why they might want to set up a shadow system so they can expedite their request.

Data Needed for a Web Site

Tied in with system functionality, but a somewhat different issue.

Sub units of the organization may need data to put on their web site such as membership lists.

These lists, which are typically not refreshed from the main database are in fact shadow databases and may quickly get out of date. In addition, since they are on a web site, the risk of public exposure and liability due to incorrect data is greater.

Enhancements

Shadow database projects have a way of growing and soon, what was a simple list will have evolved into an actual system with its own coding structures, data integrity rules, reports maintenance practices and more.

Some departments may even insist that they should have their own advancement system since they've so aptly demonstrated the they can manage it.