Impossible tri-bar

Digital Phenomena - Your first stop for internet consultancy 
Wanna Be a Project Manager?

Page 6 — Discovery Stage

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 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»

|Home|About Us|Services|Search|
W3C validatedW3C validated CSSCompatible with all browsers