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. 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". 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". 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. 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. So think about this with me for a moment. 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.
Please Rate this Article 5 out of 54 out of 53 out of 52 out of 51 out of 5
Not yet Rated
