Introduction
This paper covers the fundamentals of web project management and discusses how to implement a successful web development project. Such a project can be on-time and on-budget, and also provide peak performance for you and your organization. The processes reviewed in this document are practical and have been selected to ensure that your project, regardless of its size, is a successful one.

Agenda
We will begin by briefly describing the Project Vision Document that will define your web project and its three components. Then we will examine the project team and how the team roles have changed from conventional IT development projects. Next we will review a full-scale web development process and its specific deliverables. Also we will examine what remains the same as conventional software development to ensure that your management plan has these covered as well. Lastly we will highlight a few words of wisdom from previous projects.

Business to Consumer Web Development Projects
There are as many different types of web development projects as there are conventional IT software development projects. There are internet external facing projects connecting to consumers, partners, and employees. There are Intranet internal facing projects connecting to employees and suppliers. And there are various mixtures of the two. For the sake of this paper we will limit our focus to external facing web projects involved in business to consumer e-commerce. These are web sites on the internet whose charter may include corporate marketing, product sales, electronic bill review and payment, product support and service. These sites often profile their users and provide personalized functionality and customization based on the user profile. If you have been to Amazon.com you know the type of functionality I am talking about. Managing the production of this type of site is the focus of this paper although the principles apply directly to most other web initiatives.

Project Vision Document
All web projects should begin with a Project Vision Document. The document should include the following: the project's goals and objectives, users and scope. We will examine each of these in detail next. The number of companies that will undertake a large and expensive web development initiative without spending time clarifying the vision of the project is quite remarkable. Let's not make the same mistake.

Goals and Objectives
The project's goals and objectives should be specific, measurable and attainable. It is important to be able to clearly identify that a goal has been achieved. One of the benefits of web sites is that user interaction is directly traceable. Use this to set goals that can be measured. Examples of measurable goals are:

• The web site will capture lead information on 20 new customers a week within 90 days of launch.
• The web site will cut support costs by 20% within six months of launch.
• The web site will increase customer retention by 1% at the end of year one.
• The web site will interact directly with customers and suppliers to cut order response time by 4 days.

All of these goals are specific and measurable. We can use them to determine if we have succeeded or failed, and if so, by what margin. Objectives such as increased brand awareness or improved brand perception may also be legitimate goals. But if you set them as goals identify how they will be measured, and how it is known that the impact comes from the web presence, and not other brand initiatives.

Users and Scope
The Product Vision Document should also clearly identify the target audience for the site, also known as the users, as well as the project scope. In other papers on IT project management we have covered how to capture users as actors and scope as use cases. That is exactly how we want to capture users and scope in the Product Vision Document. Seek to capture all of the primary actors as well as the core system use cases, typically considered about 15% of the total use cases. The actors and use cases can be effectively communicated in this document using UML Use Case Diagrams.

The Project Team
The nature and makeup of the project team differs as IT departments move from conventional software development projects to web publishing. Historically, IT software development projects often had the following general composition:

• Project Manager
• Analysts
• Software Team Lead / Chief Architect
• Programmers
• Database Administrators
• QA Team Lead
• Testers
• Hardware Engineers
• Deployment Team Lead
• Deployment Team Members
• Support Team Members

I will assume for the sake of this paper that you already understand and are familiar with standard IT development roles. Many of the roles transfer directly to web development projects. Some transfer with new or additional responsibilities and some are replaced. There are also many new roles. For example an externally-focused, consumer-oriented web team is likely to consist of the following:

• Strategic Planner
• Security Specialist
• Hardware/Network Architect
• Usability Specialist
• Producer
• Senior Software Architect
• Programmers
• Database Administrator
• Site Administrator
• Information Architect
• Art Director
• Production Artists
• Copywriters
• Translators
• Audio/Video Engineers
• QA Team Lead
• Testers
• Media Coordinator

As we move from conventional IT development to web development there are a few things that are immediately noticeable. First, we have defined a lot more roles; in this example seven more. Second, there are a lot more specialists. The reason for this is simple. External facing web development is attempting to accomplish a great deal more than most conventional IT projects. To develop and manage successful web sites it is essential to understand why these new roles exist and how they impact your ability to deliver a successful site. Let's review roles that are significantly different from their conventional software development counterparts in order to understand how they will impact your projects. If you do not have anyone in these roles, your project is in immediate danger of failure. Find the correct staff and fill the roles. I have placed the first four roles to review in order of importance.

Strategic Planner
The strategic planner is appropriately listed first. In the new economy technology is not simply how a strategy is implemented – technology often is the strategy. The strategic planner is responsible for mapping emerging technologies to corporate goals and objectives. They are chiefly responsible for creating the Project Vision Document and ensuring that the team understands and implements the vision. In order to understand how to reach the specific objectives in the vision document the strategic planner conducts market research on the target audiences, monitors competitor entries into the field, creates a competitive profile and delivers that insight to the entire development team. The strategic planner's work never ends; the internet is not standing still. They should remain with the project from conception to completion providing the core set of use cases and scenarios that describe what the users are trying to accomplish with the site.

Security Specialists
Listed second in importance after the strategic planner are the security specialists. They are essential to corporate survival in the exposed world of the World Wide Web. In conventional software development, software was often delivered in one of three ways. 1. It was shipped directly to the customer and installed by the customer on their personal machine. 2. It was installed on corporate client hardware by the corporate deployment team. 3. It was installed on the corporate server or mainframe hardware by the corporate deployment team. In any of these cases security was usually relatively simple and could often be addressed late in the development process. It was also generally easy to maintain, typically getting little or no attention after deployment. In case you haven't heard, this is not the case anymore. In the internet world software is deployed by releasing it to a server with a direct connection to the internet. Anyone on the internet can connect to the server and potentially use the application. They may also be able to reach into or through the server and access your corporate information infrastructure. Your critical corporate information is potentially open and exposed to the entire planet unless specific and active measures are put in place to close it.

Security can no longer be added as an afterthought; rather it is a core architectural focus that requires attention from the very beginning. And the security job never ends. Even after the site is launched the security specialist must continually monitor the site for signs of intrusion and tampering. Also, as your tool manufacturers identify new security holes these holes must be patched and closed. Security is not a one day a month job but an active and long term component of doing business on the internet.

The security specialist establishes the fundamental security infrastructure. They identify the number and configuration of the firewalls, setup the password and user identification paradigms, design the encryption and intrusion detection strategies, and are responsible for the protection of corporate and customer data. With that all said, it should be noted that sometimes security specialists get carried away. The strategist and the usability specialist must work with the security specialist to determine what the business drivers are that protect certain types of data. Otherwise, the security specialists tend to treat all data as requiring the same security, potentially making the site awkward and unusable. Like many things in life, security infrastructure is a balance of risk and reward.

Hardware/Network Architect
The hardware/network architect is listed next after the security specialist. The hardware/network architect focuses on the system infrastructure, the network and hardware topology. In the old days this role may have been limited to the person who buys expansion cards and runs network cable. Not anymore. In a web project the hardware architect works with the security specialist to lay out the core plan for site operations. They will be responsible for answering infrastructure questions on a variety of topics such as the Internet Service Provider, Co-Location, Redundancy, Local Load Balancing, Geographic Load Balancing and E-mail Management, just to name a few. Let's review some sample questions they will be answering.

Internet Service Provider – Taking into consideration such things as east/west interconnects, scalability, and site redundancy via physically divergent pathways; who is providing access to the internet backbone?

Co-Location – Where are the site operations physically located? Are they local or in co-location centers operated by the ISP?

Redundancy – Do the local sites need to be designed with fail over hardware connected in a hot-standby mode? Should multiple sites be geographically dispersed to correspond to the general topology of the internet?

Local Load Balancing – How is load balancing handled within a local web farm site?

Geographic Load Balancing – How is global traffic directed to the best local web farm?

E-Mail Management - Does the site send e-mails and solicitations to customers? If so, what products are required based upon the anticipated capacity?

By now we have all heard stories of companies launching a new site or advertising campaign that is so successful that the site crashes due to high traffic volumes. The hardware/network architects main job is to ensure that this doesn't happen to you.

Usability Specialist
Listed next in importance to the web team is the usability specialist. Recognize that the world has changed when software is deployed over the web. No longer are your users a captive audience. No longer are they reading manuals or taking training classes to understand your arcane user interface. If they can't understand how to get the job done from a friendly and intuitive interface then they will simply leave your site and go to a competitor's. After all, your competitor's site is only a click away.

The usability specialist is responsible for ensuring that visitors to your site stay at your site, and successfully get their work done with no special training and no frustration. They do this by making sure that the user is at the forefront of the site design. All other graphical and artistic considerations are subservient to usability.

Following Jakob Nielsen, an industry expert in the design of usable web sites, a site is usable if it is learnable, efficient, natural, accommodating and enjoyable. Usability cannot be added as an afterthought. It is a fundamental concern from the very beginning of the development process. Fortunately, designing for usability prior to building a web site has many distinct advantages, including more efficient construction of the site–by spending time up front becoming intimately familiar with the users, it is possible to create a site specifically focused on their needs and interests without continually reworking costly core infrastructure.

The usability expert will use multiple techniques to create their designs. These techniques will make your web site a delight to use, and will include Personas, Goal Identification, Scenarios, Storyboards, Prototypes, Cognitive Walkthroughs, Heuristic Evaluation and User Testing. If your usability specialist is not familiar with these techniques then either train them or get a new one. There is no compromise. Without the usability specialist you might as well take the money you are spending on the web site, put it in a giant hole, and set it on fire. That goes double for the money spent advertising the site because it is pointless to get people to come to a site that they cannot understand or use. The usability specialist is essential to your site's success.

Information Architect
As defined by Wurman, "The information architect is the individual who organizes the patterns inherent in data, making the complex clear. They create the structure or map of information which allows others to find their personal paths to knowledge." In web development they are the masters of information organization. How should information be organized so that it can, in fact, be found? This role may or may not be filled by the usability specialist. At the very least the information architect and the usability specialist work closely together, with the usability specialist either proving or disproving the information architect's theories.

Art Director, Production Artists, Audio/Visual Engineers and Copywriters
The mere existence of these titles in your project team should suggest that you are doing something different than standard IT development. In fact, web teams are often a mix from IT, advertising and marketing. If you do not have these people on the web development team then likely the programmers on the team have to fill the gap. And, although some programmers are certainly capable of filling these roles, most are not. Given that other people who can fill these roles are often paid significantly less than the programming staff, it is a questionable choice on many levels to fill these roles with programmers. Build a diverse team around the truly diverse roles required in web development. Do not treat the entire web staff as interchangeable parts because they aren't.

Media Coordinator
The media coordinator is on the list as yet another reminder of how web sites differ from conventional IT projects. This role, often filled by advertising, coordinates content on the web with other corporate marketing and branding activities. The web site should enhance all of the corporate advertising and branding initiatives, thus the site needs to coordinate release content with other media buying activities. The media coordinator may also be the prime facilitator of media buying on the web.

Producer
Talked about last here, but certainly not least in importance, the producer fulfills the same role as a project manager in conventional IT projects. We have changed the name to producer to capture the change in emphasis that accompanies developing a corporate web site. To many customers, the web site is the corporation's marketing, sales, support and service departments. To many customers the web site is the company. The producer is creating an interactive virtual experience more akin to a movie than a software program that directs and creates a powerful experience for each visitor. Of course, in the process they still have to manage all of the responsibilities of a project manager including managing scope creep, developing the delivery plan, acquiring the appropriate resources, budgeting, managing the teams, and managing the corporate expectations for the web project. Needless to say this is something you want your best people doing, since it is a gargantuan task.

In terms of team role definitions we will end our review with the producer. Although we could easily talk about the other roles, we have intentionally focused on those that are the most likely to be skipped, ignored or undervalued on a first web project. These roles must be filled in order to ensure peak performance for your teams and your projects. Next we will take a look at how your teams may be organized according to the roles we have just defined.

Teams
To manage the complexity of web development we often segment the staff into three of four distinct teams. These teams all report directly to the producer and consist of full-time dedicated staff, subject matter experts, executive sponsors and contract consultants. A typical team structure consists of:

• The Strategy Team
• The Interface Team
• The Application Development Team
• The Infrastructure Team

The Strategy Team consists of the strategic planner, producer, and media coordinator as well as supplementary subject matter experts and executive sponsors. The team is focused on maintaining the on-going implementation plan for the site. This group will work closely with corporate business leaders to synthesize business drivers, user feedback and industry best-practices into an evolving, and living plan of action for the site.

The Interface Team consists of the usability specialist, information architect, production artists, copywriters, translators and audio/video engineers. They are responsible for designing a site look, feel and theme that is easy to use, useful and effectively communicates the desired brand message.

The Application Development Team consists of the senior software architect, programmers, database administrator, QA team lead and testers. They will focus on capturing business and system requirements in a software model, and designing and implementing core business logic and database services. They will also develop the initial application framework for designing, testing, launching and maintaining new applications.

The Infrastructure Team consists of the security specialist, hardware/network architect and the site administrator. They are responsible for designing and implementing a robust and scalable platform for the web site, maintaining security, building appropriate support structures and processes, and analyzing and addressing the IT aspects of business integration requirements.

Overall it is easy to see why a seemingly small entry into the e-commerce space may still involve a larger investment of time and energy. Web development is serious business.

Serious Software Development
Once we have recognized that web development is serious software development we understand the need to create a methodology that encompasses development from simple web initiatives to complex end-to-end e-commerce applications. Next we will review a sample process based loosely on "The Unified Software Development Process" by Ivar Jacobson, Grady Booch and James Rumbaugh.

The Unified Process captures software development in four phases: Inception, Elaboration, Construction and Transition. During the inception phase the core idea is developed into a product vision. The elaboration phase establishes the architectural baseline. During the construction phase the architectural baseline grows to become a completed system as the design is refined into code. In the transition phase the goal is to ensure that the requirements have been met to the satisfaction of the stakeholders. Each phase is described next in more detail for a web project:

Inception Phase
In this phase the strategy team will review and confirm the business drivers, the vision and scope of the project. The team will complete the following deliverables in this phase, The Project Vision Document, The Primary Use Cases and a Site Content Outline.

The Project Vision Document was described earlier in this paper. The Primary Use Cases capture the overview of the business model. Each use case captures the step-by-step detail for a particular action that a user of the system may perform. The Site Content Outline describes the main functional areas of the site and its possible layout.

Elaboration Phase
In this phase the strategy team is joined by the other teams. The majority of the use cases are specified in detail and the network, hardware and software architecture is designed. The primary activities performed during this phase are requirements refinement, detailed use case modeling, site structural and thematic design, and prototyping. The areas of focus may be membership and personalization as well as site integration with other corporate systems. The teams will complete the following deliverables in this phase: Requirements Document, Infrastructure Architecture and Implementation Plan, Sample Composites, Site Design Style Guide, Site Prototype, the Production Guide and a Team-Accessible Pre-Production Environment.

The Requirements Document describes the system requirements primarily in the form of detailed use cases. It may also include a business domain glossary, various scenarios for each use case and use case diagrams.

The Infrastructure Architecture and Implementation Plan describes the detailed web site infrastructure strategy and architecture, including specifications for network, hardware, and software components. An operations plan will be developed to define the daily operations of the site and the appropriate collection of performance metrics.

The Sample Composites created by the Interface Team is a series of thematic designs for the main and sub pages including menus, navigation and design elements.

The Site Design Style Guide also created by the Interface Team outlines and establishes guidelines for the developers to use when building the site. It contains information about where content will be used and provides descriptive information about the content format including consistent ways to use words and acronyms for information published on the site.

The Site Prototype with limited functionality incorporates the preferred look and feel, navigation and content. The prototype may use canned data and is typically used in usability and design acceptance testing.

The Production Guide describes how the site is built. This is key to the people building the first site and to those maintaining it over time. This production guide describes how content is added to the site including the suggested editorial review process, as well as site specifics such as the directory structure and file naming conventions. We have encountered large web projects where 3000 site files are in one directory. This is not recommended since it makes the site difficult to understand, update, maintain and repair. At the very beginning of the project establish a guideline for the file locations and naming conventions. As more and more sites are entirely database driven, part of this problem is mitigated. For database driven sites describe the appropriate interface for content editing. The second thing the production guide describes is the handling of production art. When are GIF and JPEGs to be used? What setting should they be saved at? Where is the original art located and what tools are used to edit them? It is very frustrating to need to make a small change to a graphic and to not know where or how to perform that change. Don't hide that knowledge, document it and put it in the production guide. A third thing to be sure to include in the production guide is the documentation on any advanced tools used to create the site. If the site only contains a small amount of scripting language then document here what that is and how it works. If the site is a major engineering effort, written perhaps in Java and Oracle, then simply reference where the reader can find more information on these technologies.

Lastly during the Inception Phase the team creates The Team-Accessible Pre-Production Environment. Use the web to develop for the web. Build a simple web site that enables everyone to be able to receive accurate, up-to-date representation of the project status. Keep on this site all of the documents described as being created in this process. Also host the pre-production environment. This will enable any team member at any time to view the application under development.

Construction Phase
During the construction phase the site is built. The teams will deliver iterative releases of the site and development, pre-production and production environment infrastructures during this phase.

Iterative Releases of the site are produced continually. The released code will be placed in an environment where all team members can review the functionality, look, feel and performance of the system. This promotes active communication and feedback throughout the entire group. Everyone can be well-informed about the current status, style of web presentation, and working functionality.

The Development, Pre-Production and Production Environment Infrastructures are created by the Infrastructure Team to support for the web site platform. Tasks include the configuration of the web site farms at co-location facilities, network components, web server farm construction, security and intrusion detection implementations, setup of monitoring and logging applications, and readiness for startup operations of the web site.

Transition Phase
In the transition phase the goal is to ensure that the requirements have been met to the satisfaction of the stakeholders. The main activities are user testing, help desk setup, training, and documentation completion and site deployment. Any maintenance procedures not already established are created and documented. The teams monitor feedback from beta users to insure that the system really performs as the business and users require; specifically that unanticipated results are not occurring, failures are identified and rectified, and ambiguities and gaps are fixed in the presentation engine.

The teams will deliver the Production Site Release and System Documentation during the phase. At the completion of this phase the inception phase begins again. On e-Commerce web projects, development never ends.

Project Management
The more things change the more they stay the same. Even with all of the changes in web development many standard best practices for project management do not change. To this end, web projects should be sure to address issues in Configuration and Requirements Management.

Configuration Management
Throughout the project lifecycle, all artwork, copy, project documents and software should be stored in a softcopy repository under strict versioning, backup and access guidelines.

Requirements Management
It is essential to rigorously manage software and system requirements throughout a project's lifecycle. Poor requirements management leads to ineffective system and software design, excessive rework, higher defect ratios, lost knowledge base, delayed schedules, and guaranteed higher project costs.

Changes In Web Space
There are many significant changes when an IT organization undertakes a web development project. Let's review a few of the most significant changes and strategies for managing them. Major changes are: Moving Fast Creative Content, Marketing and Brand Management Moving Deployment Targets Evolving Content

Major Change #1 Moving Fast
Computers are doubling in speed every 18 months; the amount of fiber being laid is doubling every 9 months. Ten years ago you could count the number of internet web pages on your fingers, now there are so many that you couldn't count them in a life time. The world of technology is moving fast. Most IT organizations are not used to moving fast. It is time to learn how. Carve large projects into smaller ones that can be released monthly. If you haven't been doing it already, it is time to study and implement iterative and incremental project management techniques. These techniques are the only way to survive in internet time.

Major Change #2 Creative Content, Marketing, Brand Management
IT departments are generally not considered the bastions of creative energy in an organization. Most IT departments in the past have had little or nothing to do with marketing, sales and brand management. That was always the domain of the advertising, marketing, and sales departments. With the advent of the internet, IT is now finding itself at center stage in an entirely new part of the business. No longer isolated to the arena of back office support, IT is being asked to support front line business efforts. The only way to support these new demands is to expand the teams as described previously. Enough said, just do it.

Major Change #3 Moving Deployment Targets
IT departments are used to specifying the target platforms on which their programs will run. Many times they have even installed and configured all of the client hardware so they could ensure that their software would run just right. Those days of dictatorial control are over, and they are over with a vengeance. As much as everyone pretends otherwise, the internet standards, of which there are few, are not very standard at all. In web development the team must plan for multiple browsers, multiple versions of the same browser, and multiple platforms. Users may be connected at any number of different speeds, displayed at different resolutions and in different fonts. They may or may not support frames, display graphics, allow plug-ins and support style sheets. They may have redefined fundamental ways at which key components are displayed such as default fonts and hyperlinks. All in all it is a usability nightmare, and it doesn't look like it is getting any better any time soon. To begin to deal with this level of complexity requires a thorough interface guideline and a competent testing team with extensive equipment and patience. It may also require settling on a less sophisticated user interface than the team might initially conceive. This chaos on the deployment platforms is truly a new experience for most IT departments; an experience that requires a lot of planning, time and money.

Major Change #4 Evolving Content
Most internet sites are information intensive. One of the benefits of internet deployment is the ability to reach an extremely broad audience with very deep levels of fresh information. In order to draw users back to the site this content is typically changing and evolving. Applications that change content daily can be a new experience for most IT departments. The fact that it is so easy to publish a web page in HTML and continually update its content, managers underestimate how easy it may be to make rapid changes to a system's more complex web interface. It is usually not acceptable to take a site down to update web content, especially if you are selling products or services through your web site. Sales will inevitably be lost if the site is down for more than just a few minutes. Changes must be made without any interruption in service.

Words of Wisdom
At a recent Gartner Group conference on Internet & Electronic Commerce, one CEO who has spent over $100 million on e-Commerce development had plenty of advice for those in attendance. I thought I would forward just a bit of that advice:

• The ability to scale is king. The site must be able to handle more visitors than you expect to receive. Plan for at least two or three times your expected number of visitors and make sure the scaling can take place seamlessly while the site is live.
• Know your target audience and what you want to deliver. Do not try to be everything to everybody. Pick something specific you want to do and be really, really good at it.
• Make sure that your middle level management team is on board. Educate them and convert them or get them out of the way.
• Lastly; work with experienced adults. If you work with a company run by 24 year olds recognize that they are in their first jobs and are learning at your expense.

Conclusion
The world of web software development is a moving target. New hardware, tools, capabilities and technology are making continuous demands on the development team. In this paper we have provided a few highlights on how to develop and manage successful web projects. This paper contains the seeds of many great ideas, but you will have to work to make these seeds grow. I challenge you to begin. Investigate my claims and see for yourself if and how the world of web development differs from conventional IT projects.