The 80/20 Trap And Project Time Management
Part of “Project Management” involves managing the time of project team members and the time it takes to complete project tasks.
Beyond simply being the guy in charge, a good project manager helps team members develop their own time management and scheduling skills. Another part of the job is reviewing the work done on the project and evaluating whether the project will be delivered on time.
One of the biggest traps I’ve seen individuals fall into is what I call the “80/20 trap”.
Although I work with software developers, I believe that the “80/20 Trap” is something that applies in one form or another across many different types of projects and is important as a general concept for almost every project or time manager.
There’s a version of the 80/20 rule for software which says “It takes 20% of the time to do the first 80% of the work and then 80% of the time to do the last 20% of the work”.
I’m not sure that’s a proper application of the 80/20 Rule (Pareto Principle), but it seems to hold true in many cases because there is often a level of polish and usability testing after a feature is complete. This polish and usability testing often takes more time than anyone expects even as much as 4x the time to create the original feature (thus the 80/20 rule).
Creating a separate schedule for polish time and usability testing is the smart thing to do, but some managers forget to do it. Even if the project manager does schedule these two sets of work separately from feature development, the programmer will still often need more time than expected to simply debug or clean up his feature for the polish/usability testing phase.
Now that you understand the 80/20 rule about software development, think about the situation for a moment with me.
If a team member comes up to me and says “I’m 80% done with this feature and I’m on track because I spent 4 out of my 5 scheduled days so far”, you now know as well as I do, that this team member isn’t going to finish their feature within the scheduled time allowed (in this case it was a total of 5 days).
Programming can a difficult job, but when neither the programmer or the manager understand this 80/20 rule, software delivery dates can slip wildly and repeatedly until things get under control.
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.
When you see it and don’t address it, you’re just pushing your problems in front of you, and things will get worse each day the project progresses. In other words, you’ll pay for it at some point so you might as well deal with it as soon 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.
Filed under: Business