Main Menus
Make cash!
| DavidSmythe Articles: 14 | |
| KathyNelson Articles: 12 | |
| MichaelBenifez Articles: 14 | |
| ColinJoss Articles: 7 | |
| DaveFu Articles: 12 | |
This article is licensed under a Creative Commons Attribution-No Derivative Works 3.0 Unported License, which means you may freely reprint it, in its entiretly, provided you include the author's resource box along with LIVE links (without "nofollow" tags).
View PDF | Print View | Html Version
by: MichaelAdams
Total views: 2
Word Count: 539
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.
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.
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.
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).
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.
Now that you understand the 80/20 rule about software development, think about the situation for a moment with me.
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.
Being a programmer or managing programmer can be difficult jobs. If the team does not understand the 80/20 rule, then it's almost certain that the project will repeatedly miss its delivery day.
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.
Whether you make software or not, use this notion of the "80/20 Trap" to help raise the predictability of your delivery dates, not matter what type of project you're working on, whether you're only working with yourself or managing any sort of team.
For more strategies on time management, make sure you check out author Michael Adams' exclusive free expert guide on tips for managing your time and multi-million dollar projects. Learn more at www.smart-time-management.com.