Managing Web Projects
Understanding project management for the Web
8/17/98

by Sara Fleming

The term project management conjures up visions of corporate employees in dark suits, huddled around PowerPoint presentations, muttering about Gantt charts and ROI. It's probably not an image that most web developers find appealing.

The Web needs another infusion of corporate culture like the Net needs another spammer. The good news is that you don't need a dark suit, an MBA, or even the title "Project Manager" to manage projects well. Strip away the business-school vocabulary usually associated with this discipline (phrases like "critical success factor" and "responsibility assignment matrix" come to mind) and you arrive at its essence: defining and organizing the components of a project in order to complete it successfully.

Could your projects benefit from some organization? Is your team acting anything but team-like? Are your client relationships in crisis? If so, read on.

Project Kickoff

Let's say the boss has just dropped by to let you know about a major new web initiative. If you're a freelancer, maybe your Aunt Betty has just sent you a prospective client. Either way, a project -- unformed and a little nebulous -- has just made it onto your radar.

What's your next step? Creating sketches of the home page? Diving into the code? Before you jump in, you need to get the answers to some important questions:

• Who is the client?
• What is the scope of the project?
• What are the project's goals?
• Are there multiple phases?
• Who is the audience for the product?
• What is the desired timeframe?
• What resources will be necessary to complete the project?

The client
If you work for a web firm or are an independent contractor, you understand the term client. It's the person or people for whom web development work is undertaken. In-house development staff might think of this role as a product manager, or just "the boss." In any case, when a new project hits your desk, it's important to know who's behind it.

Maybe it seems obvious. The client is the person on the other end of the phone saying, "I want it yesterday," right? Occasionally, yes. But find out if that person is really calling the shots on the project. Are they authorized to make decisions related to the project, and can they grant approval? Find out who the project contact will be and, most importantly, who needs to sign off on the finished product.

Project scope and goals
With the exception of R&D labs and personal home pages, most developers build sites for a client. And before you can start to build a web product for a client, you have to know what they're looking for, what business need they're trying to fill, what goal they hope to reach in what timeframe. You need to know the scope of the project.

Defining the project scope is not a difficult process, assuming the client has an idea of what they want (it can be very difficult if they don't). Sit down with the client and have them describe in as much detail as possible what they're looking for -- specific goals, business model, look and feel, features and functions. Identify separate phases of development, if any. Then put the scope on paper and don't do another thing until the client has reviewed and approved it.

With the scope outlined and approved at the outset, any change in scope during the course of the project will be apparent, and the project timeframe and cost can be renegotiated if necessary.

Project assessment
Another important part of the project-definition stage is to assess whether you have the resources you need to meet the project goals within the client's timeframe. It's much wiser in the long term to decline or delay a project if the resources aren't available, rather than risk sanity and reputation by pushing it through against all odds.

At the end of the project-definition stage, you should have a much better idea of the work that will be involved. Now you can move on to building your team.

Building the Team

By now you've begun to develop a relationship with the client and you've hammered out the project scope and goals. This should give you a sense of the tasks that will be necessary to complete the project, and what roles those tasks are associated with. You're ready to form the project team.

Project roles
In the early days of the Web, all your web development needs could be met by that one-person wonder, the Webmaster. These days there's much more specialization. A major web project these days might include not only a graphic designer but also an information architect and a usability engineer. Instead of a single Webmaster performing all technical functions, you might now see around the project table an HTML production specialist, a Perl programmer, a database developer, and a systems administrator.

The more roles there are, the more distributed project tasks become. The more this happens, the more you need a project manager to pull the pieces together.

Assigning staff
The process of assigning people to a project is different from company to company, but whether you use in-house staff, independent contractors, a design firm, or a combination of these to fill the roles on your team, all team members must understand what's expected of them. That means understanding not only the project's scope and goals, but also specific team tasks and responsibilities at every point in the development process.

Particularly when working with independent contractors or outside firms, take the time to go over your expectations. Will team members have access to the servers? Will they work on-site or remotely? Will they QA their work or will someone else? These little questions can add up to big headaches if team expectations differ.

The kickoff
Once the team is formed, get the project off the ground with a kickoff meeting. This is a good opportunity to review the scope in detail, assemble detailed specifications, create preliminary project schedules, and build enthusiasm for the project and a sense of team identity.

If you have no other meetings in the course of the project, have the kickoff meeting. When it goes well, it can give the project a large push in the right direction.

Project Communication

Project communication begins with the first client contact and continues through the life of the project. It includes any contact among the project manager, client, and team -- everything from e-mail to meetings to shared documentation and project sites.

Team meetings
Whether your team is distributed across many locations or all in the same room, most projects will start and end with meetings of the full project team. (And if my mailbox is anything to judge by, much of the contact in between will be via e-mail.) For the duration of the project, the project manager should be the communications hub and the primary (and sometimes only) contact with the client.

If all major projects should start with a kickoff meeting, they should wrap up with a postmortem. A postmortem is held after all tasks have been completed and the project has been closed down. The project manager, development team, and, where appropriate, the client meet to discuss the project's successes and failures. This is particularly helpful if members of the team work together regularly on multiple projects. One project's success or failure can benefit the next project that comes down the pike.

Documentation
A shared set of project documentation gives the team a common reference as development moves forward. The project scope document outlines the project's goals. The project plan, or schedule, maps specific tasks against the project timeline (Microsoft Project is a commonly used tool for this function, but other tools are also available; http://www.microsoft.com/products/prodref/576_ov.htm). Technical and production specifications make the developer's job easier, as do flowcharts and style guides.

Beyond this core set, a project's document library may include anything that's a useful reference document for the team or the client. It's important, though, to reflect changes in scope or specifications in the project documents. In order to be useful, they should be up to date.

Once formed, the project document library can become part of a project Web site. The project site can also host design comps, prototypes, team contact information, and any number of other things. David Siegel covers project sites in depth in his book Secrets of Successful Web Sites: Project Management on the World Wide Web.

Progress updates
One of the project manager's most basic responsibilities is to track the progress of the work. Are tasks being completed on time and in the right order? Are developers aware of what tasks they need to complete next, and when these tasks needs to be completed? Is the client completing tasks they're responsible for, such as providing content?

The project manager needs to be constantly aware of the current state of the project and the team. Progress updates should be provided to both the client and the team at regular checkpoints. These checkpoints allow the team to assess project status and air any concerns or problems.

Managing Risks

We've all seen it happen: just when a project seems to be doing well, the client unexpectedly changes the scope, a team member gets pulled onto another project, a technical problem doubles production time. Suddenly the schedule is a work of fiction. The project's success is jeopardized.

No matter how talented a project manager you are, unexpected challenges arise on every project -- challenges that threaten the schedule or the budget or the relationship with clients or team members. These are project risks. Risks are an unavoidable part of all projects. The key is to anticipate as many of them as possible at the start of the project, build in contingencies wherever possible, and manage any risks that do arise.

What can go wrong
The following are examples of risks that may threaten a project. A single project may suffer from one or (in cases of real trouble) several of these risks:

• The project's scope and goals are poorly defined. The project manager, the team, and the client should all have a thorough and identical understanding of the project's goals and scope.
• The project's timeline is unrealistic. The rush to launch a web product can lead to unrealistic schedules that don't allow for completion of tasks. These schedules often invite failure. Scheduling conservatively usually results in a more reliable launch date.
• The client doesn't have full authority to make decisions. This is one of the deadliest problems in the project-risk minefield. Beware of clients who aren't really calling the shots -- more often than not the project will be torpedoed, usually days before launch, by the higher-up who is.
• The business model hasn't been settled. Approach with caution any projects in which the client hasn't defined their business model, especially if it's an e-commerce application or an extranet project.
• Development begins before the planning is done. The adage "Measure twice, cut once" applies here. Putting your designers and programmers to work too early will only mean more revisions, headaches, and lost time.
• The project is understaffed. From what I've seen, the proportion of work to staff in web development groups virtually guarantees project understaffing. While it's tempting to try to squeeze in yet another project, be aware that the success of the entire pool of projects will be affected.
• Team members don't have the skills necessary to complete their tasks. One of the most uncomfortable problems a team can have is when someone isn't carrying their weight. Make sure every team member understands their responsibilities before joining, and make staff changes if necessary.
• Team members aren't invested in the project's success. For a project to succeed, the team members, project manager, and client must all be working toward its success.
• Progress isn't communicated to the team. It's not enough for the project manager to know what's happening -- the team and the client must also know where they stand, what they need to do next, and whether the project is on track.
• The pace of change on the Web itself may be a risk. With new technologies, sites, fads, business paradigms, and players appearing (or disappearing) every few months, the Web can be a risky project environment.

What can you do about it?
There are many practical steps a project manager can take in dealing with risks -- such as assigning additional project staff or negotiating changes with the client. But leadership and the right attitude are perhaps most critical.

From the outset, communicate risks clearly to the team and the client. Flag problems as soon as they arise. Create an atmosphere in which problems are discussed openly and solved quickly, creatively, and without finger-pointing. And be willing, if necessary, to start fresh or scrap the project if completion becomes unrealistic. Obviously this last option should not be undertaken lightly at the first sign of trouble, but only after all other constructive options have failed.

Quality Assurance

Consider all the things that can go wrong on a web site: bad links, images that don't load, missing ALT tags, typos, Javascript errors, cross-platform or cross-browser incompatibilities, technical glitches, server crashes, network outages. With all these potholes to worry about, why is quality assurance the first thing to be sacrificed when a project runs over schedule?

If a web project is worth doing, it's worth doing well. Most users won't come back if the site sucks... and neither will the client.

The testing process
The first basic principle of the testing process is that whoever built it shouldn't test it. I agree with this to a point. There's a ton of preliminary testing that the developer ought to do just in order to make the site or application ready for testing. When it goes to testing, the developer ought to feel that it's as clean as he or she could make it.

Once a site or application goes into testing, the tester should have a checklist to test against. That checklist might include:

• Testing forms and scripts
• Proofreading text
• Checking performance across browsers and platforms
• Confirming consistency with previous site style, where applicable
• Surfing with images off to check for missing ALT tags
• Checking links
• A variety of application-specific tasks, such as performing a search, changing personalization settings, etc.

Standards
Underlying the testing process is the assumption that there are standards for quality, performance, and style. Take the opportunity to build a style guide for each new or redesigned site you build. And take the time to set quality and performance standards early on.

The question of performance across browsers, for example, depends heavily on the site's audience. For example, a site that's aimed at a general "mass market" audience should look good in AOL's browser. Sites geared for the library or education market should be functional on Lynx. For other sites, consistent performance on 3.0 and 4.0 versions of Netscape Navigator and Microsoft IE might be more than sufficient.

The period between project kickoff and quality assurance testing might be ten days or ten months, but the mission of the project manager is the same: to successfully orchestrate the process of development. Of course, you could always leave success to chance... but why put your hard work at risk? The support and direction offered by a project manager can help stack the deck in your favor.

• Tell us about your nightmare project (or one you pulled out of the fire) in the discussion forums: http://www.ahref.com/talk/view_thread.html?thread_id=35
• Find related business and industry titles in the bookstore: http://www.ahref.com/tools/bookstore/booksindustry.html
• Browse related web resources in the Web Index: http://www.ahref.com/index/catlisting.html?cat_id=32

Sara Fleming is an Internet Project Manager based in the Boston area.

to industry guide

© 1998-1999 Anchor Productions, Inc. All rights reserved.