The quality of proposals from vendors varies significantly depending on the quality of the request for proposal they were sent. Preparing a request for proposal with care increases the likelihood of receiving suitable proposals on which to base a dependable project agreement and achieve a successful end result.
North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.
16 October 2012
Preparation of a good call for tenders is particularly important in the public sector in Finland, where the ability of procurement units to negotiate with vendors is restricted by Public Procurement Act. But the following best practices are useful in the private sector, as well.
Subject of the procurement
The most important thing in a request for proposal is to describe the subject of the procurement. The request should provide the customer and the vendor with a mutual understanding of what is being purchased and sold. Requests for proposals should clearly define the expected final result and what tasks are expected of the vendor.
A good request for bids for a web project includes at least a preliminary requirements specification or concept design. The goal of including a requirements specification is to unequivocally describe the boundaries for the content, functionality and technical implementation of the project.
If a definition has not yet been drawn up, a practical approach is often to prepare it as a separate, initial phase of the project. The project can be divided into two parts, first the preparation of a requirements specification and then a request for bids for the actual implementation based on those requirements.
The larger the project in question, the more important is it to clearly describe the expected results. More general definitions may suffice for simple projects, but basic expectations should always be documented before embarking on a project of any size.
If the request for proposal is for a long-term development project for which all details are not yet known, the competitive bidding process can be started with a detailed description of the first phase and a more general description of open project goals as options.
Requirements for vendors and proposed solutions
The request for proposal can include unconditional requirements for vendors and proposed solutions. These requirements guide vendors in offering the type of solution desired, and eliminate vendors and solutions which do not meet the customer's minimum criteria.
Criteria for vendors can relate to their business information (e.g. number of personnel and profitability) or for example to references from previous comparable projects. Since the determining factor in the success of web projects is often the implementation team rather than the company per se, requirements for the project team (people and their roles) as well as their experience and individual references should also be included in the request for proposal.
Requirements for proposed solutions are often related to the organisation's IT guidelines and existing systems. For example, IT management might require that systems be implemented using specific technologies, eliminating solutions not suited for the environment. It is also often prudent to require that the proposed technical solution is supported by several vendors, which limits future dependence on the selected vendor.
Comparison criteria
A request for proposal also describes the criteria to be used to compare proposals and the factors which will affect selection of a vendor. Typical criteria for comparison are how closely the proposal corresponds to expected results (e.g. the requirements specification), the project plan and quality of support and the total cost of the purchase. Cost alone is rarely a good criterion for selection in web projects, since different vendors' solutions differ significantly.
A detailed description of comparison criteria is particularly important in public sector procurements, since they are binding on the procurement unit in accordance with the Public Procurement Act. The private sector is more flexible, but well-defined selection and comparison criteria help vendors understand what issues are central for the customer in selecting a vendor.
Contents of a request for proposal
A request for proposals should sufficiently describe the content of the bid and provide sufficient instructions for vendors to enable them to make the type of bid desired. A good request for proposals also takes into account the vendors' needs, and does not make preparing the proposal unnecessarily difficult.
A request for proposal should include at least:
- basic information about the organisation making the purchase
- a description of the subject of procurement
- a description of the expected end results (requirements specification attached)
- tasks and services required of the vendor
- implementation schedule / duration of the agreement
- suitability requirements related to the vendor and the system being purchased
- agreement and payment terms for the contract
- required content of the proposal
- description of comparison and selection criteria
- instructions for submission of bids
- deadline for submission of bids
- duration for which bids will be in effect
- address for submissions of bids
- who to contact for further information
Many organisations use existing templates when preparing requests for proposals, which can be adapted for each specific request. Particularly in the public sector, use of an exemplar can help to ensure that the format of the request meets the requirements of the Public Procurement Act. However, general models for requests for bids are not well-suited for web project purchases, so the detailed content of a request should always be tailored for each specific project.
