The four general stages for getting a Web project to launch are:
Discovery, Planning, Production and Engineering Integration, and Quality
Assurance Testing and Wrap-up.
The discovery phase is when you figure out the basic structure and
purpose of the website.
Brainstorming: The first step is to brainstorm. I suggest accompanying
this with a client questionnaire. Write down all the questions that need to
be answered about the project. Some sample questions: "What is good/bad about the competition?" "Who is your
primary audience?" "How will you promote your brand with this website?"
One client I worked with at an entertainment company would
meet with the Web team and tell them to create something amazing like no one
had seen before on the Web -- and that was usually the extent of his
direction. The UI team and designers -- thinking they had creative
freedom -- developed original ideas and concepts that the client
always disliked because, unfortunately, they couldn't read his mind.
The client must provide detailed direction and not rely on the designers
and writers to develop the concept. The project manager needs to extract
this information from the client and force him/her to make decisions.
Requirements doc: The brainstorming meetings should produce a written document that outlines the site's scope and feature set. This document acts
as a starting point for everyone -- the client and the Web team. If, at the
conclusion of the brainstorming sessions, you can all sign off on the
contents of the document -- usually called a requirements document or work
order -- you're in pretty good shape.
Research: Once everything’s down on paper, the departments
need to do some research. For example, the designers should check out the
competition's websites. The engineers should check the feasibility of the
programming the site will require. The user interface designer should
start testing scenarios to show whether the site is going to serve
the needs of the client's audience. UI could draw up some rough schematics
of the website.
Scheduling: Using the requirements doc and the research results from tech, design and UI , you can start initial scheduling and budgeting.
Determining the schedule is your toughest task because
so much rides on these decisions. My advice is be pessimistic and pad the
dates.
The best scheduling tool is Microsoft Project. I've tested a number of other
project management software packages, and nothing works better. MS
Project makes creating a schedule and changing it as needed simple because it
automatically recalculates the schedule and budget. With a little practice,
you'll be creating beautiful schedules in no time.
The launch date: Find out what is really setting the client's desired
launch date. Is it an event, a third quarter stockholder report, or the
desire to launch an excellent well-tested product? It's usually not the
latter. Here are a few rules to try to follow when setting the schedule.
However, budget pressures will always win the argument.
1. Never plan press or party events around a Web launch. No matter how
hopeful or optimistic management is, this is a recipe for agony and
disaster. An example is the holiday media blitz that was attempted by the
e-commerce website I worked at. It was the worst
combination of untested software and optimistic scheduling.
The company spent
millions of its precious venture capital on a print and television
advertising campaign that was to run concurrent with their launch. Media
buys for print and TV happen months in advance. So the buyers went ahead and
purchased the ads because they felt tremendous pressure to launch the site
before the holiday buying season. So instead of a quality product
determining the media campaign launch, the ad campaign set the launch date.
At launch barely half the sales actually made it through the bug-laden
purchasing process, which turned off the majority of customers who came to
the site after seeing the advertising campaign.
2. Trust your schedule and stick to it. Don't let anyone convince you
they’ll get something done faster than you know they can. If it's going to
take six months, that is how long it will take. Careful thought takes
time. Good design takes time. Writing solid code takes time. These things
can't be rushed. However, you can look for alternatives.
Set up an online
store with Yahoo or Bigstep instead of building one from scratch. Build the
site in phases. Establish priorities and calculate how much of the site
can be built in three months versus building everything in six months.
3. If a delay is caused by the client or by some other unforeseen
catastrophe, stick to your schedule or push the launch date back by as many
days as necessary. Unfortunately, while this is nice in theory it usually doesn't work.
I worked
for Lucasfilm's Star Wars website during the launch of Episode I. The full
length trailer was highly anticipated and Lucasfilm wanted the first online version to be Apple's high-quality QuickTime and not a grainy video taken from inside a theater. Everything was moving along according to schedule when we realized that
because of time zone differences, Australia had permission to exhibit the
trailer a day earlier than theaters in the United States or Europe.
This opened up
the possibility that a fan might videotape the trailer in a
theater and post it on a fan website. On our side of the planet, we weren't
ready to post the trailer -- but it didn't matter. We worked all night
setting up the pages, reviewing the QuickTime and posted it a day
early.
4. Use virtual space. Create a simple Intranet where the team and client can
view and download documentation. Include all the information you can on the
Intranet and get the staff in the habit of checking it first for schedules
and documentation. This will greatly reduce the number of repetitive
questions.
Get e-mail aliases set up and get people using them from the very start.
Identify tech and design contacts at the client's company and get their
e-mails and various phone numbers. Remembering team@yourcompany.com is much
easier than keeping track of a half dozen client, contractor and internal
e-mail addresses.
Create a reliable server workspace for your project. You may need more
than one. For example, engineers are much more likely to bring down the
server than the HTML coders, so allocate a special place for them to do
experimental work. Get the proper passwords and permissions system set up
for everyone.
next page»
