Aggressive activity time estimates: Protecting against activity delays

Estimates for activity duration in the Critical Chain/Buffer Management (CC/BM) approach are assumed to be aggressive estimates and refer to the distinction between the average estimate and the low-risk estimate of an activity duration. It is a reaction to the commonly made assumption of adding safety time in the activity time estimates as is usually done in practice which might lead to quite unrealistic project deadlines.

This article compares the inflated activity time estimates and the aggressive time estimates, as follows:

  • Inflating activity time estimates: Unrealistic project deadlines and self-fulfilling prophecies
  • Aggressive time estimates: Removal of activity protection to obtain average or median time values
Inflating time estimates
Most people have the natural tendency to inflate the time estimates for project activities. Indeed, when people are asked to give a reasonable time estimate for an activity they have to perform, they tend to give an estimate they are comfortable with. In this respect, the activity time estimates are rather risk-free and contain safety time as a kind of protection. 
However, inflating the activity time estimates lead to self-fulfilling prophecies, and consequently, the initial idea of having a comfortable level safety time in the activity time estimates quickly fades away, as illustrated in figure 1.
?Figure 1. The self-fulfilling prophecy circle caused by comfortable time estimates
The self-fulfilling prophecy circle is caused by a natural behavior that most people have, and can be summarized as follows:
  • Student syndrome: When safety time is added in the activity time estimates, people have the tendency to wait until urgency (i.e. more trust and less attentive), similar to the behavior of students that postpone their work until exam deadlines.
  • Parkinson’s law: When safety time is added in our estimates, we feel more comfortable and have no incentive to speed up our work. Consequently, the work expands to fill the allotted time (consumption of safety time), known as the law of Parkinson.
  • Murphy’s law: If something can go wrong, it will (exceeding activity durations), which leads to activity durations that are even longer than their safe and risk-free time estimates. Hence, people tend to believe that they should have added even more safety time to their estimates.
Aggressive time estimates
Based on the general idea that the protection of the project deadline is the primary goal rather than the protection of each individual project activity, the activity durations should be set to an aggressive estimate to avoid that the work of an activity is smoothed out over a longer duration than really necessary, as shown in figure 1. Since activity durations are stochastic by nature and it is therefore impossible to estimate the correct deterministic duration, it is generally conjectured that the average activity time estimates are on the order of one-half to one-third of the low-risk estimates. Consequently, the safety time (i.e. the grey zone displayed in figure 2) should be removed from the activity time estimates to obtain aggressive time estimates, e.g. the 50% percentile activity duration estimate or the average duration. 
Figure 2. Aggressive and risk-free time estimate for a project activity
These aggressive time estimates (black bar of figure 2) should be used as inputs for the construction of a project baseline schedule in the critical chain/buffer management approach. The safety lost due to the use of aggressive estimates will be placed elsewhere in the project as project and feeding buffers. More information on the use of safety time incorporated in buffers can be found in ”Critical Chain/Buffer Management: Adding buffers to a project schedule”. General information on the critical chain/buffer management approach is written in ”Critical Chain/Buffer Management: Protecting the schedule against project delays”.

© OR-AS. PM Knowledge Center is made by OR-AS bvba Contact us at info@or-as.beVisit us at www.or-as.beFollow us at @ORASTalks