Requirements Management
May 7, 2018

Requirements Management: The Foundation for Project Success


For most of my life, I dreamed of being an architect. I'm a creative to the core and in high school, I loved my art, drafting, AutoCAD, and architectural drawing classes. But I was really only interested in the drawing and design part of it. In reality, there were many things I never considered about architecture like how much math was going to be involved and all of the logistics. I had never thought a thing about the necessity of designing solid foundations for the structures I was designing which is basically construction 101. In order to build a sturdy structure, you have to start with a strong foundation.

The same principle applies to any work or project management. In order to create a successful project and deliver a quality product, you have to start by building your project plan on a firm foundation. That foundation is created by gathering project requirements. Too many project managers either overlook the importance of requirements management or fail to understand the difference between scope, requirements, and expectations. In fact, 60-80 percent of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group, now a part of Gartner). G. Chandrashekar of the ProjectSmart blog wrote,

"Innumerable studies have shown that requirements gathering is the single most important step…It's far more expensive to fix a requirements error than a coding error. But somehow everyone seems to believe that a requirements specification document is the easiest part to produce…It can't be further from the truth. No one ever built a good structure without the right foundation. Make sure that you take time to gather the requirements fully and analyse them in depth."** If you're interested in helping your projects succeed, here are five important things about requirements management you should know:

1. Gathering requirements comes first, defining scope comes second.

It is fairly common in the project management world for people to use the terms "requirements" and "scope" synonymously. But they are different. Requirements are the demands, needs, and specifications for a product as outlined by project stakeholders. The Deep Fried Brain Blog defines requirements as what the customer needs. Requirements can also be many types. They can be product related requirements, performance requirements, quality requirements, project management requirements, etc.

For example, if the requested product is a house, stakeholders may require that the finished product includes four bedrooms, two and a half bathrooms, two stories, white walls, and an island in the kitchen. Requirements can also include specific budgets and timelines—any demand that is definable and considered an "absolute must."

After all the stakeholder's requirements have been collected and clarified you can start to define the scope. The scope sets the boundaries, or constraints, for the product. For example, you may need to build a house with four bedrooms and two stories, but because of the size of the plot of land, you have to do it without exceeding a scope of 1500 square feet of built-up area, or a budget of $200,000. It's important to gather and define all the stakeholder requirements first so you can make sure that the requirements are doable within the scope agreed upon. If building four bedrooms will cause you to exceed the scope, you will need to go back to your stakeholders and either try to redefine the requirements, or set new expectations: "Okay, we can do four bedrooms, but they are going to be 4 square feet smaller than you expected if we are to stay within scope. Will that work?"

2. There are two types of requirements: project requirements and product requirements.

Understand that as a project manager, you will be expected to manage your project requirements and your product requirements. The CDC Unified Process Practices Guide outlines the distinction like this:

  • Project Requirements define how the work will be managed. This includes the budget, communication management, resource management, quality assurance, risk management, and scope management. Project requirements focus on who, when, where, and how something gets done. Project requirements are generally documented in the Project Management Plan.
  • Product Requirements include high-level features or capabilities that the business team has committed to delivering to a customer. Product requirements do not specify how the features or the capabilities will be designed.

3. Make sure you adequately document all the requirements.

This is another common mistake among project managers that can have catastrophic results. When you have your initial kick-off meeting to gather requirements, make sure that you document everything and keep it in a central location. Whenever you have a status meeting, refer back to the documented requirements to remind stakeholders of the original agreements. This way, if they think of additional requirements or accuse you of missing a requirement mid-project, you can point to your documentation and have a discussion from there about what implementing this new requirement will entail and how it will affect outcomes, scope, etc.

As Chandrashekar puts it,

"During the requirements gathering you get a huge amount of data, often in disparate forms. Word documents, spreadsheets, PowerPoint presentations, image files. The list is endless. Document, index and retain every bit of information you come across using a good software tool. Ask everyone in the project to document everything in a centralised database, not on their desktops."

4. Ask for as much detail as possible.

Remember, detail is your best friend when it comes to gathering requirements. Often, if project managers do not "dig deep" and ask lots of questions to clarify the details of a requirement, they end up with misunderstandings. The problem is, different people can interpret different requirements in different ways. The more questions you ask and the more specific you get, the better off you'll be. Chandrashekar explains that everyone will interpret it based on their own knowledge and experience and that there's no way to ensure against getting the interpretation wrong. Getting the big picture right is important but so are the minute details. For example, if a stakeholder requires that the house has white walls, make sure to ask if that means all of the walls or only some of the walls. Also, clarify if they have a specific brand of paint they require. Ask if they want bright white or eggshell. These details may seem tedious and even silly, but asking specific questions and getting as detailed as possible will help you to meet your stakeholder's requirements and their expectations.

5. Sometimes, stakeholders will have expectations that conflict with the requirements.

Finally, keep in mind that, when somebody requests a product from you, they may trust you to get it done, but they still have their own idea of how they want the completed product to look, act, feel, perform, etc. This is another reason it's important for you to get as many details as you can when gathering requirements—because it helps you understand the stakeholder's expectations that they may not have even known they had. It's common during the process of a project to discover new expectations that don't align with the originally documented requirements. For example, a stakeholder could say something like, "Oh I thought this room was going to have vaulted ceilings." Though they are disappointed because they had that expectation, you can politely direct them back to the original requirements and reply, "That wouldn't work because so-and-so required this house to be two stories." If you always have specific requirements that are well documented and you communicate regularly, you will either be able to reset their expectations or find a way to incorporate their expectations—when it doesn't cause you to exceed budget or move outside of the project scope.

If you're able to remember these five things when managing requirements, you will be better able to create project foundations on which you can build solid products and have more successful project outcomes.

CLICK HERE for more information on software that can help you manage project requirements in a central location.


Get Workfront blog updates straight to your inbox.