It’s been over a year since many of us started working from home and although we gave up certain chores like driving to work or booking meeting rooms, we did invite new tasks for ourselves like making your own chai (coffee is not my cup of tea) or attending your kid’s school. All in all, the new responsibilities introduced change, more importantly change management, and Prioritisation still remains one of the top ranking tasks with any change management.
In case you’re oblivious to this concept let’s define Prioritisation in brief;
According to Google:
And according to Wikipedia:
It’s important to note that in both these definitions, the emphasis is being given on the fact that priorities are relative to each other; and this results in creation of an order by itself where one activity is more important than the other. Common examples would include “critical” being more important than “medium” or “low” being less important than “high”. And yet, here I am writing an article asking which is better, the Order or the Priority?
Although one may consider both as synonyms (and they might be in a way), it’s the way these are utilised where I find the difference. Let’s talk about a few methods we use for prioritisation; there’s the very famous MoSCoW (must-have, should-have, could-have, won’t have), there’s criticality like blocker-critical-major-minor, there’s importance like high-medium-low, and then many many variations of these. The irony with prioritisation methods is that although prioritisation refers to ordering activities, these methods only order the various buckets for prioritisation and not the specific items / activities within these buckets; thereby not complying with the definition of prioritisation that we see above.
These result in various complications when used by groups, for example a product release might end up marking all features as must-haves when following the MoSCoW technique thereby making the product feature-rich. Or every defect raised by a customer may become a critical issue resulting in L2 / L3 support getting involved in every triage that results in overall delays. These are situations where an order makes a bit more sense.
An Order may take various forms as well; top to bottom, left to right, from center moving out wards or the other way around, etc. The difference gets achieved when these arrangements are accompanied with certain rules, for example, an item on the top is more important than the item under it (relatively, like a stack); and unlike a bucket of priority, only one item / activity can live at a given position (no superimposed items at the same level). This results in a rank-based arrangement, a hierarchy where no two items / activities can have the same rank. This helps overcome the problems with techniques like MoSCoW that may result in a feature-rich product.
So, does that make an Order better than a Priority?
The answer as always is, it depends.
There are certainly situations where ordering items / activities make more sense, like when arranging a Product Backlog or deciding which book to read. This brings in more focus for teams and individuals resulting in better flow. Other times, a bucketed priority would help reducing delays when wait-time exists for certain activities, like writing an article while you wait for your 10 minute build to complete. Many such examples can be drawn where one may be more suitable than the other, what needs to be acknowledged is that there are different ways of prioritisation and it’s not just prioritisation that’s important but also the way you prioritise given your situation.
So the next time when you want to choose between making chai or attending a governance call, although by priority they are both must-haves, a suitable order will probably be much more refreshing.