Charter SVRS

7/18/2019 Charter SVRS

http://slidepdf.com/reader/full/charter-svrs 1/53

Project Charter:Statewide Voter Registration System

Prepared for:

Wisconsin State Elections Board

May 15, 2003

Prepared by

Ten Terrace Court



May 15, 2003

Mr. Kevin J. Kennedy, Executive DirectorWisconsin State Elections Board132 East Wilson Street, Suite 200Madison, 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 registrationsystem (SVRS) for the Wisconsin State Elections Board. The SVRS is a significant initiative for theentire state of Wisconsin. Successful deployment of a new system will require involvement andinvestment at the state, county, and local levels of government. It will require a complex and lengthyimplementation.

For such an initiative, it is imperative that consensus be reached on the SVRS Project Charter before thework begins. To that end we submit our report, divided into three sections plus appendices:

1. Executive Summary

2. SVRS Findings3. SVRS Project Charter4. Appendices

The Executive Summary provides a high level overview of the SVRS initiative, describing the currentsituation in Wisconsin and the implementation steps the State of Wisconsin must take to achievecompliance with the SVRS provisions of the federal Help America Vote Act (HAVA). Estimated costs ofthe SVRS and cost reduction strategies are also outlined.

The SVRS Findings section provides a review of the SVRS study project, and presents importantinformation discovered during the analysis. The findings are the result of extensive discussions withcounty 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. Thefindings are logically grouped into major themes, each of which will have a significant impact on theSVRS implementation and which therefore also shape the Project Charter recommendations.

C f f S S



the SVRS system which should be used as the basis for final policy, technical, operational, and fundingdecisions.

Thank you for the opportunity to work with you and your team. While it has been a significant amount ofwork in a very short period of time, it has been a pleasure and a privilege to work on this important projectwith the State Elections Board, the Department of Electronic Government, the Department ofTransportation’s Division of Motor Vehicles, the Department of Corrections, the Department of Health andFamily Services, and the county and municipal officials. We appreciate the effort and cooperation of allinvolved.

Sincerely,

Virchow Krause & Co., LLP

Keith Downey, Partner



Table of Contents

EXECUTIVE SUMMARY ............................................................................................................................ 5

A. B ACKGROUND..................................................................................................................................5 B. CURRENT SITUATION........................................................................................................................ 5 C. SVRS FUTURE-STATE ..................................................................................................................... 6 D. NEXT STEPS ........................ ............................................................................................................8 E. TOTAL COST OF OWNERSHIP ............................................................................................................9 F. COST REDUCTION STRATEGIES ......................................................................................................10

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

A. PROJECT B ACKGROUND .................................................................................................................12 B. STATEWIDE VOTER D ATABASE.................................................... ....................................................13 C. VOTER REGISTRATION STATISTICS – COMPARATIVE COMPLEXITY ....................................................14 D. FEDERAL AND STATE STATUTES .....................................................................................................15 E. POLICIES AND PROCEDURES................................................................................. ..........................17 F. INTEGRATION WITH OTHER SEB, COUNTY AND MUNICIPAL INFORMATION SYSTEMS ..........................18 G. INTEGRATION WITH DIRECT IMPACT AGENCIES................................................................................. 20 H. P ACKAGE VS. CUSTOM SVRS SOLUTION ........................................................................................20

SVRS PROJECT CHARTER ...................................................................................................................22 A. GOAL............................................................................................................................................. 22 B. OBJECTIVES...................................................................................................................................22 C. SCOPE........................................................................................................................................... 22 D. ASSUMPTIONS.............................. ..................................................................................................24 E. RISKS AND MITIGATION STRATEGY..................................................................................................26 F. FUTURE SYSTEM PROCESSES .......................................... ..............................................................29 G. STATEWIDE VOTER REGISTRATION SYSTEM (SVRS) PLAN ..............................................................30 H. STATEWIDE PROJECT ORGANIZATION STRUCTURE .......................................................................... 46

I. RESOURCE AND STAFFING ESTIMATES ............................................................................................47 J. FIVE YEAR TOTAL COST OF OWNERSHIP .........................................................................................49

APPENDICES



Execu t i ve Summ ary

A. Background

In October 2002, the federal government passed the Help America Vote Act of 2002 (HAVA). Thislegislation created new election administration requirements for all states and called for an upgrade ofvoting systems to better accommodate persons with disabilities. Specifically, HAVA calls for the creationof 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 ofevery legally registered voter in the state. The current timeline for HAVA calls for election officials to meetthe 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 anextension request and expects it will be accepted. .

In December 2002, the Legislature provided funds for the State Elections Board (SEB) to study andprepare specific recommendations for implementing a statewide voter registration database system(SVRS), including a proposal for the system’s cost and proposed legislation required to initially implementsuch a system. The Elections Board retained Virchow Krause & Co. LLP to assist with the study, analyzethe central and local system requirements, and develop and issue a request for information (RFI) topotential 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 Situat ion

The State of Wisconsin does not currently have a formalized statewide voter registration system orprocess. Consider the following:

• Under the present statutes, only municipalities that have a population over 5,000 are required toregister electors.

• There are some individual municipalities that have voter registration systems to comply withstatutory requirements.

• Some counties maintain voter registration data for municipalities and some municipalitieselectronically maintain elector lists but do not register voters.

• Most municipalities have no record (manual or electronic) of its electors. Consider the followingdata, collected from the November 2002 election:

Number of municipalities without voter registration 1,530Number of voters in the November 2002 election 563,272

Number of municipalities with voter registration 320Number of registered electors 2,625,353Number of voters in the November 2002 election 1,363,789

Estimated size of statewide voting age population 4,100,000



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 andprocedures for the centralized voter list.

C. SVRS Futu re-State

Based on information from other states and from vendors who have implemented statewide votersystems, it is clear that a statewide voter registration system is significantly different from a municipalsystem both in kind and in degree.

A statewide voter system is not simply a municipal system with more records. A statewide system hasdifferent integration processes (between municipalities and with other state agencies); it has differentsecurity issues; different validation processes; different purge processes, and different scalabilityrequirements. The system has to accommodate various levels of technological sophistication andvolumes of transactions ranging from the City of Milwaukee, Milwaukee County (with up to 100,000election 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 stateagencies require a very large scale project effort. Statutory, policy, funding, process, organizational, andtechnical issues must be carefully addressed in order for this project to succeed. This is a uniquechallenge 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 packagevendors. No vendor with statewide voter registration experience proposed the development of a customapplication. 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 softwaredevelopment and implementation project, and the overall initiative may benefit greatly from leveraging theknowledge 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 database—one centralized, unified list at the core of the electoral process.

• Municipal information—the SVRS is more than just voters; it requires the maintenance ofaddress, municipal, and voting jurisdiction information.

• State statutes—revised in “cosmetic” ways, to modify language pertaining to municipalregistration and revised substantially to address new issues created by the existence of onestatewide elector database.

• Policies and procedures for the 72 counties and 1,850 municipalities—to insure the integrityof the database, the number of users must be controlled and the policies and procedures thatgather the data must be standardized.



• Initial and on-going training—a burst of activity initially, but on-going training as well, becauseof the natural turnover in the office of municipal and county clerks.

•

Large scale technical architecture—the size and complexity of the system result in veryrobust 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 Wisconsin’s statewide voter registration is depicted at a highlevel in Figure 1, below.





E. Tota l 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 Services—including project management, process development, initialtraining, 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 inyears 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 vendorswho have SVRS experience, application software and modifications represent only 20% to 30% of thefive-year total cost of ownership. Hardware, implementation, training, and on-going support andmanagement 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 ofthe system.

Through detailed implementation discussions with DOA, the direct impact agencies, and the threevendors with SVRS statewide voter registration experience, cost estimates were developed to reflect aset of “low” assumptions (i.e., a low number of locations/ users, no scanning, and technical supportprovided by the state), and a set of corresponding “high” assumptions.

The estimated range of the State Elections Board’s costs are summarized below (see SVRS ProjectCharter, 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 Year 1 Year 2 Year 3 Year 4 Year 5 Total1 Define Local

Operating Modeland Pre-RFPPlanning

$475 –1,195

$475 –1,195

2 SVRS VendorSelection

$0 - 90 $0 – 90

3 SVRSImplementation

$6,725 –10,424

$6,269–10,275

$12,994 –20,699

4 Maintenance andSupport

$1,068 –3,602

1,686 –4,326

1,677 –4,326

1,663 –4,326

1,663 –4,326

$7,757 –20,906

Total $8,268–

15,311

$7,955 –

14,601

$1,677 –

4,326

$1,663 –

4,326

$1,663 –

4,326

$21,226 –

42,890

NOTES:

1) Costs above include county and municipal data conversion, but do not include any county ormunicipal hardware or connectivity costs. These are currently assumed to be provided by thecounties 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, thevariance between vendors on the “high” assumptions was substantial.

4) Because information was gathered through an RFI, vendor specific cost information (and othervendor specific system functionality information) are confidential at the request of the vendors.

F. Cost Reduct io n Strategies

A further review of the three main factors that drive the variation between the “low” and “high” costestimates 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, itwould have to support approximately 3,000 users. The alternative is to consolidate the number ofsites and users to under 1,000. One consolidation scenario is to have counties or othermunicipalities provide voter registration services for neighboring municipalities that do notcurrently have voter registration. Based on vendor response, the consolidation of users wouldsave (millions) in software site license costs, hardware costs, implementation costs, and initialand on-going training costs.

• Conversion – Data. The issue related to data conversion consists of defining the threshold belowwhich 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 notan insignificant task. The cost of typing registration forms into the new system can be done bylimited term employees.

• Conversion – Scanned Images. This issue consists of deciding whether original registration formsare converted (i.e., scanned) during implementation and whether, on an on-going basis, scannedimages are an element of the system. The possibilities related to scanning are whether all forms

ill b d f ill b d h th i i ti l t th di ti f th



We recommend that no scanning of registration documents be conducted. If a municipality desiresscanning, it may be performed by that municipality, at its discretion and cost, and housed in a localsecondary 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-3support.



SVRS Find ing s

A. Project Backgrou nd

The State Elections Board (SEB) hired Virchow Krause & Co in January, 2003 to help the state researchand assess the options and alternatives associated with the statewide voter registration system aspectsof HAVA. The study focused on the following phases:

Project Management

Quality Assurance

Risk Management

Communication

Benchmark& Process

Design

RequirementsDefinition

IdentifyVendors

Vendor RFI& Vendor

Evaluation

Vendor DemoPrep

Vendor DemoMgmt

Impl.Planning &

Rec’s.

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 realizationthat 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 reportincluding:

• Benchmark and Process Design – A high-level definition of critical high-level voter registrationprocesses was documented as the foundation for benchmarking and requirements definitionactivities. The team benchmarked the current situation for voter registration processes againstother states that have recently completed similar initiatives. The study documented criticallessons learned and identified several requirements for the application and implementationcomponents of the SVRS solution.

• Requirements Definition – The team documented business requirements associated with voterregistration based on HAVA regulations and State statutes. The team defined over three hundredapplication requirements during requirements definition and prioritized them. The requirementsserved as the basis for the RFI document.

• Identify Vendors – The team spent time identifying, researching and qualifying a list of SVRSapplication 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 andimplementation plans with the study team.

• Vendor Demonstration Prep – The team prepared a detailed demonstration script tailored to thespecific requirements for the State. The script included sample data allowing the team to viewapplication functionality.

• Vendor Demonstrations The team hosted three one day demonstrations from SVRS solution



• 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 haveaccess rights defined by state statutes and implemented through the system’s security functionality. Thedatabase will be developed, implemented and owned by the Elections Board and hosted in state facilities.Support and maintenance of the system’s components will be defined through service level agreementswith 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 theoverall application architecture cannot be underestimated, and they translate into sophisticatedrequirements 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. Whiletransactional systems create records of an instance of an event at a specific point in time, theSVRS 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 ageWisconsin 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 people’s right to vote being at risk. The software and process controlsrequired 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 bedesigned for an environment where many people (i.e., millions of voters) will need or wantaccess. Loss of systems or data at key periods in the voting cycle could have a significant impacton 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 eithercase, this requires a large scale technical architecture and application architecture. The softwarewill need to be run in a large, multi-server environment for both application servers and databaseservers.

The ser comm nit ill reflect a ide ariet of comp ter and election management skill le els



new-born children, long-deceased great-great grandparents, etc. There is a practical limit relatedto the storage of data. Once limits are placed on the content of the list, the state will need todevelop and adhere to statewide statutes, policies and procedures related to the list’s

maintenance.

C. Voter Registrat ion Stat ist ics – Comparat ive Complexi ty

Consider the following statistics defined during the SVRS study:

Wisconsin Voter Registration Structure. According to SVRS solution providers and other statescontemplating similar SVRS solutions, Wisconsin’s structure of decentralized voter registration at themunicipal level increases the challenges, risks and costs associated with implementation of SVRSsolutions that are HAVA compliant. Our study found that the number of municipalities requiring access tothe SVRS application was the single largest contributor to overall cost variation. Our research shows thecost, complexity and risk associated with SVRS implementation is magnified significantly when using thedecentralized municipal registration approach. Consider the following information gathered during the RFIprocess with several SVRS package vendors.

The current structure of managing registration requires municipalities to manage registration or tocontract with another municipality or county to complete the registration responsibilities. This structuredrives 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’ voterregistration 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 totalusers.

• Wisconsin has an estimated 4.1 million registered electors but must accommodate 1,850 siteconnections and approximately 3,000 total users (for estimating purposes). A huge costdifferential on the order of 4x to 6x the cost of the Pennsylvania solution will result.

• Michigan’s structure contained more than 1,500 municipalities where voter registration wasperformed in the past. For cost reduction purposes, Michigan was able to restructure theregistration 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 thecomplexity, risks and costs associated with the Michigan Qualified Voter File (QVF) initiative andenabled a more cost effective solution for the state of Michigan. Michigan has approximately 6.7million registered voters.

Cost Implications for Number of Users The study revealed a wide range of costs based on the



users. If the number of locations/users is not firm and fixed in the RFP, then the integrity of theprocurement process will be jeopardized.

In addition, the sooner the state makes fundamental decisions relative to the critical implementationdrivers, the earlier the state can begin to organize and structure implementation activities around thoseimplementation activities.

Data Conversion and Document Scanning Costs. The study defined the following statistics andchallenges 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,000records will manually re-enter the voter registration records prior to system go-live. Whilecalculating the threshold number of records is a simple cost/benefit relationship, the statemust decidea) 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 tomake 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 fordetermining the number of users/locations.

D. Federal and State Statutes

Section 303 of HAVA describes the federal requirements for statewide voter registration, which aresummarized 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



303 § 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 byreason of death of the registrant the State shall coordinate the computerized list with State

agency records on death.

a.2.B 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.

a.3 The appropriate State or local official shall provide adequate technological security measures toprevent the unauthorized access to the computerized list established under this section.

a.4 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.

a.5.A.i. 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 driver’s license, the

applicant’s driver’s 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 applicant’s social security number.

a.5.A.ii If an applicant for voter registration for an election for Federal office has not been issued a current

and valid driver’s 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 thatthe 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.

a.5.A.ii 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 extentrequired 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.



recommendation is that §6.27 be modified to convey the intent that, with the exception of somespecial 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 cancelledbecause of a recent event (e.g., death). Rather broader language dealing with archiving andpurging data at a system level must be developed. For example, statutes could provide thatrecords for electors who have been inactive or ineligible for over ten years may be purged andarchived with redistricting.

• Statutes must define access rights and limits. The proposed statute provides that only threeentities may access a record for the purpose of adding or modifying the record: the ElectionsBoard, election officials in the Wisconsin municipality from which the elector is moving, andelection officials in the Wisconsin municipality to which the elector is moving.

The system would control write-access through its security functionality. The system wouldprovide 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 asystem of “anywhere registration.” It is recommended that this functionality be deferred untilenough 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 determinewhere they vote, or who their elected representatives are) is seen as an important function for thevalue and acceptability of the system.

Current statutes and administrative policy do not describe provisions for the access, sale and/ordistribution of large extracts of the voter registration list. Currently, some municipalities charge forcopies of poll lists and walking lists, etc. Statewide policies and procedures would have to bedeveloped for this objective.

• Statutes must define required communication/reporting. The proposed statute calls for notificationto 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 andnotify the new municipality; or the new municipality may change the record and notify the formermunicipality. Notification may be by e-mail or through the US Postal Service.

• Reporting requirements (and supporting business processes) will change once the system is fullyoperational. Statutes should be changed to reflect this. For example, §6.275 calls formunicipalities to create and submit reports to counties. Counties then submit these reports to theSEB who then manually enters the data in order to prepare its results and analyses. Because thedata 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 system’s menu.

E. Pol ic ies and Procedu res

With the implementation of the SVRS, existing processes for voter registration will change to reflect thechange in technology, roles and responsibilities, and information access and visibility. In the existingvoter registration processes, each municipality works in its own system environment. Information

di l t i t i ibl t t id f th i i lit E h i i lit h it



• Computer generated, standardized notifications to electors and municipalities

• Information exchanges with direct impact agencies for record updates (felonies, deaths, driverslicense 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 ofJustice

• 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 throughoutthe state by the municipalities (and counties). While some counties may provide assistance in processingfor their municipalities, uniform processes must be developed and adhered to in order to contribute to theintegrity 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 databaseis introduced. The consequence of weak integrity would be the opportunity for voter disenfranchisementand voter fraud.

The study found that processes define business requirements for the RFP. The state will need to makedecisions related to future state processes prior to issuing the RFP so as to minimize implementationcosts that would be incurred through change orders.

F. Integrat ion wi th other SEB, County and Munic ipal Inform at ion Systems

The SEB currently maintains two information systems (SWEBIS 1 and SWEBIS 2) SWEBIS 1 is a



of election administration kept within SWEBIS 2. Based on the research of the study, it appears that thefunction 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 eliminatethe need for counties and municipalities to maintain voter registration systems. “Voter registration,” asused 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 trackinformation on poll locations and poll workers. Because statewide voter registration systems evolved fromcounty and municipal systems, the SVRS systems that were studied included modules for managing polllocations and poll workers. Thus, in addition to voter registration, local systems for managing polllocations and poll workers could be eliminated by the SVRS.

Larger municipal voter registration systems also maintain geographic information related to wards andaddresses. Poll lists have to communicate the ward in which a resident may vote. Some systemsintegrate 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 whichoffices are pertinent to their residence. On-line access functionality is critical to creating buy-in fromelectors. Additionally, the study found that local election offices receive hundreds and thousands of callsfrom electors for this information. Thus, the presence of on-line access to poll location information wouldcreate savings at the county and municipal level.

SVRS and the SEB’s Election Administration System. The SVRS system would overlap SWEBIS 2 interms of geography, offices, and incumbents and candidates.

SWEBIS 2 maintains data on geography at the ward level, only. For example, in SWEBIS 2, the systemonly 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 connect1234 West Main Street, Apt #4 to ward 1. Thus, the SVRS would be able to accommodate the SEB’scurrent definition of geography.

However, in SWEBIS 2, geography is connected to an office which is connected to an incumbent andconnected to candidates. There are many other data elements that are needed to completely manage theconcept of an “office” (e.g., terms of office). Thus, the SVRS system could not replace this function ofSWEBIS 2 (without significant modification).

The SVRS system would also overlap SWEBIS 2 in terms of incumbents and candidates. Incumbentsand candidates are almost always registered voters, thus name and address data would exist in bothsystems. However, candidates are only one type of “registrant” within SWEBIS 2. Others registrants

include parties, PAC’s and conduits. Also, there are many more data elements that are needed tocompletely manage candidates (e.g., campaign committee data). Thus, the SVRS system could notreplace this function of SWEBIS 2 (without significant modification).

SVRS and Campaign Finance Information. Campaign finance information is currently maintained bySWEBIS 1. SWEBIS 1 is not electronically linked to SWEBIS 2. Thus, there is redundant processing ofsome registrant data. SVRS systems would not be able to replace any aspect of campaign finance



However, there is a future scenario where a direct connection between the SVRS and the voting systemis possible. Connecting ballot creation and the recording and tallying of votes would allow for “anywhere-voting.” 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 creationsystem. Then, the voter could sign in on the voting equipment which would then pull up the appropriateballot. Thus, a voter could vote at any location that was connected to the SVRS. Furthermore, thisscenario is not far behind the concept of internet voting; that is, the voter signing into the voting systemvia the internet and then receiving and casting their ballot. Most likely, the technology for this future statewill exist long before statutes enable it.

As the state Elections Board pursues the selection and implementation of its SVRS, it should work toensure that the solution does not preclude it from the flexibility of considering anywhere-voting and

Internet voting.

G. Integrat ion with Direct Impact Agencies

HAVA calls for agreements between the SEB and the DMV. It calls on the SEB to also use data ondeaths and felony/civil rights status from other direct impact agencies (e.g., DHFS and DOJ). Theagreements must specify the following:

• The specific elements of data requested (e.g., name, address, driver’s 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 MargaretSmith), and are made even more complex when aliases and name changes are considered. The timingand 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 thousandsof 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 theirexperiences, that records that match 100% be distributed to appropriate municipalities for their approvalprior to updating the statewide voter database. This second scenario appears to be more aligned withWisconsin’s philosophy related to electors and voters. All vendors suggested that incomplete orunmatched records be ignored, because the time to resolve, cost to resolve, and potential for error and



impact of this project. If the findings of this study included a conclusion that the state’s requirements werevery 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 functionalspecifications required by the application. The RFP would need to provide screen layouts, reportdesigns, and many other system elements.

The study found that the requirements of Wisconsin’s SVRS are not very unique. That is, vendors withexisting SVRS solutions bring knowledge, expertise, and additional functionality. Thus, selection of a

custom application does not appear to be warranted.



SVRS Pro ject Ch arter

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, andadministered at the State level that contains the name and registration information of every legallyregistered voter in the State and assigns a unique identifier to each legally registered voter in the State.

B. Object ives

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 andencouraging 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 withother 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 ofvoters.

3. The Department of Corrections (DOC) Department of Justice (DOJ) for information on thestatus of convicted felons’ civil rights.

C. Scope

The high-level functions of the state Elections Board and local municipalities are depicted in Figure 2, onthe following page, showing the in-scope and out-of-scope components for the SVRS implementation.





The functions of the SVRS overlap other systems. The following is a summary of the systems within theelections process and whether they are in or out of scope for the SVRS system.

SystemIn/Out ofScope Owner Functions

SVRS In State Elections Board • A single, uniform, official, centralized,interactive computerized statewide voterregistration list.

• Processing additions and modifications tovoter records.

• Accommodating military electors, absenteevoters, 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

MunicipalInformation In State Elections Board•

Maintenance of geographic boundaries ofvarious electoral districts and reporting units.• Maintaining data on municipal clerks.• Maintaining data on municipalities as it relates

to poll locations (including accessibility) andpoll workers,

Election Administration

Out State Elections Board • Maintaining registrant files.• Administering ballot access by candidates and

political parties.

CampaignFinance Out State Elections Board • Receiving and filing campaign financeinformation from registrants.

• Auditing campaign finance information forstatutory compliance.

• Reporting on campaign finance data.Voting Out Municipalities and

counties• Ballot creation.• Administering elections.• Managing voting equipment.• Submitting election results to the SEB for

canvassing.

D. Assumpt ions

Hardware, Software and On-going Maintenance. Because of the size of the SEB’s staff, it is currently



2. How will entries in the statewide voter database be physically updated when data isreceived by the State Elections Board from other agencies and the data from the otheragency partially matches data in the statewide voter database?

3. How will entries in the statewide voter database be physically updated when data isreceived by the State Elections Board from other agencies and the data from the otheragency 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 acomplete 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:

2000Census

PopulationNumber

of Muni’s %

EstimatedNumber ofElectors %

Number ofRegistrants %

Number ofVoters

(Nov 2002) %

< 5,000 1,719 91.0 1,436,549 32.4 192,492 682,990 35.4

≥ 5,000 171 9.0 2,999,528 67.6 2,470,377 1,244,071 64.6

1,890 100.0 4,436,0772 100.0 2,662,869 1,927,061 100.0

AbsenteeElectors

LateRegistrations

Election DayRegistrationsElection

DateMuni’s

Reporting Voters # % # % # %

11/5/2002 1,850 1,927,061 113,853 5.91 5,476 .21 134,348 6.97

11/7/2000 1,903 2,619,184 160,425 6.12 32,014 1.22 411,656 15.72

11/3/1998 1,886 1,799,758 73,517 4.08 7,896 .44 170,479 9.47

11/5/1996 1,888 2,252,301 104,607 4.64 16,024 .71 260,815 11.58

11/8/1994 1,640 1,445,935 64,308 4.45 3,370 .23 101,770 7.04

11/3/1992 1,527 1,871,379 93,357 4.99 37,715 2.02 301,154 16.09

11/6/1990 1,819 1,365,203 40,853 2.99 9,137 .67 100,383 7.35

11/8/1988 1,618 2,043,218 82,360 4.03 19,800 .97 242,542 11.87

11/6/1984 1,666 1,879,619 Not Reported 21,814 1.16 190,937 10.16

Notes:

1) The number of municipalities (1,850) exceeds the actual number of municipalities because somemunicipalities’ borders cross county lines. Data on small municipalities is slightly overstated, becausesome “large” municipalities (population >5,000); e.g., Milwaukee, have a “small” ward (<5,000) inanother 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 knowthat this number includes duplicates from the point of view of a state-wide list. We do not know the



and may require any municipality to adhere to procedures established by the board for propermaintenance 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 forsignificant commitments of people from various agencies (depending on the phase). Clearly, there isalways a need for resources from the SEB. In addition, there are needs for resources from the countiesand municipalities, from DOA, and from direct impact agencies. Furthermore, especially during theimplementation, 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 theappropriate number of people with the appropriate skill sets to the phases. In the absence of numbersand skills, additional external costs would be incurred.

E. Risks and Mit igat ion Strategy

Risk Element Risk Mitigation Strategy

Resources This project will require significant

investments in hardware, software andsupport, including personnel forsignificant periods of time.

The Federal Government has

allocated funds but has not made acommitment to provide some on-goingfunding.Continue to focus on the five year,total cost of ownership in evaluatingvendor responses and budgetaryplanning.

Consolidating the number of users andsites can lower the cost of the system.

Project Sponsorship Project sponsorship involves financialresources and non-financialcommitment.

From a financial perspective, theFederal government has pledgedinitial funding which may be used forthis project. Continuing to focus on thefive year total cost of ownership willkeep the state prepared over thelonger term.

Project Sponsorship A lack of buy-in on the part ofmunicipalities, counties, or legislators

increases risks to data completenessand integrity.

From a buy-in perspective, we havelearned that continued involvement by

counties and municipalities beginningat the start of the project is a keysuccess factor. The involvement thatexisted in the RFI study was greatlyappreciated by all who participated.Local officials know that this will betheir world shortly and are excited by




Expectations The likely initial discomfort fromimplementing a new system will be

underestimated. The discomfort willlead to widespread resistance.

Only those people who have beeninvolved in a system conversion know

the challenges involved. On-goingcommunication and effective trainingwill mitigate some of this risk. Aphased implementation and roll-outwill mitigate some of this risk. Lastly,developing user groups will mitigatesome of this risk.

Planning Initial planning will be minimizedbecause it appears to be a cost-saving

tactic.

In our experience, the absence ofsufficient planning is the principle

source of project failure. The pre-RFPplanning and study will save the state(and vendors) multiples of time anddollars in the RFP phase. Pre-implementation planning anddiscussions with the vendor will savethe state (and vendors) multiples oftime and dollars. All of the tasks listedin the pre-RFP planning and study

phase, all of the tasks listed in the pre-implementation phase have to bedone. Putting them off only increasestheir cost.

Timeframe An unrealistic timeframe (i.e., tooshort) will place undo strain on allresources.

At this time, the board plans to requestan extension from the January 1, 2004deadline. This means that the newdeadline would be January 1, 2006. Arealistic timeframe, assuming that the

RFP is authorized in the latter portionof 2003 is for a completeimplementation and roll-out byJanuary 1, 2005. This will give thestate, counties, and municipalities theopportunity to plan implementationand accommodate the 2004 electionschedule. At the same time, it is nottoo slow of a timeframe that theproject incurs excessive additional

costs and/or loses momentum.Vendor Availability At this time, approximately 35 states

do not have a HAVA-compliant voterregistration system. There are only ahandful of vendors with statewidevoter registration systems experience.

From discussions with vendors, weunderstand that Wisconsin is currentlyahead of the pack in terms of studyingand defining its requirements anddiscussing its needs with vendors.




Schedule There are four elections scheduled in2004 already, including the general

presidential election in November. Additionally, municipalities mustconduct other special elections aswell. Thus, roll out must be sensitiveto these schedules.

If legislative approval for the RFP isgranted by the end of 2003, then there

would be some possibility to roll outthe solution to a small set ofmunicipalities for some of the 2004elections.

A phased roll-out would allow for themost flexibility in order to minimizeconflict with special elections andimplementation. During planning, thestate and vendor would need to

coordinate the implementationschedule with these other events.

Scope Because election systems areintegrated and overlap, there is a riskthat the scope of the project couldexpand and additional costs beincurred.

During implementation planning, thescope of the project should be clearlydefined. Both in-scope and known out-of-scope elements must be articulated.

Scope Future mandates may warrantintegration with other aspects of the

election system (e.g., voting systemsand election results tabulation). Therisk is that the selection of an SVRSpartner will limit future options.

During the RFP process, somepreference should be given to vendors

who, in addition to having statewide voter registration system experience,have experience in other aspects ofelection administration. Similarly,some preference should be given toproposals with an open architecturethat would give the state the mostflexibility in terms of choices for addingother election administration

functionalities.Technical The SVRS is more than just a

software selection and implementationproject. It is a highly complex systemintegrated with other state agencies,used by hundreds to thousands ofclerks, and accessed by millions ofelectors.

In the RFP process, preference shouldbe given to vendors who havesuccessfully implemented a statewide voter registration system. There is anopportunity to leverage expertise andexperience from good and painfullessons learned. The importance ofplanning cannot be emphasizedenough.

Future Strategy There is a risk that the system will notbe able to accommodate future statemandates related to voter registration;for example, anywhere registration,anywhere voting or voter registrationdata being encoded in the magnetic

In the RFP process, preference shouldbe given to vendors who havestatewide voter registration systemexperience, a vision (based onexperience) for the future of voterregistration resource to address that



F. Future System Process es

Future Process Flows. Detailed future state processes have been documented in process flows whichcan be found in Appendix 2. The flows layout the high-level vision of the SEB for the future of voterregistration, assuming the current understanding of revisions to state statutes. The high-level processeswere 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 hasbeen selected.

Technical Architecture. A high-level depiction of the SVRS technical architecture is:



G. Statewide Voter Registrat ion Sys tem (SVRS) Plan

The SVRS plan below illustrates the sequence of initiatives required to successfully design, develop,implement and maintain the SVRS application.

1. Define LocalOperating Model andPre-RFP Planning

2. SVRS VendorSelection

3. SVRSImplementation

4. SVRSMaintenance and

Support

0. SVRSStudy& RFI

Complete- Municipality Process

Consolidation- Conversion Planning- Local Operating Models- Custom Development Due

Diligence (Optional)- Finalize State Statute

Changes

- Refine Requirements- Identify Vendors- Vendor RFP & Eval- Vendor Demonstration- Vendor Demonstration Mgmt- Implementation Planning

- Project Planning and Scoping- Business Requirements and

Gap Analysis- Conversion Design and

Planning- Implementation Planning- Technical Design and

Configuration- Testing Preparation- Procedures and Training- Conversion Preparation- Development and Coding

- System Test- Conversion

- Application Support- Hardware Support- Networking Support- Help Desk Support- Infrastructure Maintenance- Training

5-15 Months 1-3 Months 9-22 Months On Going

1. Define LocalOperating Model andPre-RFP Planning

2. SVRS VendorSelection

3. SVRSImplementation

4. SVRSMaintenance and

Support

0. SVRSStudy& RFI

Complete- Municipality Process

Consolidation- Conversion Planning- Local Operating Models- Custom Development Due

Diligence (Optional)- Finalize State Statute

Changes

- Refine Requirements- Identify Vendors- Vendor RFP & Eval- Vendor Demonstration- Vendor Demonstration Mgmt- Implementation Planning

- Project Planning and Scoping- Business Requirements and

Gap Analysis- Conversion Design and

Planning- Implementation Planning- Technical Design and

Configuration- Testing Preparation- Procedures and Training- Conversion Preparation- Development and Coding

- System Test- Conversion

- Application Support- Hardware Support- Networking Support- Help Desk Support- Infrastructure Maintenance- Training

5-15 Months 1-3 Months 9-22 Months On Going

Phase 1. Define Local Operating Model and Pre-RFP Planning. Our strong recommendation is toproceed with step one through step three (below). We consider step four an optional step to becompleted only if the State Elections Board is interested in pursuing custom development solutions tomeet 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 numberlocations and users could occur via the consolidation of certain registration responsibilities from smallermunicipalities to larger municipalities or counties.

When the cost of local workstations and connectivity to the central SVRS are factored in, the number ofusers and locations significantly affects the total cost of ownership to the state. However, because manymunicipalities already have workstation and network resources, the impact on marginal cost issignificantly reduced. Certain SVRS vendor solutions were significantly affected by the number of usersand locations. As was discussed in the findings section, full access to the SVRS would translate toapproximately 2,000 locations and 3,000 individual users. Some package solutions are not financiallyviable at this volume. Thus, in order to increase the number of SVRS options, reducing these numberswould be necessary.



• 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 ofunderstanding – This alternative acknowledges that some municipalities may not have theresources or desire to perform some aspects of processing data in the new SVRS. Thosemunicipalities would choose a processing partner (i.e., another municipality or the county) on acase-by-case basis.

Activities DeliverablesDefine initial consolidation opportunities Municipality and county consolidation

matrixDevelop SVRS overview presentation -roles/responsibilities

SVRS overview presentation

Prepare for county consolidation focus groups(intent is to get input on consolidation approach)

Municipal and county consolidation focusgroup materials

Conduct consolidation focus groups Municipal and county focus groupfeedback and input

Prepare follow-up materials to consolidation focusgroups

Follow-up materials

Prepare for consolidation working sessions (intentis to facilitate design/development of consolidationparameters)

Municipal and county consolidationworking sessions

Conduct consolidation working sessions Initial consolidation parametersDevelop county by county consolidation approach

– DraftConsolidation memo of understanding –draft contract

Develop "opt in" and "opt out" Documentapproving the consolidation approach

Opt in / opt out document

Facilitate signing of memo of understanding –

county and municipality

Signed memo of understanding

Advantages:

• Consolidation of municipalities reduces the overall cost, complexity and risk of the SVRSimplementation.

• This option presents a voluntary approach which preserves local decision making. Therewould be no forced consolidation.

Disadvantages:

• The voluntary option requires both the municipality and the county to agree on theconsolidation terms, which will require significant effort.

• This option proposes a fundamental structure change relative to the roles andresponsibilities of the current voter registration process. It removes the element of localownership contained within the current structure, which may not be politically welcome.

• The consolidation activity requires the definition of revised resource requirements at the



• Approximately 26 municipalities per county (1,850/72)

• Approximately 80 hours per county to define and gain agreements with municipalities forthe consolidation effort

Estimating Assumptions

Driver Qty

Hrs /Driver

QtyTotal

Hrs# of FTE

Hrs /FTE Weeks

High CostRange

Low CostRange

#Counties 72 80 5,760 5 1,152 30

1 WI4 External

3 WI2 External

Projected Cost Estimate 500K 250K

• Option 2: Legislative and Statutory Consolidation – This alternative acknowledges thatconsolidation will occur for the SVRS. The statutory process would require consolidation of voterregistration processes at the county level for those municipalities that have populations less than5,000. The major focus for this phase is defining the revised resource requirements within themunicipalities and counties given assumptions that consolidation of registration responsibilities tothe county level will occur.

Activities DeliverablesDraft enabling legislation providing the StateElections Board the authority to force municipalconsolidation at the county level for municipalitieswith a voting age population less than 5,000.

Draft consolidation legislation

Develop “SVRS Consolidation” assessmentmaterials

SVRS consolidation assessment materials

Conduct SVRS consolidation assessment

sessions with municipalities and counties

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

Revise and finalize draft registration Enabling legislation

Advantages:

• This option uses statutory authority to address the largest factor for the SVRSimplementation; consolidation. Statutory authority to consolidate voter registrationresponsibility from municipalities to counties for municipalities with a population of fewerthan 5,000 will significantly reduce the total cost, complexity and risk associated with theimplementation of SVRS.

Di d t



• Increased burden on the county may be considered an unfunded mandate in times ofvery 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 tosupport processes required to support the consolidation model.

• If the consolidation legislation includes “processing fees” at the county level, themunicipalities may view the consolidation as an unfunded mandate.

Cost and Timeframe:The cost and timeframe to facilitate legislative and/or statutory consolidation is significantlyless but would require some incremental investment from Wisconsin. Our estimatingassumptions 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 requiredto process registration.

• NOTE: Initial estimates indicate approximately 20-30 registration transactions can beprocessed per hour.


Driver Qty

Hrs /Driver

QtyTotal

Hrs# of FTE

Hrs /FTE Weeks

High CostRange

Low CostRange

#Counties 72 20 1,440 5 288 8

1 WI4 External

3 WI2 External

Projected Cost Estimate 200K 75K Step 2. Develop Conversion Plan – The focus of this phase would be to define the number of automatedconversions required from each existing municipality that currently contains a voter registrationapplication/database and to decide whether original registration documents will be scanned as a part ofconversion 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. Theapproach consists of working with each municipality to determine the following statistics:

• Number of records requiring conversion – define a manual or automated approach based onpre-established conversion record thresholds. Manual data entry approaches does not implythe municipality or the county must provide the data entry service. Initial manual vs.automated thresholds consist of somewhere between one thousand and four thousand

d If th i i lit t i l th th th h ld d t t l k ld b



• Document Scanning Planning Approach – This activity will define the policy related to thescanning of registration documents.

Activities DeliverablesPrepare templates and forms fordocumentation of existing voter registrationapplications and the overall data migrationapproach.

Current voter registration application/databasedocumentation templates and data migrationapproach documents.

Identify, assess and document current voterregistration applications/databases.

Documented current applications and databases.

Create the application migration map including:• Application migration sequence - phased,

parallel, big bang• Include pre-requisites• Alternatives available for conversion of

data including1) automated conversion2) manual conversion - data entry3) process workarounds

• Costs/benefits of each alternative• Recommendation on approach

Application migration map

Identify, assess and document the policyrelated to document scanning

Cost and Timeframe:The development of data conversion and migration plans for each of the existingmunicipalities with voter registration is an essential component of cost reduction andprocurement 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 automatedconversion approach.

Approximately 210 municipalities with voter registration systems containing fewer than5,000 registration records will require a manual conversion approach (data entry).


Driver Qty

Hrs /Driver

QtyTotal

Hrs# of FTE

Hrs /FTE Weeks

High CostRange

Low CostRange

Muni’s w/

Large VoterReg Files 110 24 2,640 9 294 8

5 WI4 External

7 WI2 External

Muni’s w/Small VoterReg Files 210 4 840 9 91 3

5 WI4 External

7 WI2 External



This activity is focused on establishing standardization across the municipalities and counties relative tobusiness processes. For example, the standards committee would be charged with defining the standardset 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 disagreementresolution). The standards committee will assist in defining the local operating model definition.

Activities DeliverablesDefine the roles/responsibilities, objectives,scope deliverables for the standards committee

Standards committee charter includingroles/responsibilities, objectives, scope andexpected deliverables from the committee.

Identify the standards committee members Standards committee membersDefine the future operating model includingstandardized 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

Future operating models

Cost and Timeframe:The development of local operating models including defining and implementing a standardscommittee is a critical success factor for the SVRS implementation. Costs and estimatingassumptions 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 operatingprocedures per process.


Driver Qty

Hrs /Driver

QtyTotal

Hrs# of FTE

Hrs /FTE Weeks

High CostRange

Low CostRange

# Processes 19 80 1520 5 304 83 WI

2 External All WI

Projected Cost Estimate 125K 0

Step 4 Custom Development Due Diligence (OPTIONAL)



Activities DeliverablesIdentify custom development vendors Vendor universeCustom development RFI Custom development RFI

RFI response analysis Custom development vendor presentationsImplementation planning and revised costestimates

Cost estimates and implementation planningestimates

Develop the study report 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 provenindustry 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 softwareand these costs would also be incurred with custom solutions (i.e. implementationservices, training, conversion and hardware).

• The nature of custom development procurements will require a significant up-frontinvestment in design specifications. Design specifications for reports, screens,

application flow, application logic would all be required to ensure vendors are submittingresponsible bids during the procurement process.

• Maintenance and support of custom developed applications requires significantresources for post go-live modifications, enhancements and bug fixes.

• Additional risk may be added when dealing with custom developed applications relativeto support, maintenance and upgradeability compared to SVRS packaged vendors withproven history and track records.

Cost and Timeframe:

The custom development discovery study contains the following cost and estimatingassumptions:• Existing SVRS RFI requirements will require conversion into a custom development

conceptual design including a WBS (Work Breakdown Structure) for the inventory ofcustom development work units.

• Approximately 3 hours per requirement will be necessary to convert the existing




Driver Qty

Hrs /

DriverQty TotalHrs # of FTE Hrs /FTE Weeks High CostRange Low CostRange

# of requirements 333 3 999 4 250 62 WI

2 External All WI

Report specs 75 16 1,200 4 300 81 WI

3 External All WI

Screen specs 32 40 1,280 4 320 41 WI

3 External All WI

Application logic 1 80 80 1 80 20 WI

1 External All WI

Integration logic 3 16 48 1 48 20 WI

1 External All WI


Summary. The local operating model and “pre-RFP” planning initiative is necessary as a criticalcomponent of the overall SVRS implementation initiative. Steps one through three must be completedprior to conducting the RFP and vendor selection. Benefits of completing these activities prior to thevendor 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 SVRSsolutions and enables you to effectively lower the cost of HAVA compliance.

• Enables you to develop standards across municipalities and counties via standard operatingmodels 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 theleading SVRS vendors and a rigorous vendor screening process. Vendor selection activities are firstfocused on finalizing the SVRS functional, technical, and implementation requirements, and thenrequiring the vendors to perform scripted demonstrations using SEB business scenarios. This allows theSEB and DEG to select the best vendor solution based not only on the vendor’s ability to satisfy the



Step 1. Requirements Definition – The focus of this phase is to review those requirements defined duringthe SVRS RFI project to refine / add to these for the RFP. In addition, many critical implementationplanning 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 arefixed fee or with very narrow price ranges.

Activities DeliverablesReview HAVA Act and confirm that all mandatesare accounted for in the states requirements

Vendor RFP system requirements and planningassumptions• SVRS prioritized requirements document• Vendor RFP planning pssumptions

Review state statutes and confirm that allapplicable statutes are accounted for in thestates requirementsReview new enabling legislation and confirm thatthe existing requirements cover all additionallegislationReview existing RFI SVRS requirements(functional and technical) and adjust theserequirements as neededRefine/add to SVRS RFI requirements for theRFP

Prioritize the new list of requirementsObtain project team consensus on requirementsand their prioritiesDefine RFP planning assumptions tosupplement the initial list of requirements

Step 2. Identify Vendors – The focus of this phase is to identify those vendors in the market who offerSVRS solutions that would meet the requirements of the Wisconsin SVRS initiative.

Activities DeliverablesReview compiled list of vendors from the RFIinitiative

SVRS vendor long list

Gather additional information on known vendors(as necessary)

Step 3. Vendor RFP and Vendor Evaluation – The focus of this phase is to distribute the State’s formalRFP to the list of vendors identified as potential SVRS solution providers and to evaluate their responsesto the RFP.

Activities DeliverablesDevelop the formal RFP for the SVRS• Qualifications and capabilities• Software functionality• Conceptual design

SVRS vendor RFP



Activities DeliverablesReview and analyze responses with projectteam

Determine vendors (short list) selected to demotheir software package to the SEB 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 forthe vendor demonstrations with the selected vendors from the previous phase, as well as to prepare thestate employees on the vendor demonstration process and the demo evaluation they will be expected toconduct.

Activities DeliverablesDevelop demonstration Agenda Demonstration agendaIdentify the key voter registration processes Demonstration script

• Scripted processes• Supporting data

Create a script for the identified processes forthe vendor to demo

Review each process script and identify the

supporting data required to perform the demoCompile the process scripts and demo data intoa demonstration packet to distribute to theselected vendors

Step 5. Vendor Demonstration Management – The focus of this phase is to manage the demonstrationprocess. During this step, each vendor package would be presented against the defined requirements inorder to determine a software solution and vendor that presents the best solution for the State’s SVRSinitiative.

Activities DeliverablesSchedule demonstrations with the vendors(assume two to three 2-day demos)Create demonstration scoring methodology andtemplateReview scoring methodology and template withproject team

Vendor scoring

Conduct demonstrations Vendor evaluations

Debrief as a team on each vendor’sdemonstration and complete scoring Vendor finalist

Consolidate teams scores for each vendorConduct analysis and review of scoring resultsFollow-up discussion with vendors on anyquestions from demo and next steps in theprocess



Activities DeliverablesConduct implementation planning session withvendor including detailed gap analysis and

inventory of work units requiring modificationand enhancement (2 days).

Project organization chart

Define project resources, roles andresponsibilities (vendor and State).

Resource roles and responsibilities

Establish project organization structure (vendorin conjunction with State).

Implementation plan (workplan)

Define major deliverables and projectmanagement tools.

Project timeline and milestones

Create project workplan (task-level activities)and define critical 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.


Driver Qty

Hrs /Driver

QtyTotal

Hrs# of FTE

Hrs /FTE Weeks

High CostRange

Low CostRange

Businessrequirements 1 20 20 2 10 1

2 WI1 External All WI

Vendor research 1 4 4 2 2 01 WI

1 External All WI

RFP 1 80 80 4 20 2

2 WI

2 External All WI

Demo prep 1 40 40 2 20 11 WI

1 External All WI

Demo mgmt 3 160 480 4 120 32 WI

2 External All WI

Selection 3 80 240 4 60 22 WI

2 External All WI

Planning 1 80 80 2 40 11 WI

1 External All WI




Critical Success Factors Approach

Implementation Magnitude - Proactively addressing

the magnitude of an implementation for 1,850municipalities and 72 counties.• Training• Facilitation of implementation activities across

1850 municipalities• Operating Models• Hardware• Connectivity

• Consolidation of Municipalities - Attempting via

the Local Operating Model and ImplementationPlanning initiative to consolidate the number ofmunicipalities requiring access to SVRS.

• Transition Management - Dedicated transitionmanagement team will be required to focus onthe transition components of the overallimplementation.

Implementation Partners - Given the magnitude of

this implementation, the State Elections Board willrequire structured methodology, tools andtechniques to serve as the foundation for theimplementation.

The State Elections Board will need to identify

external and State of Wisconsin resources who bringrobust implementation methodologies, tools andtechniques to leverage as the foundation of thisinitiative

Project Management Approach – The complexityand risk associated with the SVRS implementationwill require a disciplined project managementapproach.

Define a project management approach with thefollowing 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

Organizational Structure – Experienced teammembers across functional, technical and transitiondisciplines will be essential.

• Define an appropriate mix of functional,transition and technical personnel with deepexperience in complex implementations.

• Define an organizational structure for the

initiative including significant support and inputfrom 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 theSEB to leverage the implementation methodology provided from the vendor that you ultimately choose asyour SVRS vendor. The following approach is consistent with the approaches proposed by the three RFIvendors who provided demonstrations and implementation planning information during the SVRS study:



Stage I - Design Stage II - Implementation

Configure

System

Parameters

Technical Design & Configuration

Testing Preparation

Procedures & Training

Conversion Preparation

Development & Coding

System Test

Conversion

Convert

Document Enhancements

Initiate Implementation Organization

Hardware and

Software

Installation

Business Requirements & Gap Analysis

Gap

Resolution

Conversion Design & Planning

Confirm

Conversion

Workunits

Implementation Planning

Pr o j e c t Pl an

an d S c o pi n g

Develop

Future State

Processes

Design

Functional

Specifications

Prototype

Conf. Room

Blueprint

Stage 0 - Planning

Project Management

Change Management

Complete

Technical

Design

Gap

Assessment& Requirements

Identify

FunctionalityRequirements

Define Interface

And Integration

Requirements

Macro

Migration

Approach

Define Procedures

And Training

Approach

Define Conversion

Approach and

Process by File

Define Application

Integration

Approach

Define Technical

Infrastructure

Approach

Finalize

Implementation

Design

Work

Units

Create

Test

Model

Plan

System

Test

Develop

Test

Data

Develop

Test

Environment

Develop

User

Procedures

Develop

Training

Materials

Plan

User

Training

Train

Personnel

Purify

Conversion Files

Complete

Conversion

Plan

Develop

Conversion

Procedures

Prepare

Test

Data

Support

Development

Code

Work

Units

Conduct

Unit Test

Code

Review

Define

Development

Standards

Integration

Testing

Stress

Testing

User

Testing

Check Detailed Results

Transfer to

Operational

Status

Monitor

Production

Stage I - Design Stage II - Implementation

Configure

System

Parameters

Technical Design & Configuration

Testing Preparation

Procedures & Training

Conversion Preparation

Development & Coding

System Test

Conversion

Convert

Document Enhancements

Initiate Implementation Organization

Hardware and

Software

Installation

Business Requirements & Gap Analysis

Gap

Resolution

Conversion Design & Planning

Confirm

Conversion

Workunits


Pr o j e c t Pl an

an d S c o pi n g

Develop

Future State

Processes

Design

Functional

Specifications

Prototype

Conf. Room

Blueprint

Stage 0 - Planning

Project Management

Change Management

Complete

Technical

Design

Gap

Assessment& Requirements

Identify

FunctionalityRequirements

Define Interface

And Integration

Requirements

Macro

Migration

Approach

Define Procedures

And Training

Approach

Define Conversion

Approach and

Process by File

Define Application

Integration

Approach

Define Technical

Infrastructure

Approach

Finalize

Implementation

Design

Work

Units

Create

Test

Model

Plan

System

Test

Develop

Test

Data

Develop

Test

Environment

Develop

User

Procedures

Develop

Training

Materials

Plan

User

Training

Train

Personnel

Purify

Conversion Files

Complete

Conversion

Plan

Develop

Conversion

Procedures

Prepare

Test

Data

Support

Development

Code

Work

Units

Conduct

Unit Test

Code

Review

Define

Development

Standards

Integration

Testing

Stress

Testing

User

Testing

Check Detailed Results

Transfer to

Operational

Status

Monitor

Production

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 implementationinitiative. 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 DeliverablesDevelop the project plan Project planDefine detailed project scope Project scopeConfirm the project organization structure Project organization structure

Identify and secure project resources Project teamFinalize project cost and timeline Project cost and timeline

Stage 1 - Design – The focus of this phase is to design the application functionality, technical architectureand overall migration plan for the implementation initiative. The design stage needs to address thedetailed blueprint required to manage central voter registration The design phase concludes with



Activities Deliverables

• Design functional specifications• Conference room blueprint

flows• Detailed functional specifications•

Conference room pilot defining theoperating model for the future state designConversion Design and Planning• Define the macro migration approach

including tools, templates and sequence• Confirm the conversion work units• Define interface and integration

requirements

Conversion Design and Planning• Migration approach tools, templates and

sequence• Final listing of conversion work units• Define interface and integration

requirementsImplementation Planning•

Define approach and revise estimates forprocedures 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


Final implementation plan• Training and user procedure approach and

revised estimates• Conversion approach, conversion process,

conversion sequence and revisedconversion estimates

• Application integration approach andrevised integration estimates

• Technical infrastructure approach andrevised technical infrastructure estimates

Stage 2 - Implementation – The focus of this phase is to execute the activities required to successfullyimplement the SVRS solution. The implementation stage will address detailed design, development,testing and training activities.

Activities DeliverablesDetailed Design and Configuration• Hardware and software installation• Complete detailed technical design• Detailed workunit design (conversion,

integration, detailed procedures, etc)• Configure system parameters• Prototype

Detailed Design and Configuration• Technical environments• Detailed technical design specifications• Detailed work unit design (conversion,

integration, detailed procedures, etc)• Configured application• Prototype

Testing Preparation• Develop test environment• Develop test data• Plan system test• Create testing model

Testing Preparation• Test environment• Test data• System test plan• Test model (test scripts, test scenarios,

expected results)Procedures and Training• Develop user procedures• Plan user training• Develop training materials

T i l

Procedures and Training• User procedures• User training plan• Training materials

T i d




• Prepare test data• Conduct unit test•

Support development

• Code reviews• Unit test documentation

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

resolutionConversion• Conversion preparation•

Convert• Monitor production• Transition to operational status

Conversion• Cutover plan•

Converted application• Production issue resolution• Operational support

• Project Management – The focus of this phase is to execute the activities required to successfullymanage the SVRS implementation.


• Scope management and change control

• Risk management and risk response• Communication management• Schedule control• Budget/Financial control• Quality control• Issue management• Resource management

• 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.


• Plan, develop and manage the overalltraining initiative.

• Transition planning • Change readiness assessments

• 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 OwnershipSection of this report. A sample implementation timeline is illustrated in Figure 5. The implementationtimeline represented is only a sample illustration of the potential timeframe for the implementationactivity. Many planning decision and design decisions are required prior to finalizing animplementation timeline.



Implementation M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M17 M18 M19 M20 M21 M22 M23 M24

Scoping and PlanningBusiness Requirements & Gap Analysis

Conversion Design and PlanningImplementation Planning E E E E E ETechnical Design & Configuration l l l l l lTechnical Development e e e e e eRedesign c c c c c cRedevelop t t t t t tTesting Preparation i i i i i iProceudres and Training o o o o o oConversion Preparation n n n n n nSystem TestConversionPost Implementation Support

Project Management

Legend:

Work performedKnown elections

High-Level Implementation Plan

Figure 5. High-Level Implementation Time-Line

Phase 4. Maintenance and Support

The following categories have been defined to assist Wisconsin in understanding the anticipatedmaintenance and support requirements that will accompany the implementation of the State SVRSsolution;

• Reports – The municipalities, county, and state currently use a substantial number of reports tosupport the voter registration processes. These reports will be defined during the design phase ofsystem 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. Eachrequest 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 state’s on-going funding.

• Modifications – During the design phase of the implementation, necessary modifications required tomeet 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 likelihoodthat additional modifications may be needed and / or requested in the future. Each request should bereviewed by an oversight committee in order to understand both the importance of the modificationrequested as well as to understand the amount of dollars that remain within the state’s on-goingfunding.

• Software Upgrades and Maintenance – It is a common practice of any software package to performperiodic upgrades. These upgrades are normally caused by new software functionality, resolution toknown 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

i i liti d ti th f d d t l ti Th i t f ti



Cost and Timeframe:

The cost associated with maintenance and support will be addressed in the Five Year Total Cost ofOwnership, section J. The timeframe for maintenance and support activities is assumed to be for thelife of the application.

H. Statewide Project Organizat ion Structu re

The final project organizational structure will depend greatly on the vendor and SVRS integrator the statechooses during the vendor selection and RFP initiative. The following is a sample organizational structurechart 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 theorganizational chart, with the Program management Office reporting directly to it. The Steering Committeehas overall responsibility for the project. The Steering Committee will consist of leadership personnel fromthe 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



Program Management. The program management team will include resources to oversee and overseethe project management team and support the project teams. They report to the Steering Committee andwill be ultimately responsible for managing the SVRS initiative and ensuring the functional, technical, andtransition 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 theinitiative

Project Management. The Project Managers will provide overall project management, guidance anddirection on a daily basis to the project team. The project management team will include the State ofWisconsin Project Manager and the SVRS Vendor Project Manager. Project Managers will be responsiblefor overseeing the team leads, and will report directly to the Steering Committee and the ProgramManagement 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 managementteam to design standardization across the currently non-standardized processes of voter registrationwithin the state of Wisconsin. The standards committee will be the ultimate authority on design decisionsrelative to standard reports, data standards, standard screens and standard processes. The committeewill work with functional and design team personnel to finalize the critical process and design decisionswhen several options exist.

Functional Project Team. The functional team is responsible for defining the business design (andconfiguration) for all voter registration processes and administrative processes associated with voterregistration. 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 andoverall support of the technical environment.

Transition Project Team. The transition team is responsible to directly manage the implementation androllout activities at the Elections Board, counties, and municipalities. They will also be responsible toprovide input to the steering committee and standards committee on the policy and legislative changesrequired, and to implement those changes during the implementation. They will develop and executecommunication plans for each stakeholder group.



In general, the following resource roles and staffing assumptions can be used as a starting point forplanning resources. Ultimately, the number of resources required for this initiative will be determinedduring detailed implementation planning and scoping meetings between the State of Wisconsin and theSVRS vendor you choose during the vendor selection and RFP initiative. In addition, criticalimplementation planning decisions such as the number of automated conversions, the number of usersand the number of locations will drive resource requirements up or down. The following staffing model isa solid starting point for SEB to understand the overall resource requirements for this strategic initiative:

Role Positions CommitmentSteering Committee(Phases 1 – 4)

• Key Stakeholder representatives (4-8) • Kevin Kennedy, Project Sponsor

8 hours permonth (Sponsor:12 hours per

week)

Program Management(Phase 3)

• Transition Management (1 – SEB outsourced)• Functional (1 – SEB)• Technical (1 – SEB outsourced)

24 hours perweek

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, DIAanalysts/developers as needed)

Full time

Transition Team(Phase 3)

• Team Lead (1 – SEB outsourced)• Implementation coordinators (1 SEB 4 12

Full time



J. Five Year Total Cost of Own ership

The total cost for the implementation (Phase 3) and ongoing maintenance (Phase 4) of the SVRS for thefirst five years ranges from $25,331,000 at the low end to $41,415,000 at the high end. The cost for pre-implementation 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 theimplementation and ongoing maintenance of the SVRS, excluding the cost of local hardware andconnectivity, but including the cost of data conversion. The total cost of ownership includes the followingelements:

• Initial Software and Software Modifications – the cost of up-front software modifications asneeded to meet business requirements. This would also include any programming required tointegrate 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, projectmanagement and other professional services fees to install and bring the software live andoperational.

• 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 initialhardware live and operational

• ASP/Outsourced IT Operations Management – Upfront and ongoing costs of vendor hostingand IT operations management

• Other Annual Costs – Any ongoing costs that should be budgeted for (a catch-all for intermittentcosts such as onsite support required for version upgrades if using a package system). Thisincludes 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 pre-implementation 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 registrationdocuments.

High Assumptions. The second two cost tables represent the same consolidation of cost estimatesfrom vendors, but assuming minimal consolidation of municipalities and with the scanning of original andsubsequent registration documents.

Fi Y T t l C t f O hi L A ti



Five Year Total Cost of Ownership – Low AssumptionsCost by Source

(All Costs in $Thousands)

Software Vendor - Vendor Combined Year 1 Year 2 Year 3 Year 4 Year 5 Total

Initial Software and Software Modification 2,293 2,293 4,586

Annual Software Maintenance Costs 180 674 674 674 674 2,876

Software Implementation Services & Fees 2,697 3,376 6,073

Initial Hardware Costs - Central 940 0 940

Annual Hardware Maintenance Costs 215 147 147 147 147 803

Hardware Implementation Services & Fees 406 406

Other Annual Costs 255 246 232 232 965

Annual Training Costs 16 16 16 16 64

Total 6,731 6,761 1,083 1,069 1,069 16,713

SEB Year 1 Year 2 Year 3 Year 4 Year 5 Total

Software Implementation Services & Fees 300 600 900

Staff Augmentation/ Increase Costs 500 375 375 375 375 2,000

Total 800 975 375 375 375 2,900

DOA/DEG/DIA Year 1 Year 2 Year 3 Year 4 Year 5 Total

Software Modification 89 89

ASP/Outsourced IT Operations Management 173 173 173 173 173 865


Total 262 219 219 219 219 1,138

Five Year Total Cost of Ownership 20,751

Fi Y T t l C t f O hi L A ti



51

Five Year Total Cost of Ownership – Low AssumptionsCost by Timing


One-Time Costs Year 1 Year 2 Year 3 Year 4 Year 5 TotalInitial Software and Software Modification Vendor 2,293 2,293 4,586

DOA, DIA 89 89Software Implementation Services & Fees Vendor 2,697 3,376 6,073

SEB 300 600 900

Initial Hardware Costs - Central Vendor 940 940

Hardware Implementation Services & Fees Vendor 406 406

Total 6,725 6,269 - - - 12,994

On-Going Costs Year 1 Year 2 Year 3 Year 4 Year 5 Total

Annual Software Maintenance Costs Vendor 180 674 674 674 674 2,876

Annual Hardware Maintenance Costs Vendor 215 147 147 147 147 803

ASP/Outsourced IT Operations Management DOA, DIA 173 173 173 173 173 865

Other Annual Costs Vendor 255 246 232 232 965

SEB 46 46 46 46 184 Annual Training Costs Vendor 16 16 16 16 64

Staff Augmentation/ Increased Costs SEB 500 375 375 375 375 2,000

Total 1,068 1,686 1,677 1,663 1,663 7,757


Five Year Total Cost of Ownership High Assumptions



Five Year Total Cost of Ownership – High AssumptionsCost by Source


Software Vendor - Vendor Combined Year 1 Year 2 Year 3 Year 4 Year 5 Total

Initial Software and Software Modification 2,808 2,808 5,616

Annual Software Maintenance Costs 346 1,044 1,044 1,044 1,044 4,522

Software Implementation Services & Fees 4,570 6,440 11,010

Initial Hardware Costs - Central 1,506 1,506

Annual Hardware Maintenance Costs 639 414 414 414 414 2,295

Hardware Implementation Services & Fees 1,030 227 1,257

Other Annual Costs 303 303 303 303 1,212

Annual Training Costs 16 16 16 16 64

Total 10,899 11,252 1,777 1,777 1,777 27,482

SEB Year 1 Year 2 Year 3 Year 4 Year 5 Total

Software Implementation Services & Fees 400 800 1,200

Staff Augmentation/ Increased Costs 500 375 375 375 375 2,000

Total 900 1,175 375 375 375 3,200

DOA/DEG/DIA Year 1 Year 2 Year 3 Year 4 Year 5 Total

Software Modification 110 110

ASP/Outsourced IT Operations Management 173 173 173 173 173 865

Costs of Storing Scanned Images 1,944 1,944 1,944 1,944 1,944 9,720


Total 2,227 2,174 2,174 2,174 2,174 10,923


Five Year Total Cost of Ownership – High Assumptions



Five Year Total Cost of Ownership – High AssumptionsCost by Timing


One-Time Costs Year 1 Year 2 Year 3 Year 4 Year 5 TotalInitial Software and Software Modification Vendor 2,808 2,808 5,616

DOA, DIA 110 110

Software Implementation Services & Fees Vendor 4,570 6,440 11,010

SEB 400 800 1,200

Initial Hardware Costs - Central Vendor 1,506 1,506

Hardware Implementation Services & Fees Vendor 1,030 227 1,257

Total 10,424 10,275 - - - 20,699

On-Going Costs Year 1 Year 2 Year 3 Year 4 Year 5 Total

Annual Software Maintenance Costs Vendor 346 1,044 1,044 1,044 1,044 4,522

Annual Hardware Maintenance Costs Vendor 639 414 414 414 414 2,295

ASP/Outsourced IT Operations Management DOA, DIA 2,079 2,079 2,079 2,079 2,079 10,395

Costs of Storing Scanned Images DOA, DIA 1,944 1,944 1,944 1,944 1,944 9,720

Other Annual Costs Vendor 303 303 303 303 1,212SEB 57 57 57 57 228

Annual Training Costs Vendor 16 16 16 16 64

Staff Augmentation/ Increased Costs SEB 500 375 375 375 375 2,000

Total 3,602 4,326 4,326 4,326 4,326 20,906


53

Charter SVRS

Documents