What is a buffered schedule?

A buffered schedule is one to which free float has deliberately been added. It is when we take negotiated additional schedule time and add it to the schedule as planned delays between the finish of activities and the start of activities that are dependent on them. It does not make sense to buffer any of the activities that are not on the critical path because this would mean that we would just be adding additional free float to activities, and the completion date of the project would still be determined by the critical path activities.

Figure 5-19 shows a project with an early schedule completion date of May 30. The project manager gives the stakeholder a promise to complete the project on July 30. Figure 5-20 is the buffered schedule that is created by the project manager.

Figure 5-19: SCHEDULE WITHOUT CONTINGENCY

Figure 5-20: SCHEDULE WITH BUFFER

The amount of time that the schedule is to be buffered is determined by the difference between the promise date that is given to the stakeholders and the late finish date of the project. The late finish of the project is equal to the latest late finish of the last finishing activity of the project.

The buffer time is distributed to the activities according to some scheme. One of the most popular methods of doing this is by using Goldratt's critical chain method, which we will discuss later in this chapter. It can be distributed among the activities of the project according to any scheme that is appropriate for the specific project.

Tell me more …

Many project schedules are driven by unrealistic mandated completion dates. This has something to do with the psychology of people outside the project. Some stakeholders require projects to be done by mandated completion dates that have little to do with when the project is actually needed. The reason for this is that many of these stakeholders have had disappointingly bad experiences with project managers who did not adhere to schedules. These people request that projects be done as soon as possible because they are certain that there will be delays.

By asking for projects to be completed as early as possible, they feel that the inevitable delay will be added to an earlier promise date, and the actual completion of the project will be earlier. Of course this is also a case of wish fulfillment. If people assume that projects will always be late, projects probably will always be late.

Of course if our stakeholder really has a situation where he wants to crash or fast-track his own project schedule, he wants our project completed as soon as possible and probably wants to take the risk that we will not complete on time in order to take advantage of being able to finish early. In this situation the customer is not likely to agree to the delay we suggest as a means of improving the probability of being able to adhere to the promise date.

Most project schedules have probably had a pretty bad track record and have not met their promise dates. One of the reasons for this is that many project schedules are developed by taking the most likely durations of the activities and using them to predict the most likely project duration and thus the project completion date. We can think of the possible project completion dates as points on a nonsymmetrical probability distribution as shown in Figure 5-21.

Figure 5-21: PROBABILITY OF PROMISE DATES

We can see that the most likely date has the highest probability of occurring. This date is even earlier than the PERT expected completion date that was developed in our discussion about PERT. If the probability distribution curve were symmetrical, the most likely value of the project completion date would have a 50 percent chance of predicting that the actual project completion date would be earlier (see Figure 5-22).

Figure 5-22: WILL THE PROJECT BE LATE?

Of course this means that the project would also have a 50 percent probability of being later than the most likely project completion date. In the case of the nonsymmetrical distribution, the actual project completion date has a greater than 50 percent probability of being later than the most likely date. The question that project managers need to ask themselves is, "Am I willing to promise a stakeholder a project completion date that has a 50 percent probability of being late?"

One of the first things that must be done to buffer a schedule is to convince the stakeholders and sometimes our own management that we will use the schedule change wisely to improve the reliability of the promised completion date. Usually explaining that there is a 50 percent probability that the project will be delivered late will get everyone's attention. Once you have their attention, explain the real meaning of the most likely date for project completion.

Suppose we have a situation in which we are doing a project for a client that depends on our project in order to be able to move forward with a larger project. An example of this might be if our project is to build a machine for a customer that would use the machine to manufacture their product. If we promised the machine to the customer on a specific date, such as 200 days, it is likely that the customer will discontinue the use of its old system to make way for the new machine we are supplying. If we fail to deliver the machine as promised, our customer will have no means of production because the old equipment it had been using has been removed to make way for the new equipment. If we are very late in our delivery, the consequences could be enormous. What we want to do in this case is promise the client a project completion date that has a higher reliability or probability of occurring.

In the symmetrical normal distribution, the range of values that has a 95.5 percent probability of containing the actual value is plus or minus two standard deviations from the expected or average value. In the case of projects we can say that the expected value of the project completion date, plus or minus two standard deviations, will be the range of values that the actual project completion date will fall between. Since we have already discussed the PERT technique, it probably makes sense to use those calculations again.

As a reminder, to predict the expected value of the project completion date by the PERT method:

To calculate the standard deviation:

In our example we predicted and promised our customer that we would deliver the machine we were building for them in 200 days. Suppose we want to have a better than 95 percent probability of completing the project on the promise date. We could estimate the optimistic and pessimistic dates for delivery, say 190 and 220 days respectively.

The expected value for delivery would then be:

The standard deviation would then be:

If we add two standard deviations to the expected value, we will have a promise date that has a better than 95 percent probability of the actual delivery date's being earlier than the promise date.

We have now decided to add ten days to our promised delivery of the machine. The next question we need to answer is, "Where should the ten days of buffer be in the schedule?

The ten days of buffer could be added at the end of the project, but that would mean that every time we need to use some of the buffer we would also have to reschedule the activities between the problem and the end of the project. It would be better to distribute the buffer among the activities of the project. If we do this and if an activity that has buffer is delayed within its buffer, no other activity will have to be rescheduled. This is much like creating free float in an activity.

There is no point in adding buffer to activities that are already off the critical path. These activities already have float and may have free float. We need to buffer the critical path activities first. Once we have buffered the critical path activities, we may want to reschedule some of the non–critical path activities as well.

Selecting the activities to be buffered and the amount to buffer them will be largely done by the project team's best judgment. The critical chain method attempts to put a more formal method of buffer distribution into place, but there is a lot of controversy about its application. See the discussion on critical chains later in this chapter.

Probably the best method of distributing buffer to the activities is to assess their schedule risk. If we have done a reasonable job of risk analysis, we should have a ranked list of risks already identified. Even by subjectively evaluating the schedule risks and looking at their interdependencies we can determine the best place to put our buffer.

Favoring the early part of the project with buffer may allow us to make mistakes that we can avoid later in the project. This method will also allow unused buffer from completed activities to be redistributed to other project activities by starting them earlier than planned. On the other hand, Goldratt argues that early activities with relatively large amounts of float should be scheduled to occur later in the project because we can avoid risks by learning from the successful work that was done early in the project.

Another important consideration in buffer distribution is the criticality of the resource involved. A resource that is rare and scheduled most critically may need to have predecessor activities scheduled with buffer to increase the probability of their being done when the resource becomes available.