We throw around the word requirements during different stages of an IT project, assuming that the team is on the same page on what requirements are. But let’s pause for a moment and think: Have we ever walked IT and business stakeholders through a quick definition of what this word means in the organization?
When stakeholders talk about requirements they are usually focusing on the “set” of requirements that is most relevant to them, and unwittingly, their conflicting priorities can lead to waste in misunderstandings, or even errors in tactical decision making.
For example, if you hear statements from your team such as we need an “agile business analyst” because there is not enough time to go through every single requirement, and we need to prioritize. Is the person talking referring to design requirements (specs) needed to build the solution? Or, are they talking about not having enough time to gather a requirements baseline that can be used to determine the gaps in the solution?
An Agile approach would definitely help the team on the former case, while the latter situation simply means the project is heading for trouble: if there is no gap analysis, there is no product backlog yet, so there is nothing to be Agile about.
In Leverforce we view requirements as 5 different sequential “sets” in a project. These sets are traceable to each predecessor, and they expand or contract as business analysis deliverables “check” through different project toll gates:
As project advances from charter to final product, we move from the blue spheres (problem domain) to the green ones (solution domain) and involvement and accountability of IT increases.
Thus, the statement set as an example earlier: “…there is not enough time to go through every single requirement, and we need to prioritize” would describe a very different situation for a project when the person talking is referring to set 2 in the problem domain, as opposed to sets 4 and 5 during software delivery.
Here is another way of looking at the same 5 sets of requirements:
I am adding a detailed description as a footnote to this article, but if you are comfortable and recognize these five sets of requirements in your own projects, let’s have a quick look at the implications to team dynamics and project success:
Different stakes on requirements: When software delivery teams talk about requirements, they usually are referring to the set of requirements that supports the product backlog (set 4) while business stakeholders are thinking of the larger (set 2) of User Requirements and Business Rules included in their requirements baseline.
Requirements for AGILE: An Agile Business Analyst would be an expert at defining requirements to support a product increment (set 5), based on the requirements that support the product backlog (set 4). Occasionally, AGILE business analysts would have to go back to Functional and Nonfunctional Gaps (set 3) as priorities are renegotiated, or to make sure product increments can be traced back to original value intended.
An AGILE BA might not be enough to save the project: If requirements did not go through the toll gates in sequence (perhaps the statement of work was not negotiated based on a gap analysis, or the gap analysis was not structured around a validated requirements baseline) then the AGILE Business analyst will not be able to represent stakeholders or owners. Product or process owners will have to become available during the sprints (The original AGILE way)
This last scenario could be expensive for the business and a project blocker, especially if we are talking enterprise software and stakeholders are scattered geographically.
By Larry Velarde, CBAP®
