Chapter 3
Process

In theory there is no difference between theory and practice. But in practice, there is.
—Yogi Berra

Planning a web site is a two-part process: first you gather your development team, analyze your needs and goals, and work through the development process outlined here to refine your plans. Next you build on the strategy in the project charter with implementation details—what you intend to do and why, what technology and content you’ll need, how long the process will take, what you will spend to do it, and how you will assess the results of your efforts. In this way, the project charter becomes both the blueprint for your process and the touchstone you’ll use to keep the project focused on the agreed-on priorities and deliverables.

Project Resources

The strategic importance and project budget for your web efforts will largely determine the size and skill depth of your development team. Even for a smaller project, however, you’ll need to cover the core team disciplines. In most small to medium projects one person may handle multiple tasks, or someone with specialized expertise (graphic design, for instance) may be hired for specific assignments. Many managers who are assigned the responsibility of creating a web site don’t have the luxury of picking specialist team members. Inventory the skills and aptitudes in the team you assemble, and consider careful outsourcing to supply any expertise your team lacks.

The core skill sets needed in a web development team are:

In larger web projects each role may be filled by one or several people, although in more specialized skill areas those contributors are not likely to be full-time team members for the duration of the project.

Assembling a web development team

We describe the responsibilities and activities for each domain below. Here we organize core team responsibilities by domain, establishing the domain lead role and secondary roles. We strongly recommend cross-disciplinary teams over a more phased approach, in which each domain completes its activities and hands over responsibility to another team to complete the next phase of development. With the traditional “throw it over the wall” approach, every stage of the development process is carried out independently. While this approach provides more control over the overall process and is easier to track from a project management perspective (see “Project Management,” below), it has many shortcomings. Communications suffer, and projects take more time as different domains work to resolve differences that arise from not working from a shared vision. Cross-disciplinary teams are more complex to manage, but the benefits outweigh the limitations. We all grow when exposed to views and knowledge that differ from our own, and the synergy powered by diverse viewpoints, the interdependencies that arise from collaboration, and the opportunities to build capacity for individuals and as a team more than compensate for the project management overhead.

Project sponsor

The project sponsor is the person who has authority to initiate the project and approve the final outcome. In most instances the sponsor is the client or customer for the web site development work, but in smaller in-house department projects the sponsoring manager and the project lead may be the same person. The sponsor provides the overall strategic vision and purpose for the site development project, approves the contract or work plan, and provides the resources to support the work of the site development team.

The sponsor is the client the team works to please, but sponsors have important work to perform as part of the overall site development team. Sponsors act as liaisons to the rest of the sponsoring organization, coordinating with the larger goals of the sponsoring organization and communicating project progress to leadership and the steering committee. They also provide critical domain expertise to the project and contribute to the site content. As such, it is crucial that sponsors and other stakeholders understand their responsibilities to the web team: late delivery of web site content is the most common cause of blown schedules in web development projects. Sponsors also are typically responsible for third-party or external content contracts, other media licensing negotiations, and coordination with other marketing, information technology, and communications efforts at the sponsoring organization or company. The sponsor is accountable to organizational leadership for budget, schedule, and project success.

Project lead

The project lead is the person responsible for overall project success. Activities related to leading and managing projects differ in that leading focuses on project success, while managing relates to process-related aspects of the project. Teams that use “scrum” or other “agile” frameworks divide these responsibilities between the roles of product owner and scrum master (see “Agile project management,” below). On some teams, the same person has both responsibilities.

From a strategic perspective, the project lead steers project activities toward serving the goals and objectives outlined in the project charter, keeping the web team on course. The project lead makes the tough decisions related to direction and prioritization, and manages the communication channel between the team and the project sponsor. On a tactical level, the project lead coordinates and communicates the day-to-day implementation of the web site project, acting within the constraints of the project charter, project budget, development schedule, and quality objectives laid out in the strategy and planning stages. The project lead is the team member ultimately responsible for keeping the overall team activities focused on the site strategic objectives and agreed-upon deliverables, and he or she continually monitors the scope of the project activities to ensure that the team stays “on time and on budget.” The project lead acts as the primary contact between the web team and the sponsor and manages the overall communication among creative, technical, and production elements of the web team. In larger web projects the project lead is not normally part of the hands-on production team, but in smaller in-house projects the sponsor, user experience lead, or technical lead may also act as the project lead for the site team. Project leads create and maintain the project planning and strategy documents, budget spreadsheets, project schedules, kanban boards and Gantt charts (see “Project Management,” below), meeting notes, billing records, and other project documentation that details the team’s activities (fig. 3.1).

User experience lead

The user experience lead is the primary user advocate on the web team, responsible for providing a quality experience to people who use the web site. User research and usability activities all fall within the domain of user experience, or ux. Information architecture, because it influences how users experience a site, is also typically part of ux. While several individuals may make up the UX team, in smaller teams the same individual often performs all user experience activities. User experience activities, particularly those related to user research and usability, are critical throughout the product development life cycle.

User research is the cornerstone of all successful product development, using observation and inquiry to understand user needs and preferences. In the initial stages of design, the user researcher is responsible for running interviews, field studies, and usability studies and for producing personas and scenarios to inform project requirements. Once designs are conceptualized in the form of diagrams, wireframes, and prototypes, the user researcher tests the designs with users and gathers feedback for the site designers and developers. In the final stages of a project, the user researcher evaluates the effectiveness of designs through additional field studies and usability testing, and ensures that universal usability goals are met. The user researcher is also responsible for evaluating the success of the project (Does the site accomplish the goals? Are users successful and satisfied with the design? Is the site usable and enjoyable for all users, including people with disabilities?) and for measuring project outcomes that correlate to good UX (Are more users visiting the site? Is the site producing more revenue? Are users responding to calls to action?).

Information architecture is the process of organizing and categorizing web site structure and content. The information architect is most active early in the design and planning phases of the project, developing content categorization schemes, consistent site terminology, content structure across the site, taxonomies to support categories and tags, and site architecture diagrams that explain the overall site planning to both the sponsor and the team members. Information architects often have a background in library science, using controlled vocabularies, carefully designed content and navigation nomenclature, and search techniques to help users find relevant content. Information architects work closely with the site designers to craft page wireframes, the diagrammatic page grids that show how various areas of the page will be used to support site identity, navigation, and page content. Page wireframes form the crucial connection between the overall site architecture and what the user sees on each page of the site, determining how easily a user can find content and features, and shaping the user’s overall experience. These visual representations are crucial to communicating site structure and user experience, particularly for the back-end technical developers who support the interactive elements of the site, and for use in testing concepts with users.

The information architecture strategy for a site also includes the content structure as implemented in content management systems (CMS) like Drupal, WordPress, or commercial CMS products. The content strategist and the information architect will look at CMS content block and data entry architecture, modules for implementing content and navigation menu structure, and site themes and page templates. With the increasing importance of mobile content views, user experience activities must include creating a strategy for delivering content to the smaller viewports of smartphones, tablets, and even smart watches. Mobile computing has become so important that many organizations have adopted a “mobile-first” approach to creating sites, in which the foundation planning is done for the mobile views and content, and tablet and desktop views are handled as later iterations of the core mobile design.

Design lead

The design lead is responsible for the overall look and feel for the web site, establishing the site typography, visual interface design, color palette standards, page layout details, and the particulars of how the graphics, photography, other illustrations, and audiovisual media elements of the site come together to form an integrated whole. Many graphic design professionals specialize in designing for interactive media and are well versed in user interface design, web navigation, and site architecture. In smaller projects an experienced design lead sometimes assumes at least partial responsibility for the information architecture and user experience roles in addition to directing the visual design of a site. In larger organizations the design lead is usually the person responsible for assuring that the new web design work is consistent with any established corporate identity and user interface standards.

In the site development and planning stages the design lead creates or supervises the creation of increasingly complex design sketches to illustrate the evolving design proposals to the project sponsor and web team. As designs are approved, the design lead supervises the conversion of design sketches into detailed specifications of graphics and typography that engineers will need to create themes and templates.

Technology lead

The technology lead is the person responsible for the soundness and stability of the technology architecture. He or she must have a broad grasp of web publishing environments, including content management systems, development languages and frameworks, web database options, and network technology. The technology lead acts as the bridge, translator, and plain-English communicator between the technologists and the creative and project management elements of the team.

The technology lead creates, as part of the site planning process, the general blueprints for the collection of technologies that will support the chosen technology framework, including content management systems, database integration and support, integration with social media platforms like Facebook and Twitter, custom programming, CMS theme and template development, and integration with other applications or databases that supply content or interactive features to the web site. The technology lead provides the primary data processing architecture for the project, determining the technical specifications for the overall web server and database server hardware architecture or web hosting services, shaping development frameworks, assessing the developing strategy and goals, and matching those needs to appropriate technology solutions. In larger projects the web technology lead typically manages teams of programmers, network and server engineers, database administrators, software quality assurance testers, and other information technology professionals who support the production and design teams.

Production lead

The production lead is responsible for the cohesiveness of the site and for the quality of the site over time. Site producers are usually experienced generalists. “Producer” is a title borrowed from audiovisual media, where a producer combines a project managerial role with extensive experience in integrating various creative elements (writing, hands-on web development, audiovisual or graphic production). The activities of the production lead change over the project life cycle.

Early in the design stage the production lead focuses on content development and production. Once the site has been planned and the design and information architecture plans have been completed, the production lead manages the work of building the site’s pages, typically in a CMS, assembling the work of the information architects and site graphic designers into finished pages.

A key role within the production team is the site editor, who has overall responsibility for the written content and editorial quality of the finished site. The editor establishes the editorial tone for the web site, determines editorial style guidelines, and works with clients and subject matter experts (SMEs) to collect, organize, and deliver finished text to the production team. In smaller teams the editor creates site copy, interviews smes to create content, and may be responsible for creating news and feature material for the site. Experienced editors also play an increasingly important role in the technical and production aspects of site content, ensuring that written content from the sponsoring organization is provided on time, in the specified editorial and technical markup format, and with sufficient quality to meet site goals. This technical aspect of content structure and formatting is particularly important in content management systems.

In addition to ensuring editorial quality, a site editor must also make certain that the content of the site reflects the policies of the enterprise, is consistent with local appropriate use policies, and does not contain material that violates copyright laws. Many people who post on their own sites pictures, cartoons, audiovisual files, or written material copied from other sites do not understand copyright and the legal risks in using copyrighted materials inappropriately. A site editor is often an institution’s first line of defense against an expensive lawsuit over the misuse of protected material.

Because most search engine optimization (SEO) efforts are based on careful, consistent use of keyword language and heading markup, the web editor is also the team member most likely to lead the day-to-day efforts to make the site as search-friendly as possible. Keeping the site optimized for both local search engine visibility (using local search tools built into the CMS) and keeping public sites maximally visible to general Internet search engines like Google and Bing are crucial strategic components of making the new content accessible and findable for your audience.

Unlike the other site development roles described above, the site editor’s role is a long-term job, bridging the transition from a site development project into an ongoing web publication process that maintains the web site after launch and keeps the content fresh and relevant to your audience. If the project manager is the focal point of the early stages of creating your site, then the site editor should gradually assume the leadership role in the stages just before, during, and after the site launch. This transition of responsibilities ensures that the site won’t become an orphan after the project team leaves the launch party and moves on to new assignments.

Web teams

The well-known information architect and web user interface expert Jesse James Garrett created “The Nine Pillars of Successful Web Teams,” a concise graphic description of the core roles in site development (wsg4.link/jjg-9pillars). The disciplines and site development stages proceed from left to right in a logical progression from strategic planning to implementation and visual design.

We’ve modified Garrett’s pillars and added a more explicit time dimension and emphasis on the early and continuing role of project management throughout the process of web site development. We also emphasize the importance of getting broad participation and input in the user research and strategic planning stages of your project. The more you hear from stakeholders and potential users, the better your planning and design will be. Early in the process your designs and plans ought to change almost daily, as the iterative tasks of design, user research, and stakeholder input help you refine and improve your ideas. Design iteration is essential in developing the ordered complexity of a large web site.

Later in the process, however, the team should pare down to those core specialists who are building the site. Otherwise, continuing major design changes can lead to production churning, wasted effort, and blown schedules. Get broad input early on, make the best site design and project plan possible, and then focus the team on implementing the plan.

Project Planning

Creating a project implementation plan

The project charter discussed in Chapter 1, Strategy, is the development team’s concise statement of core goals, values, and intent in order to provide the ultimate policy direction for everything that comes next. Designing a substantial web site is costly and time-consuming. When you’re up to your neck in the daily challenges of building the site, it can be easy to forget why you are doing what you are doing and to lose sight of your original priorities, not knowing whether the decisions you are making firmly support the overall objectives. A well-written project charter is a powerful daily tool for judging the effectiveness of a development effort. It becomes a compass to keep the team firmly pointed at the goals established when you started the journey. A good project charter becomes a daily reference point for settling disputes, avoiding “scope creep,” judging the potential utility of new ideas as they arise, measuring progress, and keeping the development team focused on the end result.

The next step is to create a project implementation plan, defining the content scope, budget, schedule, and technical aspects of the web site. The best project plans are short and to the point, often outlines or bulleted lists of the major design or technical features planned.

A good project plan contains the following sections, with specifications for implementation details for the project.

Project overview

The project plan should begin with a concise narrative description of the content, features, and services that the new site will provide. This section answers the “why” of your project. It should be a short description of the sales, marketing, communications, or other goals that will be accomplished by creating the new web site, along with a rationale and general metrics for determining the success and return on investment (ROI) for the proposed web site. Think of it as a written version of your “elevator speech” to senior managers who must approve the project: your most concise, to-the-point rendition of your top three reasons why the new or redesigned web site should exist. This section should end with a short strategic statement that places the site project within the context of the sponsoring organization’s missions and existing web presence.

Success metrics

Most web site projects have measurable goals: to increase traffic, boost sales, improve client relations, reduce support emails, and so on. Many of these measures rely on preexisting data to enable before-and-after comparisons of the site’s success. Review the “success indicators” in your project charter to identify which to include in your project plan as true success metrics. It is important to establish success metrics before you begin because you may need to be proactive about collecting “before” data before launching the site.

Project scope

Here you detail the “what” of the proposed site. In as much detail as possible for each stage of the project, describe the web site to be created, drawing on the strategies and tactics described in the project charter. Early in the planning process this statement will have to be general and should concentrate on the core “must-have” features, content, and purposes of the site. Avoid stipulating the use of specific technologies (“We’re using JQuery for everything”), a decision that really should be determined after the web site team has made a thorough assessment. Ironically, it is often useful (and sometimes easier) to make a careful statement of what your project is not. This form of “is/is not” scope statement is particularly useful where your new site may have aspects that are similar to existing organizational sites or where your project sponsors may not immediately grasp your intent in creating the web site.

The project scope should be flexible in the planning stages of the project but should become a fixed specification before hard budget numbers or schedule deadlines are assigned to the project. See the section on “Site Definition and Planning,” below, for details on specifying and refining project scope.

Roles and responsibilities

In the Strategy chapter we covered the importance of establishing project governance early on in the project. In “Assembling a Web Development Team,” above, we describe specific roles and responsibilities. The project plan should formalize roles and responsibilities by naming the major sponsors; the project, design, technical, and editorial team members; and any other strategic stakeholders within the enterprise. There is no single correct way to structure a web site development effort, but everyone involved should be clear at the start about who is responsible for each aspect of the site development. This is an opportunity to make the point that the project requires an ongoing commitment, beyond the site launch. It is also another opportunity to clarify for sponsors and stakeholders that they have responsibilities and deadlines too, and that the team will be dependent on everyone’s contributions. You should also outline a proposed project governance and approvals process, so that everyone involved is clear about how each major project milestone will be communicated and formally approved by the sponsors or major stakeholders.

Project budget and timeline

Your project budget should account for all of the expense categories and activities outlined in “Project Development Life Cycle,” below. Make your best calculations on your people, hardware, software, content, and technology development expenses, and then add a hefty contingency budget. Web projects always grow, often by as much as 10 percent or more, even in tightly managed projects. It happens to everyone, and it will happen to you, too. Plan for it rationally, or deal with the pain later.

Here we emphasize often-overlooked considerations that must be accounted for when budgeting time and resources.

Project risk assessment

Every good project plan should outline the risks of failure in major components of the project. Although your whole project is unlikely to melt down, take a hard look at the various make-or-break components of the plan and think about “Plan B” alternatives. For example, what happens if your content development and site design work out well but your programmers don’t meet expectations on interactive features? Will the site be viable? What happens to the project team if your designers and technologists do everything right but the client fails to produce the site content on time? What financial, schedule, quality assurance, or other contingencies could be written into the contract and project charter to mitigate those risks? Your project plan’s risk-assessment section should detail plans for minimizing or mitigating risks.

Common risk points in web projects include:

Satisficing in design

The economist Herbert Simon coined the term “to satisfice” by combining “satisfy” and “suffice.” Satisficing is consciously choosing not to try to find one perfect design solution but instead aiming at a balanced approach that roughly satisfies (“satisfices”) all major design requirements. Complex or lengthy design iteration is expensive and necessarily involves the combinations of many unknown factors with no clear promise of a single optimum design solution. Although satisficing may sound like settling for mediocrity, satisfice strategies have produced some of the most successful designs of the past century.

The Douglas DC-3 was not the best competitor in any single performance class: each of its competitors could better it in some category of speed, engine power, range, or carrying capacity. Yet the DC-3 was such a successful satisfice of all design factors that today, eighty-three years after it was designed, more than a thousand DC-3 airframes are in daily use.

Don’t allow contention over single points of your site design to paralyze the design process or to plunge your team into endless rounds of “Would it be better if… ?” All projects are in some measure satisfices, because there’s no practical way to know whether a single best solution to every problem exists for every user. Don’t let the perfect become the enemy of the very good.

Avoiding scope creep

Scope creep is the most prevalent cause of web project failures. In badly planned projects, scope creep is the gradual but inexorable process by which previously unplanned features are added, content and features are padded to mollify each stakeholder group, major changes in content or site structure are made, and more content or interactive functionality than you originally agreed to create is stuffed in. No single overcommitment is fatal, but the slow, steady accumulation of additions and changes is often enough to blow budgets, ruin schedules, and bury an elegant original plan under megabytes of muddle.

Changes and refinements can be a good thing, as long as everyone is realistic about the impact of potential changes on the budget and schedule of a project. Any substantial change to the planned content, design, or technical aspects of a site must be tightly coupled with a revision of the budget and schedule of the project. People are often reluctant to discuss budgets or deadlines frankly and will often agree to substantial changes or additions to a development plan rather than face an awkward conversation with a client or fellow team member. But this acquiescence merely postpones the inevitable damage of not dealing with scope changes rationally.

The firm integration of schedule, budget, and scope is the only way to keep a web project from becoming unhinged from the real constraints of time, money, and the ultimate quality of the result. A little bravery and honesty up front can save you much grief later. Make the plan carefully, and then stick to it.

Project Management

All project management methods are in some measure balancing acts to accommodate the three core factors that govern all projects: scope, costs, and schedule. In web projects you might understand “scope” as a combination of the size, depth, and total functionality of the interactive features and content of web sites. Each of the three factors is intimately linked to the other two, and emphasizing one or two factors always affects the third. For example, a project might balance a small initial budget by allowing a small team to work over a longer period of time, or a very high-priority project might tolerate the high cost of a large team to finish the project more quickly. Inevitably, you make hard choices. The oldest joke in project management is: “How do you want your project? Good, fast, or cheap? Pick any two.”

A full discussion of the discipline of project management is beyond the scope of this book, and many U.S. web professionals who seek careers in management now acquire formal certification as project management professionals (PMPs) from the Project Management Institute. In Britain and Europe the most popular project management certification is PRINCE2 (Projects in Controlled Environments). Either PRINCE2 or PMP professional-level certification usually takes several years to complete, and is essentially the equivalent of a master’s degree in project management techniques. However, it is not necessary to study and practice for years to understand the basics of managing the development of web sites and online content projects.

Project management “fails”


In their 2011 survey of U.S. IT projects, the Standish Group reported a failure rate of 29 percent, with an additional 57 percent of projects reported as “challenged” with significant problems; in 2013 the group reported a 38 percent failure rate of large IT projects within six- to eighteen-month time frames.

The 2013 survey reported a lower outright project failure rate (18 percent), largely attributed to the increasing use of agile project management techniques.

Choosing a project management method

All project management techniques are attempts to manage risk. The two most popular current approaches to software and web project management—traditional “waterfall” handling of project stages versus the iterations or “sprints” of the newer “agile” development techniques—are both meant to supply reliable information on the current status of a project, an overall sense of priorities, tracking of who is supposed to be doing what at each stage, and information on how close the project is to meeting its three-part goals of agreed functionality, budget, and schedule.

Waterfall and agile techniques are fundamentally different in the way they generate and prioritize tasks to be completed and features to be delivered. Both techniques require careful research on user needs. Waterfall techniques rely on team estimates of the time and money that will be needed to produce what is ultimately a (theoretically) fixed set of deliverables. In the agile framework the team and product owner don’t try to guess exactly which features the final product will contain. Instead, they emphasize user and product owner priorities: what are the most important user needs to work on at this time?

In this section we summarize the strengths and weaknesses of these two approaches to project management, and present a third hybrid option that combines the best of both.

Waterfall project management

In 1970 computer scientist Winston Royce wrote an influential article on software project management that laid out the process as a series of steps, each of which should be substantially complete before the next step is begun. That’s the core idea in waterfall projects—you complete one phase before you move on to the next phase, and the project work “flows” down a series of steps. Royce never used the term “waterfall” to describe the sequential completion of project stages, but the waterfall metaphor quickly caught on in software development.

Waterfall project management has since become the most widely used process for developing complex software and many other kinds of projects, as it offers a logical, easily understood, and predictable method that fits well within more broadly used practices in project and financial management. Although everyone (including Royce) acknowledges the potential drawbacks of a rigid waterfall process, it offers a powerfully intuitive step-by-step road map for handling very complex projects. Its simple but firm logic underlies the continuing popularity of the waterfall method.

Waterfall project management can be well suited to projects such as content-intensive web projects, in which extensive research and user requirements analysis must be done well before any active site building or coding of functionality. If you look at the details of how most web design firms handle their proposals for creating or modifying large sites, you’ll see processes and project phases far more like traditional waterfall project management than the more “agile” techniques described below. Partly this is the reality of running service businesses that work with large enterprises where most of their internal projects and vendor contracting people expect waterfall approaches. But design and technology firms also use waterfall work sequences because many projects require complex or extensive requirements, design, and content creation phases before substantial programming or web site development can logically proceed. These days most waterfall projects are far more flexible in design, allowing for multiple concurrent (instead of sequential) project threads, and iterative design-build-analyze-improve cycles borrowed from the more recent agile techniques.

Although waterfall project management was created by programmers to deal with complex software projects, it is ironic that software development—and web site development—might be some of the least suitable uses for strict waterfall methods, primarily because creating software and complex content is such a plastic process that the details almost always wander from the plans laid out in the requirements and design phases. Nothing is immune to change, and there’s never been a waterfall project that didn’t evolve over time. Thus requirements documents created early in a project gradually (sometimes rapidly) become obsolete and irrelevant. There will always be problems that were overlooked, processes that were poorly documented, designs that were poorly conceived, and this becomes obvious in later phases of projects, when the problems are better understood. And every complex project is also a learning process, with new ideas emerging almost daily to influence the software design. The business and technical environment around a long-term software project is also a powerful influence on project success, as generally used hardware, operating systems, other applications, and leadership, sponsor, and user business objectives are constantly changing, making the original requirements and design documents potentially obsolete almost as soon as they are written and approved.

Classic waterfall project management techniques have also suffered from “analysis paralysis,” in which excessively long and detailed documentation and requirements phases result in mountains of paperwork, elaborate visual design renderings, and hyperdetailed requirements and process charts that quickly become a smothering straitjacket once the building phase of the project begins. Or would, if anyone on the project actually read the documentation—which they often don’t. Businesses don’t create complex design documents because they are foolish. The extensive documentation requirements often seen in classic waterfall management reflect an attempt to do two important things: First, to reduce project risk through a thorough and documented research and requirements phase; and second, to communicate to large project teams with many managers and stakeholders. Unfortunately, a giant pile of paperwork rarely accomplishes either goal.

From the site developer’s perspective strict requirements and design phases are ways to deal with the bad side of changing ideas about what your project should accomplish: the dreaded “scope creep” or “feature bloat,” in which an ever-expanding list of new requirements is added to the project deliverables, usually without matching changes to the budget and schedule. Even if the project has the time and money to accommodate many added tasks, many projects fail because all the added “features” result in complex and unnecessary code that is difficult to maintain and does not solve real user problems. Research has shown that a staggering two-thirds of software “features” are never or rarely used.

Agile project management

The tension between two factors that emerge in every project—the fluidity of software development realities versus the rigidity of a preplanned set of design requirements—gradually forced the development of more flexible, iterative project management approaches that acknowledge that while logical planning steps are necessary, a robust process must be flexible enough to accommodate changing requirements.

In 2001 a group of software developers met at the Snowbird resort in Utah to formally develop and promote a flexible—“agile”—method to develop complex software projects. The resulting Agile Manifesto has become the basis for the major alternative to traditional waterfall project management that addresses two fundamental challenges: creating a flexible process that acknowledges and welcomes changing requirements, but that also emphasizes a strict hierarchy of functional priorities to contain the “scope creep” of less important software “features.”

Agile was born in reaction to the perceived rigidity of waterfall methods, which if poorly executed too often resulted in inflexible goals, a wandering set of daily and weekly priorities, excessive documentation requirements, and a shocking rate of failure in major information technology projects. The Agile Manifesto is a philosophical statement, not a working plan for the day-to-day development of software or web sites. It reads as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

That is, while there is value in the items on the right, we value the items on the left more. (agilemanifesto.org)

Agile project management techniques emphasize:

The rapid timelines and modest scales of agile projects are deliberately planned. Dividing ambitious web or software plans into smaller chunks with relatively short schedules is an attempt to avoid the high failure rate associated with other project planning methodologies.

Several project management frameworks have emerged in the past decade to implement the agile philosophy in projects, the most popular of which is called “scrum.” The term “scrum” is from the sport of rugby, in which a team moves forward incrementally in a series of short individual plays, or “scrums.” Scrum project frameworks are built around relatively small teams—typically five to nine individuals who work in close physical proximity and tight collaboration on software or online content projects. Good scrum teams focus on “inspect and adapt” cycles that work toward continuous improvement of both the product and the development process. During short daily “standup” meetings, team members report what they have accomplished over the past day, and what they will be doing that day.

Team structures are simple and allow for only three project roles:

The scrum framework uses some unique terminology to describe the various elements of scrum processes. With the recent popularity of scrum and agile, these terms are leaking out into the general world of software development and web design, so it’s good to have a general understanding of scrum terminology:

The fundamental cyclical rhythm of scrum projects is based on the sprint, a fixed period of time over which a subset of the overall project backlog is addressed by team members. There is no fixed duration in the definition of a sprint. Most scrum projects work with sprints of one to four weeks, with sprints of one or two weeks being most common. Once a sprint has begun, the duration is fixed, and sprints are never extended beyond the planned deadline.

Smaller projects and ongoing maintenance and editorial activities can often be run entirely from a kanban board, augmented with frequent team meetings or short morning standup meetings. The kanban system is simple, highly visible, and often ideal for teams that work in a common area. Teams that are not in the same location can use project software like Jira or Basecamp to create “virtual” kanban boards online.

All project management frameworks (waterfall or agile/scrum) are dependent on how well the component processes are understood and executed. With its emphasis on flexibility, scrum can lead to projects that bog down if the team and leadership are not accurate in their estimates for tasks, and are not ruthless enough in paring down potential user stories and tasks to only the most important elements, which in turn can practically fit within a planned sprint. With inaccurate estimates and too much flexibility in user story and task changes, scrum-based projects may be just as vulnerable to budget and schedule problems as waterfall-driven projects. However, research has repeatedly shown that scrum techniques are well suited to software and web projects, and have a much higher overall success rate than projects managed with traditional waterfall techniques.

Scrum’s emphasis on relatively small teams and projects of short duration may be less suitable for managing large, long-duration projects with correspondingly large teams. The intense team communications techniques of small short daily and weekly meetings do not scale easily to much larger teams (twenty or more people), although it is often possible to adapt scrum processes to some components of a larger project, or to subdivide large projects into smaller sequences managed through the scrum framework.

Agile projects can suffer from a lack of cohesion. Every user story is a tree, every task becomes just another leaf, and the team can lose sight of how the forest is shaping up. The emphasis on fast delivery of working software developed in rapid bursts can also lead to a “ready-fire-aim” syndrome, in which holistic elements like user and business process research, user interface consistency, and site content and messaging strategies can get short shrift in the beginning sprints of an agile project. It is crucial for both content editors and designers to be on the development team and in every meeting to assure content and messaging continuity. User research, interface development and wireframes, and core visual design approaches are the foundational architecture of successful sites, and don’t always lend themselves to short sprints, although the design and usability communities are quickly changing to accommodate the accelerated timelines of agile development.

The emphasis on building functional code and pages as soon as possible can lead to a bias toward lightweight, easily solved problems at the expense of bigger “wicked problems” with lots of ambiguous or poorly understood details and functional requirements. There’s always the temptation to do the small, easy stuff simply because it fits well within the sprint framework, not because it’s the most important thing to do at the moment. Agile teams may suffer from the “horizon effect” (also known as “kicking the can down the road”), in which difficult issues are continually moved into later sprints. You haven’t solved a problem by pushing it back to sprint.

Hybrid waterfall/agile project management

Many organizations employ a hybrid of waterfall and agile project management, often using the early requirements and design planning aspects of waterfall techniques, then using scrum techniques to manage the building and quality control of the software or web site. There is one lesson from agile that is broadly accepted across all project management techniques: that software and web development projects must allow for flexibility and an iterative approach to continual improvements in the development process, and that subdividing massive projects into more manageable chunks yields much higher rates of success, especially when the smaller projects are managed with agile techniques. Hybrid systems also allow more concurrent project development threads, where content research and strategy, functional requirements, and technology planning occur simultaneously in early project phases, as shown in the Gantt charts in this chapter.

Many scrum projects institute a “sprint zero” period during which foundational project process, business, and research issues are addressed before the team moves into active code writing and site construction. Sprint zero periods are sometimes criticized as “waterfalls in disguise,” but the strengths of the waterfall methods of early requirements gathering, user research, and the development of basic interface and wireframe approaches can be successfully married to the scrum process in the later building phases of a project. The key to a successful hybrid approach is to avoid lengthy requirements and design periods, and the excessive documentation deliverables that often plague the early phases of waterfall projects.

Lean UX

Lean user experience is a way of integrating user experience design in a meaningful and effective way into the product development life cycle. It focuses activities on designing what people really want and value, and encourages big thinking and creativity in decision making and problem solving. A lean UX approach works well with agile project management, with its emphasis on flexibility and collaboration, through methods like design studios to develop “light” prototypes.

The Lean UX Manifesto is as follows:

We are developing a way to create digital experiences that are valued by our end users. Through this work, we hold in high regard the following:

Project Development Life Cycle

Every significant web project poses unique challenges, but the overall process of developing a complex web site generally follows seven major stages that you should think through before crafting your final project planning and proposal documents:

Most development projects have far-reaching budgetary, personnel, and public relations consequences for an organization, both during the development of the site and long after its deployment. Too many web sites begin life as ad hoc efforts, created by small interest groups working in isolation from their peers elsewhere in the organization and without fully considering the site’s goals within the context of the organization’s overall mission. The result of poorly planned, hasty development efforts often is an “orphan site,” starved of resources and attention.

As you consider the development process outlined below, note that the construction of the pages that make up the web site is one of the last things that takes place in a well-designed project. Consider each step in the process and its impact on your project planning. Think before you act, and make sure you have the organizational backing, budget, and personnel resources you’ll need to make the project a success.

Site definition and planning

This initial stage is where you define your goals and objectives for the web site and begin to collect and analyze the information you’ll need to justify the budget and resources required. This is also the time to define the scope of the site content, the interactive functionality and technology support required, and the depth and breadth of information resources that you will need to fill out the site and meet your users’ expectations. If you are contracting out the production of the web site, you will also need to interview and select a site design firm. Ideally, your site designers should be involved as soon as possible in the planning discussions.

Content development

Once you have an idea of your web site’s mission and general structure, you can begin to assess the content you will need to realize your plans. Building an inventory or database of existing and needed content will force you to take a hard look at your existing content resources and to make a detailed outline of your needs. Once you know where you are short on content, you can concentrate on those deficits and avoid wasting time on areas with existing resources that are ready to use. A clear grasp of your needs will also help you develop a realistic schedule and budget.

Content inventory

A good starting point for content development is to inventory existing content and identify new content development needs. Content inventory activities work well when structured, using a spreadsheet containing long listings of every page in the site, along with such essential characteristics as the page title, URL, people responsible for the content, and so on (see Chapter 4, Information Architecture, for details on creating a content inventory).

Content production

Content development is the hardest, most time-consuming, and most consistently underestimated part of any web site development project. In many instances your team will be looking to the sponsor to provide content or subject matter experts (SMEs). Be sure your sponsor or client understands the responsibilities and takes the content delivery deadlines seriously. Starting early with a firm content production plan will help ensure that you won’t be caught later with a well-structured but empty web site—or worse, a site full of “lorem ipsum” dummy text.

Do not make the mistake of holding off on content production activities until the site is fully specified and constructed. Begin writing and revising content immediately, and integrate content into the site as soon as it’s available. Use real content in designs and prototypes, in the user interface and for content pages. Push hard on the content production work, and don’t let up until the items in your content inventory are done.

Information architecture

At this stage you need to detail the content and organization of the web site. The team should inventory all existing content, describe what new content is required, and define the organizational structure of the site. Once a content architecture has been sketched out, you should build small prototypes of parts of the site to test what it feels like to move around within the design. Site prototypes are useful for two reasons. First, they are the best way to test site navigation and develop the user interface. The prototypes should incorporate enough pages to assess accurately what it’s like to move from menus to content pages. These prototypes can be used to test the information architecture with users. Second, creating a prototype allows the graphic designers to develop relations between how the site looks and how the navigation interface supports the information design. The key to good prototyping is flexibility early on: the site prototypes should not be so complex or elaborate that the team becomes too invested in one design at the expense of exploring better alternatives.

Typical results or contract deliverables at the end of this stage include:

Site design

At this stage the project acquires its look and feel, as the page grid, page design, and overall graphic design standards are created and approved. Now the illustrations, photography, and other graphic or audiovisual content for the site need to be commissioned and created. Research, writing, organizing, assembling, and editing the site’s text content is also performed at this stage. Any programming, database design and data entry, and search engine design should be well under way by now. The goal is to produce all the content components and functional programming and have them ready for the final production stage: the construction of the actual web site pages.

Typical products or deliverables at the end of this stage include:

Site construction

Only at this mature stage of the project are the bulk of the site’s web pages constructed and filled with content. By waiting until you have a detailed site architecture, mature content components, fully tested wireframes and prototypes, and a polished page design specification, you will minimize the content churning, redundant development efforts, and wasted energy that inevitably result from rushing to create pages too soon. Of course, you will always learn new things about your overall design as the prototype matures into the fully functional web site. Be prepared to refine your designs as you and your users navigate through the growing web site and discover both weak spots and opportunities to improve navigation or content.

Once the site has been constructed, with all pages completed and all database and programming components linked, it is ready for user testing. Testing should be done primarily by people outside your site development team who are willing to supply informed criticism and report programming bugs, note typographical errors, and critique the overall design and effectiveness of the site. Fresh users will inevitably notice things that you and your development team have overlooked. Only after the site has been thoroughly tested and refined should you begin to publicize the URL of the site to a larger audience.

Typical products or deliverables at the end of this stage should include:

Tracking, evaluation, and maintenance

Your web server software can record an abundance of information about visitors to your site. Even the simplest site logs track how many people (unique visitors) saw your site over a given time, how many pages were requested for viewing, and many other variables. By analyzing the server logs for your web site, you can develop quantitative data on the success of your site. The logs will tell you which pages were the most popular and what brands and versions of web browser people used to view your site. Server logs can also give you information on the geographic location of your site users. Detailed logs provide the key to quantifying the success of a web site. Your webmaster should archive all site logs for long-term analysis and should be prepared to adjust the information categories being logged as your needs and interests change.

Google Analytics (GA) is the most popular and widely used web analytics software, and not just because it is free. Google Analytics has evolved significantly from a fairly basic “client side” tool—analytics events are triggered when a reader’s browser opens a page with an embedded GA tracking script—into a complex web tracking and reporting suite. Applying GA tracking scripts to page code does not require deep HTML skills, and many content management systems offer built-in access to ga, so all you have to do is supply your GA account information to begin tracking your site. However, you may also want to augment the reporting you get from GA with “server-side” web analytics tools that track requests directly from your web server. If your site is hosted by your company’s it department, or by a commercial web hosting service, you may already have access to server-side analytics reports. Server-side and client-side analytics supply complementary streams of information that produce a more complete picture of how your site is used, and how server performance might affect the way users interact with your site.

Maintaining the site

Don’t abandon your site once the production “goes live” and the launch parties are over. The aesthetic and functional aspects of a large web site need constant attention and grooming, particularly if a group of individuals shares responsibility for updating content. Your site editor will need to be responsible for coordinating and vetting the new content stream, maintaining the graphic and editorial standards, and ensuring that the programming and linkages of all pages remain intact and functional. Links on the web are perishable, and you’ll need to check periodically that links to pages outside your immediate site are still working. Don’t let your site go stale by starving it of resources just as you begin to develop an audience—if you disappoint users by not following through, it will be doubly difficult to attract your audience back to the site.

Backups and site archives

The site editor should be sure that the web site is regularly backed up onto a secure and reliable storage medium to ensure that a catastrophic hardware failure in your web server does not wipe out your web site. Most web servers maintained by it professionals or commercial web service providers are backed up at least once a day. If you don’t know what your backup schedule is, ask your webmaster or web hosting provider. Human error is the most common reason you may need quick access to a backup copy of your web site. Unfortunately, it’s easy to overwrite an old file (or a whole directory of files) accidentally over a newer version on the web server, to delete something important in error, or to wipe out someone else’s work by mistake when updating a web site. A recent backup (ideally no more than twenty-four hours old) can often be a lifesaver.

If your site is successful, it will quickly become an important record of your enterprise’s work, your accomplishments, and the “state of things” as the site evolves over time. Unfortunately, too little attention is paid to this aspect of web sites, and we are collectively losing huge pieces of our history because no one thinks about preserving permanent records of a web site. Unless your web site is prohibitively large, your web site editor should arrange to collect and store the files of the site periodically or contract with your web service provider to set aside a backup version at regular intervals as a long-term archive. We take for granted the “paper trail” of history left by conventional business and work practices. Without a plan for preserving our digital works, our collective online history may vanish without a trace.

Common project development mishaps

There are many choices between you and a successful project outcome—one that meets the objectives in your project charter and does not place too much burden on your budget and resources, and one that will keep its value and integrity over time. Here we describe common pitfalls and recommend ways to avoid them.

Ready, fire, aim

The prospect of creating a new or revised web site is exciting, and many teams (especially agile-based teams) will find it irresistible to jump in and start “sketching” or prototyping site designs long before anyone on the team knows:

Don’t let the process get hijacked by eager beavers who “just want to make some pages.” Decide the big strategic things first, and make pages only when you have all the important answers in place to guide the rest of the design process intelligently.

Form before function

The fastest way to run a web project off the rails is to start your planning process by discussing the home page visuals or what the overall graphic design of the site should look like. Pour the foundation and build the walls before you let anyone fuss over the color of the drapes. The visual form of your site should flow from careful and informed decisions about site structure, navigation, content and interactivity requirements, and your overall business goals. Detailed visual design should always come later in site planning: premature graphic design decisions will confound you at every turn. This isn’t to say that designers should not be involved throughout the project, just that the major visual forms of the site should be based on the business and content strategy, not the other way around.

Too many meetings

Meetings are generally reviled because so often they are poorly conceived and unorganized. Too frequently you find yourself sitting in a conference room only because it’s “the weekly meeting”: there’s no formal agenda, and you end up spending an hour on someone’s random problem-of-the-moment, not on what’s most important to the current project.

The fact that many meetings are boring time wasters is almost beside the point. Meetings are very expensive. Multiply the length of the meeting by the average hourly rate of the people in the room and you quickly come up with impressive total costs. Then consider the preparation time, travel time, and the task “switch time” of disrupting each participant’s normal work, and an average one-hour meeting of six web professionals could easily be worth $600–800 or more. At those rates, whatever transpires in that hour had better be well planned and worth the cost.

Content and feature bloat

Often the easiest way to “manage” a site project is by adding content or features to avoid contention on the team or with stakeholders, particularly if you look only at the initial programming or design costs. Large web sites are expensive to maintain, and it’s easy to bite off more than you can chew. Every new page, link, or application feature requires a long-term maintenance commitment. Stay small if you can, and stay focused. A small, high-quality site is infinitely better than a giant contraption with outdated content and broken links. The Kiva site is a model of straightforward design and functionality—staying small while accomplishing enormous good.

Neglect

These days, for the vast majority of your public audiences, you are your web site. You would never leave the front door of the company or your primary customer service phone lines unattended, and you can’t leave your site unattended either. It makes far more long-term sense to treat your site as an ongoing customer engagement process, making constant small improvements in the site, while building up a large pool of relevant user data that can drive key decisions about where to invest in new or updated content and features.

Giant redesigns

These days 90 percent of web design projects are actually web redesign projects, done for clients who have had a web presence for many years. In spite of the web’s domination of business communications for at least a decade, many senior enterprise decision makers are still stuck in print-era paradigms, where the high cost and inflexibility of print production governed all assumptions about managing communications. This is owing to:

As Paul Boag points out in his book Digital Adaptations, this kind of “boom-and-bust” thinking about web projects ignores the iterative flexibility of the web, and also ignores the fundamental change in communications from one-way marketing “messages” to active, ongoing conversations in interactive media. He points out these key differences:

If you treat your web presence as a periodic project, your web presence is doomed to be suboptimal for about 50 percent of its lifespan between major redesign projects, with all the attendant damage to your customer relations and business reputation.

When you suddenly make massive functional and stylistic changes in your web presence after years of design stasis, you also lose a huge amount of data about how your audiences uses (or used to use) your web site, and at the launch of the newly redesigned site you are almost back to zero for the user experience data that ought to be driving a process of continuing improvement. Some enterprises make major changes in their sites so often that they have no idea what kind of return on investment they are getting because they have so little useful data on how people use their sites.

Your current site is also the best prototype for any new site, as it was designed to solve very similar business problems. Even if the site was not totally successful, there are important lessons to be learned from your current site before replacing it with a new site. You want to be sure that you understand which content and features are heavily used, that the new site covers similar content and features, and that you don’t alienate existing users with the new design. Even if you have not been actively collecting and analyzing data from your current site, you should initiate a user research and analysis campaign before replacing the old site, to be sure that you have gleaned as much information as possible from the old site before launching the redesigned site. In addition to usability tests on your existing site, it’s good to ask users to evaluate competing or similar sites to see which content or features are most appealing, and how you might incorporate that learning into the new site (see Chapter 2, Research).

Information architect Louis Rosenfeld points out another irony of massive site redesigns, which is that only a small fraction of the content of your site is seen by most users. Data on what users search for generally follow a Zipf distribution, in which a few queries and content topics dominate, and most site content falls somewhere out on the “long tail” of seldom-used, seldom visited material. Check the search logs and usage data of most sites and you’ll see that revising just a small percentage of pages will have a huge impact on what the average user sees.

When was the last time you heard Amazon, Facebook, Apple, or Google announce a “site redesign”? The smart players on the web don’t announce redesigns because they are redesigning their sites all the time, every day, in small, incremental ways that continually improve the customer experience. These small, fast, agile-driven site improvements happen all the time, to quickly fix or improve the site. If A/B testing or other site data show that the new processes don’t result in better usability, these small changes can be undone or fixed almost immediately.

Recommended Reading

Figures from Chapter 3: Process on Flickr