Seems simple enough, but I can’t begin to count the number of times that failing to do this caused a project to lose direction. Meeting with project managers and content creators about what exactly we’re building, what kind of site we’re creating, is of the utmost importance at the beginning of a project. Kelly Goto and Emily Cotler call this phase “Defining the Project,”1 while Jesse James Garrett calls this phase “Strategy,”2 but both essentially mean the same thing: figure out what exactly you’re building, who’s it for, and what is needed for the successful completion of the project.

I would advise that in this phase, you try to answer the following:

• What is the site?
• What content will be on the site?
• Who is the audience? How will we want them to use the site? How will they use the site in other ways?
• What specific components are needed on the site? What technologies? Static HTML? Need dynamic content? Need a CMS? Need a custom web application or interactive features?
• What is the timeframe for completing specific phases of the project? What is the timeframe for completing the entire project? What other projects are vying for time?
• Who is on the project team? What are their responsibilities? How much of their time do we have, or can get?

Questions

What is the site?

If you can’t answer this, it will be very difficult for everyone on the team to actually build it. Its OK for the definition or description of the site to evolve over time. In fact, you should probably expect this, as your user base grows or you get new content. The project team does need to hash out, in a paragraph or two, what exactly the site is about, what it offers that other sites do not, and why it is important. If you can’t justify building the project, you should consider whether you should build it at all.

What content will be on the site?

It is very helpful to everyone on the team to have a discusion of what kinds of content will be on the site. This isn’t saying that the content needs to be done at this point; only that a good idea about what content and how much will be on the site. Is is primarily images? Text? Video? Some combination thereof? Is the content something the team is preparing, or something collected from the public? Is it a “web translation” of a physical exhibit or a book? Is it web-native? The kinds of content, its origins, and the expected interaction between users and the content, will influence answers about who the target audience is and what technologies are needed for the site.

Who is the audience?

The answer to this question has important consequences for the development of the site. Even if you have a solid answer for what the site is, and what content will be on the site, the audience for your site greatly affection how you present that content on the site. A teaching site on the history of the Spanish-American war may look and be organized differently if the primary audience is elementary or high school students instead of teachers. The language used on the site, the content for the site, and the design are all affected by the target audiences.

Needed technologies?

From the very beginning, before one line of code is written or one pixel moved in Photoshop, the team needs to decide what kinds of technologies will be needed for the website. Answers to this question depend on answers regarding what the site is about.

Do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help.

The development team specifically needs to help answer this question. Following Tom Watson’s advice, the project team should come together to discuss problems to solve, and what technologies will best solve those problems. You do not, for example, need to use a robust content management system like Drupal if your project consists of only a dozen static HTML pages.You do not need AJAX simply becuase other sites have AJAX; You do not need a blog because other sites have a blog. In other words, do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help. Have a reason for everything!

I would say that the development team needs to be the lead on answering this question. They will (or should) have the most experience with determining which technologies will solve specific problems. But its generally good to talk about the problems first, so the development team can decide on which techology solution will best solve those problems.

Timeframes?

All of the previous answers can be fantastic and full of possibility until you talk about the most important aspect of a project: time. Time can be a harsh master. It is a very a good idea to set deadlines and milestones, to keep the project moving forward and give everyone a sense of how long things will take and when they’ll be done. In some cases, work by each team member can continue simultaneously. In others, one team member must complete a requirement before another team member can start or finish her/his requirements.

In some cases, deadlines are set by grants: “We promised a fully-function site to collect public reflections by May 2009,” for example. Those absolutely should be met. Others can be a little more flexible, but not so flexible that the project never gets finished. Here’s a quick process for setting milestones and criteria:

1. Figure out what milestones are needed (content complete, CMS installed, wireframes completed, etc)
2. Set deadlines for each milestone, for specific phases of the project
3. Associate specific criteria for completing milestones by the deadline
4. If those requirements aren’t met, decide whether to move the deadline for the milestone up to allow for completing the criteria or to remove specific criteria as unnecessary.

In other words, deadlines should be stable enough to provide direction and purpose for the team, but flexible enough to account for unexpected contingencies. If you’ve reached the deadline for a milestone, but do not have all the criteria done for the milestone, consider whether those criteria are necessary to move on. Its OK to say that some criteria are, in the end, unnecessary to consider a milestone complete, and to move those criteria to other milestones and deadlines.

Having milestones, set criteria for meeting those milestones, and deadlines for milestones help keep the project on track, and prevent “feature-creep” or “scope-creep.” By this I mean the tendency for a project to take on new features or new scopes that were not set in the beginning of the process, and cause deadlines to be missed. Its fine to add new features, or change the scope of the project, so long as everyone on the team understands that the timeframe and deadlines may have to shift because of those new requirements.

Team Members

Everyone on the team should be introduced to each other, with a brief discussion of each person’s specific skills and responsibilities for the project. This not only helps build camaraderie, it also lets someone know who to contact for specific questions or issues. Having trouble finding or using the project logo? Ask the designer. Having a problem with a specific aspect of the CMS? Ask a developer. Not sure where the content is for a specific section? As a content lead or project manager.

Management Hubs

This is a lot of information to manage, a lot of tasks to track, and a lot of people to potentially know and talk to. You shouldn’t even try to manage it all on paper, or in your head. The project team needs a central location to go retrieve information about the project, manage tasks, and learn more about other phases of the project. In comes a management hub.

At CHNM, we use Basecamp, a service created and offered by 37 signals. We manage dozens of projects on our Basecamp account, with each project having a homepage, Messages, To-Dos, Milestones, Writeboards, and a place for file uploads. There is a list of everyone involved with the project, with roles and contact information. You can associate a specific to-do list to a milestone, and can thus determine if you can “complete” a milestone if you have completed all the tasks in the associated to-do list. You can assign to-dos to a specific person. We use Writeboards for meeting agendas, notes, and any other documentation we want to keep (styleguides, ideas, etc), and we tend to use the Messages feature more than email to send correspondence concerning a project, that way everyone has an archived copy of the message in Basecamp. As CHNM has grown, Basecamp has become indispensable for managing all our projects.

Alternatively, you could easily use a wiki to manage your projects in much the same way as Basecamp. Free wiki services abound on the web (PBWiki is great, for instance). While not as feature-rich as Basecamp, wikis can fulfill all the needs for project management, with a little work and devotion to organization. You could set up a PBWiki with the following pages:

• Homepage—The “dashboard” with the description of the project, the goals for a project, and list of team members with responsibilities. Links to other sections:Timeframe, To-Dos, and Notes.
• To-Dos—divided by person or aspect of a project, marked off as they’re completed.
• Notes—any meeting notes, archived discussions, or ideas you want to archive.
• Timeframe—a running list of milestones, with criteria listed for successful completion of each milestone.

In any case, the hubs should at least contain the following:

Description of the project

A paragraph or two stating what the purpose of the project is, what it encompasses, who its target audience is, and what the site will offer.

Goals for the project

A well-defined list of goals or deliverables for the successful completion of the project. This helps keep everyone on target, and ensures that any decisions made during the development of a project should only contribute to, and not add or detract from, the goals.

Project team members

I recommend devoting an entire page, or section on the main page, for listing team members, with their roles or list of primary responsibilities listed and contact information. Perhaps even a link to personal webpages or profiles.

Timeframe

Deadlines, criteria for completion of the project, and major milestones.

To-Do lists

Pretty straight-forward: lists of things that need to get done for a project. This can be divided by person, by team (design team, development team, content team) or by sections of the site. its helpful to have these in once place, so that everyone on the project has a sense of the amount of work everyone is facing. Good especially if someone asks for new features not part of the original description or goals for the project.

Meeting notes, various content pages, links as needed

Good to keep in one central location for all team members to contribute to and refer to throughout the project.

You should totally feel free to set up a wiki however you want, but you goals should be: keep everyone informed, archive project progress, and keep the scope of the project clear and visible.

All Alone?

If you’re your own project manager, have this meeting with yourself. Before you type one line of code or color one pixel in Photoshop, go through this process. Set up a project hub. Take meeting notes. Create a timetable. Make to-dos. Some of it may be meaningless (like list of team members), but it helps to formalize the development of a project. And, if you end up getting a grant or someone volunteers to help you with the project, you’ll easily be able to orient them and integrate them into the workflow for the project. If it helps, have someone else around to talk through ideas and get things down more concretely, or pretend you’re explaining the project to someone else.

What’s Next?

After doing all of this, either in one meeting or several, you should be set to move into the next phase of development: Information Architecture. I’ll cover this next week!

1. 1 See Kelly Goto and Emily Cotler, Web ReDesign 2.0: Workflow that Works, Berkeley, CA: Peachpit Press, 2005, 40.
2. 2 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 23.