ProjectFlightDeck

Concept: If 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 take the waste out of the project.

Knowing that rework will be required and even knowing which tasks are likely to cause rework are important but only part of what needs to be known. It’s also necessary to know when action is required and what action must be taken.

Practice: Rework costs (Rework$) and allowances for uncertainty guide decisions on when to take out the waste and how to do it.

When does a project need to take action on rework? Here are some trigger points. They rely more on quantitative triplines than intuitive judgments [1]:

• Trends. A series of related Rework$ readings indicates a trend. At ProjectFlightDeck, we generally require at least three readings headed in the same direction to mark a trend. When the trend is away from the baseline and toward a threshold, action is required.
• Threshold breaches. Even individual readings can invoke action. When Rework$ breaks out of the Contingency Zone (see Figure 1), further action is required. If the Reserve threshold is also breached, the urgency and implications of action escalate.
• Individual readings within Contingency. Although individual threshold breaches lead to action, individual readings in the Contingency Zone do not. The natural variation in schedule performance means that Rework$ hovers around the Fixed Budget, seldom aligning with it perfectly.

Although not as systematic as the trigger points just cited, dramatic changes in Rework$ from one period to the next can signal the need for action. At ProjectFlightDeck, we consider any change of 20% or more cause for action. [1] Although such differences are sometimes caused by failures in reporting, there are cases in which the project team makes a sudden change in tactics, causing the rework forecast to dive or to soar.

Whether it is a trend, breach, or dramatic shift that demands further action, the generic response is the same:

• identification of potential problems,
• root-cause analysis,
• action planning for remediation,
• remediation, and
• stakeholder communication.

The urgency of the analysis, extent of remediation, and type of communication vary depending on root causes and remediating actions.

If the project status is in the red zone (Figure 1), execution of the steps is accelerated. Unfortunately, there is a tendency in such cases to “jump to a solution”—to skip analysis and planning and take action immediately. Until the root cause is identified, however, there is little chance that such action will work. [2]

In this context, root-cause analysis should also trace Rework$ back to an uncertainty allowance. The Rework$ might be related to an identified epistemic uncertainty that is covered by Contingency. Or, it might be related to the aleatory uncertainty accommodated by Reserve. The final alternative, and most concerning, is that the Rework$ was not covered by the plan. In that case, a new baseline is required--a non-trivial consequence, as described here.

For a status in the yellow zone, the response is essentially the same, but it is moderately paced, involves smaller adjustments, and employs low-key messaging.

Note that remediating actions vary widely but commonly contain rapid, and sometimes extensive, shifts in schedule, budget, and even staffing.  Communications reflect the seriousness of the problem and extent of adjustment required.

Finally, although it is not called out as a specific step, it is important to monitor the results of remediating actions. It is only by doing so that the efficacy of the solution can be assessed and further adjustments can be made.

Thus, the impact of rework can be quantified, systematically assessed, and used to shape actions for improving schedule performance.

Notes: