Don't Fall Into the 80/20 Time Trap With Project Management
View PDF | Print View
by: MichaelAdams
Total views: 1
Word Count: 560
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.
One of the biggest mistakes I've seen when it comes to team members scheduling their time, is when they fall into what I call the "80/20 time trap" or more simply the "80/20 Trap".
My work involved managing software developers and what I will cover is my experience at that task. This "80/20 Trap" is something that can be applied, with a certain amount of experience, across a wide variety of 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.
Smart project managers schedule usability and polish work as separate tasks from just implementing a feature, but most don't. Even if you do though, there is often a certain amount of debugging and clean up time a programmer needs to do just to get the feature ready for usability testing.
Knowing what you know now, consider the situation 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.
As a former programmer, I know coding can be a difficult job. Scheduling is hard enough already, but when neither the programmer or the project manager understand the 80/20 rule, predicting the delivery date for the software is nearly impossible and it's near certain that the project will be late.
It's not actually that hard to fall into the "80/20 Trap". I've even seen it happen to experienced people. The best thing to do when you see it is to address it right away, in a calm cool and professional manner.
In the situations where no one called out the "80/20 Trap", quality issues and problems just pile up on themselves each day that passes, making it even harder on everyone involved. Suffice to say, it's always best to address the issues as early as possible.
Beyond software, I think the idea of the "80/20 Trap" is useful to understand for all types of projects and can easily be adopted to them. Project and team size doesn't matter, the principle scales, even if it's just you managing your own time and a personal project.
About the Author
For more tips and hints about time management, make sure you claim your copy of Michael Adams' exclusive free expert guide on tips for managing your time and multi-million dollar projects. Visit us at www.smart-time-management.com.
HTML For Publishers
Please note: This article is free to reprint but all links must remain active.
Rating: Not yet rated
