Project Time Management - Beware of the 80/20 Trap
Michael Adams
Part of "Project Management" involves managing the time of project team members and the time it takes to complete project tasks.
When I manage a project, I emphasize that each team member is responsible for developing their own abilities to manage their time and set schedule of their work. Beyond helping team members tune their ability to estimate how long a task will take for them, I'm often involved in reviewing their work and helping to make schedule adjustments along the way.
The "80/20 Trap" is one of the biggest pitfalls for team members new to scheduling and managing their own time.
Before continuing, I have to explain that I work with software developers. What I'm going to describe is my experience working with software developers, but is also something that other project and time managers can apply to their own situation or projects.
In the software business, sometimes the 80/20 rule is applied this way "The last 20% of the work takes 80% of the time to complete".
It's a separate discussion whether the 80/20 rule I just described is truly the Pareto Principle, but suffice to say, I've seen it hold true more often than not during software development. The main reason it holds true is that as a feature is completed, there is usually a period of polish work and usability testing that must happen. This extra time can often take up to 3x or 4x the time it took to create the feature in the first place.
With practice, smart project managers will usually create a separate task and schedule for the polish and usability testing time for each feature, but some don't. No matter whether they do or not, the programmer usually has to spend extra time doing debugging or clean up on his code just to get the feature ready for polish or usability testing.
So think about this with me for a moment.
With this new understanding, you and I both know now that when a programmer claims to be 80% done with a feature, he's going to need more than 20% of the total time to finish is work. Taking 4 out of 5 scheduled days to do 80% of the work means that the programmer is late and unlikely to finish the feature within the next day.
Being a programmer or managing programmer can be difficult jobs. If the team does not understand the 80/20 rule, then it's almost certain that the project will repeatedly miss its delivery day.
Needless to mention, it's always best to point out the "80/20 Trap" when a programmer, or anyone, falls into it. Understanding that the last 20% of the work can take 80% of the total task time, makes it critical to address it as soon as possible.
If you don't and everyone just waits to see what happens, you'll have quality issues and just have to deal with the delay at a later date (like at the end of the cycle) when there is even less time and flexibility for getting things done well.
Whether you make software or not, use this notion of the "80/20 Trap" to help raise the predictability of your delivery dates, not matter what type of project you're working on, whether you're only working with yourself or managing any sort of team.
About the Author:
