How big of a deal are project requirements?
The Project Management Institute says, “47% of unsuccessful projects fail to meet goals due to poor requirements management.” –Requirements Management, A Core Competency for Project and Program Success
In his book — Just Enough Requirements Management — Alan Davis shares, “Various studies suggest that errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product.”
Stakeholders hear the term “requirements” but interpret the meaning in different ways. Before we can manage anything, it’s critical that we have a working definition.
The Project Management Body of Knowledge defines requirement as “a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.”
Karl Wiegers — author of Software Requirements — shared this definition: “Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute.”
Part of the confusion concerning requirements is that there are different types. The PMBOK 6th Edition classifies requirements as follows:
Be sure to include the definitions you use in your requirements management plan.
Imagine that you’ve contracted with a general contractor to build your dream house. You’ve been thinking about this house for years. As you have visited friends, you’ve made notes about what you like (and don’t like) about their homes. Perhaps you have a Pinterest page where you’ve saved your favorite pictures.
So, you have your first meeting with the general contractor to discuss the requirements for your house. The contractor walks you through a checklist, explains your options and pricing. You specify the size of the house, the type of construction, the number of rooms, the types of systems, and the features of the home. You leave nothing to chance.
A week later, the contractor walks you through an interactive computer model of the home. You progressively refine your requirements. After a few more meetings, the contractor understands your needs. Guess what! The contractor has a much higher chance of meeting your expectations.
When requirements are vague, projects are at risk of not delivering what is needed. At a minimum, missed requirements result in rework. There will likely be adverse impacts to the schedule and to the budget. And your customers, as well as your team members, will not be happy!
How do we develop requirements?
When requirements change, I see project managers point their finger and say, “the users never know what they want.” While there may be some truth to this, I have always held the position that the requirements analyst — whether a project manager, business analyst or business lead — is largely the problem. Why?
A good analyst knows how to elicit—to draw out—and validate requirements. I have made an observation after hundreds of projects: The projects with a skilled requirements analyst have fewer requirement-related issues. If you are a project manager and you don’t have the time or the requirement development skills, make sure you secure a skilled requirements analyst; otherwise, you are asking for problems.
Here are some elicitation tools and techniques:
The word “analyze” means to break down or examine in detail the constitution or structure of something. For software projects, we break the requirements into greater detail as we move from business requirements to user requirements and further into the detailed system requirements. Once we’ve determined the details, we can synthesize the components together to meet the higher level needs.
Practically speaking, how do we analyze requirements? One of the most powerful ways is to build prototypes or create diagrams; it doesn’t have to be complicated. When users see things, they can respond with what they like and don’t like.
Another tool for analysis is a context diagram that visually depicts a product such as a building, process, or software application and how actors (individuals, groups, or other systems) interact with it. We can see the things that flow in and out of the process and who receives the outputs.
Some organizations prioritize requirements during the analysis. Which features and functions provide the greatest benefit? Which ones may cause the greatest risk? In agile projects, we can rank order the user stories in the product backlog.
In recent years, there has been a move to lighter requirements documentation and more collaboration, particularly for agile projects. There are benefits to documenting. As we document, we think and we analyze. It is also helpful to have a light version of documentation for reference as people extend the features and functions in future projects.
Business requirements are typically defined as goals in the project charter. User requirements are often captured in a use case or user story format. The detailed software requirements are often documented and captured in a requirements management tool.
Finally, we talk about requirements validation, how to ensure that the project requirements are correct, free of defects/bugs, and meets the needs of the users. Conduct validation meetings to review the requirements with a cross-functional team such as the BAs, developers, and testers.
Once the team has reached agreement on the requirements, baseline the requirements with the appropriate sign off process.
As you’ve read this article, you may have thought—this is a lot of stuff! Yes, it is. As with all project management processes, scale the requirements management processes to meet the needs of each project. Early in your project, think about your approach to requirements and create a simple requirements management plan:
Sign up for blog updates and receive the Project Management Plan Checklist. Make sure that you are including the right project baselines, subsidiary plans, and ancillary plans in your project management plans.
Join 1,000 project managers today!