Now—at last—you’re ready to apply your prioritization model. A small group of informed decision makers should participate in the rating process. This minimizes individual biases and compensates for each individual’s limitations of knowledge about the candidate projects. One approach is to have the participants create the ratings by consensus in a meeting, discussing points of disagreement to reach an equitable resolution. Alternatively, the participants could prepare their ratings individually and then meet to review the numbers and reconcile any conflicts. The decision makers need not all be from the development group. Getting your customer representatives to understand the unpleasant reality of resource limitations and the need for prioritization might help change them from adversaries into partners.

We examined several dozen projects in our backlog queue, as well as those we currently had underway. We rated each of them against all of our project prioritization drivers, using the rating scales we had defined. Sorting the candidate project list in descending order by the computed score yielded a first-cut prioritization sequence for these projects. Ironically, the analysis suggested that several of our current projects didn’t make the grade; we probably should have been working on other, more pressing ventures instead.

The numbers that come out of your prioritization model won’t be the only consideration when you choose the next project to launch. Political factors also have a way of slipping into the discussion, although a model-based rational analysis might help you combat the more irrational political games. Sometimes there are intangible "this would really be cool" issues that transcend a systematic analysis. Don’t let the glitz factor distract you into making unwise business decisions, though.

Note

Relying solely on an objective, analytical model to make prioritization decisions. Other subjective factors might override aspects of the analysis, such as an opportunity to exploit unique technologies to enhance your brand image.

You’ll need to reevaluate your project queue periodically as new proposals come along, when corporate directions change, or when significant factors change for projects in your current backlog. For example, perhaps Project A was originally rated low because it couldn’t be completed with current technical capabilities. If some other project work leads to those capabilities now being available, Project A’s priority could go up.

A reliable prioritization model can help you justify why some projects simply should never be done. Nothing helps a project queue more than eliminating the candidates that just don’t make the cut. Keep your project priority list current as life goes on around you. That way you’ll be able to devote your limited resources to those activities that will best enable your software group to help the company achieve its business objectives.