An effective RFP for a web project


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.

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.

Components of RFP

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.

This entry was posted in Effective RFP, Partner selection, Procurement and tagged , , , by Sami Kalanen. Bookmark the permalink.

About Sami Kalanen

Sami Kalanen works as Managing Partner at North Patrol Oy. 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.

3 thoughts on “An effective RFP for a web project

  1. In my opinion, requests for proposals are not extremely helpful for finding, evaluating and comparing companies that will provide a dedicated team of programmers. As you describe, developing a software web application in a fixed amount of time is a complex process, and you will have a specific set of requirements and specifications.

    For most software, it’s impossible to determine all of the features, functions and requirements up front. What is really sought after is a request for information about how the provider will fulfill a request or provide a dedicated team. To develop the kind of software in which there’s a lot of collaboration to discover and implement features and functions as the software development process proceeds, you really need a dedicated team of programmers who are paid on a month-by-month basis.

    Therefore, your RFP – your RFI – is really intending to find and evaluate the best company that can provide that team, not specifics regarding the software development itself. RFPs like this are great for small projects that use just a handful of programmers or take a small amount of time to complete. If you need a dedicated team of programmers for an extended period of time, this kind of RFP process is not very helpful.

    • Steve, you are right that the RFP described in my article is not well suited for cases where you are not buying a pre-defined project but looking for a team of developers for long-term cooperation.

      I think that in Finland we tend use project based procurement (instead of team based procurement) more than in other markets. Here, the most of the web projects are really bought as complete projects, not as a team of professional resources. In Finland, the client organisations typically expect the vendors to take responsibility over project management and budget control.

      Naturally, this approach requires more planning and specification work before the RFP to get this kind of commitment from the bidding vendors. But, as mentioned in the article, the requirements can be specified in a separate project before the RFP for implementation.

      I totally agree that there are some cases (the most complex ones) in which it is impossible to make detailed enough specifications in advance. In the biggest cases, the client organisation also has its own resources to work with the outsourced team and can take more control over project management and team supervision. In these cases a different procurement model is needed as you are not really buying a (complete) project but hiring professionals for a project.

      But still, most web projects are actually quite simple (at least in Finland). And as many client organisations lack the capability to manage the development work by themselves, the project purchase model I described suits them very well.

  2. I think most web projects take less than a year from requirement analysis to going live. And rarely you have more than 3-4 months of technical development during that time period. For those projects you can usually use this model with very good results (budget and quality).

    If the estimated “coding period” is going to be more than 6 months I would definitely recommend approaching the project more from resourcing perspective than fixed project perspective.

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s