Answers to questions submitted by potential bidders regarding RapidFTR (RFPS-USA-2011501181).
Please direct further questions to NYHQPGRFPS@UNICEF.ORG
List of Questions (Answers provided below):
1. The deadline has passed for confirming intention to bid. Is that okay?
2. Do teams have to be based in New York? Will you consider split teams or teams based in
other cities / countries?
3. How many companies are bidding?
4. What is the budget?
5. Can we bid just on the Ruby / Web / Android part of the project?
6. What’s the most important thing to focus on for the technical response?
7. A weekly blog post is one of the expected deliverables. What if there’s nothing to
discuss? Can it be bi-weekly?
8. Does the Android application really need to be backwards compatible all the way to
version 1.6 and also support Ice Cream Sandwich or later versions?
9. Does it absolutely need to be a native Android application? Can it be written in HTML5
and put in an Android wrapper?
10. How long do you expect the engagement to last? Is 6 months realistic?
11. Does RapidFTR take a product-centered view or a platform-centered view?
12. Will vendor be obliged to do lots of communication with partners, selling the project
within UNICEF or to other agencies?
13. Will bids that propose using a different code base or starting from scratch be fairly
considered?
14. Annex 2 says that proposals can suggest starting from scratch, but Annex 4 states “the
winning bidder will need to coordinate efforts with work that is already in progress by a
distributed team of volunteers.” Is this contradictory?
15. Do records need to be able to sync locally with a computer or server, or can they go first
through the web to a master database, to avoid merge conflicts?
16. Can it be deployed to a managed cloud host or will it need to also be deployed to
UNICEF’s managed cloud servers? Can it be built on 3rd party cloud
management/infrastructure software?
17. We don't do Android development but would like to bid for the website RFP. Would this
be a possibility?
18. Will it be possible to do user interviews either in person or via Skype? Can one of the
trips happen early in the engagement, so that user interviews can be conducted?
19. How do they see the tablet being used? Do we need to break out the pricing so that it
reflects the additional work required in order to develop and test a tablet version of the
system?
20. How does UNICEF see the support for this system working?
21. What are the target Operating Systems to target for NetBook (Linux? or some others?)
22. Which are the APIs that need to be completed? / We have to understand how many
APIs we need to develop: Are they the same APIs that already exist, or do we need to
build new ones on this phase?
23. Which are the features of the web application? Which are the ones that need to be
finalized?
24. Does it have to be a fixed bid? We usually bid on time and materials.
25. We’re confused about the deliverables around community management, and
hackathons. How will this work / Isn’t this something that UNICEF should handle?
26. What do you mean by Netbook? Does a MacBook Air qualify?
27. Does the Netbook client have the same functions as the handset client?
28. Do we need to write scripts that hook into the individual APIs for each provider of
managed cloud infrastructure (EC2, Rackspace, etc), or simply ensure that the software
package is broadly compatible with managed cloud providers, and could be deployed to
a variety of places if the need arises?
29. We are contemplating putting forward two approaches for the team - one purely on-site
in NYC and the other as a hybrid team of on-site and off-site team members, is it
possible to submit two models in the same proposal?
30. Are there any fixed deployment dates and scope objectives that UNICEF is working
towards?
31. The RFP talks of hosting for 2 years going forward, does UNICEF anticipate active
development going on during this 2-year period?
32. We have a substantial team in China. Are there any residency requirements for
employees who participate in the development of RapidFTR?
33. We saw the public announcement of the Humanitarian Innovation Fund Grant. Is this
RapidFTR's only source of funding?
34. Can vendors receive clarification on the current phase of the project? The proposal from
UNICEF mentions “much of the groundwork has been done.” Specifically:
a. Server application / API’s: How complete are they (in %)? What is required to
complete in this module?
b. Dashboard/Admin tools to manage instances of RapidFTR on a server: How
complete are they? What is required to complete this module?
c. The Android phone Application: How complete is it? What is required to
complete this module?
d. The Android tablet Application: How complete is it? What is required to
complete this module?
e. The web application for PC-based access / administration: How complete is it?
What is required to complete this module?
f. The Netbook server (mini-server for low-connectivity deployment environments
with easy installer) How complete is it (in %)? Has it been demonstrated /
tested? What is required to complete this module?
35. Is there any information on how UNICEF intend to install (distribute) those applications
on the phones?
36. From the UNICEF experience what is the size of the usual database to be for a country or
disaster-specific implementation?
37. When we synchronize the data between the server and a mobile device, do we make all
unresolved cases for that deployment available offline on the phone?
38. Is there a long-term plan for maintaining the central servers to host the application?
39. Is it a requirement that the netbook client be used for data collection as well?
40. Is UNICEF going to provide access to the electricity and Internet during the testing of the
system?
41. Is UNICEF providing security whenever that is required, especially during the field trips?
42. How many people are expected to be trained in each location? Is it going to be train the
trainer programme or we are expected to reach wider group of final users?
43.
44.
45.
46.
47.
48.
During the trail deployments will we be using a cloud server or on a local server?
Who will be responsible for the servers or cloud infrastructure?
What will be the data retention plan and what happens to the resolved cases?
Can we also modify the API’s if needed?
Can we get some examples of the customized forms that may be needed?
Is system expected to support many languages? If yes can we get a list of languages
UNICEF intend to support?
49. Is there a necessity for daily Skype call with all stakeholders?
50. Is there possibility for the UNICEF representatives to visit our teams in Geneva and
Dhaka?
51. Is there any chance for cooperation with the selected company whenever our bid is not
successful?
1. The deadline has passed for confirming intention to bid. Is that okay?
Yes, it okay. You can still participate by sending in your proposals on or before the
stated deadline. The letter of intent usually helps us to know if there are enough
companies that are interested in participating.
2. Do teams have to be based in New York? Will you consider split teams or teams based
in other cities / countries?
Teams can be based anywhere. The project is coordinated from UNICEF HQ, which is
located in New York, however UNICEF and the RapidFTR team is experienced and
comfortable working with distributed teams. One caveat, as listed on page 5 of the RFP:
“Though we prefer that the development team be located in or near New York
(preference to proximity), this is not an absolute requirement. However, if the team is
not in New York, then the majority of the team, including principle developers and
project managers must be able to overlap, online, on Skype for at least two contiguous
hours each day with a 9am to 6pm EST working schedule.”
3. How many companies are bidding?
The RFP is publicly posted and open to any qualified bidders.
4. What is the budget?
UNICEF does not normally give an in indication of the budget envelope this is so since
we are expected to have competitive bids for all our contracts.
The bidding organizations will need to make their own assessment of anticipated level
of effort, appropriate levels of expertise to achieve the specified outcomes. UNICEF will
then assess each of the bids to see whether the bidders have understood the
requirements of the task and come up with a credible technical proposal that also
represents value for money for UNICEF.
5. Can we bid just on the Ruby / Web / Android part of the project?
Proposals must address all portions of the RFP, however as the RFP states on page one:
“We expect a company to either have both Android and Ruby experience or to make a
compelling case that they can subcontract work they are unfamiliar with to a credible
company or individual.” Your bid must be inclusive of all the deliverables, but the work
can be outsourced to another company if needed.
6. What’s the most important thing to focus on for the technical response?
The technical responses will be measured on a seventy point scale. Annex 2 of the
Request For Proposals, RFP Technical Response Guidelines, lists out the maximum
points value for each section of the response criteria. Proposals must receive at least 50
points to be considered.
7. A weekly blog post is one of the expected deliverables. What if there’s nothing to
discuss? Can it be bi-weekly?
We think it’s important to have regular updates and communications about the
development process and especially the testing trips made available to partners,
funders, and interested parties. These don’t have to be extensive, wordy updates,
though. A photograph and caption or short paragraph about what the team is tackling at
a given moment may suffice. While we’d like weekly blog posts, it’s understandable if
the requirement slips a week from time to time, as long as there is a plan in place for
regular reports.
8. Does the Android application really need to be backwards compatible all the way to
version 1.6 and also support Ice Cream Sandwich or later versions?
RapidFTR will be used in emergencies, often in low resource environments where only
older devices may be readily available. We do not have a specific device or model that
we can target for support, so the application must be widely compatible with different
devices and OS versions. If you believe that, given these constraints, there is a reason to
adjust the range of supported versions, please include your reasoning in your technical
response. We are open to other ideas.
9. Does it absolutely need to be a native Android application? Can it be written in HTML5
and put in an Android wrapper?
Our main concerns are data security and flexibility. The application must be able to
store encrypted data to the device, log usage, and sync securely with the API. It must be
able to work with and without network connectivity. And it needs to be available on a
wide range of Android devices. If you believe that an HTML5 application is the proper
solution given these constraints, please include your reasoning in the technical
response.
10. How long do you expect the engagement to last? Is 6 months realistic?
We purposely did not dictate a set schedule so that bidders would have the flexibility to
present proposals based on their own teams and expertise. Our goal is to test RapidFTR
in two to three countries by the end of 2012, so six months would not be an unrealistic
development schedule. However, we are open to shorter and longer engagements. Tell
us what you think is the most appropriate schedule, given our deliverables.
11. Does RapidFTR take a product-centered view or a platform-centered view?
Two hallmarks of RapidFTR are that it is a flexible, customizable system, and that it is
open source, and thus available to anyone. There are many potential uses for it, but for
now we are developing RapidFTR for the specified use cases delineated in the RFP, and
not as a tool to be applied in infinite cases. In that respect, we are taking a productcentered as opposed to a platform-centered approach.
12. Will vendor be obliged to do lots of communication with partners, selling the project
within UNICEF or to other agencies?
Communications materials are an important part of the RFP, but only as designated
within the deliverables, where the emphasis is on the development process, training
materials, and documentation. There may be times when a project manager or lead
developer will be asked to take part in a meeting or presentation, but only for help
answering technical or process questions.
13. Will bids that propose using a different code base or starting from scratch be fairly
considered?
As the RFP states in “Annex 2: RFP Technical Response Guidelines,”
Note: A substantial amount of code has already been written as the foundation
of RapidFTR. We understand that some potential bidders may prefer to start
from scratch instead of building off the existing work. If this is the case with
your bid, please provide:
1 page (or less) explaining why you feel that starting over is the better course of
action.
Why we want this: We understand that development teams often prefer to start
projects completely from scratch. At the same time, we have a lot of welldocumented and tested code already written. We do not want to dissuade
qualified teams from responding to this proposal, and welcome clearly
articulated arguments in favour of your preferred strategy.
Clearly, a fair amount of work has been completed by the volunteer community, but we
understand that it may be easier or more expedient to rewrite or reconfigure some or
all of the completed work. While that is not our preference, it is understood and
expected that this may be the case, and bids that are organized on this principle will be
assessed against the same criteria as bids that are not.
14. Annex 2 says that proposals can suggest starting from scratch, but Annex 4 states “the
winning bidder will need to coordinate efforts with work that is already in progress by
a distributed team of volunteers.” Is this contradictory?
The main concern addressed in Annex 4 is that bidders understand that RapidFTR has a
large and interested community of volunteers whose contributions are valued and will
continue to be encouraged. Regardless of development strategy, bidders need to
present a plan for engaging volunteers as the work progresses.
15. Do records need to be able to sync locally with a computer or server, or can they go
first through the web to a master database, to avoid merge conflicts?
RapidFTR must be fully functional in the absence of a network connection. This means
that child protection specialists must be able to sync their mobile devices (via wifi or,
less likely, Bluetooth) to a local server or computer and exchange data. That server
should then be able to sync to an instance in the cloud or at an off-site location. Though
this strategy can certainly change, we had anticipated that merge conflicts would be
resolved simply, using the most recent ‘last edited’ time stamp to determine the most
current information, and to push conflicting information to the child history logs. Thus, if
User One updates a child record at 2pm EST but syncs the information at 5pm EST, and
User Two updates the same child record at 3pm EST and syncs it at the same time, the
system will recognize the timestamps against each record and display User Two’s
changes as the most current, with User One’s changes appearing in the child history log.
CouchDB’s architecture and replication system should help with this challenge.
16. Can it be deployed to a managed cloud host or will it need to also be deployed to
UNICEF’s managed cloud servers? Can it be built on 3rd party cloud
management/infrastructure software?
Because RapidFTR will potentially be deployed in a wide variety of contexts and in
concert with many different partners, it must be deployable in a number of ways, as
described on page 18 of the RFP, under Installers / Deployment Mechanisms:
Installers / Deployment Mechanisms
RapidFTR must be installable in a variety of ways:
 USB (or equivalent) - for netbooks / notebooks and locally managed
servers not connected to the Internet.
 Web - Local: Launch an independent, locally-managed instance of
RapidFTR downloaded or accessed from the web.
 Web - Global: A global dashboard to launch centrally-managed
instances of RapidFTR from the web, possibly including launching with
Heroku, EC2, or other cloud application platforms.
Some work has already been done on creating scripts for easy deployment to Heroku,
EC2, and Linode, but we are open to other solutions. The main concerns are that UNICEF
and partners must have independent control over their data and that all child
information be secured.
17. We don't do Android development but would like to bid for the website RFP. Would
this be a possibility?
Kindly note that as per the TOR, we expect a company to either have both Android and
Ruby experience or to make a compelling case that they can subcontract work they are
unfamiliar with to a credible company or individual.
18. Will it be possible to do user interviews either in person or via Skype? Can one of the
trips happen early in the engagement, so that user interviews can be conducted?
User interviews and documentation can certainly be incorporated into the trips, but
those trips will coincide with development milestones—when the Android client is ready
for testing, for example—and not just for discovery and user interviews. We may be
able to arrange some user interviews via skype, but the development path should not
rely on frequent and direct contact with child protection specialists working in the field.
19. How do they see the tablet being used? Do we need to break out the pricing so that it
reflects the additional work required in order to develop and test a tablet version of
the system?
A tablet version, which we see as secondary to the handset version, would be used in
the same way as the handset app. We don’t see it as a large and separate piece of
development work but rather as a porting over of the handset app to be usable on
Android tablets. Obviously, some work is still involved with this plan; the price proposal
should reflect work necessary for all deliverables.
20. How does UNICEF see the support for this system working?
We haven’t figured out how RapidFTR will be supported once it has been developed and
deployed. We are open to suggestions, of course.
21. What are the target Operating Systems to target for NetBook (Linux? or some others?)
There is no specific target operating system at the moment, but Linux would be
appropriate. It’s possible that RapidFTR could be deployed with a VM wrapper as well, if
that’s easiest / most efficient.
22. Which are the APIs that need to be completed? / We have to understand how many
APIs we need to develop: Are they the same APIs that already exist, or do we need to
build new ones on this phase?
It’s not full new APIs that need to be completed, but rather certain API calls and
functions. These are primarily around security and tokens, user levels/permissions,
activity and error logging, and syncing of user/admin information on the netbook
version.
23. Which are the features of the web application? Which are the ones that need to be
finalized?
Web application includes all admin functionality such as creating users, assigning
permission level, creating and modifying fields and forms, export, etc., as well as the
ability to create and edit records. There is some work to be done on all parts, but key
pieces of functionality include language / localization, user permissions, activity logging,
and security considerations, as well as UI/UX review.
24. Does it have to be a fixed bid? We usually bid on time and materials.
We don’t have any flexibility on the price proposals. In order to fairly compare bids from
different vendors, they need to be consistent with the guidelines that are written out in
the Evaluation Of The Proposal section of the RFP (page 7 of 21).
25. We’re confused about the deliverables around community management, and
hackathons. How will this work / Isn’t this something that UNICEF should handle?
It’s important to us that the open source nature of RapidFTR continues to be
emphasized and that the community of volunteers dedicated to the project continues to
be fostered and sustained. That’s the main goal driving this set of requirements. We
understand that figuring out the best way to sustain the volunteer spirit of RapidFTR
while engaging a dedicated team to move forward with development may present some
challenges, but we are willing to be very collaborative with the winning bidder to figure
out how this can best be done.
26. What do you mean by Netbook? Does a MacBook Air qualify?
Sadly, at this point, Netbook has become something of a legacy term as the popularity
and production of actual netbooks has declined. What we really mean are small laptop
computers that can be used in the field to run RapidFTR in the absence of a network
connection. MacBook Air, because of the price, fixed battery, lack of ruggedness, and
lack of availability in much of the world, would not be a supported device.
27. Does the Netbook client have the same functions as the handset client?
The netbook client should be seen as a localized version of the web application; it will
have the same functionality, with a local database. It should be able to sync with
handsets, create and edit users, etc. And when a net connection is established it should
be able to sync again to a master database in the cloud or on an Internet-connnected
server.
28. Do we need to write scripts that hook into the individual APIs for each provider of
managed cloud infrastructure (EC2, Rackspace, etc), or simply ensure that the
software package is broadly compatible with managed cloud providers, and could be
deployed to a variety of places if the need arises?
We want RapidFTR to be deployable to the cloud, and some scripts have already been
written experimenting with automated deployment to EC2, Heroku and Linode. We do
not expect a deployment path to be developed for each and every cloud provider, but
rather that the infrastructure to do so be in place, and functioning with at least one
provider, and that it can be tweaked in the future if a preferred provider emerges.
29. We are contemplating putting forward two approaches for the team - one purely onsite in NYC and the other as a hybrid team of on-site and off-site team members, is it
possible to submit two models in the same proposal?
The Proposer can make two proposals different in price and/or approach as long as the
ToR are fully addressed.
30. Are there any fixed deployment dates and scope objectives that UNICEF is working
towards?
There are no absolutely fixed deployment dates that UNICEF is working towards,
however, we hope to be able to test the Android client early in the summer months, and
to complete the other two testing / deployment trips by the end of the year. These
plans are dependent on the development schedules submitted by the bidding
companies.
31. The RFP talks of hosting for 2 years going forward, does UNICEF anticipate active
development going on during this 2-year period?
There may be some development during this 2-year period, but not as part of this RFP /
contract.
32. We have a substantial team in China. Are there any residency requirements for
employees who participate in the development of RapidFTR?
Nothing beyond what's listed in the RFP, which includes a preference for a two-hour
block of time contiguous with a typical EST working day for meetings, etc.
33. We saw the public announcement of the Humanitarian Innovation Fund Grant. Is this
RapidFTR's only source of funding?
We are happy to answer questions regarding the technical criteria, but are unable to
answer questions about budgets or financial criteria.
34. Can vendors receive clarification on the current phase of the project? The proposal
from UNICEF mentions “much of the groundwork has been done.” Specifically:
The best way to get a sense of progress is to look at the demo instance of RapidFTR,
available here: https://dev.rapidftr.com.
For admin level access – username and password: rfpadmin
For user level access – username and password: rfpuser
a. Server application / API’s: How complete are they (in %)? What is required to
complete in this module?
Any percentage answer will be potentially misleading, because it confers a sense
of specificity that can’t be known. That being said, a conservative estimate
would say 75ish% of core functionality is in place, but the remaining
requirements are somewhat thorny and include logging of errors and user
activity; error reporting to clients; improved security / token management;
advanced user permissions; improvement to search, especially around
language/localization; blacklisting of specific devices and IP addresses; some
smartness around client versioning and updates; and any API calls that may
become necessary to accommodate netbook clients with admin functionality.
Note: this list may not be exhaustive.
b. Dashboard/Admin tools to manage instances of RapidFTR on a server: How
complete are they? What is required to complete this module?
Nothing has been completed. There are rake tasks and deployment scripts,
which are documented on the github repository, but no dashboard or admin
tools to help less technical users launch or administer instances of RapidFTR to a
server.
c. The Android phone Application: How complete is it? What is required to
complete this module?
Very little has been done for Android. Work has been done for initial login,
downloading and display of forms. You can look at the Android repository here:
https://github.com/jorgej/RapidFTR---Android.
d. The Android tablet Application: How complete is it? What is required to
complete this module?
No work has been done on the Android tablet application, however it should be
noted that we consider this low priority and a small piece of work. We imagine
porting over the Android phone application for use on the tablet, but not
creating an entire new application.
e. The web application for PC-based access / administration: How complete is it?
What is required to complete this module?
Lots of work has been done for the web application, which can be accessed at
the address listed above. There is a significant UI/UX pass to be completed, as
well as work to be done on export functionality, language/localization, logging
of user activity, improved security / token management, advanced user
permissions, media management, import and export of forms, and more. Note:
this list may not be exhaustive.
f.
The Netbook server (mini-server for low-connectivity deployment
environments with easy installer) How complete is it (in %)? Has it been
demonstrated / tested? What is required to complete this module?
No specific work has been completed on this at all. Though the idea is not to
build an application from scratch, but rather to package the current application
for deployment to netbooks. Beyond packaging, the netbook client requires
specific additional work, including management of connections to mobile
devices; ability to switch between client and master; ability to select which
instance/db to sync with (this may be a server side task instead of a netbook
task); data encryption; and perhaps more. Note: this list may not be exhaustive.
35. Is there any information on how UNICEF intends to install (distribute) those
applications on the phones?
At the moment, the intention is to install them over the air via http link. It is likely that
the server (and netbook client) may need to make a link available to the devices. We are
open to other ideas, but so far this seems like the easiest solution.
36. From the UNICEF experience what is the size of the usual database to be for a country
or disaster-specific implementation?
We don’t have specific information to share but we anticipate the number of child
records for a specific disaster to be in the hundreds and low thousands. Of course, the
system should be scalable to handle bigger data sets, but we do not anticipate record
numbers to be in the hundreds of thousands or millions.
37. When we synchronize the data between the server and a mobile device, do we make
all unresolved cases for that deployment available offline on the phone?
At the moment, that’s how it works. However as different permission levels are put into
place, some users will be able to pull down only records appropriate to their permission
level (filtered by organization or records that they themselves have created, for
example).
38. Is there a long-term plan for maintaining the central servers to host the application?
There is no long-term plan in place at the moment. Please include any suggestions you
may have in your response.
39. Is it a requirement that the netbook client be used for data collection as well?
Yes. We envision the netbook client to be extremely similar to the web application.
40. Is UNICEF going to provide access to the electricity and Internet during the testing of
the system?
While conditions in the field can be unpredictable, UNICEF will work to ensure that basic
requirements are in place to make testing a success.
41. Is UNICEF providing security whenever that is required, especially during the field
trips?
Yes, trips will be taken in accordance with UNICEF travel policies.
42. How many people are expected to be trained in each location? Is it going to be train
the trainer programme or we are expected to reach wider group of final users?
These numbers are yet to be determined, but we imagine that trainings would involve
between twenty and thirty participants. It is possible that smaller training of trainer
programs could be attempted on the same trip as an end user training.
43. During the trial deployments will we be using a cloud server or on a local server?
We should be prepared to use both or either, depending on the needs and constraints
on the ground. One trial deployment may focus chiefly on using the netbook client as
the primary database. Fine details of these trips will be ironed out more fully with the
winning bidder.
44. Who will be responsible for the servers or cloud infrastructure?
Ultimately, responsibility for servers or cloud infrastructure will rest with UNICEF or its
partners.
45. What will be the data retention plan and what happens to the resolved cases?
Data retention plan has yet to be worked out, but RapidFTR is foremost considered a
system for documentation but not for case management. The vision is that child
information will be exported from RapidFTR into the case management systems
maintained by UNICEF’s implementing partners and that specific instances of RapidFTR
will be relatively short lived.
46. Can we also modify the API’s if needed?
Absolutely. We imagine that the APIs will need to be modified.
47. Can we get some examples of the customized forms that may be needed?
The RapidFTR demo instance contains examples of the forms, though they may have
been modified during testing. The RapidFTR developer instance and VM launches with
basic forms already included.
48. Is system expected to support many languages? If yes can we get a list of languages
UNICEF intend to support?
RapidFTR is expected to ship with support for the official UN languages, which are
Arabic, Chinese (Mandarin), English, French, Russian, and Spanish. However, users will
be able to translate the basic forms into local languages and upload local language sets
(possibly via csv) when launching an instance of RapidFTR. We do not envision switching
between languages one an instance has been launched.
49. Is there a necessity for daily Skype call with all stakeholders?
No. The daily call should be considered more of a “standup” with the developers,
project manager and RapidFTR coordinator on the UNICEF side.
50. Is there possibility for the UNICEF representatives to visit our teams in Geneva and
Dhaka?
This is certainly very possible, and perhaps advisable, but cannot be guaranteed.
51. Is there any chance for cooperation with the selected company whenever our bid is
not successful?
We certainly hope so! We can’t guarantee anything, but we will work to include
anybody who would like to participate in this open source and community driven
project. We absolutely recognize the challenges inherent in incorporating less
structured efforts into a scheduled stream of deliverables from a paid vendor, but we’re
confident that we can make it work.