Automating Your Museum

A five-part series

Stephen R. Toney
President & CTO, Systems Planning
Published on, February 2000

Copyright 2000


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.

  • Bidders must answer every question
  • Bidder must submit separate technical and cost proposals. This is because the technical evaluation is more objective if done without knowing the costs. Therefore the cost proposal should be bound separately so it can be hidden from the evaluation team until the technical evaluation is finished (this includes you!). The costs are then factored into the technical analysis to arrive at a final score.
  • In the technical proposal, bidders must, for each requirement, indicate whether they meet the requirement fully, partially, not at all, or plan to in future. You should indicate what codes bidders can use to indicate these. In addition, for each requirement, bidders should describe the method or approach they use, and what they mean by "partially."
  • Bidders must supply information about the company and its clients, products and services. Of particular interest is a list of museums which have installed the vendor's CMS. The RFP should require that the bidder indicate which existing installations use the same system they are proposing for your museum.
  • Indicate where to send proposals, number of copies, due date. State that late proposals will not be accepted.
  • Describe how vendors can get clarification on the RFP, such as that questions from vendors must be received within 15 days of the date of this RFP, and that responses will be sent to all vendors within 48 hours (this keeps the playing field level).
  • Cost proposals must show all costs, both startup costs and annual costs for each year of the contract period. Any optional items should be clearly identified. Because costs depend on the size of the system needed, you will need to provide a "costing scenario" that the bidders are required to use. This is discussed below.


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:

  • System must be able to handle your existing content. List here the numbers and formats of data and media to be handled. How many now, how many eventually, and typical sizes. The expected maximum numbers should be given here; in the scenario, probable numbers will be given.
  • Existing hardware, networks, and systems the new system must integrate with (describe).
  • Use of whatever standards you now employ (list).
  • Support of remote locations (give number and distance)

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?

Costing scenario

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:

  • Expected numbers of records of each type for each year for the first five years, and typical record sizes.
  • Expected numbers of images and media for each year, and typical sizes.
  • Number of client computers for each year, distinguishing between staff and public computers. Actually, vendors price their licenses by the number of concurrent users, but they can estimate this better than you can if you provide the total numbers.
  • Expected dates for the implementation of each major function.
  • Number of staff to be trained.

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.

Evaluation criteria

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:

  • [some date] RFP sent out
  • 15 days after RFP deadline for requests for clarification
  • 45 days after RFP due date for proposals
  • 30 days after due date initial evaluation done, museum will request demos
  • 60 days after due date museum will make award
  • 90 days after award system installed
  • 180 days after award data converted and loaded

The actual dates will be part of the contract negotiation, but this gives everyone a framework

Legal stuff

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.

Part 1: Making a Plan       Part 2: Managing the Project       Part 3: Technology       Part 5: Making Decisions

All contents of website, including HTML and JavaScript, copyright © 1996-2014 Systems Planning. MWeb, InFORMer, and CAPS are trademarks of Selago Design, Inc. MARCView and MARConvert are trademarks of OCLC, Inc.