The Electoral Commission

A new system for Party Registration and Finance.

Incomplete applications

8
Incomplete applications
6 SME, 2 large

Completed applications

6
Completed applications
5 SME, 1 large
Important dates
Opportunity attribute name Opportunity attribute value
Published Monday 20 November 2017
Deadline for asking questions Monday 27 November 2017 at 11:59pm GMT
Closing date for applications Monday 4 December 2017 at 11:59pm GMT

Overview

Overview
Opportunity attribute name Opportunity attribute value
Summary of the work To provide a new system for handling political party finance and registration compliant with all statutory obligations, using agile methodology. The system will go live by April 2019. The contractor will need to ensure a smooth transition from the previous system.
Latest start date Tuesday 3 April 2018
Expected contract length Anticipated one year; expect to tender support contract from April 2019
Location London
Organisation the work is for The Electoral Commission
Budget range Based on our earlier market engagement our initial starting estimate of the budget range for this work is around £200k - £240k including all development and the first year platform costs.

About the work

About the work
Opportunity attribute name Opportunity attribute value
Why the work is being done The existing system for party registration and finance is at the end of its life and user expectations have evolved. We need a new system which makes it easier for users to register parties, etc. and submit financial information. Transparency is important: the new system will need to be able to make registers and financial information publicly available in line with statute, produce a range of reports and be easy to search. We are looking for both a platform and a new system, and bids will need to cover both whether from one supplier or joint suppliers.
Problem to be solved The new system must make registration and uploading of financial information simple and quick, interfacing with parties’ and others’ own systems, removing manual data exchange and being easy to update. It also needs to facilitate communication with parties. Registration and financial data must be publicly available in line with statute. A reporting function is required. The transition from the current system and consequent data migration will need to be managed. Suppliers will be asked to quote both for updating the search system as part of development and for excluding it at this stage but with a view to later integration.
Who the users are and what they need to do As regulators staff at the Commission need to check that finance and registration rules are being obeyed and respond to internal and external queries so that the Commission can have confidence in processes and data quality;
As customers political parties, non-party campaigners and referendum campaigners need to upload and update information so that they can demonstrate compliance with electoral law;
As electoral administrators Returning Officers need information from the system so that they can ensure accurate ballot papers;
As commentators academics, journalists and others who analyse the information need transparent access so that they can comment on the electoral process.
Early market engagement The Commission carried out early market engagement with a range of providers to see whether latest developments in platform technology and system design could deliver what was needed. It commissioned a proof of concept from one developer. And it drew on the expertise of peer reviewers from elsewhere in the public sector. The conclusion was that there was a range of suppliers able to offer cutting-edge expertise; that a platform-based low-code/no code solution was capable of delivering results; that major improvements in efficiency and usability could be achieved; and that other organisations had successfully followed a similar approach.
Any work that’s already been done A business analyst has carried out an initial discovery phase with both internal and external stakeholders, generating around 200 user stories and a headline statement of requirements. The supplier of the previous system also carried out discovery work from the perspective of improvements which could be made to it.
Existing team A Project Manager is in place. A team of business users and ICT specialists will be in place at the start of development. External stakeholders have been approached and are willing to participate in a user group to support agile development.
Current phase Discovery

Work setup

Work setup
Opportunity attribute name Opportunity attribute value
Address where the work will take place 3, Bunhill Row, Moorgate, London EC1Y 8YZ
Working arrangements The developer will need to spend significant time in Bunhill Row collocated with business users as well as with staff and stakeholders outside London and in the devolved administrations. A degree of remote working can be accommodated, but the majority of time will need to be in London.
Security clearance Normal basic Cabinet Office clearance. In addition suppliers must declare explicitly any current or previous political affiliation and/or activity which could be seen to support any political campaign by the supplier, owner, Board or other connected entity

Additional information

Additional information
Opportunity attribute name Opportunity attribute value
Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Skills and experience
Opportunity attribute name Opportunity attribute value
Essential skills and experience
  • Have proven experience and track record of designing similar systems
  • Good understanding of agile development
  • Have experience with users of a range of digital ability
  • Know how to integrate systems across boundaries
  • Be up to date with technological developments
  • Have robust security and UK based data centre for platform
  • Demonstrate proven platform availability of 99%
  • Show flexibility to allow ongoing agile platform development
  • Facilitate platform development by in-house technical team
  • Provide on-going platform development
Nice-to-have skills and experience
  • Show experience of working with public sector clients
  • Show experience of working in a regulatory environment

How suppliers will be evaluated

How suppliers will be evaluated
Opportunity attribute name Opportunity attribute value
How many suppliers to evaluate 10
Proposal criteria
  • Proposed technical solution
  • Proposed approach and methodology
  • How the solution and approach fit our business goals
  • How well the solution and approach reflect user needs
  • Value for money
  • Estimated timeframes
  • Identification and management of risk
  • Identification and management of dependencies
  • Team structure
Cultural fit criteria
  • Show ability to work as a team with our organisation and other suppliers
  • Evidence transparent and collaborative decision making
  • Demonstrate a no blame culture focusing on learning lessons
  • Take responsibility for work
  • Share knowledge and experience, with emphasis on skill building
  • Challenge status quo and offer suggested improvements
  • Be comfortable standing up for discipline
  • Able to work with clients with low technical expertise
  • Able to appreciate the regulatory environment in which the Commission functions
  • Appreciation of risk in a regulatory environment
Payment approach Fixed price
Assessment methods
  • Written proposal
  • Case study
  • Work history
  • Reference
  • Presentation
Evaluation weighting

Technical competence

50%

Cultural fit

10%

Price

40%

Questions asked by suppliers

Questions asked by suppliers
Supplier question Buyer answer
1. Is the initial estimate envisaged to cover a Minimum Viable Product (sufficient features to give some value to the end users rather than an expectation that the full business process is covered) or should it be assumed that enough features need to be developed to fully decommission the existing system within this budget? It should be assumed that enough features need to be developed to provide a fully functioning system and decommission the existing system.
2. If it is found early on that the initial budget of £200,000 - £240,000 is below that required to achieve the level of features required, is there scope to increase the budget? or can the feature sets be phased over multiple years or limited and still deliver benefit? Quality is important to us and there is scope for negotiation.
3. The payment approach is Fixed Price. Will price be evaluated based on cost per sprint, blended rate of individuals, price per story, or will a bottom line total cost be required? We are looking for a total cost but would like to understand as a minimum:
- The price per team member per day and mix of skill levels
- Cost per spring and predicted profile
- Overheads
4. What were the key risks identified during discovery? The key risks identified during initial scoping are:
- System failing to meet statutory requirements
- System failing to command stakeholder buy-in
- Unscheduled electoral events which may impact on delivery
- Legal changes to requirements
5. Will the system require a formal GDS assessment? The system will be developed using GDS methodology. However the Electoral Commission is independent of Government and therefore no formal GDS assessment will be required.
6. Is there a hard date by which the existing system needs to be decommissioned? We aim to decommission the existing system by March 2019.
7. Is it envisaged that the existing system and new system run in parallel for a significant period of time, with a need for live data exchange, or is a one off data migration and cutover expected? We intend to switch off the existing system in March 2019, so there would be a period of parallel running. We do not however currently envisage a need for live data exchange; we expect to phase the transfer of data on an agreed basis.
8. The "problem to be solved" statement indicates that transition and migration from the existing system needs to be managed. Is this purely a "management" task with another supplier providing the technical resource, or should this tender account for all tasks associated with migration (analysis of existing date, performing data cleansing, transformation processes, gap analysis and agreement of what cannot be migrated, validation and testing etc.)? The supplier will need to provide the technical framework within which these tasks will take place so that they can be automated as far as possible.
9. The "problem to be solved" statement indicates that the new system needs to interface with parties' and others' own systems. How many parties is the system required to interface with and do all parties use a common platform/data format, or are they bespoke for each party? The new system should as far as possible allow the secure exchange of information with the systems of all major parties represented in Parliament and the devolved administrations. These platforms do not use a common data format and are bespoke to each party.
10. In terms of the project working location, you talk about one developer: is that so? Or a team is required from supplier? We expect proposals for a team, not a single developer.
11. You reference a "developer" throughout the outcome - are you looking for a specific skill set with just one developer or are you looking for a team/supplier as an "outcome" would suggest? Do you have an incumbent supplier in place currently? Will they be applying for this opportunity? We expect proposals for a team, not a single developer. As this is a new system there is no incumbent supplier in place.
12. For the question "Know how to integrate systems across boundaries", we would appreciate if you could clarify the boundaries the Authority are looking for: is it security, departmental, geographical or others? The new system will need to be able to exchange information with and download/upload information from reporting systems run by individual political parties in line with the statutory obligations on both sides. Secure exchange of information is crucial.
13. "Able to offer cutting-edge expertise; that a platform-based low code/no code solution was capable of delivering results". Can you confirm the preferred low-code product selection based on your initial evaluation? We do not have a preferred option. We are keen to see what potential approaches tenderers suggest.
14. Under "Budget Range" you write: "Based on our earlier market engagement, our initial starting estimate of the budget range for this work is around £200k-240k including all development and the first year platform costs". To produce an accurate estimate you would have shared the desired scope/functionality of the system with the company who worked on the "earlier market engagement". Please can you share this with us to ensure a level playing field. Thanks. We asked for a proof of concept of low code as part of initial market engagement, choosing one small part of the system as an example. We explained the role of the Commission, which is set out in publicly available material. The list of functions we included is set out in the attached link. User requirements were then gathered to inform the development of the relevant section of the system.

https://www.electoralcommission.org.uk/__data/assets/pdf_file/0006/237966/Requirements-to-register-online.pdf
15. The budget ranges state the budget is based on your early market engagement. Does this imply that the budget is based on sharing the desired scope/functionality of the system with them? If yes, could you share this at this stage to ensure a level playing field for organisations that were not invited to participate at the earlier stage? We asked for a proof of concept for low code as part of initial market engagement, choosing one small part of the system as an example. We explained the role of the Commission, which is set out in publicly available material. The list of functions we included is set out in the attached link. User requirements were then gathered to inform the development of the relevant section of the platform.

https://www.electoralcommission.org.uk/__data/assets/pdf_file/0006/237966/Requirements-to-register-online.pdf
16. You have stated that your discovery has generated 200 user stories. In order to understand your budget analysis, this would imply that you believe that on average each story will cost between £1000 and £1200 to deliver through Alpha, Beta and then operate and support for 1 year in live. Can you confirm this is your understanding and, if not, what our bid/planning assumption should be? The costings were based on internal mechanisms and not related to the number or complexity of user stories. They do not therefore provide a basis for a planning assumption.
17. Can we use the initial discovery work and the 200 user stories to size the work required for the project? The initial discovery work and 200 stories were designed for early stage user research and not as a definitive list of requirements. The developer will therefore need to include a full discovery phase in their proposals.
18. How much data, file, media needs to be migrated to the new system and what is the size of the existing systems database and file system? The databases are the following:
Systems databases:
Master: 6.63MB
Model: 5.06MB
MSCB: 113.63MB
TempDB 432.81MB

Main production database: 36092.88MB
19. Does this project fall inside or outside IR35 ruling? We expect to receive proposals for a team rather than from sole contractors, and to contract with an organisation which supplies a team on standard commercial terms. So in those circumstances we would not envisage that IR35 would come into play.
20. Low Code platforms are vendor specific and solutions cannot be migrated between providers. Who will hold the risk in the event the chosen platform is discontinued? We will expect shortlisted suppliers to explain their future plans for their platforms. The contractor will be expected to agree an exit strategy as part of planning the project, and to supply relevant documentation accordingly.
21. Please advise on total number of Electoral Commission administrators needed to access the system? Currently there are 5 Commission system administrators. Outside the Commission there are only party administrators who can set up users within their own party. There are currently 353 of these. It should be borne in mind however that these numbers can shift and that the system will need to build in sufficient capacity accordingly.
22. Does historic data/audit etc need to be migrated and are there any historic legislative rules or other logic that needs to be implemented in order to be able to represent data correctly according to its interpretation at that point in time? Thanks. Data will need to be migrated from the existing system. The Commission has a statutory duty to hold information in a transparent and robust way, and to maintain a clear audit trail.
23. Can you clarify your expectation of onsite work required? Would a remote team that spends 2 to 3 days in the office be acceptable and would expenses be chargeable over the budget prescribed? We are open to negotiation over exact working arrangements and a remote team spending some time in the office would be entirely acceptable; we would expect the contractor to cover these costs. We would however cover expenses of travel and subsistence which we specifically asked the contractor to incur subject to the Commission's normal rules.
24. Please advise on total number of Electoral Commission users needed to access the system? Currently about 60. It should be borne in mind however that numbers may change to meet evolving business need and that the system will need to build in sufficient capacity accordingly.
25. Could the Authority please clarify if they have a preference or have established the technologies and platform required to deliver the required service? Could the supplier provide recommendations to meet the objectives of the proposed service? We do not have a starting preference on technology or platform, and would expect the supplier to provide recommendations.
26. Would you require any accessibility standards like WCAG 2.0 level AA to be adhered to? A is our minimum standard and AA our preference.
27. Has the discovery phase recommended a technology to be used? or are there any preferences within Electoral Commission developers for technology? The initial user research has not recommended a specific technology and the Commission has no starting preference. We expect the supplier to provide recommendations.
28. Is there a Requirement Specification document using which we can estimate the effort and cost? Can the output documents and the 200 user stories of the discovery phase be shared with us? A Scope of Requirements will be made available to shortlisted suppliers. The initial discovery work and 200 stories were designed for early stage user research and not as a definitive list of requirements. The developer will need to include a full discovery phase in their proposals.
29. Do you have a preferred low-technology platform? You mention a low/no code approach - what's driving this and what are the nature of the changes you expect to have done by non-technical users? Has the developer who did the proof of concept been asked to tender for this opportunity? We do not have a preferred platform. The attraction of a low code approach is that it has the potential to make the system easier to maintain. However we are keen to see recommendations from suppliers on the options most likely to deliver our goals. This opportunity has been advertised on the Digital Market Place and we have not approached any developer to tender for it.
30. Does the budget include potential application licensing cost? The budget given is a range and there is scope for negotiation.