Many, if not most, people in project management know Murphy or Murphy’s Law.
According to the Murphy’s Law,
“If anything can go wrong, it will. “
What does this mean to us in project management?
There are many meanings; however, it is basically about accepting the idea that things could go wrong.
To counter the effect of Murphy’s law, the project team must be vigilant in their planning effort and conduct thorough Risk Management exercises.
We usually joke that Murphy will visit, so we must be ready. Today, I will share a case study where Murphy not only visited but also stayed and took over the house, i.e., the project.
The Case Study
I will focus on planning in this case study, particularly scheduling and forecasting. The project is the construction of a facility; I will not mention more to avoid exposing the parties involved or the location.
I will start with the root cause – the root cause for failure on this project is the lack of proper project management maturity and understanding of basic planning by all parties involved: owner, contractor.
The first major error was related to the original project schedule.
- The project schedule depends on a high-level, conceptual approach instead of detailing the work. While such an empirical approach might be partially acceptable for conceptual schedules during feasibility studies, it was inadequate for an engineering and construction project.
- The team included a part-time planning manager who lacked experience in this type of project.
- Additionally, there was only one scheduler—a recent graduate with just one year of experience. Although this scheduler is intelligent, he needs more experience or training. The only training he received was a course on the use of Primavera.
I should have mentioned that this project is in the hundreds of millions US$, so it is not small. It is a major project, and some might consider it a Megaproject.
So, from the start, the schedule cannot be trusted, and no one noticed.
Progress of work
Since the schedule was based on an empirical approach, rather than proper work packaging and work effort, hours and then proper progress measurement were not even possible. As a result, their progress measurement system was finite in counting the passing days.
Forecasting
Well, need I say anything?
I should; it was a disaster.
As with progress, forecasting counted the elapsed days plus the remaining days based on the original schedule. I will elaborate more in the numerical presentation below.
The Numerical Example
One main activity was 370 days long. This is primarily a control account instead of an activity.
At the time of the assessment, they estimated 48% to be complete. This was achieved by counting widgets, i.e., the number of widgets complete divided by the number of widget plans. Let us assume this is OK.
Plan = 370 days; 48% complete.
A golden rule in scheduling is we CANNOT use lapsed time as an accurate method to forecast.
But lacking any other scientific approach, let us continue.
The actual time taken to achieve the 48% was 423 days. More than the original plan for the whole account.
Earned Time = 48% of 370 days (original plan) = 178 days.
In other words, to achieve what could have been done in 178 days, they needed 423.
Now, what was the forecast used?
Forecast = 423 + Remaining Days (per original plan) = 423 + (370-178) = 615 days
The project used this forecast. The team applied the same approach for all activities/accounts. This forecast would have been acceptable if the remaining work could be completed exactly per plan, which is impossible. This represents the best-case scenario.
Then, what is the proper forecast?
Given the time available, it was impossible to calculate. However, one approach is to assume that past performance will continue. This means extrapolating the forecast, resulting in 881 days. Let’s assume this represents the worst-case scenario. Assuming the contractor did something to improve performance, the actual duration will be between 615 and 881 days; this is a huge range.
The Overall Situation
The contractor reported that the project was about seven months behind schedule. Once again, we needed more time to validate through a detailed analysis. We had only two days, and this problem (explained above) was discovered at the end of day 1.
A quick rule of thumb would help.
Based on the above example, it was clear that the delay was much more than forecast since they were using the method explained. Therefore, the forecast was wrong.
The reported progress was: Plan = 39.49%; Actual = 27.26%, so a rough SPI = 0.69.
Once again, assuming past performance will continue, then the forecast will be equal to the plan / SPI
Project Duration per Plan = 1095 days
Approximated Forecast = 1095 / 0.69 = 1587 days, or 492 days longer than plan. This is more than 16 months delay. Remember, they were reporting seven months.
Closing Comments
The calculations I shared above are quick:
a rule of thumbs = approximation = sanity checks.
Professional planners, schedulers, cost engineers, and project managers must take many other actions to measure progress and forecast the project schedule or cost. They should work at the work packages level with activities ideally 1 or 2 weeks long, not a year.
Finally, we have recently recorded more than one video and wrote more than one article about capital projects, mega projects, and their delays. Could they be using the same approach? Maybe one day, I will find out.
Click Here for Past Articles. Another Article. Video on Ethics.
Returning to Murphy, the project faced numerous issues such as cost, quality, scope, etc. However, in our professional opinion, the lack of experience and project management maturity among all parties significantly contribute to many of these issues.
Finally, in the realm of project management, Murphy’s Law often proves itself true, reminding us that diligent planning and risk management are essential to mitigate unforeseen challenges
Should the supervising company discover these problems?
How about the owner’s organization?
What do you think?