Joel Spolsky writes here about the penchant that many organizations have for playing Monty Hall when it comes to the fine art of requirement prioritization. You’re likely already familiar with how this exercise gets done in most organizations:

Step 1: Assemble a cross-functional group of the top big-wigs and engage in some serious horsetrading around whose pet requirement is a must-have versus whose is a nice-to-have.

Step2: Lather. Rinse. Repeat.

The end result, oftentimes, is a set of requirements that is more representative of who in the organization carries the bigger stick rather than an accurate prioritization of the features that will most efficiently meet the needs of the business. Lots of pretty bells and whistles – Marketing runs the house. Ten different features that are each required to close a “major deal” – the Sales team is at the wheel. A huge refactoring effort that will have zero visibility to the end users – perhaps the founder is still the CTO.

Joel takes this process, as he often does with SOP in the industry, and turns it on its head. He suggests an immensely rational approach that does away with prioritization by fiat and replaces it with a market-driven framework based on economics. His words are far better than mine so I will just urge you to take a look at what he advocates.

There are two groups in particular who I can see coming back and saying this approach would never work for them.

The first is comprised of folks that work for large companies, particularly people working in IT for large companies. Their immediate response may be that this process would never scale from Joel’s 20 person cohort to a large organization with oodles and oodles of diverse stakeholders. Perhaps the exact mechanics of getting everyone in a room – yes. But, I would suggest that it could still work quite nicely if only someone in the company would write up a quick little web application that would allow you to do all of the same simple activities with a large group of distributed people.

The second group of likely naysayers are those people in organizations that are very top-down driven. “Our management would never cede that kind of control to the user rabble.” I see a couple of possible ways around this issue. My preferred method would be to use the web-based approach suggested in the last paragraph but set it up so that you could aggregate the input from management separate from that of everyone else. If management and everyone else agrees then everything is great. If not, you have some dispassionate numbers that can be used to drive a discussion around why management’s decisions should override the thinking of the many. Alternatively, you could use some form of weighting approach that would allow you to factor management’s input at a higher rate than everyone else. I have no idea whether it should it be 2 to 1, or 10 to 1, or 100 to 1, but I imagine in most organizations it would be quickly evident.

As Joel says, “it’s not perfect.” Even so, I think it is a fantastic start for organizations trying to get off the treadmill where bad priorities lead to even worse products. If nothing else, this approach to prioritizing requirements should lead you at least a little closer to the systems your users want and need rather than those that resemble old Monty’s goat!