• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Chapter 03. Phase 1: Define the Project > Creating a Project Plan

Creating a Project Plan

With all Discovery data collected and site goals defined, you can move confidently into the creation of a Project Plan. There are separate and distinct aspects of the project to plan, but when you have finished, you will have assembled several deliverable documents that help define the project and plot the course of action for the development of the site design. Compiled, these documents form your Project Plan. Larger companies put far more effort and resources into these documents (which can swell in size to 100 or more pages), but we live in the real world. What we present here are the key items that make up the Core Process — the minimum amount of planning and organization necessary for a project's success.

Sometimes referred to as a Scope Document or a Project Charter, the Project Plan should contain at least the following (each of which is described in detail elsewhere in this chapter and is listed here in suggested order):

  • Project overview

  • Schedule (including deliverables and methodology)

  • Budget breakdown, with allocated hours

  • Communication Brief


  • Creating a Project Plan

  • Setting the Budget

  • Creating Schedules

  • Assigning Your Project Team

  • Setting Up Staging Areas

  • Planning for User Testing

  • Kicking Off the Project

Additionally, the following are suggested, though not mandatory.

  • Target audience information

  • Audience profiles

  • Audience technical capabilities

  • User testing plan

  • Details and assumptions

  • A line for the client's signature

Proposal or Project Plan?

We're not offering marketing, sales, or business- development advice here. The Core Process assumes you have the project already. We hardly touch proposals (maybe next book). With that disclaimed…

What is the difference between a proposal and a Project Plan? Both are used to define the project, outline overall goals, and announce the plan of action. Both contain a budget and a schedule with deliverables clearly defined. But as far as the Core Process is concerned, the main difference is this: The proposal is a skeletal overview, or starting point, and is dealt with before you have a signed contract. The Project Plan goes much deeper into details and execution strategy. It comes after the signed contract.

The Project Plan protects both the team and the client. It spells everything out and forms a referential starting point for the project. By agreeing to the contents of the Project Plan, the client acknowledges that they understand what the team is preparing to undertake on their behalf.

The Project Plan is a deliverable. It can be submitted to the client, along with a legally binding contract and initial invoice. Once the project officially starts, any changes to this document will result in an additional charge (AC), so take care when listing needs and details. With a client signature on the Project Plan or proposal (whichever you create), you can move forward.

Details and Assumptions

At the end of the plan, near where a signature is required (and the client is sure to be paying attention), include a list of Details and Assumptions [3.8]. The Details and Assumptions list is concise and confirms specific items that often are inadvertently subject to independent thinking (which is a diplomatic way of saying “Items the client assumes can be randomlychanged at their whim, such as the schedule”). Its main purpose is to protect the team, primarily against situations concerning scope changes. It achieves this by clearly identifying the boundaries of the project in an easy-to-understand list format. Perhaps these three items appear in your Details and Assumptions list:

  • This site will contain 20 to 25 pages.

  • This project is scheduled to be completed in 10 weeks.

  • All stock photography/illustration fees are the responsibility of the client and are not included in the budget. Obtaining any/all usage rights for stock work is the responsibility of the client.

Make sure the client approves and signs off on the Project Plan. Nothing creates accountability more than a signature.

3.8. Use this sample Details and Assumptions list as a guide. As these are only examples, you should modify them as your project requires. Be as descriptive as possible. Note that although the Details and Assumptions list can be included in a contract (and therefore be part of a legally binding agreement), on its own it does not substitute for a legal contract. It is for clarification and reference only.

This document covers you against unanticipated changes in scope and provides the team with a point of reference for increasing the budget. The more detail you provide, the more protected you are. (This is especially important for web development firms.) Please note — this documentation does not replace a legal contract, which is generally drawn up by the hiring firm if you are an outside vendor. For more information on legal contracts, please refer to Web and Software Development: A Legal Guide by Stephen Fishman.

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint