Priorities – part 3


I think perhaps the only thing worse than a three-part post is a three-part post with a week between each posting.

Here's the point I wanted to get to earlier this month: more often than not, people make mistakes with priorities. I'm not talking only about the problems I mentioned in the last two posts. My concern is the lack of factors considered when setting priorities.

For the sake of a different example, let's move to something besides bugs and features (although everything I'm about to type applies there as well). Part of my current job involves planning initiatives that effect large groups – “initiatives” that dictate work to be carried out over a long time-period by a large number of people. In situations such as this, there are always far more potential projects than can feasibly be accomplished. By the time the prioritization phase begins, the list has usually been pruned to an amount that can be discussed over a reasonable number of hours.

This is where the weird stuff happens.

Given the impact of work that may affect hundreds or thousands of people, prioritization and selection should be a carefully conducted process that takes into account dozens of parameters. Alternatively, it could involve cumulative voting based entirely on what the people in the discussion think would be cool. If the people making the decisions are smart enough (and lucky enough), they may be able to pull this off, but I’ve rarely seen this work.

A better solution for prioritizing is to define the goals of the organization and initiatives, then create values that can be used for ranking priorities. Yes, this approach is much more complex than voting, but it can pay off quickly. Often, only impact is considered when prioritizing initiatives (or features, or bugs). Decision makers want to know the size of the audience affected by making a change (or adding a feature, or fixing / not fixing a bug), but there are other factors to consider.

Time investment is something that is extremely important, but largely ignored. If I can positively (and measurably) change the way 200 people do their work by investing 10 man hours; or change the way 2000 people do their work by investing 1000 man hours which initiative is more beneficial? Most of you will say the first is more beneficial, but in practice, the second initiative is undertaken more often. The “right” answer is that you don’t have enough information yet. Proper prioritization and project selection requires careful analysis of impact, money, time, people, capacity, etc. in order to make the best selections. Basically,this approach makes an attempt at determining ROI using objective information rather than hunches and gut feel. My thoughts are based somewhat on project portfolio management if you want more information.

This approach is probably overkill for bug priorities (although I think a lightweight version may be better than triage team hunches in some cases). Along with some customer focused design principals like Kano modeling, I think a portfolio based approach would work beautifully for prioritizing and selecting features.

As for large scale projects and initiatives – it’s a no brainer as far as I’m concerned. I just need to convince a few people (or a few hundred) to think like me.


Skip to main content