|
|
|
Lessons Learned
|
The database design: The key to success
Michael A. Nicolls
Analytical Surveys, Inc.
1935 Jamboree Dr., Suite 100, Colorado Springs, CO, 80920
Abstract
As the end-users of geographic information systems become more sophisticated and end-user sofhvare
becomes more powerful, the data required to allow those systems to function becomes more difllcult,
and therefore more expensive, to produce. Unfortunately, the amount of time and effort being put into
producing the database design document, or data conversion specification, is not increasing in a similar
fashion. This paper will address the production of this critical document in some detail, with its goal the
minimizing of uncertainties and ambiguities on the part of both the end-user of the data and in particular
on the part of the data conversion vendors chosen to receive the Request for Proposal (RFP), thus
allowing for more accurate and meaningful responses to the RFP.
At a minimum, a quality database design document should accomplish the following three tasks:
- Every data item needed by all end-user parties to the GIS should be accounted for in the document.
- Detailed footnotes should be included, spelling out exactly what each item is to contain, and what the
source / selection criteria will be for each feature.
- The document should be complete and final before the RFP for data conversion is released to vendors.
Introduction
A thorough survey of the proceedings from each of the major geographic information system (GIS) user
conferences (URISA, AM/FM, GIS / LIS, and ACSM / ASPRS) over the past five years reveals a
number of papers and presentations on the related subjects of database designs, data conversion issues,
requests for proposals, and data conversion contractor selection. It is interesting that virtually all of these
papers are written by people who work for data conversion companies. This paper is no exception. All
of these papers have pointed to the need for more thorough up front work by the end users (governments,
utility companies, etc.) and the consultants hired by them in the analysis and design of the needs of the
GIS users. Despite this and despite the fact that most GIS industry insiders recognize that the data
conversion is the single most expensive and important part of the GIS implementation effort, with few
exceptions, the Requests for Proposals coming into the offices of this writer’s company do not reflect
nearly as much forethought and prior work as there should have been before the release of the RFP.
Trent Meyers (Meyers, 1994) has pointed out how many people in the GIS industry have experienced
situations where bids have been solicited from qualified vendors, only to find that the bids will vary by
several tens if not hundreds of thousands of dollars, leaving the entity seeking the data conversion
services extremely frustrated and confused. There is a good reason why these situations occur. Usually,
critically needed information is lacking in the documentation provided with the RFP, leaving the
conversion vendors to take educated guesses about many of the undefined and unknown (to them)
variables. In order to protect themselves against these unknowns and the almost inevitable increase in
the scope of work that occurs in these kinds of projects - for which the RFP issuing entity rarely wants to
pay - data conversion service companies are forced to build extra cost into their bid price responses to
these RFP’s. If the RFP is pai-titularly bad, the data conversion company may even elect not to respond
at all. As William Reid has pointed out (Reid, 1992), responding to an RFP costs a significant amount of
time and money, often several thousand dollars, and these costs must also be passed on to the data
conversion companies’ clients in the form of higher prices for services.
The Solution
Just what exactly is a “database design document” or “data conversion specification”? Nancy Lerner and
Dave DiSera (Lerner & DiSera, 1996) define the document as “A combination of a physical database
design, database quality and accuracy requirements, source document information, and requirements for
the data capture or conversion process”. While most that are issued in the industry do one or two of the
above mentioned tasks well, very few address all four issues to the extent necessary. What can be done
about this situation in order to ultimately reduce both the data conversion companies, and therefore the
requesters’ for services, costs? The following suggestions provide a starting point for discussion.
- Develop a source data matrix. Both Anthony Thorpe (Thorpe, 1995) and Andrew Hawkes (Hawkes,
1994) have described and discussed the value of a source matrix to the conversion requester. Briefly,
creating a source matrix involves a thorough review of all sources to be used. These sources include
aerial photography, paper maps and other documents, digital files of all types (e.g. text, database and
graphic) or data types generated in software from other types. Every feature type and attribute required
is entered into a column with both primary and, if appropriate, secondary sources defined. Usually just
the process of doing this forces the end-user to make many significant decisions concerning the final
product. The alternative is to have the selected data conversion company discover all of the anomalies
and begin a continual bombardment to the customer of questions, requests and complaints about data
items not covered in the database design, conflicts between differing data sources, etc.
- Give careful thought to the data required. In particular, several issues in data conversion can cost
quite a bit more than the end-user might realize. Meyers (Meyers, 1995) has pointed out how exact
replication of source documents, unreasonable accuracy requirements (especially given the source
documents to be used), and additional attributes can all drive up the cost of a data conversion project
significantly. It is critical for the consultant contracted by the data end-user to point out these issues to
their client and steer them away from spending more than their applications will ultimately require. Not
only is quality and the extra work required to ensure it not free, it’s not particularly cheap either.
- Discourage the release of preliminary /incomplete database design documents in RFP’s. If a
database design is not complete, an RFP should not be issued. There is no more sure way to drive up the
cost of a conversion effort than to continue to revise the database as the bidder selection process, contract
negotiations and conversion process proceeds. Most responses to RFP’s by data conversion companies
contain a lot of padding to account for the inevitable “scope creep” engendered by poor database design
documents. The only way to avoid this extra cost is to convince those companies that respond that this
will not occur by proving to them that all of these data issues have been thoroughly thought out.
- “Freeze” the database design except at critical milestones. Recognizing that even the best of
efforts by the end-user and GIS consultant will miss items, and that as the project proceeds from
prototype to pilot to fidl-scale conversion (Thorpe, 1995) changes will occur, allowance must be made
for changes to the document. However, these must occur only at significant junctures during the data
conversion process or much expensive rework will have to occur for which the conversion provider will
want to charge. In other words, the database design should be unchangeable from the time the RFP is
released until a conversion company is selected, again from when contract negotiations are completed
until the prototype file is converted, a third time from beginning to end of the pilot phase of a project,
and finally from the time the pilot is accepted until the project is complete. Any changes to the database
during these “open” periods can be reasonable cause for additional contract amendments on the part of
either party, and should be written into the original contract as such. The point is that with sufficient up
front work on the part of everyone, changes will be kept to a minimum and should not be a basis for
additional charges. It is even possible that the contract amount could go down should unneeded items be
eliminated by the end-users.
|
|
|
|
