print this article

Writing an RFP or Specification

Whether or not you plan to hire outside professionals to design or develop your site, one way to organize your thoughts and define your project is to write a Request for Proposals (RFP) outlining the specific capabilities (specifications) you want your site to have. This can serve as the set of blueprints for your site’s development. And if you do outsource the work, the key to being happy with your contractors is to have a clear set of specifications and expectations.

But be warned: it takes a lot of work and may be overkill if you're just hiring a freelancer to design a logo and choose a color scheme.

A good RFP should cover the following elements:

• Intended audience. Who do you want to reach? Where do they live? What’s their demographic profile? How tech-savvy are they? For example: “This site is designed for senior citizens in Maryland who are looking for important medical information but are unfamiliar with the web.” Or, “Our target users are college students with mobile phones who are interested in extreme sports.”
• Features list. It should detail specific functions you want the site to have, such as the ability to search the site with key words, a gallery of photos or an automated RSS feed. Take care to be specific. For instance, listing "site search" may not be enough. You may need to specify: "Search capability that is updated as each new file is added and finds any file placed on the web server and any data added to the database, including PDF brochures. The search doesn't need to allow complex searches but does need to agree with the site's look and feel. It should also point out possible misspellings, like Google does."
• A site map. It should outline the various kinds of content you plan to have, such as stories, registration forms, grant guidelines or discussion forums. To see an example, visit Google.com’s online site map.
• Content samples. These should give the designer an idea of the kinds of documents or information you expect to offer on the site.
• Any existing technology to be integrated. For instance, you may need to integrate your existing contact information into another database system, such as Access.
• Scope of work statement. You should be clear about the work you expect to be completed by your developer and what tasks fall outside that scope.
• Behavioral profiles. These are basic "stories" about what you expect a person to do upon visiting your site. For instance, will your visitors be tracking resources, looking at grant guidelines or signing up to participate in something? This helps the designer determine placement of the design elements and suggest features that you may have overlooked.
• Future development plans. This helps your developer build a site that will accommodate your future vision. Some current development experts recommend not overbuilding for possible future plans. That is a fine strategy, especially if you have limited resources. Still, that’s no reason to build a site that can’t expand, especially in a direction you were anticipating. For example, a developer might choose to store byline information differently, if it knows that a site will allow multiple contributors on articles in the future. Or, if a site is specific to a small geographic area, but has plans to grow to a number of areas, location information might be handled in a different manner.
• Clear and explicit deadline requirements. A reputable designer will agree to a set schedule and be able to meet deadlines. You should allow some flexibility, building in a few days before you actually need the material. Building in this extra time will help prevent missed deadlines. The designer should deliver the product on or before the due date. Written in your RFP should also be agreed-upon consequences if the designer does not deliver on time, including warnings, deduction of payment and/or termination.
• Your budget. It will save time and help you develop a more suitable RFP if you say upfront what you are willing to spend. A company that would pad its estimate will do so regardless of what you tell them upfront, and a decent company will use that information to make appropriate software, hardware and design choices.
• Ongoing support and maintenance. It can be to your advantage to bundle that request into your RFP. It also gives the company an incentive to finish the work on time and budget, because they know you intend to continue to use them for ongoing work.
• Examples of what you like. Collect some favorites and share them with your developer. For example, it's one thing to say you want "spell check" as an administrative requirement. It's another to say you’d like spell check like Microsoft Word’s or search features like Google’s.

Assembling an RFP is hard work. However, a well-crafted, detailed document will become an indispensable part of the project. You will refer back to it frequently. And it’s common, at the end of your project, to end up wishing you had been even more detailed in preparing it.

If you have an RFP you'd be willing to share, please e-mail it to news@j-lab.org and we will post it here or link to it from the comments.

> READ NEXT ARTICLE: Finding Contractors

Be the first to comment on this page. You must register before you can leave a comment.

You must be registered (free) in order to post a comment.