Managing several project managers at various levels of project management maturity and a few business analysts that have specific domain knowledge but not the broad business knowledge, one thing that I often find struggling is for the project managers and business analysts to work with their clients in understanding the gaps in the requirements. Requirements Management is not the same as Scope Management. The latter is clearer than the former and needs one to wear the critical thinking to see the strategic value, organizational benefit, etc.
Whether one is responsible for the project, program, portfolio, or product management, starting with the “why” behind the strategic value and benefits framework is very much needed. The field of systems thinking truly helps here. Some of the foundational systems thinking questions that you can combine with the “Five-Why” approach are listed here. Getting the answers to these questions from your own research or from stakeholders will ensure that you have good requirements, to begin with.
• Where
are you today?
• Where
do you want to go?
• Why
do you want to be there?
• What
are you willing to prove by going there?
• What
are you willing to give up getting there?
• How
do you know you have reached?
So, depending upon the scope of our initiative, short-term or long-term, project, program, or portfolio level work, the type of requirements evolves from high-level to low-level continuously. Therefore, the requirements have a lifecycle. The practice standard for requirements management also emphasizes this by coming up with six stages.
- These start from the Needs Assessment.
- Then, we move to the operating structure and governance framework within which the requirements are managed.
- Then, we move to the process of eliciting requirements through document analysis, interviewing, observations, market research, brainstorming, focus studies, and so on.
- As we gather the requirements, we analyze them for the value they would add. A simple measure to evaluate is the return on investment – In other words, does the time and money invested in addressing that requirement add value?
- Then, we monitor the changes to the requirement through the voice of the customer and voice of business as we iterate through the changes.
- Finally, we evaluate the solution delivered as the product moves through its lifecycle.
While these concepts are easy to understand, they are also difficult to implement. A simpler approach to apply this thinking was required. So, I came up with an approach where people can question whether any requirement from the client can be validated. I called this technique "CURTAIN", and it stands as follows:
- Concise: State actionable information without any unnecessary information
- Unambiguous: There should not be more than one way to interpret the same information
- Realistic: Deliverable within the constraints of scope, schedule, cost, quality, and available resources
- Testable: Requirements should withstand a “pass” or “fail” criterion
- Atomic: Every requirement should be unique
- Independent: Understanding the requirement shouldn’t depend on another requirement
- Necessary: Removing the requirement should affect the system/product
