ProjectFlightDeck

Concept: When work is done out of sequence, knowledge gaps are inevitable. To bridge the gaps, performers must make assumptions about missing inputs. At some point, the missing information becomes available, and when it does, it often differs from the assumptions. That means what has already been done must be reworked.

Rework is doubly wasteful. First, and obviously, re-doing what has already been done is lost time and money—time that could be spent completing new deliverables. Second, and less obviously, the time spent making the assumptions is also lost time and money—it too could have been spent on completing new deliverables. In both cases, performers feel frustration with a work process that is the exact opposite of “one and done”. They want to stop wasting time.

Knowing rework will be required and even knowing which tasks are likely to cause rework are important but only part of what you need to know to stop losing time.  What’s lacking is a fix on the impact of rework.

Practice: Given that the rework cost is a specific quantity, it can be compared to allowances for uncertainty. Recall that allowances for identified risks (Contingency) and for unknown unknowns (Reserve) should be included in overall project estimates. [1]

Part of risk assessment should include the impact of rework, for both specific deliverables and for the project as a whole. If the project plan contains allowances for rework, the rework forecast can be assessed against those allowances.

At ProjectFlightDeck, we routinely include “refactoring” as an element in our Work Breakdown Structures (and Agile Task Lists). It’s an acknowledgement of our incomplete knowledge at the start of a work product. Given imperfect knowledge, there’s bound to be revision as the work proceeds. Performing work out of sequence pretty much guarantees that refactoring will be required.

Such “refactoring” is part of the project’s allowance for uncertainty. Sometimes, it’s the only explicit allowance for rework. Other times, although less frequently, there are lump sum allowances for rework embedded in Contingency and Reserve.

Assessment of rework’s impact fits best with specific allowances for it. Otherwise, the cost of rework is summed with other variances, and the comparison is to overall Contingency and Reserve. The description that follows assumes that the uncertainty allowance is specifically for rework.

The assessment follows the pattern used for other ES metrics. [2] The only difference here is that the performance zones are related to the Fixed Budget rather than the Planned Finish, and the thresholds are related to costs rather than durations.

Rework$ has performance zones that look like this: 

 Figure 1

The threshold values for the performance zones look like this:

Figure 2

Before discussing the figures, some clarifications are necessary.

• Contingency is the response to predictable uncertainty and Reserve to uncertainty that cannot be predicted. Historically, the emphasis has been on uncertainties that cause budget overruns. But, there are also uncertainties that result in budget underruns.
• It’s important to identify underruns because they can indicate inflated estimates. I’ve seen cases where an estimate goes through several levels in an organization, and each level adds its own uncertainty allowance. The result is a budget that unnecessarily drains resources from other initiatives. Running under plan is not always better.
• Uncertainties that cause overruns are addressed by “overrun” Contingency and Reserve allowances. Uncertainties that lead to underruns are addressed by “underrun” Contingency and Reserve allowances.
• Consistent with PMI principles, Budget at Completion includes Contingency but excludes Reserve. Preferably, Rework$ is compared with allowances specifically for rework. Otherwise, its impact must be grouped with other cost variances and compared to the overall allowances.

The next post describes how to use the figures to stamp out waste on your project. [3]

Notes: