1. Overview of Project
2. Project Objectives
3. Tone and message of site
4. Description of the intended audience (also referred to as the target market).
5. List of goals for judging the success of the project

This is a long and daunting list. The Project Manager is responsible for assembling and turning in the final product, however they are not expected to create everything, all these documents. By assigning various pieces to other members of the team the entire team can feel involved in the process, the group can learn to work together, and the PM can get some sleep.

Overview of the Project
Briefly describe the client's organization. Define the scope of the project. Is this the remodel of a large existing site, or a a brand new site?
 
The Goals and Objectives
List 3-5 goals for the Web site. Find out what the client wants to accomplish with this site so you can give it to them. If they define success as a site where they can list contributors and showcase past projects, then make sure those 2 elements are included in the goals for the site. If they want to cut down on the # of phone calls, faxes, and mail requests for their schedule, then make sure their online schedule is easy to use and maintain.

Sometimes clients express unrealistic goals - such as doubling their membership, or having the most extensive Web site in Sonoma County. If this is the case try and gently educate them about the limitations of the Web and this class. If they don't seem to be getting it - drop me a note.

Another problem that sometimes arises is when a team designs a site that meets the teams goals but not the client's. If you have been dying to create a flash animation, but the client wants a clean simple site - don't try and sell them on Flash. Put a Flash animation in your electronic portfolio

Tone and  Message
What is the tone and message for the site - sophisticated, relaxed, inviting, high energy? What message is the client trying to convey with the content and the look and feel.

The Target Audience
Who are you designing the site for? Certainly it will be designed for the client - but even more importantly is designing for the typical visitor. The client should be able to accurately describe who their typical visitor will be. Once again listen to the client - if they explain that they want this Web site to be used by their volunteers and contributors, not the general public, then give them what they want.
 
Benchmarks for success
What are the ways the client will determine if the site is a success? Will it be positive feedback from the community, an increase in attendance at the groups activities, a more efficient way to process forms, or increased donations.
 

DOCUMENTING THE DELIVERABLES
The Web is a new commodity for most consumers. We all understand what a business card, letterhead, and brochure will look and feel like. Most clients do not know what a Web site or Web page is. Some "web pages" can be 10 printed pages while others are only one paragraph. Some Web sites consist of 8-10 pages while others run into the thousands. The list of deliverables needs to be extremely specific and detailed so the client is not disappointed and the development team is not exhausted. Include the number of pages, the design elements, programming, training, and marketing (if applicable)

DEVELOPING A STORYBOARD
Because Web sites are such a "new media" the client can often be confused about how the pieces of a Web site fit together. The storyboard for the site can provide a picture which allows the web development team and the client to see what the site will contain and how it will be organized.

The Storyboard can be compared to a floor plan of a new home your architect has just designed. A well done plan enables the building of your Web site to run smoothly. It is much easier to "move the walls of your Web site" on paper than it is in week 12 after you have spent countless hours creating files.

An effective storyboard is not necessarily complicated, time consuming, and difficult. A neatly drawn sketch can easily be erased if the client does not like it. However if you spend 6 hours in PageMaker struggling to make a beautiful flow chart - you will be more resentful when a suggestion for change is made. Once the design is agreed upon you can convert it to a sophisticated computer file.

Regardless of how you choose to create your storyboard must include a flowchart depicting all pages included in the Web site Traditionally a rectangular box represents each web page, lines are drawn between the boxes to indicate how the pages link together.

After you complete your storyboard, you will have a very clear conceptual framework from which to begin executing the actual production.

DETERMINING PRODUCTION STANDARDS
This document is used by the production team to present a clear picture of how the files will be created, organized, named, and stored at the final Web site. With 3-5 students working on the same site it is easy to get your signals crossed. If one student is naming all files in UPPERCASE with a .html ending and another is using lowercase.html there will be confusion when everyone starts to link.

Spell out the following criteria:

1. What development tool will be used? Your choices include straight HTML, Dreamweaver, Go Live and FrontPage. Some of the editors will dramatically alter the code you create so I have found it best if the entire team uses the same product. If you cannot agree on a product then test the products you are using to make sure that DreamWeaver does not alter the pure HTML code created by your teammate.
   
2. What code will be included? Will Cascading Style Sheets be used? What about Server Side Includes or Frames? These questions need to be decided at the beginning of the project to avoid having to remodel the site later.
   
3. Establish file naming conventions(ie names lowercase, ending html)
   
4. How will the files will be organized on the server. Will there be a separate directory for graphic images, and another directory for the Web pages which deal with the product. This flowchart determines where the files are stored - it is dramatically different from the flowchart that describes how the user navigates thru the site (the storyboard)

DEVELOPING A WORK CHART
Now that you have a list of deliverables you need to assign team members to produce these products. I refer to this document as a work chart. I have found it easiest to create the work chart by looking at the "Responsibility Checklist" for each team member, use that as a guideline for creating this document.

The work chart needs to be very specific if 2 or more people are involved in a task. For example if you have a 25 page web site, the work chart needs to specify what pages each content developer is responsible for as well as listing any pages made by the designer or programmer.

Special Note - if during the course of the project a team member is not able to complete the tasks they signed up for an email "change of assignment" needs to be sent to me. The change must be approved by the project manager and the instructor.

TIMELINE
This is used to let your team know when things need to be done. you can use my class deadlines as a guideline, however you may want to have your deadlines be a few days earlier than the class deadlines. Some PMs choose to combine the work chart and timeline into a single document. The choice is yours.

CONTRACT
This contract we use in class is a very simple document which attempts to describe what your team will provide and what they as clients will do in return. To define what your team will provide the document refers to various Web proposal documents. The sample contract lists several items you can ask the client for in return for their site (a letter of reference, credit at the site, etc. ). This class contract is NOT a model for a contract you would use in industry. Some Web development companies place the content of the proposal into the contract, while others use a generic form that refers to documents which describe this specific site. If you decide to become a freelance Web contractor, I recommend you seek legal counsel in developing our contract.

BID (optional)
If this were a real Web proposal we would be clearly stating how much the site would cost to produce. In this class the site is free, but estimating a bid may be a valuable learning experience for your group. This semester the bid is an optional element in the proposal. I encourage you to do one but am not requirig it.

There is a final bid which is due at the end of the semester which will eventually linked to the peoject site. To create the final bid or the bide estimage the PM needs to ask the team how many hours they "estimate" they will spend completing all the items listed on the Work chart. When estimating how much time you will spend on the project you can count client meetings, team meetings and production time. I recommend you do not count meetings where the team spent time getting to know each other, time you spent learning new software, or class meetings.

After estimating the amount of time you will spend you can set a rate of payment. As students you are not able to bill at the rate a professional would be paid or a Web Development firm would charge. I recommend you use these rates.

Content Development - 15 per hour
Design - 25
Programming - 40
Project Management - 30

At the end of the semester you will be asked to submit a bid which is an accurate reflection of the time you spend creating the site, You can then look back at your bid estimate and see how accurate you were.

It may be helpful to see the finished bid if your team decides to create a bid estimate.

Examples of Former Student Bids
NBCC
Alliance for Community Media
North bay Library Consortium
KITH
Additional examples of former students bids

TECHNICAL BRIEF
This is a combination of a layman's explanation of what programming will be included and a "techie" description of how the plan will be implemented.

CREATIVE BRIEF & MOCK UP (optional)
This creative brief provides the designer with as opportunity to explain why they chose the design elements they did. The mock ups area pictured of what the site will look like after it is sliced and turned in HTML The deadline for client approval of the design and creative brief is one week after the proposal meeting.

Finally here are links to former student's project Web sites, many proposal elements can be viewed from these sites.

Web Proposal Examples
TLT - by Jeri Hastava
DAAC - Cathy Clary
Theatre Arts Project Site - this is a plain text site which is just fine if you are a PM who is not applying for a design certificate.
Petaluma Arts Council - by Linda Drexler. The design for this Project site was quite sophisticated. This would be what I expect from a PM who is applying for a designer certificate.
SRJC Culinary Arts Program - David Williams The design of this site was taken from the client's site. Both the client site and project site match. This is not required.

Content for these teaching materials were developed by Linda Hemenway. If you have questions or comments on the material I can be contacted through
lhemenway@santarosa.edu
(707) 527-4855

Web site design by Jessica Hirsch - jessicahirsch@email.msn.com

Funding for these notes provided by Project FIVE and Project PICTS supervised by Doug Garrison - Dean of the Petaluma Center.