REQUEST FOR PROPOSAL (RFP-13-050)

THIS REQUEST FOR PROPOSAL (RFP) IS THE EXCLUSIVE, CONFIDENTIAL, PROPRIETARY PROPERTY OF THE INTERNATIONAL FOUNDATION FOR ELECTORAL SYSTEMS (IFES). IT MAY NOT BE COPIED, TRANSMITTED, OR DISCLOSED BY ANY MEANS WITHOUT THE EXPRESS WRITTEN CONSENT OF IFES. BY ACCEPTING A COPY HEREOF, RECIPIENT AGREES TO (I) BE BOUND BY THE TERMS AND CONDITIONS CONTAINED HEREIN (INCLUDING BUT NOT LIMITED TO THE CONFIDENTIALITY PROVISONS), (II) USE THE RFP (AND ANY RELATED DOCUMENTS) SOLELY FOR EVALUATION PURPOSES AND FOR RESPONDING TO THIS RFP, AND (III) RETURN OR DESTROY THE RFP (AND ANY RELATED DOCUMENTS) UPON IFESs REQUEST OR UPON YOUR DECISION NOT TO RESPOND TO THIS RFP.

REQUEST FOR PROPOSAL (RFP)

RFP Title: RFP #: Issued on: Proposal Deadline: Kenya Election Results Transmission System (RTS) RFP-13-050 Friday, December 21st 2012 Friday, January 4th 2013, 17:00hrs Nairobi time

I. INTRODUCTION & BACKGROUND

Under the U.S. Agency for International Development (USAID)-funded KEPPS program1, the International Foundation for Electoral Systems (IFES) is providing technical assistance to build the capacity and sustainability of the Independent Electoral and Boundaries Commission (IEBC) to implement their expanded electoral mandate, as well as to the newly created Office of the Registrar of Political Parties (ORPP) as it creates regulations and procedures to fulfil its new mandate. IFES targeted support includes capacity building in the areas of voter registration, voter education, results transmission, oversight of political parties, and the development of a dispute resolution mechanism to facilitate the IEBCs role in conducting transparent, credible, and violence-free elections. In order to assist the IEBC in its preparations for General Elections scheduled for March 4 th 2013, IFES is conducting a number of procurements in relation to the systems and services necessary to deliver Electronic Vote Transmission and presentation. For further information on IFES please see www.ifes.org For further information on IEBC please visit www.iebc.or.ke

Kenya Election And Political Process Strengthening, USAID Associate Cooperative Agreement No. 623-LA-11-00007, under the Leader Cooperative Agreement No. DFD-A-00-08-00350-00

II. PURPOSE
This RFP is aimed at seeking a suitably qualified and experienced software development company to develop, test, deliver, deploy and support a Results Transmission System for the Independent Electoral and Boundaries Commission of Kenya. The RTS is a key component of IEBCs wider Electronic Vote Transmission and Results Management Systems.

III. SCOPE OF WORK & DELIVERABLES

The Commission requires an Electronic Vote Transmission (EVT) System that allows provisional results to be transmitted electronically from all polling stations to the tallying centres where these results are consolidated and reported. The system is intended to work with a GPRS-enabled mobile device that transmits over a Virtual Private Network provided by the local telecommunication network operators. The Electronic Vote Transmission system requires each polling centre reporting the provisional results of six (6) elections to transmit these results to three (3) different Tally Centres across the country. The solution should fully automate the process as required to address the complexity of the expanded scope of multiple elections. Following the counting of ballots and the completion of the official paper forms by IEBC Presiding Officers, a mobile device will be used by each presiding officer to enter the data from those forms into a specially developed application (that is one deliverable of this RFP). This device will securely transmit these provisional results over mobile data network to servers at IEBC for consolidation and publication. The application running on the servers is another deliverable of this RFP. Meanwhile, the paper forms will be moved to the relevant Tally Centres for official consolidation and reporting. On receipt of the paper forms at the relevant Tally Centre, and once approved by the Returning Officer there, IEBC operators will enter the official results data into the RTS system (which functionality is a deliverable of this RFP). At this point, the system will contain both Provisional and Official Results. The RTS at the Tally Centres will allow tabular and basic bar chart reporting of provisional and results data, as well as other relevant management and status reports as required. Results Transmission Procedure The transmission system will be required to authenticate itself to a centralized authentication, authorization and provisioning system; this will in turn give a list of races, their candidates and reporting IP addresses (national level IP addresses, county level IP address and constituency level IP address) to the authenticated and authorized phones. The phones should therefore transmit results for each race to three specified destination IP addresses (the National Tally Centre, the County Tally Centre and the Constituency Tally Centre). The server system should then return a confirmation number for each race that is

successfully transmitted. Retransmission should be made possible after server side authorization. The system should also send a log of all previously attempted yet failed transmission for auditing purposes.

Polling Stations

Tally Centre Presentation **

Constituency Tally Centre

County Tally Centre

National Tally Centre

**basic tabular and **basic tabular and chart reports chart reports

Tally Centre Presentation **

EVT Components

Internet

Results Presentation System*

*digital mapping, *digital mapping, visualization etc visualization etc

RTS TELECOMS RPS

Figure 1 Illustration of the Proposed Workflow for Transmission of Results

The chosen vendor will develop, test, deploy and support: (1) an application that will run on the mobile device provided to each Polling Station (2) the applications that will run on the IEBC servers (3) the applications that will allow IEBC to manage and configure the mobile devices The chosen vendor will also develop and deliver appropriate training of trainers to allow IEBC to train Presiding Officers. The vendor will liaise closely with:

IEBC IFES

IEBCs telecommunications provider IEBCs electoral information presentation and visualization partner (Google)

The selected vendor will NOT be required to deliver: (1) Any hardware other than that used for training, testing and support. (2) GPRS/EDGE/3G connectivity this will be procured separately. However, close interoperability between the chosen vendor and IEBCs Telecoms provider is essential. (3) Results presentation or visualization or mapping functionality. Only numerical reporting (tabular reports, across multiple levels (polling station, county assembly ward, constituency, county, national) is required from the solution being procured under this RFP. The project requires the management of electoral results for all the major elections conducted by IEBC. The objectives of the project are to obtain a high availability and secure system that: Provides the commission with a modern automated solution of managing results Provides transparency in relaying of results to the public Is able to do Fast, accurate and efficient tabulation and tallying of results The project involves the IEBC, the transmission software developers and the mobile services providers. The mobile service provider will provide a Virtual Private Networks (VPN) within the existing GSM/GPRS/3G network and configured on the mobile phones SIM cards. The software should be able to report the results for the six elections (Presidential, Governor, Senator, Women Rep, National Assembly Rep. and the County assembly ward rep) carried out in 47 counties, 290 constituencies and 1,450 Wards when transmitted from more than 25,000 polling stations.

The project must ensure that proper training of all stakeholders (political parties, development partners and the Public) is carried out to get acceptance and understanding of the system.

The IEBC has, since 2010 implemented an EVT system. That system has several limitations: i. Scope the original EVT system was not designed for the expanded number of elections under the Constitution and is limited to transmitting results to only two tallying centres (National and Constituency) instead of the three (National, Constituency and County)

ii. User Interface - the original EVT system has a poor user interface that requires a sender to perform several confirmations in order to transmit results. The data entry interface makes it difficult to correct wrong entries. It does not provide device data validation or integrity checks. iii. Security the original EVT system does not provide data encryption on the phone interface but relies on the security provided by the mobile service providers VPN. iv. In addition to this, the original EVT system does not authenticate or authorize users/presiding officers who utilize the mobile system. The network operators VPN security should provide a second level of security, in a multi-tier security framework. v. User security the original EVT system does not provide application-level user authentication. vi. Feedback while the original EVT system notifies the user of successful sending, it fails to send a confirmation of successful receipt. vii. Multiple deployments the original EVT system requires multiple deployments of the same software to be carried out since data of candidates and destination servers is embedded into the installation and thus requires a separate installation for each ward. viii. Poor integration with digital maps. ix. The current system does not support satellite phone platforms and there are many polling centres that do not have mobile telephony network coverage. This RFP specifies a system that overcomes these deficiencies. Note that the integration with digital maps has been removed from RTS. IEBC will collaborate with Google in order to achieve widespread dissemination of results data. For an example of IEBC-Google collaboration on the visualization of Voter Registration location data, please visit http://vote.iebc.or.ke

IV. FUNCTIONAL SPECIFICATIONS OF DESIRED SYSTEM

Application Security The application should comply with the ISO IEC 17799 and ISO 27001/27002 standards on Access Control and the use of both authentication and authorization. 1. The application should have a users security management module that shall enable for creation, activation, deactivation, transfers and management of users permissions and rights both at the central and regional levels. 2. Users will identify themselves using parameters that include but are not limited to: i. Phone IMEI ii. Device IP Address iii. Username

3.

4. 5. 6.

iv. Password v. Polling Station The IMEI Number and the Device IP address will be used to authenticate devices to the central system based on a white list maintained at the central database at the Headquarters. The application should have the ability to use strong encryption and also digitally sign all data transmitted. No data will be transmitted in clear text. The central administration of these certificates should make it possible for administrators to revoke certificates on rogue mobile devices. The system should in collaboration with the security provided by network providers provide multi-level security.

User Interface The Application should comply with the ergonomics and basic principles of human centered design for interactive systems as defined by ISO 9241. This will enhance usability, familiarity, effective usage of the system, and thus enhancing user satisfaction and system acceptance. 1. In general, the application should demonstrate the following features: The system should have visibility and legibility of menus, text and graphics, The interface actions and elements should be consistent. Error messages should explain how to recover from the error. Undo should be available for most actions. Actions which cannot be undone should ask for confirmation. The screen layout and color should be appealing. It should be easy for the user to use the navigation keys on the phone to navigate. The user documentation and help should be complete. The help should be context sensitive and explain how to achieve common tasks. The system should be easy to use, navigate and learn. The system should be customizable to meet specific user needs. 2. The screen of the application should be laid out in the manner illustrated in Appendix 2. Data Entry The general objectives of designing data entry functions is to establish consistency of data entry transactions, minimize input actions and memory load on the user, ensure compatibility of data entry with data display, and provide flexibility of user control of data entry. The following requirements on data entry should be satisfied in the proposed solution. 1. The candidates list should be presented in alphabetical order of surnames i.e. in the same order candidates appear in the ballot paper. 2. The data entry screen should be simplified and optimized for data entry of 40-50 candidates per race and also allow for easy correction of wrong entries in a fast

3.

4. 5. 6. 7.

8.

manner. The application should enable capturing and transmission of the following information per race and. a. Total number of valid votes per candidate b. Total Number of spoilt votes c. Total number of rejected votes d. Total Number of rejections objected to Enable acknowledgement of completion of a data entry transaction with a confirmation message, if data entry was successful, or else with an error message. Enable easy navigation from one race to the next after completion of a data entry transaction. The system should display a message before sending data for user confirmation and also a confirmation message for successfully transmitted results. The application should provide 2 levels of validation namely: Candidate level validation that ensures only positive numbers are accepted (Negative Numbers should not be accepted). Race level validation that ensures the total turnout does not exceed the registered voters in that particular polling station. The system should also keep a log of exceptions generated (attempts to send turnouts that are above the number of voters registered at polling centre) e.t.c. to improve on transparency.

Results Transmission Presiding officer The transmission device and user will be required to authenticate to a centralized authentication, authorization and provisioning system; this will in turn give a list of races, their candidates and reporting IP addresses (national level IP addresses, county level IP address and constituency level IP address) to the authenticated and authorized phones. The phones should therefore transmit results for each race to a specified destination IP address. The server system should then return a confirmation number for each race that is successfully transmitted. Re-transmission should be made possible after server side authorization. The system should also send a log of all previously attempted yet failed transmission for auditing purposes. The results transmission mechanisms implemented in the proposed solution must enable the following; 1. Transmission of results should be enabled only after fully authentication and authorization of the devices and users. 2. Data should be transmitted only in an encrypted form and digitally signed. 3. Enable simultaneous transmission of results to the constituency tally centre, county tally centre and the national tally centre. 4. Enable both offline saving of results and allow for re-transmission of results when

network becomes available. 5. A confirmation message should be sent from the receiving station to the sending station upon receipt of results. 6. The system should have configurable time restrictions before which results cannot be accepted to prevent sending of results before polling stations have been closed.

Results verification - Returning Officer Upon receipt of provisional results from the polling station together with the documentation and signed copies of the relevant forms, the returning officer shall verify and enter the final results into a web based version that will be synchronized with the central database.

Other requirements 1. The software should provide immutable logs for ensuring a strong auditing process of the reported results. 2. The software should not only be tamper-proof but also tamper- evident logs of attacks will need to be kept.

INTERFACE WITH EXTERNAL SYSTEMS Import requirements 1. The system will interface with the candidate nomination system. The candidate nomination system will produce the boundary data (counties, constituencies, wards, polling stations, each with names and codes) the six races o Presidential o Governor, o Senator , o Women representative o National Assembly representative (Member of Parliament) o County Assembly Ward representative the candidates for the above positions (names, sponsorship (party, independent), symbol) 2. This data should be available to the results transmission system as soon as IEBC has certified the nominations once the data has been released for ballot paper production, i.e. late January 2013. 3. The RTS system should ensure that changes in the candidate nomination system data can be quickly reflected in the EVT system.

IMPORT SCHEMA The system will be required to import data from a nomination system that represents entities in the following manner.

All Primary and foreign keys are 36 byte Global unique identifiers (GUIDs, UUIDs). The relationship between all the entities is illustrated using the foreign keys (dashed lines). The link between the Races entity and the Locations (county, constituency and wards) in which offices are going to be competed for in is represented using the EntityID and entitytype fields. The type of race is denoted by racetype field. The EntityID contains the unique identifier (primary key) of the Location and the entitytype denotes the type of Location it is. For presidency the EntityID is always null. The nomination system represents the Entitytype using the following enumeration National = 5, Region = 4, County = 3, Constituency = 2, Ward = 1 The racetype is defined using the following enumeration Presidential = 1, Governor = 2, Senator = 3, NationalAssembly = 4, WomenRepresentative = 5, CountyAssemblyRepresentative = 6, Referendum = 7 The candidate status is represented using the following enumeration Deleted = 6, Deceased = 5, Nominated = 4, Disqualified = 3, Withdrawn = 2, Pending = 1, Registered = 0

Independent candidates are flagged as independent as opposed to them being in a party called independent For a complete schema for the candidate nominations system, please see Appendix 1 Database Schema - Nominations System ATTACHED
AS PDF

Export requirements The system should enable exporting of data to other systems e.g. Results Presentation System (RPS) for visualization and for external reporting. The system will need to specify the output format enabling third party software to present and visualize the data captured. A data dictionary should document all the fields used to store this data. A push mechanism should be enabled that may push data as soon as availed to subscribed services using open data formats, this will include a feed to media houses, an API for app developers and the election day result display system e.t.c. The system will forward the Races, Candidates, Parties, locations (Regions, Counties, Constituencies, Wards and Polling stations) will be forwarded to the visualization system as visualized above via CSV. The results will be PUSHED to the results visualization system as soon as they are available using JSON. A sample result for a certain race from a certain polling station will be as illustrated below [ { "PollingCentreID": "d014a4fa-12d3-11e2-a853-00ff98e4ecf6", "PollingCentreName": "Nakuru High School", "raceID": "18110e72-13d1-11e2-9b34-00ff98e4ecf6", "Disputed": 34, "Rejected": 20,

12

"Spoilt": 40, "results": [ { "CandidateID": "156918f6-14c3-11e2-9b34-00ff98e4ecf6", "votes": 300 }, { "CandidateID": "fe6352ad-14c2-11e2-9b34-00ff98e4ecf6", "votes": 380 }, { "CandidateID": "6104dca0-14c3-11e2-9b34-00ff98e4ecf6", "votes": 500 }, { "CandidateID": "084708fd-13d2-11e2-9b34-00ff98e4ecf6", "votes": 400 } ]

Other requirements include; 1. The system will need to specify the output format enabling third party software to present and visualize the data captured. 2. A data dictionary should document all the fields used to store this data. 3. A push mechanism should be enabled that may push data as soon as availed to subscribed services using open data formats, this will include a feed to media houses, an API for app developers and the election day result display system e.t.c.

13

MANAGEMENT REPORTS
The system should provide management and analytical reports for internal use within the commission. This should include but not limited to the following;

1. 2. 3. 4. 5.

Summary of results received Summary of results verified Constituency tally results County tally results National tally results

A.

PART I: DATA ENTRY AND TRANSMISSION APPLICATION

DEVICE REQUIREMENTS
Mobile Device primary platform for RTS The IEBC has in the region of twenty thousand Nokia 1680 Classic phone. This will be the primary platform for the mobile application being procured in this RFP. Details of this device are available here: http://www.developer.nokia.com/Devices/Device_specifications/1680_classic/ The supplied mobile application will run on this and equivalent devices (should IEBC purchase additional handsets).

14

Satellite Device Additionally, the IEBC owns a quantity of Thuraya satellite phones, also capable of supporting Java. The mobile RTS application should also be capable of installation and running on this handset. Details of this device are available here: http://www.thuraya.com/products/voice/thuraya-sg The supplied mobile application should run on this and equivalent satellite devices (should IEBC purchase additional satellite handsets). SIM Card IEBC will separately procure SIM cards from its Telecom partner. It is expected that the SIM card will configure the handsets so that each phone connected to a dedicated APN, thereby ensuring that all communications will be on a private network. Other configuration options may be included in the SIM. Operating Platform (Java) The application will use a Java micro edition (Java ME) program able to run on the IEBCs Nokia 1680 Classic GSM phone, as well as the IEBCs Thuraya satellite handsets. Additionally, the IEBC may require that some of its Biometric Voter Registration Laptops be used for RTS. Please see Appendix 4 for specifications of this device. Device Power Autonomy The target device should be able to run the whole day and election night. Sufficient batteries will be available. However, the delivered solution should be engineered in a manner that is sensitive to power consumption. FUNCTIONAL REQUIREMENTS USER INTERFACE

15

The screen of the application should be laid out in the following manner:

Login Screen -> races screen -> candidate screen -> candidate data entry/correction screen. It should be easy for the user to use the navigation keys on the phone to navigate.

SPECIFICATIONS FOR VOTING DAY REPORTING FUNCTIONALITY

In addition to the transmission of results, the application should also be capable of collecting events on voting day. These events are Hourly voter turnout and spoilt votes Opening of polling stations Closing of polling stations Start of counting Finish of counting Problems encountered falling in a predefined list of categories namely o Shortage or non delivery Strategic materials o Shortage or non delivery non-Strategic materials o Security incidences o Missing voters on an hourly basis All the application requirements will need to be used for this as well. This means that the application will provide end to end multi-layer security application level user authentication and authorization

16

notification of successful receipt immutable logs for all activities

The voting day reporting module will have data collected from polling stations and require all incidents reports such as missing strategic items, hourly voter turnout, opening of polling stations, closing of polling station, start time of counting, and finish time of counting. The envisage reports are: Hourly voter turnout and spoilt votes Opening of polling stations Closing of polling stations Start of counting Finish of counting Transmitting of results Voting Progress Analysis The system should provide an Election Day management presentation for management team at national tallying centres providing information analyzing the process from the opening of polling stations to close of polling and counting. Reports to include basic graphical and tabular presentation of: Percentage Number of polling stations opened over a specified period e.g. 6 am to 7am Percentage Number of polling stations closed over a specified period 5pm to 7pm Percentage Voter turnout graph per constituency Percentage Number of polling stations closed and started counting over a specified period 5pm to 7pm Statistics of polling stations that have reported problem in various categories e.g. Strategic Materials, Non Strategic Materials

17

Other than tabular and basic charting detailed here, no digital mapping or other visualization of voting day event data is required.

Figure 2 Sample Presentation for one of the envisaged reports

Training Requirements

18

Training (including appropriate materials) will be required for the following categories of personnel: 1. Mobile RTS application users 2. Field support staff 3. Tally Centre application users 4. Regional and HQ operations staff 5. Staff of the ICT Directorate at HQ and Regional locations 6. Managerial staff of IEBC and partners Additionally, the offerer will be required to make appropriate material available to the IEBC Public Communications department to facilitate stakeholder (including political parties, media, public and domestic & international observers) awareness. The offeror is required only to deliver the top of a cascade training model i.e. Training of Trainers (approximately 40) and IEBC will be responsible for ongoing training of its personnel. The scope of training should be in: i. ii. iii. iv. v. vi. vii. Configuring the system to connect and import data from the external nomination system Configuring the system with destination IP addresses Adding users/editing authorizing them Removal/locking of rogue phones Use of the voting day operations application Use of the results transmission module Administration training on where this data is stored

19

DATA ENTRY OF OFFICIAL RESULTS AT TALLY CENTRES

Following the electronic transmission of provisional results from polling stations, the official results contained on the paper Form 16 will be transported to Constituency or County Tally centres as appropriate (County Assembly Ward results will move to County Tally Centres, while other results will move to Constituency Tally centres as appropriate). The software at the servers will permit the data entry by authorised IEBC personnel of official results. In addition to reconciliation of provisional and official results, the Tally Centre server applications will present all results received and transmit official results to National Tally Centre for consolidation.

WORKSTATION AND SERVER OPERATING SYSTEM AND DATABASE ENVIRONMENTS

Redundant high-end application servers, running Windows Server 2008 Enterprise Edition R2 will be deployed by IEBC at the National Tally Centre. The offeror is asked to provide RDBMS with its solution. MySQL or Microsoft SQL Server is preferred. At the Constituency and County Tally Centres, workstations will be provided, running Windows 7 64-bit OS. Offerors are asked to provide RDBMS, MySQL preferred.

TESTING
Please See Appendix 5 Testing. Vendors are expected to submit, with their proposals, a test plan that elaborates how it will test the delivered solutions, in line with Appendix 5.

20

V. CONTRACT MECHANISM & TERMS OF PAYMENT

IFES anticipates issuing a firm fixed price contract to an offeror. IFES will issue fixed payment(s) based on submission and IFES and IEBC acceptance of deliverables. Once an award is issued, it will include a fixed price payment schedule with deliverables specified in the Scope of Work.

VI. PROPOSAL SUBMISSION REQUIREMENTS

Offerors should read the following proposal instructions carefully. All interested offerors must provide the following: 1. Capability and Technical Experience Statement not to exceed 10 pages, indicating the following: a. Brief, general overview of organization. b. Capabilities and experience for conducting similar scopes of work as described above, with emphasis on electoral projects, and in particular on the capture and transmission of results on mobile devices. c. Description of methodologies, sample design, time line of activities, and reporting plan you are recommending to achieve the described scope of work. d. Description of any partner organization or subcontractor that you might contract with to do a portion of the scope of work, and a description of the division of level of effort and responsibility between your organization and the partner or subcontractor. e. If the offeror has a website or can post examples of their work, please indicate the website. Do not send any hardware with the proposal. 2. Staffing Please identify no more than 5 key personnel and the percentage of the time they will spend on this activity. Include no more than a half-page biosketch of each key personnel. Price/Cost Proposal Offerors will submit fixed price proposal in a separate, sealed envelope labelled BUDGET PROPOSAL with sufficient detail to allow evaluation of elements of costs proposed. Budgets should be submitted in the currency of the country within

3.

21

which your organization is located. If the proposal is being submitted electronically, please send the technical and price/cost proposal in separate emails, clearly labeled technical proposal and price/cost proposal. Please provide a price proposal for the total fixed amount. The fixed price proposal should only include a fixed price for each deliverable as described in the scope of work, above. 1. Please note that IFES cannot honour exchange rates included in a budget and payments will be made according to the exchange rate at the time of payment. 2. Please indicate the inclusion/exclusion of any applicable VAT. IFES is generally exempt from VAT payments and thus will not reimburse for VAT. 4. References: Please include three client references and contact information. References should have worked with your agency within the past two years and specific to countries or regions (and if possible, subject matter) applicable to this RFP. Additional Terms and Conditions Please review Appendix 6. Certifications Please read and sign the required Certifications attached in Appendix 7.

5. 6.

22

VII. CRITERIA FOR EVALUATION

Proposals will be evaluated and ranked by committee according to the conditions described in the evaluation criteria below. Proposals will first be evaluated from a technical standpoint. Those proposals that are considered to be technically acceptable shall then be evaluated in terms of cost. Technical Scores Technical Command and Grasp Staff and Quality Control Mechanisms Regional Experience Proposed Timeline* Total Technical Score Points 40 10 40 10 TT - max 100

*Please understand that adherence to the required timeline is a fundamental prerequisite for award of this tender. The points being awarded above will reflect the evaluators confidence in the offerers ability and commitment to the electoral calendar for Kenya, 2013. Financial Scores The evaluation committee will determine if the financial proposals are complete and without computational errors. After initial review for reasonableness of costs to complete the assignment, points are assigned. Price: PP - max 40

23

The lowest price (LP) proposal will be given a financial score (Sf) of the maximum points (PP). The financial scores of all other proposals will be computed as follows: Sf = PP x LP/P1,.P2, P3 where P1, P2, P3 are the prices of the other proposals.

Total Technical Score

+ +

Sf

= =

Total Points

TT

Sf

TP

For the purposes of comparison, all prices will be converted to USD$ at the rate applicable on the date of proposal deadline. The vendor with the highest Total Points will be awarded the contract.

VIII. RFP RESPONSE INFORMATION

All responses to this RFP must be received no later than 1700hrs (Nairobi time), 4th January, 2013 Proposals should be submitted in the following format(s):

24

1) All inquiries and requests for clarification of this RFP must be submitted by e-mail to jhayes@ifes.org; jacosta@ifes.org and gmenelik@ifes.org , reference RFP-13-050, no later than 1200hrs, Nairobi, 28th December, 2012. Inquiries and answers to inquiries will be shared with all offerors. 2) Electronic email copy must be submitted in PDF format to Joshua Hayes at jhayes@ifes.org , Jaime Acosta at jacosta@ifes.org and Genet Menelik at gmenelik@ifes.org . Original copies may be mailed (not required) to Genet Menelik at the following address: The International Foundation for Electoral Systems 11th Floor Embankment Plaza Longonot Road Upper-Hill PO Box 29654-00100, Nairobi KENYA

IFES will not compensate offerors for their preparation of any response to this RFP.

IX. TERMS AND CONDITIONS

Offerors are responsible for review of the terms and conditions described below and in the award template attached. If relevant, particular attention should be paid to clauses regarding USAID geographic code, marking and branding requirements and equipment and commodity purchases.

25

WITHDRAWALS OF PROPOSALS Offerors may withdraw proposals by written notice via email received at any time before award. Proposals may be withdrawn in person by an offeror or his/her authorized representative, if the representatives identity is made known and the representative signs a receipt for the proposal before award. RIGHT TO SELECT/REJECT IFES reserves the right to select and negotiate with those firms it determines, in its sole discretion, to be qualified for competitive proposals and to terminate negotiations without incurring any liability. IFES also reserves the right to reject any or all proposals received without explanation.

DISCLAIMER This RFP represents only a definition of requirements. It is merely an invitation for submission of proposals and does not legally obligate IFES to accept any of the submitted proposals in whole or in part, nor is IFES obligated to select the lowest priced proposal. IFES reserves the right to negotiate with any or all firms, both with respect to price, cost and/or scope of services. IFES has no contractual obligations with any firms based upon issuance of this RFP. It is not an offer to contract. Only the execution of a written contract shall obligate IFES in accordance with the terms and conditions contained in such contract. REQUEST FOR PROPOSAL FIRM GUARANTEE All information submitted in connection with this RFP will be valid for three (3) months from the RFP due date. This includes, but is not limited to, cost, pricing, terms and conditions, service levels, and all other information. If your firm is awarded the contract, all information in the RFP and negotiation process is contractually binding. OFFER VERIFICATION IFES may contact offerors to confirm contact person, address, bid amount and to confirm that the bid was submitted for this solicitation.

26

FALSE STATEMENTS IN OFFER Offerors must provide full, accurate and complete information as required by this solicitation and its attachments. CONFLICT OF INTEREST Offerors must provide disclosure of any past, present or future relationships with any parties associated with the issuance, review or management of this solicitation and anticipated award. Failure to provide full and open disclosure may result in IFES having to re-evaluate selection of a potential offeror. RESERVED RIGHTS All RFP responses become the property of IFES and IFES reserves the right in its sole discretion to: o To disqualify any offer based on offeror failure to follow solicitation instructions; o IFES reserves the right to waive any deviations by offerors from the requirements of this solicitation that in IFES's opinion are considered not to be material defects requiring rejection or disqualification; or where such a waiver will promote increased competition; o Extend the time for submission of all RFP responses after notification to all offerors; o Terminate or modify the RFP process at any time and re-issue the RFP to whomever IFES deems appropriate; o IFES reserves the right to issue an award based on the initial evaluation of offers without discussion; o Award only part of the activities in the solicitation or issue multiple awards based on solicitation activities. Governing Law and Language This solicitation and any resulting contract shall be interpreted in accordance with the laws of the U.S. Government except in cases where they contradict Kenyan law. The English language version of this solicitation and any resulting contract shall govern, and all notices pursuant to the provisions of this solicitation and any resulting contract shall be in English.

27

X. RFP ATTACHMENTS
Appendix 1: Appendix 2: Appendix 3: Appendix 4: Appendix 5: Appendix 6: Appendix 7: Database Schema Nominations System Mobile Client User Interface Screenshots Server Functionality Screenshots IEBC BVR Laptop Computer Specifications Draft Test Plan Procurement Template Certifications

END OF MAIN RFP ATTACHMENTS FOLLOW

28

APPENDIX 1 DATABASE SCHEMA - NOMINATIONS SYSTEM ATTACHED AS PDF

29

APPENDIX 2 MOBILE CLIENT USER INTERFACE SCREENSHOTS

Start Screen, with IEBC logo

Securing Communications

30

Login Screen

31

32

33

Races List (red dot is Not Sent, green dot is Sent)

34

Select a Race and the candidates are downloaded

35

List of candidates party and votes ordered in the same way they are ordered in the ballot and on the results Form

36

Enter the number of votes cast for each candidate in turn Enter the number of votes cast for each candidate in turn

37

38

Enter other information from the Results Form (Disputed, Rejected, etc)

39

Review completed data entry

40

41

Navigation Options

42

Choose SEND option

43

Sending progress screen

44

Once a given Race has been sent, the dot on the Races screen turns from Red to Green.

45

Not illustrated: A confirmation message should be sent from the receiving station to the sending station upon receipt of results.

46

APPENDIX 3 SERVER FUNCTIONALITY SCREENSHOTS

Login Screen

47

Home Page (Dashboard)

48

Waiting Page

49

Results Received Page

50

Result Verification 1

51

Result Verification 2

52

Result Received Report

53

Electronic Version of Form 16 Data

54

Provisional Form 17

55

Transmission to HQ

56

Presentation Tally Percentages and Results

57

Presentation of Totals per Candidate before Final Results

58

Presentation of Totals Per Candidate with partial Official Results confirmed

59

Sample Bar Graph Presentation

60

Sample Pie Chart Presentation

61

Sample Presentation Bar Chart showing both Provisional and Confirmed (Official) results, by Constituency

62

Sample Presentation of Timestamps of Receipt of Results

63

APPENDIX 4 IEBC BVR LAPTOP COMPUTER SPECIFICATIONS

DELL E 6320 LATITUDE MODEL Processor : Intel CoreTM i3 2330 Operating System : Windows XP Memory : 2GB DDR3 SDRAM (1333 MHz) Mobile Intel QM67 Express Chipset Intel HD Graphics 3000 Display : 13.3 HD (1366x768) Anti-Glare LED 500GB HDD 7200 rpm SATA Removable DVD-ROM, DVD+/-RW Battery : 6-cell (58Wh) 3 Year Warranty Lithium Ion battery Power 65W AC Adapter 10/100/1000 Gigabit Ethernet Dual Pointing Keyboard QWERTY Keyboard 3 x USB-2 Ports

A suitable GSM modem dongle will be procured as required.

APPENDIX 5 DRAFT TEST PLAN SEE ATTACHED PDF

65

APPENDIX 6 ADDITIONAL TERMS AND CONDITIONS

Drug Trafficking: IFES AND/OR THE US GOVERNMENT RESERVE THE RIGHT TO TERMINATE THIS PURCHASE ORDER/SUBCONTRACT TO DEMAND A REFUND OR TAKE OTHER APPROPRIATE MEASURES IF THE VENDOR/SUBCONTRACTOR IS FOUND TO HAVE BEEN CONVICTED OF A NARCOTICS OFFENSE OR TO HAVE BEEN ENGAGED IN DRUG TRAFFICKING AS DEFINED IN 22 CFR PART 140.

TERRORISM E.O. 13224: Vendor/Subcontractor agrees to take all necessary actions to comply with Executive Order No. 13224 on Terrorist Financing; blocking and prohibiting transactions with persons who commit, threaten to commit, or support terrorism. (E.O. 13224 text provided and also available at: http://www.whitehouse.gov/news/releases/2001/09/20010924-1.html Note: The attachment does not include Names of Those Designated after 23 September 2001; therefore, you are required to obtain the updated list at the time of procurement of goods or services. The updated list is available at: http://treasury.gov/offices/enforcement/ofac/sanctions/terrorism.html

66

APPENDIX 7 CERTIFICATIONS
THE FOLLOWING THREE CERTIFICATIONS MUST BE COMPLETED AND SIGNED BY EACH BIDDER AND RETURNED AS PART OF THE PROPOSAL SUBMISSION PACKAGE CERTIFICATION # 1
CERTIFICATION REGARDING TERRORIST FINANCING

By signing and submitting this application, the prospective recipient provides the certification set out below: 1. The Recipient, to the best of its current knowledge, did not provide, within the previous ten years, and will take all reasonable steps to ensure that it does not and will not knowingly provide, material support or resources to any individual or entity that commits, attempts to commit, advocates, facilitates, or participates in terrorist acts, or has committed, attempted to commit, facilitated, or participated in terrorist acts, as that term is defined in paragraph 3. 2. The following steps may enable the Recipient to comply with its obligations under paragraph 1: a. Before providing any material support or resources to an individual or entity, the Recipient will verify that the individual or entity does not (i) appear on the master list of Specially Designated Nationals and Blocked Persons, which list is maintained by the U.S. Treasurys Office of Foreign Assets Control (OFAC) and is available online at OFACs website: http://www.treas.gov/offices/eotffc/ofac/sdn/t11sdn.pdf, or (ii) is not included in any supplementary information concerning prohibited individuals or entities that may be provided by USAID to the Recipient. b. Before providing any material support or resources to an individual or entity, the Recipient also will verify that the individual or entity has not been designated by the United Nations Security (UNSC) sanctions committee established under UNSC Resolution 1267 (1999) (the 1267 Committee) [individuals and entities linked to the Taliban, Usama bin Laden, or the Al Qaida Organization]. To determine whether there has been a published designation of an individual or entity by the 1267 Committee, the Recipient should refer to the consolidated list available online at the Committees website: http://www.un.org/Docs/sc/committees/1267/1267ListEng.htm. c. Before providing any material support or resources to an individual or entity, the Recipient will consider all information about that individual or entity of which it is aware and all public information that is reasonably available to it or of which it should be aware. d. The Recipient also will implement reasonable monitoring and oversight procedures to safeguard against assistance being diverted to support terrorist activity.

67

3. For purposes of this Certificationa. Material support and resources means currency or monetary instruments or financial securities, financial services, lodging, training, expert advice or assistance, safehouses, false documentation or identification, communications equipment, facilities, weapons, lethal substances, explosives, personnel, transportation, and other physical assets, except medicine or religious materials. b. Terrorist act means(i) an act prohibited pursuant to one of the 12 United Nations Conventions and Protocols related to terrorism (see UN terrorism conventions Internet site: http://untreaty.un.org/English/Terrorism.asp); or (ii) an act of premeditated, politically motivated violence perpetrated against noncombatant targets by subnational groups or clandestine agents; or (iii) any other act intended to cause death or serious bodily injury to a civilian, or to any other person not taking an active part in hostilities in a situation of armed conflict, when the purpose of such act, by its nature or context, is to intimidate a population, or to compel a government or an international organization to do or to abstain from doing any act. c. Entity means a partnership, association, corporation, or other organization, group or subgroup. d. References in this Certification to the provision of material support and resources shall not be deemed to include the furnishing of USAID funds or USAID-financed commodities to the ultimate beneficiaries of USAID assistance, such as recipients of food, medical care, micro-enterprise loans, shelter, etc., unless the Recipient has reason to believe that one or more of these beneficiaries commits, attempts to commit, advocates, facilitates, or participates in terrorist acts, or has committed, attempted to commit, facilitated or participated in terrorist acts. e. The Recipients obligations under paragraph 1 are not applicable to the procurement of goods and/or services by the Recipient that are acquired in the ordinary course of business through contract or purchase, e.g., utilities, rents, office supplies, gasoline, etc., unless the Recipient has reason to believe that a vendor or supplier of such goods and services commits, attempts to commit, advocates, facilitates, or participates in terrorist acts, or has committed, attempted to commit, facilitated or participated in terrorist acts. This Certification is an express term and condition of any agreement issued as a result of this application, and any violation of it shall be grounds for unilateral termination of the agreement by IFES prior to the end of its term.

For Subcontractor:

Signature: Typed Name: Title: Name of Organization: Date:

68

CERTIFICATION #2.
CERTIFICATION REGARDING DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS -PRIMARY COVERED TRANSACTIONS (a) Instructions for Certification

1. By signing and submitting this proposal, the prospective primary participant is providing the certification set out below. 2. The inability of a person to provide the certification required below will not necessarily result in denial of participation in this covered transaction. The prospective participant shall submit an explanation of why it cannot provide the certification set out below. The certification or explanation will be considered in connection with the department or agencys determination whether to enter into this transaction. However, failure of the prospective primary participant to furnish a certification or an explanation shall disqualify such person from participation in this transaction. 3. The certification in this clause is a material representation of fact upon which reliance was placed when the department or agency determined to enter into this transaction. If it is later determined that the prospective primary participant knowingly rendered an erroneous certification, in addition to other remedies available to the Federal Government, the department or agency may terminate this transaction for cause or default. 4. The prospective primary participant shall provide immediate written notice to the department or agency to whom this proposal is submitted if at any time the prospective primary participant learns that this certification was erroneous when submitted or has become erroneous by reason of changed circumstances. 5. The terms covered transaction, debarred, suspended, ineligible, lower tier covered transaction, participant, person, primary covered transaction, principal, proposal, and voluntarily excluded, as used in this clause, have the meaning set out in the Definitions and Coverage sections of the rules implementing Executive Order 12549. You may contact the department or agency to which this proposal is being submitted for assistance in obtaining a copy of those regulations. 6. The prospective primary participant agrees by submitting this proposal that, should the proposed covered transaction be entered into, it shall not knowingly enter into any lower tier covered transaction with a person who is debarred, suspended, declared ineligible, or voluntarily excluded from participation in this covered transaction, unless authorized by the department or agency entering into this transaction. 7. The prospective primary participant further agrees by submitting this proposal that it will include the clause titled Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion--Lower Tier Covered Transaction, provided by the department or agency entering into this covered transaction, without modification, in all lower tier covered transactions and in all solicitations for lower tier covered transactions. 8. A participant in a covered transaction may rely upon a certification of a prospective participant in a lower tier covered transaction that it is not debarred, suspended, ineligible, or

69

voluntarily excluded from the covered transaction, unless it knows that the certification is erroneous. A participant may decide the methods and frequency by which it determines the eligibility of its principals. Each participant may, but is not required to, check the Nonprocurement List. 9. Nothing contained in the foregoing shall be construed to require establishment of a system of records in order to render in good faith the certification required by this clause. The knowledge and information of a participant is not required to exceed that which is normally possessed by a prudent person in the ordinary course of business dealing. 10. Except for transactions authorized under paragraph 6 of these instructions, if a participant in a covered transaction knowingly enters into a lower tier covered transaction with a person who is suspended, debarred, ineligible, or voluntarily excluded from participation in this transaction, in addition to other remedies available to the Federal Government, the department or agency may terminate this transaction for cause or default. (b) Certification Regarding Debarment, Suspension, and Other Responsibility Matters--Primary Covered Transactions (1) The prospective primary participant certifies to the best of its knowledge and belief, the it and its principals: (A) Are not presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from covered transactions by any Federal department or agency; (B) Have not within a three-year period preceding this proposal been convicted of or had a civil judgement rendered against them for commission of fraud or a criminal offense in connection with obtaining, attempting to obtain, or performing a public (Federal, State or local) transaction or contract under a public transaction; violation of Federal or State antitrust statutes or commission of embezzlement, theft, forgery, bribery, falsification or destruction of records, making false statements, or receiving stolen property; (C) Are not presently indicted for or otherwise criminally or civilly charged by a governmental entity (Federal, State or local) with commission of any of the offenses enumerated in paragraph (1)(B) of this certification; (D) Have not within a three-year period proceeding this application/proposal had one or more public transactions (Federal, State or local) terminated for cause or default. (2) Name: Title: Date: Where the prospective primary participant is unable to certify to any of the statements in this certification, such prospective participant shall attach an explanation to this proposal.

70

CERTIFICATION #3.
CERTIFICATION REGARDING DEBARMENT, SUSPENSION, INELIGIBILITY AN VOLUNTARY EXCLUSION LOWER TIER COVERED TRANSACTIONS (Code of Federal Regulations 22 CFR 208: Government-wide Debarment and Suspension (Nonprocurement) and Government-wide Requirements for Drug-Free Workplace (Grants); Appendix B: Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion Lower Tier Covered Transactions Instructions for Certification: By signing and submitting this proposal, the prospective lower tier participant is providing the certification set out below. 2. The certification in this clause is a material representation of fact upon which reliance was placed when this transaction was entered into. If it is later determined that the prospective lower tier participant knowingly rendered an erroneous certification, in addition to other remedies available to the Federal Government, the department or agency with which this transaction originated may pursue available remedies, including suspension and/or debarment. 3. The prospective lower tier participant shall provide immediate written notice to the person to which this proposal is submitted if at any time the prospective lower tier participant learns that its certification was erroneous when submitted or has become erroneous by reason of changed circumstances. 4. The terms Acovered transaction,@ Adebarred,@ Asuspended,@ Aineligible,@ Alower tier covered transaction,@ Aparticipant,@ Aperson,@ Aprimary covered transaction,@ Aprincipal,@ Aproposal,@ and Avoluntary excluded,@ as used in this clause, has the meanings set out in the Definitions and Coverage sections of rules implementing Executive Order 12549. You may contact the person to which this proposal is submitted for assistance in obtaining a copy of those regulations. 5. The prospective lower tier participant agrees by submitting this proposal that, should the proposed covered transaction be entered into, it shall not knowingly enter into any lower tier covered transaction with a person who is debarred, suspended, declared ineligible, or voluntarily excluded from participation in this covered transaction, unless authorized by the department or agency with which this transaction originated. 6. The prospective lower tier participant further agrees by submitting this proposal that it will include this clause titled ACertification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion--Lower Tier Covered Transaction,@ without modification, in all lower tier covered transactions and in all solicitations for lower tier covered transactions. 7. A participant in a covered transaction may rely upon a certification of a prospective participant in a lower tier covered transaction that it is not debarred, suspended, ineligible, or voluntarily excluded from the covered transaction, unless it knows that the certification is erroneous. A participant may decide the method and frequency by which it determines the eligibility of its principals. Each participant may, but is not required to, check the Non-Procurement List.

71

8. Nothing contained in the foregoing shall be construed to require establishment of a system of records in order to render in good faith the certification required by this clause. The knowledge and information of a participant is not required to exceed that which is normally possessed by a prudent person in the ordinary course of business dealings. 9. Except for transactions authorized under paragraph 5 of these instructions, if a participant in a covered transaction knowingly enters into a lower tier covered transaction with a person who is suspended, debarred, ineligible, or voluntarily excluded from participation in this transaction, in addition to other remedies available to the Federal Government, the department or agency with which this transaction originated may pursue available remedies, including suspension and/or debarment. Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion--Lower Tier Covered Transactions: (1) The prospective lower tier participant certifies, by submission of this proposal, that neither it nor its principals is presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from participation in this transaction by any Federal department or agency. (2) Where the prospective lower tier participant is unable to certify to any of the statements in this certification, such prospective participant shall attach an explanation to this proposal.

Name: Title: Date:

72