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.