The moment you find out about an upcoming web project, work closely with your account lead to get as much information together as you can. The two of you will outline the project charter and a draft statement of work. You’ll also need to make sure your account lead drafts a creative brief that can be run by the creative lead. If you’re wearing multiple hats and also happen to be the account lead you just saved yourself a step and can coordinate this effort on your own.

At this point you’ll be ready to call a meeting of your core team. As we learned in Defining Web Project Roles and Responsibilities, your core team consists of the “Fantastic Four” model – you as project lead, your account lead and your creative and tech leads. Immediately getting your core team leaders on the same page will help get your project off on the right foot.

I like to call this meeting a “pre-kickoff” gathering, where the core team leaders have the opportunity to vet all the available information, start formally defining the project scope and identify any holes that may impede progress. This is where you add the most value to the project by capturing the vision of execution in the final statement of work and creative brief.

Once you and your core team are in agreement with what you believe the project scope to be you’re ready to present this information to the client. This will be your opportunity to get key questions answered before you officially move forward. It is critical that the client is involved from the very beginning. This will avoid miscommunications going forward and give them a feeling of higher investment and empowerment in the project.

In one of the pivotal scenes of Raiders of the Lost Ark, Indiana Jones says “I don’t know, I’m making this up as I go along.” Everyone should realize you’ll never get all the information you need at the beginning of a project because it doesn’t exist yet. It’s the ongoing chicken and egg dilemma of project management, so your goal is to make the most educated guess and best assumptions you can. Imagine as much as possible the way you think your project should be framed out and document your assumptions along the way. When your core team has ideally confirmed or imagined 80% of the project scope, you’ve documented the remaining 20% as assumptions and your client has approved it all you’re ready to call a project kickoff meeting with your larger team.

What functionality and content does your website need to satisfy the site strategy? Documenting this critical information is called Requirements Gathering. Web development borrows a lot of terminology from traditional software development practices, and the phrase “Requirements Gathering” comes from that world.

Marketing people don’t like traditional software practices or phrases, and marketing people are usually web project sponsors. So they’ll look at you cross-eyed if you say, “Hey, what are the requirements?” Instead, it’s often better to say something like, “Let’s get everyone’s ideas down on paper so we can figure out what this thing needs to be”. You don’t need to tell them it’s a requirements gathering session. What’s important is that you, the web project manager, know this and are starting to document the features and functionality of your web initiative. You’re the only one who needs to know the official name of this critical process step.

The best way to start gathering requirements is with a simple outline. By the time you’re ready for this you should have a well defined, client-approved site strategy in place that will guide what should and should not be included in the requirements. Schedule a meeting with the client and project team to create this outline together. Don’t do it yourself in a vacuum. Websites are all about people and politics. Don’t forget the people or you’ll be forced to deal with the politics.

Sometimes it’s helpful to walk into a meeting with a draft outline to get the conversation going. Just make sure everyone knows that’s why you drafted it and that you’re not trying to take over. Your draft outline is merely a tool to start the conversation and is open for revisions and rejection if necessary. Bring handouts of the site strategy to the meeting and write your draft outline on a whiteboard. A whiteboard or eisel is ideal because you’ll be doing a lot of brainstorming with your team as you discuss what is and is not required. Hard copy handouts of the approved site strategy will help keep everyone on task and subtly remind them that the approved strategy is not up for discussion.

As you work through the requirements most people will be thinking only about the front end, so make sure any backend issues or third party features and functionality are also included in the discussion. When everyone’s had a chance to offer up ideas, take a break and review everything together. What’s really necessary and what’s nice to have? If it’s “really cool” but doesn’t satisfy the site strategy, put that in the nice to have category. Be ruthless in this exercise. Nice to have features are one of the main causes of scope creep so be on guard.

Is everyone in agreement on what’s really necessary and what’s nice to have? If there are any disagreements, set these items aside on a separate list along with descriptions of the disagreements and table the discussion for now. Focus on what’s working and agree to work through the issues at a later time. Likewise set aside the nice to have list and agree to revisit it if and when the schedule and budget allow for it.

Next you need to prioritize your requirements. What’s most important of everything you’ve written down? What’s the least important? Is that least important item (or items) really a nice to have in disguise? If so, take it off the requirements list. Again, be thorough, direct and ruthless in your approach. Your team will thank you and so will the budget and schedule.

A thorough requirements gathering process may take more than one meeting and often requires consistent follow up to make sure all open issues are fully resolved. The final, approved requirements will serve as the basis of the creative brief, statement of work, technical specifications and ultimately the project’s profit or loss. Devote the appropriate amount of time to this due diligence step and educate your teammates on its importance. You will have more successful and profitable web projects as a result.