Prioritizing Projects

To Prioritize Projects is often a pointless exercise of Project Management.

Back in Oct2000 I wrote...

I had to write and express my disagreement with Karl Wiegers article, Just Too Much To Do (Sept. 2000). This prioritize-by-the-numbers silliness is symptomatic of the mental stretches necessary to make software development sound like a 'professional' 'engineering' 'discipline'. "Hey, we didn't make a subjective decision, we added up the numbers, just like the guys who make bridges!" Didn't Douglas Adams have a character in one of his books (Dirk Gently?) who got rich by making a software package where you'd input the parameters and the desired decision, and it would tell you the weights to use? What is the unit of measure for the final score? The "pooka"? (Update: see Decision Rationalizing)

Karl minimizes the importance of the consensus process on the overall results (in terms of score and acceptance of those scores by the stakeholder groups). He even has the gall to say "the decision-makers need not all come from the development group", when it's probably more appropriate to have only 1 member of the group come from development. In most non-trivial arenas it's the discussion of the candidate projects in the context of the possible criteria that raises all the fuzzy organization-wide issues about what the company's focus/strategy/priority is. It's not the actual scores that matter, but rather the process of making assumptions explicit and forcing agreement to them. This will typically result in universal frustration, but it forces to the surface the fact that a reasonable prioritization process is not likely in the environment of an undirected organization. The smokescreen of numbers might make people feel guilty for being dissatisfied at their project's place in the Development Queue (and guilt is, after all, an effective technique for getting people to stop complaining), but it won't really solve the problem.