Additional Ways to Prioritize Requirements

Share This Post

On our projects we are often asked to provide our requirements to the development teams with business prioritization.  I’ve been in meetings with my business stakeholders where we  have sat in front of a list of requirements and attempted to prioritize them one by one.  In my experience, this effort ended up prioritizing the list based on the stakeholders “gut feel” of the requirements, due to political clout, or just people being more demanding than others.  Using this gut feel method does not ensure that the critical requirements actually make it “above the line” for project development.

After a period of time I realized that these prioritization discussions were repeatedly following the same path.  I wanted to be able to break some of the stalemates, and by providing some additional criteria to be used in these prioritization reviews.

I came across an article called “Requirements Prioritization” on the website.  To summarize, the article lists out several options for requirement prioritization.  Of course included in that list was the stakeholder agreement model, which I mentioned above but included other alternatives for helping with prioritization.

Value, Cost and Risk
Prioritize based on business benefit or cost savings for implementing the requirement.  This is a great way to get people re-focused on the “quick wins” for an organization.  By focusing on business value you depersonalize the discussion. The challenge is that business stakeholders may not have had the time to do an in depth analysis, or the background to feel comfortable with this model.   This model works extremely well with executives who are focused on these business analytics.

Regulatory Compliance
Requirements that are needed to pass a legal and or regulator agency should be given the same priority an organization has to meeting those requirements.  I’ve been in several discussions where just because a requirement met a condition for a regulatory compliance issue that alone pushed it to the top of the list.

Difficulty of Implementation and Likelihood of Success
These two criteria go somewhat hand in hand.  These methods allow the easy “wins” to be prioritized and for the project to gain some critical success and key visibility before deep diving into more difficult development areas.   This approach would enable stakeholders to become more familiar with early project results and provide critical feedback before going forward to build more difficult and possibly more expensive aspects.

Since reading this article, I’ve attempted to incorporate these other viewpoints into my requirements prioritization sessions with good success.  I have found that by using these different perspectives on when prioritizing the requirements can help break stalemates, and end political arguments.

More To Explore

Email in toolbar

Getting More out of Transactional Emails

Are you taking advantage of all of the opportunities to promote your brand? Emails are great way to interact with your customers, and both marketing and transactional emails can be

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.