The New Hospital Complex (NCH) on the site of the Hôpital de l'Enfant-Jésus is not only one of the most ambitious construction projects in Quebec City; it is also a world-class project developed as part of a unique design process.
To give an order of magnitude to the type of management involved in a project of this scale, here are some statistics:
The architectural team alone has more than 80 members working simultaneously on the different components of the project. This team is composed of six (6) architectural practices from Quebec City and Montreal. The main project office is located in Quebec City near the site, but satellite offices are also in place at various consortium members.
The design and implementation of the plans are concretely spread over several phases of work. This is reflected in 21 distinct phases within Revit, including: existing structures, new construction spread over a period of time, as well as multiple redevelopments.
The amount of models used by the different components of the project has increased in parallel with the complexity of the buildings. As of spring 2020, the number of models used in Architecture amounts to 37, of which 8 are dedicated to a single building. This is still very little compared to the more than 400 models for all disciplines combined. The main culprit being the different MEP models, which number more than 300.
The size of the project (which we kindly call MEGA-Project, logical progression beyond Large Project), combined with the integrated design in live links, gives rise to a multitude of challenges. This blog will explore these different challenges and their solutions.
BIM One is proud to be part of the team for this project, to share our expertise in the construction industry’s digital transformation, BIM management of projects and our years of experience in the use of many technological tools. We are very happy to share in the next sections our BIM good practices that we developed and applied on this New Hospital Complex.
INTRODUCTION TO THE PROJECT
Project and team description
Before entering into our first topic, it is relevant to take a step back and try to visualize this project in its entirety. The New Hospital Complex (NCH) is located on the site of l'Enfant-Jésus in Quebec City. Its estimated budget of nearly $2 billion makes it probably one of the largest hospital projects in the region. It is possible to consult the CHU de Québec–Université Laval (CHU) website to explore the various facets of the project.
Here is a final projection including the different components and their planned opening year:
In addition to the considerable scope of the project, it is unique in its design method. The entire project is modeled in Revit in with live linked models, and that, for all disciplines combined. Interdisciplinary coordination is therefore done in real time on the BIM 360 DOCS collaborative platform. Each discipline directly integrates the models of the others into their design and documentation process.
In order to give an order of magnitude to the type of management involved in a project of this scale, here are some statistics:
- The architecture team alone has more than 80 members working simultaneously on the different components of the project. This team is composed of six (6) architectural practices from Quebec City and Montreal. The main project office is located in Quebec City near the site but satellite offices are also in place at various members of the consortium.
- The design and implementation of the plans are concretely spread over several phases of work. This is reflected in 21 distinct phases within Revit including existing structures, new constructions overtime, and multiple redevelopments.
- The amount of models used by the different components of the project has increased in parallel with the complexity of the buildings. As of spring 2020 the number of models used in Architecture amounts to 37, 8 of which are dedicated to a single building. This is still very little compared to the 400 and more models for all disciplines combined. The main culprit being the different MEP models which number more than 300.
The size of the project (which we kindly refer to as the MEGA-Project, logical progression beyond the Big Project) combined with the integrated design in living links gives rise to a multitude of challenges. This series will explore these different challenges and their solutions.
INITIAL DOCUMENTATION NEED
Transversality / independence dichotomy
In a project of this size, plans documentation and annotation is a major task. During the initial start-up phases of the first components of the project, several workflows were contemplated. The needs of the design team then surfaced.
Faced with such a large team and such a wide range of projects, a compromise had to be reached between the transversality of the inter-team tools and their design independence.
The transversality of the data between the different models of the project had to be preserved in order to deliver a standardized product to the client, while having the possibility of being able to recover the work already done on certain phases of the project in order to apply it elsewhere.
However, the work of a design team must not influence the other components directly involuntarily. All the information included in the plans must be kept in full and without alteration once issued. In a completely transversal system, changes made by a user to certain data may affect other occurrences. Just as a change in a family type will change all instances placed, it is not possible to ensure that a change does not have unintended consequences on design work already done or in production stage.
The compromise to be reached should therefore guarantee a certain degree of independence between the components of the project, while allowing the transversality of plan keynotes to be maintained.
Independent plan annotations for each building
Since the design and production periods of the different components are staggered and overlapping, the plan annotation needs are unique.
Expansion of the system
There should be an ability to add independent keynotes easily and quickly for new projects.
PROPOSED SOLUTIONS AND LIMITATIONS
Only one keynote file per model
The main limitation of the conventional Keynotes system is that only one source file can be used. This file in text format (.txt) must contain all the notes to be used. Changing files for the purpose of using different keynotes poses a huge risk of error and inconsistency.
The situation required access to component-specific notes in adjacent models. Some files had to combined to be able to access their information in a transversal way.
Multiple simultaneous users
One of the main issues that was considered when implementing a new solution revolves around remote file access. When Revit tries to access its keynotes file, it uses a local path, which means a fixed location on the user's computer. This path is recorded in the central file as an absolute path and must be standardized for each user. One of the challenges of the system is therefore to find a file hosting platform that will have a fixed and absolute path for all users, regardless of their location.
Since the people who use the notes are not necessarily the same as those who write them, it is not possible to simply host the files on a single workstation locally. The size of the team also prevented manual file transfers between the various satellite offices, and such manipulations would have been potential sources of many errors and loss of work. The use of a centralized platform for all potential users of note files is therefore a central need.
The document management infrastructure was already implemented at the beginning of the project in the form of a dedicated, client-managed SharePoint server. The files were therefore hosted on this platform in a dedicated folder and accessible via a network drive deployed on each computer.
This solution proved to be functional despite the instability of the server, which required additional management during access loss.
Naturally, one of the first questions to have when discussing new tools should be: "What already exists, and can we use it?". Some keynotes management add-on software already existed when the project was deployed, but they were rejected for a few simple reasons.
- Since the computer equipment available to the project office is managed by the client, all deployed software must be approved and installed by the IT department in charge. This precaution, although necessary to ensure the IT security of the project, greatly complicates the deployment and updating of tools directly on site. In addition, the integration of multiple satellite offices, each with its own IT management department, makes it complex to use software external to the basic tools.
- During the testing phase of these different management tools, their limits were also quickly reached. The scale of the project was causing considerable slowdowns, and the use of the tested add-on software became impossible. Here are some tools that were considered when deploying the keynotes files. It would be appropriate to revisit these tools in a future project and evaluate their benefits in comparison with a traditional system.
- Keynotes manager (Revolution Design)
- Manage keynotes (pyRevit)
- Macaw Plus +
In parallel with the deployment of the annotation system, the question of deployment inside the models was explored. One of the methods which was briefly tested was the use of element keynotes.
At first glance, the standardization of information attached to families directly seemed to be able to reduce the risk of disparity between different text occurrences. However, the blocking of information attached to the type of family would have caused a proliferation of the number of family types, especially in the case of detail components. Each variation of text requires a different note, so a new family type must be created. When considering all the possible variance in the information that can be associated with a simple gypsum panel, the idea of element keynotes was quickly rejected.
As much as the management of family versions in a transversal way in all the models of the project has its share of challenges, there is no need to add this additional layer of complexity.
NOTES PHASE 1 - INDEPENDENT FILES
The first phase of the project included the components of the Power Plant and the Integrated Cancer Centre. Being buildings largely independent of each other both geographically and design-wise, the need for transversality has been little felt.
It was therefore decided to separate the keynotes by components in order to avoid overlap and reduce the risk of error when editing and correcting the notes.
The note files have been separated so that they have only one entry point per model. The work thus divided per team ensured that each group was in control of its own annotations. A single Excel file was created for each Revit model representing a project component. The drawing sets were thus able to retain their individuality. Since working simultaneously on the same Excel file was not possible at this point, keeping a limited number of users on each file avoided modification conflicts.
Setting up shared files
If there is an already established platform, the identification notes have been placed on the customer's SharePoint server. This location ensured that the satellite offices could modify the files belonging to their respective components.
Initially, the keynotes were entered into an Excel workbook and then exported in a Revit-supported text format. A simple script ensured that the file was always saved in the same location and format, minimizing the risk of error.
NOTES PHASE 2 - CENTRALIZED FILE
The progression of the project phases inevitably brings a higher level of complexity. Phase 2 buildings are juxtaposed with one another and often interconnected. The interventions are no longer done within a single isolated model but in a transversal way as much on the modeling as the documentation spectrum.
Some buildings connect to existing old portions as well as new construction from an earlier phase. This spread results in the multiplication of interventions in several models for the same drawing set.
Following this spread, it became necessary to be able to access the keynotes of a single project in several models but also to be able to classify the keynotes relating to different projects in a single file.
A good example of this need for transversality is illustrated below. The drawing sets numbered 0501 and 1302 for their respective projects involve work in 4 adjacent models. The same notes must therefore be found in each model, making the approach of the single file impractical. The risk of error and omission brought by the need to copy notes between files is too high.
It was determined that it was necessary to be able to access the specific notes of other drawing sets than that of the current model while ensuring that the information remained constant, but also that the drawing sets and the information contained in them should not be modifiable following their issuance. Basically, a note already issued should not be reusable for other purposes for drawing sets still in design and subject to change.
- Each team responsible for a project has access to its own Excel file that is exclusive to it. Generally speaking, no more than 2 or 3 people per team have the task of adding notes to the file, so the risk of overlap is greatly reduced. Coordination is also easily done within a small group of users typically in the same satellite office.
- Once the changes are made, the individual file is saved and the person in charge opens the Excel file "MASTER" in which all the sets are collected automatically at the opening. A backup script then consolidates all the information contained in the different tabs before exporting everything into a single text file.
- By reloading this keynotes file into Revit, all notes become accessible according to the predetermined ordering. With the drawing set prefix added to each note line, organization by project is possible.
Here is a diagram illustrating the process of using files in two different models with individual and shared drawing sets.
NOTES PHASE 2.5 - WEB PLATFORM AND DESKTOP CONNECTOR
In the wake of lockdown and remote work, an opportunity for improvement has presented itself. Since the last platform migration the models are hosted on BIM360 DOCS, which also gives us the possibility to deposit files of formats other than models. The Autodesk Desktop Connector add-in software allows us to access these files by an Absolute path, which is required for access to the note files by multiple decentralized users.
Moving from Excel to Google Sheets for keynotes brings several notable benefits to large-scale deployment.
- The possibility of modification by multiple users simultaneously.
- The visualization of the changes made by each user in real time.
- Simple access on multiple platforms.
- Strict access control in several levels of permissions.
- Robust change history and recovery system.
The central Excel file is then connected to each individual section of notes by a series of queries. The consolidated data is then exported to text format that can be used by Revit.
Access through the Desktop Connector is then relatively easy even if occasional connection problems arise. The situation is quite easily resolved at the level of each user by a simple disconnection of the file and a reloading of the notes in Revit.
AVENUES FOR IMPROVEMENT AND CONCLUSION
Basically, the analysis of the progress of the working scheme of keynotes on the NCH project clearly shows us at least one thing: the scale of the projects drastically influences the methods of realization down to the smallest details. Aspects of conventional projects that we believe we have mastered and take for granted can suddenly become inadequate when faced with the scale of an overwhelming need.
The interaction between the multiple phases and components of the project coupled with the different realities of the satellite offices quickly exceeded the capacity of the initial system. It is in the face of these often-unexpected challenges that the teams responsible for BIM on such a project manage to innovate while remaining within the given framework and with the tools available.
Naturally, the solutions chosen are adapted to the needs encountered and vary from project to project. In this case, they even change throughout the same project.
Ultimately, this way of managing annotations on plans allowed multiple users to coordinate their documentation efforts and minimize the risks associated with quick plan issues. By referring to a single and simple user procedure, all users were able to contribute to the documentation of plans, regardless of their level of suitability with regards to modeling or drawing.
Flexibility when analyzing needs and available tools ensures an adequate response, regardless of the size of the project.