The Project Notebook

Handling Project Re-work

A reader at asked:  How do I account for project re-work in the project plan? 

In anticipation of us all doing the right thing, there really isn’t any formal guideline for handling re-work in a schedule which is universal.  Every organization sets their own norms.  In fact, I’m not sure I would want to call it out as a separately tracked item unless there was an ongoing issue with re-work from a project team, which does happen.  The expectation for any properly managed project is that some tasks will come in early and some will be late for a variety of reasons, including re-work.  The end result is that you hit the mark at the end of the project, or at least come close (within 10-20%).  Perhaps the better question is: How do I keep all my projects on track?

I have used a few different methods myself in the past:

  1. After the project schedule is complete, add a portion of your contingency time to all tasks resulting in deliverables.  If re-work isn’t significant or required to be tracked separately, this is ideal and you just track the schedule and actual time spent in the plan without doing anything special.  In general, as time on the project progresses, some tasks will come in early and some will be late (for many different reasons including re-work).  In some environments (e.g. software/technology) there will be other documents such as bug tickets from which you can derive the project time on re-work if necessary. Track in a separate spreadsheet if necessary.
  2. Possibly in conjunction with #1, and if re-work tracking isn’t important, just track the rework as actual time against the original task or the QA task for the deliverable being re-worked.  Without the contingency, your performance against baseline will not be good, but you will have accurately captured the project timeline status.
  3. If re-work tracking is important to the project and your organization, add new tasks and deliverables to the project without re-baselining.  These too will be deviations from the baseline.  If the deviations become too significant, then you may want to consider re-baselining the project which will mean re-estimating all tasks going forward.

The bottom line is that estimates are exactly that — estimates.  We don’t need to tell people “no rework allowed”.  At the same time, we need to maintain the expectation that everyone is doing the right thing and trying their best to minimize re-work.  Well managed projects tend to “hit their mark” because some tasks are early and some are late.  If you are not experiencing this, there may be some issues with your estimating process or scheduling process, and you need to reflect on how to best manage that.  If this is allowed to go on for too long, you will tend to build dysfunction into the project team and the organization.  The PMBOK® Guide tells us that the result of poor quality and a lot of re-work is a demoralized and low performing team.

Another possibility for frequently missed projects is that expectation setting may need adjustment.  I’ve always set the expectation, especially on software and knowledge projects, that if you are going to be late (for any reason) that you will “go the extra mile” and put in a little overtime to bring the project back on track.  I don’t put this out up front — if someone is repeatedly missing the mark I will ask they meet this expecation in the future.  Over time, this usually helps improve the estimates and inputs into plans — after all, who wants to work nights and weekends all the time?  This is a gentle and fair way of encouraging the team to perform.

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

Category: Notebook Page

Tagged: , ,

Leave a Reply

Past Articles

Links and Buttons

Add to Technorati Favorites

Blogging Fusion Blog Directory

San Diego Blog News

Submit Express Inc.Submit Express - SEO Services


All opinions on this blog are those of the site owner and do not reflect the opinion of any other entity. Information on this site may contain errors or inaccuracies; The Project Notebook does not make warranty as to the correctness or reliability of the site's content. If you believe something on this site is inappropriate and should be removed, please contact the site owner at sdcapmp at aol dot com.


"PMP" is a registered mark of the Project Management Institute.


© 2010-2012 Ray W. Frohnhoefer, MBA, PMP, CCP