Examples of buffer tasks in action

In the illustration below, task H is a project buffer task - it has no outgoing links, and no tasks to the right of it on the same bar:

If task G can finish in less time than originally planned, the tasks would look as follows after a reschedule:

As the duration of task G has decreased, the duration of buffer task H has increased to protect the finish date. In reality, this would be undesirable, but close monitoring of buffer consumption would show that this has occurred, so corrective action, such as shrinking the buffer task, could be taken.

If task G takes longer than originally planned, the tasks would look as follows after a reschedule:

As the duration of task G has increased, the duration of buffer task H has decreased to protect the finish date.

If task G is delayed and/or takes longer such that it finishes later than the finish date of the buffer task, the tasks would look as follows after a reschedule:

Buffer task H has shrunk to a finish milestone and has moved forward past the buffer task finish date. Again, close monitoring of buffer consumption would flag this as a problem.

In the illustration below, the task shown is a project buffer task - it has no outgoing links, and no tasks to the right of it on the same bar. The task is used to represent training requirements for one resource throughout a year, and stretches from 1 January to 31 December. The task is set to be a buffer task in order to prevent it from moving later than the deadline flag at the finish of the year:

If after 4 months the resource has had some, but not all, of its training, the task would look as follows after a reschedule:

The incomplete portion of the buffer task and its allocation has been moved forward to the reschedule date, but the buffer task has shrunk, protecting the finish date.

If all of the training has still not been done at the start of the following year, the task would look as follows after a reschedule:

The incomplete portion of the buffer task has shrunk so that it has a duration of 1 second and it has moved forward past the buffer task finish date.

In the illustration below, task B is a feeder buffer task, designed to protect the start date of task C. Note that there is a link from another task into the start of task C:

If task A can finish in less time than originally planned, the tasks would look as follows after a reschedule:

As the duration of task A has decreased, the duration of buffer task B has increased.

If task A takes longer than originally planned, the tasks would look as follows after a reschedule:

As the duration of task A has increased, the duration of buffer task B has decreased from its start date to protect the start date of task C.

If task A is delayed and/or takes longer such that it finishes later than the finish date of the buffer task, the tasks would look as follows after a reschedule:

Buffer task B has shrunk to a finish milestone and has moved forward past the buffer task finish date. As the buffer task has been completely consumed, task C has had to be moved. Close monitoring of buffer consumption would flag this as a problem.

If task C was able to start earlier - ie its incoming link had pulled it back - the tasks would look as follows after a reschedule:

Buffer task B has shrunk from its finish date and will still protect the start date of task C even though it is now smaller.

If task C was able to start earlier than the finish date of task A, the tasks would look as follows after a reschedule:

Buffer task B has shrunk from its finish date as much as possible and has become a finish milestone. As the buffer task is linked to the finish of task A, task C cannot move back any further.

If task C had to start later, the tasks would look as follows after a reschedule:

Buffer task B has increased from its finish date to maintain its buffering of task C.

In the illustration below, task E is a feeder buffer task, designed to protect the start date of task F. Note that there is a link from another task into the start of task F:

The behaviour of the buffer task in this scenario is the same as in example 1: the buffer task will shrink or grow to protect the start date of task F as much as possible.

In the illustration below, task B is a feeder buffer task, designed to protect the start date of task C. Note that this scenario is similar to example 1, but there is no link from another task into the start of task C:

If the reschedule option for tasks with no links is not set to Leave as drawn within constraints and task C is set to ASAP, the tasks would look as follows after a reschedule:

Buffer task B has shrunk to a finish milestone and task C is moved back, shortening the schedule.

If the reschedule option for tasks with no links is set to Leave as drawn within constraints, the tasks would look as follows after a reschedule:

The positions of the tasks have not changed at all - task C has no links so the reschedule will not move it, so the buffer task remains as it is.

If the reschedule option for tasks with no links is not set to Leave as drawn within constraints, task C is set to ASAP and task A can finish in less time than originally planned, the tasks would look as follows after a reschedule:

Buffer task B has shrunk to a finish milestone and is moved back along with task C, shortening the schedule.

If the reschedule option for tasks with no links is set to Leave as drawn within constraints, task C is set to ASAP and task A can finish in less time than originally planned, the tasks would look as follows after a reschedule:

As the duration of task A has decreased and task C cannot move, the duration of buffer task B has increased.

Regardless of the reschedule option settings, if task A is delayed and/or takes longer such that it finishes later than the finish date of the buffer task, the tasks would look as follows after a reschedule

Buffer task B has shrunk to a finish milestone and has moved forward past the buffer task finish date. As the buffer task has been completely consumed, task C has had to be moved. Close monitoring of buffer consumption would flag this as a problem.

In the illustration below, task E is a feeder buffer task, designed to protect the start date of task F. Note that this scenario is similar to example 2, but there is no link from another task into the start of task F:

In this example, the buffer task will always shrink to its minimum duration following a reschedule, as only the buffer task E is constraining task F:

Buffer task E has shrunk to a finish milestone and task F is moved back, shortening the schedule.