- Gathering Information
- Understanding Your Audience
- Analyzing Your Industry
- Understanding Discovery
- Determining Overall Goals
- Preparing a 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
- Phase 1 Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
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
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
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 randomly changed 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.
)
none 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.