Skip to main content

Get Your Priorities in Order

Let’s talk about setting priorities…  Not life priorities, prioritizing requirements.

Prioritizing requirements is one of those activities that can be either super easy or crazy tough.  If you planned ahead, prioritization is surprisingly easy.  Prioritization needs three major ingredients:

  1. A large group of stakeholders that know development priorities need to be set
  2. A set of business objectives
  3. An application with at least some complexity

Here’s why:

The larger the group of stakeholders, the more important it becomes to have a way of prioritizing requirements.  Let’s face it, if you only have one stakeholder, priority setting is really much more an executive decision than a process.  However, if there are a lot of stakeholders, the process of priority setting needs to be objective, and business analysts can add value.  In fact, the larger the group, the more the rigor needed in methodology.

Sometimes you have to ask yourself, “Am I stepping into someone else’s role?”  That position is going to get very uncomfortable very fast.

Let’s say you’re a BA working with a team that clearly needs to set priorities and there isn’t one individual that can step forward in that role. The next big issue is to create an objective way of prioritizing.  For this you must have some decent business goals/objectives for the project and use these to help guide prioritization objectively.  The approach is quite simple; take each requirement (or bundles of requirements supporting similar functionality) and ask the business stakeholders to rate it in terms of contribution to the business goals.  Similarly, ask the IT folks to rate the relative complexity of development (cost/risk) then put the two sides together to create a four quadrant grid (Dilbert would be proud!).  The resulting chart makes for a good  conversation.

The exercise of setting priorities is really less about the mathematical and much more about each stakeholder putting a stake in the ground and talking about why they’ve rated something relatively high or low.  It’s the discussion that counts – don’t shrug it off.

Finally, let’s talk about application complexity.  Let’s say you’re doing a customer order management system.  There is often no value in prioritizing something like ‘validate the customer’ higher than the next step in the same process, for example, ‘price the order.’  All these functionalities are absolutely necessary to the BASIC functioning of a system.  If a system cannot function without something like ‘record the order’, why prioritize it; it doesn’t make sense.  The first step is to separate functionality into must have/should have/could have (look at the MoSCoW technique). Then start prioritizing.  This approach separates the stakeholder discussion into two valuable stages:

  • Is this functionality absolutely essential to the basic system?
  • Okay, if it’s possible to function without that capability (even in the short term) then let’s prioritize it so that we look at all the pieces together.

For me, if a system is reasonably complex and everything described in the specification is mandatory, the spec may not be detailed enough.

Helping to prioritize functionality is one of those super high value activities of a business analyst.  It helps sometimes to uncover issues underlying stakeholders and may help bring obstinate stakeholders along.  I find it very useful myself, but it doesn’t necessarily fit in every engagement.  If it’s not your role to play, or it is not an application with sufficient complexity to have elements with different priorities, don’t try to force feed the tactic on time deprived stakeholders.

I wish you all great success.

Don’t forget to leave your comments below