Managing Records: Electronic Records: Managing GIS Records: GIS Development Guides

GIS Development Guides

Acquisition of Hardware & Software

  1. Introduction
  2. GIS Hardware and Software Acquisition
  3. Steps in the GIS Acquisition Process
  4. Evaluation of Proposals
  5. GIS Delivery and Installation Plan
  6. Sample Hardware Specifications
  7. Network and Communications Specifications
  8. Software Specifications
  9. GIS Database Structure
  10. Summary
  11. Glossary

1. INTRODUCTION

This guide begins the description of the first of four steps of the GIS Development process which deals with the actual assembly of the GIS and its subsequent operation.

All of the necessary planning, design and testing should have been completed during the execution of the previous seven steps of the GIS development process. The remaining steps and their main purpose are as follows:

Top of page

2. GIS HARDWARE AND SOFTWARE ACQUISITION

This step is the actual purchase of the GIS - hardware and software. The GIS to be acquired is usually subject to competitive bid by the interested vendors. The single most critical part of this process is the preparation of an adequate (and detailed) Request for Proposals (RFP).

Acquiring the components for your GIS is an important step. Use all of the information you have gathered up to this point to produce a document telling prospective bidders what you need. The document should clearly communicate your needs and how bidders should respond to the RFP.

During this phase remain objective. Keep as much of the "politicking" out of the selection process. You should be looking for the best value for your money, not the lowest cost.

Top of page

3. STEPS IN THE GIS ACQUISITION PROCESS

Evaluation Team

The evaluation team should be made up of interested staff from departments involved in implementing GIS within the local government. These individuals need to be objective and not have pre-defined ideas of what system they want. They need to be action oriented and willing to put in the time to do the job right. A successful RFP process involves a great deal of hard work and coordination. You will need to have people on the committee to help accomplish this.

Once a draft RFP has been developed, have an objective 3rd party look at it. You want it as complete and readable as possible. This can be another local government (maybe one of the ones how supplied you a copy of theirs) or a consultant helping you with the RFP process (make sure the consultant is not planning on bidding on the project).

Preparation of Request for Proposal (RFP)

The RFP document is used to communicate your needs to potential bidders. It will also tell bidders how you want them to respond to the RFP.

Be as specific as possible in defining what you need for your GIS. Provide detailed descriptions of the functionality, services and support you are looking for. It is recommended that you do not use specific brand names of software and hardware products in your RFP specifications. This will limit the number of potential bidders you can choose. There will be situations where specific products are needed. An example is when your organization has a policy in place for using a type of operating system or has already standardized and developed data sets for use in a particular software package. Focus more on what you want the system to do. You will not get what you need unless you specify it clearly in the RFP.

In your RFP, tell the bidders how you want them to respond. Provide examples of what you want: define how pricing should be structured, use standardized forms if appropriate, clearly state criteria for evaluating the responses. You will receive responses that are more consistent and easier to evaluate if you define the response guidelines in the RFP.

To get started, contact other local governments who have recently developed similar RFPs. Use these as a guide. It would be a good idea to contact the person responsible for evaluating the responses. Ask them what worked and what didn't work with the RFP. Adjust your RFP accordingly. Also adjust the scope of your RFP to fit your needs. If you are a small village, don't use a RFP developed by a larger city (or visa-verse) you will not get what you need and the potential bidders will be confused or mis-directed.

Distribution of RFP

You will want your RFP to go to qualified bidders. The best source for this is to go to trade shows or GIS user group meetings and ask around. Again, try to stay objective. Don't get mis-lead by flashy demos or excessive hype. Talk to other local governments and get recommendations of companies they think are qualified to respond to your RFP.

Another method might be to post a notice in GIS trade journals (both regional and national). Be prepared for a large amount of companies inquiring about your project. This method is better used for large, expensive projects.

Bidder's Meeting

A bidder's meeting should be scheduled within a week or two of the RFP be sent out. Make sure the time and location is in the RFP. This meeting is used to get feedback from the bidders and to clarify anything not clearly stated in the RFP. It is always an interesting experience to have number of competitors gathered together in one room. There will be a reluctance by the bidders to ask any questions that might give away their bidding strategy to their competitors. Do not be surprised if there are not many questions raised at the meeting. To get things going, have a short prepared statement or presentation that outlines the history of the project and the requirements of the RFP.

It is important to ask the bidders to submit written questions to you in a specified period of time. It is also recommended that all written questions and your responses be compiled and sent back to all bidders. This will provide consistency and fairness in the process.

The purpose of this meeting is to communicate to all bidders what you need and how you want them to respond.

Answering questions

In addition to the written responses from the bidder's meeting, you will need to provide some mechanism for answering ad-hoc questions from bidders. The best way to do this is to require that all questions be faxed or e-mailed to a specific person and provide a response within 24 hours. It would be impractical for your organization to provide these ad-hoc questions and answers to all bidders. It would be a good policy to take questions up to the submission date for proposals. After that date no correspondence between a bidder and people involved with the selection process should be allowed.

Deadline for submission

Establish a deadline for submission. All responses must be in by the specified time and the specified location in order to be considered. Set your time to be a few hours before the close of business. Inevitably a bidder will get stuck in traffic or a courier will be delayed. This will give you a little cushion and allow you time to check in responses while still allowing you to go home at a reasonable time.

Top of page

4. EVALUATION OF PROPOSALS

Evaluating proposals should be done by the RFP committee with all the members using the same criteria as listed in the RFP. This process should be documented in case a protest arises. If you have been specific defining your GIS needs and defining how bidders needed to respond, the evaluation process should be straight forward.

Sample Questions - Has the bidder:

Criteria for Evaluation

It is important that this process be documented in case a protest is submitted or to explain why a proposal was not accepted. Each of the criteria needs to be measurable or quantifiable.

Functional capabilities
In the Needs Assessment phase GIS functionality was identified and documented. This documentation of functionality should be defined in the RFP and used for this evaluation. Develop a checklist of the various functions and have each committee member fill out the checklist for each proposal.

Vendor Support
Without proper support any system is doomed to failure. Part of the evaluation is to understand the type of support being offered. What kind of response time is being offered and what are the standards. Will the vendor provide answers to a problem within 24 hours of a call? Will they provide on-site vs. factory service for hardware problem? Make sure you are comfortable with the level of service being offered.

Cost / Maintenance Fee
There are a lot of ways to state the price of a proposal. It is recommended that you be specific as possible in the RFP and bidder's meeting about how the price should be structured. The more pricing can be itemized in the proposal the easier it will be to compare the responses to each other. A suggestion is to develop a pricing form for each bidder to fill out and include with their proposal. As a minimum have separate pricing for software, hardware, services and support. More detail for each of these sections would be nice, just don't get too carried away.

Interviews / Benchmark Test (see Benchmark Test Guide)

After the RFP committee has evaluated the written proposals, a "short list" of bidders should be agreed upon. Any proposals that are not in compliance with the RFP or do not rank high in the evaluation should be eliminated from consideration the remaining bidders compromise the short list. Some marginally qualified bidders many need to be eliminated as well to keep the short list of bidders a manageable size. These short list bidders will be invited to a interview and/or a benchmark.

During this process you will be evaluating the bidder on:

Selecting a Proposal

Once the Interview / Benchmark is completed. The RFP committee members should compile all of their evaluations independently then meet as a group. This meeting should review all of the proposals and begin to focus on which proposal to select. At this meeting questions may arise that need to be answered in more detail. Take the time to get these answers from the bidder before a selection is made (generally a phone call will work but sometimes a follow up interview is needed if practical).

Once all of the committee's questions are answered, it should move quickly to making a selection and notifying the bidders. At this point a contract needs to be put in place that defines the scope of work outlined in the RFP. This contract needs to be executed before any further phase of GIS implementation is started.

Top of page

5. GIS DELIVERY AND INSTALLATION PLAN

Once you have selected a vendor(s) for your system you will need to coordinate the delivery and set up of all of the components. there are many resources to call on to do this. The most obvious being the vendor. They should have demonstrated that they have some level of expertise with GIS and can help you get up and running quickly. It is a good investment to buy their services to install and set up the system for you. These services can be contracted for on a time-and-material basis or under a scope-of-service contract.

The most effective means of describing how to prepare the RFP is to do so by example. The remainder of this guideline consists of selected parts from an actual RFP, - presented here to illustrate the scope, content, and level of detail needed. A properly prepared RFP increases the chances that the vendor responses will be most appropriate to the needs of the local government.

Top of page

6. SAMPLE HARDWARE SPECIFICATIONS

Specifications for a system configuration to support Geographical Information System (GIS) development and operational applications follow. The system configuration consists of various devices that will be networked together to support data capture, storage, processing and display in both digital and hard copy forms, including:

The proposal shall include technical and functional capabilities of the devices offered to meet these specifications. Provision of the following information should be included for each device:

GIS Workstations

The Mapping/Analysis workstations will support a wide range of GIS activities, including database development, database quality control, user application development, database maintenance and all GIS applications supported by fully functional GIS software such as cartographic production, geographic database queries, and advanced geographic analysis using both spatial and attribute information. One of the GIS workstations must support high capacity data storage, and multi-user GIS processing, and should perform all GIS operations and applications within acceptable user response times.

General Specifications for Workstations:

Specific Details of Workstations:

Both workstations should support the following hardware specifications:

Small-Format Color Printer

One (1) color printer will be used for the production of color hard copy graphic plots and nongraphic report generation.

The color laser printer should meet the specifications or equivalent described below:

Sample hard copy outputs from the proposed device(s) shall be included with the proposal.

Cartridge Tape Drive

The system should include one (1) 4mm DAT tape subsystem for the Planning and Zoning Department. The tape should have a capacity of not less than 5 GB. The tape subsystem will provide a mechanism for performing system and data back-ups.

Large-Format Color Raster Plotter

A color raster plotter shall be included for the production of high quality, large format cartographic products. This device must provide a high-volume color plotting capacity. The plotter shall support 36" x 42" plots and produce color plots at a minimum resolution of 300 dots per. The plotter shall be compatible with the proposed LAN hardware and communications protocols and must be accessible by all workstations on the LAN. A sample hard copy output from the proposed plotter(s) shall be included in the proposal.

Additionally, the plotter shall meet the specifications described below:

Provide four (4) replacement paper rolls with the printer. The paper should be a high quality glossy bond.

Top of page

7. NETWORK AND COMMUNICATIONS SPECIFICATIONS

There is a requirement to connect new hardware in two departments. Existing software consists of Intergraph's I-Dispatcher, emergency response dispatch system. Requirements for each level of communications are outlined in the section below. Vendors shall state the level of compliance and provide a description and cost quotation for all hardware and software components needed to meet the requirements at each level of data communications. Vendors should include in the cost proposal the cost of any specialized hardware devices that will be required to implement the proposed communication network.

Network Processing Requirements

Network processing requirements are as follows:

Network Management and Monitoring Capabilities

The proposed physical network should also be able to perform the following network management functions:

The proposal shall include all cabling and devices required to implement all data communication connections, utilizing existing facilities.

Network Speed and Capacity

The proposed system must operate at a minimum raw data speed of 10 megabits per second. The Proposer shall provide information about the upper limit in numbers of mapping/analysis/query workstations that can be supported without major degradation in response time or error rates on the proposed network.

Transactions and Data Exchange with Existing Systems

Initially, the GIS network will not support on-line links with the existing IBM mainframe. Access to data residing on the mainframe will be accomplished by downloading data onto 9-track tapes and then re-writing this data onto current industry standard media such as 4mm data tapes or CDs.

Top of page

8. SOFTWARE SPECIFICATIONS

Software Component Overview

The GIS software components shall fully support and exploit the capabilities of the proposed hardware platform and shall provide full functionality for entry, editing, maintenance, analysis, display, and hard copy output of both graphics and tabular data on a continuous and interactive basis.

For purposes of this procurement, software component capabilities have been grouped into the functional categories of:

Data Editing And Maintenance

The proposer shall describe the tools and capabilities of the proposed system to modify and manipulate spatial and attribute data in the GIS for the following categories:

Data Query And Analysis

The proposed software shall support the following data query and analysis capabilities:

Data Display/Output

The data display and output tool capabilities that the proposed software shall support including the following:

Application Development

The Proposer shall propose one of more software components that, in a well integrated manner, provide the following capabilities and features:

Basic Operating System Requirements

The operating system component of the software shall be the primary operating system of the proposed hardware platform and shall provide all of the traditional features of current operating systems as described below:

Network Management Functions

The proposed system shall provide capabilities for monitoring and managing all data and devices on the GIS network as one unified system and support the following capabilities:

Top of page

9. GIS DATABASE STRUCTURE

Database Model

A GIS database model defines the nature and usage of spatial (geographic)data with a database. The proposed software shall support a spatial data model that is capable of creating, managing, and manipulating data sets, defined on the basis of spatial coordinates and associated attribute data sets.

Feature Types: The data model shall support multiple feature types including point, node, line, polygon, and text features

Data Storage: Features shall be stored as double precision x and y coordinates

Data Types: The data model shall support multiple graphic and nongraphic data types

Database Organization: Vendors shall describe strategies for organizing data into logical groups on the basis of data themes, and shall describe the capabilities of the data model for supporting simple and complex feature types.

Topological Data Structures

The geographic data model shall support the creation and maintenance of topological data. Topology shall be created through execution of a software function to structure graphic data sets. Vendors shall describe the ability of the proposed data model to support logical polygons, networks, and user-defined topological structures.

Design

Software capabilities that support large-scale engineering and design activities should be outlined as well as specific engineering functions and appropriate modules.

Raster Image Data

The Proposer shall describe support for storage of raster map images (e.g., scanned bluelines, orthophotos) and for raster scanned documents.

Continuous Geographic Database

The geographic data model shall support the creation and storage of a continuous geographic database

Relational Database Management System

The Proposer shall recommend a relational database management system (RDBMS) that will be able to maintain a minimum of 30,000 records of parcel ownership information in a single table and shall provide functionality for updating database content, queries, and production of reports. The recommended RDBMS must be either a part of the GIS software or have a direct access capability.

Top of page

10. SUMMARY

The RFP sections presented above give a good example of the scope of topics and level of detail needed. This particular RFP did not present a conceptual data model for consideration by the vendors, but rather specified general characteristics for the GIS data model required. An actual conceptual data model, rather than its general characteristics, could be more useful to vendors, and thus more productive for the user's organization.

Top of page

Return to Table of Contents