Requirements prioritization – what’s the point?

An aspect of prioritization don’t hear about quite so much is understanding the value of prioritization. Requirements prioritization is a time intensive activity and can push our stakeholders to their limits. What’s the value in prioritization that makes it work the time and effort we must invest to get it right?

As analysts, many of us work in an environment in which everything is important and all requests for work are high priority. So, if the stakeholders need it all and need it now, why bother to go through the exercise of prioritizing? This  is a valid question that becomes especially important when time frames to conduct work are squeezed and the practitioner is facing yet another task that consumes valuable time.

The issue that prioritization helps to solve is really a simple concept that is illustrated by the time:cost:quality ratio, which are inversely proportional to one another.  In other words, increase one and the other takes a hit.  Specifically, if you are asked to do 50 things yet have time only for 10, your quality will suffer. Also,  while your initial cost will go down due to less time spent, your overall cost will increase due to rework as a result of the poor quality.

Value of Prioritization

To understand what the point of the prioritization effort is, one has to understand why it’s valuable.

Balancing Out the  Scales

When faced with onslaughts of work under ridiculous deadlines, we have to make some decisions about what is most important, and the answer to this question can be different depending on who you ask. To a delivery manager, the project is going to come in on-time and within budget and that person will be successful, but what about the rest of the project team members?

One of the most common reasons to prioritize is to label the order in which work items are completed under the constraints of the project. For Project Managers, the high importance items that are results of the prioritization exercise represent the critical path to completion. As Analysts, it might mean the items that represent the most value to the stakeholders are worked first. Developers and Designers can find the most technically complex items identified for working first.

Stakeholder Accountability

A project has limited resources and therefore limited hours in which to perform the set of tasks necessary to be successful upon completion. Jam more into the bucket of work and the bucket will overflow. It’s prudent for the health of the project to understand that the requested amount of work must equal the number of available resource hours, and when it doesn’t something has to give.

This is where prioritization comes in, because it forces the decision-making process about what is most important in situations where it is not possible to deliver everything. By determining the value of each item based on defined criteria, one can also begin to slot each one in order of importance. Now, what one person says is valuable or important, another says it is not. Therefore, it’s best to weigh the answers of a group of stakeholders together. Once this occurs, the prioritized list represents an agreement amongst the requester and delivery team of what constitutes the items that will be worked on within the time that is available. If those get completed,  there are additional, and agreed upon, items in order of importance that will then be addressed.

Focused Domain Knowledge

Prioritization can also lead to a deeper understanding of specific problem domains. Specific work items have the potential to illustrate or highlight targeted areas of the business or technical infrastructure, and prioritization of them can bring an early recognition of the pieces and parts that make up processes and procedures, technical functionality, and business unit or system interactions with one another. Knowledge of more complex components of a project early in its life cycle is an important aspect of being able to craft the total picture with better structure and more flexibility, as well as understand what the limitations might be.

Prevention of Corner Cutting and Rework

Anyone who’s been on a rushed project knows what occurs. Work gets done as fast as possible with less attention to detail and quality in order to get the tasks completed on time. By not prioritizing work the team may be working on the lowest value items, and it deprives itself of the ability to plan and accommodate issues that come up in a project. Rushing through the work to meet the delivery schedule is often accomplished by skipping valuable tasks like prioritization and reviews that are deemed less productive because they do not result in a tangible delivery item. Those corners that are culled off the WBS actually have huge value that can prevent flawed thought processes on the business side or defects in the IT delivery. Prioritization sets boundaries around the amount of work, or concurrent work, that must be accomplished, thus it also helps to allow for quality producing tasks in the outcome of the work.

Finally….Requirements Prioritization

So maybe you’ve been thinking, “I thought this was about requirements prioritization, not prioritization in general.”…haven’t you?

Well, you’re right. There I said it. However, it is important to understand the value of prioritization in whole before pigeon-holing it onto requirements alone. In fact, an analyst’s requirements prioritization can actually be a problem, if there is not broader use at the overall project. Now that I’ve mentioned the requirements aspect, there is really not much more to say about the value it brings without going into how to implement it, because the same concepts and values are applicable at this level. The difference is where the analyst applies the priorities, such as at requirements instead of higher level project work. It is still all about managing work that is more critical before addressing less important objectives.

>>Figure Out Your BA Timeline

Join us for the BA Essentials Master Class. You’ll learn exactly how to come up with a business analyst timeline for a new assignment and where to incorporate prioritization into your project priorities.

Click here to learn more about the BA Essentials Master Class

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. Nice post, Doug. Prioritization by value is critical to allocating constrained resources to specific work projects. However, the value of prioritization itself is diminished significantly without a rigorous and defensible way to pick which sub-set of projects will provide a maximum return from multiple constrained resources. Those are the projects that should be worked-on first. That’s why I say prioritization without optimization is like soup without water.

    Consider that for a portfolio of 20 projects, there are over 1 million possible sub-sets to choose from. For a portfolio of 40 projects, there are more than 1 trillion(!) possible sub-sets of projects to choose from. So choosing an optimal sub-set that will deliver the highest value manually using spreadsheets is about as likely as picking a winning lottery ticket.

    So the best way to pick an optimal set of projects is to use an optimizer that can rapidly find solutions for you. If you’re interested in seeing how this works in practice, I have a free webinar called “Project Prioritization and Ranking on Steroids!” You can see a 2 minute preview at http://bit.ly/bixC7T

    George

  2. I’ve also been trying new ways to determine the “real” priorities because so often the first pass at priorities doesn’t provide the best possible information. I’ve often found time boxing to work, especially if you have a sense that there are some extra requirements sneaking themselves in. Being able to say, well, we have about a month of time to deal with, let’s rank these….if the bottom ones fall off the list would that be OK to deliver?

    One thing I struggle with still is that real, honest prioritization is very hard work. It takes a lot of analysis and stakeholder involvement. I try to take some care that we invest enough time in the process to understand priorities, but not so much that we end up prioritizing or ranking items that have no chance to be implemented or that absolutely must be implemented. There’s a lot of gray areas on each side of the prioritization scale!

  3. Davids:
    Thank you both for your comments. It appears you each have been able to realize the benefits of this process in different ways.

    DavidH: To your comment on the time-boxed approach with prioritization…do you think that teams come up with alternative solutions due to innovation afforded by this combined method?

  4. Thanks for the very useful blog post. In many ways the word “requirement” gets in the way of usefully moving products / projects forward, since people often get in the mindset of “if it’s a requirement, then it’s *required*”.

    I agree with all you points, but I think that the Focused Domain Knowledge may actually be the most important. Trying to narrow in on the complexities earlier is definitely preferable, and prioritization can help burrow into those areas.

    Another angle on the issue: if prioritization is combined with a time-boxed delivery approach, then team members can often fairly quickly come up with other approaches to the *same* requirement that are both simpler to implement and get to satisfying a business need sooner.

    Related to prioritization is how to *package* the implementation of requirements. So you may for example first implement lower priority items if in the aggregate they are easy to implement, easy to explain as a package, and help put you in better stead for implementing those harder buy higher priority items later.

    Thanks again for the nice post.

  5. Dave Schrenk says

    I agree with the importance and the value of prioritization.

    I recently assisted a large legacy system replacement project by taking a relatively large set of requirements (600+) and categorizing them as best as I could. I then worked with the business sponsor and SMEs to prioritize them so that the scope of the next system release was more manageable. This effort resulted in the identification of 194 requirements that would be included in the scope of the next system release. The remaining 400+ requirements were prioritized as either being needed for the next product release or as a future enhancement. It also provided a framework for how prioritization can be accomplished for future releases.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.