Join Haydn Thomas for an in-depth discussion in this video Understanding the requirements pyramid, part of Business Analysis Foundations.
- When admiring an Egyptian pyramid from afar, you can see it in all its glory. When standing at the base and looking up, it's difficult to see the top of the pyramid. The sheer size of the base is overwhelming and you get to appreciate that effort and activity that was needed to build the pyramid. Though the best view of the pyramid is when you're standing on top. Now imagine your project is a pyramid. You have four layers. At the top of your pyramid is your project need. That need is supported by your requirements. These top two layers describe the high-level problem and opportunity domain of your project and focus on what is needed.
The bottom two layers represent the solution domain, and they help define the low-level How. The bottom half of the pyramid supports the top two layers with specifications and designs and then execution of the specifications. Both bottom layers typically absorb the bulk of the project time and resources needed to deliver against the problem/opportunity domain. Too many stakeholders can only ever see the bottom half and focus on the solution domain. It is a classic problem facing business analysts who are collecting project requirements.
When asking what is needed, the responses from stakeholders invariably describe the How. Many requirements collectors can overlook the value of this how input. Here is a way you can take this low-level how input and extract the most value from it as you create your requirements documentation, which is defining what you want the solution to do for you. When collecting requirements from stakeholders, use a flip chart or notebook with two columns, one marked What and the other marked How. When stakeholders start sharing their requirements as a how, place that in the How column.
To determine the What they need, ask questions like, "What would you want that tool "to do if it was available to you today?" Through this questioning, you're ascertaining the What behind the How. Sometimes the How reflects the essence of the way your stakeholder understands their requirement. Capturing it and asking further details not only validates the stakeholder's needs, but it gives you additional understanding as well. Although many business analysts are accustomed to flip-flopping between high-level and detailed requirements gathering, this approach can be effective with stakeholders that have a definitive How in mind, and discussion involving detail requirements is another way of extracting the What.
This approach can also develop an understanding of the way in which the stakeholder prefers or needs to work. From this, the requirements gatherer can extract the What that is needed to complete the project requirements documentation. Requirements gathering is a fine art. Successful requirements gathering is best performed by taking full advantage of all the input received from stakeholders, sorting the How from the What and investigating appropriately is an important means of validating the expressed requirements yet staying true to the business analysis objectives.
The more specific your requirements can be in the top two layers of the pyramid, the better chances they can be transformed into a specification. These specifications then inform the design, which are then executed against to create the project deliverables of what the stakeholder is really asking for in the first place and creating a lasting solution for others to admire.
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.