IN FEDERAL AGENCIES TODAY

J. Timothy Sprehe

Introduction

Over the past several years, SRA International has served as a contractor to several federal agencies in various aspects of records management. Among other projects, in 2000-2001, SRA carried out a government-wide survey for the National Archives and Records Administration (NARA) which was published as Report on Current Recordkeeping Practices within the Federal Government. In 1997-1998 SRA conducted a business process re-engineering for the Environmental Protection Agency (EPA) with respect to its regulatory docket filing facilities; SRA performed similar services for the Department of Transportation. In 2001-2002, SRA is assisting EPA in developing an agency-wide electronic document management (EDM) and electronic records management (ERM) system.

These activities have involved not only systems integration functions but also conducting interviews, debriefings, focus groups, and paper-and-pencil questionnaires with hundreds of federal employees, as well as private sector companies. For the NARA and EPA work, SRA has gathered the perceptions of federal Chief Information Officers, General Counsels, Inspectors General, information technology staff, records managers, and staff carrying out the day-to-day duties of conducting federal programs. The company has also interacted extensively with firms marketing software systems to federal agencies and firms engaged in systems integration and implementation.

This article is a distillation of the foregoing experience and reflects the educated opinions of the authors and many SRA experts. The article attempts to delineate the frontiers of ERM in the federal government at the present time.

1. Challenge of E-Mail Records Management. The biggest single worry federal agencies have in the records management field today is how to capture e-mail records. The agencies recognize that e-mail constitutes their greatest source of liability in the event of litigation, FOIA requests, congressional investigation, or media exposure. Policy in most agencies stipulates that, when an e-mail qualifies as a record, it should be printed out and saved in paper format. Most agency staff will say they doubt the policy is widely known or being carried out at all and they have no enforcement mechanisms. Compliance is up to each individual at his or her desktop.

Moreover, the volume of e-mail for business transactions has grown to the point that a print-to-paper policy is impracticable. Department of Energy (DOE) records management personnel say the department is processing one million e-mail messages per business day. The logistics of deciding daily whether each of these messages is a record and whether it should be printed out and filed surpass DOE’s administrative capabilities. At DOE and other agencies, the primary focus of pilot projects in ERM is e-mail; other records can come later. Add to this the fact that, at many agencies, systems administrators adopt the practice of deleting all e-mails from users’ in-boxes after the messages reach a certain volume or date limit. If users are not transferring record materials out of their in-boxes to a records management system or other storage, the records are simply lost.

Many components in the Department of Defense (DoD) have decided to cope with this problem by saving all emails and software vendors have responded with products to assist them. OTG Software, Inc., for example, offers EMAILxtender that performs e-mail "archiving," meaning the product burns all e-mails onto optical disks. This is not records management but a kind of minimal safeguard measure, mixing record and nonrecord material together on a storage medium. These DoD components are not, in fact, managing the e-mails as records; they are simply putting them in storage and deferring the management to some later date.

2. Not an Integral Component of Information Technology Planning, Systems Design, and Architecture. A key problem with ERM in federal agencies is that records management in general, let alone ERM, has not been an integral component of information technology (IT) planning and systems design. When IT managers sit down to figure out what kinds of systems they will need to manage agency information resources, they do not take records into account. They are not habituated to think that the eventual automated retirement and disposition of data in IT systems is an IT planning and design function, as well as an integral part of program planning and design. Neither IT nor program personnel understand the business and legal imperative of separating federal record information from nonrecord information, the importance of disposing of record materials in a prescribed manner and of destroying nonrecord materials. Saving information the enterprise should have destroyed can be just as harmful as destroying information that should have been saved

Part of the problem is traceable to basic terminological misunderstandings; the words "record" and "archive" mean very different things in the IT environment and in the federal records environment. Part of the problem is that the records management function has for too long been either omitted from federal information resources management or treated as an inconvenient afterthought; it has been seen as a "back room" administrative function rather than an IT systems and basic program function. Neither IT nor program planners have absorbed the basic business case for records management, namely, that no enterprise can conduct business without ready access to its important records. And today those records are born and live in electronic media.

For example, if one were to examine agency plans for implementation of the Government Paperwork Elimination Act (GPEA) in October 2003, one would find insufficient or no planning for ERM. Agencies are making plans to put electronic forms on their websites and to receive information electronically from the public (e.g., applications for benefits). In some cases, agencies either have or are planning for the internal IT systems that will process electronic submissions inside the agency. And in other cases, agencies will print to paper and process the information manually as they always have, a situation that undermines the very purpose of GPEA. Few agencies are planning for the fact that the information may qualify as federal records -- certainly true of applications for benefits -- which must be captured in and retrievable from agency electronic recordkeeping systems. Benefits applications, for example, can become part of applicant case files enduring over many years, files that may have to be recalled from time to time and added to. As benefits are paid or denied, the same files may entail legal, financial, and accounting ramifications beyond the immediate program-related activity of granting or withholding a benefit at the present moment.

Designing-in Metrics. Some of the experienced agency ERM users SRA interviewed in the EPA project stressed the importance of metrics, of measuring any aspect of an ERM system that is quantifiable. One aspect that bears close monitoring is the effects of the ERM system on overall IT system capacity. Some agencies automatically delete all emails after a set number of days for IT capacity reasons, irrespective of whether they contain potentially vital, uncaptured record materials. Quality assurance aspects of ERM may also be quantifiable. ERM commercial-off-the-shelf (COTS) systems are designed so that the user can designate materials as record or nonrecord. If the system metrics show that certain users are filing far fewer records than fellow users doing the same kind of work, it is reasonable to suspect that low-filer users are circumventing the ERM system, probably considering it a nuisance. If the metrics are designed into the system as implemented, management can identify low-filers, see that they receive additional training, and/or make a minimum filing level an employee performance criterion.

3. Challenge of Updating Conventional Records Management. Agencies intending to acquire and deploy ERM systems often discover that they have neglected their basic records management programs, especially electronic records, for a period of years. Laws have changed, new programs have started up, and old ones may have ended, meaning new series of records appeared and old records require disposition.

The first thing any ERM system will require upon installation is input from the conventional records management program. Among other things the input will consist of:

Records inventory. The inventory is a descriptive listing of each record series or system (not each and every record), together with an indication of location and other pertinent data.

Records schedules. Scheduling is the process of developing a document that provides mandatory instructions for what to do with records (and nonrecord materials) no longer needed for current agency business. These are documents, approved by NARA (via Standard Form115), that for each set of records tells whether the records are temporary or permanent, how long they will be kept in temporary storage, and when and how they will be disposed of -- destroyed if temporary; transferred to NARA ownership and custody if permanent.

File Plan. A file plan is a set of categories (virtual cabinets, file drawers, folders, etc.) for the agency recordkeeping system. Each category in the file plan has associated with it a records schedule.

According to SRA’s information collection study for NARA, agencies soon learn that many, if not most, electronic records have not been inventoried or scheduled and that their file plan is out of date.

When inventories, schedules, and file plans are outdated or missing altogether, the agency must undertake the labor-intensive, time consuming, and expensive exercise of bringing them up to date. Like any other system, an ERM system cannot overcome faulty or incomplete input data. The point is that no agency can do ERM until it has brought its conventional records management programs up to date.

4. Challenge of Integrating ERM with Other IT Systems. Agencies face the problem – and potentially substantial up-front costs – of integrating ERM systems with their other legacy or future systems. This challenge takes several forms.

Integration with Information Management Systems. Where do electronic records originate? They come from word processing, spreadsheet, database, e-mail, and website applications. Agencies that have, or are planning to acquire, ERM systems must integrate ERM with these functions. EPA, for example, specified to SRA that any ERM system must integrate with Lotus Notes e-mail because Lotus Notes is EPA’s agency-wide e-mail system.

Integration with Knowledge Management (KM) and Electronic Document Management (EDM) Systems. A particularly widespread and urgent need is to integrate ERM systems with KM and EDM systems. EPA required SRA to develop functional requirements for an integrated EDM/ERM system. The Department of Education is now doing a requirements analysis for an integrated KM/EDM/ERM system; Department of Treasury is planning a department-wide integrated EDM/ERM system. In its work for EPA, SRA produced a set of functional requirements for EDM/ERM systems.

Integration with Other Enterprise Systems. DOE headquarters installed Tivoli and decreed that all new applications had to run in a Tivoli environment. When DOE wanted to pilot TrueArc’s ForeMost ERM system, DOE, TrueArc, and Tivoli had to spend six months writing an interface. Similar tales will doubtless occur in many other agencies. Doubtless the intranet aspects of Navy/Marine Corps Intranet (NMCI) will impose integration requirements on all KM/EDM/ERM systems acquired.

5. Challenge of Pilots and Phased Implementation. ERM is sufficiently complicated to introduce that agencies are finding they must first pilot an ERM system to learn how its introduction will affect work processes and workflow and how the system will work in their environment. In the same vein, phased implementation of an ERM system must be part of the agency’s planning. Simultaneous, agency-wide implementation will lead to chaos. It is much better to implement office-by-office within an agency, remembering that workflows and work processes vary from one office to the next.

SRA produced a Lessons Learned paper for EPA, which indicated that pilot projects must be kept simple if the agency is to learn anything from them. Agencies initially want to test more variables than a pilot project can handle well; if they do so, they end up learning next to nothing. The tendency to overload a pilot with too many twists and wrinkles should be resisted.

6. Challenge of End-User Training. ERM vendors sell training separately from their systems and they sell it expensively. At present, for ERM to work the end user sitting at a desk top must decide that something is a record and know which file category to put it into. This takes two kinds of training for end users: (1) training in basic records management (know what a record/nonrecord is and what to do with a record) and (2) training in how to operate the ERM application. In the EPA Lessons Learned document, SRA found that agencies are coping with this problem with a combination of approaches:

Train the Trainer. Agencies send a few of their employees to the expensive vendor training so that these employees can become internal trainers for end users. Then, as each office goes through phased implementation, the internal trainers conduct mandatory classes for the office employees.

Computer-Based Training. Agencies are also investing in computer-based training for end-users. The few agencies thus far interviewed say that the tools they are contracting for are not generalizable or usable by other offices or agencies because they are tailoring the computer-based training to their own workflow and work processes. The preferred sequence of events is that an end user will first complete the training class. Then, the next time the user sits down at his or her computer, the computer-based training will appear and step the user again through the basic records management concepts, how to use the ERM application, and how it particularly applies within his or her office.

Refresher Training. The pioneer agencies in this field are also recognizing that records management training is a continuing function. Not only will new IT systems features necessitate ongoing training, but end users need reminding and updating on both the records management and applications skills. Some of this can be done with computer-based training; other parts with small training classes.

These agencies are also recognizing that all new employees will require basic records management training. Eventually, this must mean that every entering employee, as a component of basic agency orientation, goes through records management training. At one intelligence agency, staff say that new employees do not receive a computer account and password until they have completed this training.

Agencies have not yet extended this thinking to recognition that all political appointees (agency heads, assistant secretaries, etc.) also need employment entrance briefings and exit debriefings on records management because of the importance of their records. A very few agencies have succeeded in making appointee debriefings mandatory, trying to overcome the temptation of many appointees to take their records with them when they leave.

7. Challenge of Business Process Reengineering. The introduction of ERM systems, especially inasmuch as the systems involve all end-users, will require substantial business process reengineering (BPR) across the board in agencies. ERM systems have some effect on everyone’s work processes within a work unit, and if the processes are not re-designed to accommodate systems introduction, the systems will not work in practice.

Some believe pilot projects must come before BPR; others say you cannot design a good BPR until you first do some piloting. The latter proponents argue that you do not understand how the ERM system is going to affect the work processes and just how they will have to be reengineered until you have tried to pilot the system. Whatever the answer – perhaps an iterative process -- the point is that BPR must be closely tied to pilots and phased implementation. Planners should recognize that the BPR itself will change as experience is gained in pilots and phased implementation. They should also understand that ERM systems are not ready to go live until conclusion of BPR.

8. Challenge of Website Records Management. Agencies are recognizing that their websites have increasingly become their primary "public face." This recognition will become even more pronounced once GPEA implementation starts in 2003 and as the e-government initiatives penetrate all agencies. If discontinued postings to agency websites simply disappear (i.e., no record remains) when taken off the sites, the agencies could be exposed to substantial liability. GPEA and e-government will make websites even more important as the critical interface between the agencies and all external clients and constituencies. Many agencies are investing in website management applications without considering the records management aspects of their sites. Some vendors are now marketing products to capture website content. Tower Technology, Inc., for example, markets a product called WebCapture that essentially "archives" a website by burning it onto CDs. Again, this is not records management; it is simply storage with some search-ability, a device to defer formal records management to some unspecified future date.

NARA has been rumored for more than a year to be on the verge of issuing guidance on website records management. Thus far the guidance has not appeared, even in draft. The only guidance available on the subject remains the study that Charles McClure and J. Timothy Sprehe did for NARA’s National Historical Publications and Records Commission in 1998, Guidelines for Electronic Records Management on State and Federal Agency Websites. McClure-Sprehe recommended that, at a minimum, agencies keep a log or register of the materials posted on their websites, that the register be treated as a record, and that the register be posted to the agency intranet and possibly to the public website.

Several developments call for website records management.

Agency personnel are authoring materials direct to the website. That is, the website copy is the original and the materials are not capture elsewhere as records.

Agencies use their websites for real-time interactive events – webcasts, webinars, etc. – that are captured nowhere except on the Web. The McClure-Sprehe study found an instance where a state real estate commission held an official meeting via Web simulcast and no record was kept of the webcast, even though testimony was heard, official votes taken, and state financial resources committed.

Agencies do make mistakes, sometimes mistakes with serious consequences. If they are not keeping a register record of what materials go up on their websites, when they are posted and taken down, who authored the original materials, what versions have been superseded, and similar measures, they have no means of answering future accountability questions about past website contents.

9. Challenge of Auto-Categorization. In a better world, ERM would not need to involve the desktop end-user. Upon receipt of an information object, a software application would read the information and decide (a) is this a record? and (b) if yes, where does it belong in the agency file plan? Such an "auto-categorization" application, if effective and under the control of trained records managers, would eliminate end-user involvement, thereby eliminating a major cost and a major source of error in the records management program.

A truly effective software solution to the categorization problem would also be most desirable from a legal standpoint. In the litigation surrounding the Iran-Contra scandal – the lawsuits that galvanized ERM systems development in the early 1990s – the White House argued that, if an electronic message in their PROFS system "rose to the level of a record," staff were instructed to print out the message and save it as a paper record. The court held that the White House practice was deficient, among others reasons, because a trained records manager should make the decision whether something is a record, not the rank-and-file end user.

Effective auto-categorization tools could also substantially reduce, if not eliminate, training costs associated with ERM systems. These costs now loom as potential major drains on agency IT budgets. Numerous firms now market auto-categorization tools (Autonomy, Inxight, Semio, and others) based on Natural Language Processing or Neural Net technology.

At present, the consensus in the industry is that auto-categorization technology has not yet proven itself but that the need for the technology is so great that we will soon have reliable auto-categorization. Many would say we must have auto-categorization tools if ERM is to become truly feasible and cost effective in the contemporary business and governmental enterprise.

Conclusion

Underlying the challenges presented in this paper is a growing awareness that federal information management and IT management are beginning to come together as perhaps never before. Because today’s information in today’s enterprise is born, lives, and dies electronically, the challenges facing federal KM, EDM and ERM illustrate two general propositions.

It is no longer possible to plan and manage the life cycle of information without taking into account the life cycle of the IT system in which the information resides.

It is no longer possible to plan and manage the life cycle of an IT system without taking into account the life cycle of the information residing in the system.

The emergence of records management as an integral element in federal information resources management signals the mutual interdependence of information management and information technology management in the contemporary government and business enterprise.

Giovanna Patterson is Chief Technology Officer, Civil Government Systems, SRA International, 2000 15^th Street North, Arlington, VA 22201. E-Mail: giovanna_patterson@sra.com. Ms. Patterson’s seventeen years of experience in the computer science field include program management, systems engineering and software development, and computer security engineering. She has held progressively more extensive managerial, technical, and project responsibilities in large-scale information management systems during her career. In addition to her current position with SRA, she worked for TRW’s Systems Integration Group, and First Information Systems Group. Ms. Patterson holds a B.S. from Virginia Polytechnic Institute and an M.S. in computer science from George Washington University.