This page is powered by Blogger.





Contacting Us
Mike Tarrani
Linda Zarate
Kate Hartshorn

Who We Are
TEAM Zarate-Tarrani

Our main weblog
Notes from the Field

Our other pages
Mike's home page
Linda's home page
Kate's home page

Simpatico [we]blogs
Dan Gilmore
Robert X. Cringely
Jakob Nielsen
Julian Bond
Deborah Branscum
Lisa Rein
Ed Yourdon


Wednesday, March 27, 2002


Software RFPs. A friend recently asked if I had an example RFP for software development. The short answer was I had a few, but like all RFPs they were poor examples. I've been on both sides of the RFP process: I've written them and managed the vendor evaluation and selection process, and I've responded to them with proposals. Rare is the RFP that does the either party justice (rarer still are proposals that completely respond to RFPs, but that issue is for another time).

If you want it done right, do it yourself, so I'm going to take this opportunity to develop an RFP template and share it with all who needs one.

The Goal. The goal of the RFP is to clearly communicate what it is that you're seeking, and to give potential bidders enough information with which to propose a solution that is matched to your needs. An RFP epitomizes capitalism at its finest because you want something someone else has, and they want your money in exchange for it.

An RFP also is an exercise in risk management because you don't want to pay more than necessary to to get what you want. In the seller's case, value is at risk. The sellers who will be responding with proposals will be competing for your money, and risk bidding too high and losing your business or bidding too low and leaving money on the table (or losing money).

There are other, more subtle risks inherent in the process that go to the stability and track record of the seller, the quality of their work, their ability to warrant their work and make good on the warranty, and ownership of the product after it has been developed and delivered. All of these will be addressed in the discussion below.

Elements of the RFP. Here are the minimum elements of a software development RFP and why they are necessary:

  1. Statement of Objectives - describe what you are seeking in general terms. Example: Company is seeking the development of a software application to sort widgets.

  2. Background - give the background in a paragraph or two that sets the context of your objective(s). Example: A workflow study concluded that our manufacturing facility can reduce cycle time by 30% and improve quality by 50% if newly manufactured widgets are sorted by size and color before they are sent to QA. The software application we are seeking is an initiative sponsored by our VP of Manufacturing to implement a system that results in the improvements cited in the workflow study.
  3. Environment - Describe the technical environment that will determine how the respondents to the RFP approach crafting a proposed solution. Example: The system operates on a 24x7 basis, supporting geographically dispersed manufacturing locations across three time zones with two 10-hour shifts in each time zone. We use IBM AS/400 midrange systems that are located in our West Coast data center. The applications to which our widget counting solution must interface are written in RPG/400. We use IBM Client Access/400 and Rumba 5250 terminal emulation from Windows 98 and Windows 2000 PCs. Access to the midrange systems are via point-to-point circuits from each remote facility. Each circuit is sized to allow each remote user 56 kbps of bandwidth, and all terminate into a 100 mpbs switched Ethernet environment in our central data center.
  4. Policies, Standards and Methods - List all mandatory policies and standards with which vendors are expected to comply, and methods that you employ to which they will need to align. Example:
    • [Company] has policies in place for change control and release management (copies to be provided under non-disclosure to bidders that make our short list) with which the success bidder must comply.
    • We use Rational ClearCase software configuration management software and will make one licensed seat available to the success bidder to be used during the life of the contract.
    • The system into which the application we are requesting will be integrated has the following service level objectives [list them]. These service level objectives cannot be degraded by any proposed solution.
    • We are in the process of standardizing on Windows 2000 with plans to migrate to Windows XP in 9 months. Any proposed solution must work with our existing and planned standards, and not conflict with the standard software suites and configurations for [Company] desktop PCs that are provided in Attachment A.
  5. Statement of Work - Completely describe what you want in unambiguous language. Make sure that the following are covered:
    • Requirements and specifications. Express requirements as business rules for the best results. Example: The application will:
      1. Sort all widgets in two passes: (1) by size and (2) by color.
      2. Group all widgets of the same size and color
      3. Create a routing slip that provides a count of each group and route widgets as follows: Size less than 1" and Color = any to QA station #1, Size greater than or equal to 1" and less than 2" and Color = any to QA Station #2, Size greater than or equal to 3" and Color = any to QA Station #3.
      4. If any Group has only one widget create an exception report that documents the operator (from the WIDGET_OP table), date and time (from the RUN_DATE table) and the size and color (from the widget_size and widget_color columns in the WIDGET_BATCH table). The PK/FK will be the run_number attribute in all of the above tables.
    • Provide all specifications. Example: The application will use Client Access/400 data queues as the means of inputting data into the system. The application will use standard SQL queries to extract any necessary information from the system.
  • List service level management requirements: Example: Any problems with the application that are not detected in acceptance testing must be resolved in accordance with our standards for problem management. Definitions for severity and priority levels are provided in Attachment B.
  • Terms and Conditions. Although your organization probably has a standard format, make sure the following are considered:
    • who owns the source code - if the vendor, will the source code be placed in escrow so you have access if the vendor goes out of business?
    • specify expectations for corrective action for defects discovered after the software has been accepted
    • specify in clear language acceptance criteria before payment will be made; if you you're using progress payments, what are the quality gates for each progress stage

    Also be aware that acceptance testing is your responsibility and the criteria for acceptance needs to be clearly stated in the RFP.