By Mark Ilich, Burcin Becerik, and Bert Aultman

Project collaboration is an industry buzzword that you may have read about in the Engineering News Record or seen marketed at one of the numerous Architecture Engineering and Construction (AEC) tradeshows in the past 5 to 6 years. Or perhaps your firm has made the leap of faith and has adopted one of these tools to keep your company ahead of the competition. Regardless of your company’s familiarity with project collaboration, there is a chance that you may not realize the extent to which these tools are underutilized in our industry. The purpose of this paper is to shed some light on why adoption has been slower than would seem reasonable and what should be done for successful collaboration through technology.

Introduction

Collaboration is defined as the agreement among specialists to focus their abilities in a particular process to achieve the longer objectives of the project as a whole, as defined by a client (Hobbs, 1996). Collaboration is needed to share visions among different stakeholders and to maximize team efforts on a particular job. Collaboration involves people working together by sharing (interacting, communicating, exchanging, coordinating, and approving) information and processes.

Managing construction projects using web-based techniques is gradually becoming a common practice as contractual, organizational, and informational integration is achieved. On typical large construction projects of geographically distributed teams, it is a daunting task to encourage collaboration between the hundreds of different individuals representing dozens of companies. The use of collaboration technologies represents a movement toward a virtual organization, where people are not tied to any particular workspace, thus allowing the flexibility to work from any physical location. Increased bandwidth capability, vastly expanded connectivity, and the integration of communications with computing technology together enable communication of richer and more complex information than was previously possible and contribute to a large variety of changes in organizational forms.

If effectively deployed, project collaboration dramatically increases the speed of communication, reduces the costs of communications, and provides productivity savings. The technology has the potential to offer a competitive corporate resource in this era of information management. It might become an integral part of corporate strategy of AEC businesses helping to reduce staff, connecting subsidiaries in different regions, facilitating new organizational structures, increasing the company’s bargaining power with customers and suppliers, and improving the internal and inter-organizational efficiency of the company.

In 1999, over 150 vendors were marketing project collaboration software and/or services to the AEC industry. During the past 7 years, we have seen rapid changes in the marketplace of vendors, and we are now left with a handful of competent companies who have gained from experience and learning our business. A current evaluation of these tools would prove that there is a good variety of vendors who are capable of addressing their customer’s needs. Such competition between vendors allows consumers to get the best product/service for the value.

Despite the proven advances in the technology itself, our industry has yet to fully embrace these tools. With each day, new teams are mobilized to begin projects with no coordinated plan to utilize project collaboration. While this fact is alarming to technology advocates, the struggle is to identify the obstacles that contribute to the underutilization of these tools. Sources for the slow adoption may include: inadequate implementation practices, lack of team-wide value proposition, potential impact on traditional work practices, risk and liability concerns, ownership and control of data, lack of education and training, and the culture of the industry (including both human and organizational factors).

Current State of the Technology

Ultimately the goal of project collaboration is to enhance communications between the architect-engineer, owner, consultants, and contractors in order to reduce the errors, omissions, and coordination problems in construction documents. Table 1 summarizes a recent Harvard Design School study of the benefits of these tools at the project and organizational level.

Table 1: Tangible, quasi-tangible, and intangible benefits at the project and organizational levels (Becerik and Pollalis, 2006)

Many integral events have influenced the utilization of project collaboration systems. By late 2001, only 40% of general contractors (GCs) had tried project collaboration software, compared to 89% in 2004 according to the Construction Financial Management Association’s Information Technology (IT) survey for the AEC industry in 2002 and 2004. Most of the technological barriers that once stifled the widespread adoption of these tools have fallen away in the last 10 years. Most large construction job sites, in all but the most remote locations, have access to high-speed Internet connections. High performance personal computers/laptops, scanners, plotting devices, and other electronic office equipment are affordable and widely available. Additionally, office staffs in general are more technologically savvy and better prepared to operate the hardware and software required in the web-based environment. Collaboration vendors better understand their clients’ needs and continuously develop the capabilities of their tools by offering a wider array of services.

The most commonly used modules of a project collaboration system are the document management and workflow processing applications, which include cost management, storage of drawings and specifications, submittals, transmittals, daily reports, document and drawing logs, meeting minutes, and RFIs. Most projects use the collaboration system to share cost information only in a limited way; usually, the cost-related information is for internal use. Most of the documents are created and transmitted electronically unless there is a strict requirement for legal documents requiring signatures and/or stamps (e.g., change orders, architect’s instructions, and shop drawings).

Through attrition and consolidation, the crop of project collaboration vendors has begun to distill into just a few market leaders. A recent example is the acquisition of Constructware by AutoDesk in February 2006. Many AEC organizations, especially large GCs, have begun to standardize on one of these collaboration systems. In a recent survey, it was found that 67% of project collaboration investors were owners, general contractors, or construction managers (Becerik and Pollalis, 2006).

GCs have made a considerable investment in vertically integrating the off-the-shelf project collaboration applications with other business software, especially internal accounting systems. Such integration provides a smooth transition of workflow from field trailers to backend office operations. Additionally, by consolidating projects into a single database, companies can easily roll-up information across their entire portfolio. This dashboard capability allows upper management greater visibility to a broad range of projects and allows program-wide reports and metrics, while providing capabilities to drill down to specific problem areas.

One of the fastest growing markets for project collaboration vendors has been with owners, especially large public and private developers. Developers, with their large catalog of buildings, often need to manage new construction and on-going repair and alteration work in existing buildings concurrently. Data ownership is a key issue for owners in the event of a dispute or litigation with a contractor. Document version control and the audit trail feature of these tools offer accountability and help minimize risks during and after construction. Many large public sector owners—such as public agencies, school boards, colleges, and urban municipalities—are driven by the additional security and document accountability offered by collaboration tools. Sophisticated owners not only mandate the use of this technology in contracts, but they also provide detailed guidelines on how and when the tool should be used.

Barriers to Collaboration

One acknowledged hurdle toward the adoption of project collaboration is the nature of the contracting vehicles used in the AEC industry. In an effort to protect themselves from claims and disputes, each stakeholder keeps its own documentation and paper trail as a matter of project record. Contracts form the basis for the relationships between project teams and thus contribute to the litigious nature of our industry. Instead of focusing on improved productivity and communications, teams must strive to minimize claims and to protect their own interests. Alternative contract delivery methods (design-build, CMc, etc.) help to reduce this adversarial relationship.

As collaboration tools become more commonplace in the industry, an interesting dilemma has arisen when multiple stakeholders advocate the use of their own tool. Since one of the primary goals of collaboration is to avoid duplication of effort, which tool should the entire team use? Owners have the ultimate decision in such situations, but often they do not get involved. So depending on the contractual relationships of the project, either the CM or GC dictates which tool is implemented. This can cause frustrations in the team, especially for A/E, consultants, and subcontractors as they are forced to use new tools as they join a project team. The result is information disparity, potentially long learning curves, and resistance to using these tools.

Regardless of the medium used to collaborate, a prerequisite for collaboration is to have a shared understanding and vision. AEC project collaborators are fundamentally from different backgrounds and professions with different objectives and values. They do not have a common educational and technology background. Project teams are temporary multi-organizational entities that come together for a short term. While they work for the common goals of a project, each organization has its own goals. Collaboration in the AEC industry tends to stretch out over a long period of time. Even if the original participants are no longer involved, their decisions still influence the project.

Despite the advances in project collaboration technology in recent years, there is still room for improvement. One frustrating limitation is that the tools do not communicate with each other. For example, the data input into a CM’s collaboration tool cannot be easily shared or populated into a GC’s system. This scenario is becoming more and more common as firms begin to standardize on a single collaboration platform. An even more annoying situation arises when both the CM and GC use the same vendor’s tool, but each with their own customized database. In this example, the technology does not facilitate data transfer between the two data sources. Thus either one party must adopt the tool owned by another stakeholder, or there will be duplication of data entry, neither of which is desired. Interoperability between systems is a factor that is becoming a higher priority, but it is still not on everyone’s radar.

Successful technology implementation requires establishing procedures for both electronic and manual processes. During the kickoff stage of many collaboration tools, basic project processes and/or workflows are documented and the tools are modified to mimic the desired procedures. Despite the flexibility of this customization, there are changes required in existing procedures to achieve the desired level of automation. It comes to a point when users understand that success is not so much about the technology itself but the process they choose to implement the tool, which usually requires cultural change. Users should be willing to review the procedures by which they do work and the computing tools currently available, and be willing to revise existing procedures when the tools offer clear advantages. Even for the most technology savvy people, it is a hassle to change the way the work is done or to change the tools they have been using for years.

Another perceived obstacle is the technical inability of subcontractors to utilize these advanced tools. In reality, many large mechanical and electrical subs are as equipped and IT savvy as some GCs. There are obvious exceptions to this theory when considering smaller trades that are only on the job for a limited duration. The training time and learning curve associated with such team members to get up-to-speed would make their participation not worth it.

The cost of collaboration tools varies greatly from vendor to vendor, primarily due to the different variations of pricing models used to sell their products and services. Additionally, customers typically have several options when choosing to purchase collaboration tools: (a) buy individual licenses plus associated maintenance fees, (b) purchase on a monthly or annual subscription basis, or (c) negotiate a fixed cost for unlimited number of users, space, and projects. Although purchasing a new collaboration tool has recently become affordable, there are always indirect costs that are overlooked. These indirect costs may include productivity losses during the rollout of the tool; initial and remedial training during major or new phases of the project; resistance of various team members to change; and redesign of organizational functions, processes, and reporting structures.

Inadequate planning and poor execution during the implementation stage is considered the chief cause for an unsuccessful adoption of project collaboration tools. Unfortunately, some vendors provide little or no support to end users during this critical stage. Or the customer is permitted to purchase a new tool without being fully aware of the indirect (hidden) cost of the technology. This creates enormous frustration and damages credibility, which in turn further slows the adoption of collaboration technology.

Future Challenges and Next Steps

One of the biggest gripes from collaboration non-believers is that these tools do not yet integrate with other business applications (financial, contracting, scheduling, facility management, etc.). The technology exists, such as Extensible Markup Language (XML), to solve this hurdle but it will take time and a desire from the industry to convince vendors to take action. Furthermore, interoperability between competitors and similar systems can be achieved but, again, needs more business pressure from the industry consumers before a solution will be presented and implemented.

Future collaboration solutions should be better equipped to handle the advent of 3D, 4D CAD, and building information modeling (BIM) technologies. These powerful design tools put greater emphasis on the document management and versioning than current technology supports. Additionally, collaboration tools need to incorporate more universal file viewers, so that all team members can view and interact with these advanced drawings and associated documents.

Increasing integration with operating systems and a variety of e-mail services would foster acceptance and give added ease of use. These tools should also be smarter with attributes and have extensive search capabilities. Wouldn’t it be powerful for a user to see both his local desktop and his online collaboration folders structure in Windows Explorer, to be able to search for a keyword across both platforms, and to drag and drop whole folder structures seamlessly between systems? Shouldn’t a user with the Lotus e-mail system be able to publish his calendar to the system, while someone using MS Outlook is able open his address book to see not only the local contacts but also those in the collaboration tool?

It’s an accepted fact that collaboration technology will continue to improve and be utilized by a widening audience of users throughout the AEC industry. Many of the larger companies have already begun using web-based tools with some success and are already influencing their further development. As companies adapt to the capabilities of these tools and begin to include them in their everyday operations, they will begin to see an even greater return on investment and increased productivity. Once teams have experienced a successful project utilizing collaboration systems, the use of such technology on the next job should be obvious and bring along new users in the process. Project collaboration software may not have reached its full potential, but it has come far enough that there is no reason that any team shouldn’t try it on their next project.

References

Becerik, B. and S.N. Pollalis (2006). Computer Aided Collaboration for Managing Construction. Cambridge, MA: Harvard Design School.

Hobbs, R.W. (1996). “Leadership Through Collaboration.” AIArchitect, Vol. 3, p. 11.

Authors’ Biographies

Mark Ilich is the Vice President of Procon Consulting. He has extensive experience in the implementation and integration of project and program management tools and technologies for various clients in the local and federal government sectors of the AEC industry. He is a member of ASCE in Northern Virginia and attended both undergraduate and graduate school at Virginia Polytechnic Institute and State University. E-mail: milich@proconconsulting.com

Burcin Becerik is a doctoral student at Harvard Design School. Her on-going research at Harvard examines the enhancement possibilities of implementation and operation of online collaboration and project management tools in the AEC industry. In addition, it explores the opportunities and tries to measure the benefits/values that the new technology can provide to project stakeholders and their collaborators. She graduated from Istanbul Technical University with a Bachelors degree in Architecture in 1999, and an MS in Architecture in 2001. In 2002, she attended UC at Berkeley where she received her MS degree in Civil and Environmental Engineering with a special concentration on Construction Engineering and Management. E-mail: bbecerik@gsd.harvard.edu

Bert Aultman is an associate with Procon Consulting. He currently provides technology support to the National Capital Region of the U.S. General Services Administration, specializing in the startup and implementation of project management and collaboration technologies. He graduated from the Georgia Institute of Technology in 2000 with a B.S. in Mechanical Engineering. E-mail: baultman@proconconsulting.com