Request For Proposal Template

How to use this template

Just reading this document will give ideas of the areas that need to be covered when a small organisation plans its new web site, but the structure is also designed to be used as the basis for a more formal document to engage developers in a tender process. Some sections of this document are more important than others, and in some you will have nothing to say. Feel free to add and omit sections, and to communicate what you think needs communicating.

A good Request For Proposal will also go down well with large donors.

Final format for this document

Most documents of this type are usually created in Microsoft Word and distributed as PDF. It is the opinion of the present author that such a document, about your web site, should contain links, and be published as a web page, in your house style. This will show that you have moved beyond the belief that printed paper is the only true medium, that you can write for the internet, with links and styles, and that you are ready to use the internet as a tool, not just a brochure.

Cover page and meta data

This shows you are serious about communicating formally and clearly, that the document which follows is more than just a sketch. The metadata will include information like the title, information about who wrote the document, the date it was finished, the release date, the version number, the URL where it can be found, the number of pages, the response date, email, the award date, a contact for questions, your logo. These bits of information might be on the header, footer, or cover page.

Preliminaries

Executive summary

Indicate the nature of the business, the budget if you can, timeframe, the aim of the web site and its expected impact. It should contain buzz words and name dropping, and be comprised of sentences plucked from the first two sections.

Definition of terms

This is a space for you to explain all the terminology from your sector of which developers may not know your meaning. It shows you don't think in a bubble. Aim for about 5-15 terms. Include only terms used in this document.

Table of Contents

This should be hotlinked, if the file format allows. The Organisation

Mission Statement Strategy Stakeholders
The Project
Currently Goals of Project Main Features Users
Other Issues
Political or Business Requirements Ideas for solutions Migration Project management Future Work
Response Template

About the organisation

This is a standard introductory passage which you can probably copy and paste from another document. For a designer of graphics, information architecture, and usability, it is very important to have a broad view of the organisation and its purpose, partners and ways of working. This is your opportunity to excite the developers about the project. It is your chance to mention your impact and you want them to be falling over each other to work with you and put you on their resumes!

Mission Statement

This is a short statement which encapsulates the values and specific purpose of the organisation. Again, most organisations have one prepared.

Strategy

How does your organisation specifically meet the values stated above? What are the key levers it has identified, how does it use resources? Remember that you will be talking later about how this web site fits in to the strategy. Feel free to insert diagrams to break up the text.

Stakeholders

Talk about the relationships your NGO has with other organisations. All of your NGO's activities and goals should connect with at least one stakeholder. You can mention them by name or talk about stakeholder groups; such groups might include:

  • Donors
  • Hosting organisations
  • Employees
  • Partners
  • Suppliers
  • Ultimate Beneficiaries
  • Influenced parties
There may be some value in tabulating or weighting stakeholder interests, as this shows where the organisation's priorities are.

Processes

The new web site will be designed to support the organisation's structures and ways of working. Talk about how the organisation works now, indicating perhaps its limitations. Types of information and ways of information sharing, the publishing / approval process, bottlenecks in the organisation, how the organisation is accountable; how it interacts with stakeholders. You might include an organigram.

About the project

Goals of Project

It is time to talk about this web project, and what results are expected. What are the high level goals of this project and how do they conect to the organisation goals and stakeholder interests? When does it need to be finished? (Try not to appear rushed, these things take months to tender, prepare, build, populate, test and deploy.) How will this project make a difference? What is the lifetime of the project? What is the budget over that lifetime? What are the most important results, and which could be delayed if it turned out too expensive? Are there any deadlines which must be met?

Currently

If this is a new project then this section may not be necessary. How is the current web site adressing the new needs? This could have implications for continuity and architecture. Are you using a CMS already? How many content items are in it? In many cases the new website will have to do all the old web site did, and more. You will soon outline the exciting new functionality, but here you need to describe about the existing functionality. If you have a specification document for your current web site it would make a good Appendix item. Remember that the reader will have your web site in front of them if you provide a link, so you don't need to describe the web site, but talk about it on a high level.

Main Features

These are the headline items, the tools that will answer the original need. Try not to be specific about the technology, the developers want you to give them that freedom. Write a paragraph or two on each, and explain how they will link together, and how they support your organisation's objectives. It is this section which will explain what you need most succinctly. Examples of main features include:

  • A library of project reports
  • a rosta of available experts
  • a collaborative document editing space
  • constituent management tools
  • a space to discuss specialist issues
Note that many of the other things you will want, such as an editing hierarchy are not special features and are included later in this requirements section.

Users

Graphic designers and information architects often like to start the process by understanding who the users are, so you should show in the RFP that you are ready for this. Here are two ways to communicate with developers about who your users are and what they want. Click for more on usability.

User Profiles
List as many different kinds of potential user as you can. They could be real users. Talk about who they are, how they use the web site, how often they visit, what they need from it, how they find it, what language they speak, what business they're in, how much internet experience they have.
Use Cases
A Use case is an account of a user coming to your web site with some needs, and how those needs are met. It is the story of a visit. You should have several use cases, showing different motivations or results. Don't attempt all possible use cases though.

Other Issues

This is the most flexible section in this template. It can include anything else you think might need expressing. Feel free to create new sections here.

Political or Business Requirements

There are a range of non-technical requirements which could affect your choice of CMS and contractor. For example, a young CMS will have more longevity than a fading one, though upgrades will be more disruptive. In five years, the market will look very different. If the organisation is locked into Microsoft, Sharepoint it's first decision is whether to use sharepoint. Software licensing models play a large role in determining CMSs for larger organisations. They may be priced by the number of processors, or by the number of users or add-ons, or by some combination combination; other CMSs are of course free.

  • The system should use open source software so that our stakeholders in the south can re-use it without paying licence fees
  • The system should have a large community of developers
  • The system should run on Linux, as it will be hosted in-house
  • The vendor should have a track record with non-profits
  • The liason person should be fluent in Turkish in order to be able to communicate directly with our director
  • Though vendors from abroad will be considered, use of aeroplanes is counter to the aims of this project.

    • Ideas for solutions

    Talk about any prototyping done, and what was learned. Mock-ups can be included in an appendix. This is the moment to get technical. Don't mention anything which might prejudice the developers e.g. Such-and-such CMS seems good.

  • Some way of importing RSS items into the library would make them permanently available to search.
  • Autodetection of keywords would make it easier to create content
  • The contacts, the members and the rosta, could all be one kind of object - people. This would save duplication.

    Migration

    If you want to bring large numbers of pages or other content from your current system to your new system, you should explain here who should be responsible for that. Migration can be a large operation, drawing on an intimate knowledge of the content which can only come from within the organisation. It may also involve adding metadata to the content, a process which involves processing every content item individually. On the other hand, it can be just another requirement. So in this section you should mention how much content there is for each content type, who will take it out of the old system and re-shape it for the new.

    Example: The developer should import the content which will be prepared by the NGO: The current site has around 80 pages in html which will require a straight migration. The contacts database will be presented as an Outlook export file. We shall agree a format and prepare all the metadata for the 300 items in the new library. The developer should be responsible for migrating the 16 project sheets from PDF.

    Project management

    It is unrealistic to expect to just hand over the job and let the developer get on with it. Developers may want ready access to a decision maker for quick, frequent decisions. Usually, the content is prepared by the NGO at the same time as the site is built, and the two teams need to communicate. This is why you need project management. Who will your point of contact be? What decisions will they be allowed to make? Will it be possible to make rapid decisions? How much time and resources will the point of contact have? What will be the sign off process? Do you anticipate doing the project in stages? Over how long? What guarantees can you offer that the content will be ready to import by the time the web site framework is ready?

    Future Work

    NGOs, almost by nature, are full of ideas and wants, and many will have been cut out of this document. Here you can talk speculatively about your hopes for the future of the web site. It could be that solutions already exist and they are easier than you thought. This section is also important to allow the builders to leave certain doors open in the design of the site, and to tempt the developer that there might be another, (even more interesting!) project leading on from this one.

    Response Template

    At the end of your Request for proposal, you could put a response template. This helps you to collate and compare the responses, and gives you an opportunity to see how willing the respondents are to frame things in your terms. Here are some elements you might include in a response template. Be careful not to make the template more binding than necessary. Many responses will have a pro forma element, which is fine.

    Headline figure
    This is the quote to implement all the requirements in this document. You should be absolutely clear if some requirements are optional, or low priority, which ones are to be included in this figure.
    Optional requirements
    The optional or low priority requirements should be listed here, one by one, for separate quotes. Perhaps draw a table allowing room for comments
    Questions
    You may ask questions of the developer to test their knowledge or clarify your understanding. You should make these open questions and expect a variety of answers. E.g. What is your experience experience of NGOs? What's the best way to... Which requirements are the most problematic?
    Start date
    You need to establish how busy the company is, and when they will be able to do the job. Don't ask for a start date, because this is likely to change. Ask how many months ahead they are booked up at the moment. It will be in the company's best interests to be truthful!
    Suggestions
    Ask for suggestions about how things could be done, or done better than proposed already. You probably want creative input from all the recipients, and throughout the build.
    Project Management
    They should be able to give an enlightening account of their internal communication channels and project management practices. Many companies include this in their pro forma section.
    References
    Just as with a job application, you can ask for references, especially if they have worked with non-profits before.

    In return for their conformity, you should be clear to them what your budget is, when you would need the web site by, whether you intend to respond to all bids, and when you will announce the winning bid.

    This document owes something to the logical framework analysis. It was created on the basis of consulting with NGOs and web site developers, with ideas from the Appropriate Software Foundation.

    		•