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 [email protected]; [email protected] and
[email protected] , 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 [email protected] , Jaime Acosta at [email protected] and Genet Menelik at [email protected] . 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: