REQUEST FOR PROPOSAL (RFP-13-050)

2

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: Kenya Election Results Transmission System (RTS)

RFP #: RFP-13-050

Issued on: Friday, December 21st 2012

Proposal Deadline: 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 IEBC’s role

in conducting transparent, credible, and violence-free elections.

In order to assist the IEBC in its preparations for General Elections scheduled for March 4th

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

1 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

3

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

IEBC’s 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

4

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

Constituency Tally Centre

County Tally Centre

National Tally Centre

Tally

Cen

tre

Pre

sen

tati

on

**

Internet

Results Presentation

System*

Tally

Cen

tre

Pre

sen

tati

on

**

EVT Components

RTS

TELECOMS

RPS

*digital mapping, visualization etc

*digital mapping, visualization etc

**basic tabular and chart reports

**basic tabular and chart reports

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

5

IEBC’s telecommunications provider

IEBC’s 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 IEBC’s 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)

6

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 provider’s 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 user’s 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

7

iv. Password

v. Polling Station

3. 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.

4. 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.

5. The central administration of these certificates should make it possible for

administrators to revoke certificates on rogue mobile devices.

6. 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

8

manner.

3. 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

4. Enable acknowledgement of completion of a data entry transaction with a

confirmation message, if data entry was successful, or else with an error message.

5. Enable easy navigation from one race to the next after completion of a data entry

transaction.

6. The system should display a message before sending data for user confirmation and

also a confirmation message for successfully transmitted results.

7. 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.

8. 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

9

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

12

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,

13

"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.

14

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. Summary of results received

2. Summary of results verified

3. Constituency tally results

4. County tally results

5. 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).

15

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 IEBC’s Nokia 1680 Classic GSM phone, as well as the IEBC’s

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

16

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

17

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

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

18

Figure 2 Sample Presentation for one of the envisaged reports

Training Requirements

19

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. Configuring the system to connect and import data from the external nomination system

ii. Configuring the system with destination IP addresses

iii. Adding users/editing authorizing them

iv. Removal/locking of rogue phones

v. Use of the voting day operations application

vi. Use of the results transmission module

vii. Administration training on where this data is stored

20

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.

21

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.

3. 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

22

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.

5. Additional Terms and Conditions – Please review Appendix 6.

6. Certifications– Please read and sign the required Certifications attached in Appendix 7.

23

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 Points

Technical Command and Grasp 40

Staff and Quality Control Mechanisms 10

Regional Experience 40

Proposed Timeline* 10

Total Technical Score 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 offerer’s 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

24

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):

25

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.

26

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 representative’s 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.

27

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.

28

X. RFP ATTACHMENTS

Appendix 1: Database Schema – Nominations System

Appendix 2: Mobile Client User Interface Screenshots

Appendix 3: Server Functionality Screenshots

Appendix 4: IEBC BVR Laptop Computer Specifications

Appendix 5: Draft Test Plan

Appendix 6: Procurement Template

Appendix 7: Certifications

– END OF MAIN RFP – ATTACHMENTS FOLLOW –

29

APPENDIX 1 – DATABASE SCHEMA - NOMINATIONS SYSTEM – ATTACHED AS PDF

30

APPENDIX 2 – MOBILE CLIENT USER INTERFACE SCREENSHOTS

Start Screen, with IEBC logo

Securing Communications

31

Login Screen

32

33

34

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

35

Select a Race and the candidates are downloaded

36

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

the results Form

37

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

candidate in turn

38

39

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

40

Review completed data entry

41

42

Navigation Options

43

Choose SEND option

44

Sending progress screen

45

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

46

Not illustrated: A confirmation message should be sent from the receiving station to the sending

station upon receipt of results.

47

APPENDIX 3 – SERVER FUNCTIONALITY SCREENSHOTS

Login Screen

48

Home Page (Dashboard)

49

Waiting Page

50

Results Received Page

51

Result Verification – 1

52

Result Verification – 2

53

Result Received Report

54

Electronic Version of Form 16 Data

55

Provisional Form 17

56

Transmission to HQ

57

Presentation Tally Percentages and Results

58

Presentation of Totals per Candidate before Final Results

59

Presentation of Totals Per Candidate with partial Official Results confirmed

60

Sample Bar Graph Presentation

61

Sample Pie Chart Presentation

62

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

63

Sample Presentation of Timestamps of Receipt of Results

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.

65

APPENDIX 5 – DRAFT TEST PLAN – SEE ATTACHED PDF

66

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

67

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. Treasury’s Office of Foreign Assets Control (OFAC) and is available online at OFAC’s 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 Committee’s 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.

68

3. For purposes of this Certification- a. “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 Recipient’s 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:

69

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 agency’s 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

70

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) 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.

Name:

Title:

Date:

71

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.

72

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: