Strictly speaking, if you have a rigorous quality process in
place, there should be no reason for a discussion of rework. In fact, it might
be said that rework is the result of not having rigorous enough quality
processes in place to begin with. 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.

Rework is not the same as your normal process of gathering
feedback on deliverables. If you create a document, for instance, 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 publish your completed document
and then find errors in the content, the resulting updates would be considered
rework. Likewise, let's say you are developing a software module. If you test
the module and declare that is complete, the assumption is that it is, in fact,
complete and final. However, if further testing reveals flaws that need to be
addressed, this additional effort is considered rework.

Tips in your inbox

Looking for expert IT project management? Get the help you need from TechRepublic's free Project Management newsletter, delivered each Wednesday.

Although you may accept some rework as inevitable based on
the nature of the project, it does not mean the project manager and project
team should not strive to eliminate it. You and your team should always strive
to eliminate defects and rework by continually improving your processes.

If there is to be rework, focus on finding it as early in
the lifecycle as possible. Remember that errors in the analysis will propagate
into errors in design and errors in construction. If you don't find the errors
until the testing phase, there might be rework required throughout the
lifecycle, including the prior analysis, design and construct phases. On the
other hand, there is less of a chance of propagating requirements errors
downstream if you have a rigorous process to validate that your deliverables
are complete and correct before moving to subsequent project phases.

You can track rework to determine how much of your project
time is spent "thrashing" or working on the same problems twice. For
instance, in the testing process you can track the number of errors and the
effort associated with resolving the errors. Much of this problem resolution
will require rework of previously "completed" deliverables. When
these errors are corrected, you may find that the change does not work
adequately, which will cause more rework. You may find that fixing one problem
may break something else. This second, unintended error will cause even more
rework. You can track the total number of errors that require rework, as well
as the effort hours associated with the rework.

The nature of rework is that it is caused by problems in
your quality management process. Rework is needed to bring a deliverable up to
the level of quality it should have been at to begin with. One of the
responsibilities of a project manager is to put into place a quality management
process that seeks to keep rework to a minimum.