Time Management and Project Management are closely related because in both cases you’re managing time (yours or the team members) and how long it takes to get tasks completed.

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.

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”.

Whether or not this is an appropriate application of the Pareto Principle (80/20) rule, it does appear to be oddly accurate in many situations. After a software feature is complete, there is often an additional amount of usability testing, and polish work that needs to be done. Sometimes this extra work can take up to 3 to 4 times the amount of time it took to create the original feature.

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.

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.

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.

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.