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.

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.

A common application of the 80/20 rule in software is described in these terms: "For any software task, the last 20% of the work takes up to 80% of the total time for the task".

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

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.

Now that you understand the 80/20 rule about software development, think about the situation for a moment with me.

When a software developer comes to me and tells me that he is 80% done with a feature and on track with his schedule, because he has only spent 80% of the scheduled time so far, I now that he's late and doesn't even realize it. I also know that the team member is very unlikely to finish his feature within the scheduled 5 days.

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.

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.

The concept of the "80/20 Trap" can be applied across a wide range of projects. It makes sense to adopt it to whatever you're working on, whether it is a multi-million dollar project or just managing your own time.

About the Author

For additional strategies on time management, be sure you claim your copy of Michael Adams' excellent free expert guide on tips for managing your time and multi-million dollar projects. Visit us at www.smart-time-management.com.

Comments

No comments posted.

You do not have permission to comment. If you log in, you may be able to comment.

Complete the details below to send a link to the page:
http://uniquebusinessarticles.com/management/the-80-20-trap-and-project-time-management.html