Web Style Guide 3rd Edition

1 Process
Developing a Project Charter

The project charter is the planning 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.

At minimum, a project charter should define the content scope, budget, schedule, and technical aspects of the web site. The best project charters are short and to the point, often outlines or bulleted lists of the major design or technical features planned. The finished project charter should contain the goals statement from the planning phase, as well as the structural details of the site.

Goals and strategies

What is the mission of your organization?
How will creating this web site support your mission?
What are the two or three most important goals for the site?
Who is the primary audience for the web site?
What do you want the audience to think or do after having visited your site?
What web-related strategies will you use to achieve those goals?
How will you measure the success of your site?
How will you adequately maintain the finished site?

Production issues

What is the budget for the site?
What is the production schedule for the site, including intermediate milestones and dates?
Who are the people or vendors on the development team and what are their responsibilities?
How many pages will the site contain? What is the maximum acceptable count under this budget and schedule?
What special technical or functional requirements are needed?
Who will be responsible for the ongoing support once the site is launched?

These are big questions, and the broad conceptual issues are too often dismissed as committees push toward starting the “real work” of designing and building a web site. However, if you cannot confidently answer all of these questions, then no amount of design or production effort will guarantee a useful result.

Avoiding scope creep

The project charter defines the scope of your project: what you need to do, the budget, and the development schedule. 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 during site construction 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 what might have been an elegant original plan under megabytes of muddle.

One excellent way to keep a tight rein on the overall scope of the site content is to specify a maximum page count in the project charter. Although a page count is hardly infallible as a guide (after all, web pages can be arbitrarily long), it serves as a constant reminder to everyone involved of the project’s intended scope. If the page count goes up, make it a rule to revisit the budget implications automatically—the cold realities of budgets and schedules will often cool the enthusiasm to stuff in “just one more page.” A good way to keep a lid on scope creep is to treat the page count as a “zero sum game.” If someone wants to add pages, it’s up to them to nominate other pages to remove or to obtain a corresponding increase in the budget and schedule to account for the increased work involved.

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.

Shaping the final project charter

The project charter is the document that formally authorizes a project to begin. In projects bid out to external contractors this information is generally contained within a request for proposal (rfp) document, but a project charter should exist for every web project, even small in-house web sites.

Statement of work or deliverables

The project charter should begin with a concise narrative description of the content, features, and services that the new site will provide. For in-house projects the project sponsor usually supplies this statement of overall intent for the site. For projects offered to outside design firms the statement of work forms the core of the rfps offered to potential contract bidders.

Business needs the site will support

This section answers the “why” of your project. It should be a short description of the sales, marketing, communications, or other business 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.

Satisficing in design

The economist Herbert Simon coined the term “to satifice” by combining “satisfy” and “suffice.” Satisficing is consciously choosing not to find one perfect design solution and 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: all its competitors could best it in some category of speed, engine power, range, and carrying capacity. Yet the DC-3 was such a successful satisfice of all design factors that today, more than seventy-five years after it was designed, more than thirteen hundred 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 if there is a single best solution to every problem for every user. Don’t let the perfect become the enemy of the very good.

Drawing of the side view of a Douglas DC-3 airplane.

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. Before you begin a site development project, determine how you will measure the impact of your efforts, and include details of success metrics in your project charter. 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 and description

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. 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 specifying the use of specific technologies (such as, “We’re using Ajax for everything”) that really should be determined after the web site team has made a thorough assessment. The project scope description should be a living document early 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. 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.

Roles and responsibilities

Your charter should name 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 everyone involved is clear about how each major project milestone will be communicated and formally approved by the sponsors or major stakeholders (fig. 1.11).

Large, two-page diagram of a very detailed Gantt chart for a complex web design project, showing the relative level of effort for each team discipline over the life of the project.

Figure 1.11 (Click for a PDF version) — A more detailed look at a typical web site development project. Note that although many people and disciplines may contribute to building a site, not everyone is busy at the same time. Project management is essential to bring the right resources to bear when they are needed.

Project budget

Your project budget should account for all of the expense categories outlined in Site Definition and Planning, above. 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.

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?

Common risk points in web projects

Schedule, budget, and scope of work: Let these drift and you’re doomed.
Quality assurance: qa becomes a problem when other schedules run long but the launch date doesn’t change and qa testing is squeezed into the last few days before the site goes live.
Content development: This is the most commonly underestimated factor in web publishing—ask any editor.
Application development: Web projects rarely fail because an application does not function properly. Instead they fail because the intended audience hates to use it or doesn’t find its features useful.

Security audits and managing security risk

Databases and applications that deal with e-commerce, or sensitive personal, financial, or health-related information should be scrupulously maintained and periodically audited for data security threats. Even a minor security leak or unchecked programming error could allow a hacker to access your database records, cause malicious damage, or take over your server to support email spamming or other illegal Internet schemes. The data security environment changes daily, and what was perfectly secure six months ago might be hopelessly vulnerable today if your servers, databases, and applications are not under active management and maintenance. Any web-based application or web database must operate with a plan for periodic security audits, as well as the normal timely application and web server patching and maintenance that you’d expect in any well-management data center or commercial web hosting service.

Ongoing technical support for hosting, databases, applications

Nontechnical managers are often unpleasantly surprised by the expenses of hosting and maintaining web sites that require substantial database or programming support. Although basic hosting of “static” web sites is an inexpensive commodity, web sites that depend on databases and the complex interactive features of web applications must usually be hosted on two or more tightly interrelated servers for security and technical reasons. The multiple servers must be maintained and updated, regularly backed up to prevent data loss, and housed in a secure networked data center environment for maximum reliability and “up time.” Make sure that your technical team lead has accounted for these ongoing system maintenance costs as well as the initial development and start-up costs.

Editorial maintenance

Your brand-new web site starts aging the day you launch it into the world. If you don’t maintain the site, technical changes, content changes, and the inevitable entropic “link rot” will degrade your site over time. Even a simple site with relatively stable content will deteriorate over time without basic maintenance, and business environment changes that affect your content will certainly happen. Plan for it, make sure you can clearly identify who is responsible for which content on the site, and make ongoing maintenance part of the original site planning.