This post has been written by three schedule experts (alphabetically):
Levanon, Tal – CTO and co-owner of Tal Levanon – HCP Ltd., https://www.hcp-consulting.com
Lupu, Toni – Founder-Owner, PBM, toni@pbm.co.il;
Morag, Assaf – CEO, Rakia, https://www.rakia-eng.co.il/;
The issue of ’buffer’ in projects in general, and in construction and infrastructure projects in particular, has become a “hot issue” in recent years. Everybody wants a buffer, everybody wants to own it, and there is a great lack of knowledge on this issue.
The ‘buffer’ also goes by other names: Contingency, Float, safety margin.
Let’s try to put a bit of order in all of this…🤔
WHY DO WE NEED A BUFFER?
The main issue is – we provide inaccurate time estimates.
Why?
There are two reasons: the first – errors caused by an internal factor (the one making the estimate) and the second – errors caused by external factors.
The Planning Fallacy explains the first reason.
Goldratt and TOC explain the second reason.
The Planning Fallacy
Time estimate for execution by the executor: Optimistic
The Planning Fallacy – this is an issue which was raised by Daniel Kahneman and Amos Tversky already back in 1979. This is the phenomenon, in essence:
When people need to provide a time estimate for their tasks (complex tasks) – they are always optimistic and they provide an estimate which is shorter than the time the task actually took in reality. Moreover, even when they do the same task again – the time estimates fall short of the actual. This is a sort of internal “disease”, we all are carriers – each one for his own tasks.
*A vicious little game: play it on yourselves – give time estimates for a “slightly complex” task like – dinner with 1-2-3-4 children – from the moment you begin the preparations until you have cleaned up the kitchen when it’s over. Write your estimate on a small note and write the start time next to it. When this little project is over, check the end time. In the same vein, check all the excuses that’ll run through your head to explain why you were wrong with your estimate – “he had to go to the toilet in the middle” / “the dog started barking” / “I received a really important phone call” / “the scrambled eggs got burned” – or any other form of originality. Finally – console yourselves – this was a Planning Fallacy – happens to the best of us…
TIME ESTIMATE BY THE CONTROLLER: REALISTIC
Who is instantly cured of this affliction? Whoever is controlling the task from the outside. The ‘Controllers’ (in other words, the persons performing the control) need no more than one look at the person performing the task in action – to provide a much more accurate estimate of “how much time it is going to take him to accomplish the task next time”.
Important note – in these experiments, if the schedule was not met – there is no “penalty” (like for example, losing a job, a fine, etc.). If a “penalty” is installed, the time estimates change.
*Continuing our vicious little game: Ask your partner – how long dinner will take (assuming he or she will only be watching TV at the same time and not taking part in the whole mess). Their time estimate is going to be a lot more accurate – unless they are managing the event in collaboration with you – in which case the Planning Fallacy will work just as precisely… and mercilessly… on them too.
You can play this game on anything – a visit somewhere, shopping, finding parking downtown…
WHAT IS A BUFFER, ANYWAY?
1. Eli Goldratt and the buffer
Eli Goldratt, the father of the TOC – Theory Of Constraints – first presented the term “Time Buffer” in his book – The Haystack Syndrome (1991) and developed it further in Critical Chain (1997).
Goldratt claimed that anyone that has to commit to completing his task, takes a 200% buffer (from Eli Goldratt’s book, Critical Chain, pp. 138-140, publisher: Daniella Di-Nur – Publishers).
In other words, if someone thinks the net time for a task will be one week – he will demand three weeks. Goldratt’s solution is to slash every task in half – in other words, allocate 1.5 weeks for the same task and the remaining half move to the end of the project.
This way, on the one hand the task receives a realistic time allocation (time which in most cases will be sufficient to complete the task = 1 week net + 0.5 extra week for small problems) and if there are any major problems, in other words if Murphy shows up and throws a spanner in the works – there’s till enough of a “reserve” buffer at the end of the project, which will enable the project to be brought to a conclusion within the time allocated to it.
Since only part of the tasks are going to encounter problems requiring use of the buffer, the outcome is that the buffer required for the overall project is not going to be the sum of all the buffers we shaved off the various tasks, but only half of that. So it is that we have benefitted twice: we got a project done within a shorter time span and also a sizable buffer at its end to be able to sustain multiple problems.
The term Goldratt coined for this – Project Buffer – became accepted all over the world.
The buffer is a task. The duration of the task defines the buffer size.
2. The buffer and the AACE
Toni Lupu explains:
The AACE (American Association of Cost Engineers) https://web.aacei.org/, defines the buffer – the “Contingency” – as follows:
Contingency – is an integral part of the total estimate cost/time of the project and is a specific provision for unforeseeable elements of cost/time within the defined project scope (known unknowns). (Risk.03.01 – 2004 AACE International Transactions).
WHERE DO WE PUT OUR BUFFER?
The buffer is placed before the milestone we want to “protect”. “Protect” means – to ensure that the milestone deadline will not be delayed despite all the surprises in store for us along the way in the project (and they certainly are in store… that’s just the way it is).
All of the activities preceding the milestone will precede the buffer and only the buffer will precede the milestone.
That way, any problem that may occur can be absorbed in the buffer. If we had included it earlier, then there would be no protection for problems which would occur in tasks which are scheduled for after the buffer.
The buffer will be defined at the WBS level, which is identical to the milestone.
HOW LONG IS A BUFFER?
Assaf Morag told the following two stories:
1. The duration of the buffer according to the theory of constraints
Goldratt defined (from statistical considerations concerning the size of problems) that the buffer at the end of the project has to be 50% of the length of the critical chain. In other words – two-thirds of the project duration will be allocated to tasks and an extra third will be allocated as a buffer, which will be used to absorb delays which will occur cumulatively in all of the tasks.
2. Bank of Israel
A study done by the Bank of Israel, which was published on March 22, 2010 examined 196 transport projects in Israel, found that:
- In 64% of the projects, the actual project cost was higher than the initial cost estimate.
- In 82% of the projects, the actual date of completion was later than the original date.
- The final cost is on average 31% higher in real terms than the original budgeting.
- The average delay in completion is approximately 64% of the duration of the original project.
- In large-scale projects (greater than 100 million NIS ~30 million $), the final cost in real terms is 45% higher on average.
- Studies from elsewhere around the world show that the changes in the costs of transport infrastructure projects in Israel were similar to the changes in such projects elsewhere.
It should be pointed out that these numbers refer to projects beginning with their initiation, through the design to the build, and therefore the numbers are higher than the delays in the build phase alone.
Tal Levanon made a contribution on this matter:
3. Rule of thumb: every task / project / will take 30% more than planned
In one of the most important research centers, there was a well-known rule – every project (or task) takes 30% longer than planned.
So said a professor at that institute to a young 16-year-old girl who eventually became a scheduling consultant. (He still tells this story today and points out that this was known at the time as the Sages’ Wisdom.)
This dictum remained with me, albeit unproven, until I began searching for a place to do my Ph.D. (spoiler: it didn’t happen).
In the course of my meetings with the various professors, one of them, from the Ben-Gurion University, told me that he had completed a huge study with dozens of students, undergraduate, graduate and doctoral, which proved over dozens, if not hundreds of projects, that all of the projects are planned to take X days or months and that they take that long X 1.3, meaning they take 30% longer!
Toni Lupu added information from the literature:
4. Definition of a 20% buffer per task and per project 25% of the critical chain
Lawrence P. Leach, in his book Critical Chain Project Management, states that:
“There is substantial evidence to indicate that people tend toward overconfidence in their belief in the accuracy of their estimate. It is unlikely that most project tasks can be estimated better than +/- 20%.”
Critical Chain Project Management – L. Leach p.19
The goes further and states that a project buffer must not be less than 25% of the project duration (which he defines as the critical chain, which is the critical path on which includes links not only according to the task logic but also according to the demand for critical resources).
Do not allow the project buffer to be less than 25% of the critical chain.
Critical Chain Project Management –L. Leach p. 168
Tal Levanon adds from her experience:
5. Specification of a buffer per project = 20% of the project duration
When taking all the data and summing them up – the planning fallacy, the theory of constraints, the rule of thumb, Laurence Leach – the conclusion is: the buffer necessary is at least 20% of the project duration.
Is there proof? The answer is: although this is not pure mathematical proof, since it has worked in so many projects – it’s becoming “de-facto” proof.
In all of my subsequent projects, I prepared the skeleton schedule with the project managers. To this we added a buffer of 20% of the project duration hedging the milestone entitled “completion of contractor works” – and thus were also the contractual milestones defined.
Regarding how buffers are managed in projects – see the next section, “How is a buffer managed?”
Following are some of the examples for projects where a 20% buffer was specified, and which succeeded in ending on time and even slightly before that:
Projects: Moriah Jerusalem Development Corporation Ltd.
- Removing Infrastructures for the Jerusalem Light Rail – The Red Line:
- Henrietta Szold – Management: Dan Ben Amram Engineering & Management, Contractor: Bardrian Bros. Ltd.
- Ora Junction – Management: Ehud Tayar Management & Engineering Ltd., Contractor: Barad Earthmoving Works Development & Roads Co. Ltd.
- Ora-Hadassah – Management: Ehud Tayar Management & Engineering Ltd, Contractor: Ben Ari Tel Ram Projects Ltd.
- Hadassah – Management: David Eckstein Ltd., Contractor: Y.D. Barazani Ltd.
- Megaproject – Begin Highway (Highway 50) (3 management companies, 5 contractors):
- Segment 1 from Golomb junction to Me’asef junction – Management: Ehud Tayar Management & Engineering Ltd., Contractor: Shapir – Y.D. Barazani Ltd.
- Segment 1 from Me’asef junction to Rakevet junction – Management: Ehud Tayar Management & Engineering Ltd., Contractor: Mordechai Binyamin – Barashi Zalman & Bros. Co. Ltd.
- Segment 1 – Golomb Tunnel Systems – Management: Ehud Tayar Management & Engineering Ltd., Contractor: Cohen & Ben David Ltd.
- Segment 2 – Management: Project Management Shalem Ltd., Contractor: Shapir Engineering
- Segment 3B – Management: David Ackerstein Ltd., Contractor: Galnor Building & Development Ltd.
- Segment 3A – Management: David Ackerstein Ltd., Contractor: Y.D. Barazani Ltd.
The Begin Highway megaproject was awarded the PMI – POY (Project Of the Year 2015) award – first place and also the Engineering Society’s award in recognition of an outstanding infrastructure project for 2015.
to reach successful conclusion as it happened in these projects,
the issue of buffers is essential but not sufficient.
To achieve this, it is imperative that all forces work together,
rather than separately,
and also that a HCP-Go analysis be conducted
on the basic schedule and then again every month.
If you want to test that, try HCP-Go
HOW IS A BUFFER MANAGED?
Tal Levanon describes the method she applies to projects:
A buffer is defined as 20% of the duration of the remaining work.
This means:
If a project’s duration is 36 months start-to-end, then the work itself has to take 30 months and the buffer task must be done within 6 months.
The buffer gets shorter as the project progresses:
When the project makes progress, the buffer necessary for the remainder of the project gets shorter accordingly. For example, when there are 24 months left to project completion, the schedule will show that there are 20 months left for work and 4 months left as a buffer.
The advantage of this method is that it is totally objective. There is no bias in favor or against one party or another. This is a mathematical calculation, according to which the buffer does not get shortened deliberately by one of the parties.
What does this look like in real life? See the following section: A real life example – a Case Study – summarizing the buffer“.
Toni Lupu details his method of calculating a buffer, which describes the risk:
When a developer asks: “When will my project really end? Regardless of the contractual stipulations…”
The answer is that the project duration will be as long as the critical path (which ends the latest) plus a buffer, the size of which is recalculated on a monthly basis – according to the build updates.
There are several ways to calculate the buffer. Toni uses the Monte Carlo method mostly, or an extrapolation of S curves.
SUMMARY THEORETICAL EXAMPLE OF A BUFFER
For example:
Specified project duration: 24 months.
- Notice-To-Proceed was issued on January 01st, 2022
- The customer has specified 3 milestones: 8 months, 16 months, 24 months (project completion).
In rows 3, 4, 5 we can see the milestones specified by the customer and their target dates:
Milestone #1 – 8 months from NTP: August 31, 2022
Milestone #2 – 16 months from NTP: April 30, 2023
Milestone #3 – 24 months from NTP: December 31, 2023
In row 10 we see the buffer. For a 24-month project, we see 4 buffer months ending on the project completion date, in this example – December 25, 2023, or 6 calendar days prior to the contractual project completion.
Note that in the baseline, it appears as if milestones 1 and 2 are going to be completed before their contractual date. But, as we know, the chances of completing a task within the time allocated to it are small if not non-existent.
What is the most important thing for the project customer? Accomplishing Milestone #3. The most important thing is that Milestone #3 must not be reached late. If we can do it sooner – all the better! Therefore, milestone 3 is the one to protect – and that’s why Milstone#3 is the only successor of the buffer, and the buffer is the last of all the tasks.
Now let’s go along the timeline, 12 months into the future and take a look at the schedule.
After 12 months, the project build begins. On January 1st, 2023, the following situation is reached:
- The tasks for Milestone #1, in row 7, did not take 6 months as in the baseline, but rather 30% more – as is always the case – therefore they lasted 7.8 months.
- Milestone #1, row 3, ended on time, August 29, 2022 – no delay relative to the contractual deadline: August 29, 2022.
- Buffer – has to shorten to 2 months, because there are 12 months of work left until the end of the project and these are divided into 10 work months, 2 buffer months (= 10*20%), in total: 12 months.
A REAL-LIFE EXAMPLE - A CASE STUDY - SUMMARIZING THE BUFFER
The buffer method Tal presented was applied in an infrastructure project in a large city. The method is presented in two charts which show the buffer from the baseline schedule through to the 18th month into the project.
The first curve contains the buffer in percent of the duration of the remaining work in the project:
- The Purple Line – 20% as contractually required.
- The orange line – the buffer values, in percentages, as obtained in the schedules, upon each update.
The second curve contains the same values, only this time in months, not percentages.
- The green line shows the 20% as contractually required, in months. The value in months diminishes as time passes.
- The blue line shows the duration of the buffer in months, as obtained from each monthly update of the schedule.
One can see that in the basic schedule, the contractor succeeded in creating the schedule so that the buffer was approximately 23% of the project duration – 3% more than required. The same way, the duration of the buffer was almost 7 months, whereas contractually he was required to allocate 6 months only. (Meaning that the planned project duration was – 36 months).
- Until the 7th month, the contractor makes healthy progress and succeeds in accomplishing his tasks, such that he increases his buffer to 35%, which in the 7th month constitute 7.5 calendar months.
- In the 8th month something happens that causes a sizable delay in the project. As a result, the buffer diminishes to only 22%, or 5 calendar months.
- Between months 9 and 12 the contractor once again shows recovery and the buffer increases to 30% (which are 5.5 calendar months by the 12th month).
- From the 12th month it seems the buffer is used and it diminishes, and in month 16 something happens again and causes a sizable delay in the project, reducing the buffer to only 12%, meaning 2 calendar months that month.
- Corrective action takes place in month 17 and the buffer stabilizes on the 20% required in the contract.
WHO OWNS THE BUFFER?
This is a big issue in itself – therefore we will cover it in part 2.
