A Rational Model of Task Priority

TL;DR: for tasks, assess each of Urgency, Importance and Easiness subjectively, in isolation; and then determine the logical Priority from there by calculating Priority = Easiness × Importance × Urgency. Then decide the actual Order of execution based on what this Priority calculation has revealed… don’t just fudge the figures.

I’ve done what I can in my career to avoid being promoted to any kind of manager, delegating such tasks to the kind of people that can multitask and deal with the intractabilities of other people. Ugh. I work better with code, and in particular, coming up with ideas and developing them as proofs-of-concept.

Still, those that do attempt to wrangle me usually seem to want time estimates and decisions. Because I prefer working with experimental projects rather than grinding out the same reliable, tractable, pedestrian thing over and over, I usually consider it largely impossible to come up with meaningful estimates. Often, I’m not even sure a task is possible — at least, as designed — until I’m pretty much done writing it. So, the best I can give you is a firm estimate of how long something’s going to take to do when I’m about 90% complete doing it. Sometimes.

Even with this uncertainty that can range in multiple levels of magnitude, I do often see these tasks arbitrarily prioritised, though. They are subjectively assigned, based on the opinion of the person doing the prioritisation. Invariably, their “bigger picture” is not the same (even remotely) as the “bigger picture” of their colleague. This is fairly easy to comprehend, as they have different responsibilities in their job titles.

(I must admit I do this myself: I pick what I’m concentrating on, either at a macro- or microscopic level based on what my assessment of the bigger picture is, or heck, often just what I feel like doing…)

For example, a project manager may prioritise based on what progresses the overall project in the short term, or if they’re in the right frame-of-mind, in the long term too. A client contact might prioritise based on what they need to keep the client happy.

A techie, on the other hand, is likely to want a neat, maintainable backend, and to cover their arse when it all goes horribly wrong… unfortunately, prioritising security updates for a hypothetical bug that may never be revealed is utterly invisible to the client, right up until there’s a massive global hack.

Problem is, arbitrary priority is subjective. That makes it subject to change at the whim of whoever is shouting loudest.

Priority really should be something that is determined, not decided.

So, what is priority? It’s the relative ordering of tasks for the maximum utility, in the short-, medium- and long-term. That’s how it needs to be seen. Put that way, it makes sense to try to break it down into factors that can be determined objectively, or at least dispassionately.

Now, I’m not going to try to quantify any of this. It’s unnecessary. We’re not going to try to solve the admittedly-important matter of budgeting and client expectations, but we can view it purely from the matter of getting things done (note, not Getting Things Done®). For that, we only need to know relative priority: whether to do Task A before or after Task B.

The other thing we can’t really do is manage the critical path. That’s far more complicated, and some may suggest unnecessary: there have been many successful companies based on the model of best effort, and using project management solely as a tool to ease blockage and make sure things are getting covered, rather than interfering with any natural flow. That’s not to say the critical path is irrelevant; just that it can be accommodated within common-sense and assessment of the tasks themselves for most projects… if there’s a complicated critical path, then perhaps the project architecture is at fault.

So, we just need to identify the elements of what could make one task self-evidently higher priority than another.

Easiness

The first one’s simple to identify: the easiness of the task relative to other candidate tasks. Now, for reasons I’ll explain later, it’s simpler to see this as “easiness” rather than “difficulty”.

Simply put, if you have two tasks that are predominantly identical — of equal importance, priority or what-have-you, then do the quicker one first: the classic “quick win”. Doing the harder one might be more interesting to a technical or creative mind, but in terms of getting the project progress bar moved on, why not do the easier one first?

Well, there are answers to that. Firstly, if doing an experimental project, wouldn’t it make sense to identify and solve problems that may scupper the entire project before wasting time on everything else? True, that does make sense. For this model to work, however, such tasks should not be considered identical to their easier brethren: they’re more critical, more important, and so may be seen as having a higher relative priority. More on that later, though.

Importance and Urgency

This bit’s tricky, but it’s the difference between spinning plates, treading water, flailing about and actually making progress.

These two terms are inextricably linked, but they’re critically different.

In this model, Importance represents the long-term view: how significant the completion of the task is to the overall project, regardless of when it gets done. An task of highest importance might be business critical, even if you leave it a few months.

Urgency, on the other hand, represents the short-term view: how time-sensitive the task is, regardless of whether the task actually matters or not in the grand scheme. An urgent task is one that will be of less value if not done soon; or alternatively, it will lose value the longer it is left.

So, you might have a time-critical task of taking the recycling out this morning; it must be sorted and taken out by 9 a.m. for it to be picked up. However, if it’s missed, then so what? It just gums up the garage until next week. This is an urgent task, but it’s not important.

Conversely, making sure your last will and testament is valid and up-to-date is critically important (at least to your family!) but unless you’re unlucky or just really really old, it’s not that time-critical. It’s an important task, but it’s not urgent.

Now, for practically all of examples, importance and urgency are not independent, and they’re not fixed in stone. If you repeatedly fail to take the recycling out, it’ll build up to the point your garage is full and you can’t get your car out. The importance of the task rises. And, the more you age to the tune of the Grim Reaper’s actuarial tables, the more urgent drafting your will becomes.

These can also impact our other factor, Easiness, too: if you leave your recycling too late, there will be so much and the municipal sanitary engineers won’t take it away, and you’ll have to find another way to get rid of it.

Dead Presidents

Thing is, this model isn’t new. It’s sometimes called the “Eisenhower Matrix”, in reference to a quote from President (and previously, General) Dwight D. Eisenhower:

“I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.” The resulting “Eisenhower Method” which is said to have been used by Eisenhower makes a polarised judgement on tasks categorised as such:

• Do the tasks that are both Urgent and Important;
• Decide when to schedule the tasks that are Important but not Urgent;
• Delegate tasks that are Urgent but not Important;
• Delete tasks that are neither.

I think this is too polarising, but as an example, it’s good. It does start to cover the idea of prioritisation, but only for an instantaneous point. It also doesn’t take into account the difficulty, or Easiness, of the tasks in question.

With a large stack of tasks, I think a scale of priority is needed.

Combining the factors

So, we have three somewhat independent factors that admittedly do influence each other.

There are a few things to note about the factors.

Firstly, they are relative. As I mentioned earlier, we’re not trying to quantify them. What matters is how easy a task is compared to another. What matters is how urgent a task is compared to another. What matters is how important a task is compared to another.

Secondly, these factors are subjective. There’s no denying that. Easiness is the easiest factor to determine: while it might be hard to guess at how hard a task is or how long it’ll take, it’s usually quite straightforward to make a guess at whether it’ll be easier than another task, at least within a level of magnitude.

Importance and Urgency are very hard to determine if the definitions above aren’t taken to heart. Don’t overthink them; avoid thinking things like, “this task is more urgent because if we don’t get it done, the project will fail”; or, “this task is more important because the client wants to see progress now.” That’s mistaking our factors for subjective priority.

Thirdly, not only are the factors relative, but they’re debatable and dynamic too. The project collaborators (stake-holders, if you must) need to argue those points. However, unlike priority — arguing of which is predominantly circular and almost always fruitless and unconvincing — these variables can be argued on their merits.

You can easily establish urgency in isolation with customer milestones, and integrating critical path. Yes, here’s where that critical path comes in: if you have a Task B that is dependent on Task A being completed, then undeniably Task A is of higher urgency than Task B.

For a constructive project where all aspects are necessary, Importance is difficult to establish as one can claim that all tasks are equally important. However, you can usually identify some tasks that can be neglected or eliminated altogether, and there are almost always some undeniable show-stoppers. For more open-ended projects, like support team scheduling, then it’s easy to slap “Very Important” on “Backups”, “Security Patches” and “Documentation” without much argument, if you can concede that it doesn’t matter if they’re left for a while in favour of getting the boss’s email client using the right fonts (Urgent!)

Incidentally, those last tasks — backups, security patches, documentation, training and so forth, are the first casualties in a superficial priority assignment technique. They’re the things that this approach is really intended to accommodate.

The minimum quantification

Even though we’re trying not to quantify, we do need to slap some enumeration on this, even if it’s vague: “Very Important”, “Somewhat Important”, “Neutral”, “Somewhat Unimportant”, “Very Unimportant”, for example.

Instead, consider using numbers 1 to 5 for all of these. It doesn’t matter what they mean in isolation, but merely relative to each other.

For example, you might decide that Easiness is measured on the scale of:

1. Months of work: difficult;
2. Weeks of work;
3. Days of work;
4. Hours of work;
5. Minutes of work: easy;

…or you could divide it up evenly. It doesn’t really matter, as long as the tasks are distributed between 1 and 5. They don’t even need to be evenly distributed; just don’t put all tasks as “3” and be done with it.

It also makes things easier if the factors are all numbered the same way. Strictly speaking, as relative factors we should really be numbering these from 0 to 1, but it just doesn’t feel as intuitively right.

Numbering from 1 to 10 is a possibility too, but I think it’s too easy to get hung up on it: “Oh, it is a five or a six? Maybe it’s a five point five?”

No. Just use 1 to 5 and be done with it. If you have two tasks at 3, then don’t worry about it as we’re going to fudge things at the end anyway…

Importance can be categorised like this:

1. Nice to have: not important;
2. If it doesn’t get done, our jobs are harder;
3. If it doesn’t get done, it could cause serious problems;
4. If it doesn’t get done, our jobs are at risk;
5. If it doesn’t get done, the company itself could go bankrupt: very important.

And for urgency:

1. If it doesn’t get done by the time I retire, I really should tell my successor to do it;
2. It needs to get done in the next month or so to be of use;
3. It needs to get done in the next week or so to be of use;
4. It needs to be done today to be of use;
5. Do it now, or there’s no point in bothering.

See that these assignments to Urgency don’t dictate the consequence of not doing the task; that’s where Importance comes in.

There is a virtue here in keeping it vague. It’s easier to agree on those, and what we really need is consensus.

Incidentally, you can invert all these numbers, and have “1” as the highest difficulty (rather than easiness), “1” as the most urgent, and “1” as the most important. I’ve chosen to go the other way.

The process

So, once you’ve identified the tasks to be done, the team needs to sit down and thrash out the values. Go through them one-by-one and agree values for them.

Start with Easiness as while it is probably subjective — unless you’re a lot better at estimating work than I am, which is almost inevitable to be fair — it’s something that has a narrower picture: you just consider the implementation work rather than impact on the customer, other teams, business, and so forth.

Then, someone will have to jump in and throw in their best guesses at Importance and Urgency as a starter for ten. The team wrestles them until everyone agrees, picking the clearer ones first, and resorting to a one-on-one face-off for others: consider two tasks and ask which one is more important than the other.

In fact, it’s probably best to tackle Importance first, as I think for most people, Urgency is the one that’s closest to Priority, and that’s what we’re doing our best to avoid considering!

Once these are complete, open another column in the spreadsheet (which I assume you’ve been throwing these all into) and label it “Priority”.

Priority

In this model, I define Priority as the (multiplicative) product of Easiness, Urgency and Importance.

Priority = Easiness × Importance × Urgency

(Or, more precisely, relative Priority is the multiplicative product of relative Easiness, relative Importance and relative Urgency. It’s only significant within the set of tasks being considered. Worth remembering.)

So, a task we’ve identified as Medium Easiness (3), High Urgency (4) and Very High Importance (5) has a Priority of 3 × 4 × 5 = 60.

Sure, that’s arbitrary, but it’s enough with which to sort the spreadsheet in rough order of relatively-objective priority.

It’ll ensure that security patches (easy, urgent and business-critical ⇒ high priority) get done in a timely manner; documentation (medium difficulty, less urgent but important in the grand scheme ⇒ medium times low times high ⇒ medium-high priority) doesn’t get left to last; client-pleasing quick wins (easy difficulty, high urgency, low importance ⇒ high priority) get done quickly; and implementation of little-used features get left until there’s nothing left to do.

The highest “score” is 125 in this particular model, but that’s irrelevant because the distribution across this range may or may not be even or spread. The Priority only matters relative to the other tasks in the list: higher or lower.

The shifting tides

Tasks can get easier or harder the longer you leave them: starting with a blank sheet is harder than working with some established context, but for that matter, a mature, complicated codebase requires harder work than that middle ground. Similarly, it gets easier the more familiar you are with the code. But, if left too long, you might have spaghetti code to deal with and a nasty complicated refactoring to do.

The Easiness of a task also increases once work on the task commences: as it approaches completion, the Easiness of the task (defined as the estimated amount of effort to complete the task) obviously gets higher. That manifests in Priority as the urge to complete tasks in progress rather than starting new ones of equal urgency and importance.

Obviously, the urgency of tasks tends to increase the longer you leave them; the more likely it is that the chief developer gets hit by a bus and that “non-urgent” documentation is suddenly critical. Or, you start losing customers while you utterly fail to implement a helpful feature that you’ve decided is peripheral to the main purpose of the product.

Saying that, urgent tasks can become less urgent as they become less relevant, especially if they’re tasked to handle fixed events like a scheduled product launch. That’s the time that it might even be worth deleting a bunch of previously “Urgent” tasks that weren’t “Important” enough to make the grade.

Important tasks can become more or less important too. As Importance is intended to be independent of time in our original definition, it tends not to be a trend either way; instead, tasks can suddenly increase or decrease in importance if — for example — a bug exploit is released, or conversely, support for an older browser becomes less important as usage stats decline.

So, it’s worth reassessing all these assumptions made in the spreadsheet. Each week, or each meeting, or whenever, question whether the Easiness, Importance and Urgency are still valid.

Now what?

Once we have the priorities, sort the tasks by calculated priority and look at them carefully. Truths will become evident that you’d chosen to ignore, underestimated, or failed to notice entirely.

You’ll see that a particular task that everyone thought was a blockbuster can actually wait a while, and should (arguably) be postponed in favour of some housekeeping, or documentation, or a quick-win.

That’s what this process is meant to reveal. But we don’t have to obey it.

The relative priority of these tasks as we’ve calculated them is just a springboard for the actual assignment of tasks. Add another column, “Order”.

In that column you actually consider the practicality of the assignments. Consider what staff resource is available and whose talents fit the tasks at hand. Consider the critical path (yuck). Consider what feels right, and what you (as a team) want to achieve. Just use the priorities you’ve calculated as a guide to what you should actually do.

Number the tasks from 1st, 2nd, 3rd, and so on; write assignments next to the tasks, or however you want to do it. This ordering may not match the priority entirely, but if you’ve done it right, they should tend to agree on the whole. If not, reconsider your assumptions in Importance and Urgency again.

But do not tweak them just to change Priority to what you think it *should *be!

I can’t stress that enough. To do so is just to lie to yourself. If you feel the priority is wrong even though you’ve confirmed your reasoning for the E, I and U factors, then just change the Order column. Leave the Priority value as it is, so that when you revisit it you can read the note you’ve helpfully added saying why you feel it necessary to disregard Priority. Don’t just fake the numbers. Justify your disagreement with the numbers. That’s okay: you’re in charge, not the numbers.

Oh, but this is all so complicated!

It really isn’t. I have some nice macros in Google Sheets that colour-code the columns, and calculate priority neatly. I’ve used it to justify and persuade my colleagues of the value of tasks that were otherwise ignored. And sadly, I’ve used it for one or two “I Told You So”s when the Priority column was disregarded and the shit hit the fan.

The funny thing is that more than once I’ve been told this system is too complicated, by colleagues who have subsequently absorbed books on Scrum and Agile practices and decided that using the Fibonacci sequence to quantify priority and work units and introducing a glossary of trendy words is somehow simpler!

All I want you to do is compare one task against another and answer three fundamental questions: which one is easier to do? Which one is more important in the long-term? Which one has more immediate impact?

From that, you can rationally calculate priority: a feat I’ve never actually seen done otherwise.

In the end, I’m just a humble programmer, though. See what works for you.

Note: I wrote this article a while ago, and mulled it over, got feedback, etc. I’m still not sure about it, as it may show that I’m clearly a project management naïf. I’ve just decided to pull the trigger anyway, and to hell with opinions. Anyway, I bet you haven’t heard the word “naïf” used recently, so there’s that at least…

Also, I’m under no illusion this is an original system. I came up with the Prioritisation method independently, but it’s obvious enough that someone with actual project management pedigree must’ve considered it and disregarded it before. I don’t make a habit of reading project management books. It’s a naïve system. All I claim is really that hammering straight for the Priority column and throwing in your best guess is a cop-out and a subjective, unjustifiable and ultimately irrational approach. If you know of a similar or identical system, I’d love to hear about it.