• The Creative Brief • Needs Assessment • The Project Charter • The Statement of Work • Use-Case Scenarios • Wireframe Mockups • Content Map
• Tech Requirements Meeting • Application Flow Diagrams • Technical Specification • Project Risk Assessment
A Web project is a temporary endeavor that employs Internet technologies to achieve a specific objective by creating or enhancing a unique product. To qualify as a project, it must do the following.
• Produce a unique outcome or deliverable
• Be finite in duration, having a clearly defined beginning, middle, and end • Require work
• Seek to fulfill a measurable objective
Your Web project may be the result of a corporate initiative originating from within your company or a proposal that has been accepted by a client. In either case, your immediate task during this embryonic stage is to define the project by assessing the needs of stakeholders and working with your team to draft
requirements documentation. There are several key documents that will serve as a road map for your team as you set off to deliver Web development services. The Creative Brief
Project definition begins with the creative brief. A creative brief is a work request containing a high-level description of the business objectives and functional
requirements, drafted by a project stakeholder and used to initiate the project. The creative brief may consist of an accepted proposal or a form that project
The purpose of the creative brief is to communicate the objectives and describe the major deliverables of the project, including significant features and deadlines. The brief should include business objectives, desired launch date, user profile, budget, project description, success metrics, a list of model Web sites, and a feature summary. Using the creative brief as a springboard, you are ready to leap into the murky waters of project definition.
Getting Started with Internal Initiatives
Internal corporate initiatives are particularly susceptible to the phenomenon of runaway requirements. This is due to the fact that true costs are often difficult to measure in the absence of rigorous employee time-tracking and profit-center accounting. Since the real costs are unclear, project stakeholders have little incentive to limit the scope of their ambitions. New project managers who are struggling to establish a process for handling Web initiatives within their
organization usually begin by creating templates for project stake holders. The creative brief is the most common of these documents. While the introduction of a creative brief template is a crucial step in gaining control over the project, it can provide a false sense of security. The creative brief is only the first of a series of documents that must be created in collaboration with project stakeholders. Are you doing enough to manage requirements in the early phases of a project? What are the early symptoms of incomplete project definition? The following scenario illustrates a recurring nightmare that may be familiar to you if your organization is new to the process of Web site development.
Sample Creative Brief
A sample creative brief is in the Chapter 4 folder of the CD-ROM and on this book's Web site at http://www.realwebprojects.com.
This sample presents a thorough and concise description of a promotional book club Web site. Submitted by the marketing VP of a large publishing company, this brief shows the level of detail that can be expected after a project stakeholder has received some assistance from the project team. Creative Brief
project name: Writer's Club Web Site
stakeholder: Publishing Company Inc. desired launch date: April 2002 development budget:
$500,000 plus $3,000/ month hosting
Business Objectives
This new Web site will provide visitors with the opportunity to achieve a very special goal: getting published in paperback. We expect this
promotional site to do the following.
• Attract new visitors to our site through promotions with writers' clubs. For example, the XYZ Writers Club of America has 8,000 members who are specifically committed to getting their novels published.
• Increase traffic and retention on our corporate Web site through direct participation (visitors submit entries, read, rate, and review other members' stories) and due to the nature of the contest (new stories/winners posted monthly)
• Increase minutes per pages
• Promote our brand as a leading publisher of fiction
• Attract high-level stakeholders and generate revenue in the $1 million-plus range
• Increase online book sales by driving traffic to our online bookstore • Obtain newsletter sign-ups and add these users to our marketing
database Project Description
• The Book Club Web site will allow visitors to submit works of short fiction, rate and review one another's submissions, sign up for an e- mail newsletter, and share content with friends.
• Visitors will be encouraged to submit short stories (length 5,000– 7,500 words), of which two per month will be chosen as a winner by a celebrity author judge or panel of judges provided by Book
Publishing Company.
• At the end of six months, winning stories will be published in paperback as a collection of short fiction by Book Publishing
Company.
• Each monthly winner will have the option to submit a completed novel manuscript for re-view; one of 12 complete novel submissions will also be published in paperback form.
Model Web Sites
The following sites have some examples of similar features with desirable look and feel.
http://www.ivillage.com/books/ http://www.amazon.com
http://www.writersdigest.com/ User Profile
The typical user will be female, college-educated, age 25 to 50, who is a frequent buyer of popular fiction. She will probably access the site from home. Her motivations for visiting the site include the desire to connect with women of similar interests, the possibility of being published, and curiosity about fiction created by women like herself. Detailed
demographic data to follow. Feature Summary
The Book Club site will consist of the following major features. • Home Page
• Registration • E-mail Newsletter • Submit a Story • Journaling Tool
• Editors' Publishing Tool • Story Archive
• Read and Review • Send to a Friend Home Page
• When users arrive at this page, they will find a welcome message and a description of the contest with an introduction to the celebrity judge(s). The bottom of this page will also house a brief profile and photo of the last month's winner. We may also want to include a small photo of the judge(s), as well as audiorecorded messages. • The rest of the page will be dedicated to related links.
• At the bottom of the page users will be invited to sign in if they'd like to submit an entry or read other stories.
• Clicking "sign-in" will bring the user to a registration page. Registration Page
Before they can either submit or read a story, visitors will have to sign up and submit their e-mail, which provides them with a membership in the contest.
Monthly E-mail Newsletter
Visitors receive a monthly newsletter that does the following. • Announces the monthly winner
• Introduces new books
• Presents book discounts and promotions • Links to the writing center on our Web site • Highlights the monthly deadline
Submit a Story
When members select "submit," they arrive at a Submit home page. This page will feature How to Submit, Official Rules, FAQs (with links to separate article pages where relevant), and a "Submit Your Story Now" button.
• Clicking the "Submit Your Story Now" button will allow the user to submit a story of 5,000–7,500 words via a Journaling Tool.
• After entering the story in the tool, they will arrive at a Thank You page. This page will offer links to read and review other stories and go back to the Book Club. Also, auto-reply e-mails will be sent to the submitter.
• Each submission will need to be monitored before being published on the site to confirm that there is no inappropriate content. Each
submission should enter a queue, which can then be reviewed and either "accepted" (published) or "denied" (perhaps a form e-mail should be sent informing the party that their story could not be posted on the site). Submissions will all be read a second time by judges to determine the monthly winner.
• When the submitter is notified that the story has been posted, there will be the option to send to friends and family e-mail inviting them to come and read the submission.
• Winners will be notified via e-mail of their success. Read and Review
• When members click "Read and Review," they arrive at a "Read and Review" home page.
• This page provides links to directories of this month's stories organized either by title or by author.
• Visitors will be invited to be a "Peer Judge" and rate and review the stories.
• There will also be a self-updating list of the Top Ten peer-rated stories here. Each story title will be a direct link to the story. These stories could be identified with a "Top Ten" icon at the top; this icon would serve as a link back to the Top Ten list page so members can opt to read all 10 of the Top Ten stories.
• Each story will have a Rate and Review option. • Each story will have a Send to a Friend feature.
The creative brief arrives as an "urgent" e-mail, addressed from an important project stakeholder. The message contains an awkward subject line: "Okay, I filled out your form. Let's get the ball rolling." The attached brief announces broad business objectives, includes a rough sketch of a home page, and displays a list of model Web sites with notes like "We love their color choices" or "We can do better than this, right?"
You quickly find that your inbox is choking under a deluge of mysterious messages originating from remote divisions of the
company. Each of these e-mails features a massive block of text in the "cc" line. With each successive reply, the names on the "cc" list grow
like an alphabetic bacterium. The guerrilla lobbying effort of another inspired project stakeholder has begun.
In an effort to drum up support for the project idea, the creative brief has been circulated to potential allies across the company. With each thread of the electronic brainstorming session, feedback blurbs are introduced by "my comments in CAPS" or "see responses below." Random feature suggestions appear, perhaps including a "peer-to-peer networking for sharing pet photos." People stop you in the hallway and ask, "When is the launch date?" The list of requirements is already out of control, and you haven't even announced a kickoff meeting yet! "Feature creep" begins to resemble an avalanche, and you're at the receiving end.
The next section introduces the project documentation that will help you seize the reins of runaway projects.
Project Documentation
Now that the project stakeholders have communicated the project concept and are asking your team to commit resources, it is time to roll up your sleeves and draft the requirements documents. The purpose of this extremely labor-intensive activity is to work with your team to describe the project. Table 4.1 summarizes the main documents that are used to define a Web project, as well as the chief collaborators who will be instrumental in their creation.
Several key documents are used to describe the characteristics of a Web site. Guided by a thorough needs assessment, use-case scenarios, and other
requirements-gathering techniques, these documents capture the business objectives and functionality at the genesis of the project.
• Project charter • Statement of work • Wireframe mockups • Content map
• Application flow diagrams • Technical specifications
Use-case scenarios are narratives that describe all the possible ways in which users interact with a Web site as they seek information or make a transaction. Use-case scenarios are explained in detail later in this chapter.
Needs Assessment
Needs assessment is an ongoing process that usually takes place in a series of formal meetings with project stakeholders. Regardless of whether these
stakeholders are coworkers (in the case of an internal project) or external customers who are paying consulting fees, the goals are the same. The initial
objectives of the needs assessment process are to address gray areas or omissions in the creative brief and to gather information that will be used to create the project charter. If the business objectives are unclear, address these first by distributing the creative brief to project stakeholders and compiling their feedback, while placing a time limit on the response. Allow dissenting opinions to be heard and evaluated before the features are set down on paper. Work with the project stakeholder to refine the business objectives. If your team includes a business or marketing strategist, their consultations will be crucial at this stage. These specialists have expertise in applying Web-based solutions to the business problems of a particular industry.
Table 4.1. Project Definition Activities and Deliverables
Task Collaborators Deliverable
Assess Needs Define business objectives Project Stakeholder Business/Marketing Strategist Project Charter
Describe user profiles Project Stakeholder Business/Marketing Strategist
Information Architect
List assumptions Project Stakeholder Identify success metrics Business/Marketing Strategist Conduct competitive review Producer/Product Manager
Identify model sites Draft project charter
Define Requirements
Create client wish list Project Stakeholder Account Manager Producer/Product Manager Statement of Work Review technical feasibility Tech Lead Prioritize deliverables Project Stakeholder
Account Manager Producer/Product Manager Draft statement of work Producer/Product Manager Create use-case scenarios Information Architect Producer/Product Manager Tech Lead Developer Use-Case Scenarios Draft wireframe mockups Information Architect Tech Lead Developer Wireframe Mockups
Draft content map Information Architect Editor/Content Producer Project Stakeholder Producer/Product Manager Content Map Hold tech requirements meeting Tech Lead Developer Information Architect Producer/Product Manager
Application Flow Diagrams Technical Specifications
Draft application flow diagrams
Information Architect Tech Lead
Developer
specifications Developer
Information Architect
Evaluate Risk List constraints and dependencies
Project Stakeholder
Tech Lead Risk Assessment Identify technical risk Tech Lead
Plan contingencies Project Stakeholder
Tech Lead Contingency Plans
Once the business goals are clear, hold a series of feature brainstorming sessions, but insist that each idea must relate to the business objectives and provide a clear success metric. You may feel that you are exposing the product to a cycle of endless revisions, but it is important to address feature suggestions early so that everyone will be on board. This will lessen the impact of the inevitable second- guessing that occurs at later stages and hopefully prevent radical changes in direction.
The desire to put the brakes on open-ended feature discussions or resort to the easiest solution can be irresistible for deadline-driven project managers. However, creative problem solving plays a crucial role in this new medium. Given the
blistering speed at which new features and technologies appear on the Web, the "right solution" to your business objectives will rarely be obvious. This is the case even if your project team includes top business strategists. If you are fortunate enough to retain business strategists, keep an open mind. The record of business initiatives on the Web is littered with pompous whitepapers expounding on the virtues of debunked technologies and business models that were rendered embarrassingly obsolete in six months.
Top Web project managers make it their business to stay informed about recent developments and serve as a valuable resource for stakeholders. Be courageous by opening up the debate in these early stages and presenting creative suggestions. Do your homework, take a deep breath, and then take the lead by initiating a creative, open-ended needs assessment.
Here are some tips for conducting a needs assessment.
• Provide a questionnaire for project stakeholders that will help them to clarify their thinking about their new initiative.
• Solicit examples of existing projects that are similar, and then define the similarities and differences between existing projects and the proposed initiative.
• Define your terms as you go along (for example, "What do you mean by 'category' versus 'section'?").
• Communicate ideas visually with diagrams and sketches.
• Paraphrase/repeat back each important concept to demonstrate understanding of the issue, to clarify a point, and to reassure.
• Explore the project objectives at a greater level of detail than what was brought up in the creative brief.
• Find out what determines a successful outcome for the project and how this outcome can be measured.
• Ask the client to envision how the Web site will change over time. • Solicit suggestions for future enhancements.
Needs Assessment Questionnaire Open the Chapter 4 folder of this book's CD-ROM to find specific examples of the questions that you'll need to ask. The book Web site contains an updated version at http://www.realwebprojects.com. The purpose of the needs assessment questionnaire is to assist project stakeholders in defining the initial scope and objectives of the project from a business perspective. Based on these core business needs, the Web development team, led by the project manager, can suggest appropriate Web-based solutions.
These types of questions are also used by account managers during the sales process to uncover the customer's problems and open the door to a solutions proposal. Rather than duplicating their efforts, you should try to fill any remaining gaps in the creative brief or accepted proposal.
The Project Charter
The purpose of the project charter is to obtain consensus on the mission of the project and establish the high-level expectations of the project stakeholders in terms of schedule and resources. Putting the objectives into writing helps expose any hidden agendas, misunderstandings, or confusion on the part of project stakeholders. Eventually, project owners will have to resolve priority conflicts by making difficult choices about which features to include in the initial launch. The
project charter sets forth the guiding principles that will inform these choices, and it will keep the project from becoming easily sidetracked by one of the random suggestions that your client makes late in the game. When drafting the charter, try to avoid delving too deeply into specific features. The objective here is to justify the project. The project charter is usually divided into several sections covering objectives, scope, success measures, resources, and risks from a strategic or