Exactly. I do apologize to them for that.
Thank you very much for indulging me and not making me send you notes.
I'm going to talk about five specific points around the remote voting solution we built for the Commons and are now putting in place for the Lords. At the end, I guess you can ask me questions, as you wish.
The first area is the rationale for the approach we took. Obviously, there are a lot of solutions out there in the marketplace that deliver voting for various different mechanisms. However, we decided to build it in-house as a bespoke development for two reasons. One was around building on software that we already had. Our voting solution in both Houses is already electronic, to the point where it's recorded on tablet devices and collated at the end of the division. The results are published to our website and in Hansard and other such places. We wanted to make sure we built on top of what we already had.
We also wanted to make sure that what we were delivering was familiar to House staff. Obviously, they have a lot of change, a huge amount of change, going on. It's a completely new world for them. Trying to keep some familiarity for them was important.
Equally as important was some familiarity for members. On the Commons site, we have a system for members, called “MemberHub”, which members have had for about three years now. It is used for tabling oral and written questions and for signing motions. Again, it was logical to us that at a time of immense change, when members were working in a completely different way and were obviously under a lot of pressure, we would keep something familiar for them as well.
That's why we didn't go off and try to buy a completely different product off the shelf and customize it. We wanted to build on top of what we had now so that we knew it would work. The integrations would work and take minimal effort for those who have to look after them. As well, members wouldn't be asked to learn another set of log-ins, or have to log in to a different system that worked or behaved in a slightly different way from other things that they were used to. That was the reason we went down that path.
Next, for those who are interested, everything is built on a Microsoft technology stack. It's Microsoft .NET with SQL server databases behind it. Everything communicates over straightforward Internet protocols, but everything is secure. It's all https—the thing with a little padlock, for those of you who are familiar with using a web browser—but everything is secure and sent over the Internet and then web traffic so we can control the pipeline we're operating the system over.
We built the system, which took us about four weeks from beginning to end. We were asked by the Clerk of the House to put together a solution on April 6, and I think the first vote was pretty much five weeks after that. We rolled it out for live testing pretty much four weeks to the day from the day we were asked to start building it. We were asked to start building it before it had been formally agreed, obviously, by the procedure committee, because we wouldn't have wanted to wait until the House was ready. They'd have asked us for a solution, to which we'd have said we needed another four weeks to build it. We wanted the House to be able to use it once they decided they wanted it.
We went through the build process. Whilst we were building it, we were running it and testing it internally first, with our own staff pretending to be members. Then we did a number of demonstrations to various members across various committees. Ms. Bradley and her committee had a demonstration. Some members of the administration committee had a demonstration, as did the leader of the House and the chief whip. So a number of the sort of.... I'll say the wrong thing now and say the “key stakeholders”, but the sort of key stakeholders have been making recommendations about how this should go forward. We're all taking them through the system so that they understand it.
As part of that, we took on board quite a lot of feedback as well. There were ideas which at the beginning sounded very sensible, but it was logical to ask the technical people who were building it about, for example, the ability to let members change their vote during the division. Within a 15-minute window for a division that took place, if a member made a mistake, they could go back and correct it. Having run through this process and received feedback from those who administer this and would have to work with it, we were asked to take that away and instead move to a process of double confirmation, i.e., “Please cast your vote. Are you sure this is the vote you wish to cast?” After that, the vote is locked in. Obviously, that's in line with how it works in the real world. There were lots of little pieces of feedback like that.
The main information that came back—I'm sure you want to ask about this yourselves—was around security. I didn't talk about it too much at the beginning. We have a single sign-on process for members to log in to their parliamentary accounts, to log in to their emails and to log in to their laptops, always with the same password. We built a system with that in mind, so we have the same password, and we have a multifactorial authentication process to double-check that they are who they say they are.
From the point of view of security, it's pretty much the same as you would use for online banking. It's the same concept as that. You have to have your password and a device with a number that you type into the system to confirm it's you.
Once we'd finished the testing, we had to roll the system out. We had two systems in place already, as I say, one for recording the votes and one for the members to interact with. That was rolled out onto those two platforms, and then we ran a second test. This time members took part in pretend divisions on key and interesting questions like, “Does one put tea in the cup before the milk?” and such vital questions of the day, just to engage people. We kept it very non-political because we didn't want to bring anything political around the voting system. That's a completely separate thing, so we wanted to keep it very stand-alone.
Those tests highlighted some issues, as I'm sure we'd expect them to. There were two issues we came up with. The first one was around the performance of the system. A lot of the feedback we had then was, “Well, I can't believe that with 650 MPs you could have a performance problem in your system.”
Because of the way the House works, however, and the many rules and processes around divisions, what's actually going on behind the scenes are a lot of checks to make sure the division is active, that it hasn't been stopped and that the member hasn't voted on another device. There are lots of things going on behind the scenes to ensure the security of the vote taking place. A lot is going on actually when 600 people are logging in. The first time we tried it, the system slowed down quite a lot, so we did a lot of work to improve that.
The second issue we had was around security. We had over-secured our network, and members who were using their parliamentary devices supplied by the digital service were able to vote in our test divisions without any problems, but those who were using their personal devices were being blocked. Basically, our network was responding with, “We don't recognize this device. Go away.”
Again, the reason for doing all that testing up front was to learn all of that and correct all of that before the first live division happened. Once that was all done, we rolled out live divisions, and then the House voted, I think, 10 or 11 times in the first couple of weeks of using it.