

Perpetually Almost Finished Projects

The previous article on multitasking relates so closely to this one by Tyner Blain that I was tempted to merge the two posts.  But, Perpetually Almost Finished Projects deserves its own.

Your project is almost finished. Last week, it was almost finished. And you suspect that next week, it will still be almost finished. Why does this happen, and what can you do about it?

This references Zeno's Paradox where the over-analytical mind thinks about crossing a room by crossing half the remaining distance.  Zeno can never make it all the way across because there is always that one little bit left.

Tyner's solution is to move from percent complete reports to a digital "complete" or "not complete" status on shorter task chunks (2 - 8 hours).

I am particularly fond of the approach of I've learned with Theory of Constraints: ask for time needed to complete the task, AND ask "what are you waiting for now."  The second piece is not meant to be accusatory, but to collect data for continuous improvement.  If you find the same "waiting for" item creates problems for projects over and over again, then do something about it!

The other element of a good solution is that these tasks need to be tied into an accurate project network, so that the project manager can see which of the incomplete tasks are impinging upon the success of the overall project.  It is not the case that all tasks are equally important.  The PM needs a mechanism for judging the impact of delays and early completions, so that resources can be redeployed in a sane fashion.

Changes in a community create friction

Multitasking and fragmenting still don't work