In Real Estate the mantra is Location, Location, Location. If Requirements Management had a mantra it should be Prioritize, Prioritize, Prioritize. From the highest level requirements down to the detail requirements, Business Analysts should work with the stakeholders to prioritize each requirement.
Prioritizing Project Objectives
When you are initially scoping a project, prioritizing the project objectives will help guide the team in understanding what is most important to the stakeholder. This process and dialogue may even lead to the stakeholders realizing some of the objectives are not needed for the project. At this stage in the project, estimates may be given to the stakeholders. By having prioritized objectives, the stakeholders can decide to eliminate some of the lower priority objectives if necessary.
Prioritizing the Detail
As you move through the project and gather business, functional, and design requirements you should continue prioritizing. In some cases, the priority may be the same as the project objective it is traced from, but the priorities can be different. As the team has more detail requirements, better estimates are given and again the priorities give the stakeholders a basis for removing or postponing some requirements if the cost and/or duration of the project is longer than they would like.
In addition to aiding the stakeholders, the priorities guide the team on which requirements are most important. Teams are often crunched for time in all stages of the project. The requirement priorities are a tool that the team can use to determine where they should focus their attention.
The prioritization of requirements will be needed during a project and you’ll be glad you did it!
September 11th, 2006 at 12:42 pm
I had some challenges with regard to prioritization. During requirements gathering, I always asked my clients to give each requirement a priority, however sometimes they were reluctant to do so and commented that why don't you scope everything and give us an estimate on that, then we figure out the priority later. I know this is not the right strategy, but I am not sure how can I convince them or justify my suggestion. Well one thing I can think of now is the matter of focus or attention. As we all know, all resources are limited, the question is how do we get the most out of something within limited time and resources. If we treat everyting equally important, then we might spend lots of time on something that may end up out of the scope in the project. Any other ideas on how to convince clients when they are reluctant to prioritize requirements? Cheers! 2cents
September 12th, 2006 at 8:28 pm
You are not alone 2cents. It is a difficult process, and most clients do not enjoy it.
Another idea that may help: In many cases, after all detail requirements are reviewed and clearer estimates are given, the project will be longer and cost more than the client wants. If the requirements are prioritized up-front the user can more effectively determine which requirements can be deffered to a future phases or removed all together. Cost and time alone should not be the only factors going into the decision. The business priority has to play into that decision. Prioritizing earlier will makes the process less painful. Don’t give up trying!
September 15th, 2006 at 4:16 pm
I think that while most people pay lip service to prioritization, they don’t have a general methodology for doing it.
For instance, the first stage of prioritization concerns what the customers want. Too often, though, this is also where priortization stops.
A second way of prioritizing I can think of is what will cause the customers the most pain if they don’t have it.
Next, we should prioritize according to what is most risky to the project — this is core to the rational process, I think.
One should also prioritize based on cost. Some things take a long time. If two things are equally valuable to the client, but one takes longer, then that should have a lower priority than the quick win.
Other methods of prioritizing that are only important to developers are things like keeping related technology together and doing it all at once if possible. Switching between technologies or problem domains costs time.
And of course, don’t put the cart before the horse. To a certain extent, software development is an organic process, and certain things have to come before others, no matter what the priority schedule says.
Anyways, that’s my five cents.