The Community Blog for Business Analysts

Praveen Udupa
Praveen Udupa

All requirements are important!

I was running a meeting with a few stakeholders. I was imploring them to indicate the relative importance of requirements, but was hitting a brick wall; they kept insisting, "They all look the same to me. All requirements are important. They all are must-haves."

I tried to reason with them multiple times over. There are just too many requirements, and cannot possibly implement all of them in the available time and/or budget. But they kept insisting that all requirements were indeed important.

I thought to myself, “Why are these people being so difficult? Why are they deliberately feigning ignorance?” I literally felt like tearing my hair out!

Have you been in this situation? I bet you have. Why is prioritization such a hard exercise? There must be a better way, right?

Let's rewind a little bit and review how we usually begin a Requirements Prioritization meeting: "Thanks for accepting this meeting. The purpose of this meeting is to prioritize the requirements. We are going to use the MoSCoW technique. Let us walk through each of the requirements and collectively decide whether this is a M, S, C or W."

Sounds familiar? If not exactly as stated above, it could be some flavor of the above. Instead of M, S, C or W, it could be some other rating mechanism. But, for the most part, the spirit is essentially the same.

My hypothesis is that, with the above expectations, stakeholders truly are not able to differentiate relative importance among requirements. They aren’t being difficult at all; they honestly cannot prioritize. Let me give you an analogy:

Imagine being in a corporate conference room. What can you find in there? Whiteboard, video con equipment, large table, uniform looking black chairs around the table, etc.

Suppose I ask you to arrange the chairs around the table in the decreasing order of blackness, what would you say to me? I imagine you would say, “They all look the same to me.” Exactly the way requirements appear to the stakeholders – all the same.

Suppose I give you a pair of glasses. Not any ordinary pair of glasses, but one that has spectrograph capability, and a display on the top right corner. When you wear this glass, and look at any object, a graph of various colors on the object along with their intensity represented numerically is displayed. Now would you be able to do arrange the chairs in their decreasing order of blackness? Sure you would!

Few questions to ponder over:

  1. You weren’t initially able to arrange the chairs in their decreasing degree of blackness. Is that your fault? Does it indicate your weakness? Or does it point towards my weakness of not knowing how to enable you to do that activity?
  2. Is it the stakeholders’ fault that they aren’t able to prioritize the requirements? Or is it my drawback as a BA that I wasn’t able to get them to “see” the relative importance among requirements?

Think it over. I would love to hear your comments. Let’s talk and engage in a productive discussion.

Meanwhile, in my next blog, I will write about the various glasses that you can provide to your stakeholders to get them to truly see the relative importance among requirements.

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

Related Articles


Reidmanchester posted on Wednesday, June 15, 2016 3:50 PM
Praveen what a shift in perspective your article has provided! Thank you!. Now the question is, what can I give that helps the stakeholders differentiate the requirements? perhaps categorizing the features?
a) time savers, b) convenience features, c) compliance features, d) marketing features....
Karl Wiegers posted on Monday, June 20, 2016 9:27 PM
One problem is that participants in prioritization do not share an understanding of what M, S, C, W or High, Medium, Low or any other priority classification actually mean. So begin by providing some clear definitions.

I look at it in terms of not just perceived importance but the two dimensions of importance (how much does this capability contribute to the business success of the project") and urgency (how quickly must this capability be delivered?).

High-priority requirements are both important and urgent: they MUST be included in the next release or iteration or you cannot ship that release. Medium-priority requirements are important to success but not urgent; they can wait for a later release. Low-priority requirements are neither important nor urgent. Sure, they'd be nice to have, but in terms of contributing to business success they can wait longer, perhaps forever.

If you make these definitions clear, and emphasize that if the next release could go out without a specific requirement then that requirement is NOT high priority, then maybe not everything will become high priority in the customer's mind.
Karl Wiegers
Praveen Udupa posted on Tuesday, June 21, 2016 12:32 AM
@ Reidmanchester...please have a look at the two blogs after this: "Glasses for Priority" and "Step into Right Priority". In these two blogs I explain a few best practices that one can use to overcome the obstacles discussed in this blog.
Praveen Udupa
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