"Scope Creep" is the most
prevalent cause of Web project failures.
In
many projects, scope creep is the gradual process by which previously
unplanned "features" are added, content and features
are padded to mollify each stakeholder group, major changes in
content or site structure during site construction are made, and
more content or interactive functionality than you originally
agreed to create is stuffed in.
No single overcommitment is fatal, but the slow, steady accumulation
of additions and changes is often enough to blow budgets, ruin
schedules, and bury what might have been an elegant original plan
under megabytes of muddle and confusion.
Don't leap into building a Web site before you understand what
you want to accomplish and before you have developed a solid and
realistic site specification for creating your Web site. The more
carefully you plan, the better off you will be when you begin
to build your site.
Developing a site specification
The
site specification is the planning team's concise statement of
core goals, values, and intent, to provide the ultimate policy
direction for everything that comes next. Designing a substantial
Web site is a costly and time-consuming process. When you're up
to your neck in the daily challenges of building the site, it
can be surprisingly easy to forget why you are doing what you
are, to lose sight of your original priorities, and to not know
on any given day whether the detailed decisions you are making
actually support those overall goals and objectives. A well-written
site specification is a powerful daily tool for judging the effectiveness
of a development effort. It provides the team with a compass to
keep the development process focused on the ultimate purposes
of the site. As such, it quickly becomes a daily reference point
to settle disputes, to judge the potential utility of new ideas
as they arise, to measure progress, and to keep the development
team focused on the ultimate goals.
Planning
Web sites are developed by groups of people to meet the
needs of other groups of people. Unfortunately, Web projects are
often approached as a "technology problem," and projects
are colored from the beginning by enthusiasms for particular Web
techniques or browser plug-ins (Flash, digital media, XML, databases,
etc.), not by real human or business needs.
People are the key to successful Web projects. To create a substantial
site you'll need content experts, writers, information architects,
graphic designers, technical experts, and someone responsible
for seeing the project to completion.
If your site is successful it will have to be genuinely useful
to your target audience,
meeting their needs and expectations without being too hard to
use.
At
minimum, a good site specification should define
the content scope, budget, schedule, and technical aspects of
the Web site.
The best site specifications are very short and to the point,
and are often just outlines or bullet lists of the major design
or technical features planned.
The finished site specification
should contain the goals statement from the planning phase,
as well as the structural details of the site and answers to the
following important questions:
Goals
and strategies
What is the mission of your organization?
How will creating a Web site support your mission?
What are your two or three most important goals for the site?
Who is the primary audience for the Web site?
What do you want the audience to think or do after having visited
your site?
What Web-related strategies will you use to achieve those goals?
How will you measure the success of your site?
How will you adequately maintain the finished site?
Production issues
How many pages will the site contain? What
is the maximum acceptable count under this budget?
What special technical or functional requirements are needed?
What is the budget for the site?
What is the production schedule for the site, including intermediate
milestones and dates?
Who are the people or vendors on the development team and what
are their responsibilities?
These are big questions, and the broad conceptual issues
are too often dismissed
as committees push toward starting the "real work"
of designing and building a Web site.
However, if you cannot confidently answer all of these questions,
then no amount of design or production effort can guarantee a
useful result.
Content inventory
Once you have an idea of your Web site's mission and general structure,
you can begin to assess the content you will need to realize your
plans. Building an inventory or database of existing and needed
content will force you to take a hard look at your existing content
resources and to make a detailed outline of your needs. Once you
know where you are short on content you can concentrate on those
deficits and avoid wasting time on areas with existing resources
that are ready to use. A clear grasp of your needs will also help
you develop a realistic schedule and budget for the project.
Content development is the hardest, most time-consuming
part of any Web site development project. Starting early
with a firm plan in hand will help ensure that you won't be caught
later with a well-structured but empty Web site.
One
excellent way to keep a tight rein on the overall scope of the
site content is to specify a maximum page count in the site specification.
Although a page count is hardly infallible as a guide (after all,
Web pages can be arbitrarily long), it serves as a constant reminder
to everyone involved of the project's intended scope. If the page
count goes up, make it a rule to revisit the budget implications
automatically — the cold realities of budgets and schedules
will often cool the enthusiasm to stuff in "just one more
page."
A good way to keep a lid on scope creep is to treat the page count
as a "zero sum game." If someone wants to add pages,
it's up to them to nominate other pages to remove or to obtain
a corresponding increase in the budget and schedule to account
for the increased work involved.
Changes
and refinements can be a good thing, as long as everyone is realistic
about the impact of potential changes on the budget and schedule
of a project.
Any substantial change to the planned content, design, or technical
aspects of a site must be tightly coupled with a revision of the
budget and schedule of the project. People are often reluctant
to discuss budgets or deadlines frankly and will often agree to
substantial changes or additions to a development plan rather
than face an awkward conversation with a client or fellow team
member. But this acquiescence merely postpones the inevitable
damage of not dealing with scope changes rationally.
The
firm integration of schedule, budget, and scope is the only way
to keep a Web project from becoming unhinged from the real constraints
of time, money, and the ultimate quality of the result.
A little bravery and honesty up front can save you much grief
later. Make the plan carefully, and then stick to it.
(c)
Yale University Web-Style Guide, 2nd Edition
http://www.webstyleguide.com/process/specify.html
