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

    2=Planning

  •  Minute Read

There are numerous reasons that projects may fail, and one of the top reasons is poor requirements.  We can overcome many of the causal factors and deliver greater value. In this article, let's explore five things to start and five things to stop in requirements management.

5 Things to Start

  1. Identify and engage appropriate stakeholders. Project managers who work in a matrix environment should seek resource approval from stakeholder 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. Ask if a requirement is in the scope of the project. For future consideration, the project manager may wish to capture out-of-scope requirements in a parking lot. Check with the Project Management Office (PMO) or other authorities on how to handle these requirements.
  4. Analyze requirements using context diagrams, use cases, stories, and other tools and techniques. Project managers or business analysts who use different tools help the stakeholders see things from various perspectives.
  5. When requirements change, be sure to update the requirements with version control. Ideally, the project manager should be able to see the versions of each requirement, from the initial requirement to the current version. Many requirements tools provide this capability.

More...

5 Things to Stop

  1. Overanalyzing requirements (analysis paralysis). Project managers and business analysts must use discernment. At some point, you must move on.
  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.

Have You Thought of Becoming a Business Analyst?

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 several certifications, including 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 identify better, evaluate, and manage project requirements.

Project Risk Coach Tips

Sign up for the weekly Project Risk Coach blog posts and receive the Project Management Plan Checklist. This will allow you to deliver projects with fewer problems and greater value.

"Intelligent leadership, creative communication and depth of technical skill all describe Harry Hall." –John Bartuska, Director of HR–ONUG Communications

Powered by ConvertKit

You may also like

What is a RAID Log?

What is a RAID Log?
>