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 7: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 2:31 AM
User is offline Stewart F
119 posts
7th 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

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Architecture and AI In our recent conversation with Joseph Edward, we explored the transformative power of business architecture (BA) and technology as tools for uplifting communities. Joseph, with his rich background spanning from education to IT leadership, shared...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - The AI Business Analyst I recently had an engaging discussion with Maria Becerra, a passionate advocate for AI and an accomplished business analyst, on the AI Business Analyst. Maria is a respected name in strategy, business analysis and AI. Her path from Colombia to Canada ...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Analysis. I'm happy to share insights from my recent conversation with Kingsley T. Ihejirika, PhD, an ICT Business Analyst at the Ministry of Justice in New Zealand. Kingsley's unique blend of academic theory and practical expertise sheds light on the path t...



Copyright 2006-2024 by Modern Analyst Media LLC