Request for Proposal

for

<project>
Version 1.0 draft 1
Prepared by <author>
<organization>
<date created>

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 2

Table of Contents
Table of Contents...........................................................................................................................ii
Revision History.............................................................................................................................ii
1. Statement of Confidentiality...................................................................................................1
2. Abbreviations, Acronyms, and Definitions............................................................................1
3. Introduction..............................................................................................................................1
3.1 About Our Company............................................................................................................1
3.2 About this Request for Proposal..........................................................................................1
3.3 Submitting Proposals...........................................................................................................1
3.4 Accepting Proposals.............................................................................................................2
3.5 Contracting Schedule...........................................................................................................2
4. Proposal Preparation Guidelines............................................................................................2
5. Project Overview......................................................................................................................4
6. Statement of Work...................................................................................................................4
6.1 Project Organization............................................................................................................4
6.2 Communication....................................................................................................................4
6.3 Dependencies and Constraints.............................................................................................4
6.4 Design, Development, and Implementation Methods..........................................................4
6.5 Evaluation and Monitoring..................................................................................................5
6.6 Change Management...........................................................................................................5
6.7 Product Acceptance..............................................................................................................5
6.8 Support and Maintenance....................................................................................................6
7. Supplier Requirements............................................................................................................6
8. Technical Requirements..........................................................................................................7
9. Deliverables..............................................................................................................................7
10. Cost and Schedule Estimates..................................................................................................8
11. Contracts and Licenses............................................................................................................8
11.1 Purchase Agreement.........................................................................................................8
11.2 Licensing Agreements......................................................................................................8
11.3 Intellectual Property Ownership......................................................................................8
11.4 Supplier Warranties..........................................................................................................8
11.5 Performance Bonds, Late-Delivery Penalties, and Early-Delivery Bonuses...................8
11.6 Maintenance Contract......................................................................................................9
11.7 Supplier-Supplied Training..............................................................................................9
11.8 Nondisclosure Agreements..............................................................................................9
12. Proposal Evaluation Criteria..................................................................................................9

Revision History
Name

Date

Reason for Changes

Version

initial draft

1.0 draft 1

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 1

<Note: This template contains both guidance text, shown in italics, and boilerplate text, shown
in normal text. When creating an RFP from this template, customize the boilerplate text to suit
the specific details of the project. Remove the guidance text and insert your own specific
information for the project. Do a global replace of the string <acquirer> with the name of
your company.>

1. Statement of Confidentiality
This Request for Proposal (RFP) contains confidential and proprietary information that is the
property of <acquirer>, which is provided for the sole purpose of permitting the recipient to
respond to the RFP. The recipient agrees to maintain such information in confidence and not to
copy nor disclose this information to any person outside the group directly responsible for
responding to its contents. The contents of this document may not be used for any purpose other
than preparation of a response to this RFP. Should <supplier> not be chosen for the engagement
described in this RFP, <supplier> must return all copies of this RFP to <acquirer contact
person> at <acquirer address> immediately upon notification that <supplier> was not selected.

2. Abbreviations, Acronyms, and Definitions

<List any specialized terms or abbreviations and their definitions.>

3. Introduction
3.1 About Our Company
<Provide a brief description of your company and its products, locations, size, lines of business,
organization, and so on. Indicate where the product being subcontracted fits into your
companys environment or product line.>
3.2 About this Request for Proposal
<acquirer> is issuing this RFP for systems and software development services for <project>.
Your company is invited to respond to this RFP. <acquirer> will compare the competitive
advantages that your proposal offers with those from the other responding companies. Proposals
will be evaluated in terms of satisfaction of the technical requirements set forth in this RFP,
quality, delivery schedule, price, project management, and risk management. <acquirer> intends
to identify a short list of qualified respondents and, ultimately, to select a supplier for this
project.
This RFP is not an offer to contract. Issuance of this RFP and the receipt of responses by
<acquirer> do not commit <acquirer> to award a contract to any bidder.
3.3 Submitting Proposals
Please acknowledge receipt of this RFP and reply indicating whether your company intends to
submit a proposal by contacting <acquirer contact person> via e-mail at <e-mail address> no
later than <date and time>. If your company does intend to submit a proposal, please provide the
name, mailing address, e-mail address, telephone number, and fax number from the
representative from your company who will serve as the single point of contact for all

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 2

communications regarding this RFP. If your company chooses not to submit a proposal, please
return all copies of this RFP immediately to <acquirer contact person> at <acquirer address>.
The costs of preparing a proposal are the sole responsibility of your company. All proposals and
supporting documentation submitted with the proposal become the property of <acquirer>.
Proposals must be prepared according to the description in section 3, Proposal Preparation
Guidelines.
Submit questions regarding this RFP in writing to <contact person, e-mail address, fax number>.
<acquirer> will provide copies of all questions and their answers to all bidders who received this
RFP.
Submit your proposal in hard copy form to <acquirer contact person> at <acquirer address>. All
proposals must be received in the required format by <date and time>. Proposals received after
this time will be returned to the supplier without being considered.
3.4 Accepting Proposals
<acquirer> will evaluate submitted proposals according to the criteria summarized in section 12,
Proposal Evaluation Criteria. <acquirer> may accept or reject any proposal, whether or not it
satisfies the requirements stated in this RFP. <acquirer> reserves the right to negotiate further
with bidding suppliers.
Your response to this RFP constitutes an offer by you to do business with <acquirer> on the
terms stated in your response. Should your company be selected, <acquirer> may incorporate
any portions of your response into negotiated agreements.
In the event that <acquirer> decides not to accept your proposal, you will be so notified.
<acquirer> reserves the right not to communicate the basis upon which its decision was made.
3.5 Contracting Schedule
Milestone
Issue RFP to suppliers
Intent to bid or withdraw
Written proposals submitted
Site visits or surveys
Supplier selected
Negotiations completed
Contract executed and purchase
order issued

Date Due

Deliverables
RFP
E-mail notification
Proposals in hardcopy
none
Written notification
Final statement of work
Contract, purchase order

Responsibility
<acquirer>
Supplier
Suppliers
<acquirer>
<acquirer>
<acquirer>
<acquirer>, supplier

4. Proposal Preparation Guidelines

<Describe the contents, organization, and document layout and formatting (fonts, margins,
sections, etc.) for the proposals. A standard proposal format will make it easier to compare
proposals received from different suppliers. Suggested proposal contents include the following,

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 3

but check to ensure that the items you request are both appropriate and necessary for a project
of this nature and size. Theres no point in making the proposal process any more burdensome
for the supplier than necessary, so make sure you know how you will use all of the information
you request

Cover letter that specifies the legal name and address of the supplier, the
name and contact information of the individual who is authorized to respond to
issues raised by <acquirer>, and the name and contact information of the individual
who is authorized to conduct negotiations and execute a contract

Executive summary containing a brief description of the proposed project

development approach

Corporate history and information, including financial details

Qualifications, including previous acquirers for whom the supplier has done
work with contact information (for references), and cost, schedule, and quality
performance data (actual versus estimates) on previous projects

CMMI maturity level, ISO 9000 registrations, other software process

qualifications, conformance to IEEE or other established standards, status of
software process improvement activities

A description of the development process and software development life cycle

to be used

Processes to be used for requirements management, configuration

management, testing, and quality assurance

A statement of work that incorporates the SOW included in this RFP with any
appropriate modifications or additions, leading to a full description of the suppliers
proposed statement of work for the project

A project plan that includes:

1. the major project milestones and deliverables from each
2. the proposed team and the team members qualifications; evidence of technical
skills, technical staff, and available resources
3. proposed schedule and how it was derived, including contingency buffers
4. assumptions the supplier made
5. dependencies on external factors, third parties, or acquirer-supplied materials
6. an analysis of significant project risks
7. the suppliers proposed tradeoffs between functionality, quality, schedule, and
cost

Estimated project costs and payment details, including software development,

any needed hardware, system software, third-party components that must be
licensed, consumables, installation and checkout, maintenance and support,
training, documentation, travel expenses, and any other costs not specifically
requested by the acquirer

Payment milestones and the amount due at each

Any other terms and conditions that the Supplier wishes to impose on the
contract or project

How the supplier intends to satisfy the stated evaluation criteria

A suppliers section, to include information the supplier feels is relevant or

useful for the project, but which is not required or requested elsewhere in the RFP>

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 4

5. Project Overview
<Provide a concise vision statement that gives a high-level description of the product being
developed, its context and origin, its intended purpose, scope (what will be included) and
limitations (what will not be included), and your primary business objectives.>

6. Statement of Work
<The statement of work states the management requirements for the project, describing the
acquirers expectations from the supplier and the ways in which the acquirer and supplier will
work together.>
6.1 Project Organization
<Identify the project manager, suppliers subcontract manager (primary point of contact
for the supplier), subject matter experts, any technical coordinators, verification
engineers, testing and quality assurance staff, and other key personnel. Describe their
roles and responsibilities with respect to the subcontracted project.>
6.2 Communication
<Describe how communications will be conducted and managed between the acquirers
subcontract project manager and the primary point of contact at the supplier. Describe
how technical interactions between other key members of the supplier and acquirer staffs
will take place. Possibilities include face-to-face meetings, teleconferences, and
commenting on documents through word processor revision markup and inserted
annotations (such as Microsoft Word comments). Identify points at which face-to-face
interactions will be needed and the expected participants. Indicate who will be responsible
for travel costs for such meetings. Identify the key project decision makers on the acquirer
side.>
6.3 Dependencies and Constraints
<Identify any known dependencies that this project has upon external factors, such as
other projects or products or components to be reused from previous projects, as well as
key intraproject dependencies. Itemize any constraints within which the project must
operate, including pertinent corporate policies, industry standards, government
regulations, or other business rules.>
6.4 Design, Development, and Implementation Methods
<Specify the technical methods and the development tools and environments to be used for
building the product. Include design modeling conventions or tools, source code control
procedures, quality assurance and testing procedures, backup and recovery procedures,
and the like. Indicate who will be the intellectual property owner of the design
documentation. Indicate how the design will be reviewed, with participation by the
acquirers technical staff.>

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 5

6.5 Evaluation and Monitoring

<Describe how the acquirer will work with the supplier to track and measure progress
throughout the project, addressing the following points:

Frequency, format, mechanisms, and contents of status reporting

Tracking of actual results against the plans and estimates.
Quality checkpoints and joint reviews of work products that will involve
representatives from both the acquirer and the supplier. Indicate the supplier team
members (by role) who will participate in the major reviews and the approximate
review schedule.
Status documents that the acquirer will review at defined checkpoints.
How replanning will be conducted when necessary.
How testing progress and defect statistics will be tracked.
How issues requiring corrective action will be raised, documented, communicated,
escalated, and resolved.
How to handle situations in which the acquirer or supplier fails to produce an
expected deliverable on schedule.
How project risks are to be managed and how frequently the supplier will provide
the acquirer with the current risk list and status of risk management actions.
The measurements that the acquirer will perform after the project is completed, such
as cost and schedule performance compared with estimates and product quality.>
6.6 Change Management
<Indicate how changes in scope, requirements, technology, and the contract are to be
proposed, evaluated, resolved, and communicated. Describe how the impact of changes on
the projects schedule, cost, or quality will be resolved. State who is responsible if
information not originally provided by either the acquirer or the supplier turns out to
significantly affect cost or schedule estimates, and who will pay for corrections that need
to be made in information or materials provided by either party.>
6.7 Product Acceptance
<Describe how the acquirer will evaluate both interim and final deliverables for
acceptability, including both executables and nonexecutables. If you will provide more
detailed customer acceptance criteria to the supplier prior to project completion, describe
what you will deliver and when. Indicate the time limit for performing acceptance
procedures, how the acquirer will inform the supplier of the acceptance procedure results
and of issues that arrive, how issues will be tracked and resolved. Consider defining
quantitative quality targets, such as performance goals, estimated residual defect
densities, or defect removal effectiveness (e.g., 97% defect removal effectiveness means
that the supplier removed 97% of all defects found during development acceptance, and
the first three months of operation.
Consider defining acceptance criteria selected from the following categories:>
Functional Testing
Defect Data

Evaluation of the testing of product functionality to determine

whether the testing is adequate for ensuring quality and fitness
for use in the products intended operating environment.
Evaluation of product defect information. Verification of correct
product operation for top-priority features.

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 6

Product
Reproducibility

Evaluation of the ability to accurately and consistently rebuild

the software product. Ensure the consistency of the product
package contents with the expectations for the released product
package (e.g., through a configuration audit).
Install Testing
Verification of correct product install and uninstall in target
environment. The installation procedure must be fully
documented and automated as much as possible.
Customer
Contracted user manual and maintenance documentation must be
Documentation
provided in either hard copy or online format. Evaluate product
user documentation for accuracy and consistency with product
operation.
Compatibility Testing Evaluation of the product to perform its required functions while
sharing the same environment with other systems or components.
This includes binary sharing, data sharing, hardware and
operating system environments, and backward compatibility.
Legal or Regulatory Evaluation of product compliance with pertinent legal and
Compliance
regulatory requirements, such as Underwriters Laboratory.
Evaluation of documentation confirming required validation to
satisfy regulatory agencies, such as FDA. Verification that
products development process would pass any pertinent
compliance audit, such as FDA.
Continuous
Evaluation of the products operation over a period of time to
Operation
detect time-dependent defects such as memory leaks, race
conditions, and other factors that reduce reliability.
Performance
Evaluation of the key performance attributes of the product to
Measurement
determine whether performance goals are met.
Standards
Compliance

Evaluation of product compliance with product standards or

other industry standards.

6.8 Support and Maintenance

<Describe the expected level of ongoing support and product maintenance that the
supplier is expected to provide. This section could be written as a service-level agreement,
addressing the expected response times to reported defects, technical assistance with
maintenance, transfer of skills and knowledge to acquirer staff, delivery of new releases of
commercial components, and future enhancements.>

7. Supplier Requirements
<Describe the qualifications of the development, management, quality, and maintenance staff
that the supplier is to assign to the project. These qualifications could include specific skills,
education, years of experience in the problem or technical domain, professional certifications,
and the like. These requirements are intended to prevent the supplier from assigning
unqualified, inexperienced staff (e.g., co-op students) to the project.
Indicate that the records retention policy of the supplier is to match the acquirers corporate
policy.

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 7

State that all development and testing be done using legally licensed versions of the tools used.
Indicate whether the supplier is to comply with any specific standards for development of
safety-critical products.
State that the acquirer has the right to inspect the development premises and facilities, and to
conduct project and technical reviews at the suppliers site. Specify the review frequency, if
specific reviews are planned.>

8. Technical Requirements
<This section contains the software or system requirements for that portion of the product that
will be outsourced. The reader must be able to distinguish requirements from descriptive
information. Also, distinguish mandatory requirements from optional requirements. A supplier
proposal that does not satisfy all mandatory requirements may be disqualified. This section
should include the same sections that appear in the software requirements specification
template.>

9. Deliverables
<Itemize the interim and final deliverables to be produced for the project. Include both
technical and project management deliverable. Possible deliverables include, but are not
limited to, the following:

supplier-written requirements specifications

design descriptions and database definitions
user interface prototypes
source code for APIs DLLs, and executables
test plans, cases, procedures, and reports
suppliers software development plan and any revisions made to it
work breakdown structure
help screens and other user documentation
status, schedule, and cost reports and metrics
change request reports and metrics
defect tracking reports and metrics
performance metrics
support and training documents
maintenance documentation
configuration management plan and reports
build procedures and scripts
installation scripts and procedures, operating manuals
requirements traceability matrices

Specify the media and form in which the supplier is to provide each deliverable. Indicate whether
the complete set of historical versions of a deliverable is to be provided and, if so, using which
version control tool.
Itemize user documentation to be produced, such as help screens, reference manuals, and tutorials.
Define any standards the supplier is to follow when preparing documentation or other deliverables.
Specify the level and nature of code comments to be included. Consider including an example that
shows the type, level, and depth of documenting that is expected.>

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

10.

Page 8

Cost and Schedule Estimates

< Indicate the dates when development is to commence, and when delivery is expected. Provide
your own cost and schedule estimates, presented as a range. This will help you judge whether a
proposal is plausibly achievable. Indicate that the supplier must justify any cost or schedule
estimates that are significantly outside the range you present.>

11.

Contracts and Licenses

<Describe the contract and other legal documents to be executed, including the following items.
The suppliers proposal will provide the details of some these elements. Consider attaching a
sample of the purchase contract that will be used to the RFP, inviting suppliers to review the
attached contract and list in their proposal any potential issues. The contents of this section and of
the contract itself should use the acquirers standard corporate legal language.>
11.1

Purchase Agreement

<List the elements that will go into the purchasing agreement and any standard terms.>
11.2

Licensing Agreements

<These agreements will identify the terms and the initial and recurring costs of any licenses that the
acquirer must procure for this project, either from the supplier or from third parties. Licenses might
be necessary for package or reused components or that will be integrated into the developed
product.>
11.3

Intellectual Property Ownership

<State the intellectual property ownership rights that the acquirer and the supplier shall have with
respect to products developed by the supplier, existing supplier components that are integrated into
or reused in the product, and third-party components that are integrated into the product. State who
owns uncompleted work products if the contract is terminated prior to final delivery.>
11.4

Supplier Warranties

<State the warranties that the supplier is to provide for the various system components, including
any to be provided by third parties.>
11.5 Performance Bonds, Late-Delivery Penalties, and Early-Delivery
Bonuses
<Describe any performance bonds, escrow funds, letters of credit, or the like that the supplier will
be requested to post. These items help protect the acquirer against supplier nonperformance.
Performance bonds are not required. If you decide to use them, work with your companys legal
counsel to define the specifics of such bonds.
Define cost penalties that the acquirer will apply for missed milestones or late delivery of the
contracted product. Examples: 5% penalty for each month that supplier-tested code is late; 5%
penalty for each additional 0.5 defects/KLOC discovered in system test over 2.0 defects/KLOC 5%
penalty for each additional 0.2 defects/KLOC discovered after delivery to customers over 0.2

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.

Request for Proposal for <Project>

Page 9

defects/KLOC. Contractual penalties are not required. If you use them, select appropriate numbers
for the nature of your project.
Describe the financial bonuses that the acquirer will pay if the supplier delivers a product of
acceptable quality and functionality ahead of schedule or if the supplier delivers a product with
exceptionally few defects. Bonuses could include a monetary bonus for exceeding schedule and
quality requirements, or an equity stake or shared IP ownership of the product. Examples: 5%
bonus if supplier-tested code is available 1 month before the contracted date; 10% bonus if the
number of defects discovered in system test is between 1.0-1.5/KLOC, with a higher bonus for a
lower defect density. Contractual bonuses are not required. If you use them, select appropriate
numbers for the nature of your project.>
11.6

Maintenance Contract

<If a specific maintenance contract is to be executed, identify the elements of the maintenance and
support contract or service-level agreement that is to be executed, including the duration, costs,
services covered and not covered, communication mechanisms to be used between supplier and
acquirer. Include categories for software defect correction, adaptive maintenance, training, hotline
or help desk, and enhancements and extensions. Do not duplicate information from section 6.8
Support and Maintenance here.>
11.7

Supplier-Supplied Training

<The supplier is expected to list, by course, the hours and total cost of training services that
supplier personnel will provide to acquirer staff.>
11.8

Nondisclosure Agreements

<State the nondisclosure and confidentiality agreements that the supplier or individual supplier
employees will be asked to execute.>

12.

Proposal Evaluation Criteria

<Describe the criteria you will use to evaluate proposals. This might include the suppliers project
management and technical capabilities, the technical methodologies they intend to use, and their
approach to requirements management, configuration management, and quality assurance. You
might also use the suppliers track record on projects for previous acquirers, CMMI maturity level
or ISO registration, and the like. You may include the proposal evaluation matrix, but you might not
wish to include the weight given to each element in the matrix.>

Copyright 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.