Everything You Need to Know About Gathering Project Requirements

Project objectives are high-level business goals that contribute to an organization’s vision, while project requirements are specific actions necessary to complete a project.

For example, a project objective may be to build a roadway that reduces commute time into the city, while a project requirement is that the roadway must have three lanes in each direction.

To create a project requirements management plan, you’ll need to define three key elements: the project scope, the methodology or process, and the execution plan. 

According to A Guide to the Project Management Book of Knowledge (PMBOK® Guide), the project requirements management plan is “a central document that defines the basis of all project work. The project management plan defines how the project is executed, monitored, controlled, and closed. The project management plan’s content varies depending upon the application area and complexity of the project. It is developed through a series of integrated processes extending through project closure.”

Requirements management is essential to project success. First, you define the project scope, which drives the rest of the requirements management plan. The scope provides critical information that informs all requirements necessary to complete the project and helps avoid scope creep.

“You must make certain expectations are outlined,” says Ben Timmerman, Vice President of Software Engineering at The Brookfield Group. “We prefer to template our requirements and set standards around what is expected to be included in every task. Then we break down our requirements into both functional and technical requirements. Functional requirements define the functions and purposes behind the components of the work being completed. The technical requirements outline the specific data requests and calls needed via an API.”

The project requirements management plan will note stakeholders, a definition of the requirements, who will manage the requirements, how you will track each requirement, and what you will do to manage change. 

“We want to use processes and practices aligned to the type of project and organization,” says Zucker. “Managing requirements for constructing an office building, road, or sewage treatment plant will differ from a software project. And for software projects, life-critical applications will have different needs than a tool used by a few dozen people.”

Gathering project requirements is one step in the requirements management process and typically takes place at project onset. To gather requirements, talk with stakeholders, document all observations, and review the project as a team. 

These seven research techniques will help you identify and gather project requirements following project initiation:

1. Brainstorm: Perform internal and external research to gather as many ideas as possible to create a preliminary requirements list. This will arm you with questions when meeting with stakeholders.
2. Take Inputs from the Project Charter: The project charter describes your project’s roadmap. Be sure to review this document so that your requirements remain in scope and aligned with objectives. “Requirements are the foundation for defining what is in and out of scope for the project and the technical details,” says Zucker. 
3. Interview Stakeholders: Ask clarifying questions to identify your stakeholders’ critical features or functionality. Talk to multiple people, as you may find that the stakeholders you initially talk to are not the decision-makers.
4. Send Questionnaires: Ask stakeholders to answer a series of questions about the project needs. Doing so ensures everyone has an opportunity to submit their project requirements and that they start thinking about the project.
5. Perform a Gap Analysis: Perform a gap analysis that compares the current state with the desired future state. This will help you identify areas of improvement that you can include in the project requirements.
6. Observe End-Users: Watch end-users and stakeholders in action to gain insight into behaviors and preferences that you might not get from talking alone.
7. Review Requirements with Stakeholders: Review all project requirements with the stakeholders before finalizing them. This ensures everyone is on the same page and comfortable with the project’s direction.

Document requirements in a readable, sharable format that is accessible to all project team members and stakeholders, so you can refer to requirements throughout the project. The format varies, but a shared spreadsheet is easy and common.

The project requirements document (PRD) consolidates all final requirements in a clear, concise manner. This ensures all team members and stakeholders are on the same page.

Without project requirement documentation, there is no record of what needs to be done to successfully complete a project. The PRD ensures all team members are on the same page. 

According to Info-Tech Research Group, “up to 50 percent of project rework is attributable to problems with requirements. Of projects that fail, 70 percent fail due to poor requirements.” Mishandling requirements is a surefire way to set a project up for failure. Therefore, incorporating your requirements management efforts early in the project planning will improve the project success rate. 

“If requirements are not documented, there is no clarity around expectations, and the likelihood of a successful project is low,” says Zucker. “Imagine asking a contractor to build a house without documenting the requirements.”

Below are additional benefits that result from documenting project requirements:

• Clearer Project Expectations: Straightforward, concise project requirements ensure that all team members and stakeholders know what to expect from the project. 
• Improved Alignment and Communication Across Teams: By identifying project requirements, you’ll open lines of communication across the business, building awareness and visibility into the project vision and objectives. 
• Stronger Project Completion Criteria: The project requirements can establish traceability of what is complete, by whom, and when, which functions as a checklist for project completion. 

“Documenting project requirements is ultimately a problem prevention practice,” shares Timmerman. “In the development world it’s best to be completely transparent. We document the requirements and we receive sign-off, and there is a mutual understanding of what work will be completed and in what timeframe. Documenting requirements is also a good practice for the development team. All team members should be able to pick up a task, understand the requirements, and implement the necessary code changes.”