Steal Our 8-Step Requirements Gathering Process for Project Management

Imagine standing at the start line of a marathon without fully understanding what you’ve committed to or what is required to complete the race.

You didn’t know you were required to train the distance, invest in a strong pair of running shoes, or pack energy gels to fuel your body and keep going. Perhaps it’s even a surprise that a marathon is 26.2 miles long!

Basically…you haven’t completed the prep work required to succeed in this challenge, and honestly, you might not make it to the finish line. Sounds stressful, right?

While business projects aren’t usually as physical as the average marathon, they rely on the same “requirements gathering” process to set companies up for success.

This guide will teach you how to collect requirements for a project, including when and who is involved. By following these steps, you’ll control project costs, stay on schedule, and deliver a successful project you and your team are happy with.

What is requirements gathering in project management?

Project management requirements gathering is the process of understanding every requirement involved in completing your project successfully. These “requirements” translate as all the tasks or resources you need to deliver the project on time, within budget and scope, and that meets (or ideally, exceeds) expectations.

While that probably sounds like a lot, requirements usually fall into two buckets:

• Business requirements: This is essentially the overall goal of your project
• Technical requirements: Everything involved in accomplishing the goal above

💡 Example: A marketing project’s business requirements may be to “increase leads by 20%.” The technical requirements include completing tasks to deliver items such as social ads and lead magnets to target customers with special offers.

Why is gathering project requirements so important?

Gathering project requirements is one of the most critical processes in a project’s lifecycle. 35% of failed projects cite inaccurate requirements gathering as the primary cause of failure. Don’t be part of this statistic.

Project progress requirements will help you to:

• Understand the scope of work
• Identify and assess all project risks
• Accurately estimate the cost of the project
• Create a project timeline everyone is happy with
• Effectively allocate and prioritize project resources 
• Not obliterate the project budget on irrelevant “requirements.” 

To stay organized as you grow and juggle projects, you must build a process that collects, translates, and shares requirements with the team to get it right every time.

The three main phases of requirements gathering

Requirements gathering happens in three broad phases.

Requirements elicitation

Requirements elicitation happens first. This initial phase gathers information to understand what stakeholders need, both during and from the project outcome. This step requires strong and open communication and proper investigation to check every requirement you “think” you need actually aligns with your business objectives.

Requirements documentation

The next step is to document the requirements to make them formal. You’re effectively putting a stake in the ground and announcing, “Hey, these are our non-negotiables.”

Documentation typically includes detailed descriptions of your business and technical requirements, but above all else, they must be accessible. After all, what’s the point of writing your requirements down if no one understands what they mean?

Requirements confirmation

In the final phase, key stakeholders will review, validate, and approve the requirements you’ve gathered. They’ll check that the requirements accurately reflect the stakeholders’ needs, are achievable within project constraints, and align with the organization’s overarching goals.

Be warned…there may be some discrepancies at this stage. Some stakeholders could disagree with others about the importance of certain requirements. Overcome this by using a recipe of negotiation, prioritization, and feasibility assessments to finalize your list of requirements.

How to gather requirements for a project

You can break each of the phases above into actionable steps. It’s worth pointing out that all projects differ, so there is no “best” way to gather them. But the list of steps below is a fantastic starting point.

Step 1. Decide when to gather project requirements 

Typically, you’ll gather the requirements right at the beginning during the project planning phase, allowing you to include them in your project brief and kick-off meeting. Deciding how much time to set aside for this is like asking how long a piece of string is. The size and complexity of the project and the availability of stakeholders will influence how straightforward this is.

Step 2. Assign roles to collect project requirements

The person or team responsible for gathering requirements will vary depending on your business and team size:

• Freelancer? That’s on you
• A small business? Potentially the founder or CEO
• Growing company? An Agile team project lead, account manager, or business analyst
• The best-case scenario? Get a project lead and domain expert involved. Just remember, the domain expert/s will and should change depending on the type and complexity of the project.

Personalities and strengths play into finding the right person. For example, if a development team’s technical expert isn’t comfortable with stakeholder interviews, have them draft questions while someone else leads the discussion.

Step 3. Interview project stakeholders

Once you’ve identified key stakeholders, meet with them to get an idea of what they hope to get from the project. Understanding what you need to achieve is critical, as this will be the deciding factor behind what deliverables you create.

Step 4. Gather and document your findings

Also known as requirements management, you’ll use a project requirements template at this stage to take the info from above and shape it into something that makes sense for you and your team (click on the link above to make a copy of ours!).

Depending on the project’s complexity, you might have to speak with multiple stakeholders to fully understand the project scope of work — each may have different requirements.

But remember that not all project requirements are necessary for success. Ask yourself: Is this requirement essential to achieving the business goal?

This is where you assess if the project requirements are:

• Inconsistent or duplicated
• Not feasible based on resources and logic

These two points are significant factors that can frustrate your team, waste their time, and cause delays.

Remember to identify and assess project risks as part of this process. Get your team together for a brainstorming session to figure out how to reduce those risks to ensure you stick to the project timeline and stay within budget.

Step 5. Break down the deliverables into smaller chunks

Once you understand the project goals and objectives better, you can start to determine what effort needs to go into the project to deliver it successfully.

Use a Work Breakdown Structure (WBS) to break the project into manageable phases and tasks. 

A WBS is a hierarchical outline of the tasks and workflows required to complete a project. The WBS “breaks down” the structure of a project into manageable deliverables or phases.

It helps streamline, visualize, and manage projects more efficiently. It also serves as a framework for detailed cost estimation and control and an overall project schedule guide.

You can download our free WBS template here (just make a copy to customize it). It will help you understand what resources are needed for the project, as well as create an initial project timeline and project budget.

Step 6. Create your baseline budget and timeline

Once you fully understand the scope of work, you’ll need to create your baseline project budget and timeline.

You can do this by allocating costs to each task within your WBS. Or, if you’re using Toggl Track, you can access past project data within the Project Dashboard to pull together a quick baseline estimate. Task-level functionality is also available within the same dashboard.

Step 7. Get approval from project stakeholders

Meet with key stakeholders to present your baseline estimates. Get their feedback, ask more questions, clarify requirements, and get approval to start.

It’s all part of the process. Good project requirements gathering may mean a lot of back and forth. But you’ll remedy the expensive and infuriating process of reworking project deliverables long after the deadline because “that wasn’t quite what we wanted!”.

Step 8. Create your statement of work

Once you understand everything, it’s time to create and sign a statement of work, including all the information you’ve collected in the previous steps.

Your SoW acts as your safety net if the project gets somewhat out of control. It should outline project tasks, deliverables, timelines, and costs, including anything out of scope.

Requirements gathering techniques

Let’s circle back to that part where you magically find out everything you need to know about your stakeholders’ requirements. Here are some tried and tested techniques you can use to extract this essential information without feeling like you’re pulling teeth:

Questionnaires

Questionnaires are convenient if you need to gather the requirements for your entire project asynchronously. You’ll simply create your list of questions, submit them, and wait for the answers to roll in. They’re particularly useful if you need to ask the same questions to a wide range of stakeholders.

Broad questions like “What are the requirements?” are too vague. Instead, ask questions about what they want and hope to accomplish. Then translate the desires, goals, and objectives into deliverables, a timeline, and a budget you and your team members can work with.

How does this work? The goal is to ask the kinds of questions that describe the requirements regarding business needs — as they will provide more actionable info for your project team. For example:

• “What problem are we trying to solve?” (and resist adding “and how do we solve it?”—that isn’t their job)
• “Can you describe [current solution] for me?”
• “What are the pain points/issues with the current process?”
• “What would an ideal experience for [project topic] look like?”

User stories

Use case scenarios are a useful technique to prep for the requirements confirmation stage. Based on the information you know, either collected through questionnaires, focus groups, or any other technique, you’ll flesh out a description of how you expect your team members to execute a project.

You’ll include plenty of detail, such as role responsibilities, user needs, and the steps they’ll take to reach your project goal. Then you’ll present your user story to stakeholders and ask them to validate it.

Prototypes

Prototypes have a similar goal to use cases. This technique requires you to create a prototype to show what the deliverable could look like for end-users. You’ll present your prototype to stakeholders for validation, allowing you to tinker with the requirements to ensure they meet your project objectives.

Mind mapping

Mind mapping is great for visual learners or for documenting requirements when your projects are more complex than the traditional list of resources or “jobs to be done.”

It’s a type of visual brainstorming — you’ll place your business requirement or project goal in the center of your mind map, then offshoot it with bubbles depicting each of your technical requirements. Keep branching out with different levels and sub-levels of bubbles until you have a visual roadmap that accurately depicts your requirements.

3 common challenges of gathering project requirements

“Essential but not easy” would be a good way to sum up the practice of essential requirements gathering. Here are three common challenges you may encounter as you conduct this process.

Preventing scope creep

Projects that aren’t planned out to the letter have a habit of spiraling, going off on tangents, and draining your resources. Avoid getting into a situation where your project demands more and more requirements post-kick-off by having a solid, pre-approved statement of work. This allows you to manage requirements by maintaining control and focus. It also provides enough leverage to renegotiate your project agreement if scope creep does occur.

Documenting the requirements

We’ve talked about the importance of getting your project needs and requirements written down so they’re set in stone. But how? It’ll be no surprise that we’re not a fan of the old-fashioned paper and pen method. Honestly, spreadsheets can be pretty cumbersome, too, particularly as your projects and business scale.

In most cases, project management software is a strong option, particularly as many have a free version. As you prioritize different software requirements, look for a platform that offers:

• Customizable requirements gathering templates
• Real-time traceability
• A positive user experience

Anticipating change

Often, a project’s technical requirements won’t be static, and you’ll need to anticipate change throughout the process. To prevent future change requests from derailing your budget or timeline, include these three things in your initial SoW:

• A clear definition of what falls within the project scope
• An explanation of how changes will be addressed (e.g., additional costs)
• An agreement that stakeholders accept any changes in terms before they’re acted upon

Gathering project requirements is a skill to hone

Collecting different types of requirements, documenting them, and weaving them into your project plan is crucial to its success. It keeps the project scope in line, satisfies stakeholders, and allows you to stay comfortably within budget and deadline.

Sure, the collect requirements process in project management may feel a little daunting at first — but it’s a skill you can hone using the methodology above.

Need extra tips? Check out our blogs on project cost estimating and project time estimation.