Part 4: Sample RFP
Here is an outline of a simple RFP.
Purpose. Here you briefly state the problem you are trying to solve; details will come later. For example, the Purpose might be "To provide a computer system for the ABC Museum to support its registration, collections management, curatorial, educational, conservation, and exhibitions functions. The system must include a public web interface to the database of museum objects." You should also indicate the size and complexity of the problem, such as the collections to be managed, the number of objects, the number of museum departments and buildings, remote locations if any, and unusual functionality required. This helps vendors to know if their systems are at least in the ballpark without having to read the entire RFP.
Scope. The purpose of this paragraph is to tell the bidders what kinds of deliverables they would supply: software, hardware, networking, services, etc. This is a good place to state whether custom development is acceptable or whether you require an established product. The duration of the proposed contract goes here too, although for CMS procurements, this isn't required unless you are proposing a partnership or other close relationship. (CMSs are usually an outright sale plus annual licensing and support costs.)
Multiple awards. "Award" is the term used in procurement to mean the acceptance of a proposal. State here whether you will you be awarding a contract to a single vendor, or will vendors be asked to work together. Also indicate whether vendors may submit joint proposals, for example if one company supplies the system and another provides support and training.
Timetable. Give an indication of your desired implementation schedule. There will be a detailed timetable later also.
How to submit proposals
This section outlines the rules bidders must follow as they prepare their proposals. Here are some suggested rules.
The statement of requirements is where the problem is described in detail.
Requirements are of two kinds: Mandatory and Desirable. Mandatories are those requirements that the system absolutely must have or you cannot use it. A proposal that does not meet the Mandatory requirements need not be considered further.
Desirables are the requirements that will be used to compare the proposals. If you imagine you and your team sitting around a conference table trying to understand how several different systems implement a certain functionality, you will realize that simply asking bidders to answer yes or no to requirements will not help much. That is why I specified above that bidders must describe the method or approach they use to meet each requirement.
The most common mistake made is to have too many requirements. If you have hundreds of Mandatories, no system will meet them all. Thus you will end up re-evaluating which Mandatories are really mandatory. It is better to do this as the RFP is written. Mandatories should be limited to essential points of architecture, functionality, and scalability. To do otherwise only limits your choices, which are already very few in this market.
For example, you may feel that the system absolutely must handle your images of a certain size or format. However, it may be that converting the images will work just as well, and not limit your choice of system. In other words, try to state your problem, but allow the bidders to propose solutions. This will generate a lot more alternatives to choose from. To specify the solution instead of the problem just reduces your options.
Here are some examples of what might be Mandatory requirements:
As with Mandatories, Desirables should also be kept few. All too often, it is felt that a program or process that is not represented in the RFP is somehow unimportant. Drafting the RFP turns into a turf battle. Just keep visualizing yourself trying to evaluate the proposals: will you really downgrade a system because you can't change the look of the data-entry screens? What if that system is otherwise the best?
One of the hardest parts of the evaluation is to compare costs, because each vendor prices their system using a different formula. Therefore it is up to you to provide a level playing field.
You do this by including in the RFP what I call a "costing scenario." This describes the expected volumes the system must handle (not the maximums), so you can get a realistic picture of what each system will cost each year. The RFP should state that you require that bidders to use the scenario in costing.
The main points for the costing scenario are:
These points enable the bidders to provide costs of the license, the hardware, and the training. Most will also have additional costs, depending on the extent to which they itemize.
One of the largest costs is also the hardest to estimate, or to provide a scenario for -- data conversion. Most bidders will provide a ballpark estimate, based on the number of records you have, but data varies so much that this can be only an indication. The cost of data conversion is one of the major topics for discussion with the short list of vendors who you negotiate with. At that point they will probably want to see samples of each type of record.
Sometimes the method of evaluating the proposals will be included in the RFP. Whether or not you do this, you should be preparing an evaluation plan as you write the RFP. The plan should be complete and in writing before the RFP goes out. It is as important to get museum-wide agreement on the evaluation plan as it is on the requirements.
Evaluation should be done by numeric scoring; this is your best chance of getting the system that best meets your needs. Generally about 75% of the total points are given for the technical proposal, and 25% for the costs, but this can be varied to meet your needs. You should outline how the points for the technical proposal will be assigned, such as 10% for registrarial functions, 10% for public access, etc. Alternatively you can assign points to each major area instead of percentages.
Within the technical proposal, the various requirements will be weighted so that more important requirements weigh more heavily in the decision. That is, there may be eight requirements that make up the registrarial functions; unless the eight are all of equal importance you should weight them (a scale of 1 to 5 is sufficient, 5 being the most important). Weights will be assigned after the technical requirements are written.
As you evaluate each proposal, you assign a score for each requirement. A scale of 0 to 5 works well, with 5 meaning the requirement is met exceptionally well and 0 meaning the requirement is not met. Then the scores are multiplied by the weights to arrive at total scores.
The cost scores should be based on the total five-year cost of each system. You can ask bidders to supply this number, but you should also calculate it yourself. You give the cheapest responsive proposal the maximum possible points and the most expensive zero points. The others are interpolated mathematically. Obviously this means the bidders must be costing using the same assumptions. That is why you required them to use the costing scenario.
Will demos be required of vendors? Usually this is a good idea for the two or three top scoring proposals, not for all of them. As you evaluate the proposals, make a list for each vendor of the points you want demonstrated. Part of the demo should be allowed the vendor to show what they think is important, but part should be given to having unclear features clarified.
Finally, talk to your colleagues at other museums who use the systems you are considering. This is the best way to find out about vendors' honesty, reliability, and responsiveness. This is a good way to clarify vague or subjective matters. For example, no vendor will say their system is hard to enter data into, so go watch how it's done at another museum.
List the major dates in the procurement process, such as:
The actual dates will be part of the contract negotiation, but this gives everyone a framework
Since the RFP and proposal are legal documents, and also become the basis for a contract or license, I'm sure your legal department will want to include boilerplate.