Concept: It’s one thing to measure schedule adherence. It’s another thing to actually use it for schedule management. The gap between the numbers and action is filled by thresholds. They tell us when the numbers warrant action and with what urgency.
Not just any numbers will do, however. To be credible, thresholds must meet certain conditions. They must not be idiosyncratic or arbitrary. They must not be complex. They must be ready-to-hand, that is, not require excessive time to analyze and interpret. Finally, thresholds must be sensitive to the unique circumstances of each project.
In short, thresholds must be consistent, simple, accessible, and relevant.
Consistency: thresholds must apply equally across PMs and projects.
Simplicity: thresholds must be easy to understand, without convoluted logic and sundry exceptions.
Accessibility: thresholds must offer quick guidance without demanding lengthy study.
Relevant: thresholds must take into account the unique attributes of each project.
These conditions set a high bar for thresholds. At ProjectFlightDeck, it took considerable time and a number of false starts to find credible thresholds, [1] but we were able to do so for several metrics, including R$tot and IC$tot.
Practice: Action on Schedule Adherence problems depends on comparing R$tot and IC$tot to thresholds. There are several typical scenarios for such comparisons.
- Trends: A series of related Schedule Adherence measurements headed in the same direction indicates a trend. At ProjectFlightDeck, we generally require at least three such readings to mark a trend. When the trend crosses thresholds, action is required.
- Singletons: Even individual measurements can invoke action. When a metric first breaks a threshold, further action is required. The more thresholds that are breached, the greater the urgency and implication of action.
- Exceptions: There is a natural variation in schedule performance. Sometimes, that means metrics hover around thresholds. In such cases, a single breach does not demand action. It’s better to wait for a trend to emerge.
What are the threshold values for R$tot and IC$tot? The uncertainty allowances that are already part of the project plan fit the bill. By comparing R$tot and IC$tot to Contingency and Reserve, we have a way to quantitatively assess when action is required and with what urgency.
Pro: An example illustrates how well this works. Say that R$tot trends above Contingency. After the third successive reading beyond the Contingency threshold, action is demanded. If the trend crosses Reserve, the response becomes urgent and generally has far-reaching impacts. [2] (For details on the evaluation process, see Appendix B.)
R$tot’s fit to such a comparison is obvious. It’s an incremental cost, and the comparison assesses whether or not the additional cost is within the uncertainty allowance.
But, why think that such comparisons apply to IC$tot? After all, IC$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. It unifies the approach to the two metrics.
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 Impediments and Constraints, the delay is in the initial delivery of value, which is late due to the absence of productive work.
Contingency and Reserve must account for both types of delay. Looked at from this perspective, R$tot and IC$tot both must fall within the boundaries of uncertainty allowance. If either breaches thresholds, action is required.
Con: In practice, it’s rare to see the impact of Rework and Impediments/Constraints called out explicitly as elements of Contingency and Reserve.
It is, however, common to see terms such as “refactor”, “reiterate”, or “recycle” in project schedules. These terms reflect the recognition that, in most projects, rework is likely. It’s just not cast as “Rework”.
Similarly, it is common to see buffers in schedules. Buffers account for expected delays in delivery of value. So, they express the impact of impediments and
constraints. Again, they are not cast as “Impediments/Constraints”.
Given their presence in schedules, both rework and impediments/constraints can be isolated. But, as expressions of uncertainty, they are tacit, embedded in Contingency and Reserve but not explicitly acknowledged as such.
Thus, setting thresholds based on uncertainty allowances can appear to be unrealistic, as it appears to be difficult to identify what parts of Contingency and Reserve are relevant. [3]
Notes:
[1] For a case study in how we arrived at a solution, see Appendix A.
[2] For details on the evaluation process, see Appendix B.
[3] Note that on one view, there’s no difficulty. The argument goes like this. Value can be delivered on time or not on time. If on time, there’s no deviation from plan. If not on time, value is either delivered early or late. Rework initially delivers value early. Impediments/constraints initially deliver value late. Uncertainty allowances are provided to cover plan deviations, i.e., value delivered early or late. So, there’s nothing to unravel—simply assess the combination of R$tot and IC$tot against Contingency and Reserve. |
