Iowa County Recorders Association

Electronic Services Project Team

Meeting Summary

October 7, 2003

Participants

Sue Vande Kamp, Story County Recorder Dave Erickson, Iowa State Bar Association

Joan McCalmant, Linn County Recorder Jenny Tyler, Iowa State Bar Association

Karen Benschoter, Kossuth County Recorder Kim Axtell, Title Guaranty

Marty Minnick, Calhoun County Recorder Mark Harmening, Iowa Land Title Association

Mary Miller, Adams County Recorder Bob Hartwig, Iowa Bankers Association

Tim Brien, Polk County Recorder Sandy Burke, Community Vitality Center

Scott Williams, Marshall County Bob Rafferty, The Rafferty Group/

Mitch Tollerud, Scott County Public Strategies Group

Carmella Zenti, Polk County Joel Romey, Land Surveyors

Jim Rice, Cerro Gordo MIS Phil Dunshee, Enterprise MidAmerica/

Public Strategies Group

Bob Mulqueen, Iowa State Assoc. of Counties Lisa Sinclair, Enterprise MidAmerica

Welcome and Introductions

Following introductions, Phil Dunshee summarized his role as Project Manager and emphasized the importance for open communication throughout the project with members of the Task Force and all stakeholders.

Review Project Scope of Work

·  Develop a Project Plan, Schedule and Budget

The near term project goal is to make tangible progress early prior to the end of the calendar year. The Project Team and Task Force will be review specific policies and standards, and the Project Manager will act as a bridge between all customers and those delivering the technology. We will define specifications and outline the stakeholder preferences in a format that will assist the selected vendor(s) with the design of the application. This will be an ongoing process in order to facilitate future updates and make improvements. The Team will have input in the planning process, and the Task Force will be responsible for decision making and selecting a vendor.

·  Coordinate and Summarize Stakeholder Input (internal and external)

Anyone who is a customer is a possible stakeholder and the list of stakeholders will be expanded as needed. The Project Manager will be developing documentation of what internal and external stakeholders desire in the proposed Web application. In October we will be gathering input from various stakeholders. Affiliates of ISAC are considered as internal stakeholders that may be involved or affected by this project. It was suggested that other county officials, such as the Assessors, be included as stakeholders.

·  Document System Requirements

At this time, there is not a list of system requirements. System specifications concerning information technology platforms will be developed as required for the request for proposals.

·  Develop and Execute a Request for Proposal (RFP)

In collaboration with ICIT representatives, the Project Manager will develop a request for proposal document which includes the specifications for the proposed Web application, and the evaluation criteria for selecting a qualified vendor(s). The Project Manager will facilitate the process of accepting and reviewing proposals. The final decision concerning the selection of the vendor(s) will be made by the Task Force.

·  Facilitate Vendor Communications and Project Activities

Following the selection of a vendor(s), the Project Manager will oversee the work of the vendor(s) under the direction and guidance of the Task Force. Activities that will be included in this role will include Project Oversight and Control, Application Design, Testing and Implementation, and Change Order Management.

·  Develop a Marketing Plan

In conjunction with the development of the proposed Web application, strategies and tactics for informing customers about the system and for encouraging system usage will be developed.

Review Preliminary Project Schedule

The initial focus of the project will be to gather and summarize customer requirements for the system. By the end of October, a refined project schedule will be developed which will include a list of stakeholder and customer requirements and a master list of requirements for the vendor.

Stakeholder Input Schedule

In September, we began reaching out to various stakeholder groups in order to schedule meetings with representatives from the Iowa Bar, Credit Union League, Iowa Bankers, Mortgage Lenders and Realtors. We also plan to schedule a meeting with the Land Surveyors and Abstractors. Our goal is to have as many meetings as possible in October. If possible, there should be one Recorder in attendance at each meeting. The Task Force may designate Recorders at their discretion.

Communications Protocols

All groups involved, including ISAC and its affiliates, will be included in email distribution lists and will be kept apprised of project development.

A project website will be developed.

This website will contain:

·  documents such as meeting summaries with Stakeholders

·  general updates of project activities and emails

·  a record of all input received

This website will NOT contain:

·  working documents by the Resource Group and Task Force (until approved)

·  Requests for Proposal (RFP) drafts (until approved)

Policies and Standards

The Project Task Force has generally determined that the proposed Web application will require the adoption of PRIA standards with some exceptions. These policies are being established by a separate committee of the Recorders Association, and may be finalized later in 2003. The request for proposal will instruct prospective vendors that PRIA standards will be followed.

Information Technology Planning

The activities of a related ISAC/Public Strategies Group project were reviewed. Generally, a planning effort is being initiated to explore the development of electronic service delivery for other county government functions. These activities will need to be aligned with the design of the proposed Web application for land record access in order to create opportunities for coordination and shared resources. The next Information Technology planning meeting is tentatively scheduled for October 30, 2003. [This meeting was postponed and will be rescheduled.]

Participants in that meeting are expected to discuss the following topics:

·  other services and products that would be suitable to send over the Web

·  how customers will perform multiple transactions on the website

·  how the customers will need to identify themselves

·  how the website will be secure

Product Design and Definition

The Project Team participated in a discussion of the many elements to be included in the proposed Web application, and sought to address the following questions.

·  What will customers receive?

·  How will they access it?

·  What are the issues and barriers?

·  What are the options and solutions?

The following comments reflect various ideas and perspectives about the project, and should not be interpreted as a final decision or recommendation. Specifications and requirements for the Web application will be established in the request for proposal.

Our goal is to provide an electronic service which would make information accessible through the internet and available through transactional activity. We want to provide information that has a relationship to the county outside of the Recorder’s scope and to look at this project from the customer’s point of view. We need to remember that we are building this based on functional needs and not based on the technology.

An implicit requirement of this system is to enable the use of electronic/digital signatures so documents can be recorded online.

Statewide forms should be uniform and accessible online. A form can be either printed and mailed, or completed online and submitted.

Forms for marriage licenses, trade name licenses, birth/death certificates and passports must be paid for in advance and therefore cannot be done on the computer without electronic signature.

Licenses including boat, snowmobile and conservation could be transacted online.

What information should be accessible online?

·  acceptance of electronic legal forms (online filing)

·  transfer tax calculator

·  document imaging with electronic signature

·  smart documents

·  basic county office information (e.g., location, hours of business)

·  access to land and business records

·  disclaimers regarding military and vital records

·  formatting information as to how to do business with the Recorder’s Office (a tutorial)

·  law changes

·  FAQ on state and local levels

·  links to help customers find referrals to other resources (e.g. traffic tickets, courts)

·  navigation by county information (e.g., zip code or search graphic map)

·  magistrates

·  miscellaneous county information

·  links to, or alignment with other groups in the county, such as the Treasurer and Auditor, using similar tools or infrastructure but avoid repeating LegalEngine.com

Current web applications require customers to search themselves and print out what information they find. Will this be acceptable in the future?

We hope to allow and include:

·  export data

·  field base searches

·  spatial analysis using selected boundaries

·  existing fields in a database

·  batch searches

·  batch imports

·  shopping cart method of search and print

·  keyword search

Because the technology is out there, we should be aware of issues and perceptions concerning out-of-state users.

Whether or not county residents should be charged for the service was discussed. Perhaps we need to develop a pricing scheme with different levels of cost or only charge in order to cover our costs.

We should explore whether or not to have digital formatting.

To make the Recorder’s job easier, it will be necessary to build uniform applications into the architecture for later use. Also, we need to plan for the adoption of functions which may be useful in the future. For example, Auditors wish to approve documents before they are recorded. Other offices will not have to redo steps and this can save on expenses.

Stakeholders need to consider their business processes before the next meeting so we can define the way specific elements included in this service will help work through those business processes.

The program writers will need a high level of detail:

·  consideration of how things will be done electronically

·  consideration of future changes

·  consideration of workflow

The role of the Auditor’s Office was discussed. It was determined that we should design the architecture so as to establish standards for future applications for other affiliate functions, including the Auditor if possible. It would be helpful to have a link between parcel identification numbers and GIS (Geographic Information System). Also, a parcel and legal relational table would be beneficial. A possible problem is that some systems would have to be renumbered. It was noted that a customer would typically refer to a map site first and then pull-up the document or identification number.

Ideas on how the customer will access information:

·  open access

·  land records site

·  a broader definition of land record information that seeks to provide more information (with Assessors, Auditors, Treasurers, etc.)

·  county websites should link to the state website with some template uniformity (counties not online would be included at state site

·  subscription (not necessarily with a fee)

à  customer would need a user identification number and password

à  Recorders want to know who is using the system

à  Recorders do not care to track searches

à  redaction capability required

à  register online and wait for password to be issued by office

*  verify identity

*  payment mechanism

*  time for denial (e.g., having bounced a check)

*  build a profile

Recorders conveyed they want to support county identities and not just a Recorder site.

They believe the customers will be their county residents and just want easy access to their desired information whether it be on the county or state level and can be trained to use the county site.

Some stakeholders suggested it would not matter if the information was located at the county or state site as long as functionality or links were compatible and there was a uniform methodology throughout the system.

There must be cross functionality because each office has its own specific information requirements (e.g., address, parcel number, name) and it would be helpful to the customer to be quickly referred to the office using the information the customer has.

The Task Force needs to consider whether to have the county sites appear the same, similar or different from one another.

A feature not discussed at this meeting is the idea for a special, secure site over which the Recorders could communicate. Possible information stored on this site include:

·  communications

·  questions

·  meeting requirements

·  staff training information

·  management features

The next meeting of the Project Team is scheduled for November 6, 2003

5