Charter SVRS

Project Charter:
Statewide Voter Registration System

Prepared for:
Wisconsin State Elections Board

May 15, 2003
Prepared by
Ten Terrace Court

Madison, WI 53707
608-249-6622
www.virchowkrause.com
May 15, 2003

Mr. Kevin J. Kennedy, Executive Director
Wisconsin State Elections Board
132 East Wilson Street, Suite 200
Madison, WI 53701-2973
Dear Kevin,
Re: Statewide Voter Registration System Project Charter
Enclosed is the final report of Virchow Krause & Co., LLP for the study of the statewide voter registration
system (SVRS) for the Wisconsin State Elections Board. The SVRS is a significant initiative for the
entire state of Wisconsin. Successful deployment of a new system will require involvement and
investment at the state, county, and local levels of government. It will require a complex and lengthy
implementation.
For such an initiative, it is imperative that consensus be reached on the SVRS Project Charter before the
work begins. To that end we submit our report, divided into three sections plus appendices:
1.
2.
3.
4.
Executive Summary
SVRS Findings
SVRS Project Charter
Appendices
The Executive Summary provides a high level overview of the SVRS initiative, describing the current
situation in Wisconsin and the implementation steps the State of Wisconsin must take to achieve
compliance with the SVRS provisions of the federal Help America Vote Act (HAVA). Estimated costs of
the SVRS and cost reduction strategies are also outlined.
The SVRS Findings section provides a review of the SVRS study project, and presents important
information discovered during the analysis. The findings are the result of extensive discussions with
county and local officials, state agencies affected by the SVRS, the Department of Electronic Government
(DEG), other states, and three system vendors with previous experience in statewide voter lists. The
findings are logically grouped into major themes, each of which will have a significant impact on the
SVRS implementation and which therefore also shape the Project Charter recommendations.
The Project Charter is the definition of the SVRS implementation initiative. The objectives, scope,
assumptions and known risks of the SVRS initiative are documented, along with proposed draft statutory
changes. Flowcharts show the business processes and technical architecture of the new system across
the local, county, and state levels. Phased implementation plans provide the approach, high level work
steps, resources, and organization required to finalize the operational model at the county and municipal
levels, select the system vendor, and implement the system. Detailed 5 year total cost of ownership
schedules show a year-by-year cost estimate broken down by cost element, based on vendor RFI
responses and other agency cost estimates. Combined, these components provide a high level design of
the SVRS system which should be used as the basis for final policy, technical, operational, and funding
decisions.
Thank you for the opportunity to work with you and your team. While it has been a significant amount of
work in a very short period of time, it has been a pleasure and a privilege to work on this important project
with the State Elections Board, the Department of Electronic Government, the Department of
Transportations Division of Motor Vehicles, the Department of Corrections, the Department of Health and
Family Services, and the county and municipal officials. We appreciate the effort and cooperation of all
involved.
Sincerely,
Virchow Krause & Co., LLP
Keith Downey, Partner
Table of Contents
EXECUTIVE SUMMARY............................................................................................................................ 5
A.
B.
C.
D.
E.
F.
BACKGROUND .................................................................................................................................. 5
CURRENT SITUATION ........................................................................................................................ 5
SVRS FUTURE-STATE ..................................................................................................................... 6
NEXT STEPS .................................................................................................................................... 8
TOTAL COST OF OWNERSHIP ............................................................................................................ 9
COST REDUCTION STRATEGIES ...................................................................................................... 10
SVRS FINDINGS ....................................................................................................................................... 12

A.
B.
C.
D.
E.
F.
G.
H.
PROJECT BACKGROUND ................................................................................................................. 12

STATEWIDE VOTER DATABASE ........................................................................................................ 13
VOTER REGISTRATION STATISTICS COMPARATIVE COMPLEXITY .................................................... 14
FEDERAL AND STATE STATUTES ..................................................................................................... 15
POLICIES AND PROCEDURES ........................................................................................................... 17
INTEGRATION WITH OTHER SEB, COUNTY AND MUNICIPAL INFORMATION SYSTEMS .......................... 18
INTEGRATION WITH DIRECT IMPACT AGENCIES ................................................................................. 20
PACKAGE VS. CUSTOM SVRS SOLUTION ........................................................................................ 20
SVRS PROJECT CHARTER ................................................................................................................... 22

A.
B.
C.
D.
E.
F.
G.
H.
I.
J.
GOAL............................................................................................................................................. 22
OBJECTIVES................................................................................................................................... 22
SCOPE........................................................................................................................................... 22
ASSUMPTIONS ................................................................................................................................ 24
RISKS AND MITIGATION STRATEGY .................................................................................................. 26
FUTURE SYSTEM PROCESSES ........................................................................................................ 29
STATEWIDE VOTER REGISTRATION SYSTEM (SVRS) PLAN .............................................................. 30
STATEWIDE PROJECT ORGANIZATION STRUCTURE .......................................................................... 46
RESOURCE AND STAFFING ESTIMATES ............................................................................................ 47
FIVE YEAR TOTAL COST OF OWNERSHIP ......................................................................................... 49
APPENDICES
Executive Summary
A. Background
In October 2002, the federal government passed the Help America Vote Act of 2002 (HAVA). This
legislation created new election administration requirements for all states and called for an upgrade of
voting systems to better accommodate persons with disabilities. Specifically, HAVA calls for the creation
of a single, uniform, official, centralized, interactive computerized statewide voter registration list defined,
maintained, and administered at the state level that contains the name and registration information of
every legally registered voter in the state. The current timeline for HAVA calls for election officials to meet
the majority of the HAVA requirements by January 1, 2004, and the remainder by January 1, 2006.
Extensions of the initial deadline (to January 1, 2006) are permissible and Wisconsin plans to submit an
extension request and expects it will be accepted. .
In December 2002, the Legislature provided funds for the State Elections Board (SEB) to study and
prepare specific recommendations for implementing a statewide voter registration database system
(SVRS), including a proposal for the systems cost and proposed legislation required to initially implement
such a system. The Elections Board retained Virchow Krause & Co. LLP to assist with the study, analyze
the central and local system requirements, and develop and issue a request for information (RFI) to
potential vendors of statewide voter systems and other interested vendors. This report and the enclosed
Project Charter represent the results of that study and the RFI.
B. Current Situation
The State of Wisconsin does not currently have a formalized statewide voter registration system or
process. Consider the following:
Under the present statutes, only municipalities that have a population over 5,000 are required to
register electors.
There are some individual municipalities that have voter registration systems to comply with
statutory requirements.
Some counties maintain voter registration data for municipalities and some municipalities
electronically maintain elector lists but do not register voters.
Most municipalities have no record (manual or electronic) of its electors. Consider the following
data, collected from the November 2002 election:
Number of municipalities without voter registration
Number of voters in the November 2002 election
1,530
563,272
Number of municipalities with voter registration

Number of registered electors
Number of voters in the November 2002 election
320
2,625,353
1,363,789
Estimated size of statewide voting age population
4,100,000
Furthermore, there are over fifty different software solutions (e.g., Workhorse Software, Town Hall
Software, etc.) and fifty custom applications being employed by those 320 municipalities, including
custom applications in the states largest municipalitiesMilwaukee and Madison. Associated with those
varied solutions are a myriad of policies and procedures.
In summary, the current activities and processes supporting voter registration are:
Currently managed at the local levels,
Largely decentralized and non-standard, and
Effective in maintaining the integrity of the local electoral process.
To comply with HAVA regulations, the state will require new SVRS applications, processes and
procedures for the centralized voter list.
C. SVRS Future-State
Based on information from other states and from vendors who have implemented statewide voter
systems, it is clear that a statewide voter registration system is significantly different from a municipal
system both in kind and in degree.
A statewide voter system is not simply a municipal system with more records. A statewide system has
different integration processes (between municipalities and with other state agencies); it has different
security issues; different validation processes; different purge processes, and different scalability
requirements. The system has to accommodate various levels of technological sophistication and
volumes of transactions ranging from the City of Milwaukee, Milwaukee County (with up to 100,000
election day registrations) to the Town of Butler, Clark County with its 70 voting age electors.
The complexities of implementing a statewide system involving municipalities, counties, and multiple state
agencies require a very large scale project effort. Statutory, policy, funding, process, organizational, and
technical issues must be carefully addressed in order for this project to succeed. This is a unique
challenge for the state in a critical area where the right of citizens to vote is affected.
Furthermore, there is a body of expertise in statewide voter registration found in the SVRS package
vendors. No vendor with statewide voter registration experience proposed the development of a custom
application. There is a significant opportunity to leverage existing HAVA-specific software functionality,
expertise, and lessons learned. The State Elections Board SVRS initiative is much more than a software
development and implementation project, and the overall initiative may benefit greatly from leveraging the
knowledge and experiences of SVRS package vendors to ensure success.
The future statewide voter registration system will need to take into consideration the following factors
(see the Findings section for more detail on these elements):
Statewide voter databaseone centralized, unified list at the core of the electoral process.
Municipal informationthe SVRS is more than just voters; it requires the maintenance of
address, municipal, and voting jurisdiction information.
State statutesrevised in cosmetic ways, to modify language pertaining to municipal

registration and revised substantially to address new issues created by the existence of one
statewide elector database.
Policies and procedures for the 72 counties and 1,850 municipalitiesto insure the integrity
of the database, the number of users must be controlled and the policies and procedures that
gather the data must be standardized.
Integration with direct impact agencieshow often to integrate, what data to extract, how to
match and what to do with the other agencies data.
Costthe cost to the state and municipalities will vary significantly depending on the number
of users (i.e., degree of consolidation), the magnitude of conversion, and whether the state or
the vendor will host the application and provide on-going maintenance and support.
Statewide implementation and roll-outthe nature, timing and duration of activities to bring
the system live.
Initial and on-going traininga burst of activity initially, but on-going training as well, because
of the natural turnover in the office of municipal and county clerks.
Large scale technical architecturethe size and complexity of the system result in very
robust software, hardware, and connectivity requirements.
On-going operation and maintenance of both central and distributed system components
another cost of doing business that must be factored into state and local budgets.
The proposed future-state process map for Wisconsins statewide voter registration is depicted at a high
level in Figure 1, below.
Figure 1. High-Level Statewide Voter Registration Process Map
D. Next Steps
At a high level, the next phases of the SVRS initiative are shown below. Before proceeding with the
phased components of the plan, consensus regarding the project charter and funding must be achieved.
0. SVRS
Study
& RFI
Complete
1. Define Local
Operating Model and
Pre-RFP Planning
1-3 Months
5-15 Months
- Municipality Process
Consolidation
- Conversion Planning
- Local Operating Models
- Custom Development Due
Diligence (Optional)
- Finalize State Statute
Changes
2. SVRS Vendor
Selection
3. SVRS
Implementation
9-22 Months
- Project Planning and Scoping Refine Requirements

- Business Requirements and Identify Vendors
Gap Analysis
Vendor RFP & Eval
- Conversion Design and
Vendor Demonstration
Vendor Demonstration Mgmt Planning
- Implementation Planning
Implementation Planning
- Technical Design and
Configuration
- Testing Preparation
- Procedures and Training
- Conversion Preparation
- Development and Coding
- System Test
- Conversion
4. SVRS
Maintenance and
Support
On Going
Application Support
Hardware Support
Networking Support
Help Desk Support
Infrastructure Maintenance
Training
It will be critical to execute Phase 1 and 2 completely before attempting to move forward to the
implementation phase.
Of note, the Phase 1 activities must be completed in order for the vendor RFP process in Phase 2 and
the implementation in Phase 3 to be successful for the following reasons:
Failure to define the local SVRS environment in Phase 1, including the number of users, number
and type of conversions, operating models, statutory changes, and the consolidation of voter
registration functions across municipalities and at the county level, would make it impossible for
SVRS system vendors to propose fixed fee bids and accurate implementation timeframes. It
would also be impossible to accurately budget for the hardware and connectivity at the state,
county, and municipal levels.
Failure to complete Phase 1 would also impact the cost and risk of the implementation in Phase
3. Leaving these critical project scope decisions to the implementation phase could result in
significant rework, cost overruns, and delivery delays as discoveries are made during the
implementation.
If custom developed systems are to be considered (not recommended given the complexities of
the application and the value to the State of the experience gained by vendors with existing
SVRS systems), then the optional step of developing design specifications needs to be
conducted before the RFP is issued so custom development vendors would have an accurate
basis on which to propose.
Also, the Elections Board will need to carefully plan and budget for the staffing of this initiative. The
current staffing of the Elections Board will not meet the substantial time requirements nor the
implementation and technical skills required to manage a project of this magnitude. It must be recognized
up front that the Elections Board will need significant support from a combination of other state project
resources, external (i.e., outsourced) contract staff, and additional vendor support. These factors have
been considered in the preliminary staffing model and total cost of ownership estimates in the Project
Charter.
E. Total Cost of Ownership

Total cost of ownership of the SVRS initiative includes the following categories of cost:
Initial Software and Software Modifications (typically incurred in years one and two)
Software Maintenance (typically incurred in years two and beyond)
Software Implementation Servicesincluding project management, process development, initial

training, etc. (typically incurred in years one and two)
Initial (Central) Hardware (typically incurred in year one)
Initial (Workstation) Hardware (typically incurred in year one)
Hardware Maintenance (typically incurred in years two and beyond)
Hardware Implementation Services and Fees (typically incurred in year one)
Annual Training (typically incurred in years two and beyond)
Other Annual (typically incurred in years two and beyond)
Interagency Costs (i.e., charges from the Department of Health and Family Services (DHFS),
Division of Motor Vehicles (DMV), Department of Corrections (DOC) and Department of Justice
(DOJ)) (a spike in year on and also incurred in years two and beyond)
Elections Board, Department of Administration (DOA), and Municipal/County Staffing (a spike in

years one and two, and also incurred in years three and beyond)
Networking and Connectivity (typically incurred in all years)
The cost of software is a small fraction of the total cost of ownership. In the RFI responses from vendors
who have SVRS experience, application software and modifications represent only 20% to 30% of the
five-year total cost of ownership. Hardware, implementation, training, and on-going support and
management of the statewide system represent the vast majority of the total cost.
It is critical to note that the total cost of ownership is significantly influenced by three factors:
1. the number of locations and users,
2. the number of automatic data conversions, and
3. whether the scanning of registration applications at conversion or thereafter will be an element of
the system.
Through detailed implementation discussions with DOA, the direct impact agencies, and the three
vendors with SVRS statewide voter registration experience, cost estimates were developed to reflect a
set of low assumptions (i.e., a low number of locations/ users, no scanning, and technical support
provided by the state), and a set of corresponding high assumptions.
The estimated range of the State Elections Boards costs are summarized below (see SVRS Project
Charter, section J for a detailed breakdown of the total cost of ownership estimates.) The estimated low
and high total cost of ownership is shown on the following page (all numbers are in $thousands):
Phase
1 Define Local
Operating Model
and Pre-RFP
Planning
2 SVRS Vendor
Selection
3 SVRS
Implementation
4 Maintenance and
Support
Total
Year 1
Year 2
Year 3
Year 4
Year 5
Total
$475
1,195
$475
1,195
$0 - 90
$0 90
$6,725
10,424
$1,068
3,602
$8,268
15,311
$6,269
10,275
1,686
4,326
$7,955
14,601
1,677
4,326
$1,677
4,326
1,663
4,326
$1,663
4,326
1,663
4,326
$1,663
4,326
$12,994
20,699
$7,757
20,906
$21,226
42,890
NOTES:
1) Costs above include county and municipal data conversion, but do not include any county or
municipal hardware or connectivity costs. These are currently assumed to be provided by the
counties and municipalities.
2) The low and high ranges are largely the result of the three variable factors described above.
Strategies for these factors are expanded upon in the cost reduction section below.
3) The vendor cost estimates for the low assumptions were reasonably consistent; however, the
variance between vendors on the high assumptions was substantial.
4) Because information was gathered through an RFI, vendor specific cost information (and other
vendor specific system functionality information) are confidential at the request of the vendors.
F. Cost Reduction Strategies

A further review of the three main factors that drive the variation between the low and high cost
estimates reveals that there are significant cost saving opportunities available to the Elections Board:
Number of locations and users. If every municipality and county had full access to the system, it
would have to support approximately 3,000 users. The alternative is to consolidate the number of
sites and users to under 1,000. One consolidation scenario is to have counties or other
municipalities provide voter registration services for neighboring municipalities that do not
currently have voter registration. Based on vendor response, the consolidation of users would
save (millions) in software site license costs, hardware costs, implementation costs, and initial
and on-going training costs.
Conversion Data. The issue related to data conversion consists of defining the threshold below
which data is entered into the new system manually. The issue is a relatively simple cost benefit
calculation. The costs of electronically converting data from its existing format to the new are not
an insignificant task. The cost of typing registration forms into the new system can be done by
limited term employees.
Conversion Scanned Images. This issue consists of deciding whether original registration forms
are converted (i.e., scanned) during implementation and whether, on an on-going basis, scanned
images are an element of the system. The possibilities related to scanning are whether all forms
will be scanned, no forms will be scanned, or whether scanning is optional at the discretion of the
municipality. Scanning original documents will add millions of dollars to the cost of the project and
provide functionality that very few, if any, municipalities are using now.
We recommend that, prior to issuing the RFP, the state undertake the Phase 1 initiative to formally define
the operations of the SVRS across municipalities or at the county level and the consolidation within them.
We recommend that any data file smaller than 5,000 records be manually entered into the new system.
10
We recommend that no scanning of registration documents be conducted. If a municipality desires

scanning, it may be performed by that municipality, at its discretion and cost, and housed in a local
secondary processing system.
Currently, we recommend that DOA host the servers and applications and provide tier-1 support.
Furthermore, we recommend that the vendor provide application maintenance and tier-2 and tier-3
support.
11
SVRS Findings
A. Project Background
The State Elections Board (SEB) hired Virchow Krause & Co in January, 2003 to help the state research
and assess the options and alternatives associated with the statewide voter registration system aspects
of HAVA. The study focused on the following phases:
Benchmark
& Process
Design
Requirements
Definition
Identify
Vendors
Vendor RFI
& Vendor
Evaluation
Vendor
Demo
Prep
Vendor
Demo
Mgmt
Impl.
Planning &
Recs.
Project Management
Quality Assurance
Communication
Risk Management
The team focused a significant component of the study on current and future business processes,
including technical, functional and organizational requirements. This focus is based on the realization
that implementing statewide voter registration is much more complex than a software implementation.
Each of the deliverables from the phases above provides significant input into the content of this report
including:
Benchmark and Process Design A high-level definition of critical high-level voter registration
processes was documented as the foundation for benchmarking and requirements definition
activities. The team benchmarked the current situation for voter registration processes against
other states that have recently completed similar initiatives. The study documented critical
lessons learned and identified several requirements for the application and implementation
components of the SVRS solution.
Requirements Definition The team documented business requirements associated with voter
registration based on HAVA regulations and State statutes. The team defined over three hundred
application requirements during requirements definition and prioritized them. The requirements
served as the basis for the RFI document.
Identify Vendors The team spent time identifying, researching and qualifying a list of SVRS
application vendors. The vendors identified were asked to participate in the RFI phase.
Vendor RFI and Evaluation The team reviewed over thirteen SVRS responses to the RFI.
Three vendors were invited to present their application functionality, cost estimates and
implementation plans with the study team.
Vendor Demonstration Prep The team prepared a detailed demonstration script tailored to the
specific requirements for the State. The script included sample data allowing the team to view
application functionality.
Vendor Demonstrations The team hosted three, one-day demonstrations from SVRS solution
providers. The sessions consisted of demonstrating application functionality, discussing cost
estimates and discussing the implementation approach, plans and challenges.
Implementation Planning and Recommendations The team is summarizing the implementation
plans and recommendations in this report. The report will include study findings, study
recommendations and implementation plans
Our findings are organized in the following sections:
Statewide voter database
12
Voter registration statistics comparative complexity
Federal and state statutes
Policies and procedures
Integration with other SEB, county and municipal information systems
Integration with direct impact agencies
Package vs. custom SVRS solution
B. Statewide Voter Database

At the center of the system is the single, uniform, official, centralized, interactive computerized statewide
voter registration list. Municipalities and counties will not own or possess electronic data, but have
access rights defined by state statutes and implemented through the systems security functionality. The
database will be developed, implemented and owned by the Elections Board and hosted in state facilities.
Support and maintenance of the systems components will be defined through service level agreements
with the Elections Board, the Department of Administration, and the vendor.
While on the surface, the data model of a voter list may not seem sophisticated, the complexities of the
overall application architecture cannot be underestimated, and they translate into sophisticated
requirements and increased costs for the SVRS application software. Following are some examples:
The SVRS does not just include voters but the relationship between voters, municipal information
(which changes), and voting jurisdictions (which are periodically modified and redrawn).
The SVRS system must carry over time information at the voter master file level. While
transactional systems create records of an instance of an event at a specific point in time, the
SVRS must keep track of and be able to recreate a snapshot of the voter, municipal information,
and voting jurisdictions at any historical point in time.
The SVRS in many ways serves as a guardian of the voting franchise for 4.1 million voting age
Wisconsin citizens and as such requires an extremely high standard of accuracy. For example,
even 99% accuracy within the SVRS on voting day could result in the unacceptable outcome of
as many as 41,000 peoples right to vote being at risk. The software and process controls
required to operate at a much higher accuracy must be in place.
The software must include recovery and rollback features to recover from faults, and must also be
designed for an environment where many people (i.e., millions of voters) will need or want
access. Loss of systems or data at key periods in the voting cycle could have a significant impact
on the voting franchise.
Security and privacy must be protected, including protection from identify theft.
Periodic re-indexing of primary keys within the database will be required for such things as
redistricting, annexations, and other events related to municipal and voting boundaries.
If on-line usage were consolidated at the county level, there will be approximately 320 users. If no
consolidation occurs, there will be approximately 3,000 individual users of the system. In either
case, this requires a large scale technical architecture and application architecture. The software
will need to be run in a large, multi-server environment for both application servers and database
servers.
The user community will reflect a wide variety of computer and election management skill levels.
Software and process controls must be robust to maintain the accuracy of the list.
The list will contain more than just eligible voters. That is, in order to enhance the systems ability
to prevent and/or detect voter fraud, the list will still contain the names of persons who are
ineligible to vote (e.g., deceased voters and voters who have lost their civil rights). Thus, names
are not removed from the list. They are marked as ineligible to vote along with an appropriate
reason-code. The presence of ineligible voter names allows the system the opportunity to
determine whether someone else is attempting to vote using that voters identity. Theoretically, at
the extreme, the list could contain everyone who has been or is connected to the state, such as
13
new-born children, long-deceased great-great grandparents, etc. There is a practical limit related
to the storage of data. Once limits are placed on the content of the list, the state will need to
develop and adhere to statewide statutes, policies and procedures related to the lists
maintenance.
C. Voter Registration Statistics Comparative Complexity

Consider the following statistics defined during the SVRS study:
Wisconsin Voter Registration Structure. According to SVRS solution providers and other states
contemplating similar SVRS solutions, Wisconsins structure of decentralized voter registration at the
municipal level increases the challenges, risks and costs associated with implementation of SVRS
solutions that are HAVA compliant. Our study found that the number of municipalities requiring access to
the SVRS application was the single largest contributor to overall cost variation. Our research shows the
cost, complexity and risk associated with SVRS implementation is magnified significantly when using the
decentralized municipal registration approach. Consider the following information gathered during the RFI
process with several SVRS package vendors.
The current structure of managing registration requires municipalities to manage registration or to
contract with another municipality or county to complete the registration responsibilities. This structure
drives the following planning assumptions:
Approximately 1,850 municipalities will require access to SVRS
72 counties and 10 SEB personnel will also require access to SVRS
A general planning assumption of 1.5 users per location requires approximately 3,000 users who
will require access to SVRS
Hardware, network connectivity, software licensing, training, conversion and other services for
each municipality and county will be required to successfully implement SVRS.
Other States Experiences. The SVRS study focused on learning more about how other states voter
registration processes are structured. Consider the following:
Pennsylvania has approximately 7.8 million voters but manages registration at the county level.
Pennsylvania has only 67 county election offices with approximately 400 total users.
Connecticut has approximately 1.8 million voters. Connecticut does not have a county structure,
so elections are managed through its 169 municipalities. Connecticut has approximately 600 total
users.
Wisconsin has an estimated 4.1 million registered electors but must accommodate 1,850 site
connections and approximately 3,000 total users (for estimating purposes). A huge cost
differential on the order of 4x to 6x the cost of the Pennsylvania solution will result.
Michigans structure contained more than 1,500 municipalities where voter registration was
performed in the past. For cost reduction purposes, Michigan was able to restructure the
registration process to have counties provide the voter registration activity for all municipalities
with voting age populations of less than 5,000. This policy and structure change reduced the
complexity, risks and costs associated with the Michigan Qualified Voter File (QVF) initiative and
enabled a more cost effective solution for the state of Michigan. Michigan has approximately 6.7
million registered voters.
Cost Implications for Number of Users. The study revealed a wide range of costs based on the
complexity, risk and large number of locations/users within the current structure. Cost variations of as
much as $19.5 million were noted for one experienced SVRS solution provider based on the number of
locations and users required on the SVRS application.
The study determined that significant decisions on the fundamental structure for voter registration will be
required as the SEB progresses through the SVRS solution implementation process. Making these
decisions early in the process is necessary to provide a foundation for the vendor selection. That is, in
order for a vendor to give a best and final fixed-fee offer, they will need to know the number of locations/
14
users. If the number of locations/users is not firm and fixed in the RFP, then the integrity of the
procurement process will be jeopardized.
In addition, the sooner the state makes fundamental decisions relative to the critical implementation
drivers, the earlier the state can begin to organize and structure implementation activities around those
implementation activities.
Data Conversion and Document Scanning Costs. The study defined the following statistics and
challenges relative to converting data from existing voter registration municipalities:
Approximately 320 municipalities currently have some form of voter registration.

Design, development and implementation of 320 automated conversion routines will mean
significant cost and complexity.
There would be approximately 4.1 million registration documents to be scanned.
This cost can be managed through two strategies:
1) Define the number of automated conversions by setting a threshold of 5,000 records. That is,
any municipality with a current voter registration database containing fewer than 5,000
records will manually re-enter the voter registration records prior to system go-live. While
calculating the threshold number of records is a simple cost/benefit relationship, the state
must decide
a) Who will perform any manual data entry (vendor or the state), and
b) Who will bear the cost of data conversion (the state or the municipality).
2) Eliminate the conversion (i.e., scanning) of original registration documents.
Similar to making a decision on the number of users/locations, the study found that the state will need to
make its decisions related to data conversion and document scanning prior to the issuance of the RFP.
The reasons for making these decisions prior to issuing the RFP are the same as those stated for
determining the number of users/locations.
D. Federal and State Statutes

Section 303 of HAVA describes the federal requirements for statewide voter registration, which are
summarized as follows:
303
Requirement
a.1.A
The computerized list shall serve as the single system for storing and managing the official list of
registered voters throughout the State.
The computerized list contains the name and registration information of every legally registered
voter in the State.
Under the computerized list, a unique identifier is assigned to each legally registered voter in the
State.
The computerized list shall be coordinated with other agency databases within the State.
Any election official in the State, including any local election official, may obtain immediate
electronic access to the information contained in the computerized list.
All voter registration information obtained by any local election official in the State shall be
electronically entered into the computerized list on an expedited basis at the time the information
is provided to the local official.
The chief State election official shall provide such support as may be required so that local
election officials are able to enter information.
The computerized list shall serve as the official voter registration list for the conduct of all
elections for Federal office in the State.
If an individual is to be removed from the computerized list, such individual shall be removed in
accordance with the provisions of the National Voter Registration Act of 1993.
For purposes of removing names of ineligible voters from the official list of eligible voters the
a.2.A
15
303
a.2.B
a.3
a.4
a.5.A.i.
a.5.A.ii
a.5.A.ii
Requirement
State shall coordinate the computerized list with State agency records on felony status; and
For purposes of removing names of ineligible voters from the official list of eligible voters by
reason of death of the registrant the State shall coordinate the computerized list with State
agency records on death.
The list maintenance performed under subparagraph (A) shall be conducted in a manner that
ensures that
the name of each registered voter appears in the computerized list;
only voters who are not registered or who are not eligible to vote are removed from the
computerized list; and
duplicate names are eliminated from the computerized list.

The appropriate State or local official shall provide adequate technological security measures to
prevent the unauthorized access to the computerized list established under this section.
The State election system shall include provisions to ensure that voter registration records in the
State are accurate and are updated regularly, including the following:
A system of file maintenance that makes a reasonable effort to remove registrants who are
ineligible to vote from the official list of eligible voters. Under such system, registrants who
have not responded to a notice and who have not voted in two consecutive general elections
for Federal office shall be removed solely by reason of a failure to vote.
Safeguards to ensure that eligible voters are not removed in error from the official list of
eligible voters.
An application for voter registration for an election for Federal office may not be accepted or
processed by a State unless the application includes
in the case of an applicant who has been issued a current and valid drivers license, the
applicants drivers license number or
in the case of any other applicant (other than an applicant to whom clause (ii) applies), the
last 4 digits of the applicants social security number.
If an applicant for voter registration for an election for Federal office has not been issued a current
and valid drivers license or a social security number, the State shall assign the applicant a
number which will serve to identify the applicant for voter registration purposes. To the extent that
the State has a computerized list in effect under this subsection and the list assigns unique
identifying numbers to registrants, the number assigned under this clause shall be the unique
identifying number assigned under the list.
The State shall determine whether the information provided by an individual is sufficient to meet
the requirements of this subparagraph, in accordance with State law.
a.5.B.i
The chief State election official and the official responsible for the State motor vehicle authority of
a State shall enter into an agreement to match information in the database of the statewide voter
registration system with information in the database of the motor vehicle authority to the extent
required to enable each such official to verify the accuracy of the information provided on
applications for voter registration.
a.5.B.ii
The official responsible for the State motor vehicle authority shall enter into an agreement with the
Commissioner of Social Security.
State statutes concerning voter registration must be modified in several ways (see Appendix 1 for the
most recent version of proposed revisions to statutes).
The state will create and maintain the list. There will be one list. There will be one record per
elector. The record will include the persons drivers license number, and/or the last four digits of
the social security number, or an affirmation that the elector has neither.
Language related to municipalities responsibility for maintaining voter registration lists must be
modified.
There are two aspects of this. Principally, 6.27 must be repealed. The
16
recommendation is that 6.27 be modified to convey the intent that, with the exception of some
special populations (e.g., military voters and some new residents), all voters must be registered.
Furthermore, statutes are sprinkled with phrases like, where registration is required that must be
removed.
Language must be modified, especially related to deleting or canceling registrations. As was

discussed previously, records in the statewide database should not be deleted or cancelled
because of a recent event (e.g., death). Rather broader language dealing with archiving and
purging data at a system level must be developed. For example, statutes could provide that
records for electors who have been inactive or ineligible for over ten years may be purged and
archived with redistricting.
Statutes must define access rights and limits. The proposed statute provides that only three
entities may access a record for the purpose of adding or modifying the record: the Elections
Board, election officials in the Wisconsin municipality from which the elector is moving, and
election officials in the Wisconsin municipality to which the elector is moving.
The system would control write-access through its security functionality. The system would
provide the opportunity to investigate transactions through its audit functionality.
The statute could be modified so that any election official could modify any record, thus creating a
system of anywhere registration. It is recommended that this functionality be deferred until
enough time has passed and enough comfort has been established with the new system.
Current statutes do not require electronic, read-only access by individual voters. However,
electronic, read-only access (e.g., via the internet) by voters to their record (e.g., to determine
where they vote, or who their elected representatives are) is seen as an important function for the
value and acceptability of the system.
Current statutes and administrative policy do not describe provisions for the access, sale and/or
distribution of large extracts of the voter registration list. Currently, some municipalities charge for
copies of poll lists and walking lists, etc. Statewide policies and procedures would have to be
developed for this objective.
Statutes must define required communication/reporting. The proposed statute calls for notification
to the relevant municipality whenever the Elections Board adds or modifies a record. Also, when
a registered elector moves within the state, the former municipality may change the record and
notify the new municipality; or the new municipality may change the record and notify the former
municipality. Notification may be by e-mail or through the US Postal Service.
Reporting requirements (and supporting business processes) will change once the system is fully
operational. Statutes should be changed to reflect this. For example, 6.275 calls for
municipalities to create and submit reports to counties. Counties then submit these reports to the
SEB who then manually enters the data in order to prepare its results and analyses. Because the
data will be available in the system, this statute could be repealed and/or revised significantly,
because the county and the SEB could select the report from the systems menu.
E. Policies and Procedures

With the implementation of the SVRS, existing processes for voter registration will change to reflect the
change in technology, roles and responsibilities, and information access and visibility. In the existing
voter registration processes, each municipality works in its own system environment. Information
regarding electors is not visible to anyone outside of the municipality. Each municipality has its own
registration form and voter notification practices. All of this will change in the future due to the
functionality that accompanies a centralized, statewide voter registration system.
The major differences in the future state are as follows;
Registration of all eligible electors within the state (regardless of size of municipality)
Visibility to all electors within the state, across municipalities (single, centralized list)
Immediate access to a computerized list of electors
17
Computer generated, standardized notifications to electors and municipalities
Information exchanges with direct impact agencies for record updates (felonies, deaths, drivers
license number)
Standardized forms and processes across municipalities
Preventative measures to decrease potential for voter fraud / voter error
Better systems for detecting voter fraud / voter error
Integration/validation of drivers license information with the Division of Motor Vehicles
Integration/validation of felony information with the Department of Correction and Department of

Justice
Integration/validation of death information with the Department of Health and Family Services
There will need to be one set of carefully defined policies and procedures that are carried out throughout
the state by the municipalities (and counties). While some counties may provide assistance in processing
for their municipalities, uniform processes must be developed and adhered to in order to contribute to the
integrity of the database. These policies and procedures include
Adding electors
Modifying electors
Marking electors as ineligible
Purging records
Managing election day activities
Accommodating military voters
Processing absentee voter requests and votes
Accommodating overseas voters
Accommodating other special voting populations (e.g., college students)
Managing integration with direct impact agencies
Maintaining geographic data on streets, wards, and districts
Maintaining data on poll locations
Maintaining data on poll workers
If policies and procedures are not uniform, then significant risk to the integrity of the data in the database
is introduced. The consequence of weak integrity would be the opportunity for voter disenfranchisement
and voter fraud.
The study found that processes define business requirements for the RFP. The state will need to make
decisions related to future state processes prior to issuing the RFP so as to minimize implementation
costs that would be incurred through change orders.
F. Integration with other SEB, County and Municipal Information Systems

The SEB currently maintains two information systems (SWEBIS 1 and SWEBIS 2). SWEBIS 1 is a
system that manages campaign finance data. SWEBIS 2 manages registrants, ballots and ballot access,
and municipal information. Counties and municipalities that currently maintain voter registration systems
will often also use that system to manage poll locations and poll workers. The following is a summary of
the overlaps and handoffs between those systems and the proposed SVRS system.
SVRS and the SEBs Municipal Information Database. The SVRS and municipal information (a part of
SWEBIS 2) overlap on the topics of poll locations. Poll location data is fairly isolated from other aspects
18
of election administration kept within SWEBIS 2. Based on the research of the study, it appears that the
function of recording and tracking poll location data in SWEBIS 2 could be eliminated by the SVRS.
SVRS and County and Municipal Voter Registration Systems. Obviously, the SVRS would eliminate
the need for counties and municipalities to maintain voter registration systems. Voter registration, as
used here is a catch-all for voter registration, managing military voters, absentee voters, and so on.
Many local voter registration systems, especially the larger ones, are also used to record and track
information on poll locations and poll workers. Because statewide voter registration systems evolved from
county and municipal systems, the SVRS systems that were studied included modules for managing poll
locations and poll workers. Thus, in addition to voter registration, local systems for managing poll
locations and poll workers could be eliminated by the SVRS.
Larger municipal voter registration systems also maintain geographic information related to wards and
addresses. Poll lists have to communicate the ward in which a resident may vote. Some systems
integrate sophisticated mapping systems. These systems could be eliminated by the SVRS.
Furthermore, the study found that many individual voters would access the SVRS in order to learn which
offices are pertinent to their residence. On-line access functionality is critical to creating buy-in from
electors. Additionally, the study found that local election offices receive hundreds and thousands of calls
from electors for this information. Thus, the presence of on-line access to poll location information would
create savings at the county and municipal level.
SVRS and the SEBs Election Administration System. The SVRS system would overlap SWEBIS 2 in
terms of geography, offices, and incumbents and candidates.
SWEBIS 2 maintains data on geography at the ward level, only. For example, in SWEBIS 2, the system
only records the fact that the city of Whitewater is comprised of wards 1 through 6. In the SVRS system,
geographic data must be kept at the street and street number level. That is, the SVRS would connect
1234 West Main Street, Apt #4 to ward 1. Thus, the SVRS would be able to accommodate the SEBs
current definition of geography.
However, in SWEBIS 2, geography is connected to an office which is connected to an incumbent and
connected to candidates. There are many other data elements that are needed to completely manage the
concept of an office (e.g., terms of office). Thus, the SVRS system could not replace this function of
SWEBIS 2 (without significant modification).
The SVRS system would also overlap SWEBIS 2 in terms of incumbents and candidates. Incumbents
and candidates are almost always registered voters, thus name and address data would exist in both
systems. However, candidates are only one type of registrant within SWEBIS 2. Others registrants
include parties, PACs and conduits. Also, there are many more data elements that are needed to
completely manage candidates (e.g., campaign committee data). Thus, the SVRS system could not
replace this function of SWEBIS 2 (without significant modification).
SVRS and Campaign Finance Information. Campaign finance information is currently maintained by
SWEBIS 1. SWEBIS 1 is not electronically linked to SWEBIS 2. Thus, there is redundant processing of
some registrant data. SVRS systems would not be able to replace any aspect of campaign finance
recording and tracking.
SVRS and Voting. There is no overlap between SVRS and voting at this time. The current handoff
between the two systems is the ballot. The ballot is created by the county and municipality with support
from the SEB and the Election Administration system. Voters receive specific ballots based on the
location of their residence (within a municipality).
Ballot creation, and the recording and tallying of votes are not modules within an SVRS system.
19
However, there is a future scenario where a direct connection between the SVRS and the voting system
is possible. Connecting ballot creation and the recording and tallying of votes would allow for anywherevoting. That is, the system could be connected so that a voter could use voting equipment at a
Wisconsin polling place that is electronically connected to the voter database and the ballot creation
system. Then, the voter could sign in on the voting equipment which would then pull up the appropriate
ballot. Thus, a voter could vote at any location that was connected to the SVRS. Furthermore, this
scenario is not far behind the concept of internet voting; that is, the voter signing into the voting system
via the internet and then receiving and casting their ballot. Most likely, the technology for this future state
will exist long before statutes enable it.
As the state Elections Board pursues the selection and implementation of its SVRS, it should work to
ensure that the solution does not preclude it from the flexibility of considering anywhere-voting and
Internet voting.
G. Integration with Direct Impact Agencies

HAVA calls for agreements between the SEB and the DMV. It calls on the SEB to also use data on
deaths and felony/civil rights status from other direct impact agencies (e.g., DHFS and DOJ). The
agreements must specify the following:
The specific elements of data requested (e.g., name, address, drivers license number),
The format of the data,
The frequency of data requests, and
The cost for data.
In addition, the following issues must be addressed:
Programs must be written to match the extracted data to the statewide voter database.
Policies and procedures would be developed for dealing with
Records that match 100%,

Records that partially match, and
Records that do not match at all.
Name matching and validation issues are very complex (e.g., matching Margie L. Smith with Margaret
Smith), and are made even more complex when aliases and name changes are considered. The timing
and error correction routines of the interfaces to other state agencies is extremely important. Even a 1%
error rate on an interface validating names, driver license numbers, etc. could generate tens of thousands
of bad matches in an error log, well beyond any ability for the users to manually verify the errors. Again,
a high degree of accuracy is imperative prior to the modification of voter records.
One vendor proposed (and has implemented) an option where records that match 100% be pushed
automatically into the statewide voter registration database. Two others suggested, based on their
experiences, that records that match 100% be distributed to appropriate municipalities for their approval
prior to updating the statewide voter database. This second scenario appears to be more aligned with
Wisconsins philosophy related to electors and voters. All vendors suggested that incomplete or
unmatched records be ignored, because the time to resolve, cost to resolve, and potential for error and
disenfranchisement was too high.
H. Package vs. Custom SVRS Solution

The RFI responses led the study team to focus on vendors who have knowledge and experience with
statewide voter registration systems. The objective was to leverage that knowledge and expertise in order
to be in a position to create a viable procurement process, including preparing the state for the financial
20
impact of this project. If the findings of this study included a conclusion that the states requirements were
very unique, then it would be more likely that a custom solution could be a viable option.
In order to prepare an RFP to which custom developers could provide a credible (i.e., fiscally responsible)
reply, the state would need to expend a significant amount of up-front investment (see Project Charter,
section G). Because, in addition to specifying business requirements (as this study did through the RFI),
a custom development RFP would need to identify and develop detailed design and functional
specifications required by the application. The RFP would need to provide screen layouts, report
designs, and many other system elements.
The study found that the requirements of Wisconsins SVRS are not very unique. That is, vendors with
existing SVRS solutions bring knowledge, expertise, and additional functionality. Thus, selection of a
custom application does not appear to be warranted.
21
SVRS Project Charter

A. Goal
The aim of this project is to select, implement and maintain a statewide voter registration system (SVRS).
This system has been defined by the Help America Vote Act of 2002 (HAVA) as a single, uniform, official,
centralized, interactive computerized statewide voter registration list defined, maintained, and
administered at the State level that contains the name and registration information of every legally
registered voter in the State and assigns a unique identifier to each legally registered voter in the State.
B. Objectives
The objectives of this system are:
1.
To achieve compliance with HAVA and revised state statutes.
2.
To promote an active interest in good government and civic affairs by aiding and
encouraging maximum participation in the election process by all eligible voters in the state,
and
3.
To strengthen the integrity of the voting process in Wisconsin, and
4.
To develop and maintain consistency in the application of election administration.
In order to maintain and administer such a system, HAVA calls on the State Elections Board to work with
other state agencies:
1.
The Division of Motor Vehicles (DMV) for address change information,
2.
The Department of Health and Family Services (DHFS) for information on the death of
voters.
3.
The Department of Corrections (DOC) Department of Justice (DOJ) for information on the
status of convicted felons civil rights.
C. Scope
The high-level functions of the state Elections Board and local municipalities are depicted in Figure 2, on
the following page, showing the in-scope and out-of-scope components for the SVRS implementation.
22
Figure 2. State Elections Board Functions
23
The functions of the SVRS overlap other systems. The following is a summary of the systems within the
elections process and whether they are in or out of scope for the SVRS system.
In/Out of
Scope
In
Owner
State Elections Board
Municipal
Information
In
Election
Administration
Out
Campaign
Finance
Out
Voting
Out
Municipalities and
counties
System
SVRS
Functions
A single, uniform, official, centralized,
interactive computerized statewide voter
registration list.
Processing additions and modifications to
voter records.
Accommodating military electors, absentee
voters, overseas electors, and electors
covered by protective orders.
Integrating data from other impacted agencies
(DMV, DHFS, DOC/DOJ/CCAP).
Maintenance of geographic boundaries of
various electoral districts.
Report generation (e.g., poll lists, election
statistics, etc.).
Creating election statistics related to the
number and type (e.g., absentee) of voters
Maintenance of geographic boundaries of
various electoral districts and reporting units.
Maintaining data on municipal clerks.
Maintaining data on municipalities as it relates
to poll locations (including accessibility) and
poll workers,
Maintaining registrant files.
Administering ballot access by candidates and
political parties.
Receiving and filing campaign finance
information from registrants.
Auditing campaign finance information for
statutory compliance.
Reporting on campaign finance data.
Ballot creation.
Administering elections.
Managing voting equipment.
Submitting election results to the SEB for
canvassing.
D. Assumptions
Hardware, Software and On-going Maintenance. Because of the size of the SEBs staff, it is currently
assumed that hardware and software will be housed and maintained by the states Department of
Administration (DOA) in cooperation with the SVRS vendor through specific service level agreements
(SLAs).
Integration with other Impacted State Agencies. From an administrative level, the state will need to
define the rules for integration with other agencies (i.e., DMV, et al). These rules will have four elements:
1.
How will entries in the statewide voter database be physically updated when data is
received by the State Elections Board from other agencies and the data from the other
agency completely matches data in the statewide voter database?
24
2.
agency partially matches data in the statewide voter database?
3.
agency does not match any data in the statewide voter database?
4.
Will data from each of the other agencies be treated the same? For example, will a
complete match from DMV be processed the same as a complete match from DOC?
See Appendix 3 for estimates from the direct impact agencies.
General Estimating Assumptions. The following statistics were generated for the November 2002
election from form EB-190:
2000
Census
Population
Number
of Munis
< 5,000
1,719
5,000
171
1,890
Election
Date
11/5/2002
11/7/2000
11/3/1998
11/5/1996
11/8/1994
11/3/1992
11/6/1990
11/8/1988
11/6/1984
Estimated
Number of
Electors
Number of
Registrants
Number of
Voters
(Nov 2002)
91.0
1,436,549
32.4
192,492
682,990
35.4
9.0
2,999,528
67.6
2,470,377
1,244,071
64.6
100.0
100.0
2,662,869
1,927,061
100.0
Munis
Reporting
1,850
1,903
1,886
1,888
1,640
1,527
1,819
1,618
1,666
4,436,077
Voters
1,927,061
2,619,184
1,799,758
2,252,301
1,445,935
1,871,379
1,365,203
2,043,218
1,879,619
Absentee
Electors
#
%
113,853
5.91
160,425
6.12
73,517
4.08
104,607
4.64
64,308
4.45
93,357
4.99
40,853
2.99
82,360
4.03
Not Reported
Late
Registrations
#
%
5,476
.21
32,014
1.22
7,896
.44
16,024
.71
3,370
.23
37,715
2.02
9,137
.67
19,800
.97
21,814
1.16
Election Day
Registrations
#
%
134,348
6.97
411,656
15.72
170,479
9.47
260,815
11.58
101,770
7.04
301,154
16.09
100,383
7.35
242,542
11.87
190,937
10.16
Notes:
1) The number of municipalities (1,850) exceeds the actual number of municipalities because some
municipalities borders cross county lines. Data on small municipalities is slightly overstated, because
some large municipalities (population >5,000); e.g., Milwaukee, have a small ward (<5,000) in
another county. That small ward would be included in this example.
2) Because there is no ability to check for duplicate records across municipality boundaries, we know
that this number includes duplicates from the point of view of a state-wide list. We do not know the
degree of overstatement.
State Statutes. A significant assumption is that through statute or administrative rule, the Elections
Board will be able to define business rules for the design and maintenance of the database. Statewide
voter registration mostly affects Chapter 6 of state statutes. The more significant proposed changes to
state statutes related specifically to this issue are
Sections 5.05 and 6.36: The board shall be responsible for the design and maintenance of the
official registration list. The board shall require all municipalities to use the list in every election
25
and may require any municipality to adhere to procedures established by the board for proper
maintenance of the list.
Section 6.27: Each elector shall register under this chapter before voting in any election, with
exceptions for military voters, certain new residents, and certain former residents.
Resources. The charter organizes subsequent work into four phases. Each of those phases calls for
significant commitments of people from various agencies (depending on the phase). Clearly, there is
always a need for resources from the SEB. In addition, there are needs for resources from the counties
and municipalities, from DOA, and from direct impact agencies. Furthermore, especially during the
implementation, there is a need for particular expertise within those resources.
The ability to complete the phases on schedule assumes that people will be assigned to the project on a
timely basis. Furthermore, for each of the phases, we have attempted to estimate costs to external parties
(e.g., outside consultants). There is a critical assumption that the SEB will be able to provide the
appropriate number of people with the appropriate skill sets to the phases. In the absence of numbers
and skills, additional external costs would be incurred.
E. Risks and Mitigation Strategy

Risk Element
Resources
Risk
This project will require significant
investments in hardware, software and
support, including personnel for
significant periods of time.
Project Sponsorship
Project sponsorship involves financial

resources and non-financial
commitment.
Project Sponsorship
A lack of buy-in on the part of

municipalities, counties, or legislators
increases risks to data completeness
and integrity.
26
Mitigation Strategy
The Federal Government has
allocated funds but has not made a
commitment to provide some on-going
funding.
Continue to focus on the five year,
total cost of ownership in evaluating
vendor responses and budgetary
planning.
Consolidating the number of users and
sites can lower the cost of the system.
From a financial perspective, the
Federal government has pledged
initial funding which may be used for
this project. Continuing to focus on the
five year total cost of ownership will
keep the state prepared over the
longer term.
From a buy-in perspective, we have
learned that continued involvement by
counties and municipalities beginning
at the start of the project is a key
success factor. The involvement that
existed in the RFI study was greatly
appreciated by all who participated.
Local officials know that this will be
their world shortly, and are excited by
the prospect of participating and
shaping its future.
Risk Element
Expectations
Risk
The likely initial discomfort from
implementing a new system will be
underestimated. The discomfort will
lead to widespread resistance.
Planning
Initial planning will be minimized

because it appears to be a cost-saving
tactic.
Timeframe
An unrealistic timeframe (i.e., too

short) will place undo strain on all
resources.
Vendor Availability
At this time, approximately 35 states

do not have a HAVA-compliant voter
registration system. There are only a
handful of vendors with statewide
voter registration systems experience.
27
Mitigation Strategy
Only those people who have been
involved in a system conversion know
the challenges involved. On-going
communication and effective training
will mitigate some of this risk. A
phased implementation and roll-out
will mitigate some of this risk. Lastly,
developing user groups will mitigate
some of this risk.
In our experience, the absence of
sufficient planning is the principle
source of project failure. The pre-RFP
planning and study will save the state
(and vendors) multiples of time and
dollars in the RFP phase. Preimplementation planning and
discussions with the vendor will save
the state (and vendors) multiples of
time and dollars. All of the tasks listed
in the pre-RFP planning and study
phase, all of the tasks listed in the preimplementation phase have to be
done. Putting them off only increases
their cost.
At this time, the board plans to request
an extension from the January 1, 2004
deadline. This means that the new
deadline would be January 1, 2006. A
realistic timeframe, assuming that the
RFP is authorized in the latter portion
of 2003 is for a complete
implementation and roll-out by
January 1, 2005. This will give the
state, counties, and municipalities the
opportunity to plan implementation
and accommodate the 2004 election
schedule. At the same time, it is not
too slow of a timeframe that the
project incurs excessive additional
costs and/or loses momentum.
From discussions with vendors, we
understand that Wisconsin is currently
ahead of the pack in terms of studying
and defining its requirements and
discussing its needs with vendors.
Because many states are looking to
develop such a system, it is important
for Wisconsin to maintain its
momentum so that it can be in a
position to engage the best team from
the vendor selected.
Risk Element
Schedule
Risk
There are four elections scheduled in
2004 already, including the general
presidential election in November.
Additionally, municipalities must
conduct other special elections as
well. Thus, roll out must be sensitive
to these schedules.
Scope
Because election systems are

integrated and overlap, there is a risk
that the scope of the project could
expand and additional costs be
incurred.
Future mandates may warrant
integration with other aspects of the
election system (e.g., voting systems
and election results tabulation). The
risk is that the selection of an SVRS
partner will limit future options.
Scope
Technical
The SVRS is more than just a

software selection and implementation
project. It is a highly complex system
integrated with other state agencies,
used by hundreds to thousands of
clerks, and accessed by millions of
electors.
Future Strategy
There is a risk that the system will not

be able to accommodate future state
mandates related to voter registration;
for example, anywhere registration,
anywhere voting or voter registration
data being encoded in the magnetic
stripe on drivers licenses.
28
Mitigation Strategy
If legislative approval for the RFP is
granted by the end of 2003, then there
would be some possibility to roll out
the solution to a small set of
municipalities for some of the 2004
elections.
A phased roll-out would allow for the
most flexibility in order to minimize
conflict with special elections and
implementation. During planning, the
state and vendor would need to
coordinate the implementation
schedule with these other events.
During implementation planning, the
scope of the project should be clearly
defined. Both in-scope and known outof-scope elements must be articulated.
During the RFP process, some
preference should be given to vendors
who, in addition to having statewide
voter registration system experience,
have experience in other aspects of
election administration. Similarly,
some preference should be given to
proposals with an open architecture
that would give the state the most
flexibility in terms of choices for adding
other election administration
functionalities.
In the RFP process, preference should
be given to vendors who have
successfully implemented a statewide
voter registration system. There is an
opportunity to leverage expertise and
experience from good and painful
lessons learned. The importance of
planning cannot be emphasized
enough.
In the RFP process, preference should
be given to vendors who have
statewide voter registration system
experience, a vision (based on
experience) for the future of voter
registration, resource to address that
vision, and a solution that has an open
architecture to accommodate future
enhancements.
F. Future System Processes

Future Process Flows. Detailed future state processes have been documented in process flows which
can be found in Appendix 2. The flows layout the high-level vision of the SEB for the future of voter
registration, assuming the current understanding of revisions to state statutes. The high-level processes
were grouped into the following categories;
Regular, In-Person Registration
Late, In-Person Registration
Late, In-Person Registration, Residency <10 Days
Regular, Mail-In Registration
Late, Mail-In Registration
Election Day Registration (No Technology On-site)
Election Day Registration (Med Technology On-site)
Election Day Registration, Residency <10 Days
Returned EB-180 Postcard Verification
Detailed, conceptual design flows will be created after statutes are finalized and after the vendor has
been selected.
Technical Architecture. A high-level depiction of the SVRS technical architecture is:
Figure 3. High-Level SVRS Technical Architecture.
29
G. Statewide Voter Registration System (SVRS) Plan

The SVRS plan below illustrates the sequence of initiatives required to successfully design, develop,
implement and maintain the SVRS application.
0. SVRS
Study
& RFI
Complete
1. Define Local
Operating Model and
Pre-RFP Planning
1-3 Months
5-15 Months
- Municipality Process
Consolidation
- Conversion Planning
- Local Operating Models
- Custom Development Due
Diligence (Optional)
- Finalize State Statute
Changes
2. SVRS Vendor
Selection
3. SVRS
Implementation
9-22 Months
- Project Planning and Scoping Refine Requirements

- Business Requirements and Identify Vendors
Gap Analysis
Vendor RFP & Eval
- Conversion Design and
Vendor Demonstration
Vendor Demonstration Mgmt Planning
- Implementation Planning
- Technical Design and
Configuration
- Testing Preparation
- Procedures and Training
- Conversion Preparation
- Development and Coding
- System Test
- Conversion
4. SVRS
Maintenance and
Support
On Going
Application Support
Hardware Support
Networking Support
Help Desk Support
Infrastructure Maintenance
Training
Phase 1. Define Local Operating Model and Pre-RFP Planning. Our strong recommendation is to
proceed with step one through step three (below). We consider step four an optional step to be
completed only if the State Elections Board is interested in pursuing custom development solutions to
meet SVRS solution requirements.
Step 1. Define the number of locations/users with full access to SVRS
Step 2. Develop conversion plan
Step 3. Define local operating models
Step 4. Determine requirements for custom development RFP (optional).
Step 1. Define the number of locations/users with full access to SVRS A reduction in the number
locations and users could occur via the consolidation of certain registration responsibilities from smaller
municipalities to larger municipalities or counties.
When the cost of local workstations and connectivity to the central SVRS are factored in, the number of
users and locations significantly affects the total cost of ownership to the state. However, because many
municipalities already have workstation and network resources, the impact on marginal cost is
significantly reduced. Certain SVRS vendor solutions were significantly affected by the number of users
and locations. As was discussed in the findings section, full access to the SVRS would translate to
approximately 2,000 locations and 3,000 individual users. Some package solutions are not financially
viable at this volume. Thus, in order to increase the number of SVRS options, reducing these numbers
would be necessary.
In addition to reducing the total cost of the project by reducing the total cost of hardware, software and
connectivity, reducing the number of users and locations (regardless of method) has the following
benefits
Increases efficiencies across the state,
Reduces the number of participants within the voter registration process reducing the possibility
of process breakdowns,
Increases the ability to standardize, and
30
Reduces the number of users requiring training.
The following options/alternatives exist to systematically define the number of locations and users:
Option 1: Full access to the SVRS by all municipalities - voluntary consolidation via memos of
understanding This alternative acknowledges that some municipalities may not have the
resources or desire to perform some aspects of processing data in the new SVRS. Those
municipalities would choose a processing partner (i.e., another municipality or the county) on a
case-by-case basis.
Activities
Define initial consolidation opportunities
Develop SVRS overview presentation roles/responsibilities
Prepare for county consolidation focus groups
(intent is to get input on consolidation approach)
Conduct consolidation focus groups
Prepare follow-up materials to consolidation focus
groups
Prepare for consolidation working sessions (intent
is to facilitate design/development of consolidation
parameters)
Conduct consolidation working sessions
Develop county by county consolidation approach
Draft
Develop "opt in" and "opt out" Document
approving the consolidation approach
Facilitate signing of memo of understanding
county and municipality
Deliverables
Municipality and county consolidation
matrix
SVRS overview presentation
Municipal and county consolidation focus
group materials
Municipal and county focus group
feedback and input
Follow-up materials
Municipal and county consolidation
working sessions
Initial consolidation parameters
Consolidation memo of understanding
draft contract
Opt in / opt out document
Signed memo of understanding
Advantages:
Consolidation of municipalities reduces the overall cost, complexity and risk of the SVRS
implementation.
This option presents a voluntary approach which preserves local decision making. There
would be no forced consolidation.
Disadvantages:
The voluntary option requires both the municipality and the county to agree on the
consolidation terms, which will require significant effort.
This option proposes a fundamental structure change relative to the roles and
responsibilities of the current voter registration process. It removes the element of local
ownership contained within the current structure, which may not be politically welcome.
The consolidation activity requires the definition of revised resource requirements at the
municipal and county level to process the registration transactions.
Cost and Timeframe:
The cost to facilitate development of official agreements across approximately 1,850
municipalities and 72 counties will not be an easy or low cost activity. Our estimating
assumptions include:
Approximately 1,850 municipalities
72 Counties
31
Approximately 26 municipalities per county (1,850/72)
Approximately 80 hours per county to define and gain agreements with municipalities for
the consolidation effort
Estimating Assumptions
Driver
#
Counties
Qty
Hrs /
Driver
Qty
Total
Hrs
# of
FTE
Hrs /
FTE
Weeks
High Cost
Range
Low Cost
Range
72
80
5,760
1,152
30
1 WI
4 External
3 WI
2 External
Projected Cost Estimate
500K
250K
Option 2: Legislative and Statutory Consolidation This alternative acknowledges that

consolidation will occur for the SVRS. The statutory process would require consolidation of voter
registration processes at the county level for those municipalities that have populations less than
5,000. The major focus for this phase is defining the revised resource requirements within the
municipalities and counties given assumptions that consolidation of registration responsibilities to
the county level will occur.
Activities
Draft enabling legislation providing the State
Elections Board the authority to force municipal
consolidation at the county level for municipalities
with a voting age population less than 5,000.
Develop SVRS Consolidation assessment
materials
Conduct SVRS consolidation assessment
sessions with municipalities and counties
Revise and finalize draft registration
Deliverables
Draft consolidation legislation
SVRS consolidation assessment materials

Municipality and county impacts of legislative
consolidation including:
Revised roles and responsibilities
Resources required to execute at the
municipal and county level
Issues and barriers to draft legislation
Enabling legislation
Advantages:
This option uses statutory authority to address the largest factor for the SVRS
implementation; consolidation. Statutory authority to consolidate voter registration
responsibility from municipalities to counties for municipalities with a population of fewer
than 5,000 will significantly reduce the total cost, complexity and risk associated with the
implementation of SVRS.
Disadvantages:
This option proposes a fundamental structure change relative to the roles and
responsibilities of the current voter registration process. Removes the current element of
ownership at a local level for the voter registration process.
Forced consolidation will run counter to local decision making and may be viewed
negatively by the municipalities and counties.
The consolidation activity requires the definition of revised resource requirements at the
municipal and county level to process the registration transactions..
32
Increased burden on the county may be considered an unfunded mandate in times of

very tight budgets and very tight resources.
There would be a need to clearly define the processes that would be supported (such as
poll book distribution from county to municipality) and the amount of time required to
support processes required to support the consolidation model.
If the consolidation legislation includes processing fees at the county level, the
municipalities may view the consolidation as an unfunded mandate.
Cost and Timeframe:

The cost and timeframe to facilitate legislative and/or statutory consolidation is significantly
less but would require some incremental investment from Wisconsin. Our estimating
assumptions include:
Approximately 1,850 municipalities
72 Counties
Approximately 26 municipalities per county (1,850/72).
Approximately 20 hours per county to define changes in staffing and resources required
to process registration.
NOTE: Initial estimates indicate approximately 20-30 registration transactions can be

processed per hour.
Driver
#
Counties
Qty
Hrs /
Driver
Qty
Total
Hrs
# of
FTE
Hrs /
FTE
Weeks
High Cost
Range
Low Cost
Range
72
20
1,440
288
1 WI
4 External
3 WI
2 External
200K
75K
Step 2. Develop Conversion Plan The focus of this phase would be to define the number of automated
conversions required from each existing municipality that currently contains a voter registration
application/database and to decide whether original registration documents will be scanned as a part of
conversion and whether document scanning would be a part of the final solution.
Conversion and Migration Planning Approach This activity will define a high-level conversion
and migration plan for each of the 320 municipalities with voter registration databases today. The
approach consists of working with each municipality to determine the following statistics:
Number of records requiring conversion define a manual or automated approach based on

pre-established conversion record thresholds. Manual data entry approaches does not imply
the municipality or the county must provide the data entry service. Initial manual vs.
automated thresholds consist of somewhere between one thousand and four thousand
records. If the municipality or county is less than the threshold, data entry clerks would be
used to enter the data manually as a more cost effective solution than automated
conversions.
Unique database or duplicate database assess the database architecture and define if the
current municipal or county database is unique or is a duplicate data architecture found in
other municipalities and counties throughout Wisconsin. Duplicate database architectures will
reduce the effort required to design, develop and implement automated conversions.
Data standards assessment assess the degree of effort required to standardize data
definitions across all existing voter registration databases.
33
Document Scanning Planning Approach This activity will define the policy related to the
scanning of registration documents.
Activities
Prepare templates and forms for
documentation of existing voter registration
applications and the overall data migration
approach.
Identify, assess and document current voter
registration applications/databases.
Create the application migration map including:
Application migration sequence - phased,
parallel, big bang
Include pre-requisites
Alternatives available for conversion of
data including
1) automated conversion
2) manual conversion - data entry
3) process workarounds
Costs/benefits of each alternative
Recommendation on approach
Identify, assess and document the policy
related to document scanning
Deliverables
Current voter registration application/database
documentation templates and data migration
approach documents.
Documented current applications and databases.
Application migration map
Cost and Timeframe:

The development of data conversion and migration plans for each of the existing
municipalities with voter registration is an essential component of cost reduction and
procurement planning efforts. Our estimating assumptions include:
Approximately 110 municipalities with voter registration systems containing more than
5,000 registration records. These municipalities are assumed to require an automated
conversion approach.
Approximately 210 municipalities with voter registration systems containing fewer than
5,000 registration records will require a manual conversion approach (data entry).
Driver
Munis w/
Large Voter
Reg Files
Munis w/
Small Voter
Reg Files
Qty
Hrs /
Driver
Qty
Total
Hrs
# of
FTE
Hrs /
FTE
Weeks
High Cost
Range
Low Cost
Range
110
24
2,640
294
5 WI
4 External
7 WI
2 External
210
840
91
5 WI
4 External
7 WI
2 External
280K
150K
Step 3. Local Operating Model This phase is focused on defining the future local operating model for
voter registration and related processes. An essential component of the local operating model will include
a standards committee to assist with defining standards during design, development, implementation and
maintenance/support phases for the SVRS application. Overall, this step focuses on defining the roles
and responsibilities for municipalities and counties within the voter registration process.
34
This activity is focused on establishing standardization across the municipalities and counties relative to
business processes. For example, the standards committee would be charged with defining the standard
set of poll lists, walking lists, SVRS reporting requirements. A SVRS standards group will be organized
and considered the governing authority on design and requirement decisions (including disagreement
resolution). The standards committee will assist in defining the local operating model definition.
Activities
Define the roles/responsibilities, objectives,
scope deliverables for the standards committee
Identify the standards committee members
Define the future operating model including
standardized processes/procedures and tools/
templates required to process voter registration.
Regular, in-person registration
Late, in-person registration
Regular, mail-in registration
Late, mail-in registration
Election day registration
Military voters
Absentee voters
Overseas voters
Managing poll locations
Managing poll workers
Maintaining district geographic data
Deliverables
Standards committee charter including
roles/responsibilities, objectives, scope and
expected deliverables from the committee.
Standards committee members
Future operating models
Cost and Timeframe:

The development of local operating models including defining and implementing a standards
committee is a critical success factor for the SVRS implementation. Costs and estimating
assumptions to build the local operating models include:
Approximately 19 critical processes requiring standard operating procedures and policies.
Approximately 80 hours of effort to design and approve the standard operating
procedures per process.
Driver
# Processes
Qty
Hrs /
Driver
Qty
Total
Hrs
# of
FTE
Hrs /
FTE
Weeks
High Cost
Range
Low Cost
Range
19
80
1520
304
3 WI
2 External
All WI
125K
Step 4. Custom Development Due Diligence (OPTIONAL)

The approach we recommend for custom development due diligence is to complete a custom
development discovery study.
Activities
Convert current business systems requirement
inventory into custom development conceptual
design and WBS (work breakdown structure).
35
Deliverables
Custom development conceptual design
Reports, screens, application flow,
application logic
Activities
Identify custom development vendors
Custom development RFI
RFI response analysis
Implementation planning and revised cost
estimates
Develop the study report
Deliverables
Vendor universe
Custom development RFI
Custom development vendor presentations
Cost estimates and implementation planning
estimates
Custom development study report
Advantages:
Provides Wisconsin with an alternative solution to consider for HAVA compliance.
Enables Wisconsin to design custom and unique functionality into the SVRS solution.
Addresses the custom development advocates.
Allows Wisconsin to make a decision on package vs. custom development based on

analysis and facts.
Disadvantages:
Custom solutions may not have the features and functionality associated with proven
industry standard SVRS packages.
Custom solution providers do not contain the collective elections industry experience and
expertise that SVRS package vendors will bring to this initiative.
Significant cost, complexity and timeframe risk is added when introducing SVRS
solutions which have not been fully developed, tested and implemented.
The majority of the SVRS package solution costs are not associated with the software
and these costs would also be incurred with custom solutions (i.e. implementation
services, training, conversion and hardware).
The nature of custom development procurements will require a significant up-front

investment in design specifications.
Design specifications for reports, screens,
application flow, application logic would all be required to ensure vendors are submitting
responsible bids during the procurement process.
Maintenance and support of custom developed applications requires significant

resources for post go-live modifications, enhancements and bug fixes.
Additional risk may be added when dealing with custom developed applications relative
to support, maintenance and upgradeability compared to SVRS packaged vendors with
proven history and track records.
Cost and Timeframe:

The custom development discovery study contains the following cost and estimating
assumptions:
Existing SVRS RFI requirements will require conversion into a custom development
conceptual design including a WBS (Work Breakdown Structure) for the inventory of
custom development work units.
Approximately 3 hours per requirement will be necessary to convert the existing
requirements into custom development conceptual design and custom development WBS
(e.g. report specifications, screen specifications, application flow, application
functionality).
36
Driver
Qty
Hrs /
Driver
Qty
# of requirements
333
999
250
2 WI
2 External
All WI
Report specs
75
16
1,200
300
1 WI
3 External
All WI
Screen specs
32
40
1,280
320
1 WI
3 External
All WI
Application logic
80
80
80
0 WI
1 External
All WI
Integration logic
16
48
48
0 WI
1 External
All WI
600K
Total
Hrs
# of
FTE
Hrs /
FTE
Weeks
High Cost
Range
Low Cost
Range
Summary. The local operating model and pre-RFP planning initiative is necessary as a critical
component of the overall SVRS implementation initiative. Steps one through three must be completed
prior to conducting the RFP and vendor selection. Benefits of completing these activities prior to the
vendor selection include:
Provides SEB with increased leverage during contract negotiations with the vendor.
Provides you with the answers required to complete a comprehensive RFP.
Gives the vendors the information required to provide fixed fee or narrow cost range estimates.
Allows you to proactively address the largest cost drivers associated with implementing SVRS
solutions and enables you to effectively lower the cost of HAVA compliance.
Enables you to develop standards across municipalities and counties via standard operating
models and a standards committee to help develop and enforce standards.
Reduces the risk of moving forward without answering foundational implementation decisions.
Provides a solid starting point for the overall implementation.
Phase 2. Statewide Voter Registration System Vendor Selection

The SVRS vendor selection will consist of a formal RFP process that will focus on identification of the
leading SVRS vendors and a rigorous vendor screening process. Vendor selection activities are first
focused on finalizing the SVRS functional, technical, and implementation requirements, and then
requiring the vendors to perform scripted demonstrations using SEB business scenarios. This allows the
SEB and DEG to select the best vendor solution based not only on the vendors ability to satisfy the
system functionality requirements, but more importantly, also on their ability to satisfy the specific
implementation requirements and business objectives of the Wisconsin SVRS solution. A critical success
factor coming from the RFP process will be a detailed understanding of any gaps associated with
Wisconsins requirements including proposed workarounds or modifications.
The following approach is recommended for the procurement and RFP process. We recommend a
structured vendor selection and RFP process. The following phases have been defined to assist
Wisconsin through the vendor selection and RFP initiative for SVRS solutions;
37
Step 1. Requirements Definition The focus of this phase is to review those requirements defined during
the SVRS RFI project to refine / add to these for the RFP. In addition, many critical implementation
planning decisions (e.g. number of locations, number of users, and number of automated conversions)
can be introduced into the general RFP requirements allowing vendors to provide responses that are
fixed fee or with very narrow price ranges.
Activities
Review HAVA Act and confirm that all mandates
are accounted for in the states requirements
Review state statutes and confirm that all

applicable statutes are accounted for in the
states requirements
Review new enabling legislation and confirm that
the existing requirements cover all additional
legislation
Review existing RFI SVRS requirements
(functional and technical) and adjust these
requirements as needed
Refine/add to SVRS RFI requirements for the
RFP
Prioritize the new list of requirements
Obtain project team consensus on requirements
and their priorities
Define RFP planning assumptions to
supplement the initial list of requirements
Deliverables
Vendor RFP system requirements and planning
assumptions
SVRS prioritized requirements document
Vendor RFP planning pssumptions
Step 2. Identify Vendors The focus of this phase is to identify those vendors in the market who offer
SVRS solutions that would meet the requirements of the Wisconsin SVRS initiative.
Activities
Review compiled list of vendors from the RFI
initiative
Gather additional information on known vendors
(as necessary)
Deliverables
SVRS vendor long list
Step 3. Vendor RFP and Vendor Evaluation The focus of this phase is to distribute the States formal
RFP to the list of vendors identified as potential SVRS solution providers and to evaluate their responses
to the RFP.
Activities
Develop the formal RFP for the SVRS
Qualifications and capabilities
Software functionality
Conceptual design
Implementation planning assumptions
Implementation tools and methodologies
Costing
Develop formal RFP packet and distribute to the
list of vendors identified in the previous phase
Review Cost Analysis template created in RFI
initiative and refine to support analysis of the
RFP responses
38
Deliverables
SVRS vendor RFP
Activities
Review and analyze responses with project
team
Determine vendors (short list) selected to demo
their software package to the SEB
Deliverables
Vendor Analysis
Cost comparison
Vendor short list
RFP response analysis
Step 4. Vendor Demonstration Preparation The focus of this phase is to prepare the documentation for
the vendor demonstrations with the selected vendors from the previous phase, as well as to prepare the
state employees on the vendor demonstration process and the demo evaluation they will be expected to
conduct.
Activities
Develop demonstration Agenda
Identify the key voter registration processes
Create a script for the identified processes for

the vendor to demo
Deliverables
Demonstration agenda
Demonstration script
Scripted processes
Supporting data
Review each process script and identify the

supporting data required to perform the demo
Compile the process scripts and demo data into
a demonstration packet to distribute to the
selected vendors
Step 5. Vendor Demonstration Management The focus of this phase is to manage the demonstration
process. During this step, each vendor package would be presented against the defined requirements in
order to determine a software solution and vendor that presents the best solution for the States SVRS
initiative.
Activities
Schedule demonstrations with the vendors
(assume two to three 2-day demos)
Create demonstration scoring methodology and
template
Review scoring methodology and template with
project team
Conduct demonstrations
Debrief as a team on each vendors
demonstration and complete scoring
Consolidate teams scores for each vendor
Conduct analysis and review of scoring results
Follow-up discussion with vendors on any
questions from demo and next steps in the
process
Project team final discussion and review of
vendors
Selection of vendor finalist
Deliverables
Vendor scoring
Vendor evaluations
Vendor finalist
Step 6. Implementation Planning The focus of this phase is to work with the selected vendor to define
the implementation plan for the SVRS; including resource requirements and roll-out timing.
39
Activities
Conduct implementation planning session with
vendor including detailed gap analysis and
inventory of work units requiring modification
and enhancement (2 days).
Define project resources, roles and
responsibilities (vendor and State).
Establish project organization structure (vendor
in conjunction with State).
Define major deliverables and project
management tools.
Create project workplan (task-level activities)
and define critical milestones.
Deliverables
Project organization chart
Resource roles and responsibilities

Implementation plan (workplan)
Project timeline and milestones
Cost and Timeframe:

The vendor selection and RFP contains the following cost and estimating assumptions:
Existing SVRS RFI requirements will largely be used as the basis for defining the
requirements associated with the RFP.
Qty
Hrs /
Driver
Qty
Total
Hrs
# of
FTE
Hrs /
FTE
Weeks
High Cost
Range
Low Cost
Range
Business
requirements
20
20
10
2 WI
1 External
All WI
Vendor research
1 WI
1 External
All WI
RFP
80
80
20
2 WI
2 External
All WI
Demo prep
40
40
20
1 WI
1 External
All WI
Demo mgmt
160
480
120
2 WI
2 External
All WI
Selection
80
240
60
2 WI
2 External
All WI
Planning
80
80
40
1 WI
1 External
All WI
90K
Driver
Phase 3. Statewide Voter Registration System Implementation

This phase consists of the implementation activities required to design, configure, develop, implement
and support a HAVA compliant SVRS solution.
Projects of this size and magnitude are difficult and complex. Based on extensive experience with
complex implementations, we see several critical success factors that will increase the likelihood of a
successful project including:
40
Critical Success Factors

Implementation Magnitude - Proactively addressing
the magnitude of an implementation for 1,850
municipalities and 72 counties.
Training
Facilitation of implementation activities across
1850 municipalities
Operating Models
Hardware
Connectivity
Implementation Partners - Given the magnitude of
this implementation, the State Elections Board will
require structured methodology, tools and
techniques to serve as the foundation for the
implementation.
Project Management Approach The complexity
and risk associated with the SVRS implementation
will require a disciplined project management
approach.
Organizational Structure Experienced team

members across functional, technical and transition
disciplines will be essential.
Approach
Consolidation of Municipalities - Attempting via
the Local Operating Model and Implementation
Planning initiative to consolidate the number of
municipalities requiring access to SVRS.
Transition Management - Dedicated transition
management team will be required to focus on
the transition components of the overall
implementation.
The State Elections Board will need to identify

external and State of Wisconsin resources who bring
robust implementation methodologies, tools and
techniques to leverage as the foundation of this
initiative
Define a project management approach with the
following critical components:
Scope management and change control
Risk management and risk response
Communication management
Schedule control
Budget/Financial control
Quality control
Issue management
Resource management
Define an appropriate mix of functional,
transition and technical personnel with deep
experience in complex implementations.
Define an organizational structure for the
initiative including significant support and input
from municipalities and counties.
During the SVRS study, the State Elections Board received many RFI responses from SVRS vendors.
Each vendor has a unique approach for the implementation of the SVRS solutions. We encourage the
SEB to leverage the implementation methodology provided from the vendor that you ultimately choose as
your SVRS vendor. The following approach is consistent with the approaches proposed by the three RFI
vendors who provided demonstrations and implementation planning information during the SVRS study:
41
Stage I - Design
Stage 0 - Planning
Stage II - Implementation
Conversion Preparation
Initiate Implementation Organization
Business Requirements & Gap Analysis

Identify
Functionality
Requirements
Gap
Assessment
& Requirements
Project Plan and Scoping
Develop
Future State
Processes
Design
Functional
Specifications
Gap
Resolution
Complete
Technical
Design
Configure
System
Parameters
Design
Work
Units
Hardware and
Software
Installation
Confirm
Conversion
Workunits
Develop
Test
Environment
Plan
System
Test
Define Conversion
Approach and
Process by File
Develop
Test
Data
Create
Test
Model
Code
Review
Prepare
Test
Data
Define Technical
Infrastructure
Approach
Develop
User
Procedures
Develop
Training
Materials
Finalize
Implementation
Support
Development
System Test
User
Testing
Stress
Testing
Check Detailed Results
Plan
User
Training
Train
Personnel
Conduct
Unit Test
Integration
Testing
Procedures & Training

Define Application
Integration
Approach
Code
Work
Units
Testing Preparation
Define Procedures
And Training
Approach
Development & Coding
Prototype
Define
Development
Standards
Define Interface
And Integration
Requirements
Develop
Conversion
Procedures
Purify
Conversion Files
Conf. Room
Blueprint
Conversion Design & Planning

Macro
Migration
Approach
Complete
Conversion
Plan
Technical Design & Configuration
Conversion
Convert
Monitor
Production
Transfer to
Operational
Status
Document Enhancements
Project Management
Change Management
Figure 4. High-Level SVRS Implementation Plan

NOTE: Activities within stages are not sequential and will be performed in parallel.
Stage 0 - Project Plan and Scoping The focus of this phase is to prepare for the implementation
initiative. The planning and scoping stage will set the foundation for the overall implementation initiative.
The scope will be defined in detail and the project plan will be developed and approved.
Activities
Develop the project plan
Define detailed project scope
Confirm the project organization structure
Identify and secure project resources
Finalize project cost and timeline
Deliverables
Project plan
Project scope
Project organization structure
Project team
Project cost and timeline
Stage 1 - Design The focus of this phase is to design the application functionality, technical architecture
and overall migration plan for the implementation initiative. The design stage needs to address the
detailed blueprint required to manage central voter registration. The design phase concludes with
implementation planning based on information learned during the design phase.
Activities
Business Requirements and Gap Analysis
Identify functionality requirements
Gap assessment of requirements
Gap resolution
Develop future state processes
42
Deliverables
Business Requirements and Gap Analysis
Functional requirements
Functional gaps
Gap resolution designs
Detailed future state application process
Activities
Design functional specifications
Conference room blueprint
Conversion Design and Planning

Define the macro migration approach
including tools, templates and sequence
Confirm the conversion work units
Define interface and integration
requirements
Define approach and revise estimates for
procedures and training
Define conversion approach, conversion
process and revise conversion estimates
Define the application integration approach
and revise integration estimates
Define the technical infrastructure approach
and revise technical infrastructure estimates
Finalize the implementation plan
Deliverables
flows
Detailed functional specifications
Conference room pilot defining the
operating model for the future state design
Migration approach tools, templates and
sequence
Final listing of conversion work units
Define interface and integration
requirements
Final implementation plan
Training and user procedure approach and
revised estimates
Conversion approach, conversion process,
conversion sequence and revised
conversion estimates
Application integration approach and
revised integration estimates
Technical infrastructure approach and
revised technical infrastructure estimates
Stage 2 - Implementation The focus of this phase is to execute the activities required to successfully
implement the SVRS solution. The implementation stage will address detailed design, development,
testing and training activities.
Activities
Detailed Design and Configuration
Hardware and software installation
Complete detailed technical design
Detailed workunit design (conversion,
integration, detailed procedures, etc)
Configure system parameters
Prototype
Testing Preparation
Develop test environment
Develop test data
Plan system test
Create testing model
Deliverables
Detailed Design and Configuration
Technical environments
Detailed technical design specifications
Detailed work unit design (conversion,
integration, detailed procedures, etc)
Configured application
Prototype
Testing Preparation
Test environment
Test data
System test plan
Test model (test scripts, test scenarios,
expected results)
Procedures and Training
User procedures
User training plan
Training materials
Trained users
Conversion plan
Conversion procedures
Cleansed conversion files
Configuration and Coding
Coding development standards
Completed technical development work
units
Procedures and Training

Develop user procedures
Plan user training
Develop training materials
Train personnel
Complete conversion plan
Develop conversion procedures
Data cleansing for conversion files
Configuration and Coding
Define development standards
Code work units
Conduct code reviews
43
Activities
Prepare test data
Conduct unit test
Support development
System Test
Conduct integration test
Conduct user system test
Conduct technical stress test
Monitor and resolve issues
System Test
Integration test results and issue resolution
User system test results and issue
resolution
Technical stress test results and issue
resolution
Conversion
Cutover plan
Converted application
Production issue resolution
Operational support
Conversion
Conversion preparation
Convert
Monitor production
Transition to operational status
Project Management The focus of this phase is to execute the activities required to successfully
manage the SVRS implementation.
Deliverables
Code reviews
Unit test documentation
Activities
Scope management and change control
Risk management and risk response
Communication management
Schedule control
Budget/Financial control
Quality control
Issue management
Resource management
Deliverables
Scope control and change control plans
Risk management and risk response plans
Communication management plan
Schedule control plan
Financial plan
Quality plan
Issue management plan
Resource management plan
Change Management - The focus of this phase is to execute the activities required to successfully
transition the user community to the new SVRS application and processes.
Activities
Plan, develop and manage the overall
training initiative.
Transition planning
Change readiness assessments
Deliverables
Training
Transition plan
Change readiness assessment
Implementation Cost and Timeframe:

The cost for the implementation stage will be covered in the Five year Total Cost of Ownership
Section of this report. A sample implementation timeline is illustrated in Figure 5. The implementation
timeline represented is only a sample illustration of the potential timeframe for the implementation
activity.
Many planning decision and design decisions are required prior to finalizing an
implementation timeline.
44
High-Level Implementation Plan

Implementation
Scoping and Planning
Business Requirements & Gap Analysis
Technical Design & Configuration
Technical Development
Redesign
Redevelop
Testing Preparation
Proceudres and Training
System Test
Conversion
Post Implementation Support
Project Management
M1
M2
M3
E
l
e
c
t
i
o
n
M4
M5
M6
M7
M8
E
l
e
c
t
i
o
n
M9
E
l
e
c
t
i
o
n
M10 M11 M12 M13 M14 M15 M16 M17 M18 M19 M20 M21 M22 M23 M24
E
l
e
c
t
i
o
n
E
l
e
c
t
i
o
n
E
l
e
c
t
i
o
n
Legend:
Work performed
Known elections
Figure 5. High-Level Implementation Time-Line

Phase 4. Maintenance and Support
The following categories have been defined to assist Wisconsin in understanding the anticipated
maintenance and support requirements that will accompany the implementation of the State SVRS
solution;
Reports The municipalities, county, and state currently use a substantial number of reports to
support the voter registration processes. These reports will be defined during the design phase of
system implementation, however, due to changing legislation and the needs of other stakeholders,
there is a high likelihood that additional reports may be needed and / or requested in the future. Each
request should be reviewed by an oversight committee in order to understand both the importance of
the report requested as well as to understand the amount of dollars that remain within the states ongoing funding.
Modifications During the design phase of the implementation, necessary modifications required to
meet the needs of the state based on HAVA regulations and state statutes will be identified.
However, due to changing legislation and the needs of other stakeholders, there is a high likelihood
that additional modifications may be needed and / or requested in the future. Each request should be
reviewed by an oversight committee in order to understand both the importance of the modification
requested as well as to understand the amount of dollars that remain within the states on-going
funding.
Software Upgrades and Maintenance It is a common practice of any software package to perform
periodic upgrades. These upgrades are normally caused by new software functionality, resolution to
known issues / bugs (patches), and/or standard adjustments based on other operating requirements.
On-going Support Due to the limited state staff, the SVRS system may require outside support,
especially during the time leading up to an election and on day of election. This help will support the
municipalities and counties as they prepare for and conduct elections. The on-going support function
will most likely be cyclical in nature, with increases in need around elections and a significantly
decreased need in off election times.
45
Cost and Timeframe:

The cost associated with maintenance and support will be addressed in the Five Year Total Cost of
Ownership, section J. The timeframe for maintenance and support activities is assumed to be for the
life of the application.
H. Statewide Project Organization Structure

The final project organizational structure will depend greatly on the vendor and SVRS integrator the state
chooses during the vendor selection and RFP initiative. The following is a sample organizational structure
chart based on the information gathered during the SVRS study.
Figure 6. SVRS Project Organization

Roles and Responsibilities.
SVRS Steering Committee. The SVRS Steering Committee level is the highest level on the
organizational chart, with the Program management Office reporting directly to it. The Steering Committee
has overall responsibility for the project. The Steering Committee will consist of leadership personnel from
the State Elections Board, Direct Impact Agencies, Department of Electronic Government / Department of
Administration, League of Municipalities and the Wisconsin Counties Association as well as senior
leadership from any external consulting and/or SVRS vendors. The Steering Committee will be
responsible for:
Decision-making and the resolution of major issues
Resource and budget management
Communicating and advocating change in the organization
Communicating project vision and policy from the top down
46
Program Management. The program management team will include resources to oversee and oversee
the project management team and support the project teams. They report to the Steering Committee and
will be ultimately responsible for managing the SVRS initiative and ensuring the functional, technical, and
transition activities are coordinated and successful. Its major roles and responsibilities include:
Resolve and escalate conflicts as they arise
Communicate importance of and demonstrate commitment to the project
Manage cost and scheduling of the project
Approve key decisions related to the direction of the project
Communicate vision to project team members
Participate in execution of the communication plan to display leadership commitment for the
initiative
Project Management. The Project Managers will provide overall project management, guidance and
direction on a daily basis to the project team. The project management team will include the State of
Wisconsin Project Manager and the SVRS Vendor Project Manager. Project Managers will be responsible
for overseeing the team leads, and will report directly to the Steering Committee and the Program
Management Team. Their responsibilities include:
Overall project planning, resource acquisition and work assignment responsibilities
Establish project milestones, track project performance, and adjust project plans and staffing to
ensure cost effectiveness and timely delivery
Communicate status to the Steering Committee and Program Management Team
SVRS Standards Committee. The SVRS standards committee will work with the program management
team to design standardization across the currently non-standardized processes of voter registration
within the state of Wisconsin. The standards committee will be the ultimate authority on design decisions
relative to standard reports, data standards, standard screens and standard processes. The committee
will work with functional and design team personnel to finalize the critical process and design decisions
when several options exist.
Functional Project Team. The functional team is responsible for defining the business design (and
configuration) for all voter registration processes and administrative processes associated with voter
registration. The functional team is also responsible for driving the testing and training activities.
Technical Project Team. The technical team is responsible for SVRS application configuration,
modification, data conversion, integration with direct impact agencies, infrastructure & environment and
overall support of the technical environment.
Transition Project Team. The transition team is responsible to directly manage the implementation and
rollout activities at the Elections Board, counties, and municipalities. They will also be responsible to
provide input to the steering committee and standards committee on the policy and legislative changes
required, and to implement those changes during the implementation. They will develop and execute
communication plans for each stakeholder group.
I.
Resource and Staffing Estimates
The final resource and staffing models will depend greatly on which SVRS vendor partner is chosen and
the assumptions associated with internal State of Wisconsin resources vs. external vendor resources. It
is critical to note the Elections Board will not have the staff resources to fulfill all the obligations the state
will have in this project. Included in the staffing model below are projections for the project roles the
Elections Board will likely need to outsource.
47
In general, the following resource roles and staffing assumptions can be used as a starting point for
planning resources. Ultimately, the number of resources required for this initiative will be determined
during detailed implementation planning and scoping meetings between the State of Wisconsin and the
SVRS vendor you choose during the vendor selection and RFP initiative. In addition, critical
implementation planning decisions such as the number of automated conversions, the number of users
and the number of locations will drive resource requirements up or down. The following staffing model is
a solid starting point for SEB to understand the overall resource requirements for this strategic initiative:
Role
Steering Committee
(Phases 1 4)
Positions
Key Stakeholder representatives (4-8)
Kevin Kennedy, Project Sponsor
Commitment
8 hours per
month (Sponsor:
12 hours per
week)
Program Management
(Phase 3)
Transition Management (1 SEB outsourced)

Functional (1 SEB)
Technical (1 SEB outsourced)
24 hours per
week
Project Management
(Phase 3)
State Project Manager (1 SEB outsourced)

Vendor Project Manager (1)
Full time
Standards Committee
(Phase 1 3)
Municipal Delegates (1-3)

County Delegates (1-3)
Project Sponsor (1)
SVRS Transition Program Manager (1)
SVRS Functional Program Manager (1)
8 hours per week
Functional Team
(Phase 3)
Team Lead (1 - vendor)

Design Lead (1 - vendor)
Testing Lead (1 - vendor)
Training Lead (1 - vendor)
SVRS Analysts (1 SEB, 1 SEB outsourced, 1-3
vendor)
Full time
Technical Team
(Phase 3)
Team Lead (1 vendor)

Development Lead (1 - vendor)
Conversion Lead (1 - vendor)
Infrastructure & Operations Lead (1 vendor, 1
DOA)
Technical Analysts and Developers (4-12 vendor
developers, 1-2 DOA technical analysts, DIA
analysts/developers as needed)
Full time
Team Lead (1 SEB outsourced)

Implementation coordinators (1 SEB, 4-12
vendor and/or SEB outsourced)
Full time
Transition Team
(Phase 3)
48
J. Five Year Total Cost of Ownership

The total cost for the implementation (Phase 3) and ongoing maintenance (Phase 4) of the SVRS for the
first five years ranges from $25,331,000 at the low end to $41,415,000 at the high end. The cost for preimplementation planning (Phases 1 and 2) ranges from $475, 000 to $1,285,000.
The tables on the subsequent pages present the detailed analysis of the total cost of ownership for the
implementation and ongoing maintenance of the SVRS, excluding the cost of local hardware and
connectivity, but including the cost of data conversion. The total cost of ownership includes the following
elements:
Initial Software and Software Modifications the cost of up-front software modifications as
needed to meet business requirements. This would also include any programming required to
integrate the SVRS with other direct impact agencies.
Annual Software Maintenance Cost the annual cost for help desk support, software updates,
maintenance to existing software modifications, and ongoing modifications/enhancements.
Software Implementation Service Fees The up-front cost of consulting, training, project
management and other professional services fees to install and bring the software live and
operational.
Initial Hardware Cost The up-front hardware cost, including all servers, workstations, network
devices, and communications.
Annual Hardware Maintenance Cost The annual cost for hardware help desk support, repair,
replacement, upgrades, and upgrade implementation service fees
Hardware Implementation Related Fees and Services The up-front cost of consulting,
training, project management and other professional services fees to install and bring the initial
hardware live and operational
ASP/Outsourced IT Operations Management Upfront and ongoing costs of vendor hosting

and IT operations management
Other Annual Costs Any ongoing costs that should be budgeted for (a catch-all for intermittent
costs such as onsite support required for version upgrades if using a package system). This
includes annual inter-agency costs between the SEB and the direct impact agencies.
Annual Training Cost The ongoing training costs for staff turnover and new features
Staff Augmentation The costs of additional personnel that would be incurred during the preimplementation study, RFP phase, implementation and on-going support and maintenance.
Low Assumptions. The first two cost tables represent a consolidation of cost estimates from vendors,
assuming maximum consolidation of municipalities and no scanning of original or subsequent registration
documents.
High Assumptions. The second two cost tables represent the same consolidation of cost estimates
from vendors, but assuming minimal consolidation of municipalities and with the scanning of original and
subsequent registration documents.
49
Five Year Total Cost of Ownership Low Assumptions

Cost by Source
(All Costs in $Thousands)
Software Vendor - Vendor Combined
Initial Software and Software Modification
Annual Software Maintenance Costs
Software Implementation Services & Fees
Initial Hardware Costs - Central
Annual Hardware Maintenance Costs
Hardware Implementation Services & Fees
Other Annual Costs
Annual Training Costs
Total
SEB
Staff Augmentation/ Increase Costs
Total
DOA/DEG/DIA
Software Modification
ASP/Outsourced IT Operations Management
Other Annual Costs
Total
Year 1
2,293
180
2,697
940
215
406
Year 2
2,293
674
3,376
0
147
Year 3
Year 4
Year 5
674
674
674
147
147
147
255
16
246
16
232
16
232
16
Total
4,586
2,876
6,073
940
803
406
965
64
6,731
6,761
1,083
1,069
1,069
16,713
Year 1
300
500
Year 2
600
375
Year 3
Year 4
Year 5
375
375
375
Total
900
2,000
800
975
375
375
375
2,900
Year 1
89
173
Year 2
Year 3
Year 4
Year 5
173
46
173
46
173
46
173
46
Total
89
865
184
262
219
219
219
219
1,138
20,751
Five Year Total Cost of Ownership
50
Five Year Total Cost of Ownership Low Assumptions

Cost by Timing
One-Time Costs
Vendor
DOA, DIA
Vendor
SEB
Vendor
Vendor
Total
On-Going Costs
Other Annual Costs
Staff Augmentation/ Increased Costs
Total
Vendor
Vendor
DOA, DIA
Vendor
SEB
Vendor
SEB
Year 1
2,293
89
2,697
300
940
406
Year 2
2,293
Year 3
Year 4
Year 5
Total
4,586
89
6,073
900
940
406
6,725
6,269
12,994
Year 1
180
215
173
500
Year 2
674
147
173
255
46
16
375
Year 3
674
147
173
246
46
16
375
Year 4
674
147
173
232
46
16
375
Year 5
674
147
173
232
46
16
375
Total
2,876
803
865
965
184
64
2,000
1,068
1,686
1,677
1,663
1,663
7,757
3,376
600
20,751
51
Five Year Total Cost of Ownership High Assumptions

Cost by Source
Software Vendor - Vendor Combined
Other Annual Costs
Total
SEB
Total
DOA/DEG/DIA
Software Modification
Costs of Storing Scanned Images
Other Annual Costs
Total
Year 1
2,808
346
4,570
1,506
639
1,030
1,044
1,044
1,044
414
227
303
16
414
414
414
303
16
303
16
303
16
Total
5,616
4,522
11,010
1,506
2,295
1,257
1,212
64
10,899
11,252
1,777
1,777
1,777
27,482
Year 1
400
500
Year 2
800
375
900
1,175
Year 1
110
173
1,944
2,227
Year 2
2,808
1,044
6,440
Year 2
Year 3
Year 3
Year 4
375
375
375
Total
1,200
2,000
375
375
375
3,200
Year 3
Year 4
Year 5
Year 4
Year 5
Year 5
173
1,944
57
173
1,944
57
173
1,944
57
173
1,944
57
Total
110
865
9,720
228
2,174
2,174
2,174
2,174
10,923
41,605
52
Five Year Total Cost of Ownership High Assumptions

Cost by Timing
One-Time Costs
Vendor
DOA, DIA
Vendor
SEB
Vendor
Vendor
Total
On-Going Costs
Costs of Storing Scanned Images
Other Annual Costs
Total
Vendor
Vendor
DOA, DIA
DOA, DIA
Vendor
SEB
Vendor
SEB
Year 1
2,808
110
4,570
400
1,506
1,030
Year 2
2,808
Year 3
Year 4
Year 5
Total
5,616
110
11,010
1,200
1,506
1,257
10,424
10,275
20,699
Year 1
346
639
2,079
1,944
500
Year 2
1,044
414
2,079
1,944
303
57
16
375
Year 3
1,044
414
2,079
1,944
303
57
16
375
Year 4
1,044
414
2,079
1,944
303
57
16
375
Year 5
1,044
414
2,079
1,944
303
57
16
375
Total
4,522
2,295
10,395
9,720
1,212
228
64
2,000
3,602
4,326
4,326
4,326
4,326
20,906
6,440
800
227
41,605
53

Charter SVRS

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Charter SVRS

Загружено:

Авторское право:

Доступные форматы

Project Charter:

Statewide Voter Registration System

Wisconsin State Elections Board

Ten Terrace Court

May 15, 2003

Keith Downey, Partner

SVRS FINDINGS ....................................................................................................................................... 12

PROJECT BACKGROUND ................................................................................................................. 12

SVRS PROJECT CHARTER ................................................................................................................... 22

Number of municipalities with voter registration

Estimated size of statewide voting age population

Currently managed at the local levels,

Largely decentralized and non-standard, and

Effective in maintaining the integrity of the local electoral process.

State statutesrevised in cosmetic ways, to modify language pertaining to municipal

Figure 1. High-Level Statewide Voter Registration Process Map

- Project Planning and Scoping Refine Requirements

E. Total Cost of Ownership

Software Maintenance (typically incurred in years two and beyond)

Software Implementation Servicesincluding project management, process development, initial

Initial (Central) Hardware (typically incurred in year one)

Initial (Workstation) Hardware (typically incurred in year one)

Hardware Maintenance (typically incurred in years two and beyond)

Hardware Implementation Services and Fees (typically incurred in year one)

Annual Training (typically incurred in years two and beyond)

Other Annual (typically incurred in years two and beyond)

Elections Board, Department of Administration (DOA), and Municipal/County Staffing (a spike in

Networking and Connectivity (typically incurred in all years)

F. Cost Reduction Strategies

We recommend that no scanning of registration documents be conducted. If a municipality desires

Our findings are organized in the following sections:

Statewide voter database

Voter registration statistics comparative complexity

Federal and state statutes

Policies and procedures

Integration with other SEB, county and municipal information systems

Integration with direct impact agencies

Package vs. custom SVRS solution

B. Statewide Voter Database

C. Voter Registration Statistics Comparative Complexity

Approximately 320 municipalities currently have some form of voter registration.

D. Federal and State Statutes

the name of each registered voter appears in the computerized list;

duplicate names are eliminated from the computerized list.

Language must be modified, especially related to deleting or canceling registrations. As was

E. Policies and Procedures

Immediate access to a computerized list of electors

Computer generated, standardized notifications to electors and municipalities

Standardized forms and processes across municipalities

Preventative measures to decrease potential for voter fraud / voter error

Better systems for detecting voter fraud / voter error

Integration/validation of drivers license information with the Division of Motor Vehicles

Integration/validation of felony information with the Department of Correction and Department of

Marking electors as ineligible

Managing election day activities

Accommodating military voters

Processing absentee voter requests and votes

Accommodating overseas voters

Accommodating other special voting populations (e.g., college students)

Managing integration with direct impact agencies

Maintaining geographic data on streets, wards, and districts

Maintaining data on poll locations

Maintaining data on poll workers

F. Integration with other SEB, County and Municipal Information Systems