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 www.requirements.com 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.