Architecture, Engineering, and Construction (AEC) + Environmental Consultancy (EC) firms are always looking for new and innovative ways to communicate and collaborate on project work. But all too often, we see projects teams lacking a proper communication and collaboration strategy. To me, this is a bit like running a marathon and stopping two steps from the finish line. However, in encouraging news, many AEC firms begin to align with the ISO19650 standards for delivering BIM and now GIS content for the built and natural world. Even more encouraging is that we see alignment with this primarily BIM-driven standard to include GIS capabilities. You can find a great example of this alignment with ISO19650 in this StoryMap from Khaled Alhoz (August 30, 2021).

To support AECs in working projects, organizations are sharing content for feedback, and publishing content for consumption in a way that aligns with the ISO19650 standard. Recognizing the complexity of “projects” in the AEC space, Esri has developed several approaches, schemas, and licensing vehicles to support the many approaches we see to both project collaboration and delivery.

But to get this blog started, we should first define a project in the context of an AEC. Simply put, a project is an ordered series of tasks that need to be completed to reach a specific successful outcome. A project is also driven by a scope of work agreed upon by one or many parties. For example, we may have a contract for a project to redevelop a downtown mixed-use community or a project to remediate contaminated land. In these scenarios, the AEC delivers collaborative services work through the container of a Project.

Defining what is not a project is equally important because this scenario comes up in AECs today. The following are considered commercial offerings and not projects:

• When an AEC develops a repeatable solution or product they sell it on the commercial marketplace or directly to customers.
• When an AEC creates GIS content, then hosts the data\apps and manages that content in an ongoing manner (effectively acting as the GIS department for a client).

The critical difference presented in these scenarios is that these are market-focused commercial offerings where the AEC is monetizing the Esri technology (e.g., ArcGIS) in an ongoing manner to an end customer (or 3^rd party).

For both scenarios, Esri does have offerings that will support the AEC’s end goals and objectives. But we must differentiate these two pathways for AEC and other Commercial entities using ArcGIS because it changes the approach one must take to deliver outcomes to their customers or clients.

Projects

Let’s first talk about collaborating on projects to get the ball rolling. From an ISO19650 perspective, Collaboration is defined as communications and coordination between two or more parties. In this situation, we have an Appointing Party who initiates, funds, and bears ultimate responsibility for the project. In many cases, this might be a government entity (think rail provider or City government) or an electric utility (think power provider).

We may have one or many Appointed Parties. These are the organization, companies, and joint ventures that are Appointed (e.g., contracted) to do the work. In many cases, these are AEC or Environmental Consulting firms.

So, it would make sense that we keep this in mind when we start talking about the Collaboration of project information and deliverables. More directly, when we speak of Collaboration for projects, there are two primary patterns Esri recommends:

1. Direct Collaboration – between the Customer and its suppliers (e.g., AECs).
2. Project Delivery Collaboration – between the AEC and external parties (clients, customers, stakeholders, subcontractors, etc.).

In the following two sections, we will dive into the details of each scenario to help you understand the recommended approach and the workaround approach when the first option is a no-go for the Appointing Party (e.g., the AEC customer).

Collaboration Directly

If we are talking about Collaboration, we would be remised if we did not discuss the best practice first. The best way to collaborate is direct. Meaning if a City is running a project, they are aligned with the concept of the Appointing Party in the ISO19650 standard, and the AEC firm(s) become the Delivery Teams. This also means the City (or its designated party) should take the lead in coordinating work products to help the project be successful. This also helps streamline the transition from construction handover to operation by the City.

What does this look like practically? Ideally, the City (or its designated party) would host the central data management system from which all other Delivery Teams connect and collaborate directly. The following figure illustrates an example where the City has opted to host a firewalled collaboration and delivery environment from its internal system and will easily allow collaboration with the Appointed Party (AEC1) Delivery team through Partnered Collaboration.

This also supports the expansion of the project to additional AEC Delivery Teams. And this is the inevitable evolution of a project because it’s rare that one AEC firm performs all the aspects of a project (e.g., environmental permitting; architecture and design; design and engineering; construction; construction management, and handover).

This direct Collaboration between the Appointing (the City) and Appointed Parties (AECs) is the pattern that makes the most sense and reduces costs and complexity around content management, licensing, and identity management.

When collaborating directly in a scenario like this, it is suggested that there be some separation between the City’s production systems and its project coordination \ delivery systems. The most common way to make this work is through an ArcGIS Online Partnered Collaboration.

Sharing through Partnered Collaboration makes sense in this scenario because it allows both parties (AEC and the City) to separate but still collaborate bi-directionally. Thus, making this a true collaboration (as opposed to a copy or referencing data from one environment to another). Now, this does require ArcGIS Online for both parties, and it does require the establishment of trust between the two environments. But this is where the idea of separation comes into play.

Now that AEC 1 firm can easily share critical environmental and social data collected to support the permitting process directly with the City. The City can safely and securely review the changing content as it is developed, and any project problems can be identified much earlier. This approach also opens future collaboration opportunities at the project level as additional phases of the work commence. For example, now that the permitting process is wrapped up, the City can invite AEC2 and AEC3 into the picture to start the design and engineering work.

Once again, we are using Partnered Collaboration to share content between each of the AECs and the City. This also allows the City to control which of the Design and Engineering AEC contractors can see the environmental permitting data from AEC1 based on geography and need.

When it comes to this type of direct collaboration, many project initiators, like the City of Zion, cannot manage a project coordination environment. In these scenarios, we have seen third parties like an AEC firm, Esri Business Partners, or Esri Distributors get directly involved on behalf of the City. They may act on behalf of the City to manage the project environment for the City. This is especially common for mega infrastructure projects like High-Speed Rail 2 in England. For that project, HS2 did not have the ability or experience to manage a coordinating ArcGIS Project environment, so they hired Esri UK to manage the Project Collaboration Environment for the project’s duration. This approach then helped the many AEC suppliers working on the project to align under one system instead of constant jockeying to determine which firm manages the ever-growing GIS and BIM content.

As you can see, this collaboration model makes sense, but it does require a certain amount of maturity on all sides of the equation. We all know that things don’t always work this smoothly in the real world. This is why Esri has created a secondary option when this ideal collaboration scenario cannot be met directly or indirectly, like in the HS2 example.

Collaboration with Project Delivery

In scenarios where you cannot collaborate directly, deploying what is known as a Project Delivery Subscription (PDS) may be necessary. A Project Delivery Subscription is simply an ArcGIS Online environment that acts as an intermediary between the AEC and its clients, partners, and subcontractors.

The primary driver behind a PDS is the need to collaborate securely with third parties while maintaining separation between internal production systems, which means parties external to the AEC or commercial firms. A secondary driver behind PDS is its licensing capability to be used in a project setting with third parties. AEC firms can invite collaborators in from the outside without violating their existing licensing agreements.

Above all else, containerizing project work for a client is a best practice. This is primarily because it isolates the work and ensures that you have no crossover between other AEC client projects. Simply using groups within ArcGIS Online or ArcGIS Enterprise does not guarantee the security of the information when the environment is occupied by many parties (e.g., a multi-tenancy environment). A PDS comes in handy because it creates natural isolation centered around specific clients or projects. It becomes an externally facing system of engagement with a very specific purpose, to deliver the project.

There are several setup options for PDS environments, but the most common is via ArcGIS Online because it requires less management and overhead costs to maintain. However, regardless of how a PDS is deployed, it is wise for the AEC firm to step back and establish an information management plan that clearly spells out how the PDS is to be used and not used.

For example, let’s say that the AEC2 firm needs to communicate design alternatives for our City project. In this scenario, the City doesn’t want to allow the AEC2 firm into its internal production environment. They have asked the AEC2 firm to host the project content while the project is in flight. IN THIS SCENARIO, the AEC2 will stand up project delivery subscriptions to support collaboration and delivery. Their project \ task is to deliver design alternatives. They will need to communicate a wide range of content like basemap, drone capture data, 2D\3D design drawings, traffic plans, & design impact assessments. The AEC2 firm will use PDS to communicate “Published” data directly to the City and the project stakeholders.

Additionally, the City has asked the AEC2 firm to support public comment on the design alternatives. In this case, they will leverage Hub Premium from within the ArcGIS PDS to create a publicly facing website to communicate project intent and solicit feedback from the community. The City will need view access to the PDS environment via ArcGIS Online Viewer Named User to accomplish this. The AEC2 firm will also need to extend the PDS environment to work with Hub Premium to get credentials that allow you to track and manage public feedback.

Behind the scenes, the AEC2 firm will gather and create content within its ArcGIS enterprise environments; once the data is ready to be published, it will be shared through collaboration mechanisms with ArcGIS Online. It is important to note that an ArcGIS enterprise environment can only collaborate with one ArcGIS Online environment (see past scenario blog). For this reason, we often see a PDS configuration that Leverages a singular ArcGIS Online environment to act as the Publication Environment. The critical requirement for this deployment pattern is the 1:1 rule and the ability to act as a coordinating proxy for all externally published content from the AEC firm’s ArcGIS Enterprise subscription.

AEC Project Delivery is only meant to be a stopgap when the project initiator (the City) cannot or will not host data, and there is still a need to collaborate and deliver digitally. Even when PDS is used for projects, it is very common to hand over the entire environment to the City at the outset of the project to take ownership of the project’s digital data and support ongoing maintenance workflows.

Commercial Solutions

Sometimes when an AEC has created IP around services utilizing ArcGIS, they will see an opportunity to make a repeatable Solution or Product. In these scenarios, we move the conversation from simple project collaboration to repeatable solutions sold for a commercial profit. Therefore, we move away from Collaboration in these scenarios and start talking about Platform as a Service or Partner Collaboration scenarios. For more information on these scenarios, please reach out to your Account Manager or Partner Manager at Esri.