Request for proposals for a collections management system

Table of contents

• Introduction
• Planning and defining the project
  • Defining requirements
• Approaches to acquisition
  1. Purchase a commercial software package “off-the-shelf”
  2. Purchase a commercial software package and have it customized to perform functions specific to your organization
  3. Acquire an open-source software solution with a contracted development option
  4. Acquire an open-source software solution and develop in-house
  5. Develop a customized system
• Request for proposals overview
  • Cover page
  • Background
  • Technical environment
  • General contracting information
  • Timeline
  • Scope of work
  • Limitations
  • Collections management requirements
  • Submission requirements
  • Contractual details
  • Evaluation criteria
  • System demonstration
• In closing

Introduction

This document provides guidance on the information that is typically included in a request for proposals (RFP) issued for a collections management system (CMS). In creating an RFP, you are setting out your requirements and objectives on which potential providers can place bids for a CMS solution.

As each organization’s needs are different, RFPs vary: they can be extremely complex or relatively straightforward, depending on the situation. Even for a straightforward RFP, an organization will need preliminary research and planning to ensure that its needs are properly identified before proceeding, as the system will likely be in place for several years. These guidelines will help you with that process.

An RFP document should include enough detail to cover all of the elements that an organization would like to have within the final contract once the work has been awarded. It may seem like a lot of work upfront, but it will help save you from developing two separate documents and will keep your purchasing process fair and transparent.

Planning and defining the project

Establish a project team to:

• Determine the scope of the project
• Identify the reasons for selecting a new system
• Define the role of the project team
• Determine the contracting authority
• Identify the stakeholders involved, their roles and needs
• Define the exact requirements of the system
• Determine the timeline and the budget (both for installation and support)
• Establish a project schedule that includes planning, procurement, launch and testing phases
• Examine and document the current environment and status of collections documentation
• Identify the target environment
• Establish a communication strategy to inform people of possible upcoming changes

Even in a small organization without a large team, a project leader should be chosen to oversee the work.

Defining requirements

The first step in developing an RFP is to define the system requirements. To start, document all the information units and functions required in the system as well as the collections or information management processes used either in the current system or within your organization (if you do not have a CMS). This will help determine the strengths and weaknesses of your existing information handling practices and facilitate future improvements.

The Canadian Heritage Information Network (CHIN) Collections Management Software Criteria Checklist will help you identify required features necessary when building the “Requirements” section of the RFP. It is essential to consult your stakeholders—all individuals or groups in the museum who rely directly or indirectly on collections management information—when defining requirements. Document exactly what data will be entered in the system and what will be done with that data. This will determine what types of input and output are required. Consider both current and potential needs as well as current and potential users of collections data.

Approaches to acquisition

Once the needs of the organization and all users have been defined, you can choose one of several approaches to acquiring a CMS:

• A. Purchase a commercial software package “off-the-shelf”

  Purchase an application that is pre-built to perform all or most required functions, hosted either by your organization or by the software provider (as your situation permits). These software applications will differ in approach and emphasis but come pre-packaged with most of the information units and functionality required for use. Some compromises will usually be necessary in taking this route, as all stakeholders will rarely view one application as the perfect solution, but it is usually the most economical solution in both the short and long term. Benefits of off-the-shelf packages include ongoing development by the system providers and a pre-existing community of users.

• B. Purchase a commercial software package and have it customized to perform functions specific to your organization

  This type of customization may avoid some compromises necessary with off-the-shelf packages, but it will usually be more expensive and could preclude you from benefiting from future, general system upgrades by the software provider. The initial cost and ongoing support requirements will depend on the extent of customization. It may also be possible to purchase commercial software and customize as time and resources allow, although this possibility should be investigated at the outset.

• C. Acquire an open-source software solution with a contracted development option

  An organization may decide to adopt an open-source software solution and contract with a developer to customize the solution for their needs. The initial cost and ongoing support requirements will depend on the extent of customization, but contracting ongoing support means that you will not need the in-house expertise usually required for open-source products. This solution can apply to both cloud-based and in-house systems.

• D. Acquire an open-source software solution and develop in-house

  While open-source software can be free at the point of acquisition, it can prove costly to adapt and maintain, particularly in staff resource costs. This option should only be chosen by organizations with considerable information technology (IT) expertise to install, test, customize, maintain and support the software in the organization’s technical environment (or online, should a cloud-based solution be adopted). Note: This is included as a development option for your information, but it would not require an RFP if using in-house technical expertise.

• E. Develop a customized system

  This is done using programming software (e.g. Access or FileMaker Pro) that has no built-in collections management functionality. It requires a great deal of time and specialized expertise to design, develop and maintain a customized system. This option should only be chosen by organizations with either the abilities or funds to maintain and support the software once built, as there will be no provider or community of support on which to rely. It is rarely a timely or cost-effective solution.

When requirements have been identified and potential acquisition or procurement approaches considered, start to draft the RFP. In cases of complex projects, contracting expertise to help develop a detailed RFP may be necessary.

Request for proposals overview

These guidelines provide a basic approach to developing an RFP document. It is not intended for complex projects that require a consultant to manage the RFP process and should not be considered legal advice.

Cover page

To make it easier for potential bidders, provide a cover page that includes the name of your organization, the budget for the project, a short description of the RFP goal and a general timeline including the dates for RFP submission and overall project start-up and completion.

Background

Describe the organization, mandate and collection size and type, including expectations for growth in collection records. Also include the current state of digitized images and/or other multimedia material, related documents and online content, along with any plans for growth in this area.

Technical environment

Describe in detail any current CMS and the organization’s technical environment. The technical environment includes the network, operating systems, computing devices, browsers used, etc. For those looking to replace a CMS, some possible questions to guide you include:

• How many records will need to be migrated from the current system?
• How many people work with this system, and what kind of access do they currently have (for data entry and read-only access)?
• Is there a local system administrator?
• Are there multiple users?
• Are there any systems that it needs to be compatible with? (A digital asset management system [DAMS], for example.)
• Are there security considerations, such as firewalls?

Describe the current situation in as much detail as possible. If you are looking to acquire a CMS for the first time, some of this background information will be different. If you are migrating from a non-specialized spreadsheet or database system, describe what software and version you are using.

In some cases, a schematic for the technical system as well as a glossary of terms may be appended.

General contracting information

Provide contact information for the administrative authority (contracting agent) and any individuals that vendors can contact if they have questions. Document the process and timeline for questions and responses. Define the process for addenda based on responses to questions. Include cut-off dates for addenda requests.

Timeline

Outline the dates of the RFP, such as final dates for submitting proposals, timeline for the evaluation of the proposals and timeline for project start-up and completion. Identify major milestones along the way.

Scope of work

The scope of work and technical requirements form the core of the RFP and will require the most time to develop. The scope should outline in detail what the organization is seeking. The following questions will help frame this section, though they do not include everything that may be needed. Base the scope of work on your preliminary internal research.

• What are the major goals of this project?
• Is the CMS for internal management only, or is a CMS and online publishing interface required? (Collections database + exporting to virtual exhibits or online public access?)
• Is contribution to another type of external system required (e.g. a DAMS)? List any APIs (application programming interfaces) that may be required.
• If you seek an online (browser-based) solution, what is the list of preferred/compatible browsers?
• Do you have a preference for a cloud-based solution? If the answer is yes, are there security constraints regarding where the information is hosted?
• Do you prefer to store information on a local system?
• Would you like cloud-based backup of a local system?
• What are your expectations of the backup process, such as frequency and type?
• Who is expected to do the migration?
• What training and documentation will be required and in what format?
• What support is required during and after installation and for how long?

Limitations

Describe any specific limitations here. Describe the parameters of the project. Is ongoing support required or is support on a case-by-case basis needed? Are there limitations to the length of the contract?

Note the maximum budget.

Collections management requirements

CHIN recommends that Canadian museums follow the Spectrum operational procedures. Spectrum is a collections management standard developed by the Collections Trust in the UK and used worldwide. It is divided into 21 activities or procedures. Primary procedures are the ones which most museums will use most of the time. Museums should decide which of the procedures are required and should be supported by their future CMS. (The Spectrum 5.0 procedures are available online in English on the Collections Trust website. CHIN is in the process of translating Spectrum into French.)

The list of procedures is as follows:

• Object entry (primary)
• Acquisition and accessioning (primary)
• Location and movement control (primary)
• Inventory (primary)
• Cataloguing (primary)
• Object exit (primary)
• Loans in (borrowing objects) (primary)
• Loans out (lending objects) (primary)
• Documentation planning (primary)
• Condition checking and technical assessment
• Collections care and conservation
• Valuation
• Insurance and indemnity
• Emergency planning for collections
• Damage and loss
• Deaccessioning and disposal
• Rights management
• Reproduction
• Use of collections
• Collections review
• Audit

Sample wording for Spectrum compliancy for an RFP could be:

The Bidder must ensure that the proposed system is compliant with the following Spectrum 5.0 procedures: (list required procedures).

CHIN Collections Management Software Criteria Checklist

Consulting the Collections Management Software Criteria Checklist will help determine other requirements, which you should prioritize based on whether they are mandatory or nice to have. Construct specific requirements based on the organizational responses to the checklist items. For functions that are indicated as mandatory, the following sample wording could be used:

The system must be able to...

For functions that are designated as nice to have, you could use the following wording:

The system should…

In cases where the process may require description, the requirement can be phrased as a question asking the bidder to describe how the system does something.

Areas for which you may need to specify detailed requirements are:

• User interface
• Queries
• Reports
• Enhanced collections management
• Technical requirements
• System administration
• Installation
• Migration
• Testing
• Training
• Documentation
• Phased deliverables (for a large-scale project)
• Frequency and type of backups required
• Accessibility
• Language (bilingual or multilingual capability) interface
• Language (bilingual or multilingual capacity for data entry and handling Web interface development and customization)

Submission requirements

In this section, provide information for bidders on what they should include in their submission, such as:

• Where to submit and when
• How many copies
• In what format (print copy with an electronic file to be sent to a specific email address, for example)

The following supporting information may be requested in an RFP.

1. Bidder’s corporate profile:
   • Company’s legal name
   • Biographies of staff who would be working on the project with a description of their role and level of involvement
   • Business address, phone and fax numbers and website address
   • Contact information for their representative for this submission
   • An overview and history of the company’s business
   • Product information
   • Official languages supported
   • Availability of a Canadian or North American office for support, including business hours
2. Statement regarding how bidders will meet the specified requirements.
3. Experience on related projects:
   • Request a list of clients with systems of similar size and scope, including three references with contact information
   • Ask if there are other clients in the area using the system
4. Approach and methodology that will be used (use as many of these points as may apply to the project and any others specific to your needs):
   • Description of the CMS, including hosting and deployment options
   • Description of the exact basis on which licensing agreements are priced (number of users, number of records, etc.)
   • Software costs and fee schedule
   • Cost breakdown of all software and installation
     • Is there a one-time application fee, or are payments made by module?
     • Are there annual licensing fees?
     • Is there a cost for upgrading?
     • Is there a cost for documentation?
     • What are the support and maintenance costs?
     • Are there training costs?
     • What does it cost if the system changes in size or usage?
     • Is there a data conversion plan and loading costs?
   • Options for purchasing extra modules after the system has been implemented
   • Any other fees and how they are determined
   • Frequency of software updates (When was the date of the last major upgrade?)
   • How major and minor upgrades, patches and bug fixes are handled and whether they are covered by a service agreement
   • Maintenance and support plan after project completion
   • Hosting and deployment options
   • Process for data migration
   • Detailed project plan including a project timeline with milestones
   • Sample contract with standard clauses, rights and period of contract
   • Test plan
   • User acceptance testing
   • Security (e.g. where will data be stored, if a cloud-based solution?)

Contractual details

List general legal information, including such details as:

• Issuing agent does not pay the costs for proposal development
• Specific issues related to subcontracting
• Specific lines of communication
• State the right to cancel the RFP
• If there is a holdback in payment until system acceptance, state it clearly

If desired, state the right to cancel the RFP process and recommence with the same or an amended set of requirements. Some RFPs may state upfront the right to negotiate a change of scope to the work during the evaluation process. The RFP may also state that proposals without satisfactory reference ratings will be rejected.

These contractual details should be developed with assistance from a legal department or contracting advisor.

Evaluation criteria

Describe for the vendor on what basis the proposals will be evaluated and who will be doing the evaluating (roles rather than individual names). Be sure to require a system demonstration for all bidders who pass the initial review. Proposals may be evaluated based on the following examples:

• An understanding of the organization’s needs as reflected by vendor recommendations
• Clarity of the proposal
• Appropriate solution to the RFP requirements
• Total cost of the project
• Schedule and strategy within timeline
• Vendor’s track record for this type of project (based on references)
• Availability and quality of personnel for installation and post-installation support
• Ability to customize software to suit the organization

One way to evaluate is to assign points based on priorities devised from ranking your requirements. An example might be:

• Extensive experience with collections management solutions (25 points)
• Technical proposal completeness—corporate profile, approach, schedule, project team, ongoing support (25 points)
• Price proposal (20 points)
• Interview including demonstration (15 points)
• References (15 points)

Note: This is an example only. The organization must decide which priorities it will use to rate the proposals.

The RFP may state that only vendors who meet mandatory requirements may pass to non-mandatory requirement evaluation. Another option is simply to evaluate any proposals that meet all the requirements and select a single criterion (value for money, for example) as the deciding factor, as long as it is stated upfront.

System demonstration

Describe the desired type of demonstration: for a downloadable version, how long can the organization have access to it in order to test the system? In the case of a live demonstration, what features will be demonstrated? How will this be done? Is it only for bidders with a certain cumulative score?

In closing

A successful RFP depends on the initial efforts by an organization to understand and clearly define its collections management and technical needs and capabilities. Making this effort at the start of your project will ensure you are best placed to produce a clear RFP and to discover the CMS solution that is right for you. You can use these guidelines to guide your approach to the research and development of your RFP, using the table of contents to help shape your document.

These guidelines have been developed based on introductory text from past CHIN CMS reviews and a number of sample RFPs as well as input from the museum community. They provide guidance on developing an RFP, but each organization will need to determine their needs based on stakeholder input.