The Community Blog for Business Analysts

Praveen Udupa
Praveen Udupa

Glasses for Priority

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!

This entry was published on May 19, 2016 / Praveen Udupa. Posted in Requirements Analysis (BABOK KA) , Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  30 members liked this article


Ted posted on Wednesday, May 25, 2016 6:10 PM
Hi Praveen, Your glasses analogy is a good one. Seems like glass #1 is going to be the winner and it's rightfully so that you put it as #1. I can see a case where each of the following 5 (#'s 2-6) all play into how full you glass #1 could get. I'd be really interested if people have found cases where #1 would not win out in assessing prioritization.
Follow along with me as I write about data. Message me an "I'm in." and I'll add you.
Praveen Udupa posted on Wednesday, May 25, 2016 10:28 PM
Thanks for your input Ted.

I use "Glasses" here to mean spectacles (as opposed to something to drink from, which I suspect is how you might have interpreted it). If you read my previous blog, I introduce this term there.

Secondly, you are right...some stakeholders might just use Business Value spectacles, which is great. But it is highly recommended to view requirements priority from multiple perspectives to optimize their priority.
Praveen Udupa
Karl Wiegers posted on Tuesday, June 21, 2016 8:54 AM
Regarding Glass #1, I suggest that it would be more appropriate to assess the extent to which each requirement contributes to achieving the stated business objectives for the project. This is much more specific, focused, and measurable than the more vague "better, faster, cheaper". Thinking like this also reinforces the importance of each project clearly defining its business objectives, as all requirements -- and indeed all project work -- should align with achieving those desired outcomes.
Karl Wiegers
supriya posted on Monday, August 21, 2017 12:41 AM
Thank You
Very Useful Information to me
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC