 |
(Reprinted
from the December 2001 issue of the Associated General Contractors
of California's Legal Briefs.)
By Paul W. Berning and John W. Ralls
They
are described in a variety of ways - project specific Web
sites, collaborative Web sites, project management Web sites
- and they have been heavily advertised in construction
industry publications. Some are well known, including Buzzsaw,
Citadon and Meridian. A number have failed and have gone
out of business. Although they have not yet become widely
accepted by the industry, their use is being required on
some projects, and many would-be participants are faced
with the choice of using them or taking a pass on a potential
new job.
Before
using such Web sites, project participants need to evaluate
whether the sites will make their project better. If that
seems likely, the Web sites raise a number of practical
and legal issues that should be resolved before the site
is used. This article includes checklists to help contractors
evaluate when to use Web sites for projects and what agreements
on use need to be reached with other project participants.
What the Web Sites Do and Don't Do
The
collaborative Web sites promise to:
-
Keep a complete set of project correspondence in one place
for all on the project to see.
-
Keep a complete and current set of plans and specifications
in one place for all to see.
-
Keep complete sets of schedules and RFIs in one place
for all to see.
-
Alert project participants to changes in plans, specifications
and schedules.
-
Speed and ease communication by use of e-mail.
-
Enable project participants to interactively review, discuss,
mark up, and ask and answer questions about plans and
specifications.
-
Provide ticklers to project participants and track the
status of tasks.
-
Encourage accountability by providing a complete documentary
record.
-
Reduce the cost and effort needed to keep complete project
files and archives.
-
Improve communication by making it faster and easier.
The
collaborative Web sites can be used at a number of points
during a project:
-
By the owner and design professionals during design.
-
By design professionals and equipment vendors during design.
-
By the contractor, subcontractors, design professionals
and owner during construction.
It
also is important to understand what the sites do not do:
-
They do not replace scheduling software.
-
They do not replace estimating software.
-
They do not replace computer-assisted design software.
- They
do not replace cost accounting systems.
-
They do not replace accounts payable and accounts receivable
systems.
Providers
of the Web sites also are likely to insist on license and
use agreements that shield them from all or nearly all liability
for system failures. If the Web sites crash, become unavailable
or do not work right, project participants are likely to
bear the risk and cost of the resulting delays, disruptions
and extra costs, not Web site providers and vendors.
Proponents
of collaborative Web sites often talk of making them accessible
in the field by use of PDAs (personal digital assistants
such as Palm Pilots). However, it is an open question whether
PDAs, with their small screens, would be much help, particularly
in examining drawings and other large documents.
Tools to Evaluate the Web Sites
A
good starting point for evaluating such Web sites is to
ask: What do they do for this project that conventional
telephones, cell phones, faxes, e-mail, photocopies and
existing software cannot do? A short list of benefits could
indicate that the project is not a good candidate for a
Web site.
Other
factors to consider include:
-
The importance of good communication to successful projects.
- The
need to document numerous project issues because the documentation
involves money, risk and liability exposure.
-
How easy it is to become buried in paper on a large or
complex project.
-
The possibility that the project owner will insist that
a collaborative Web site be used.
Only Agreements Preserve Rights
Once
a decision is made to use a collaborative Web site, users
need to understand that almost no laws or rules govern operation
of such Web sites. Rather, the terms of use are subject
to negotiation by project participants. If no agreements
are reached, project participants are likely to find that
they have few or no rights to a system that sits at the
heart of their project. Or, they will be reduced to seeking
project records through discovery in a lawsuit if legal
disputes arise about the project. Having an agreed right
of access to key project documents is far superior to discovery
as a basis for access.
The
collaborative Web sites can be structured to address virtually
all issues of access, use and storage. However, to obtain
maximum benefit, participants must identify the issues that
concern them, reach agreement on procedures that address
their concerns, document agreements and then train all participants
to use the Web site as agreed.
Checklist of Issues to Consider and Resolve
Who
owns the site, the software and the data: A number of
issues center on who has the right to look at data placed
on the system. As a practical matter, in the absence of
agreement, such issues will turn on who purchased the system.
For instance, if the owner purchased the system and has
a continuing relationship with the software vendor for technical
support, then the owner will have the ability to access
the entire system simply by calling the vendor and requesting
access. At the outset, the following questions should be
asked:
-
Who purchased the Web site for the project?
-
With whom does the Web site provider have a contractual
relationship?
Access
and permission levels during the job: With most systems,
"permission levels" are established for data placed
onto the system, which is said to permit users of the system
to restrict access as needed. At the same time, most systems
specify that particular individuals (often called "site
administrators") have the right to change security
levels and access particular files or portions of the site.
The administrator typically is an employee of the owner
or design firm. Therefore, it is important to understand
who controls the site during the job. Without adequate answers
to these questions, contractors are well-advised only to
put information on the system they agree that others (including
the owner) may see.
-
Who can access what information on the site?
-
How can your organization designate materials as confidential?
-
Who has the ability to change permission levels?
-
What assurances does your organization have that the permission
levels will not be changed without your consent?
Buy-in:
A frequent criticism of Web collaboration systems is
that where some but not all of the project participants
agree to use the system, use becomes a waste of time (such
as communications have to be made both "within"
the system to some and by other means "outside"
the system to others).
-
Among the project participants, who has committed to using
the system?
-
Do the participants who say they will use the system have
the resources (computer equipment, Web access, staffing
and training) to use the system?
-
Will your subcontractors and suppliers use the system?
-
If they don't, what extra administrative work will you
have?
Job
site issues: The limitations of the job site should
not be ignored. What works well in a design professional's
office, where T-1 access is routine, may not work in a job
site trailer, where dial up modems are more common. Also,
faxes continue to be widely used, especially to and from
the field.
-
How reliable and fast are the connections going to be?
Will T-1, DSL or cable access be available in the field?
-
To the extent that faxes remain a common and handy method
of communication, how does the system deal with that?
Forms:
Most Web based project management systems have their own
set of forms for routine construction administration items
(RFIs, etc.). While these forms may work well for short
routine communications (such as a very simple RFI), they
may not work well for more complicated communications (such
as when an RFI raises what turns out to be a complicated
issue addressed over months). Also, the forms may conflict
with those that have served your organization well for years.
-
What construction administrations forms will be used "within the system" (such as RFIs, meeting agendas and minutes, summaries of teleconferences, etc.).
-
Do you have to use these forms, as opposed to the forms that have served you well in the past?
-
Are there limitations on the forms (such as a limited number of characters)?
Access
to data after the job: At the end of the job, all of
the files placed on the system (e-mails, meeting minutes,
records of telephone conversations, correspondence, etc.)
typically are archived and placed on CD-ROM, DVD disc or
other electronic media. Typically, this information is kept
by the party that purchased the system.
-
Who controls the site and has access to the archive after
the job?
-
After the job, can the contractors and subs have a copy
of their parts of the Web site for their archives?
-
How, if at all, are the "permission levels"
established during the job maintained after the job is
over?
Future
access: The need for access to the information may not
arise for several years. For instance, a lawsuit for latent
construction defects can be filed as many as 10 years after
the project is completed.
-
What guarantees do you have that your organization will
be able to access the data in the future? Will the hardware
and software needed to access the data in 10 years still
be available?
-
What system can your company put into place to ensure
access to this data?
Risk
of system crashes: If Web collaboration systems deliver
even part of what they promise, they will be a very important
part of the project, which raises questions concerning what
happens to the job when the system crashes.
-
If all embrace the system, how can you work if there is
a crash?
-
Who is at risk for the delay/impact from a system crash?
Security
of the data: The data placed on the system also needs
to be secure from hackers and the elements.
-
Is the server in a safe location in terms of dust, dirt,
heat, cold, wet?
-
Will the system be Web-based or operated on a private
network or extranet? If Web-based, the system is likely
to be safer from dust, dirt, heat, cold and wet but will
require T-1 or other fast means of transmitting data and
must be safe from hackers. If operated on a private network,
access will be fast if the server is kept on-site and
safer from hackers, but the server will be at risk from
dust, dirt, heat, cold and wet.
-
What precautions are taken to back-up the data?
-
Are the firewalls reliable?
Training:
Working on a project that employs one of these systems will
mean routine tasks have to be done in a new and different
way. Training will be essential.
-
What training do employees in your organization need to
use the system effectively?
-
What resources are available to train employees in your
organization?
-
How can you make sure that your employees are trained
to keep confidential information off the site?
Multiple
systems: If owners or design professionals choose which
system to use, employees of contractors may find themselves
using one system on one project and another system on the
next project.
-
Will this reduce productivity or increase employee frustration?
-
Will it increase training costs?
Cost:
Finally, as a practical matter, the cost of using the
system needs to be understood.
-
How will your company be charged? By number of users?
By the amount of data archived on the system? Some other
way?
-
What indirect costs will you incur? Training? New computers?
New printers/plotters? Web access?
More Information
For
a comprehensive listing of e-commerce sites for the construction
industry and links to those sites, click
here. For more reading on these issues, click
here.
If you would like to receive legal reports and updates
more quickly, by e-mail, click here and fill out the mailing list form. If you would like to subscribe to our RSS feeds or learn more about RSS, click here.
©2002 ConstructionWebLinks, Inc.
|
