Releasing requirements for specific iterations of a physical solution implementation by a devoted development team can be easy, hard or somewhere in between.  Most often, requirements and their release candidacy fall somewhere along a spectrum of very easy to implement to very hard or more difficult.  In a world of utopia it would be nice for us to say that X requirement is slated for release 1, that requirement Y is slated for release 2 and that requirement Z  is slated for release 3, and so on, without worry, frustration, concern or uncertainty.

In the real world, several factors contribute to a decision when a requirement is released.  And in that real world, slotting a requirement into a release is not as easy as 1-2-3, in most cases.

In the next few paragraphs, I hope to enlighten all business analysts with some of the factors that should be kept in mind when making a decision about releasing a requirement for the folks that will turn the requirement into an actual solution, the development team.

Some projects have a small amount of requirements; others have volumes of requirements.  The issues of time, money and quality all come into play when it comes time to make a decision about which requirements should be implemented first.  And there is an exercise that we can use as business analysts to help segment these requirements into workable blocks.

Before I get to this, I want to mention that I was re-introduced to the concept of requirements valuation and feasibility while I was studying for my certification as a SQL Server business intelligence specialist this past summer.  The simple concepts revisited during my certification course hit home for me and I hope that you can use this as part of your requirements management regime.

When we talk about requirements valuation with a business I would like to suggest that we initially refrain from talking about prioritization.  That exercise would come afterward.  What I would proffer is that we ask the business about their perception of value for a requirement in terms of how its implemented solution helps its business. 

For example, I am quite certain that a business would value a requirement about the availability of certain languages in a BI tool lower compared to a requirement about needing to know metrics about when a customer makes a purchase of a certain product in a certain region at a specific time of day.  The latter requirement would be rated a higher valuation to the business than the former.  We continue to issue a high, medium or low valuation for each requirement until all requirements are reviewed. I assume that dependent requirements are minimal (more on this shortly).

Once we have that task completed and approved by the executive sponsor of the project, we turn our attention to the solution development team and ask them about how difficult it would be to implement that solution.  Criteria to use here includes time and effort. The difficulty level (high, medium or low) applied to each requirement yields the feasibility factor. At this point the solution team should have all dependent requirements too in their possession to complete their assessment.

Next we draw a box with four quadrants. The top left quadrant buckets requirements with a high business valuation but low feasibility (harder to implement).  Call this quadrant A. The top right quadrant buckets requirements of high business value and low feasibility. Let’s call this quadrant B. The bottom left quadrant (C) groups requirements of lower business value and low feasibility.  Quadrant D, the last one, collects requirements of low value but high feasibility (easy to implement).

So what about priority?  To begin, work with the stakeholders on those requirements in quadrant B because these are the ones a business believes will bring high value to their business knowing that the solution developer has placed a high feasibility on its implementation (including dependents). When that is done go back to the table and talk more about the requirements in quadrant A.  If time permits implement those from quadrant D.   Ignore, postpone or consider cancelling those in quadrant C as these are difficult to implement and are of lower business value to the organization.

As a final thought, for those requirements in quadrant B that you can map to specific business goals and objectives (the strategic aspect), consider those as candidates for a phase 1 release on a BI project.

Prioritization doesn’t need to be difficult although it can be a challenging exercise. Having the right tool and technique can bode well for moving forward with an implementation schedule.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: