frustrated guy.jpg

Construction Stories 101: Things That Make Project Owners Blood Boil

When you deal with some of the most complex projects in the world, things will come up and mistakes will happen. What drives people crazy isn’t the initial mistake, but rather the cascade of poor decision making that takes a relatively simple delay and makes it into a more costly & significant delay. Here is an example that we have heard in some variant:

In a HiRise construction, delays to enclosure *should* impact start of drywall to follow best practices. IN this case, the enclosure was late, but drywall needed to keep on schedule. The PM inserted a mitigation strategy into the project schedule to keep the end-date. In order not to have to pay for acceleration, the PM decided the cheapest route was to put in a temporary roof and stack the trades for the drywall sub. The problem was compounded when the pricing determined for a temporary roof was too high, so they decided to only stack the trades. Except they haven’t discussed with the drywall sub whether they could get enough tradesmen - which they couldn’t. So, nothing ended up changing from the original plan except the obviously delayed end-date that was not moved out on the schedule.

Instead of coming clean that their well-intentioned mitigation strategy fell through, they left it on the project schedule as if there wasn’t a delay. To add insult to injury, this scenario was compounded when they had to later coordinate multiple trades within the same zone causing another ripple of delay. You can predict what happened later in the project with additional requests, finger-pointing, etc.

I can hear half the readers saying, “not on my job” and the other half saying, “maybe not this situation, but something similarly frustrating.” Either way that you fall on the above scenario, the reality in complex construction is that we are dealing with an amazingly complex and fast changing environment. Critical path management is as much art as it is science.

The reason for project controls is to have an oversight function that hopefully catches ad hoc decisions that can magnify the impact of a small delay as it ripples through the project schedule. If you are an owner, you hopefully hired a firm that has a good reputation and a team that you trust. The reality is that even the best of teams will make mistakes on projects this size. Some of these are recoverable if caught in time. Some are even preventable if you have visibility to the decision before it is implemented. Sometimes, it isn’t about prevention, just plain ol’ accountability.

The problem is how do you “trust, but verify” without being intrusive?

The answer is relatively simple – a competent project team will keep the project schedule up-to-date for their own reasons beyond communicating with the stakeholders. With a reasonable flow of updates, a good scheduling & delay analyst can catch most of the trending on a project. With more time invested, they can map the critical path impacting delays and provide a more granular analysis. You may not want to spend that amount of money for a report 30 days later, but the analysis is possible if you are willing to spend.

Alternatively, you would like to have a deep analytics platform that would process all the changes within the project schedule and provide an executive report on what are the critical delays that you need to prioritize. Additionally, you would love a simple dashboard that could tell you how well the schedule update is logically so that if you are missing key information or logic ties, it will give you the ammunition to go back and make sure that the project schedule is at the level that it needs to be to do its job. Also, you would like to have a simple way of seeing how the project is trending:

● Is the forecasted end-date realistic, did we really pick up some recovery in the schedule or are the activities compressed to make it fit?

● Are we seeing trends that will need to be addressed before we get to that point to keep us on track?

● Did we really have that many weather days of delay?

● What really caused that 2-week delay?

We all know that delays are par for the course. We budget for them, we plan for them, and we anticipate that there are just “un-know-ables” on every project. The BUT in that statement is that “we don’t want to overpay for performance we expect.”

● If it could have been preventable

● If it was on 2 days rather 10 days of weather

● If we had known about that decision, we may have made an alternative suggestion to keep us on track

The bottom line is that YOU CAN’T FIX WHAT YOU CAN’T SEE.

Doesn’t mean it is even fixable, but preventing one delay, evidence to show that the additional request wasn’t our fault or being able to audit decisions without being onsite all the time – that could have significant impact in keeping the project on track. Catching one mistake could pay for itself many times over.

If you could send over the project schedule files and get back the answers, wouldn’t that be worth it?

Author: Michael Pink

Recent Posts