AERM Workshop

Editor's Notes

• #2: \n
• #3: \n
• #4: When developing requirements and an overall records management program, it is necessary for an effective records manager to have the understanding of all of the functions and process within an agency. This is necessary for learning where records are created, how they are maintained, and how long they are needed.\n\nWhile we know that the RM must have this knowledge, barriers often exist between the RM and IT worlds that make it difficult to get this vital knowledge.\n
• #5: To overcome the barriers to managing information assets, agencies and programs must address the realities of the relationship (or the lack thereof) between IT and RM worlds and cultures.\n\nThe critical problem is that agencies and program are generally not managing the records from the moment they are created and in accordance with appropriate policies and procedures.\n
• #6: RM and IT are often not integrated in agencies as cornerstones of an integrated information management strategy. There is often a lack of understanding of the importance of each discipline to the other’s successful operations, particularly as agencies rely more on electronic records and the applications and systems that produce them to conduct agency business.\n\nAs IT has moved beyond data management to document management (and in some cases, has moved on to enterprise content, or knowledge, management), there is now a convergence of responsibilities between RM and IT that has not been recognized by senior agency managers. Agencies must realize that capturing the institutional knowledge of an agency demands a multidisciplinary approach integrating RM, IT, and the users who create the records.\n\nImportant to have a team approach.\n
• #7: Problems for Records Managers generally involve the fact that modern records management has become a responsibility distributed across the agency. Records Managers must expand their understanding of the current business environment beyond their experiences with paper records (which involved situations in which RM and IT integration was not critical), and focus more on the best ways to manage content in all formats (e.g., using new technologies, processes, and procedures).\n\nAlso, RM staffs generally do not have the necessary technical training and experience to talk with IT staff about their operations, and as a result, are often unable to translate records and information requirements into specific system requirements that IT can implement.\n\nRecords management responsibilities have become distributed across the agency, largely due to the rise of IT networks—every user has a “delete” key. \n
• #8: On the other hand, IT is often focused on building and deploying systems, not on managing the information within those systems as business assets that need to be maintained for as long as needed. This means that records management controls are not built into electronic systems, web sites, e-mail and office automation applications, and all other tools developed or maintained by IT. In cases in which IT is the only one involved, only the tools—not the content—are being managed.\n\nWhen RM and IT aren’t integrated, the authenticity, reliability, and integrity of records and information may be undermined, and the agency may not be able to defend its records and its RM processes when necessary. Two obvious problems arise if agencies are involved in litigation, or must produce records pursuant to Freedom of Information Act (FOIA) requests. \n
• #9: To build institutional knowledge, agencies need to integrate RM and IT to ensure that electronic records and information can be located, shared, and accessed agency-wide whenever needed. Agencies must recognize that the records and information, as well as the tools, must be managed with the RM and IT programs working together. \n\nAs noted earlier, there needs to be more collaboration between RM and IT, since the responsibilities for managing agency information assets are now shared. RM staff should be included with the IT staff during agency capital planning processes for new and enhanced electronic systems.\n
• #10: RM staff must understand how technologies affect electronic records, such as hardware- and software-dependent records.\n\nRM staff must also know that they are key players in teaching IT the value and usefulness of information. \n\nUltimately, IT and RM staffs need to understand that records management requires a level of technology comprehension beyond mere document tracking, a level which requires the expertise of both staffs.\n
• #11: It is important that all records management staff possess the same set of skills, including process mapping, analytical thinking, the ability to speak IT’s language, leading meetings and facilitating discussions, managing projects, and familiarity with the Systems Development Life Cycle (SDLC). \n\nMost important, RM staff should possess strong writing and oral communication skills, especially the ability to explain records management concepts without jargon, in a way that ties records to the business process they document. Analysis of business processes will document transactions where records can be identified and requirements can be defined.\n\nIt is essential to be familiar with terms as they are understood by IT staff, and to be able to clearly communicate terms as they are understood by RM staff.\n
• #12: Records management and IT professionals use many of the same words, but they do not always have the same meaning.This is a case of everyone speaking English, but not all using the same dictionary.\n\nFor example, the word archive:\n\n–IT—A collection of computer files that has been moved from central magnetic disk storage to another location (either for backup purposes or for storage on less expensive storage media), from which it can be recalled to online status if needed.\n\n–RM—A collection of noncurrent organizational records retained permanently. In the case of Federal records, they are removed permanently from an agency and transported physically (in an acceptable format) to NARA. At that point, NARA assumes legal responsibility for the preservation of the records because of their continuing or enduring value.\n
• #13: Record:\nIT—A collection of data items (sometimes called fields), each of which contains an item of information (such as a date or name) about a specific subject or activity. Sometimes referred to as a database record.\nRM—Any book, paper, map, photograph, database record, e-mail message, image, or other documentary material, regardless of physical form or characteristics, that is made or received by a Federal agency and is evidence of the organization’s activities, or has informational value.\nDocument:\nIT—A word-processing text file, completed form, voucher, or other representation of stored information.\nRM—Structured or semi-structured information (such as a book, memo, letter, or map) that has a predictable structure and can be accessed and read by people.\nFile:\nIT—In data-processing, a collection of records. In computer applications, an entity of information that has a unique name, a particular format, and, usually, a specific file name suffix.\nRM—An accumulation of business materials arranged according to a plan and related to each other in some way (e.g., a case file).\n\nBackup:\nIT—IT archival and tape backups—usually two types, “operational” and “project.” For operational backups, IT wants to be able to restore systems that fail and provide the restoration of the files, e-mails, and databases that are corrupted or have failed. The project backups have the same purpose, but are usually associated only with a unique system or group of systems that are themselves associated with an ongoing project.\nRM—A duplicate of a record or of groups of records used primarily for the protection of information in case of loss or destruction of the original; to be stored off-site under appropriate environmentally controlled conditions.\n
• #14: \n
• #15: Points of Disconnection Between IT and RM\nDifferent perspectives on the word “records”\nDifferent perspectives on lifecycle\n\nRM records lifecycle: the lifespan of a record from its creation and receipt to its final disposition. Usually described as having three stages: creation, maintenance and use, and disposition\n\nIT Systems Development Life Cycle (SDLC) definition: phases of development of an electronic information system\nTypical stages: initiation, definition, design, development, deployment, operation, maintenance, enhancement, and retirement\nSignificant step in several stages: the definition, development, and refinement of the data model that includes the records being created or managed\nImplications of lifecycle differences\n\nThe records lifecycle often exceeds the SDLC.\nWhen it does, the agency needs to retain the record for a period of time longer than the life of the electronic information system.\nThis presents special challenges, such as maintaining the trustworthiness of the record when migrating from one system to another.\n
• #16: In the modern office, no one can develop and promote a records management program in isolation. Overcoming communications problems is a task for allies, not rivals.\n\nIt is vital to convince top management that the records management program will be beneficial to the agency, and it is vital to get their support. Building alliances with others will go a long way toward ensuring that your records management program will succeed.\n\nGood communication is part of building alliances. Using your skills of active, empathetic listening and appropriate and timely communication, you can build an effective working relationship that maximizes your own and your allies’ resources. Your communication skills and strategies will be essential in building rapport and eliminating obstacles to effective interaction.\n\nEstablishing clear objectives and responsibilities and developing a consensus are important success factors in working in effective teams. The objective for defining responsibilities, authorities, and inter-relationships is to establish and maintain a records and information management regime that meets the needs of internal and external stakeholders.\n
• #17: Every employee needs records management competencies. A “network” approach to managing agency records and information permits each staff member’s relevant expertise and interests to be applied regarding the creation, maintenance, and use of records. For example, unless each stakeholder participates in RM, business assets can be difficult to locate, cannot easily be shared, and are at a risk of being lost. Good networks of communication are essential.\n\nThe 21st-century workplace exerts an almost constant pressure to update skills in order to keep up with careers and functions that are evolving. Career development is a necessary concern to both RM and IT.\n
• #18: \n
• #19: In conducting business, every Federal agency creates a great number of records in a variety of media. The quality of those records varies from agency to agency and program to program. If information is not captured in records that are accessible in organized files or electronic recordkeeping systems, it will not be available when needed later. Poor documentation may result in an unresponsive government, or a government that cannot account for its actions, or both.\n\nConducting Government business without adequate documentation increases the possibility that, in time, not all relevant facts will be available, or interpretations may be distorted. This is even true in the short term.\n\nNARA uses the term “recordkeeping requirements” to refer to the statements in statutes, regulations, agency directives, or other issuances that specify which records are to be created or received and maintained by agency personnel\n
• #20: \n
• #21: \n
• #22: \n
• #23: \n
• #24: \n
• #25: \n
• #26: \n
• #27: Exhibit 53 of OMB Circular A-11 allows each agency and the OMB to review and evaluate the agency’s IT spending and to compare it across the Federal Government. The Exhibit consists of four parts and captures an entire Agency IT Investment Portfolio (all IT investments).\n\nEach agency submits one Exhibit 53 to OMB with its overall budget submissions. The exhibit maps to the function of the investment, not to the function of the program or mission of the agency\n\nExhibit 300 of OMB Circular A-11 must be developed for major investments. The Exhibit 300 business case is a high- level summary of the investment’s current justification and management plans, including a project plan, benefit-cost analysis, alternatives analysis, acquisition plan, risk management plan, human resources management plan, enterprise architecture, and IT security plan. In the case of IT investments that are proposed or underway, this information is used by the operating unit, the agency’s Capital Investment Technology Review Board (CITRB), and OMB to determine whether investment funding should be recommended or continued.\n
• #28: \n
• #29: The Freedom of Information Act (FOIA) generally provides that any person has a right, enforceable in court, to gain access to Executive Branch agency records. Some agency records (or portions of them) are protected from public disclosure by one of nine exemptions, or by one of three special law enforcement record exclusions. The E-FOIA Amendments of 1996 (E-FOIA) were developed to update the FOIA and include e-records references. NARA now has an office that serves as an ombudsman for FOIA in the government, the Office of Government Information Services (OGIS). OGIS resolves disputes that arise from FOIA requests.\n
• #30: The Privacy Act (PA) seeks to ensure that when the Government collects personal information about people, the Government manages and protects that information properly. The definition of a record is different under this Act. Key points include:\n\nUnder the Privacy Act definition, a record is “…[a]ny item, collection, or grouping of information about an individual that is maintained by an agency, including, but not limited to, his education, financial transactions, medical history, and criminal or employment history and that contains his name, or the identifying number, symbol, or other identifying particular assigned to the individual, such as a finger or voice print or a photograph.” These records need to be maintained in a secure environment.\n
• #31: The Electronic Records Policy Working Group (ERPWG) was formed to meet the mandates of Section 207 of the E-Government Act of 2002 (Pub.L.107-347). NARA led the ERPWG in developing recommendations to ensure effective management of Government information on the Internet and other electronic records.\n\nThe ERPWG report, “Barriers to the Effective Management of Government Information on the Internet and Other Electronic Records,” identified four barriers faced by agencies attempting to manage electronic information.\n
• #32: There is no understanding, particularly by agency staff at the desktop, of the concept of lifecycle management that ensures that information and records will be managed effectively as business assets for as long as needed.\nRecords management is either not incorporated into business processes, or not incorporated early enough, particularly as these processes are automated. Records management is not perceived as supporting the agency mission. Instead, agencies view it as an afterthought—an administrative support function performed at the end of a particular process when the records are no longer needed for current business and are eligible for disposition.\nBecause the benefits of strong records and information management practices are not apparent to management, the records management function is one that has little clout and is not provided with the resources to achieve its goals.\nAgencies must realize that capturing the institutional knowledge of an agency demands a multidisciplinary approach integrating records management, IT, and the users who create the records and information.\n
• #33: The ERPWG submitted their “barrier report” to ICGI (Interagency Committee on Government Information). ICGI recommended a Government-wide, coordinated information and records management strategy to assist agencies in overcoming barriers and in meeting their information and records management responsibilities in the current environment.\n\nICGI’s three major recommendations are:\n1.Support agencies through effective leadership and clear records management guidance.\n2.Create the RM profile in the Federal Enterprise Architecture.\n3.Improve accountability for records management.\n
• #34: \n
• #35: Good records management and recordkeeping practices for new IT systems begin at the earliest point of development, usually in the early concept and planning stages, and continue on, through traditional Capital Planning or Systems Development processes.\n
• #36: Professional systems developers and the customers they serve share a common goal of building information systems that effectively support business process objectives. To ensure that cost-effective, quality systems are developed which address an organization’s business needs, developers typically undertake these activities\n\nThis list is based on the Center for Technology in Government report Models for Action Project: Developing Practical Approaches to Electronic Records Management and Preservation, 1998, SUNY University at Albany, and by reference to Kal Toth, Intellitech Consulting, Inc. and Simon Fraser University; the list is partly created from lecture notes: Software Engineering Best Practices, 1997\n
• #37: This is a graphic representation of the steps in the SDLC.\n
• #38: Product plan/Initiation phase: Identify and validate an opportunity to improve business accomplishments of the organization or a deficiency related to a business need; Identify significant assumptions and constraints on solutions to that need; Recommend the exploration of alternative concepts and methods to satisfy the need.\n\nConcept phase: This phase will determine whether an acceptable and cost-effective approach can be found to address the business need, with high confidence that technology can support it. Identify interfaces, data and business requirements, and basic ERM requirements. Establish system boundaries, identify goals objectives, critical success factors, and performance measures. Evaluate costs and benefits of alternative approaches to satisfy the basic functional requirements. Assess and mitigate project risks. Complete Business Process Redesign. Develop high-level architecture, process models, and data models, and a concept of operations\n\nRequirements Phase: Further define and refine the functional and data requirements. Complete component selection. Develop detailed data and process models. Define additional functional requirements that are not easily expressed in the data and process models. Further refine the high-level architecture and logical design. Continue to identify and mitigate risks. \n\nPreliminary Design: Design, develop and test the system, update plans to deploy the system. Complete business transition planning, and identify and initiate business transition activities. Hopefully, initiate the records scheduling process. \n\nIntegration and system test, development and acceptance: This phase is completed when the Technical Review Board conducts the Production Readiness Review confirming that the AIS is complete, correct, fully tested, and ready for the Deployment Phase to begin. During this phase, the records schedule should be completed and approved.\n\nProduction: At this phase, the system is certified operational and deployed in the agency for business purposes. The system should be evaluated regularly against the mandate to serve the agency’s mission and meet business needs. New systems should be developed when legacy systems cannot be successfully or effectively upgraded, and the process will begin again.\n
• #39: \n
• #40: Imagine your agency is planning a new, enterprise-wide IT system for handling all its records. You know it has to include records management.\nWhere do you go to find out the specific records management requirements?\nWho will build those requirements into the system—the system analyst? The contractor? You?\nAre there existing Commercial Off-the-Shelf (COTS) packages that can handle your agency’s requirements?\n
• #41: \n
• #42: \n
• #43: \n
• #44: The goal of this step is to gather basic information about what the system will and will not manage. It may not be practical or cost-effective to manage all the records in all formats. You should identify the various types of agency-specific records that are created and their formats. \n\nIn addition, identify stakeholders who will need to be consulted on how the system will create, capture, maintain, disseminate, and dispose of records generated in the course of agency business. \n\nFinally, identify your agency’s existing systems. Most organizations have existing systems that create or store electronic records, and most of these are not designed to provide basic recordkeeping functionality, such as file plan organization and disposition. Once these systems have been identified, the decision to migrate or integrate them into an ERM system may generate additional agency-specific requirements. Review existing systems \n
• #45: Agencies should have an enterprise-wide IT architecture that provides the baseline for the existing infrastructure and lays the foundation for future improvements. Any ERM system must fit within the existing infrastructure, and the organization must incorporate ERM into the enterprise architecture.\n
• #46: \n
• #47: \n
• #48: \n
• #49: \n
• #50: \n
• #51: \n
• #52: \n
• #53: \n
• #54: A successful pilot test will allow the agency to ensure that their current records management requirements are sufficient for a software solution.\nThe pilot allows the agency to test the system design in a real-world, controlled environment with actual production users performing their normal routines and tasks. This permits the validation of the system design, as well as the identification of any modifications to procedures that the solution may require. Pilots are particularly useful for complex projects such as ERM, when the software is new (either to the agency or the market), implementation represents a significant change in the way staff works, and user acceptance may be difficult to obtain. A pilot will provide the practical experience necessary before introducing an ERM solution agency-wide.\n
• #55: \n
• #56: Defining the purpose and goals is essential for the success of the pilot. These are not the same as your goals for the overall agency ERM initiative. For the pilot, the goals should be related solely to the product under evaluation. \n
• #57: \n
• #58: Keep in mind that failure of the pilot is not always a negative. The goal of a pilot is to evaluate a product, and to develop an objective analysis of the results and an assessment as to how to, or even whether to, proceed with full deployment of that product. \n\nIf the decision is made to proceed with an ERM system, the pilot process provides several key outcomes:\n\nBetter-trained staff in terms of records management processes and understanding as to the importance of ERM to the agency\nWell-developed technical, managerial, and production processes\nAn improved implementation plan\nRevised cost estimates and a realistic schedule for agency-wide deployment\nSupport of management and users\n
• #59: \n
• #60: \n
• #61: \n
• #62: \n
• #63: \n
• #64: \n
• #65: \n
• #66: \n
• #67: \n
• #68: \n
• #69: \n
• #70: \n
• #71: \n
• #72: \n
• #73: \n
• #74: \n
• #75: \n
• #76: \n
• #77: \n