The 80/20 Trap And Project Time Management

I normally write about Time Management, but another topic “Project Management” involves a large amount of time management across a set of project tasks or team members.

Part of my job as a project manager is to help teach team members to be responsible for improving their ability to manage their time, as well as schedule their own work. Additionally, I’m often the one who directly reviews their work, making adjustments to the project schedule 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”.

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.

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.

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.

Suffice to say, the best answer is to address the fact that if only 80% of the feature is done and 80% of the time has passed (”80/20 Trap”), you need to address the issue of being late right away knowing that the last 20% of the work can indeed take up to 80% of the total time to get it done.

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.

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.