About us RCL 20 Projects Colour Selector Library
Library
Guides
Written requirements
Windsor Half Marathon
CRASH
Design guidelines
Briefs & proposals
Articles
Don't believe your web stats
The perils of mailing lists
Wasting money on web sites
dot slash ~ keep your URLs trim
Best-before dates
ISP surveys
1998 Central European ISP Survey
1996 UK ISP Survey

How to write briefs & proposals

Paola Kathuria & Frank Wales

September 1998

Contents

Introduction

The ideal process

What actually happens

The ideal brief

The proposal

Judge a proposal by its cover

Summary

If your company wants a new web site or if you want to redevelop your existing site, how do you go about selecting the best company to design and develop your web site? How can you tell which company has the right skill and judgement that you need?

Or, if you're a web company, how can you present your skill and experience to your best advantage?

This article will be relevant to companies and organisations preparing web site briefs and for web development companies who write proposals; it discusses issues from both perspectives. It was written for an invited talk at the 1998 [off-site] Institutional Web Management Workshop, when the authors were directors of Limitless.

Introduction

There are over 1000 companies in the UK offering web design services. Some will offer to do your interactive 50-page site for a few hundred pounds and some will charge tens or hundreds of thousands. Some will take the printed material you send and put it on a web site exactly (leaving in references to other pages by number, for example) with no questions asked. Others will work with you to specify the site and will not start development until the specification is approved.

In responding to a proposal, a company has to reassure the reader that they have understood the requirements and are able to fulfil them. They then have to persuade the reader that they're the best company for the job.

The ideal process

  1. You send a web company a set of your printed brochures and ask for a quote for putting them on the web
  2. You get proposals and quotes back within a week and find some within your budget
  3. You select a web company and work proceeds
  4. The work is delivered on time and within budget
  5. You're happy with the result and you pay the web company on time

Unfortunately, this process is unlikely to result in a site that meets your needs and those of potential visitors, because an organisation's web site will usually be quite different to what can be gleaned from a printed brochure.

What actually happens

While working in our Internet companies, We developed a process from handling initial enquiries to delivering a proposal. It is based on our experience of people's expectations when they make first contact; the level of information they have; the likelihood that they're probably calling around a few companies; and that they have probably underestimated the work involved in what they have asked for, and the potential of what they could be doing online.

1. First contact

Get an overview of the requirements and the intended scope of work during a telephone call. If additional ideas come to mind, mention one or two. Find out if anyone is doing anything similar and what is thought of them. Before the end of the call a) determine their budget and timings, b) set up a meeting, c) ask for their promotional materials to be sent that day.

2. Confirm meeting

Confirm the time, date and venue of meeting. Send map and directions to our office if required. Say who will be coming to the meeting and why.

3. Pre-meeting preparation

Get a feel for the market and the required site by looking for similar sites and competitors. Make colour printouts (5-10) of screen-shots to discuss at the meeting. Brainstorm further ideas for the site. Pick 2-3 for discussing at the presentation; more will be included in the proposal.

When the brochure arrives, discuss with the graphic designer. Discuss possible main site sections and navigation. The designer may do some sketches of initial ideas of the home page and 1-2 key pages or types.

4. Meeting

Invite the prospect to introduce themselves and give an overview of their requirement. Flesh this out through questioning. Add our 1-2 suggestions. Give a summary of our experience, client work and strengths.

The graphic designer presents their work - this includes a description of the design process in the context of the other stages of site development. Examples of Internet work and other design work are presented. End with sketches for the proposed site, with commentary. At the end of meeting, agree what features will be included in the proposal as the core system and what should be quoted for separately.

5. Prepare and send the proposal

Write, bind and post 1-2 copies of the proposal within a week.

6. Follow-up

Within a further week, make a follow-up call to the prospect and answer any questions.

The ideal brief

If you don't want to talk or meet companies before you see their proposals, the list below covers the kind of things you could include in your brief so that the web company has enough information to give a reasonable cost estimate (since the vaguer the requirement the higher the estimate will be).

1. Background

Brief history, size, strengths, successes.

2. Aims & audience

What is the purpose of the site? What is to be achieved? Who is the audience? Is it to replace or supplement an existing system (e.g., staff directory) or to be something new (staff-moderated discussion areas to support tutorials). Should the site make money? Should it save money? Should it match or beat the features of a competitor's site?

3. Corporate identity

Include brochure, promotional material and state if a corporate identity, or brand manual exists and whether web site guidelines exist.

4. Scope & phases

If planning in phases, what is planned for when? What will be included in the core site - that is, what has to be done at the outset? Is the site public-facing only or will it have an intranet or extranet component?

5. Content sources

What content is already available? How much and in what format? What and how much needs to be created? What content is to be created by the web company? How much imagery is available to use, e.g., photos and logos? Is it legally and contractually available for use on the web?

6. Integration with existing systems

Is the site a stand-alone system or will it be integrated with existing databases or systems? If so, what and how? Is the site transactional (online quotes, online ordering, querying live data)?

7. Hosting

Do you want the company to host the site? If yes, ask for the company's service level agreements with regard to availability and support. What site statistics do you want available and how often?

If not, give platform of the intended server and an indication of the level of access allowed, as this will probably affect the development cost.

8. Maintenance

If the content is based on high volumes of information, is it a one-off or on-going update (e.g., prospectus). If on-going, what format is it in? How is it currently updated (e.g., in Word, on a PC database, from a database on a larger server)? Is the web site data to be read-only (extracted from existing sources) or will you require a web-based update facility?

Who will maintain the site? Is a restricted development or preview site needed to check changes before making them live? Will the person at the organisation maintaining site know HTML or be using a web-editing tool?

9. Design requirements

List related sites liked and not liked, giving URLs and reasons. List particular features liked or disliked (e.g., animation, chat area, search facility). Give 10 descriptors for the site in terms of what should be conveyed (e.g., "professional", "traditional", "forward-thinking", "accurate", "reliable").

10. Targets

How will you know if your site is a success? Are you measuring by number of page accesses, number of pages viewed per visit, visits, number of enquiries, survey responses, increased sales, reduced costs? What time-scale applies to these targets?

11. Future Work

Do you expect this work to lead to other projects, if it is a success?

12. Deadlines

By what dates do you want a proposal? What should be included. When is the site to be delivered for testing? When is the proposed launch or re-launch? If copy needs to approved by someone (e.g., your legal department), state the turnaround time.

13. Quoting

List features or areas which should be quoted separately. Invite the company to submit further ideas which should be quoted for separately.

14. Suitability

Ask the web company for:

  • number of years doing web sites
  • experience of main developers
  • particular strengths
  • 5 client web sites - client, URL, year of launch, work done (since some sites are credited to 2 or more web companies and so find out what their actual involvement was), and client references if possible
  • a copy of their brochure

What are you looking for in the respondents? Price, experience, ideas?

The proposal

Below we describe a proposal when the requirements have come out of initial discussions. Proposal-writing is a process we continually improve upon.

1. The requirement

One or two pages - Restate the requirement as you understand it. Include the stated goals, specific features and key information (e.g., whether this is an on-line version of a printed document or a new service).

2. The existing site

One to three pages - If the work is for an existing site, analyse the site statistics (for which a copy has already been asked). Describe successes and problems with the existing site and compare it to competing sites.

3. The solution

One to three pages - Describe your understanding of the proposed web site, including a draft graphical representation of the site structure if enough known to do this. Give an overview of the main sections of the site.

4. Our approach

Two pages - working methods, technical environment and design principles.

5. Who we are

One page - overview of our company, our work, clients and working partners.

6. Estimate

For each deliverable and optional extra, use the following format:

  • sub-heading followed by a brief description of the item
  • item name and cost, in bold - include the word EXTRA for optional extra
  • description of what is included, any assumptions made and elapsed time

Only include those items that have been asked for.

  • domain name registration - set-up and on-going costs
  • specification consultancy - if requirements are still vague, this item covers a few days time to work closely with the prospect to develop an on-line strategy and produce a specification for the first-phase web site
  • graphic design - in stages
  • web page implementation (state the expected number of pages and sections, includes preview and test on development site, addition of meta information to maximise site visibility, site registration)
  • Optional extras - as separate tables
  • Hosting - options:
    • live only
    • live and development
    • hosting features
  • On-going maintenance - fixed or pro rata
  • Extra online and offline promotion

7. Notes

For example, assumptions, invoicing, payment of third-party royalties for images.

Judge a proposal by its cover

A proposal should be as well-presented and as professional as you would intend the site described within it to be.

Our proposals are bound in coloured card (matching the corporate colour of the prospect, when possible), with an acetate sheet protecting the first cover. The project and client name appear on the cover. Our proposals are set in our company's chosen typefaces.

The cover includes the client name, project name, main contents, contact names, addresses and the date of proposal. The header of each page includes the project name and page number; the footer includes a copyright notice.

The proposal should be spell-checked before sending.

Don't bind it in such a way to make it difficult to photo-copy and ensure that it is all legible if photocopied - that is, don't rely on colour alone to convey essential information. Send two or three copies if you know it will be reviewed by different departments.

Summary

If a brief is the statement of a problem, a proposal is the statement of a solution. A brief should only describe functional requirements and should not attempt to specify solutions in terms of implementation; you may compromise the outcome otherwise. If you're paying a company because you think they're experts, don't tell them how to do their jobs - let them show you what they can do.

If, however, you do want to specify everything and are not interested in the value that can be added by a company, remember that you will probably get what you pay for.

Don't allow companies to take advantage of vague requirements if you lack expertise. Hire an independent consultancy to help you prepare the brief and to review the proposals.

Finally, if you're satisfied with the work a web company does for you, let them know and recommend them to others. If they do a bad job, let them know what the problems were. Allowing companies to learn from their successes and mistakes helps to improve the marketplace, and the quality of service you can expect in the future.