PDF Version
Introduction
The construction administration (CA) phase of a project can be the most exciting phase where construction actually begins. However, it can also be the most stressful as contractor and design teams must coordinate to ensure that the final product delivered meets design specifications, building standards, and owner requirements.
Law Insider defines construction administration as “administrative services provided by a governing body or an architect, a landscape architect, or an engineer, and includes providing clarifications, submittal review, recommendations for payment, preparation of change orders, and other administrative services included in the agreement…”
For design teams, the administrative burden to respond to Requests for Information (RFIs) and review hundreds of submittal packages for each project can be time-consuming and costly. Contractors rely on prompt responses from the design team to keep the project on schedule and on budget.
In today’s fast-paced construction world, having an electronic system for processing submittals and RFIs is most often specified as a contractual requirement. And many AEC firms spend hours researching software solutions and spend thousands of dollars a year on software licenses and subscriptions. However, recognizing a return on these investments requires more than just installing software.
There are several areas outside of the scope of CA software solutions that project teams should address to ensure that they are getting the most value from their software investment. Taking time to address the people and process aspects of the construction administration process before logging into the software will certainly pay off.
Project teams should also understand what software features and functions are available and applicable to the project prior to purchase and use. Many features are difficult to implement once submittal and RFI processing has started. In addition, taking time to properly configure the software and train the project team will also increase the probability of a positive outcome from the software investment.
What Construction Administration Software Cannot Do
Construction Administration software significantly improves the submittal and RFI review process by providing an automated exchange of information, tracking and reporting mechanisms, status reports, and notifications to keep the team on track.
However, there are considerations that are outside the scope of CA software. High-performing project teams focus on the people and process aspects of a project with an emphasis on improving overall team performance. The software cannot clearly document and communicate the rules of engagement for submittals and RFIs. It also cannot outline communication procedures or determine the requirements for organizing data. And although project team training on the software cannot usually be enforced, it will help a project team to fully utilize the software to increase productivity, reduce errors and rework, and proactively manage risk.
The Software Cannot Establish the Ground Rules
Most ground rules for construction administration are documented in the General Conditions section of the contract, including provisions for handling of submittals and RFIs. However, leading project teams are expanding these rules to limit unnecessary processing, eliminate potential contractual abuses, and provide more clarification of roles and responsibilities.
Acceptable Use of RFIs
The construction RFI is a formal written process where all parties, including designers and contractors, will clarify information gaps in a construction document. But often, RFIs create more ambiguity as the purpose of the RFI is not always used consistently by the entire team.
It is not uncommon for specific use cases to be called out to identify acceptable and unacceptable use of RFs in the General Conditions of the contract. In a blog written by J. Scott Shannon, Esq. and Lee/Shoemaker PLLC and posted by AIA Potomac Valley, examples of unaccepted use of RFIs are outlined as:
- Incomplete RFIs waste valuable time when all related information and documentation required for the design team to respond is not included. Contractors must go back to the subcontractor team if there is missing information. Design teams are forced to return RFIs with an incomplete status which wastes additional time. Although standard contract forms such as AIA document G716™ 2004 specify the information to include with an RFI, the form does not specify types of documents such as shop drawings that should be included as references to ensure the correct documentation is provided to answer the question.
- “Already Answered” RFIs increase the volume of RFIs and add more burden to the design team. These types of RFIs occur when the contractor team did not complete the proper due diligence to find the answer to the question that was already documented and available.
- Contract Sum or Contract Time Changes requested through an RFI are usually included as prohibited in the contract. Although questions raised in an RFI may have cost or schedule implications, the RFI should not be used as a replacement for another contractual document such as a change order.
- Requests for Substitutions may also be called out in the contract as prohibited.
By documenting and communicating the rules for acceptable and unacceptable use of RFIs, any ambiguity is removed. Eliminating the noise of unnecessary RFIs will improve the quality of the RFI response process, enabling the design team to respond in a timelier manner.
Submittal & RFI Review Periods
Contracts generally include provisions for submittal and RFI procedures, including specification of the review period. Typically, a response time of five business days is a default for RFIs and ten business days for submittals. Many CA software applications allow these dates to be configured by the software administrator and use the review period to drive the workflow and notifications within the software. The review period date may also be used to track performance. The software application administrator and project team should understand how the review period dates are used in the software to avoid any performance tracking and reporting issues during the project.
Teams should also be clear as to how the software handles the review period for revisions and resubmissions. If the time to process modifications specified in the contract differs from the original review period, teams should verify how the software handles this.
Roles and Responsibilities
The contractual ground rules may also include provisions for the assignment of responsibilities. If responsibilities are not specified in the contract, the project team may want to review responsibilities related to using the software before entering data.
Many contractor teams assign responsibility for initiating an RFI to one or two individuals. This provides additional control to ensure the RFI is validated before it is sent to the design team. The design team may also want to assign responsibilities to forward submittals and RFIs to engineers and consultants and track response times back to the contractor. For some projects, such as federal government or municipal projects, the owner team may want to have the final review authority before a submittal or RFI is returned to the contractor. Documenting the workflow and approval process is key to ensure that final review authority is not bypassed in the review process.
The Software Cannot Determine Team Communication Protocols
Timely communication during the construction administration review process is key to keeping the project on track. Although automated CA software packages can streamline email communication, the software is not a substitution for a human conversation. Project team members can still talk to each other outside of the software.
Many project teams outline communication procedures for meetings but fail to address communication requirements for the software during the review process. There tends to be two schools of thought around email notifications: notify everyone for everything, or only send email notifications on a “need to know” basis. It’s easy to add project team members to automated email distribution lists; however, too much communication is not necessarily a good thing. For example, does the structural engineer need to receive an email notification for all interior design submittals? And does the contractor need to receive an email notification every time a submittal or RFI is forwarded from the design team to an engineer or consultant? Suppose a team member’s inbox is flooded with automated email notifications from the software application. In that case, there is a high probability that they will miss the notifications that are most important for them.
There may be options other than email notifications that are available in the software to track ball-in-court. Automated audit trails or status reports may be a better option than receiving an email notification.
The Software Cannot Plan & Organize Project Workflow
Prioritization & Scheduling
The software cannot determine the order in which RFIs, and submittals are entered into the system. Project teams may want to determine a prioritization scheme for submittals and RFIs. This ensures that responses to critical items are handled promptly. For example, the contractor may require a response to an RFI for a recent structural issue before a receiving a response to an RFI sent earlier regarding paint color.
Most contracts include a requirement to develop a schedule for submittals. However, the schedule is often managed in an Excel spreadsheet. If the software solution includes an automated submittal schedule, it is worth taking the time up front in the project to put this schedule in place. It may require a bit more work, but will it ultimately save time for the project’s duration.
Aligning Terminology & Systems
Each design firm uses its own terminology for submittal review status. Although there is often overlap in review status terminology across firms (make corrections as noted, not reviewed-incomplete, etc.), the action required of the contractor may differ. Having this conversation before processing submittals will eliminate any confusion as to the required action.
The software cannot force all parties to use the same software. But if the contractor and design teams are using two different CA systems, teams may want to review what information needs to be transferred, and agree on how to map that information between systems. For example, if each company uses a different numbering scheme, should the project team choose one? And if not, how teams reconcile information between systems? Defining required information and then mapping that information between systems will prevent errors if fields in the software have a different meaning or is used in different ways. Mapping issues are resolved if the software systems have been connected using APIs where the software pre-established the mapping.
Categorization of Submittals and RFIs
The software application can provide the mechanisms to categorize submittals and RFIs, but it cannot define the categories. Upfront planning of how submittals and RFIs will be categorized and organized in the software can save time locating information later in the project, and it can also reduce errors with critical information not being misplaced.
Project teams may want to take a two-pronged approach to organize information. They may first want to determine how information needs to be separated out for tracking and reporting purposes. They can also look at what categorization options are available in the software. There may be mechanisms available to organize information in the software that the team did not consider.
It is much easier to categorize items at the beginning of the project versus having to go back later to try and sort out what items belong to which categories.
Common submittal categorization options include:
- Trade or discipline (civil, structural, MEP, etc.)
- Informational vs. actionable – also categorized as Performance of Work vs. Administrative.
- Project Phase – preconstruction, construction, and close-out.
- Building structure – parking garage, building A, etc. (if submittals will be unique)
RFI categorization options:
- Project Phase – preconstruction vs. construction phase
- Trade or discipline
- Priority
- Potential budget or schedule Impact
Once the team determines what categories are required for submittals and RFIs, they can then determine how to implement this in the software.
Submittal Packages
Project teams may also want to specify how submittal documentation should be packaged. The design team may prefer that all documents be submitted individually, but design teams could also specify that certain documents should be bundled and submitted as a package. Some design teams prefer “action” related documents such as shop drawings, samples, or product data, be submitted separately. Other “informational” submittals may be bundled to reduce the number of submittals.
Understanding how the software handles submittal packages or bundles is key. The software application may require the contractor to submit documentation by specification section. The software may also allow items to be bundled even though the team has decided not to process submittals this way.
It is also important to understand how the software application will handle the review of a bundled submittal. If the design team rejects one item in the package, will the software require the architect to reject the entire package?
The Software Cannot Train Your Team
Training on the software application is one area that is often overlooked or hurried through. Contractor and design teams who have been working together for some time and have been using the same software are most likely on autopilot and may not need additional training. But many times, new people on the project team are not familiar with the software. In addition, CA software solutions are constantly evolving, adding new features and functionality, so it is worth spending time at the beginning of the project to learn what is new or has changed.
There are also hidden benefits to training. Training also allows the team to discuss and agree on people and process components, including communication protocols and workflow. Live training sessions where the contractor and design teams can jointly discuss and agree upon workflow, organization, and communication provide an additional opportunity for everyone to get on the same page. If training is offered on the proper configuration of the software, many of the areas outlined above should be covered.
What Construction Administration Software Can Do
The Software Can Provide Interoperability
Software technology providers can take the burden off project teams for mapping information between systems. Mapping metadata and common fields between software applications can be accomplished through an Application Programming Interface (API). For example, Newforma has mapped the submittal and RFI information between Project Center and other CA applications including ConstructEx and Procore.
Interoperability between CA applications enables the contractor team and design team to use the software they prefer without manually uploading, downloading, and rekeying information between systems.
The Software Can Enforce Required Information
Most software applications have required fields that must be completed in order to process the submittal or RFI. This is especially helpful when all team members are using the software. For example, many teams have subcontractors submit their information via email. If the submittal or RFI emailed to the contractor is incomplete, the burden is placed on the contractor to track that information down. However, if the subcontractor team completes the submittal or RFI in the software form, they must enter the required information to proceed. This software cannot prevent the subcontractor from failing to upload all required attachments, but the file upload box on the form serves as a great reminder.
The Software Can Automate Governance and Controls
The software can provide automated controls that are often missed with manual processes. In addition to preventing certain types of users from taking actions, such as issuing an RFI, the software can also prevent users from accessing information before it has been fully approved or finalized.
Some CA software solutions assign users to specific roles (subcontractor, contractor, design team, reviewer, owner, etc.). These roles include automated workflow controls that govern what a user can and cannot do in the software. For example, there may be controls that restrict subcontractors from issuing an RFI or a submittal directly to the design team. Subcontractors can only send submittals and RFIs to the general contractor as a draft. If the software workflow does not match the desired workflow for the project, adjustments to user roles may be required.
Some CA software solutions can also restrict who has access to what. Workflow controls or user permissions in the software ensure that the team can only access information that is applicable to their function. For example, the software may include workflow controls that restricts the contractor from accessing submittal and RFI information that is in review with the design team. This prevents the contractor team from accessing and acting on review information before it has been fully approved. If these types of controls are not automated, other processes may be required to ensure proper governance of the data.
The software can also provide automated audit trails of who access what and when. Newforma Project Center includes a feature to track the transfer of documents to project team members, providing complete visibility to when the document was downloaded and accessed.
The Software Can Provide a Structure to Organize Information
Although the software cannot define the structure for organizing information, it can provide the mechanism for organization. For example, the software may include options to categorize submittals and RFIs by workflow status (draft, in review, returned to contractor, closed), and trade or discipline (civil, structural, MEP, etc.). This enables subcontractors, engineers, and consultants to easily locate submittals and RFIs targeted for their discipline. There is also a generic category field that is user defined. This field can be used to organize submittals and RFIs by project phase (preconstruction, close-out), priority (high, critical, etc.) or type (action, informational).
The Software Can Keep Team on Track with Automated Workflows & Notifications
Many CA solutions have an automated workflow with features that enable the submittal or RFI to seamlessly travel through the review process, transferring required information and associated documents directly to the person next up for review. Some CA solutions have features to “auto-forward” submittals and RFIs that can be configured by discipline to direct the submittal or RFI sent from the contractor directly to the responsible engineer or consultant reviewer. The architect is notified of the transfer by email but is not required to forward the submittal or RFI manually. This feature is designed to prevent any potential bottlenecks if the architect is out of the office or unable to forward for review.
The software can also help the team stay on track with ball-in-court email notifications and overdue reminder emails. For example, an email notification can be sent to the design team when a submittal or RFI has been sent by the contractor. The contractor should also get an email notification when the design team has completed the submittal review or has responded to an RFI. Reviewers should receive an email reminder when a submittal or RFI is approaching the deadline to complete the review. As mentioned previously, proper configuration of email notification distribution lists in the software will ensure that the appropriate team member is notified when their response or review is required.
The Software Can Provide Tracking, Audit Trails & Archives
Automated submittal schedules can keep track of what documentation has been submitted, when, and by whom. This type of tracking is beneficial during close-out to ensure that all required documentation has been properly reviewed. Tracking of submittals and RFIs can also be automated with filtering options and dashboards.
The right CA software can also keep a historical record project record for each action taken in the review process, including who initiated the submittal or RFI, dates sent to the design team and reviewers, and dates returned to the contractor team. The audit trail can be useful to trace events if a problem occurs. This valuable information can be used to determine proper remediation.
In addition to audit trails, the software archive captures the complete project record, which can be accessed years after the project has been completed. If litigation occurs after the project is completed, having access to the complete project record is critical.
Conclusion
Automated solutions for construction administration are designed to reduce the administrative burden, improve productivity, reduce errors, and proactively manage risk. Many AEC firms have recognized the benefits of implementing CA software solutions. Although these systems are effective, there is room for improvement. By planning, organizing, and communicating the people and process aspects of construction administration, project teams can realize the full value of the software.