What is ambiguity? According to Wikipedia:
“Ambiguity is a type of meaning in which a phrase, statement or resolution is not explicitly defined, making several interpretations plausible. A common aspect of ambiguity is uncertainty. It is thus an attribute of any idea or statement whose intended meaning cannot be definitively resolved according to a rule or process with a finite number of steps”
Applying this to construction planning, if a plan creates a situation where multiple interpretations are possible, chaos during the project execution is a guaranteed result. So, the desired outcome of a plan is to avoid such chaotic situations.
Now, let us examine what a basic construction project plan comprises.
At the very least, they need to include:
- Work details
- Start date and duration
- Dependencies between activities to design the construction logical sequence
For a given activity, its work details, start date and duration are straightforward for a planned resource executing the activity. Dependencies design, however, has the potential to create ambiguity. Let us examine this with an example:
Example 1 — Scheduling backward:
Let’s take a look at the following two activities and their dependencies.
In this example, the team is planning to start the Tree felling works on 1 Oct.
To prepare for this, they plan to submit the Authority approval on 31 Aug and get it approved by 17 Sep. Schedule wise, everything seems to look fine, right? Get the approval on time, and start the work on time.
However, the commonly made mistake here is the use of negative lag dependency to achieve this schedule. If you take a look at the dependency, the relationship used is FS-30 days, from the Tree felling work. Although this dependency solved the scheduling problem, it does not serve the purpose of planning logically. By this relationship, it is saying that the Authority approval has to be submitted 30 days before the Tree felling finishes. How is the team supposed to know in advance when the Tree felling can be finished?
Another problem with this is the impact that the Authority approval has on the Tree felling. Using this relationship, if the Authority approval were to get delayed, let’s say until 5 Oct, the Tree felling would still be scheduled on 1 Oct, without any consequences arising from the delay of Authority approval.
Instead, the correct dependency should be:
Using the FS+7 days dependency, the schedule, as well as work planning is satisfied. As per the original schedule, Authority approval is planned to start on 31 Aug and Tree felling on 1 Oct. If the Authority approval starts later, or starts on time but takes longer, the consequences of this will be immediately reflected on the start date of the Tree felling work.
This commonly made mistake of scheduling backward and using negative lag values to simply schedule the activities, without having a proper planning logic would add ambiguity in managing the project during the execution, thereby not achieving a realistic project timeline.
Example 2 — Scheduling without proper site planning logic:
Let’s look at another example of the dependency between simple Excavation and Pipe Laying works.
Both works will be done in stages, where after a certain portion of the Excavation has been done, the Pipe laying can start. However, like in Example 1, the relationship has been set up with the mistake of using negative lag days to schedule them at required dates.
Again, this has satisfied the scheduling requirement in terms of their start dates and end dates. However, there is no logical meaning to the relationship between these two activities. Without proper site planning logic, the plan merely becomes a master program with scheduled dates. It does not give us the transparency and predictability to monitor and control the execution of the activities on the site.
Excavation | FS -6 days | Pipe Laying
This means that Pipe Laying can start 6 days before the Excavation finishes. When an activity is planned based on the ‘expected’ or ‘predicted’ end date of another activity, you are inducing ambiguity to the plan, which leads to an unreliable plan.
Let’s try to induce a proper site planning logic here. By right, Pipe Laying can start after a certain portion of Excavation has been completed. We can instead use the Start-to-Start dependency here with a positive lag of 3 days. (SS+3 days)
This has induced some logic to the plan. Pipe Laying shall start 3 days after Excavation starts. If the first 3 days of Excavation are executed without any disruptions, this plan works well. However, there is still some ambiguity as to exactly how much of the Excavation should be completed before Pipe Laying can commence, in this context.
In this case, one possible solution would be to break the Excavation down into two parts — the first part which the Pipe Laying’s start date depends upon, and the second part which will continue. The plan would look like this:
The plan now has a proper site planning logic, and there is no ambiguity during execution for the site team as well.
Start date of Pipe Laying is linked to a definitive scope of Excavation. Any changes to the plan, e.g. if there is any delay in the Excavation works, the impact on the Pipe Laying will be immediately realized, which gives us an accurate forecast of the end date of the project. It provides transparency and removes ambiguity.
Although it requires more effort, proper planning practices lead to the proper execution and better control of the project. Taking a shortcut with fewer activities and dependencies with negative lags may produce a fixed schedule, but does not serve any other meaningful purpose to the execution of the project. To enable dynamic site planning with proper logic and better control of the project, Lean PlanDo integrates with Microsoft Project or Primavera P6 plans with positive lag values only.
For more in-depth analysis and examples of why negative lags should be avoided, you can refer to the links below: