You are here: Home Blogs Four Thoughts on the Nature of Project Rework
Wednesday, 21 September 2016 19:36

Four Thoughts on the Nature of Project Rework

Written by 
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2016.21.09

Four Thoughts on the Nature of Project Rework

Rework refers to the time spent correcting deliverables that you thought were already complete and correct. Strictly speaking, if you have a rigorous quality process in place, there should be no reason for rework. In fact, rework is the result of not having rigorous enough quality processes in place. But, let's be practical as well. No project can afford to spend the time and effort that would be required to guarantee that every deliverable is perfect the first time. Even a company operating at a 'Six Sigma' level has some small probability of error.

There are a few things to keep in mind about rework.

·        Rework is not the same as your normal process of reviewing deliverables. If you create a document and you circulate it to gather feedback, the resulting changes are not considered rework. These changes to the document are your way of making sure that you have a good document to begin with. However, if you finalize the document and then find errors in the content later, the resulting updates would be considered rework.

·        Focus on finding rework items it as early in the project as possible. Errors that are undiscovered early in your project will likely propagate into more errors later in the project. The later the errors are uncovered, the more costly and time-consuming they are to correct. 

·        You can track rework to determine how much of your project is spent “thrashing” or working on the same problems twice. When you encounter errors or defects in your project, try to classify them as "normal" errors that are a part of building the deliverables, or rework on deliverables you thought were already complete.

·        Rework is not the same as a scope change. Rework is caused by problems in the quality management process. Rework is needed to bring a deliverable up to the level of quality it should have been at to begin with. Scope change refers to modifying part of the solution because of a new requirement. The effort and cost associated with rework needs to be absorbed by the project. Effort and cost associated with scope changes should be agreed to and paid by the client.

Although you may accept rework as part of the nature of the project, it does not mean the project manager and project team should not strive to eliminate it. Your goal should always be to eliminate defects and rework by continually improving your processes.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit or contact us at
Read 3391 times
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Parse error: syntax error, unexpected end of file in /home/spektmedia/public_html/wp-content/plugins/ccode.php on line 82

Who's Online

We have 670 guests and no members online

Got something to say?