Datasheet

Establish the Scope
If we were asked to build a house, there are a few questions we’d want answered before agreeing to do
the work. How large will the house be? How many rooms? What kind of budget is allocated for this pro-
ject? All of these questions are meant to establish the scope of the construction project. It’s a means of
gathering information about the project, so that you can more intelligently assess its needs. By establish-
ing the scope of the project, we can better understand exactly how involved the project is, how long it
will take to complete, and how much it will cost — all items that are integral to any formal contract.
If you can’t tell by now, our construction metaphors aren’t exactly our strongest point. But while we
might have been snoozing through those episodes of This Old House, the parallels to the start of a Web
project are uncanny. Before firing up Photoshop or slinging one line of code, you and your client should
work together to produce a well-reasoned scope statement. This aptly named document not only deter-
mines what work will be performed throughout the duration of the project, but also implicitly defines
what work is outside the scope of the project. This is an incredibly important point. When the deadlines
are tight and the expectations high, knowing exactly what is expected of you throughout the course of
the project will keep your budget in check, and both you and your client focused.
Most frequently, the scope statement contains the following information:
❑ Strategy. This contains some information about the goals and business needs behind the project.
Is the site you’re designing supposed to increase advertising revenue, or shore up readership
numbers? Is the project supposed to increase a site’s accessibility, or its search engine ranking?
❑ Deliverables. These are the products that will be created over the course of the project. If your
project involves some level of site planning, will you be building a site map, or providing wire-
frames? When the project is finished, will you provide the client with all the Photoshop files
used in your designs?
❑ Assumptions. This is all of the conditions and constraints that were used to establish the scope
and upon which all other timelines and goals are founded. Should any of these initial assump-
tions change, the scope of the project should be revised accordingly. For example, if initial client
meetings uncover only 30 pages on the site that need to be built, then the landscape (and your
estimated budget) can change rather drastically when the client informs you two weeks into the
project that it has another 300 pages it would like you to redesign.
❑ Scope management. No matter how extensively you document your assumptions and time-
lines, someone will invariably request changes during the course of your project. Whether it’s
Murphy’s Law or bad karma, it doesn’t matter — you and your client need to acknowledge that
this change will likely occur and mutually agree upon some process for handling it. Some devel-
opers will write a separate document detailing how these changes are managed, and how the
client approves the resulting changes in schedule and budget.
This isn’t an exhaustive list, nor should it be seen as definitive. As we’ll no doubt harp at you through-
out the remainder of this book, each project has its own needs, its own goals. Because of this, each scope
statement should be tailored to reflect this.
However, it is important to remember that it is the project scope that forms the basis for whatever contract
you and your client establish. Because of this, the gathering of the requirements should be a highly collab-
orative process. You and your client should work closely together to flesh out exactly what information
should go into the scope statement. Otherwise, if you and your client have differing expectations as to
what work falls under the auspices of the project scope, then problems may arise as deadlines approach.
2
Chapter 1
03_588338 ch01.qxd 6/22/05 11:18 AM Page 2