An effective RFP for a web project

Please note that this article is over 12 years old, so the content and links may not necessarily be up to date. For more recent reading, you might be interested in one of these articles:

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

Sami Kalanen

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.

Sami Kalanen

Sami Kalanen, M.Sc. (Eng), is an expert in project planning, requirement specification, and tendering.

Sami consults with customers on project preparation and definition of requirements, and supports customers in competitive bidding and oversight of vendors’ implementation work. His areas of specialisation include broad, technically challenging web projects and competitive bidding in the public sector.

Sami has been working with web projects since the mid-1990s. Earlier in his career Sami worked in IT procurement at a large industrial company, in management roles at software vendor companies, as Managing Director and a partner at an independent consulting firm and as product manager for a telecommunications operator.

Websites

Building a complex and content-heavy website? North Patrol's team helps you design data structures, user interfaces and key functionalities.

Read about our services

Request a quote

About North Patrol

We are a team of ten consultants, all of whom are experienced designers and technology experts. Every year we design and prepare over 50 different online services and information systems. Our customer satisfaction is very high (9.5 out of 10), and we have helped many customers transform their digital services.

Read more about us

How we differ from our competitors?

  • We specialize in digital service design

    We specialize in high-quality design and requirements specification of digital services. Our mission is to help customers succeed in their software project by creating the best possible foundation for implementation – whether it is an agile implementation done inhouse, a project done with a partner, or a publicly tendered project.

  • We don't sell coding or licenses

    Many software companies recommend software solutions that they also implement themselves. We don’t do that. We don’t do software implementation projects or have partnerships with technology providers. Our perspective on the software market is broad, as it should be for our customers. Our goal is always to find the best possible software solution for our customer, whether it’s a custom-built solution, a SaaS service, an open-source platform, or a combination of these.

  • We are realistic and forward-thinking

    We design digital service concepts, implementation methods and architectures that are sustainable and can be further developed. We place great importance on the feasibility of software solutions, the availability of good partners and the predictability of costs.

Back to top