Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  THE ART (OR SCIENCE?) OF PRIORITIZING REQUIREMENTS RIGHT
Previous Previous
Next Next
New Post 8/20/2018 8:20 AM
User is offline Srilatha
1 posts
No Ranking

  1. Get all involved in a room to discuss each participant’s reasons for priorities so that they are all heard.
  2. Don’t try to prioritize all requirements in one sitting.
  3. Try to get numerical priority (especially for high priority items) instead of general high, medium, low categories.
  4. Buy A Feature (Assign a value to each feature and give stakeholders a fixed amount of fake cash that they may use to “purchase” the features they most desire.)
  5. First In, First Out
  6. Prioritize by considering Cost of Delay
  7. Company Drivers/Department Drivers – Know the priority of each driver and based on that, prioritize the requirements.
  8. MoSCoW approach – must have, should have, could have, won’t have
  9. Determine if multiple requirements are addressing the same problem to reduce potential duplicates or conflicting requirements first.
  10. Agree on a Ranking/Rating System and define the rank values (High, Medium, Low; What do they mean?)
  11. Refer to the project objectives to identify high priority requirements. If a requirement does not help achieve an objective determine whether the requirement is out of scope or an objective was missed.
  12. Determine high priority requirements by asking “If you could only have x items in your solution which would you choose?”
  13. Priority Pyramid – Force the group to determine the most important feature or requirement for the top box. Next select the next 2 most important items for row 2.
    Continue expanding by one feature for each row until the pyramid is built. The top 2 or 3 rows would be the highest priority.
  14. Realize that priorities will change over time, even on short projects. Constantly revisit
    priorities to ensure validity
New Post 8/1/2019 3:31 AM
User is offline Stewart F
69 posts
8th Level Poster


Hi there,

I know this post is nearly a year old, but I read it and was rather perplexed by what it is actually trying to say. It seems to be a data dump for every way to prioritise requirements, as opposed to a step by step way to carry out the task.

For example, point 4 and 12 are one and the same, and the rest are variations on the same theme (i.e. they carry out the same task, but are just different ways of doing it). 

I would also say that 25 years experience as a Senior BA and now BA Manager tells me that step 1 is prone to failure. Depending on how large your project is, you could have 5 to 10 different senior personnel in the room. They will NOT want to be sat in a meeting room, probably for 3 to 4 hours, listening to everyone else's priorities. They have better things to do and will not spare the time. 

The biggest problem with prioritising requirements, and therefore the reason most of these may well fail, is that every stakeholder thinks their requirement is the most important. It certainly is for them and in the Dog Eat Dog world of business, they wont care about anyone else's priorities. 

By all means collate all the priorities but you are better off carrying out this task with your Senior Developer, Project Manager and Project Sponsor. The Dev will tell you a rough estimate to effort building it (assuming the project is technical - if it isn't then replace the Senior Dev with the person who is in charge of the area you are making the Change, for example the Operations Manager), the Project Manager and Project Sponsor who both have a handle on the political stance (what is crucial to the Business to get in first). Then look at impact - what is the Business Driver for the project, is it a new corporate Website? In which case, building the website would need to come AFTER you have agreed its contents. Equally though, could the developers start building the framework for the site? This is where your Dev comes in - he or she will be able to tell you the order the technical build requirements should come in and therefore their priority.

Most of the rest of the requirements priorities then fall into common sense and an agreed project scope. Is there a Phase One and Phase Two? In which case, can all the Phase Two stuff wait or does it NEED to be started early? If it doesn't - it waits. Common sense will tell you that you may well want a new Insurance Product, but if you haven't priced it up yet, what's the point of trying to sell it?

If you are left over with any other requirements that have similar priorities, then by all means get their owners together, but you don't need everyone in that room.  It wouldn't be the first time when I have told two Stakeholders that they aren't leaving the room until they have agreed a priority order between them. The best way is often the most honest way. Explain that you need to knw which needs to come first - let the two stakeholders argue this out between them and then get them to come back and tell you which is higher. Often, if you treat Stakeholders as adults, they will sort it out themselves. They just need to be guided every so often.

Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  THE ART (OR SCIENCE?) OF PRIORITIZING REQUIREMENTS RIGHT

Community Blog - Latest Posts

IT companies are rapidly looking or adapting modern methodologies, so the business analyst role is increasing day by day. Offline is shifting to online, and this is why today, companies can easily garner important data in any aspect. But, data itself has no meaning hence, organizations look for a business analyst who can analyze the data and draw a...
0 Responses
Analytics is the future of the business industry. Businesses and organizations today run on data and its interpretation. Its correct evaluation is the fundamental key to success. And business analysts are the guides to it. It is a very prosperous industry and has a lot of potential for talented people. To even qualify, you require more than just...
2 Responses
With the advent of modern-day cloud infrastructure, many business-critical applications like databases, ERPs, Marketing applications have all moved to the cloud. With this, most of the business-critical data now reside in the cloud. Now that all the business data resides on the cloud, companies need a data warehouse that can seamlessly store the da...
0 Responses

Upcoming Live Webinars

Latest Articles

How Will It Work? The Future How Viewpoint...
Dec 08, 2019
The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, ...
Copyright 2006-2019 by Modern Analyst Media LLC