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
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
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&#x2019;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
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&#x2014;every user has a &#x201C;delete&#x201D; key. \n
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&#x2014;not the content&#x2014;are being managed.\n\nWhen RM and IT aren&#x2019;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
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
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
It is important that all records management staff possess the same set of skills, including process mapping, analytical thinking, the ability to speak IT&#x2019;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
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&#x2013;IT&#x2014;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&#x2013;RM&#x2014;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
Record:\nIT&#x2014;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&#x2014;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&#x2019;s activities, or has informational value.\nDocument:\nIT&#x2014;A word-processing text file, completed form, voucher, or other representation of stored information.\nRM&#x2014;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&#x2014;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&#x2014;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&#x2014;IT archival and tape backups&#x2014;usually two types, &#x201C;operational&#x201D; and &#x201C;project.&#x201D; 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&#x2014;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
Points of Disconnection Between IT and RM\nDifferent perspectives on the word &#x201C;records&#x201D;\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
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&#x2019; 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
Every employee needs records management competencies. A &#x201C;network&#x201D; approach to managing agency records and information permits each staff member&#x2019;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
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 &#x201C;recordkeeping requirements&#x201D; 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
Exhibit 53 of OMB Circular A-11 allows each agency and the OMB to review and evaluate the agency&#x2019;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&#x2019;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&#x2019;s Capital Investment Technology Review Board (CITRB), and OMB to determine whether investment funding should be recommended or continued.\n
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
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 &#x201C;&#x2026;[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.&#x201D; These records need to be maintained in a secure environment.\n
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, &#x201C;Barriers to the Effective Management of Government Information on the Internet and Other Electronic Records,&#x201D; identified four barriers faced by agencies attempting to manage electronic information.\n
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&#x2014;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
The ERPWG submitted their &#x201C;barrier report&#x201D; 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&#x2019;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
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
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&#x2019;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
This is a graphic representation of the steps in the SDLC.\n
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&#x2019;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
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&#xF074;Where do you go to find out the specific records management requirements?\n&#xF074;Who will build those requirements into the system&#x2014;the system analyst? The contractor? You?\n&#xF074;Are there existing Commercial Off-the-Shelf (COTS) packages that can handle your agency&#x2019;s requirements?\n
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&#x2019;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
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
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
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
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
ADVANCED ELECTRONIC RECORDS MANAGEMENT July 13, 2011: Nashville, TN Arian D. Ravanbakhsh Office of the Chief Records Officer National Archives and Records Administration
Outcomes2 Describe the positive factors that promote collaboration between RM and IT staff Identify legal requirements and policies that impact Federal information requirements for electronic records Recognize where to insert RM requirements into the planning, development, and implementation of information systems Develop and implement an enterprise-wide electronic records management pilot Demonstrate awareness of current issues in electronic recordkeeping as well as emerging technologies and their implications for web- based records management Describe best practices in ERM
The IT and RM Worlds3 Effective Records Managers must understand the technical functions and processes within an agency.
Overcome Barriers4 The realities of the current relationships between the IT and RM worlds…
Integrated Information5 There must be a multidisciplinary approach integrating RM, IT, and the users who create the records.
Problems6 Problems generally arise from the fact that records management has become a distributed responsibility across the agency.
More Problems7 IT builds the system—but does not manage the content. RM manages content—but the system may be lacking some necessary tools.
Solutions8 Integrate RM and IT Ensure that electronic records can be located, shared, and accessed agency-wide Records and information, as well as tools, must be managed by RM and IT working together
RM Staff Must…9 Understand how technologies affect electronic records Know that they are key players Realize that records management requires technological skills and understanding far beyond document tracking
Records Management Staff Skills10 Records management staff should posses the same set of skills: Process mapping Analytical thinking Speaking IT’s language Managing projects Familiarity with the Systems Development Life Cycle
How Would You Define the Term?11 RM and IT professionals use many of same words, but they mean different things archive archive
IT and RM Connection Points13 IT systems development Capital planning, IT architecture, and strategic plans (Clinger-Cohen/ITMRA) Electronic signatures (GPEA) Transfer of permanent electronic records to NARA (E-Gov) E-mail Electronic recordkeeping
IT and RM Points of Disconnection14 Different perspectives on the word “records” Different perspectives on lifecycle
Building Alliances15 No one can develop and promote a records management program in isolation; it requires allies Top management must be convinced that records are essential agency assets and managing them is vital Good communication is key to working collaboratively across the organization IT and RM must both meet the needs of internal and external stakeholders
New Skills for Working Together16 Electronic records management Communication Risk assessment and management Business process design Systems analysis Requirements development Project management
Recordkeeping Requirements18 Poor documentation may result in an unresponsive Government that cannot account for its actions Even in the short term, lack of documentation causes problems The solution is to develop, implement, and enforce recordkeeping requirements NARA uses the term “recordkeeping requirements” to refer to the statements in statutes, regulations, and agency directives that specify which records are to be created and maintained.
Legal Requirements19 Federal Records Act Clinger-Cohen Act Government Paperwork Elimination Act (GPEA) E-Gov Act of 2002 Office of Management and Budget (OMB) Circular A-130 OMB Circular A-11
Federal Records Act (44 U.S.C. 3301)20 Gives the Archivist of the United States the authority to provide guidance and assistance on the management of records.
Clinger-Cohen Act (40 U.S.C. 1401)21 Requires that investments in systems include a cost-benefit study on the use of electronic recordkeeping functions to manage the electronic records.
Government Paperwork Elimination Act (P.L. 105-277)22 Makes Government information more available electronically and relieves the public reporting burden. Generally, GPEA states that electronic records will be and are being created under this Act and that, in addition to the e- records themselves, e-records required for verification are also being created.
E-government Act of 2002 (44 U.S.C. 3601)23 Identifies initiatives to integrate agency operations and IT investments. Eliminates redundant systems and improves customer service. Example: Travel systems. From independent in every Federal agency to GovTrip
Office of Management and Budget (OMB) Circular A-13024 Requires agencies to plan for managing information throughout its lifecycle, and to train personnel to do so.
Office of Management and Budget (OMB) Circular A-1125 Requires establishment of performance goals for IT; provides guidance on preparing budget submissions. Exhibit 53: Agency IT Investment Portfolio Exhibit 300: CPIC and Business Case for Each Systems
Other Information Requirements27 Freedom of Information Act (5 U.S.C. 552) Privacy Act (5 U.S.C. 552a)
Freedom of Information Act (FOIA)28 Any person has a right to gain access to Executive Branch agency records Some records or portions of them are protected from public disclosure either by one of nine exemptions, or by one of three special law enforcement exclusions If a FOIA request is received, you cannot destroy any information related to the request
Privacy Act29 For the purposes of the Privacy Act, a record is defined as any item, collection, or grouping of information about an individual that is maintained by an agency, including: Education Medical Criminal Employment if that information contains any identifying information These records need to be maintained in a secure environment
Electronic Records Policy Working30 Section 207 of the E-Government Act of 2002 Tasked NARA to lead ERPWG in writing: Barriers to the Effective Management of Government Information on the Internet and Other Electronic Records
ERPWG Identified 4 Barriers31 1. Records are not managed as business assets. 2. RM is not viewed as critical. 3. There is a lack of training, tools, and guidance for Federal staff. 4. RM and IT disciplines are poorly integrated in Federal agencies.
Solutions to Identified Barriers32 To overcome the barriers, Federal agencies must manage their records from the moment of creation
Recognize Where to Insert RM Requirements34 Records management must start early— at the concept or planning stage.
Typical Tasks in the System Development Process Lifecycle35 System conceptualization Unit development System requirements and Software integration and benefits analysis testing Project adoption and project System integration and testing scoping Installation at site System design Site testing and acceptance Specification of software Training and documentation requirements Implementation Architectural design Maintenance Detailed design
SDLC Phases37 Product Plan and Initiation Phase Concept Phase Requirements Definition Preliminary and Detailed Design, Development Integration and System Test, Development, and Acceptance Production and Upgrades, or Retirement and Rollover
Evaluating a Proposal38 Declare documentary materials as records Capture records in a secure repository Organize records for efficient retrieval Limit access to records to authorized users Preserve records for their entire lifecycle Allow for disposition of records based on approved agency schedules
Guidance for Your System39 Your agency is planning a new IT system to handle its records, and needs to include RM: Where do you go to find out the requirements? Who will build them into the system? Are there existing COTS packages that fit your requirements?
Help from Two Sources40 DoD 5015.2 Endorsed by NARA Extremely technical Provides baseline for RMA ISO 15489 Recognized around the world Provides information on trustworthiness of an electronic record
DoD 5015.241 Design criteria standard for electronic records management software applications (RMA) Includes mandatory and non-mandatory requirements Provides minimum RM requirements based on NARA regulations and 44 U.S.C. 2902 Fluid document Always being updated
Beyond DoD 5015.242 1. Determine ERM scope. 2. Review infrastructure/IT architecture. 3. Review agency records and information resources, management guidance, and directives. 4. Review additional standards. 5. Review requirements. 6. Classify requirements. 7. Involve stakeholders in review.
Beyond DoD 5015.2 (cont’d.)43 1. Determine ERM scope. Ask what the system will and will not manage: E-mail Paper Office automation software Web content Electronic forms Identify and consult with stakeholders Review existing systems to determine: What system creates or contains records? What types of records? What legacy systems will be integrated or migrated?
Beyond DoD 5015.2 (cont’d.)44 2. Review infrastructure/IT architecture. Find out about: Network servers and system software Security Desktop applications Standard desktop configuration At what level will the system be administered?
Beyond DoD 5015.2 (cont’d.)45 3. Review agency records and information resources, management guidance, and directives. RM policies IRM policies Security policies Disposition and retention schedules
Beyond DoD 5015.2 (cont’d.)46 4. Review additional standards. Reach beyond your agency for best practices within the industry Model Requirements for the Management of Electronic Records (MoReq) AIIM Standards Committee on Integrating Records Management and Document Management Requirements Reports by Doculabs on ERM, EDM, and ECM systems ISO 15489-1: Information and Documentation—Records Management
Beyond DoD 5015.2 (cont’d.)47 5. Review requirements (created after steps 1–4). Does it: Describe a system functionality? Express a single idea? Map clearly to specific organizational goals? Map directly to business processes or policies? Describe user’s needs? Is it: Testable? "Keep, Too vague? eliminate, Too implementation-dependent? or revise" requirement
Beyond DoD 5015.2 (cont’d.)48 6. Classify requirements. Assess the functionality of each additional requirement as to whether: The system cannot function without it It provides significant savings in time or resources It smoothes the path for the end user It provides the Records Manager with useful tools It reduces risks to future access to the information
Beyond DoD 5015.2 (cont’d.)49 7. Involve stakeholders in review.
Beyond DoD 5015.2 (cont’d.)50 This step-by-step approach will allow you to develop requirements that: Support business process Make best use of resources Harmonize with current system Produce system with tangible benefits
Records Management Application Considerations52 Adequacy of existing agency record schedules Amount of IT support available Technical awareness (training) of agency staff
Piloting an RMA53 Piloting it rather than installing it Will allow the agency to ensure that its RM requirements are sufficient Is useful for complex projects where Implementationrepresents significant change User acceptance may be difficult to obtain Allows for real-world testing in a controlled environment
Three Phases of Pilot Projects54 Preliminary Conducting the pilot Testing and evaluation
Defining the Purpose and Goals Goals for overall Goals for ERM pilot ERM initiative 55
Conducting the Pilot56 Check assumptions: Findout if your preliminary assumptions regarding hardware, software, and service level were accurate Develop tools to facilitate: Documentation Communication/knowledge transfer Metadata processes Select an office to serve as testers Install the application Document user experiences
Testing and Evaluation57 Some problem areas to avoid: Holding out for perfection—causes delays; increases costs and the impatience of users Too many changes based upon individual user requests with little or no analysis of the impact of those changes Lack of user involvement—or, on the other hand, too much user involvement Unrealistic schedule for product Erroneous cost/benefit assumptions Lack of management support
Where Next?59 Component-based Architecture A component is a self-contained business process or service with predetermined functionality that may be exposed through a business or technology interface.
Emerging Technology60 Web 2.0 is: A second generation of web design Rise of social networks Facilitating communication and collaboration Commonly dubbed “social media”
RM/Appraisal Concerns61 What constitutes the “record” Method and frequency of capture Applicability of existing schedules
What Does NARA Say?74 Managing Records in Web 2.0/Social Media Platforms http://archives.gov/records-mgmt/bulletins/2011/2011-02.html Managing Records in Cloud Computing Environments http://archives.gov/records-mgmt/bulletins/2010/2010-05.html Report on Federal Web 2.0 Use and Value http://archives.gov/records-mgmt/resources/web2.0-use.pdf