{{Article.Title}}

{{Article.SubTitle}}

By {{Article.AuthorName}} | {{Article.PublicationDate.slice(6, -2) | date:'EEEE, MMMM d, y'}}
{{TotalFavorites}} Favorite{{TotalFavorites>1? 's' : ''}}
{{Article.Caption}}

Engineering and construction organizations could benefit from learning lessons from past experiences, whether their own or another’s. However, the industry is not always great at looking inward, and there remains a common perception that each new project is completely different from the last. 

Look around at how other industries such as manufacturing learn from the past and embrace new techniques and technologies to drive improvement. While this approach is growing, it’s not as widespread across E&C as perhaps it should be. So why doesn’t the industry look back at what it’s done to improve what it’s about to do – and then repeat that approach next time? 

The industry must ask: Is it a question of not having the right information from prior projects to be able to gauge anything of value? Is it due to the manual approach to certain aspects of a project—meaning organizations don’t capture everything? Or, could it be because of the fragmented nature of projects, with teams spread far and wide preventing everyone involved from having a full view of the project?

Encouragingly, E&C organizations are using technology to capture a true picture of a project’s full lifecycle by using a common data environment (CDE). Coupled with that change, innovative businesses are starting to appreciate commonalities between projects as they look for ways to improve processes.

Learning from Natural Disasters

E&C is quickly moving toward a position where there should be no real reason it can’t look back at or learn from previous projects. But what about looking at completely different situations and taking lessons from those? A case in point is the way the recovery process is managed following natural disasters. Those learnings can and should be applied to everyday projects.

From direct dealings with operations following Storm Desmond in the UK and Hurricane Sandy in the U.S., among others, the primary takeaways from these experiences is that there are common lessons that can be easily replicated across other kinds of projects.

Post-disaster rebuilds are obviously very different from building an office tower, nuclear plant or airport facility. They are often larger in scale, although there are more, increasingly huge and complex construction projects around the world. 

Natural disasters are not just a developing-world issue. No matter where they occur, they often impact multiple resources at the same time, be that water, energy supplies or roads. There is also obviously an expediency required in disaster recovery that isn’t required at a normal project level. Finally, there’s the humanitarian impact and the significant implications from every decision made in the recovery efforts.

Depending on the scale, disaster rebuild projects often take multiple years, though some certainly stretch beyond a decade. Unfortunately, a lack of credible decision information frequently prolongs the rebuild processes. How the parties manage the rebuild is naturally key, so this requires building trust, creating continuity and increasing decision velocity through the transparent exchange of information across the vast network of teams involved in the rebuild process. With the right systems in place, teams achieve objectives at a significantly accelerated pace—in one case cutting the timeframe to six months rather than the 18-24 months it would have otherwise taken to start the long-term rebuild process.  

Applying the Key Lessons

Striving to be resilient and continue making progress to manage rebuilds better and faster using today’s available technology tools and data is crucial to making disaster recovery outcomes better for all affected. Below are four key lessons from disaster recovery efforts that are transferable to stakeholders serious about improving everyday projects. 

1. Provide Seamless Access to Information 

In complex and chaotic disaster recovery situations, the biggest blocker to rational and sustainable decisions traditionally is the granularity of information required. In a typical situation, people will have different information in their silos that is not integrated. This creates frustration because information either isn’t available or takes too long to find. In the latter scenario, leaders frequently must change certain decisions that were made because they suddenly have information that wasn’t previously available. 

Increasingly, project leaders are examining lessons learned from completed projects to understand the value of investing in technology. By creating an environment that brings all data sources together—whether they are from legacy systems or modern platforms—leaders make information easily accessible to all teams. As a result, all parties can look at certain attributes from a much richer understanding of the issues and concepts, leading to better decisions and outcomes.

2. Enable Information Transparency

 A key feature of decision making is the balance of power that a person holds and the faith people have in them. If people trust an information source and see him or her as open and transparent, meaning they welcome and genuinely consider broad opinions, it’s easier for people to get involved and remain engaged. 

Similarly, by mandating the use of trusted software and database systems with features such as built-in security, leaders can enable people to rely on one version of the truth. As a result, all stakeholders can see tracked changes within the system—even years later—as everything is audited and traceable. Because what is being said by word can be traced by action, this allows people to confidently make decisions much quicker.

3. Efficient Management of Change

One thing common to all projects is the level and frequency of change in the speed at which decisions are approved or rejected. In the past, delays in making complex decisions were common due to project leaders’ inability to know all the implications all the time. Instead, many decisions often had to be made based on two or three flat data points. Not surprisingly, delays frequently led to missed deadlines or other implications that decision-makers simply couldn’t foresee or fully understand.

Today’s information systems, when properly applied, allow project leaders to consider a variety of options and augment their intelligence to help understand the richer picture of the unseen data.

As a result, workflows that used to take weeks for governance can now take hours. Project leaders can intelligently inform management levels about required actions and systems can automatically determine who should authorize changes, removing weeks or months of delay. This automates the electronic process at a previously unimaginable pace, and the system inherently provides various levels of control.

For example, with a technical scope change, if a project manager already knows who the scope belongs to, Intelligence Augmentation —technology systems designed to improve a human decision-maker’s function or capability—automatically informs the project manager that a particular stakeholder should be involved in the acceptance of the change. The system informs the stakeholder and provides the intelligence they need, thereby supporting the project manager and eliminating potential mistakes such as an incorrect material being used. 

In one project, stakeholders were able to be informed that a delay by a couple of days would mean that the whole project would move by nine months because of environmental windows. Decision outcomes that can be represented digitally more powerfully show stakeholders the far-reaching impact of decisions within a project, which are sometimes based on one or two data points. In another example, by communicating that a digital system for exchange of all information was required, a project manager was able to manage 170,000 interactions and exchange 10,000 documents with 32 different organizations and 300 personnel in the first year of one project. Without a digital system, it wouldn’t have been possible to maintain rationality.

4. Communicate and Link Actions and Impact

Disaster recovery operations involve multiple organizations, with a vast group of stakeholders ranging from government to emergency services and community end users. With emotions and organizational agendas at the center of the decision-making process, all parties require believable information.

Transparency and auditable provenance of information is extremely important. Similarly, the governance across everyday projects also involves vast teams all needing to work from the same information, echoing challenges that many projects teams face. 

When boiling down the issues and outcomes from disaster situations, there are many lessons that could be adopted across all projects. Budget and funding concerns impact both, as does scheduling from the planning perspective. There are also many occasions where integrating different IT tools into a single platform is a primary objective, particularly to establish a CDE. 

A critical lesson for superior performance is to avoid being trapped by the enterprise system alone. Instead, stakeholders must embrace an openness to using other agnostic tech tools to help the Geographic Information System, for example. This collaboration of solutions will enable stakeholders to work faster and smarter, with information shared with all parties more regularly in real time. 

Overall, lessons can be found in lots of different scenarios. Disaster recovery is a key, heavily documented category from which the E&C industry can learn and apply principles. The industry needs to be more connected to what’s happened before and what’s happening around it. It also needs to be prepared to not just capture data but also to share it across a project and across the industry for better visibility. The more examples the industry can use to learn, the better the approach it will be able to take across projects to produce more connected teams, safer worksites and higher quality outcomes.

Print

 Comments ({{Comments.length}})

  • {{comment.Name}}

    {{comment.Text}}

    {{comment.DateCreated.slice(6, -2) | date: 'MMM d, y h:mm:ss a'}}

Leave a comment

Required!
Required! Not valid email!
Required!