Methodology for Prioritizing Business and Project Requirements - Part 1

Why Prioritize Requirements?

Rookie project managers will often figure out which tasks need to be completed in order to achieve the end goal and create

something called a Work Breakdown Structure (WBS.) This winds up creating a list of discrete items that can be done independently and can be used to create the project schedule. They then take these tasks and create the project plan, and proceed onward. Even in a perfect world, this has little chance of succeeding. It would require that each task be perfectly scoped and budgeted, and it would mean that no one on your project team gets sick, quits, or takes a vacation. It also means that you have accounted for the unexpected ahead of time, either unexpected difficulties, or a shifting market landscape.

Doing project scheduling in this manner almost always leads to “Inside-Out” prioritization of project requirements. That is, the project team decides which things to work on first. A good project manager will probably schedule either the most risky things first, the prerequisites first, or perhaps the hardest things first. None of these are objectively bad ideas; getting the hard or risky things done up front might be a good idea. But doing this can miss the point. The hardest and riskiest things to do are not necessarily the ones that provide the most value. And providing value is a project manager’s main charter.

Outside-In Prioritization of Project Requirements

The question then becomes one of how to prioritize business and project requirements. In order to maximize the value that a project delivers, you should be always be working on the most valuable things. The best way to define value is by using the “Outside-In” approach. Internally, a project team might become enamored of a certain piece of functionality, or perhaps they are persuaded by the difficulty or risk it presents. However, the end users don’t consider those things. They consider their own use cases, or user stories. These stories answer “What is the user trying to do?” These range from “Make a dinner reservation” to “Purchase a stock” or “Design a business card.” Whatever the user is trying to do creates the story. Don’t forget internal stories, too. “Upgrade the server,” “Monitor the health of the web farm,” etc.: These can be just as important.

From here, you can determine which tasks are required for which stories, determine which stories are the top priority, and deliver the tasks that match. If your entire project has 100 tasks, but only seven are needed to complete the first user story, you should be working only on those seven. Let us say that it takes two months to complete those seven tasks, and your project team is pretty sure in those same two months that it could have completed 20 of the tasks, if they had been allowed to choose. Keep in mind that unless all the tasks for a user story are complete, then you have effectively built nothing at all.

Tips for Prioritization

But how to prioritize business and project requirements? This is a tricky problem, as all of your stakeholders will have different sets of priorities. In general, there are three key stakeholder groups. First is the business sponsor or business owner; they are the ones paying the bill for the project, so they rightly get a say in the priorities. The second group is the end user. Sometimes, you can have a representative from the user community available; other times you’ll need to identify someone to act as a proxy. The third group is the internal team. This could be the IT staff, the development team, etc. Each of these three classes of folks has varying degrees of input into the prioritization of requirements. There is a fourth group of folks like legal, contracts, partners, and other third-parties, but I’m going to leave them out of this discussion.

The good news is that having three different stakeholder groups is not all that unwieldy. They key is to getting each group represented by one person each. If you can manage that, prioritization works just like any other prioritization exercise. First, you can get a quick sensing by asking for “As, Bs, and Cs” from each person. Things that are all As are in, things that are all Cs are out. Easy enough. But that’s not all you need to do. Merely identifying all the “As” won’t get us what we need. We need to know which of the requirements is first, which is second, etc.

But now that we’ve gotten all the low priority items off the board, we are left with a pure stack-ranking exercise. That is, each requirement needs to be compared against all the others and ranked in order. This can be done using voting, using affinity diagrams, or perhaps by trying to put a dollar value on each requirement, and sorting by absolute value. It actually doesn’t matter which metric you wind up using; what is important is that you use one that you all agree upon.

What does matter is that you leave the room with a pure, ranked list of prioritized user stories. With that in hand, deciding what to do first is the easiest part of the job.

Image source:https://www.flickr.com/photos/44124414060@N01/2458194209

by Mai Le