A wise person once told me to eliminate “I don’t have time for _______” from my vocabulary and replace it with “_______ has not yet become a priority for me”. And if you think about it, they’re right. Every time we say things like this, it’s usually as a crutch to hide the real truth. If I say “I don’t have time for going to the gym”, what am I really saying? I am saying “Going to the gym has not yet become a priority for me”. We have time to do anything we want – it may just mean foregoing other opportunities or planned activities.
Bringing it back to the workplace, let’s talk for a minute about how we fill up our calendar and spend our time via prioritization. Prioritization sounds like something extremely simple and straight-forward. If I have a list of ten things, I simply need to put them in order or sequence for completion and start knocking them out. Some of them may be big, some small, but all in all – they have to get done in a certain order in a certain amount of time to satisfy a colleague, a boss, a project, or some other external factor. And that’s how I prioritize them (or, often times, how I let someone else prioritize them for me).
But, I have found that prioritization always seems to be a lot more difficult than that or yields a poorly prioritized set of tasks. At a minimum, in my experience, the ability to effectively prioritize things (whether they are projects themselves, tasks, or effort/focus as a whole) is something that is widely lacking across the majority of Corporate America. Everyone likes to think that they are masters of prioritization, but they usually land on prioritizing the wrong things at the wrong time to drive expected results. And, once you start chasing your tail, it’s really hard to course correct or reset the clock.
So what’s the answer? How should prioritization be approached in order to ensure, at a minimum, a greater chance of prioritization occurring accurately enough to fulfill originally stated objectives/mission in a relatively appropriate timeframe? As with most things, I don’t claim to have all the answers. But, in my overly-logical and methodical approach to life (at some point I’ll reveal my Myers-Briggs/DiSC/etc profiles and my wider thoughts on those programs – it will be wildly anti-climactic, trust me), I think I can provide at least a blueprint or skeleton of things to consider in your own quest to reach an accurate prioritization:
- Consider the size, schedule, cost, and complexity of initiatives: Sure, it may sound great to do the hardest, most expensive, longest project first because it has the greatest return – but is there opportunity to knock out a few shorter-term or easier projects to give quick wins back to the organization/team in parallel to kicking off a wider effort with the massive project?
- Consider your senior leadership and the organizational landscape: What will make the senior team happiest? What will have the best benefit for the business as a whole? Asking these types of questions ensures you are keeping your leadership happy and likewise considering yourself and your efforts in the context of the larger group, which may very well already have corporate strategic goals in place that make certain efforts of yours more important (at least on the perception side) than others.
- Consider your peers and business partners: What types of projects are they completing or taking on sooner which may have synergies or ties to your efforts? Does sequencing your projects in a certain way make more sense to align efforts and consolidate integration/change management/rollout efforts? Killing two birds with one stone is always preferable to reinventing the wheel in my experiences.
- Consider seasonality and planned downtime: Does your organization typically have lots of down time between Thanksgiving and New Year’s? Will it be really difficult to hit a January 1 launch given all that time off? Are other people thinking the same as you and trying to cram everything to hit a specific date in which case it might not make sense to have everyone launch their new projects/processes at the same time? Are there scheduled events which need to be considered prior to developing a roadmap/implementation strategy/plan
- Consider the existing pipeline: Similarly, it is extremely rare that we get to prioritize new initiatives or develop roadmaps in a silo. There is almost always already some set of planned activities that are non-negotiable (or, at a minimum, will need to be a lens while reviewing your own priorities), and those have to be taken into account when embarking on any new greenfield set of priorities.
- Consider the morale of the team: Lastly, and (in my opinion) most importantly, how will the people who are directly (or indirectly) impacted by this event or effort receive the project/task? Change for the sake of change is never a good thing – people need to know WIIFM (What’s In It For Me – another topic I will revisit many times I’m sure in the not so distant future). There are projects that boost morale, and those that drain it; be sure you aren’t piling on too many of the draining ones in your sequence, and ensure your prioritization is manageable on the people side. If you’re unsure of how your project or task may be received – ASK! People love the opportunity to spill their own ink on plans; it creates a sense of ownership in them (and I have found that people will work much harder if they know they had a hand in the recipe).
Again, I know these may seem to be basic and largely common sense tips, but you wouldn’t believe how many times I’ve seen prioritization fail even with the brightest of teams. So, next time you go to roadmap or prioritize a set of efforts, please have some consideration.
Til Next Time,