In my previous blog post titled "All requirements are important!",
- I reasoned that stakeholders only appear to be uncooperative in the prioritization process. In reality, they are unable to prioritize requirements because they cannot see one requirement more or less important than the other.
- I urged you to ponder whether it could be due to BA's drawback that s/he is unable to get the stakeholders to really see priority among requirements.
In this post, let us consider a few 'glasses', which will enable the stakeholders to see the relative importance among requirements. Here you go:
Glass #1: Business Value
Business Value is viewed in terms of faster, better and cheaper. Wearing the Business Value glasses, the stakeholders determine the degree to which one requirement contributes to the business to become faster and/or better and/or cheaper relative to the other requirements. Higher the business value offered by a requirement, higher its priority. Typically, business stakeholders weigh in on determining the Business Value of requirements.
Glass #2: Business Risk
Business Risk is viewed in terms of what can go wrong in the business. This must not be confused with what can go wrong to the system (that is implementation difficulty or technical risk). For e.g. introducing an interface between two systems will lead to a bunch of data entry operators losing their jobs. This is a risk although its impact depends on the risk appetite of the organization.
Wearing the Business Risk glasses, the stakeholders determine the degree of risk that the business would face because of a requirement relative to the other requirements. In other words, if that requirement was dropped, then the risk to the business is reduced.
Applying the general principle of fail early, fail quick when the cost of failure is low, higher the business risk posed by a requirement, higher its priority. However, this depends on the organization's risk appetite. Some organizations may choose to do the opposite. Typically, business stakeholders weigh in on determining the Business Risk posed by requirements.
Glass #3: Technical Risk
Technical Risk is viewed in terms of what can technologically go wrong during the implementation of the solution. Wearing the Technical Risk glasses, stakeholders determine the degree of technological risk posed by a requirement relative to other requirements.
Again, based on the general principle of fail early, fail quick, higher the technical risk posed by a requirement, higher its priority regardless of the risk appetite of the organization. Typically, implementation stakeholders like architects, designers and developers weigh in on determining the Technical Risk posed by requirements
Glass #4: Implementation Difficulty
Implementation difficulty is used when demonstrating quick success is important. In such situations, implementation stakeholders determine those requirements that are easiest to implement relative to other requirements. Lower the implementation difficulty of a requirement, higher its priority
Glass #5: Minimum Viable Product (MVP)
MVP is used to determine those requirements without which the product would simply be incomplete. You wouldn't purchase a car without breaks or mirrors for instance, would you? But you might consider buying the car without, for instance, automatic windows.
Thus MVP Requirements must have higher priority over other requirements. In this context, requirements that cater to a regulation must be a part of MVP.
Glass #6: Dependent Requirements
A requirement that by itself may not be treated as high priority, but if other high priority requirements are dependent on this requirement, then it is also provided high priority.
The above are some of the key glasses that can help stakeholders get over their "all requirements are important" syndrome and truly participate in the prioritization exercise. By the way, I am sure you realize that I only use the term "glasses" to extend the analogy from my previous blog. The proper term for glasses is "Prioritization Criterion or Parameter"
Are these the only glasses/parameters that you must use? No, absolutely not. In fact, some of the above parameters may not even apply in your project situation. You may find it necessary to use entirely different set of parameters. As a BA, you must first collaborate with the stakeholders must arrive at a set of prioritization parameters that are relevant to your specific project situation.
In my next blog, I will write a detailed note on the best practice process for requirements prioritization. Till then, I would love to read and respond to your comments...keep them coming!