Hi there,

I know this post is nearly a year old, but I read it and was rather perplexed by what it is actually trying to say. It seems to be a data dump for every way to prioritise requirements, as opposed to a step by step way to carry out the task.

For example, point 4 and 12 are one and the same, and the rest are variations on the same theme (i.e. they carry out the same task, but are just different ways of doing it). 

I would also say that 25 years experience as a Senior BA and now BA Manager tells me that step 1 is prone to failure. Depending on how large your project is, you could have 5 to 10 different senior personnel in the room. They will NOT want to be sat in a meeting room, probably for 3 to 4 hours, listening to everyone else's priorities. They have better things to do and will not spare the time. 

The biggest problem with prioritising requirements, and therefore the reason most of these may well fail, is that every stakeholder thinks their requirement is the most important. It certainly is for them and in the Dog Eat Dog world of business, they wont care about anyone else's priorities. 

By all means collate all the priorities but you are better off carrying out this task with your Senior Developer, Project Manager and Project Sponsor. The Dev will tell you a rough estimate to effort building it (assuming the project is technical - if it isn't then replace the Senior Dev with the person who is in charge of the area you are making the Change, for example the Operations Manager), the Project Manager and Project Sponsor who both have a handle on the political stance (what is crucial to the Business to get in first). Then look at impact - what is the Business Driver for the project, is it a new corporate Website? In which case, building the website would need to come AFTER you have agreed its contents. Equally though, could the developers start building the framework for the site? This is where your Dev comes in - he or she will be able to tell you the order the technical build requirements should come in and therefore their priority.

Most of the rest of the requirements priorities then fall into common sense and an agreed project scope. Is there a Phase One and Phase Two? In which case, can all the Phase Two stuff wait or does it NEED to be started early? If it doesn't - it waits. Common sense will tell you that you may well want a new Insurance Product, but if you haven't priced it up yet, what's the point of trying to sell it?

If you are left over with any other requirements that have similar priorities, then by all means get their owners together, but you don't need everyone in that room.  It wouldn't be the first time when I have told two Stakeholders that they aren't leaving the room until they have agreed a priority order between them. The best way is often the most honest way. Explain that you need to knw which needs to come first - let the two stakeholders argue this out between them and then get them to come back and tell you which is higher. Often, if you treat Stakeholders as adults, they will sort it out themselves. They just need to be guided every so often.