priorities don't work. period.
in my experience, setting priorities doesn’t work.
why? for one simple reason: 98% of the time, the priority is set arbitrarily. “we need you to take care of this. karen says it’s urgent.” so should you stop what you’re doing and take care of what karen asked? it depends.
“is this task on the critical path?” â€” whether yes or no, this answer should be the primary metric for driving your efforts. often times a manager, or the client, or someone else who may not be involved in the finer aspects of a project will ask for you to do something that doesn’t reflect the core goals of the project. just because someone “wants” something doesn’t mean that it’s the right thing for them. the critical path is a map of current tasks and their interdependencies. if one task on the critical path slips, you’re now looking down the barrel of a loaded gun called schedule creep.
more after the jump.
when you start any project â€” and most certainly within the project’s life cycle, as requirements change â€” you should map out the tasks necessary to complete your stated objectives, and identify the critical path. many times you’ll find one key task that ends up being the driving force behind a vast majority of your work. this critical path will help keep you honest, and ensure that you’re completing that which should be completed rather than what you, or the client, wants completed. but the critical path isn’t the only metric you need to focus on; you also need to consider the level of effort involved.
you need to ask, “how much effort is this going to take?” when you boil it all down, you have 40 hours a week in which you can work. that’s 40 hours to get as much done as possible. if you have tasks that require a small amount of effort, why not pick the low-hanging fruit first? because in the end, it has to get done anyway â€” right? powerpoint decks don’t create themselves, and visual basic applications don’t troubleshoot themselves (though i long for the day!). if you look at effort, as well as the priority of the item, you can develop a matrix to show which tasks can be completed, and which cannot. it’s unrealistic to expect someone to complete a critically important task with a high level of effort and also find the time to complete a medium ranked task that also has a high level of effort involved.
it’s an unrealistic expectation because, as mentioned, your work week is limited. in fact â€” the man-hours on your project are probably limited as well! if a task falls outside of the matrix, you need to re-visit it and make sure that you’ve categorized it properly in terms of critical path, effort, and priority. however, if you’re certain that it was categorized correctly, then it’s time to bring the nasty pants out of the closet and tell the client their longed for bells and whistles won’t make it into the project â€” unless there’s extra funding (for more man hours, jelly doughnuts) or they wish to bump some other tasks from the current work load.
without having some sort of quantitative algorithm or qualitative methodology behind the labels, you risk finding yourself buried under a mountain of uncontrollable tasks and requirements.
so stop setting priorities; start thinking in terms of critical path and effort, and start working.