The Promise of Project Files: A Case Study.

Information managers are familiar with project files as a subcategory of a type of office records usually called case files. While all case files are associated with specific persons, things, instances, or activities, project files document activities with discrete objectives, starting dates, and completion dates.(1) They are part of the relatively new, but widely adopted, discipline of project management.

Although engineers first popularized project management, information managers have enthusiastically adapted its principles for their own undertakings. One of the best descriptions of this adaptation is Alice Gannon's article "Project Management: An Approach to Accomplishing Things." (Records Management Quarterly, July 1994) Project management is a discipline that information managers can apply to their own projects, and it is a discipline in which information management must play a crucial role, no matter what type of project is involved.

Perspective: The Los Angeles Metro Rail Project

In 1980 the people of Los Angeles realized that extending the city's maze of freeways could not prevent total gridlock by the year 2000, so they voted a half-cent sales tax to finance a rail transit system and then sent politicians to Washington to lobby for additional federal dollars. There followed countless designs, environmental impact studies, public hearings, property condemnations, engineering designs, construction contracts, and -- of course -- lawsuits. By the end of the 1980s, the L.A. Metro Rail project had become the largest public works project in the United States.

The project began to falter after a large section of Hollywood began slowly sinking into the ground above the tunnel; the project's credibility with the media, politicians, and the public crumbled. By early 1998, the wells of local, state, and federal funds had run dry. The Metropolitan Transportation Authority voted to suspend the project. Faced with the challenge of mothballing all project-related documents, L.A. Metro Rail discovered that it had never really mastered the prerequisite job of establishing an effective project file.

The following are some "Monday morning quarterback" reflections on the importance of a secure, accessible project file, the obstacles to achieving it, and how to overcome them.

The Promise of the Project File

The project file promises several important benefits regardless of the project's nature. First, because a project creates or changes something, rather than just operating or maintaining it, the likelihood is much greater that disruptions and discontinuities will occur. Such occurrences always tend to upset someone. Consequently, most projects (and all of those in the state of California) incur lawsuits that require well-organized, accessible, and comprehensive project records. For example, on the L.A. Metro Rail Project, there were many document discovery demands specifying "all records pertaining to" the project in question. Others required a set of records that had never before been considered an identifiable group. The greatest cost in responding to such demands is not the expense of reproduction, but the labor of locating and assembling the requested records. In facilitating these document productions, a properly managed project file is invaluable.

Secondly, a properly administered project provides a clear financial accounting of all funds expended. For a project like the L.A. Metro Rail, which is funded by federal and state grants, the expenditure of these funds has to be explained in minute detail. However, any kind of project can expect to be audited. A well-maintained project file will reduce the work (and cost to the company) of the auditors who scrutinize each aspect of a project. It also streamlines the work of the staff who must locate and present the records demanded on short notice by auditors. To deal effectively with audits, a well-maintained project file is crucial.

Third, projects are rarely unique. They usually have antecedents, and -- if successful -- can expect to be imitated. In the case of L.A. Metro Rail, the same team of engineers, planners, and contractors had been drafted from similar rail projects in Atlanta, Miami, Houston, and Vancouver. Even in Los Angeles, the Metro Rail project was not so much a single project as a series of related projects constructing various segments of an integrated rail system. By preserving a record of the similarities among projects, a well-organized project file can help avoid reinventing the wheel and facilitate the integration of a series of related projects that begin at various times and locations.

A fourth value of a properly managed project file is the important information it provides to those who must use the product of the project once it is completed. For example, the contractors constructing the L.A. Metro Rail were not overly concerned with the operations and maintenance manuals that came with the communications, air-conditioning, traction-power, and signaling components. For the staff that must operate and maintain this equipment, these manuals -- not to mention a description of the equipment modifications not reflected in the manuals -- are a sine qua non. The project file bridges the gap separating the divergent perspectives of builders and users.

Finally, a well-designed project file is indispensable to public relations presentations prepared for public meetings, politicians, stockholders, and the press. Good publicity is vital to a project. The absence of information -- or worse, the collection and dissemination of conflicting information -- can kill it. A project team never knows what it will have to explain or which opportunity for good publicity will arise. Thus, the records detailing the project must remain continually organized and accessible. The assumption that it is sufficient to assign someone to assemble and organize the records that document a project once it is completed is not sound.

Fragmentation: The Project File's Nemesis

File fragmentation is the major problem confronting the maintenance of a healthy project file. The underlying problem is a failure to identify contents, ownership, and retention requirements, the same problems addressed by any records management program. However, the problem is more severe for project files.

Members of project teams are usually assembled from several different functional departments. Inevitably, there will be misunderstandings and procedural differences -- not to mention distrust -- among these groups. Consequently, they will maintain their own files of everything -- "just to be sure."

In the example of the L.A. Metro Rail project, the two agencies and four major construction management consultants involved in the project each established document control offices using computer-assisted indices and logs of all significant incoming and outgoing correspondence. Some of these systems were microfilm-based; some were merely indices of paper documents. In the beginning at least, each was incompatible with all of the others. Since most of the correspondence was written between these organizations, most items indexed in one were captured and indexed in at least two of the others. Moreover, there was no consistency among them with regard to data entry standards, index codes, or even whether to capture the entire document or only the transmittal.

To make matters worse, each different engineering department within each of these organizations kept its own files; the design, facilities, systems, construction, engineering, third party coordination, contracts, project accounting, labor compliance, and contract compliance departments each possessed sets of paper files that were largely identical. This duplication seemed merely silly until the citizens in Hollywood sued because the "City of the Stars" began to sink into the tunnel being dug. The documents demand from the plaintiffs' lawyers amounted to 1,200 cubic-foot storage boxes. Three-fourths of these were duplicates. Because they were retrieved from different offices, contained slight differences, and were stored in different ways, the judge ordered that all these documents had to be photocopied and made available to the opposing side.

The maintenance of multiple, uncoordinated filing systems leads to inordinate file maintenance and photocopy expenses. It also produces an unexpected problem: the loss of documents that are extremely valuable. How is it possible, if so many parties are maintaining so many copies, that an important document can be lost? Because everyone believes someone else was filing it. It must be made clear to every individual or office exactly who is responsible for preserving these documents.

The second reason for project record fragmentation is the dynamic nature of a project. Unlike the records of a functional department that remain the same year after year, project records are "owned" by one part of the team at one time and by another part at another time. In other words, because a project is dynamic, the identification of a document's "office of record" is continually changing. This situation, of course, seems to justify each office keeping its own set of files. It also means that, in the case of litigation or audit, it is unclear whom to ask for the information. Often, that entails asking everyone for copies.

In the L.A. Metro Rail project, the problem of ownership most severely manifested itself with regard to the engineering drawings maintained by configuration management consultants. Because these media (mylars and computer assisted drafting and design or CADD files) were so expensive, the problem of document ownership during several phases became critical. The agency constructing the system claimed that it should retain the record drawings and technical documents. After all, it had bought the rights-of-way, procured the funds, and constructed the line. Why should it give up ownership of the record drawings? The agency that was to operate the system effectively argued the absurdity of an arrangement in which the operator does not possess the official as-built drawings or operation and maintenance manuals. Shouldn't the operator be able to modify the original mylar drawings or CADD files in order to reflect post-construction changes? The fact hat this debate did not end until the two agencies eventually merged, provides a clue as to the need for a single, integrated plan for the project file.

The divergent organizational allegiances of team members and the dynamic nature of project management threaten the unity and integrity that a project file requires. To counteract this peril, the team must recognize that the project file has a unique identity, with its own life cycle delineated by a coherent progression, a unified set of standards, and a separate records retention schedule. Otherwise, the project is destined to expend resources maintaining duplicate and obsolete records, while finding itself unable to access other documents it really needs.

Building a Project File Program

The first step in developing a project file program is for someone to take responsibility for doing it. It will not necessarily be obvious who that will be. Chances are it will not be in anyone's job description. However, there will be no adequate project file unless someone or some group of team members with an information management background takes the initiative in developing an integrated, comprehensive project file program.

The second step: the records must be inventoried, appraised, and scheduled. These tasks are not too different from the standard steps that are already detailed in numerous information management textbooks. Yet there is one big difference: because the "office of record" for most project records will change as the project evolves, the concept of dynamic ownership must be understood by all members of the project. Otherwise, duplicate file maintenance and expectations that "someone else is keeping it" will abound.

Perhaps the program's most important requirement is: education. Everyone must understand the project record program's implications, agree to abide by them, and implement associated procedures.

To achieve this understanding, two steps are required beyond explanation. First, we must make sure that the entire team sufficiently absorbs the concept by showing how the principles apply to their shops and will make their lives easier. This requires visiting the departments involved and showing them how to apply the information management principles they have learned.

On-site training must be followed up with periodic procedural audits to make sure there is no backsliding. Is this a heavy investment in training and follow-up resources? Yes, but it will more than pay for itself by reducing the number of duplicate files stored and by accelerating access to documents required for operations, audits, public relations, and litigation.

One method for helping the procedures to become more palatable and improving upon all aspects of project-file maintenance is to add an imaging component. Electronic document imaging seems to have been invented for project files, for it solves many of their most vexing dilemmas. Imaging allows each team unit to scan and index the documents it creates or receives into a repository that it controls but that can be simultaneously accessed by all other team members for review or action. This arrangement eliminates the need for maintaining multiple files and searching in multiple locations. It will also greatly reduce the expense of copying, distributing, and filing multiple copies of the same records. Moreover, if the imaging system has an adequate workflow component, it will increase the speed with which documents can be circulated, revised, and approved. Most importantly, a system of this sort can provide a process break. When there is such a clear breach with traditional ways of doing things, it is much easier to convince everyone concerned to adopt a consistent project file modus operandi.

(1) The term "project file" is largely synonymous with the term "project record" as used in the engineering environment. However, "project record" is sometimes equated with "as built" engineering drawings and specifications, while "project file" in this discussion embodies all of the records associated with any sort of project, both within and outside the engineering area.

Robert Sanders, PhD, CRM, is the Manager of Records and Mail for the Los Angeles Metropolitan Transportation Authority. He was previously an Associate Professor of History, Director of Records and Registration, Registrar, and Archivist at Pepperdine University.