Money, Patience, Testing and Inevitable Delays: What it takes to build a Statewide Voter Registration System

Introduction:

In 2002, Congress adopted the Help America Vote Act (HAVA), a response to controversies surrounding the 2000 Presidential Election. In addition to authorizing funds for states to replace punch card voting systems, HAVA created the U.S. Elections Assistance Commission (EAC), required the new EAC to take over the testing and certification of voting equipment, and imposed a set of requirements on states concerning the administration of federal elections. One of those state requirements, (The Help America Vote Act, P.L. 107-252, Sec. 303. ) demanded that each state create a “single, uniform, official, centralized, interactive computerized statewide voter registration list defined, maintained, and administered at the state level that contains the name and registration information of every legally registered voter in the state and assigns a unique identifier to each legally registered voter in the state…” Section 303 further required that, for federal elections, the statewide list was to serve as the official voter registration list.

Why did Congress include Section 303 in HAVA? At the time, voter registration databases in all but three states — Michigan, Kentucky, and Alaska — were the responsibility of county, city, and/or township elections officials. When HAVA was adopted, many elected officials believed such a dispersed system was vulnerable to voter registration fraud. Voters move frequently and old registrations sometimes took years to be cancelled causing databases to be notoriously inaccurate and out-of-date. Duplicate registrations were perceived as a systemic vulnerability — an opportunity — for multiple voting in the same election by a single voter.

As is often the case in elections administration, states interpreted the new federal requirement differently. Some, such as Oregon, Colorado, and Maryland, built “top-down” voter registration databases, complete with elections management functions, administered by the chief state elections official. Each local elections official in those states signed in to the same, statewide, real-time, computer system to add new voters, update registrations of existing voters, produce poll books, manage petitions, record candidate filings, track poll workers, and a host of other elections management functions. Other states, such as Ohio, California, and South Dakota, allowed local elections officials to continue to manage their own voter databases and elections management systems. The locals were required, however, to upload voter registration data periodically to a centralized state list of voters. Such systems picked up a moniker by elections officials as “bottom-up” systems. Bottom-up systems were easier and cheaper to build. Some states, such as South Dakota and Utah, built them in-house.

The EAC, in official guidance issued in 2005, blessed both the top-down and bottom-up approaches despite a serious weakness of bottom-up systems: A state’s voter registration database, maintained by a bottom-up approach, was always going to contain data disparities from a local database. In the 22 years since HAVA passed, more and more bottom-up states recognized their systems’ weaknesses. They are abandoning that approach and building new, top-down systems. Recent examples include Washington, New Jersey, and Nevada.

A statewide voter registration system with election management functions is not an off-the-shelf product. Yes, there are similarities in all state systems. But differences in state laws and election functions from one state to the next require extensive customization. In addition, security requirements have become increasingly important in the wake of bad actors trying, sometimes successfully, to breach state systems.

An Expensive and Risky Task

Technology experts often warn elections officials that the failure rate for large information technology projects is high — ranging from 50% to 75% or more in some fields. Cost overruns, delays, and inadequate project management are common, and the warnings underscore the importance of thorough project planning, managing expectations, building flexibility into the schedule, and assessing risk management throughout the life of the project. Based on the experience of various states, building a top-down system can take two to three years to complete and cost, depending on the size of the state and the number of local jurisdictions can climb as high as $20 million to $30 million.

Based on a history of projects completed or underway in the states, the following best practices are recommended for project planning:

• First, settle on a realistic schedule and go-live date. It is generally recommended that states try to go live with a new system in years that do not include a federal election. But the complexities of completing big projects during busy federal, state, and local elections schedules in some states sometimes make it impossible to avoid it. Elections officials should, however, plan for possible delays.
• Buy-in of local elections officials is a must. Turf wars can create serious problems if buy-in is not secured at the beginning. Local elections officials, county commissions, township boards, and city officials who oversee local voter registration systems must be satisfied that a statewide system will benefit their voters by expanded functionality and increased efficiency. Large jurisdictions are typically the most difficult to bring on board. Because they know and trust their systems and are often blessed with more resources, large jurisdictions often doubt their state’s ability to convert to a system that meets their needs.
• Designate a state project manager. State and local elections officials need to be confident that the state’s project manager is experienced and capable of overseeing a complex, high-risk project. The project manager should be designated before the competitive bid process is underway.
• Select an independent quality assurance (QA) monitor. A qualified QA monitor who is not a state or local employee should be hired to monitor the project and issue periodic public reports on progress and risk, including the status of project expenses. Continual risk assessment will keep all parties aware of potential delays, cost overruns, and the quality of work done by the vendor.
• Include local elections officials in setting requirements for the new system. The state project manager should oversee the process for determining, in detail, the functionality desired for the new system. The functionality is determined by a set of detailed requirements that the vendor must build into the system. The typical project can have dozens — or even hundreds — of requirements. Local elections officials must be involved so that they can be confident that the new system will meet their needs.
• Include local elections officials in the competitive bid process, including proposal evaluation and scoring. It is easier for local elections officials to trust the process if some of them are involved in picking the best vendor for the job at a competitive price. They must help determine if the bidder has satisfactorily explained that it can meet all the requirements.
• Require bidders to include a proposed schedule for the project and name the personnel — including their qualifications — who will manage the project for them. State and local elections officials want assurances that the vendor is providing qualified and experienced personnel and that they will be assigned for the life of the project. The turnover of vendor personnel raises the failure risk of large projects.
• Require bidders to develop a plan for adequate testing of the new system. All bidders should agree to participate with state and local elections officials in thorough user acceptance testing (UAT) and mock elections. The testing should be closely reviewed by the quality assurance monitor. Thorough record keeping and adequate time must be built into the project schedule for the vendor to fix bugs revealed by the testing and for re-testing to take place.

With project planning completed and a vendor selected, the state and vendor are ready to launch the project with a schedule and go-live date in mind. But as states have experienced, not everything goes as planned.

What can go wrong?

Some of the most common project complications reported by states include:

• Vendor delays in completing requirements.
• State and local elections officials find it difficult or impossible to devote the time necessary for their participation in the project.
• Change orders due to state and local elections officials requesting new requirements/functionality after the project has started.
• User acceptance testing and mock elections delays because local elections officials are unable to participate as planned.
• High turnover of local and state elections officials impedes user acceptance testing.
• User acceptance testing reveals issues with vendor compliance with requirements, which requires delays to fix “bugs.”
• Local official complaints that training provided by the vendor and the state on how to use the new system is inadequate and additional training must be scheduled.

Such complications require patience and flexibility by the state and a willingness to accommodate the concerns of local elections officials, adapt to delays and set a new schedule. Nevada’s secretary of state, one of the most recent offices working to complete a top-down project, has laudably adjusted its completion schedule to take into account and accommodate the critical needs of local election officials, including an unusually high turnover in county elections personnel, requests by county personnel for more training, and additional time needed for its vendor to fix bugs revealed by user acceptance testing and a mock election.

In a March 18, 2024 letter to the secretary of state, the Nevada Association of County Clerks and Elections Officials reasonably requested that the go-live date for the state’s new Voter Registration Management System (VREMS) system be delayed from April 1 to July. This would move the go-live date to after the state’s June primary election allowing for clerks to be confident that the vendor, KnowInk, would be able to correct any bugs in the system prior to a major election date.

“We thank you for your acknowledgement and sensitivity to the many statutory requirements of our elected positions and the limited resources of our offices. We have been working closely with your Elections Division and the vendor team to develop, test, and roll-out an enterprise software project of the scope and significance of VREMS, and it has not been easy. Through the project many of us have struggled to meet both the daily demands of our Elected Offices and the workload required by the project. We would not have been able to make the progress we have if not for the leadership and generous support of your team,” the clerks’ letter stated.

The mock election using the new system unleashed a “shock to the system,” according to Nevada Elections Director Mark Wlashin. It spurred local elections officials to request additional training and revealed systemic problems that the vendor must fix. The secretary of state acknowledged the clerks’ concerns and agreed to a new schedule, which sets July 31, 2024 as a new go-live date. The delay should accommodate the needed fixes and additional testing needed to use the new system for the 2024 presidential election, according to Wlashin.

Nevada is just the latest state to experience delays that seem inevitable for big voter registration system projects. Another state, Oregon, also delayed implementation of a new system. The secretary of state’s $7.4 million project to replace its aging top-down system also experienced delays and similar issues. Oregon officials used a web page devoted to public information about the status of their project to explain that in September 2023 they decided to delay going live until the first quarter of 2025.

Conclusion/Recommendations:

Building a top-down, statewide voter registration and elections management system is likely to be the biggest and most high-profile information technology project ever attempted by a state’s chief elections official. Management by secretaries of state or state boards of elections will be closely scrutinized by the public, legislators, and local elections officials. But chief elections officials today have an advantage over those that attempted such projects immediately after the passage of HAVA. They can learn from the experiences of others that went before them, which are embodied in the following recommendations.

Based on the experiences of Nevada and other states, the following are recommendations for increasing the odds of successfully completing a statewide, top-down, voter registration and elections management system:

1. Thorough project planning is essential. Successful planning before technical work begins is key to minimizing delays and managing costs. The planning process outlined earlier in this memo is recommended.
2. Transparency builds confidence in the project. Posting public reports on the progress of the project, including risk assessments, by a quality assurance monitor will provide early warnings of possible problems and build confidence in the project management. In addition, posting information online about the progress of the project can also build confidence. Oregon recently built a new top-down system to replace the system it completed in 2005 and posted comprehensive information on the secretary of state’s website.
3. Flexible time frames may be required. Unanticipated problems could force project delays (Example: High turnover rates in local elections offices.) Deadlines should be adjusted if project goals have not been met.
4. Conduct thorough, well-documented, user acceptance testing and mock elections. UAT and mock elections must be well-planned in advance with participation by the vendor and state and local elections officials. The state, not the vendor, should produce test scripts for use by testers. The state’s project manager should oversee the process and designate, if necessary, a testing manager. If testing reveals functionality problems with the system, delays in implementation should be considered.