Five Things to Start and Five Things to Stop in Requirements Management

Photo courtesy of

Photo courtesy of

Some time back, I wrote an article entitled “Why PMs Need BAs for Project Success.” I highlighted three of the biggest factors that lead to failed or challenged projects, according to the Standish Group:

  1. Lack of user input
  2. Incomplete requirements
  3. Changing requirements

The Pareto Principal says that 80% of the project problems come from 20% of the causal factors. If these three factors are primary, project managers will be wise to address them.

Let’s look at a few things to start and stop in order to improve the chance for project success.

5 Things to Start

  1. Identify and engage appropriate stakeholders. Project managers who work in a matrix environment should seek resource approval from stakeholder’s managers early in the project.

  2. Ensure the requested software features will be used. Inquire (politely) why the features are needed. How does the requirement align with the goals of the project? The results of one Standish Group indicated that 45% of product features were never used.

  3. If questionable, ask if a requirement is in the scope of the project. The project manager may wish to capture out-of-scope requirements in a parking lot for future consideration. Check with the Project Management Office (PMO) or other authority on how to handle these requirements.

  4. Analyze requirements using multiple views (context diagram, use cases, stories, etc.). Project managers or business analysts who use different tools enrich the perspective and view of the stakeholders.

  5. When requirements change, be sure to update the requirements under version control. Ideally, the project manager should be able to see the versions of the requirement from the initial version to the current version. Many of the requirement tools today provide this capability.

5 Things to Stop

  1. Over analyzing requirements (analysis paralysis). PMs and BAs must use discernment, but at some point, the PM or BA must press on to the next steps.

  2. Storing requirements information in more than one location. Some project managers make the mistake of capturing requirements in different places such as emails, spreadsheets, notes, and meeting minutes. Determine early in the project the one location for all requirements.

  3. Writing vague, ambiguous requirements. Be specific. Determine if the tester can test the requirement.

  4. Diving too deep into the design while defining requirements.

  5. Using a word processing program for storing requirements. Check with the PMO or other authority to determine if the company has adopted a standard requirements management tool. If not, the project manager may wish to work with stakeholders to select a tool.

Business Analyst Credentials

More organizations are recognizing the value of improving the requirements process through business analysis. Both IIBA and PMI offer business analysis certifications.

The International Institute of Business Analysis (IIBA) has two certifications: 1) Certification of Competency in Business AnalysisTM(CCBA®) Designation and 2) Certified Business Analysis ProfessionalTM (CBAP®) Designation.

The Project Management Institute (PMI) has added the PMI-Professional in Business Analysis(PBA) Designation to its family of certifications. This certification prepares project managers to better identify, evaluate, and management project requirements.

According to PMI, “The number of business analysis jobs is predicted to increase 19 percent by 2022, according to the U.S. Bureau of Labor Statistics. This research indicates a growing need for professionals skilled in effective requirements management.”

Question: What else would you add to the Start and Stop lists?


Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *