dynamoo.com home

 
Site navigation

home
blog
technical
diary
webmaster
orange book
moobiles
shop
contact
links
  
Updated
May 2007

   Dynamoo 2007

 

 

 

Bedford Elections 2007 and the electronic counting fiasco

7th May 2007

Electronic counting is a pretty new thing when it comes to British elections, and at 10am May 4th 2007 the town of Bedford took part in a trial to use an electronic counting system sourced from Indra of Spain.

The counting process is reasonable straightforward in principle - paper votes are scanned and then verified. Any papers that are questionable go to level one adjudication. Anything that needs further adjudication goes to a second level adjudication process nominally controlled by the returning officer. Ballots which have been verified are then counted and the system automatically tallies the result.

 Simplified Counting Process

There were three elections taking place on the same day: the election for Mayor of Bedford, a number of elections for Borough Councillors and also some Parish Council elections. There were a number of different voting systems in use: a limited form of STV (single transferable vote) for the Mayor, first-past-the-post with a single member returned for most Borough Council elections and first-past-the-most with multiple members for some Borough Council elections and the Parish Council Elections.

In total, over 80,000 ballot papers would need to be processed. Past experience of manual counts indicated that this would take between four and six hours. However, in the end the electronic counting system took a staggering 16 hours to deduce the final result.

Before I start to examine some of the flaws of the Indra supplied counting system, I would like to make it clear that the Borough Council staff processing the count worked extremely hard and I do not hold them responsible for the problems that occurred.

Scanning

The problems began early on in the process. There were around half a dozen scanners to scan 80,000+ papers. Although the scanners should have been able to "feed" the ballot papers quickly enough this process fell apart early on.

The initial problem was that some of the ballot papers had glue along the top and these did not go through the scanners. Somebody managed to find a pair of scissors in order to "trim" the ballot papers but this still led to delays. Productivity improved significantly when a second pair of scissors were found.

Also many ballot papers had been incorrectly torn off at the polling stations due to problems with the perforations. Although these passed through the scanners correctly, they were mis-scanned later in the process.

Although only one ballot paper was meant to be scanned at a time, there were some cases in which up to three ballot papers were picked up at once. In these cases, only the "top" vote was counted and the rest was lost. It is not known how many papers fall into this category.

First Level Verification

The verification process was meant to examine each ballot paper for a valid vote and then move it along to the "counting" stage if valid, else this was passed to first level adjudication. Initially 10 stations (laptop computers) were used for this process. However, a very high level referrals meant that these stations became overwhelmed with around 30% of all ballots being referred to the adjudicators - which is about 24,000 papers split between 10 stations. It has been reported that 17,000 of these votes were for the Mayoral election.

Apart from ballots that genuinely required adjudication (e.g. spoiled ballots, incorrect voting etc) the system could not reliably differentiate between the "1" and "2" votes written on the Mayoral ballot papers ("1" is for first preference, "2" for second). The computer system repeatedly failed to confuse "1"s written with serifs for "2"s.

 1 = 2?

Although voters were told to write "1" or "2" only on the paper, no guidance was given on how to write the numbers for the benefit of the OCR system. Also, many thousands of voters used a traditional "X" instead of a "1" or "2" which is still counted as a valid first preference vote.. although the computer system did not understand this and it referred all such votes to first level adjudication.

Although the Mayoral count was more complex because of the first/second preference voting, a human counter would easily be able to cope with "X"s on the ballot.

Overall, far too many ballots were referred to first level adjudication due the way the computer system was designed. For most of the 16 hours of the count, the people operating the first level verification computers were swamped.

The work was very difficult for the human operators as there were three different voting systems in use on that date and the ballot papers were coming through more-or-less in a random order. This meant that the adjudicators continually had to adjust their "mind set" depending on which paper they were looking at.

Returning Officer Verification

At the start of the counting process, three stations were set up as "second level adjudication". These were meant to be for any ballots referred from the first level adjudicators. It soon became apparent that all three stations were displaying exactly the same ballot paper, rather than three different ones. As a result, the "second level adjudication" stations were reduced from three to just one.

Nominally, second level adjudication is the responsibility of the returning officer, but in this case it was a nominated employee. In the Indra system the second level adjudication takes place at the RO (Returning Officer) station.

Two types of ballot paper were being referred - the first type were those papers where the determination was unclear and the voter's intention had to be carefully scrutinised in conjunction with the guidance notes that had been issued to both staff and observers beforehand (this was a new thing at this election and was a very good idea). This meant that the papers often had to be looked at closely and discussed with the political agents and/or the returning officer. In some cases there was no precedent or guidance set, so the discussions could take place for some time.

In some cases ballot papers had become folded while scanning and the ballot had to be manually retrieved from storage. In other cases the determination of the voter's intention was hampered by the poor resolution of the scanned image on screen.

The second type of ballot paper referred to the RO station were ballot papers where the serial number could not be determined. This was either due to a misprint (in some cases) or a mis-scan where the scanner could not determine the location of the barcode - this usually happened where the ballot had been incorrectly torn off. It came as a surprise to the observers that the serial number was being recorded alongside the vote as this could be viewed as compromised the secrecy of the secret ballot.

These mis-scanned ballots effectively clogged up the RO station and led to severe delays. Worse still, a flaw in the counting software meant that any ballot with a missing serial number could not be "skipped" and looked at later, and this sometimes held the system up while the paper was located - in one case this took over half an hour when nothing could be processed.

Around 2% of all ballots were referred to the RO station causing significant delays.

Other concerns

With a pure paper-based ballot there is complete transparency in the voting process - each individual ballot can be scrutinised by counting agents working for the candidates. With the scanning system, the vast majority of ballots could never be scrutinised.

There were cases when votes could be seen on the adjudication screen where the papers were stuck together. I personally saw this three times, but it is not known how many other papers went through in this way. In one case three papers were stuck together, but only one vote could be recorded.

In this particular case, the Spanish consultants had arranged to leave with their equipment that night. If the vote hadn't been completed on the Friday then it would have to be recounted again manually the next week. In order to get the count done, staff worked from 10am on Friday morning to almost 2am on Saturday with very few breaks. In addition, the building where the count was taking place had been booked for a wedding the next day so the count could not over-run.

Insufficient monitoring of the count's progress was taking place. One good feature of the Indra counting system was that the full statistics of the count could be observed, including the rate of progress and number of ballots in the queue. It became clear to most people at an early stage that progress was slow, although the full extent of the backlog did not seem to be realised. This can in part be put down to a lack of familiarity with the new system.

The counting process relied heaving on support from the Spanish company providing the equipment. I cannot believe that this level of support is scalable to large-scale use in the UK.

As stated before, the ever-changing ballots required an incredibly high level of concentration. This was difficult enough as an observer, but for those actually adjudicating this must have been almost impossible. The ballot papers should have been separated before being processed in order to make the task easier.

A minor issue, but an important one to those involved in the process was that the poll results for each election were generated with the candidate with the most votes being read out first, rather than the standard practice of being read out in alphabetical order by surname. This meant that the first name read out was always the winner which rather spoiled one of the few bits of enjoyment to be had out of this process.

Advantages

Despite all the problems, there was one significant advantage with the Indra system: in the Mayoral election, voters had a first and second preference vote. If their first preference is eliminated, then their second preference vote is counted instead. The Indra system coped well with this, and this negated the need for further counting (which would be needed in a paper-based system).

Conclusion

As implemented, the Indra system offered no advantages over the traditional paper-based approach. The lack of flexibility and problems with accuracy let to delays. The low-tech approach offers a great deal of flexibility and scrutiny, whereas the computerised version did not.

It was probably not a good idea to attempt the trial on such a large-scale election with twice the number of ballots as usual. It was only due to the dedication of staff (and presumably the glossing over of workplace health and safety regulations) that allowed the result to be delivered at all.

Certainly, some delays were due to unfamiliarity with the process, however the lack of flexibility is a major disadvantage. I sincerely hope that this system is never used again in the UK in its current form.

Further reading

 

 

 Subj: Shopping and Services

 

 home   technical   diary   webmaster stuff   orange book   shop   contact   links   your privacy