What does 'Priority' really mean?

This post originally appeared June 20, 2011 on BetterProjects.net.


Hello everyone from my multiple week hiatus. My deepest apologies for my prolonged absence. I was out one week on a family vacation and then had two weeks of hip (more like neck) deep work that piled up while I was out of town and had to get done before I got back to blogging. All of that is now taken care of, my batteries are recharged from some time away and I’ve got a whopper (I hope) of a first post for you.

Lets talk about priority. Yes, I know, I said I have a whopper of a topic and priority, well, doesn’t seem to fit that kind of a heading. Hang on with me for a moment and I think you’ll agree that priority doesn’t mean what you think it means.

The traditional view of priority

While on the plane ride out to California, I listened to one of my regular podcasts, Back to Work, hosted by Merlin Mann and Dan Benjamin. It was episode 17 and Merlin spent a lot of time opening my eyes as to what priority really means.

If you’re like me, when you hear ‘priority’, you might picture a large group of people sitting around a conference room table trying to determine which items on this big feature list they want done first. Its all about scarce resources and how to best deploy those resources.

Maybe you take a different viewpoint; maybe to you, its a notepad that contains a bunch of tasks that you have to get done today. You drop off your personal belongings at 8am and begin to complete those tasks in the order that your boss expects them to be completed.

In these views, priority is all about order and completeness. There is no thought that any of these items won’t be done, its just a matter of how long until they are complete. To me, this had always been my thoughts on priority as well, even though it never really sat right with me.

My issues with priority

There are two things that always bothered me with this view of priority. During really large projects, I noticed a tendency for features that were either really difficult to implement or that were falsely labeled as important, almost always fell off the final deliverables list somewhere along the way. When we delivered a release, all of these things which people had given enough priority to be included in the initial scope just never made it to the finish line.

Stranger still was the rarity in which someone would complain about one of these items missing from the final product. Sure, the person who came up with the idea may grumble about it not being there, but when everything was said and done, the non-inclusion of these functions were non-issues.

For the really difficult to implement issues, they almost always fell apart not because the technology didn’t exist or was too expensive, but that the business rules and definitions were always so vague or poorly defined that no one in the business areas even really understood what was being asked for. When those items failed to meet the final build, no one noticed because no one really understood what that thing was all about in the first place.

When it came to items that were falsely labeled as important initially, it was almost always to appease the ego of one stakeholder. Often times these items were tossed in to scope, even though they didn’t really fit with the goals of the project, just to mollify someone who was offended that the genius of their pet project wasn’t recognized by everyone else. Since no one ever saw this as a priority anyway, when it fails to be delivered, no one really complains about its absence.

What we’re missing

What is missing in all this discussion of priority is a concept that, at first glance, seems like it doesn’t really come in to play anyway. Yet, if we’re really going to talk honestly about priority, you can’t without it. Merlin nailed it when he discussed priority being nothing more than a way to quantify sacrifice.

Yes, sacrifice. When something is correctly prioritized, you’re really discussing your value system showing what you will not do more than what you will do.

We need to reframe the discussion about priority. We need to change the thought from being “Here’s a huge list of stuff, we’re going to do all of these in this particular order” to “Here is the small number of things we’re going to do and do really well, because these are the things that matter to us. Every other idea may be good, but we’re going to sacrifice and not do them because they don’t fit with what we really do want to do.”

The outcome

Why would we want to change our viewpoint on priority? Isn’t the traditional viewpoint better because it gives us a direction on what to go do after the current project?

No, it isn’t. There is an assumption in an ordered list that we’ll have the time and resources to continue completing items until the list is complete, but that assumption is faulty for many reasons. Projects are time bound activities and there is no guarantee that there will be a next project after this one, which fixes or adds in everything this first projected failed to include.

So is our alternative to just make all projects omnibus, where they contain larger and larger sets of requirements so that everything becomes a 'priority 1’? I don’t really have to tell you the answer to that is 'No’, because we’ve all seen those projects and we all know that even if they reach completion and deliver a final project, its never the exact product anyone wanted delivered.

The answer then, is smaller projects and a sharper focus on cutting out everything we can. We get that laser-like focus, we sacrifice everything we can live without in order to perfect the things which truly matter.