photo by stress-relief, via flickr

in my experience, setting priorities doesn’t work.

ever.

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.

photo by mike_lockie, flickr artist

it’s going to happen.  no matter how much you plan ahead, or how much you think you might know — how comfortable you are in your abilities… you’re going to lose sight of your overall vision.

scope creep happens, and unfortunately it happens often. we all want to create amazing things, and we all want to deliver the very best we can to our clients. many times it’s the client who makes the changes! but either way, changes happen. instead of doing x, we do x and add on y because it makes x better in some way.

one of the most difficult things to do is telling ‘no’ to people who say, “you know what would be good?…” but there are times when it’s absolutely necessary. why? well no matter what you’re doing, you always have a main mission; every step you take along the way should be made to help you reach that end state. simply put, anything else is ancillary. so why do we always lose sight of where we’re going?!

because it’s fun to be creative! it’s awesome when you sit down, talking either among your internal team or with various members of the client’s organization and brainstorm new ideas (new ideas grow the business after all). we often get into situations when we have status updates and look at our progress only to find things that we want to change, areas for improvement. unknowingly, we tend to jump in without putting a toe in the water first.

in every project you do — maybe even every task — you have to set up points in time to have a reevaluation of your situation. ask yourself: “what am i supposed to be doing? what am i doing? does this get me closer to my end goal?” if you don’t set up these meetings or times for personal reflection, you’ll lose sight of what your original purpose was and find yourself slipping off track.

so set some time aside periodically to step back from what you’re doing; stop focusing on the trees, and find your forest.

perhaps the most important part of project management when creating schedules for work is the inclusion of wiggle room.  there are issues that occur when working on projects — large or small.  some of these issues are known, and some are unknown, and some are even known to be unknown in that you know the issue will occur, but not when or what impact it would have on the project.  as much as we’d like to — the fact of the matter is that we cannot fully remove all risks and issues from a project.  what we can do, however, is to study those risks and issues and minimize their effects.  one of the best ways to do this is by scheduling wiggle room.

on a project, you might come across a piece of work that takes too long.  a task that — for whatever the reason — doesn’t go as you expected that it should.  it could be as simple as having your main resource who’s working on the core programming come down with a cold or virus that leaves her out of the office sick for 3-4 days.  it could be something as drastic as funding suddenly being removed from your project because it needs to be allocated to something more important.  this is actually fairly common in my experience, and one of the only recourses to help guard against the entire project becoming derailed is to include time into the schedule to deal with these kinds of unforeseen issues.

think about it as buying shoes.  sometimes you find a shoe that fits when you’re standing.  it hugs those parts of your foot that a shoe should hug.  it provides support for your ankle, or your arches, or is either narrow or wide enough to fit the top of your foot comfortably.  and sometimes that shoe, when you walk, becomes too tight and abrasive.  it causes pain, calluses, sometimes bleeding if the sore is bad enough.

you wouldn’t buy that shoe, would you?  so why would you sell that kind of a project to your team and to the client?  if you look at a project’s schedule, and say “best case we can make deliver this on [x] date,” don’t ever give that date to the client.  i can almost guarantee you that — like the shoes — you will feel an instant pain and pressure, suffer long-term stress and discomfort, and possibly ‘bleed’ your company through losing a client, or damaging other projects because of having to scramble to get the project back on schedule.

wiggle room should be built-in.  the schedule should be in keeping with the expectations of the work, but also have some time allocated for dealing with issues that you might find in doing the work, problems found in testing, problems during the implementation, or problems like the unforeseen issues i had mentioned above.

bad situations happen in project management, and you’ll find yourself up to your neck sometimes.  but you can breathe a little easier next time knowing you have that wiggle room to get yourself out of a tough spot.