CUIPO: A Rational Model of Task Priority

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

In my career I’ve done what I can to avoid being promoted to any kind of manager, delegating such tasks to the kind of people with the gift of multitasking and the patience to 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’ve pretty much completed it. So, the best I can give you is a firm estimate of how long something’s going to take to finish when I’m about 90% complete doing it. Maybe. 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.

Complexity

The first one’s simple to identify: the complexity of the task relative to other candidate tasks. Think of this as easy vs. difficult; or quick vs. slow. Either way, how big a job is it?

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 greater subjective 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. A 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 is the task, regardless of whether the task actually matters or not in the grand scheme. An urgent task is one that needs to be done soon if it’s going to be done at all.

So, you might have a time-critical task of taking the recycling out this morning; it must be sorted and at the curbside by 9 a.m. for it to be picked up at all. But 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 usually not urgent.

So, get the recycling done in the morning, and then do your last will and testament.

Now, for practically all matters, 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, complexity, too: if you leave your recycling too late, there will be so much and the truck won’t take it away, and you’ll have to find another way to get rid of it.

When it comes to food waste, you might say the urgency increases, because you can’t just leave the waste until next week or it’ll stink the place out. Actually, the urgency is probably the same: the garbage truck will arrive at the same time no matter how desperate you are. However, if you did miss it one week, the importance of getting it out in time for the truck is greater.

All three of these metrics should be evaluated based on your best guess right now. So, if a task is made easier by another, then its complexity might be high now, but could be reduced later once the prep task is done.

Dead Presidents

Thing is, this model isn’t really 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” 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 (or Defer) tasks that are neither.

I think this is too polarised, but it’s snappy, and 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 complexity 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 really trying to quantify them. What matters is how complex a task is compared to another; how urgent a task is compared to another; how important a task is compared to another.

Secondly, while we’re trying to treat them as objectively as we can, these factors are subjective. There’s no denying that. My opinion on what’s easy is going to be different from yours.

Complexity is often the clearest 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 or harder than another task, at least within a level of magnitude.

Importance and Urgency are very hard to determine if our definitions aren’t taken to heart. Don’t overthink them; avoid thinking “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 individual factors for definitely 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 discuss and argue those points. However, unlike arguing priority — 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 the 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 the most urgent task of getting the boss’s printer working.

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.

First things first, decide which way you want to go: low-to-high numbers or high-to-low numbers for increasing priority? It makes things easier if the factors are all numbered the same way; in other words, do it so Easy = Urgent = Important, and Difficult = Not Urgent = Not Important. This is because we’re trying to sort tasks by the desirability of their immediate completion.

Here we’ll choose high-to-low, so we end up with Priority 1 being tasks that are easy, urgent and important.

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

• 5: Months of work: difficult;
• 4: Weeks of work;
• 3: Days of work;
• 2: Hours of work;
• 1: 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.

Strictly speaking, as relative factors we should 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:

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

And for urgency:

• 5: If it doesn’t get done by the time I retire, I really should tell my successor to do it;
• 4: 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;
• 2: It needs to be done today to be of use;
• 1: 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.

Now, you can invert these, as noted above… Urgency of 5 being less than Urgency of 1? Without context, it sounds silly, but it makes the mathematics (slightly) easier. If you choose the other way, fine… you’ll just have to subtract Priority from 125 at the end.

The process

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

Start with Complexity 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, just to start. 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, the (multiplicative) product of Complexity, Urgency and Importance gives you Priority; and we then use that to decide the Order of tasks. That’s the “CUIPO” acronym.

Complexity × Urgency × Importance = Priority ⇒ Order

(Or, more precisely, relative Priority is the multiplicative product of relative Complexity, 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 Complexity (3), High Urgency (2) and Very High Importance (1) has a Priority of 3 × 2 × 1 = 6.

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

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 out. The Priority only matters relative to the other tasks in the list: higher or lower.

If you’ve chosen to do the numbers the other way, you’ll probably want to say P = 125 - (C × U × I) so Priority 1 means high priority. Or just go with it and reckon a high number means high priority. Up to you.

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 Complexity of a task also decreases once work on the task commences: as it approaches completion, the Complexity of the task (defined as the estimated amount of effort to complete the task) hopefully gets lower. 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 Complexity, Urgency and Importance are still valid.

Now what?

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

You’ll see that a particular task that everyone thought was a show-stopper 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 these results.

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 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 make it 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 C, U and I 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 felt it necessary to disregard Priority. Don’t just fake the numbers. Don’t lie to yourself. You can rationally 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 done it in Excel, Monday.com, and Notion, and 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.

Once you get used to it, you can qualitatively do this in your head: maybe not all the numbers, but you can detach Complexity, Urgency, and Importance, and estimate relative Priority rather than just guessing.

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 Agile practices and use the Fibonacci sequence to quantify priority for work units and project stories, and think that 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 has more immediate impact? Which one is more important in the long-term?

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 to me 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.

UPDATE, 2024: After using this for years, I’ve tweaked it a little bit, but not that much. I’ve implemented it a few times with Google Sheets, then in Monday.com for our task management, and I’ve just sat down and put it together in Notion. It becomes natural.

I’ve also finally chosen a name: “CUIPO”, being an acronym (and mnemonic) for the factors. It’s also the name of a tree found in Central/South America, which is nice.

In line with my thoughts above, I honestly didn’t hack the acronym to match the tree… I moved away from “Easiness” being a better name than “Complexity”, and then the C, U and I columns were always somewhat fungible on the sheet. It then turned out to sound like a word, so I googled it. Fortunately, it wasn’t something awful.