 |
|
 |
|
The project plan is the guideline and overview
for the project scope. It can take many forms,
from an extensive document (sometimes called a
scope document or a project charter) to a simple
overview of methodology, budget and schedule.
The project plan should contain enough information
and detail to accurately describe the project
to both the client and the Web development team.
This plan should outline the project phases, the
project team, the schedule, budget and deliverables.
The plan can also contain information about usability
testing, QA and any other services relevant to
the project. Database or dynamically driven site
development often runs on an interrelated development
track, through the engineering team. (Note: We
will cover these processes in future additions
to this site.) Be sure the engineering team is
involved in this phase as much as possible—such
early involvement is key to successful coordination
throughout the process.
Make sure to have the client approve and sign
off on this deliverable (along with all other
important papers and milestone documents). Requesting
a signature greatly increases the likelihood that
a document will be read. Once the project starts,
any changes to this document will result in an
AC (additional charge) or project delay—so
define and outline needs in a careful manner.
One of the greatest challenges is to effectively
outline the details, deliverables and assumptions
of any given project at the outset. A clear definition
and a roadmap are necessary to avoid any issues
of scope creep down the road.
|
| |
|
Scope
Creep
|
| The inevitable
migration of a project from a budgeted, scheduled,
defined plan to a slowly expanding source
of conflict, confusion and additional costs.
|
|
| |
Establishing
a Project Team
Each project requires varying levels of expertise.
Determine what project-specific needs you have.
Is the site a dynamic site? Is there a large multimedia
effort? Will you need specific Web programming or
database expertise? Determine the individual roles
and responsibilities of the team. One team member
may wear several hats, but each hat must be defined.
First, there are basic roles that will need to be
filled. The following list of roles and descriptions
show general descriptions of team member responsibilities.
Depending on the scope of the project, level of
expertise needed and overall budget, some of these
roles may expand into actual teams, other roles
may be filled by one individual. |
| |
|
|
| Team Member |
|
Description of Services |
Project Manager/
Producer |
|
Manages expectations
through a project's lifecycle. Determines project
needs, outlines specific deliverables and oversees
the process and team from start to finish. Maintains
ongoing client communication and education throughout
project. Handles budget and scope issues, including
weekly status updates and additional charges. |
| |
|
|
| Art Director/Designer |
|
Oversees visual design
process. Helps to translate client expectations
into a visual look and feel. Applies technical and
user needs into final UI (User Interface) design.
Works with project manager and client to establish
a clear vision for the site. Manages design team
to create design comps and final layered files to
hand off to production. |
| |
|
|
| Information
Architect/Designer |
|
Defines overall site
organization and layout from an informational, navigational
and functional perspective. Works with client and
project manager to determine overall content strategy
and site structure (site map), page layout (screen
schematics) and interaction (user paths) throughout
a site. Participates in usability testing and works
with production and engineering to bridge gap between
design and technology. |
| |
|
|
HTML Production
Lead/
HTML Developer |
|
Facilitates production
and implementation of visual design templates into
final HTML. Oversees design and prototype phase
to ensure visual direction can be translated effectively
into HTML. Works with HTML production team to maintain
standards for coding. |
| |
|
|
Copy Writer
or
Content Manager |
|
Provides a consistent
style and tone. Works closely with client to gather
all information and materials for the Web site.
Understands fundamentals of Web ready copy, and
has a clear understanding of the overall goals and
communication objectives of the site. Works with
the information architect to implement content in
an efficient manner. |
| |
| Additional
Roles (Depending on Scope of Project) |
| |
|
|
Engineering
Lead/
Technical Lead |
|
Provides management
and direction of the engineering team for back-end
projects such as database development or system
integration specialists. Acts as a liaison between
front-end and back-end teams. |
| |
|
|
| Usability
Specialist |
|
An individual with
a background in human factors engineering and/or
cognitive psychology who has a broad understanding
of usability issues on the Web. This individual
should have knowledge in information design, navigation
and Web development processes. |
| |
|
|
| QA Lead |
|
The QA lead is responsible
for creating a test plan and determining the testing
needs of the project according to size and scope.
The QA lead ensures the project is delivered under
specifications and monitors the testing process,
the tracking of bugs and errors, and the resolution
of testing to a final release. |
| |
|
|
Creating a Schedule
Creating a timeline and methodology for the project
is the first project document you need to hand out
to your team and client. An initial overview should
give a comprehensible breakdown of the project by
week—showing the process, methodology and deliverables
in one view. Whether created in Microsoft Word,
Microsoft Project, or Macromedia Dreamweaver
with the Calendar
Object extension, the schedule should be a document
that communicates urgency. The schedule can be elaborated
on after the project begins, showing specific deadlines
and deliverables in an expanded manner. Sometimes
presented in a calendar view, sometimes presented
in a task-oriented view, the schedule needs to quickly
convey deliverables, due dates and process. The
schedule should also outline content requirements
and milestone dates for delivery (content is further
detailed in Phase 3.) The more complex the project,
the more detailed the schedule. |
| |
Establishing a Budget/Assigning
Hours
It is usually a matter of experience to truly define
a project's budget. You can quickly gauge a project's
budget by taking a realistic view of the resources
and time allocation. Once the budget is established
and hours for each task and/or individual are assigned,
you will need to track hours carefully through a
project each week to see how much time has been
used and how much time is left (according to your
budget allocation). When tracking hours in this
way, you are able to give a heads up to the client
early on in the process, and also see where and
how a project is going out of scope. For design
firms: There are two realities when determining
budget. One—we charge what we can. Two—we
base our cost on hours. Determining how much the
client has to spend on a project is often a good
place to begin. |
| |
Determining Deliverables
Understanding what is due and when it is due keeps
a project moving forward. By setting up clear deliverables
and due dates for both client (internal or external)
and team members, you will ensure that each person
knows what they are supposed to be working on. Design
efforts are often inefficient when undertaken without
a specific deadline. A deliverables list can be
created within a detailed schedule elaborated on
from the schedule overview or can be a separate
check list with draft, review and final dates for
each item. Be clear. Update the team and client
weekly, as deadlines shift and change throughout
the process. |
| |
Creating a Usability
Test Plan
Gathering actual user feedback throughout the process
is one of the best ways to develop and refine your
project to improve the user experience. Usability
testing is one valuable means of obtaining firsthand
data through observation. There are many valid forms
of feedback (focus groups, online surveys, etc.)
but usability testing differs in that it shows what
users actually do, not what they think they might
do. Usability testing is a one-on-one interaction
between a moderator (preferably with a background
in human factors engineering) and a participant
(a typical user of the site). The moderator observes
the participant moving through the site completing
predetermined tasks. The usability test plan takes
the project plan as a foundation and identifies
where various forms of usability testing can best
fit into the overall process. |
| |
Creating a QA Plan
QA, or quality assurance, is one of the most often
skipped steps of the Web development process. Usually,
during the HTML production phase, the site is checked
by the production artists on different browsers
and platforms to make sure the pages don't break.
This is valid testing during production, however
it is usually not enough, particularly for highly-trafficked
sites. A QA test plan outlines the manner in which
the site will be tested before launch to ensure
compatibility with a targeted (predetermined) set
of browsers, platforms, screen sizes and more. Depending
on time, budget and a measure of the impact of the
site going live with errors, a QA plan will outline
the browser and platform specifications, specific
test paths if functionality is involved and how
bugs will be tracked. The complexity and cost will
vary from a formal (using an outside facility or
trained QA staff) to very informal (using existing
team members and the client) approach; in any case,
building in time to test, fix and re-test can make
or break a successful site launch. |
| |
|
|
|
|
|
