ECE2031 Proposal Overview – A Sample RFP

advertisement
ECE2031 Proposal Overview – A Sample RFP
The following was taken from an actual RFP (“Request for Proposal”) by the U. S. Government. This was public information then (and still is), and is typical of what an RFP
for industrial and academic institutions will look like. Key elements that relate to
ECE2031 are noted in boxed text (like this). Different RFPs will use different formats,
so don’t expect an ECE2031 project assignment to look exactly like this.
1. SECTION I: BAA 97-20 PROPOSER INFORMATION
This section provides further information on technical scope, open review requirements,
evaluation criteria and funding processes, and proposal format.
Note above that an RFP describes the overall scope, tells how proposals will be evaluated, and gives specific formatting instructions. Below, the proposer will be called the
“offeror.” In this case, the government is the “customer” or “sponsor.”
The Defense Advanced Research Projects Agency (DARPA) often selects its research efforts
through the Broad Agency Announcement (BAA) process. The BAA will have appeared first in
the Commerce Business Daily, published by the U.S. Government, Department of Commerce.
The following information is for those desiring to respond to the BAA.
Many RFPs (including virtually all government ones) are provided in an open forum
with fair access to all. In ECE2031, this includes the web sites (diglab and OWL), as
well as questions answered in a public forum (the newsgroup).
2. LONG TERM OBJECTIVE
A long-term objective underlying the present Broad Agency Announcement is to field a "robot pointman" to perform the notoriously dangerous functions of the first soldier in an assault
force to enter an area, a building, or a room. The Government hopes to achieve this objective
within the next decade.
Note how brief and open-ended the basic problem statement is.
3. TECHNICAL SCOPE
The technical scope of proposals should address, but need not be limited to, the six following
technical areas, listed in decreasing order of relative importance.
This is a much more complicated and expensive project than an ECE2031 project, and
that shows up in this section more than any other. Here, the essential technical elements
are described in more detail. You will be given a few details as well. When you are
thinking about what “specifications” your design must satisfy, look for a corresponding
section in your assignment.
(1) Locomotion and Real-Time Control. For Small Unit Operations in urban terrain, the locomotion chassis should be small enough to be easily deployed in the field, mobile enough to
traverse rubble, agile enough to negotiate steps, and fast enough to avoid detection and simple
capture by unfriendly forces. For field operations, the locomotion chassis and controller hardware
should be rugged enough to survive being carried into the deployment area and survive short falls,
for example, falling off a curb or step.
(2) Operator Interface. For Small Unit Operations in combat situations, the operator interface
should be non-distracting, allowing the operator to maintain awareness of the environment evolving around them. Thus, the operator interface need not be capable of displaying rich streams of
data transmitted over high-bandwidth links. Rather, the operator interface should enable multimodal interaction using more than one of the operator's senses. This may involve definition of a
command and telemetry set. DARPA encourages but does not require offerors to consider the
integration of existing displays and interfaces into a functional unit.
(3) Sensing and Perception for Mobility. Robots operating in urban terrain must be capable of
identifying hazards and obstacles to robot motion. This identification requires sensing to gather
raw data about the external environment, and perception to interpret that data with respect to the
vehicle capabilities. Both of these functions must be performed on-board the vehicle.
(4) Path Planning. One approach for the robot to avoid detection by and simple capture by
unfriendly forces, is to move rapidly. This poses a challenge for path planning and reactive control
algorithms, both to achieve the robustness to perform well in a wide variety of urban terrains, and
to achieve and sustain the operational cycle-time required for rapid motion.
(5) Perception for Reconnaissance. Primary purposes of reconnaissance operations include
gathering information about the presence of people, and the presence of traps. Specific problems
of interest to DARPA include determining the location of people in an urban environment, identifying people that are non-combatants, and identifying booby traps such as trip wires.
(6) Task-Level Planning. For Small Unit Operations in combat situations, robot operators do
not have the luxury of paying exclusive or even close attention to the robot. Thus, the robot must
have the capability to plan, sequence, and execute its own operations to perform its mission as
given by the operator.
THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY AND SHOULD
NOT BE INTERPRETED AS GOVERNMENT SPECIFICATIONS.
2
The preceding statement is really interesting. Although the section clearly covered the
general nature of specifications, the government is careful to allow the offeror (proposer) to be more specific. (Note the non-coincidental use of “specific” and “specifications.”) In other words, a good proposal for an open-ended problem will nail down
some of these items (i.e., YOU will have to do it). In this case, for example, a proposal
may make a logical argument about what constitutes “rich streams of data” and go on
to show that the proposed solution has enough bandwidth to carry that much data. Some
RFPs are VERY specific, but most of the “fun” stuff is more oriented toward basic research and development, leaving more flexibility to the proposer.
4. EVALUATION CRITERIA AND FUNDING PROCESSES
Evaluation of all proposals will be accomplished using the following criteria, which are listed
in descending order of relative importance: (1) Contribution/relevance to the overall DARPA
SUO program; (2) Quality and technical merit of the proposed program; (3) The degree to which
technical data and/or computer software developed under the proposed contract are to be delivered to DARPA with unrestricted rights; (4) The offeror's ability to implement the proposed approach as demonstrated by specific accomplishments in the technical field to be studied, by availability of qualified personnel, and by appropriate facilities; (5) Proposed cost and cost realism.
Note: Cost realism will be used only as an evaluation criteria in proposals which have significantly
under or over estimated the cost to complete their effort.
You will have a similar set of criteria, but these criteria are used mainly to determine
how your finished project is GRADED. All of your proposals will be “accepted” (i.e.,
“funded”) but that’s not ture in the real world. Of course, “cost” doesn’t really enter
into this, but you are expected to show a believable plan for how the work will be split up
among a limited number of team members, and also to provide a rough schedule for
completion of what you consider to be the key elements (“milestones”). This is often
called a “management plan.”
All awards made in response to this BAA will be subject to availability of Government funds.
Evaluation and selection of proposal(s) for award will be made to those offerors whose proposals
are considered most advantageous to the Government. The Government reserves the right to select for award any, all, part, or none of the proposals received in response to this announcement.
As soon as the proposal evaluation is completed, the proposer will be notified of selectability or
non-selectability. Selectable proposals will be considered for funding; non-selectable proposals
will be destroyed (one copy of non-selectable proposals may be retained for procurement file purposes.) Not all proposals deemed selectable will necessarily be funded. Decisions to fund selectable proposals will be based on funds availability and the above evaluation criteria. The Government reserves the right to select for award all, some, or none of the proposals received. All responsible sources capable of satisfying the Government's needs may submit a proposal which shall
be considered by DARPA.
3
I’ve written lots of “selectable” proposals that were never funded!
5. FORMAT
The title page for both the preproposal and proposal must reference BAA 97-20 and list the
title, the preproposal/proposal date, the name and address of the offering institution(s), the principal investigator's name, phone number, fax, e-mail if available, and address if different from the
offering institution, the duration of the proposed effort, and the signature of an authorized official
from the submitting institution(s).
Everyone has arbitrary formatting rules, and these are not the same as those of
ECE2031. But the intention is the same – to create a readable style and some uniformity
across ALL the documents provided by different authors.
Documents must be prepared as follows: single-sided, double-spaced pages; page size not
larger than 8 1/2 X 11 inches; font to be not smaller than 12 point; one-inch left/right margins,
1.25 inch top margin, 0.5 inch bottom margin on all sheets.
5.1 PREPROPOSAL FORMAT
For a large project like this, you might have to do TWO proposals. The first one is simpler, more like what you would do in ECE2031. In industry and government, this might
be called a “preproposal” as it is here, or perhaps a “white paper” or a “proposal abstract.” Later on, if the sponsor like the preproposal and a full proposal is also written,
the preproposal may be used almost in its entirety to make up an introductory section
that is often called an “Executive Summary.” This is very similar to our notion of an
abstract, but a bit longer, since it summarizes a much longer document.
Offerors are encouraged to submit a preproposal which serves as an initial screening to save
bidders the time and expense of developing detailed proposals that may have little chance for
award. The preproposal title page should include rough estimates of total funds requested for
both Task 1 and Task 2. Preproposals shall be strictly limited to 15 pages. The 15-page preproposal limit does not include the title page, but does include all figures, charts, and/or tables. The
preproposal should include: (1) a discussion of the technical approach; (2) major tasks and schedules; (3) briefly identify technology demonstrations (if applicable); (4) a brief discussion of key
individuals and/or team members and their roles; and (5) one-page cost estimate with options
costed separately. Preproposals should only contain a rough estimate of cost. Handwritten and
faxed preproposals will not be accepted. Acknowledgment of receipt of preproposals will not be
made. Preproposals will not be returned.
4
5.2 PROPOSAL FORMAT
Full Proposals shall contain technical and cost sections and shall be strictly limited to a maximum of 30 pages, not including the title page. The proposal title page should include total funds
requested from DARPA for the base contract without options.
The technical section must contain, but is not limited to (1) a title page; (2) a table of contents; (3) executive summary; (4) concept description; (5) program plan; (6) a Statement of Work;
(7) schedule or milestone chart; (8) description of facilities, equipment and personnel; and (9) description of prior relevant work.
This is a lot of material. Again, what we do in ECE2031 is a lot more like what is called
a “preproposal” here.
The Cost Section shall include a cost summary and detailed cost breakdown. The cost summary should be shown to the level of major tasks and should indicate manpower levels of effort
(labor hours and cost), cost of equipment, travel, G&A and other miscellaneous expenses for the
tasks of the entire program. Details of cost sharing proposed, if any, must be included. Cost data
for team members or subcontractors shall be identified under the appropriate tasks. Cost data for
options should be presented separately.
5
Download