Concept: When work is done out of sequence, schedule performance suffers. If value is earned prematurely, rework follows. If initial value is earned late, opportunities are lost. In both cases, there is an impact on cost.
Previous posts have spelled out the impact on cost: RTot and I/CTot. Certainly, it’s important to know the estimated costs and to know which tasks led to them, but that’s only part of the information required to actually improve schedule performance.
Turning the knowledge into practice also requires knowing when to act and what actions to perform.
Practice: The cost of noncompliance, RTot and I/C$Tot, along with allowances for uncertainty, guide decisions on when to take action and how to do it.
A previous post described the triggers and action steps for RTot. Similar ones apply to I/C$Tot.
I/C$Tot Triggers
When does a project need to take action on I/C$Tot? Here are some trigger points. They rely on quantitative triplines rather than intuitive judgments.
- Trends. A series of related 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, action is required.
- Threshold breaches. Even individual readings can invoke action. When I/C$Tot breaks out of the Contingency Zone (see Figure 1), further action is required. If the Reserve Zone is also breached, the urgency and implications of action escalate.
- Individual readings within Contingency. Although individual threshold breaches lead to action, individual readings within the Contingency Zone do not. The natural variation in schedule performance means that I/C$Tot hovers around the Fixed Budget [1], seldom aligning with it perfectly.
Figure 1
Before detailing the triggers (in particular, threshold breaches), there is one issue and a clarification that must be addressed.
Fit (or Mis-Fit) of I/CTot to Comparisons
Comparisons to Contingency and Reserve play a key role in determining when action is required. RTot’s fit to such comparisons is obvious. It’s an incremental cost, and the comparisons assess whether or not the additional cost is within uncertainty allowances.
But, why think that such comparisons apply to I/C$Tot? After all, I/C$Tot is an opportunity cost and does not add incremental cost to the project.
The answer lies in the delay associated with both Rework and Impediments/Constraints. In the case of Rework, the delay is in the ultimate delivery of value, which is late due to the need for repetitious work. In the case of I/C, the delay is in the initial delivery of value, which is late due to the absence of productive work.
Allowances for uncertainty must account for both types of delay. Looked at from this perspective, RTot and I/C$Tot both must fall within the boundaries of uncertainty allowance. If either one individually breeches thresholds, action is required. (Later, I will discuss using the two measures together.)
Threshold Breaches
Note that thresholds can be breached in a couple of ways. Historically, the emphasis has been on breaches that represent budget overruns. But, breaches can also occur with budget underruns.
Significant budget underruns often signal inflated estimates. There are 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.
On Figure 1, breaches linked to overruns fall into “+Contingency” and “+Reserve”, and breaches linked to underruns fall into “-Contingency” and “-Reserve”.
Trigger Details
As shown in Figure 1, if the I/C$Tot is greater than the Fixed Budget, but less than the Fixed Budget plus Contingency (i.e., it is within Budget at Completion), I/C costs are on track to complete within the budget, and the status of these costs is labelled as Green. [2] If the forecast is under the Fixed Budget but more than the Fixed Budget less Contingency, the outlook for finishing within budget for impediments and constraints is also good, and the I/C status is again labelled as Green. Together, “+Contingency” and “-Contingency” represent the “Contingency Zone”.
Again, as shown in Figure 1, if I/C$Tot exceeds the Fixed Budget plus Contingency but remains within the Reserve, the I/C cost is not on track to complete as planned (i.e., it is not within Contingency [3] ), but it should still finish as committed (i.e., it is within Reserve). So, the I/C cost is labelled as Yellow.
If I/C$Tot is less than the Fixed Budget minus Contingency, the project is, once more, not on track to complete as planned, and the cost is labelled as Yellow. In this case, it is Yellow not because the cost is likely to exceed uncertainty allowances [4] but because the planned amount is unsound. After all, an allowance was made for fewer impediments and constraints, and the forecast makes it appear that something was mistaken. Either the relevant uncertainties were incorrectly identified or the allowance for impediments and constraints was too large (i.e., there are fewer impediments and constraints than anticipated).
Finally, if I/C$Tot exceeds both the Contingency Zone and the Reserve Zone, the project will not meet the committed budget. There are far more impediments and constraints than allowed for originally. The status of I/C cost is labelled as Red.
By the same token, if I/C$Tot is below both the Contingency Zone and Reserve Zone, it appears that there are far fewer impediments and constraints than anticipated. The allocation for impediments and constraints appears to be wildly inflated. So, the I/C status is labelled as Red—neither Contingency nor Reserve were set at appropriate levels.
Impact of Dramatic Changes
Although not as systematic as the trigger points cited above, dramatic changes in I/C$Tot 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. [5]
Sometimes, such changes are caused by failures in reporting, but there are also cases in which the project team has made a sudden change in tactics, causing the I/C$Tot to dive or soar. Sudden, drastic changes warrant action, even if they turn out
to be false alarms.
Triggered Action Steps
The next post describes what to do once action is triggered.
Notes:
[1] As risks might or might not be instantiated, Contingency and Reserve represent variable costs to the project. When such costs are included, let’s call the total the Variable Budget. In contrast, work apart from risk management is expected to be instantiated and is in that sense fixed. Let’s call that scope of project costs the Fixed Budget.
[2] The term “status” is used here with a scope confined to I/C costs. The scope can be broadened to include the project as a whole—but only with conditions. The conditions are related to using RTot and I/C$Tot together and will be discussed in a post to follow.
[3] The project’s baseline includes Contingency and excludes Reserve.
[4] I/C costs are not likely to exceed uncertainty allowances because it appears that there are fewer impediments and constraints than estimated.
[5] There are, no doubt, situations in which the trigger should be less (or more) than 20%. As mentioned elsewhere, that’s the problem with intuitive, experiential thresholds: it’s not clear if and when they apply. Still, if the number is treated as a heuristic, rather than a fixed boundary, it’s a starting point for decision-making. |
