One technique I like to use is a concept of a Risk Heap. If you remember from your college days, a heap is a data structure that looks like a tree and efficiently keeps the item with the highest value on top, ready to be removed. The ordering of the heap is kept in real time, and at any given moment you’re guaranteed to have the entire set of values sorted in priority order.
To apply a heap to a project, you approach a project by (mentally) inserting everything you have to do into a heap that is ordered by that item’s risk to the project. Then working your way though your project is simply a matter of:
1) Come in in the morning
2) Insert into your risk heap anything new that’s popped up over night
3) Take the first item off the top of the heap until you’re blocked and can move it no further
4) Repeat #3 until you can’t take it any more and go home
I’m willing to wager that if you use no other technique but this one, and otherwise just blunder and feel your way through a project, you still have a so-so chance for pulling the whole thing off.
The metaphor continues to work even when you stretch it a little. For example, if you take an item off the heap, do a little something to it to significantly reduce its risk and then toss it back on the heap it will settle to the right level and something else more important will pop to the top. Try to avoid unpleasant tasks, they’ll remain stubbornly at the top of the heap waiting for you to pick them up the next day.
Of course, what really separates the men from the boys with this technique is how you calculate “risk”. Personally, I don’t run every item through a computer simulation that uses a five-page formula only a Ph.D would understand. I simply use a formula that looks something like this:
risk(x) = (probability_of_failure(x) * (impact_to_quality(x) + impact_to_timeline(x) + impact_to_business(x))) – how_long_you_have_to_deal_with_it(x)
where x is the task in question.
Don’t spend forever figuring this out. Remember the concept of Decision Algebra because if you take as long building and sorting your risk heap as you would have spent just dealing with its contents, then you’ve failed before you started.
There are also a variety of ways you can get the risk formula just plain wrong, like these for example:
risk(x) = impact_to_business(x) – how_much_I_dont_feel_like_dealing_with_it(x)
risk(x) = how_interesting_solving_the_problem_is_to_me(x)
risk(x) = (impact_to_timeline(x) + impact_to_business(x) ) * how_annoying_the_person_asking_is(x)
So there you go. Try it out for a few weeks and let me know how it goes.
Ok, for the nit-picky out there you may have realized that what I’m calling a Risk Heap is, strictly speaking, a Risk Priority Queue. But a heap is close enough and, after all, most priority queues are implemented under the covers with a heap anyway. That, plus, Risk Priority Queue just doesn’t roll off the tongue the same way.