Murphy's Law

What happens when Murphy takes over the house?

Many, if not most people in project management know Murphy or Murphy’s Law. According to the Murphy’s Law Website, “If anything can go wrong, it will“. For more information about the origin of this law, visit http://www.murphys-laws.com/murphy/murphy-true.html.

What does this mean to us in project management?

Well, 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 exercise. We usually joke that Murphy will visit so we must be ready.

Today, I will share a case study where Murphy did not only visit but decided to stay and take over the house; i.e. project.

The Case Study

In this case study, I will focus on planning, in particular, scheduling and forecasting. The project is the construction of a facility; will not mention more in order not to expose the parties involved or 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 schedule.

  • The project schedule was developed based on high-level, conceptual approach rather than details of the work to be done. Such an empirical approach might be partially acceptable if we are doing conceptual schedule during a feasibility study but here the project was in engineering and construction.
  • The team included a planning manager, part time, that did not have experience in this type of projects.
  • There was one scheduler that was a recent graduate with limited 1-year experience. This scheduler is smart but lacks experience or training. The only training he had 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 Mega Project.

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, then proper progress measurement was not even possible. As a result, their progress measurement system was limited to counting the elapsed days.

Forecasting

Well, need I say anything?

I should, it was a disaster. Same as a progress, forecasting was counting the elapsed days + the remaining days based on the originial schedule. I will elaborate more in the numerical presentation below.

The Numerical Example

One main activity was 370 days long. This is mostly a control account instead of an activity. At the time of the assessment, they had estimated 48% complete. This was achieved by counting widgets; i.e. the number of widgets complete divided by the number of widget plan. let us assume this is OK.

So – 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. Basically 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; this is the forecast used on the project. The same approach was used for all activities/accounts. This forecast would have been OK if the remaining work will be completed exactly per plan, which is not possible. Will assume this is the best case scenario.

Then, what is the proper forecast? In the time given it was impossible to calculate but one approach is to assume that past performance will continue. That means the forecast will be extrapolated and will be 881 days. Let us assume this is the worst case scenario.

Assuming the contractor did something to improve performance, then the actual duration will be somewhere between 615 and 881 days; this is a huge range.

The Overall Situation

The contractor was reporting that the project was about 7 months behind schedule. Once again, we did not have enough time to validate through a detailed analysis. We had 2 days only – and this problem (explained above) was discovered at the end of day 1.

Just a quick rule of thumb would help.

Based on the above example, it was clear that the delay was much more than predicted 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 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 7 months.

Closing Comments

The calculations I shared above are quick, a rule of thumbs = approximation = sanity checks. They are not to be used for proper progress measurement and forecasting of the project schedule, or cost for that matter. Proper forecasting requires working at the work packages level with activities ideally 1 or 2 weeks long, not a year. Many other actions would be required by professional planners, schedulers, cost engineers, and project managers.

Finally, we have recently recorded more than one video and wrote more than one article about capital projects, megaprojects, and their delays. Could they be using the same approach? Maybe one day will find out.

Click Here for Past Articles. Another Article. Video on Ethics.

By the way, back to Murphy. This project was facing numerous issues related to cost, quality, scope and other areas. However, many of the issues and problems, in our professional opinion, goes back to the lack of experience on the team and lack of project management maturity by all parties involved.

Should the supervising company discover these problems?

How about the owner’s organization?

What do you think?