As this week's article on the CERL's DrChecks shows, the technology is available and proven whereby construction project team members can share huge amounts of electronic information securely, share comments instantly, and store a wealth of project information for later analysis and use. The Technology in Architectural Practice PIA gives insight into how to use this power wisely.

Balance the Risks and Risk Mitigators

Collaborative information-transfer technologies require a balanced approach. When project team members share project drawings, specifications, clarifications, field observations, and other sensitive and critical project information over the Internet—even when it's secure from outside prying eyes—there are new risks that must be managed. At the same time, these very technologies can be applied to mitigate risk.
Here are some examples.

Risks
• Posting project notices to an email box of an individual no longer engaged on a project, while simultaneously failing to notify that person's replacement
• Working from project data (drawings and specs) believed to be current because that's how they are presented on the project Web site while, in fact, the most current version is being worked on by others
• Relying on a contractor-paid project Web site throughout a project, only to discover on closeout that the contractor now owns the only record of many important project messages and documents
• Attempting to access one's project data on Monday, only to discover that the service provider had gone out of business over the weekend—with no notice, no backup, and no recourse

Mitigators
• Distributed data, intelligence, and security, whether peer-to-peer or Web-server-based and synchonized/replicated, supports close communication among team members, which helps enormously to reduce the likelihood of errors and omissions.
• Collaborative technology, by being widely distributed and redundant, can be more resilient in the face of a disaster or business interruption. For example, firms whose offices were destroyed on 9/11 and needed to restore their files since their most recent surviving backup had to rely on clients and consultants to return copies of documents, email, and other correspondence. A properly secured, off-site project collaboration system would have put these folks back in business faster—almost instantaneously.
• Having quick client-response time, close communications, and data recovery capability makes you more competitive.
• Anticipated and steady increases in bandwidth and storage capacities (and corresponding decreases in cost) combined with steady advances in system/message security, server-side security, and client-side security will make future collaborative technologies more forgiving of business interruptions than either present nondigital systems or stand-alone digital.

This is only a quick overview to give the reader an appreciation of the scope of the issue. To take advantage of this capability, we need to assess collaborative strategies in light of their potential redundancies and corresponding system resiliency. To learn how to strike the proper balance for your firm, you will just have to come to D.C. April 5–6 to the Six Degrees of Collaboration conference.

Jerry Laiserin, FAIA
The Laiserin Group, Woodbury, N.Y.

Collaborative Systems Don't Manage Themselves

Webcor Technologies served as a consultant to our parent company, Webcor Builders, and their client, the Palm Corporation, on a recent project that taught me, as director of AEC Information Services, some valuable lessons.

I would say that the key success factor is management of the collaboration system. There always seems to be some point at which people think they can "set it and forget it." I've never seen that work. Someone—one of the players involved in the project or a separate systems manager—has to have the responsibility for managing the collaboration system to make sure it's working and people are using it. System management is pretty much a full-time job.

This next point is not news, but bears repeating. If something is involved in a project, then eventually, one way or the other, the client is going to pay for it. So feasibility of using a collaboration system will boil down to whether the client feels that it's worth it.

Palm's managers were definitely behind using the Buzzsaw system we selected for their project. Nevertheless, another truism made itself apparent. Even with strong backing from management, there is still some cat herding involved with a few people who don't want to get into the right spots. I can point to three ways to overcome that natural group dynamic.
• You have to really, really put in the effort to make using the system the path of least resistance. You can have the stick—the owner saying "Thou shalt do this"—and yet some people are going to find ways to go around it. So you really have to offer the carrot of making it easier.
• Align the system with the workflow processes that are already ongoing, such as RFIs, meeting minutes, and those sorts of things. Construction projects have a number of pretty ironclad workflow processes. Even though they may vary from project to project, in a given project they are fairly definable.
• Focus your training. Rather than have people sit for an entire day learning a lot of stuff that they didn't need to know, we carefully looked at the training and at what the people needed to know. It is only respectful of people's time to teach them what they need to know, and only what they need to know, and let them get back to work.

Jim Bedrick, AIA
Webcor Technologies, Hayward, Calif.

Copyright 2002 The American Institute of Architects. All rights reserved.