FBI Records Management Architecture: Transition Strategy
FBI Records Management Architecture:
1.1 Stream 1: Records from RMA Integrated Applications
1.2 Stream 2: Records from ERKC Applications
1.3 Stream 3: Paper Records
1.4 Legacy Systems/Applications and New Systems/Applications
1.5 Work Breakdown Structure and Schedule
3.1 Conduct Project Planning and Adhere to Project Management Methodology
3.2 Implement QA Procedures
3.3 Conduct Project Reviews
3.4 Integrate Contractors into QA Processes
3.5 Communication with Stakeholders
LIST OF APPENDIXES
LIST OF TABLES
Table 5-1:Stream 1 Incremental Integration
Table 5-2:Quantitative Risk Assessment of Project Characteristics
Table 5-3:Summary of Risk Analysis
Table 5-4:RM Transition Reviews
Table 5-5:RM Transition Deliverables
Table 5-6:Inputs, Outputs, and Exit Criteria for LCM Phases
Table 5-7:Creation Phase Gap Analysis
Table 5-8:Maintenance/Use Phase Gap Analysis
Table 5-9:Disposal Phase Gap Analysis
LIST OF FIGURES
This is the final document in a series of sequential work products designed to move the Bureau from the current state of Records Management (RM) to the Target RM environment. After conducting a high-level Current State Evaluation, the Records Automation Section (RAS) developed a Business Concept of Operation (ConOps) and a System ConOps for the target RM environment. The concepts were concurrently integrated with the Federal Bureau of Investigation's (FBI) Enterprise Architecture (EA) effort. This Transition Strategy provides the high-level direction for moving from the Current State to the Target environment by addressing the following key areas.
- Implementation Strategy. The transition has three streams that correspond to the three main sources of FBI records. Stream 1 consists of records from applications that will fully integrate with the Records Management Application (RMA). Stream 1 will use an incremental integration whereby increasing sets of functionality are implemented. This approach reduces risk and allows for tangible benefits to be realized more quickly. The Stream 1 transition will occur first. Stream 2 consists of records from Electronic Recordkeeping Certification (ERKC) applications. ERKC applications are those applications that have successfully demonstrated compliance with electronic recordkeeping requirements as specified in theFBI Electronic Recordkeeping Certification Manual Version 1.0, April 30, 2004. The Stream 2 implementation will overlap with Stream 1, and the timeframe for completion will depend on the number of applications that are categorized into that Stream. Stream 3 consists of paper records. These records will be transitioned to RMA management last. However, the DocLab conversion project that currently includes some metadata capture will continue in the interim.
- Work Breakdown Structure (WBS) and Schedule.The high-level WBS included in this document includes the Streams and second level tasks that must be completed. A detailed WBS that includes additional levels of granularity will be developed during the planning for each transition Stream. As illustrated in the figure below, under Stream 1 Iteration 1 (i.e., core capabilities), the highest priority applications will be integrated during CY 2005. Secondary applications will be integrated during CY 2006. Iteration 2 and Iteration 3 will be completed during CYs 2007 and 2008, respectively. Stream 2 starts at the beginning of CY 2006 with a completion date to be determined. Stream 3 starts at the beginning of CY 2008 with a completion date to be determined. The schedule for the transition is described and illustrated in Section 2.1. More detailed schedules will be developed during the planning for each transition Stream. However, the planning and implementation timeline for the Streams will, to a significant extent, be driven by the progress of the overall EA effort.
Risk Management Strategy. The risk management strategy involves identifying, quantifying, assessing, and mitigating potential risks. The first step in the process begins with an initial quantitative risk assessment of the project characteristics. The second step identifies the consequence, severity, and probability of specific risk factors and suggests mitigation measures. The RMA implementation will use the Risk Management Tool Kit, which is a set of tools that help identify, analyze, prioritize, and track risk. The tools also assist with implementing mitigation plans, supporting effective decisions to control risks, and assuring that risk information is communicated and documented.
- Quality Assurance (QA) Strategy. The QA strategy described in this document includes identifying processes/tasks to be monitored, creating quality standards, establishing metrics to measure progress, tracking and trending processes/tasks, analyzing actions needed, recording results of action taken, participating in project reviews, and capturing lessons learned. The strategy relies on the development and execution of a detailed Quality Assurance Plan (QAP). In addition to the functions specified in the FBI's Information Technology (IT) Lifecycle Management (LCM), the QAP will describe project planning, QA procedures, project reviews, integration of contractors into QA processes, and communication with stakeholders.
- Configuration Management (CM) Strategy. CM involves identifying the configuration of hardware/software at each lifecycle phase to control changes and maintain the integrity of the configuration throughout the entire lifecycle. The CM strategy for the RM transition will be executed by developing and implementing a detailed CM Plan. The Plan will identify items placed under configuration control, describe the approach to defining and managing project baselines, and include management and control of hardware, software, interfaces, data, procedures, and facilities. The Plan will describe the methods for controlling, tracking, implementing, and reporting changes and describe the configuration status accounting procedures for maintaining baselines. The plan will also describe system and document identification conventions.
- Process Management Strategy. Process Management is the development, documentation, evaluation, and modification of standardized processes to facilitate quality improvements and efficiency through the institutionalization of lessons-learned. During the RM Transition, there will be three broad sources of modifications of standardized processes. The first source will be modifications to the internal transition processes. The second source will be modifications to existing standard operational processes that must occur as a direct result of the RM Transition. The third source will be modifications that occur independently of the transition (e.g., as a result of on-going process improvement initiatives) within the operational and administrative units of the Bureau.
- Milestones. The LCM specifies the control gate and deliverable milestones that the RM transition will have to meet. The milestones include reviews of the System Concept, Acquisition Plan, Critical Design, Deployment Readiness, System Test Readiness, and Operational Acceptance and completion of the deliverables associated with each of these reviews.
- Gap Analysis. Gap analysis is a technique used to compare the current state of an activity within an organization with a desired end state. We provide a description of the Current State and Target State for each phase of the lifecycle and provide comments on the actions necessary to close the gap.
The desired end-state is that most FBI records are maintained and managed electronically by an enterprise RMA. To achieve this end-state, the FBI needs to identify, acquire and deploy an application that combines electronic workflow, imaging, and management of documents, e-mails, evidence, and records. The RAS has developed an enterprise RM model that provides the framework for storing, accessing, and managing the FBI's records, regardless of format, media, source, or location.1 In this model, an enterprise RMA will provide lifecycle management of the Bureau's records.
From the user perspective, employees with the proper authorization will have access to FBI electronic records and information at their desktop. This desktop access will provide a more robust, user-friendly environment to create, access, and share information. The capabilities will also include creation, receipt, processing, dissemination, use, storage and final disposition of records.
In the model, an RMA enabled by a metadata repository will allow users to search and cross-index information without accessing the legacy applications. The RMA and metadata repository will also support the FBI's DocLab paper records conversion projects and enable the ordering of documents in both paper and electronic form from the FBI's Paper Repository. By capturing required metadata, all information that may be created or received through the FBI's investigative or business processes can be electronically managed in a legally acceptable manner, while safeguarding privacy and other sensitive information.
To be successfully implemented and effectively used by the Bureau, the RMA must integrate with existing and future systems within the Target EA. The integration of records, documents, data, evidence, and Freedom of Information and Privacy Act (FOIPA) management in a single solution is key to achieving the FBI's vision of efficient and effective records management.
There will be three sources of records: RMA integrated applications, ERKC applications, and paper. Each method corresponds to a Stream in the transition. As illustrated in the figure on the following page, the transition will occur over time with progressively more records managed by the RMA and fewer records maintained in paper form. It is also anticipated that, after an initial increase, the number of records managed by ERKC applications will also decline over time.
The Baseline EA Application Layer provides an initial frame of reference for the magnitude of the required transition. More than 300 applications were identified as part of the baseline architecture. Most of these applications generate records. During the Target EA development, redundant capabilities will be identified. Refinement of the Target EA will facilitate determining which applications will be included in each Stream. This determination will be based on objective criteria such as mission criticality, volume of records produced, frequency of use, remaining application/system lifespan, and ease of integration with the RMA.
Stream 1 consists of those applications that will fully integrate with the RMA. The RMA will facilitate desktop capability for the creation, receipt, processing, dissemination, use, storage, and final disposition of records. The RMA enabled by a metadata repository will allow users to search and cross-index information without accessing the legacy applications. The Stream 1 implementation will occur incrementally. The LCM describes the incremental model as a "software development methodology in which constituent activities occur in an overlapping and iterative manner resulting in incremental completion of the overall product. Each subsequent product delivery fulfills an additional subset of requirements until all desired features and functionality are complete."2 High-priority system features and functionality are incorporated in the early iterations. The incremental approach is appropriate because:
- RM core requirements are relatively stable and well understood
- Early, partial capability is needed (i.e., core electronic RM requirements)
- The system divides naturally into increments (capabilities aligned with FBI Service Domains)
The core records management capabilities (i.e., those capabilities aligned with the Records Management Service Type under the Digital Asset Services Domain in the Target EA) will be implemented in the first iteration. Subsequent iterations will implement the capabilities that are aligned with other Service Domains/Types.3 The implementation order will be based on a prioritization agreed upon at the EA level. During iteration 2, medium priority capabilities would be implemented and the RMA will be integrated with all high and medium priority applications. During iteration 3, the remaining capabilities will be implemented and the RMA integrated with all high and medium priority applications. Low priority applications will never be integrated. They will either not be refreshed at the end of their useful life, or will be included in Stream 3.
Individual applications will be logically grouped, and integrated simultaneously or on a staggered basis during the iterations. As indicated in Table 1, the highest priority applications will be integrated with the RMA during CY 2005. Additional applications will be integrated during CY 2006. Subsequent iterations will be completed as scheduling, budgeting, and staffing resources permit.
|Iteration||Capability Priority||Application Priority||Complete By|
|2||Medium||High and Medium||TBD|
|3||Lowest||High and Medium||TBD|
In Stream 2, those applications that will not be fully integrated with the RMA will achieve ERKC.4 Stream 2 will overlap with Stream 1 as illustrated in Figure 1. The application/system owner will manage the modification of the existing system with input and guidance from the Records Management Division (RMD). Each application that undergoes modification to achieve ERKC will follow the FBI IT LCM process and be subject to the control gates and deliverables tailored to that application.
Once an application has achieved ERKC, the native application will be capable of capturing and exporting record metadata to the RMA metadata repository. However, the record content will not be exported to the RMA content repository. Planning for this Stream is necessary because some applications being used at the FBI will not be capable of integrating with the RMA in the short or near-term. However, these applications may be capable of being modified to meet the ERKC requirements.
Some applications will not be able to integrate with the RMA or meet ERKC requirements and, therefore, will have to maintain paper records. In addition, paper records will also continue to be received in hard copy format (e.g., a fax from a local law enforcement office). The DocLab operations will digitize and capture some metadata for many of these records. Digitized records will eventually be stored in the central content repository and managed by the RMA.
Records that remain in hard copy format will be incorporated into the enterprise RM system by designing and implementing metadata capture capability. Metadata will be entered through a browser template and stored in the metadata repository. Implementation of the metadata capture capability will follow the LCM process. Planning for this scenario is necessary because some information will always be received and maintained in hard copy. Paper documents will be stored in the Paper Repository.
Some applications will be identified that will not be refreshed at the end of their normal lifecycle if the capabilities they provide can be provided by other applications. In the interim, the records generated by these applications will remain paper-based. Metadata capture capability for these applications may be implemented during Stream 3, however, these applications most likely will not be included in the transition.
Through the EA and IT LCM governance processes, the FBI will be able to ensure that any new applications and systems can be fully integrated with the RMA or, alternatively, can achieve ERKC. These governance processes will allow the FBI to continue to migrate towards having progressively fewer paper records. The long-term vision is that most FBI electronic records will be managed by the RMA. However, even in the near and medium-term, this transition strategy provides a centralized search capability using a metadata repository.
The figure below presents the high-level WBS and schedule for the entire transition.
This high-level WBS depicts the LCM phases occurring simultaneously throughout Stream 2 because that transition involves the modification of individual systems/applications to achieve ERKC. It is possible that some systems/applications will not require modification to be certified. However, most ERKC systems/applications will likely require some modifications.
Each system/application that requires modification to achieve ERKC will be required to follow an appropriately tailored LCM process. This concept is illustrated in the figure above.
Risk management is an on-going process that begins in the Concept Exploration phase with initial risk identification and continues throughout the project's lifecycle. The FBI's IT LCM defines risk management as the "proactive identification of potential issues before they occur".5 This proactive identification allows for timely avoidance or mitigation of risks. The FBI's LCM incorporates risk revalidation during planning and implementation and calls for an active risk management approach to monitor, mitigate, and control risks. Program management in the RMD will work to ensure that risk factors are accounted for throughout the transition and that new factors are identified and mitigated.
The risk management process for the RM transition involves identifying, quantifying, assessing, and mitigating potential risks. The first step in the process was to conduct an initial quantitative risk assessment of the transition characteristics (Table 5-2). The second step was to identify the consequence, severity, and probability of specific risk factors and suggest mitigation measures (Table 5-3).
Table 5-2 lists the project characteristics and associated risk factors for Stream 1, Iteration 1 of the transition. Because each iteration in the transition provides realizable benefits by itself and does not depend on subsequent iterations, evaluating the risk characteristics of individual iterations is more appropriate than evaluating the transition as a whole. Prior to commencement, similar evaluations will be conducted for the other Stream 1 iterations, Stream 2, and Stream 3. The evaluations will be monitored and updated throughout each phase of the transition. The factors applicable to the RM transition are highlighted in bold.
|Project Characteristic||Risk Factor||Risk Value|
|Development exceeds 30 staff years or development costs exceed $10 million.||
|Development requires 20 - 30 staff years or development costs between $5 and $10 million.||
|Development requires 15 - 20 staff years or development costs between $2.5 and $5 million.||
|Development requires 5 - 15 staff years or development costs between $1.5 and $2.5 million.||
|Development requires 2 - 5 staff years or development costs between $0.5 and $1.5 million.||
|Development requires less than 2 staff years or development costs less than $500,000.||
|System failure has irreparable impact on FBI mission, including threat to human life.||
|System failure has severe impact on FBI mission.||
|System failure has moderate impact on FBI mission.||
|System failure has minimal impact on FBI mission.||
|System failure has minimal impact on FBI mission and manual processes are available in case the system fails.||
|Data loss or data integrity issues have irreparable impact on FBI operations, including threat to human life.||
|Data loss or data integrity issues have severe impact on FBI operations.||
|Data loss or data integrity issues have moderate impact on FBI operations.||
|Data loss or data integrity issues have minimal impact on FBI operations.||
|Data loss or data integrity issues have minimal impact on FBI operations and manual back-up processes are available in the event of data loss or data integrity problems.||
|System must provide for real-time processing with time constraints.||
|System must provide for real-time processing.||
|System must provide for near real-time processing.||
|System must provide for daily or less frequent processing.||
|System implements a new business process.||
|System implements a modified business process.||
|System implements a current or slightly modified business process.||
|Development schedule is compressed.||
|Development schedule is optimized or follows a critical path.||
|Development schedule has planned contingencies or built-in reserve.||
Total Risk Value
Low, Medium, and High Risk projects are generally characterized by total risk values of 0 - 9, 10 - 18, and 19 - 39, respectively. With a total risk value of 15, Iteration 1 falls in the "Medium Risk" category.
If risks occur they can have adverse impacts on the project time, cost, or quality. The RAS has identified potential risks and their associated probabilities to determine an appropriate response: Accept (no direct action is taken), Control (reactive risk management), or Mitigate (proactive risk management). Mitigation is the recommended response for all identified risks in Iteration 1.
Table 5-3identifies the risk areas for Iteration 1. The risk areas were evaluated with respect to their probability and severity of impact. The probabilities and impacts are characterized as Low, Medium, or High. Low impact implies minor problems/inconveniences. Medium impact implies some cost/schedule overrun, but the risk does not threaten project success. High impact means major cost/schedule overrun or the risk threatens project success.
Additions to this risk assessment, if warranted, will be made as the transition moves forward. The RMD will monitor and address risks throughout the transition by using the FBI's Risk Management Tool Kit, which is a set of tools that help identify, analyze, prioritize, and track risk. The tools also assist with implementing mitigation plans, supporting effective decisions to control risks, and assuring that risk information is communicated and documented. The tools provide the tracking mechanism for potential and actual risks across the entire lifecycle.
(Cost, Schedule, Product, Quality, Benefit)
|Severity of Impact
|Probability of Occurrence|
(Accept, Control, Mitigate)
|Technical environment (hardware and software) not in place on a timely basis||
C, S, B
|M - Develop realistic implementation plan, formulate contingency plans, and monitor efforts.|
|Software not working as planned||
C, S, P, Q, B
|M - Monitor system development and implementation effort; participate actively in requirements definition, design, and testing; conduct rapid issue resolution; and track action items.|
|Operational and organizational shortfall||
P, Q, B
|M - Ensure adequate system performance and user support, provide training and backup documentation, and conduct user acceptance testing.|
C, S, P, Q, B
|M - Acquire executive commitment and sponsorship and assign program managers to the implementation effort. Continue participation in the Enterprise Architecture Board, Solution Architects Working Group, and other communication forums to elevate awareness of RM issues.|
C, S, B
|M - Ensure contract accuracy and monitor vendor/contractor performance. Agree on scope and schedule upfront and closely monitor development and integration efforts. Require monthly budget expenditure and forecast reporting.|
C, S, B
|M - Develop realistic project plan, review monthly plans, submit weekly status reports, resolve issues rapidly, and track action items.|
The QA Strategy described in this section includes identifying processes/tasks to be monitored, creating quality standards, establishing metrics to measure progress, tracking and trending processes/tasks, analyzing actions needed, recording results of action taken, participating in project reviews, and capturing lessons learned.
The strategy relies on the development and execution of a detailed Quality Assurance Plan (QAP). The purpose of the QAP is to help the program manager (PM) build QA as an integral component to the project management. The PM will maintain and prepare updates to the QAP throughout the project. Changes may be necessary to reflect significant events such as major contract modification and programmatic change.
The QAP will address both the management of the project and the products and services that are to be produced. The IT LCM specifies that the QAP should contain procedures for detection, reporting, analysis, and correction of deficiencies. The QAP is produced in conjunction with other process and QA documentation such as the Software Development Plan or the Configuration Management Plan. As appropriate, the RM transition QAP will also draw on a variety of internal and external project management methods including leading practices and other recognized industry standards such as the Project Management Institute, Software Engineering Institute, and the International Standards Organization. The LCM specifies that, at a minimum, the document should include the following sections.
- Scope. Includes an Identification paragraph that defines the purpose of the document, provides a description of the plan's major features and objectives, and provides a concise summary of the approach toward implementing QA. Also provides a System Overview that briefly states the purpose of the system and a Document Overview that summarizes the purpose and contents of the document and describes any security or privacy considerations. This section should also describe the relationship of the QAP to other project management plans.
- Reference Documents.Lists the number, title, revision, and date of all documents referenced in the plan. Identifies the source for all documents not available through normal Government channels.
- Organization. Identifies the person responsible for the QA program and all individuals assigned to the QA organization. Includes an organization chart and narrative that describes the relationship between the contractor management, the QA organization, the program manager, the segment development organization, the test organization, and any other related organizational entities. The responsibilities of each organization with respect to the detection, reporting, analysis, and correction of deficiencies should be included in this section.
- QA Functions. Describes the procedures for each of the functions. Audits, participation in technical reviews, test monitoring, documentation review, and discrepancy control monitoring should be addressed. The LCM describes the requirements for these functions. Additional paragraphs may be added to the QAP to describe project specific QA functions. The required content for these additional paragraphs is also described in the LCM.
The RM transition QAP will describe five additional functions to help consistently deliver quality results. We describe each of these functions in more detail in the sections that follow.
Project planning and management methods will include processes, templates, and techniques. RAS will designate an FBI PM who is experienced using project management methods and tools and will implement them throughout the project. The PM will use the following methods and tools to plan, manage, and control the quality of the work.
- Project management methods including processes, templates, and techniques to support efficient and effective project management.
- Range of tools to efficiently manage the program management plan including project scheduling tools and internal risk management tools.
- Repository of successful planning and implementation techniques. We will use this repository for lessons learned and capturing new and creative ways to improve transition performance.
This function consists of defining project objectives, managing the project budget, establishing and maintaining the staffing plan, and following the FBI contract modification process. We will develop and implement detailed QA procedures to help guide the conduct of the transition. The core QA transition procedures will include the following.
- Develop Project Objectives. Work with the EA Program Management Office and other stakeholders to define clearly stated goals and objectives that meet the project requirements and user expectations.
- Conduct Project Planning. Require contractors to document and maintain a time-phased project budget and schedule as the basis for managing their aspects of the transition.
- Manage Project Budget. Require contractors to actively manage project finances using estimates defining the project costs and budgets to control execution. We will require contractors to monitor progress against the budget/schedule and take corrective action if performance deviates from the plan.
- Use Issue and Action Management. Implement a process for documenting, classifying, and tracking issues and actions that affect transition.
- Establish Deliverable Management Plan. Require contractors to create deliverable management plans to help define deliverables specified in the contract before project implementation.
- Use Change Management Processes. Implement a process for managing the documentation, analysis, and approval of changes to the contract and project work products.
- Manage Risk. Identify, document, analyze, and plan responses to project risks throughout the project lifecycle.
- Measure/Analyze Performance. Develop metrics to support information needs regarding budgetary health, solution integrity, progress to plan, and user satisfaction.
- Closeout. Require contractors to confirm with the PM that the contract is satisfied, project activities have been completed, and there are no outstanding issues before closing out their portion of the transition.
In addition to the LCM specified reviews, our QAP will incorporate several additional periodic reviews.
- Contract Reviews. These reviews will assess project status/progress, issues, financial health, and risks to verify that the project is being managed in accordance with contractual commitments and satisfying FBI requirements.
- User Surveys. The RMD will develop a process to annually measure and monitor user satisfaction. The process will begin with objective setting, continue with regular communication and feedback including executive interviews, and then start again the next year.
- Project Change Requests. The RMD will also perform a QA review for every contract modification that adds scope or funding to the project.
- Project Management Reviews (PMRs). These monthly reviews will focus on the project level processes and tasks. The review team will consist of the Program Manager, Task Managers, subject matter experts, and other key personnel. These will be comprehensive reviews of the project that also address high importance/high urgency issues. The PMR will have various input sources such as QA documents, PM feedback, resource requirements, process reviews, Monthly Progress Reports, status meetings, and follow-up actions from other reviews. At the conclusion of the PMR, the PM will create and disseminate a report to review participants and other stakeholders. The report will record the findings of the PMR and identify any follow-up actions, changes to improve quality, and measures that may improve the effectiveness or efficiency of the project.
- Root Cause Analysis. We will also document the root cause of problems and provide a description of the corrective action taken. A Root Cause Analysis is conducted in order to determine corrective or preventive actions that will resolve incidents and prevent their recurrence and to identify opportunities for improving the quality of work products and processes. The Root Cause Analysis will begin when there is a severe incident, a pattern of similar incidents is detected, or an increase in the number of incidents is detected over time. An incident may be a defect, problem, issue, corrective or preventive action, or change request.
The RMD will require its contractors to be active participants in the QA program. Contractors will be responsible for gathering and analyzing relevant data to help improve the effectiveness of their processes, services, or products. At a minimum, contractor QA activities will consist of identifying processes/tasks to be monitored, creating quality standards, establishing metrics to measure progress, tracking and trending of processes/tasks, analyzing actions needed, recording results of action taken, participating in the RMD's QA activities and Project Management Reviews, and capturing lessons learned.
Our communications plan will be based on a continual, open dialogue with stakeholders. The first step in developing an effective plan will be to determine the relevant stakeholders. For the RM Transition, many stakeholders will come from the IT, RM, and Department of Justice communities. Among others, the IT community stakeholders will include the EA Unit, EA Program Management Office, and Enterprise Security Architecture Unit Information Assurance Section (ESAU/IA). The RM community stakeholders will include NARA. The Department of Justice stakeholder community will include the Drug Enforcement Agency and other agencies that have a vested interest in the Bureau's records management. Once the stakeholders have been determined, the communication plan can be structured to meet the needs of different groups. The plan will include conducting routine status meetings, submitting Monthly Progress Reports, and briefing any output from the QAP. The RMD will also share with stakeholders the results of any surveys, Project Change Requests, After Action Learning sessions, process reviews, and follow-up actions from management reviews. In addition, we will document and share with stakeholders any work products relating to project objectives, planning, monitoring, and control; financial and risk management; issue and action management; root cause analysis; deliverable management; measurement and analysis; and project close-out.
Process Management is a Key Support Process in the FBI's IT LCM. The LCM defines Process Management as the development, documentation, evaluation, and modification of standardized processes to facilitate quality improvements and efficiency through the institutionalization of lessons-learned. During the RM Transition, there will be three broad sources of modifications of standardized processes. The first source will be modifications to the internal transition processes. The second source will be modifications to existing standard operational processes that must occur as a direct result of the RM transition. The third source will be modifications that occur independently of the transition (e.g., as a result of on-going process improvement initiatives) within the operational and administrative units of the Bureau. The three sources require different management strategies.
These changes will primarily be an outcome of QA initiatives. For example, the project team may identify opportunities for improving the quality of work products and processes as a result of Root Cause Analyses. The strategy for managing these changes will be a natural extension of some of the previously defined elements of the QA Strategy.
- Change Management Process. We will define the process for documenting, analyzing, and approving changes. In those instances where modification of a process is approved, the change management aspects of the QA Plan will be extended until implementation and measurement of the modified process has been completed.
- Issue and Action Management. The same process for documenting, classifying, and tracking issues and actions that affect transition will be applied to modified processes until implementation and measurement of the modified process has been completed.
- Project Change Requests. As part of the QA review for every contract modification that adds scope or funding to the project, the RMD will determine what, if any, process management actions are necessary.
- Contractor Participation. As described in the QA Strategy, contractors will be responsible for analyzing relevant data to help improve the effectiveness of their processes, services, or products. When a process modification occurs as a result of these initiatives, the contractor will be required to monitor the modified process, create quality standards, and establish metrics to measure progress.
The transition will undoubtedly create opportunities and needs for modifications to existing operational processes. Effectively executing the communications plan will be the key to identifying and managing these changes. The changes will be identified through the regular, on-going dialogue with stakeholders. Routine status meetings and briefing will create a forum for identifying and discussing the potential impacts of changes. These discussions will be included as an agenda item during these status meetings and briefings. Surveys, Project Change Requests, After Action Learning sessions, process reviews, and management reviews will also provide mechanisms for identifying potential changes and associated impacts. Our communication plan will include outreach to operational and administrative units to encourage their participation. When warranted, separate working groups can be established to further define, plan, and implement the required changes.
We also recognize that change can occur from continuous improvement initiatives, redesigned processes, and external developments. These changes are one of the most common causes of potential problem areas. By aggressively monitoring changes and identifying new potential problem areas, we will reduce the chance that these potential problem areas become actual problem areas. Whatever the source of the change, the transition team will be on the lookout for potential problems. While every transition team member will be encouraged to be a "change" analyst, we will ensure the team has experienced change analysts to help facilitate the change management process.
The Configuration Management (CM) strategy will be based on the relevant procedures described in the LCM.7 The LCM is designed to move an idea from concept to resulting capabilities using a methodical process. As decisions are reached, the information should be baselined to support follow-on efforts. Maintaining baselines allows the program to move in a methodical manner from one lifecycle phase to the next. Each baseline is linked to information/decisions from the prior baseline. By establishing, managing, and linking baselines, organizations can move back in the lifecycle to analyze the impact of issues and implement changes to baselines to resolve problems before moving forward.
The CM strategy for the RM transition will be executed by developing and implementing a detailed CM Plan. The Plan will identify items placed under configuration control, describe the approach to defining and managing project baselines, and include management and control of hardware, software, interfaces, data, procedures, and facilities. The Plan will describe the methods for controlling, tracking, implementing, and reporting changes and describe the configuration status accounting procedures for maintaining baselines. The Plan will also describe system and document identification conventions. The LCM specifies that the CM Plan should include the following sections.
- Scope. Includes an Identification paragraph that defines the purpose of the document, provides a description of the plan's major features and objectives, and provides a concise summary of the approach toward implementing CM. Also provides a System Overview that briefly states the purpose of the system and a Document Overview that summarizes the purpose and contents of the document and describes any security or privacy considerations. This section should also describe the relationship of the CM Plan to other project management plans.
- Reference Documents.Lists the number, title, revision, and date of all documents referenced in the plan. Identifies the source for all documents not available through normal Government channels.
- Organization. Describes the organization with emphasis on the CM activities. Includes the CM responsibility/authority of all participating groups and their role in configuration control boards. Includes integration of CM functions with other program activities. Includes identification of the CM organization/responsibilities and interfaces with the Government, subcontractors, and contractors.
- Configuration Management Phasing and Milestones. Describes the events and milestones for CM implementation. Includes release and submission of configuration documentation, establishment of baselines, implementation of configuration control, establishment of configuration control boards, implementation of a status accounting information system, provision of reports, and conduct of configuration audits.
- Configuration Identification. Describes the procedures for identifying and selecting configuration items; managing developmental configuration including document, drawing, and software development libraries; managing corrective action process; and establishing baselines. Includes definition of the required configuration documentation, illustration of configuration documentation relationships, and assignment and application of configuration identifiers including document numbers, nomenclature, serial numbers, hardware, and software.
- Interface Management. Describes the procedures for identifying interface requirements and establishing interface agreements.
- Configuration Control. Describes configuration control procedures including functions and authority of control boards. Describes authority level for change approval/concurrence and processing of Engineering Change Proposals, Requests for Deviations/Waivers, and Specification Change Notices.
- Configuration Status Accounting. Describes procedures for collecting, recording, processing and maintaining data necessary to provide status accounting information. Also describes reports related to identification of current approved configuration documentation and configuration identifiers associated with each Configuration Item (CI). Describes status of proposed engineering changes, results of configuration audits, status and disposition of discrepancies, status of requests for critical and major deviations and waivers, traceability of changes from baselined documentation, and status of configuration changes.
- Configuration Audits. Describes the approach to supporting configuration audits including plans, procedures, documentation, and schedules for functional and physical configuration audits. Describes format for reporting results of in-process configuration audits.
- Subcontractor/Vendor Control. Describes the methods used by contractors to ensure subcontractor and vendor compliance with configuration management requirements.
Milestones include the reviews and deliverables specified in the LCM. Interim milestones for each of the Streams will be developed as part of the more detailed planning for each Stream. Drivers for the transition planning include progress of the overall EA effort, budgeting, and mission priorities.
The table below presents the management and technical reviews to be conducted during the transition. For each review, we specify the organization responsible for conducting the review, concurring with the results of the review, and approving the results of the review. The RMD will participate in all reviews. The Stream 2 (ERKC Applications) transition will require the Critical Design, Deployment Readiness, System Test Readiness, and Operational Acceptance reviews for each certified system/application. The Stream 1 (RMA Integrated Applications) transition will also require those reviews during each iteration and may require multiple reviews within each iteration.
|System Concept||Approve recommended System Concept of Operations.||EAB (R)
|Acquisition Plan||Approve the System Specifications and Interface Control documents and the approach and resources required to acquire the system as defined in the acquisition plan.||CRB (R)
|Critical Design||Approve the build-to and code-to documentation and associated draft verification procedures. Ensure that the design can be produced and is expected to meet its design-to specifications at verification.||EAB (R)
|Deployment Readiness||Approve the readiness of the system for deployment in the operational environment.||TRB (R)
|System Test Readiness||Verify readiness to perform official system-wide data gathering verification test for acceptance.||TRB (R)
|Operational Acceptance||Approve overall system and product validation by obtaining customer acceptance and determining whether the O&M organization agrees to, and has the ability to, support continuous operations of the system.||IMPRB, O&M (R)|
*R= conducting the review, C=concurring with the results of the review, and A=approving the results of the review.
The figure below illustrates the timing of the reviews with respect to the LCM phases. The reviews generally occur at the end of a phase of the LCM.
The table below presents the deliverables, by LCM Review, to be produced during the transition.
|Control Gate 1 - System Concept Review|
|Business Plan||Final||Demonstrate to the approving officials that the project is a unique, worthwhile investment of FBI funds that will assist the FBI in accomplishing its mission.||Concept Exploration|
|Concept of Operations||Final||Baselines the user requirements for the project and describes the user Concept of Operations that was used to support the identification and definition of these user requirements.||Concept Exploration|
|Risk Assessment||Preliminary||Aids in identifying risks; analyzes their impact and prioritizes them; tracks risks and the implementation of mitigation plans; supports informed, timely, and effective decisions to control risks and mitigation plans; and assures that risk information is communicated and documented.||Concept Exploration|
|Control Gate 2 - Acquisition Plan Review|
|System Specification||Final, baselined||Defines the procurement requirements for a system and the methods to be used to ensure that each requirement has been met.||Acquisition Planning|
|Test and Evaluation Master Plan||Final, baselined||Describes plans for the verification of configuration items, segments, sub- systems, and systems. Describes the test environment to be used for verification, identifies the tests to be performed, and provides schedules for verification activities.||Acquisition Planning|
|Project Plan||Final||First plan for the project. Defines the project and obtains the necessary management support and resources to implement it. Describes the need and includes how the project contributes to the Bureau's mission. Provides initial cost and time estimates and describes the general approach to be implemented during the Study, Acquisition, and Operations Periods of the project lifecycle. Provides detailed planning information for completing the Study Period.||Requirements Development|
|Acquisition Strategy||Final||Describes the expected approach to be used in acquiring and deploying a specific system or services. Defines the acquisition approach including funding, staffing levels, and facilities that will be required.||Acquisition Planning|
|Bidders List||Final||Comprised of those companies judged capable by the Government to submit bids, proposals, or quotations. Developed and maintained by the procuring organization. It is not released to interested bidders as it may contain relevant, proprietary information about the bidder.||Acquisition Planning|
|Reqs. Traceability Matrix (RTM)||Level 2||Traces the allocation of system and interface requirements to the following locations:
- To allocated sub-system, configuration items, and interface requirements specifications
- To hardware, software, components, and manual operations which implement the functions
- To the configuration, sub-system, and system test procedures and test results which verify the satisfaction of the requirements
|QA Plan||Final, baselined||Describes an independent program to ensure that prescribed standards and requirements are met. Contains procedures for detection, reporting, analysis, and correction of deficiencies.||Acquisition Planning|
|CM Plan||Final, baselined||Describes the configuration management approach to manage the business and technical baselines of the project. Includes management and control of hardware, software, interfaces, data, procedures, and facilities for the project.||Acquisition Planning|
|Interface Control Document (ICD)||Preliminary||Requirements agreement between two or more participants within a system, or between systems. Specifies the requirements and/or design definitions of system interfaces affecting two or more systems, two or more segments, or multiple contractors within a project. Establishes the specifications and system requirements associated with the equipment, software, operations, or services affecting the involved systems or segments.||Requirements Development|
|System Design Document||Preliminary||Describes the design of a Computer Software Configuration Item (CSCI). Describes CSCI-wide design decisions, the CSCI architectural design, and the detailed design needed to implement the software.||Acquisition Planning|
|Software Product Specification||Preliminary||Contains or references the executable software, source files, and software support information, including "as built" design information and compilation, build, and modification procedures for a CSCI.||Requirements Development|
|Software Development Plan||Preliminary||Describes a developer's plans for conducting a software development effort. The term "software development" is meant to include new development, modification, reuse, reengineering, maintenance, and all other activities resulting in software products. Provides a tool for monitoring the processes, methods, and approach for each activity and monitoring project schedules, organization, and resources.||Acquisition Planning|
|Risk Assessment||Updated||Same as preliminary under Gate 1.||Acquisition Planning|
|Control Gate 3 - Critical Design Review|
|Systems Design Document||Final, baselined||Same as preliminary under Gate 2.||Design|
|Interface Design Document||Final, baselined||Describes the interface characteristics of one or more systems, sub-systems, Hardware Configuration Items, CSCIs, manual operations, or other components. It may describe any number of interfaces.||Design|
|O&M Design Document||Final, baselined||Describes design decisions that affect the support environment and activities that will be used by the system during the Operations Period of the project's lifecycle. Assists with development of a detailed cost estimate for the recurring operations and maintenance cost of the system after its deployment into the operational environment.||Design|
|Security Plan||Final, baselined||Describes how security requirements will be built into the design.||Design|
|RTM||Level 4||As defined in the Document Requirements Description of the IT LCMD.||Design|
|Critical Performance Measures||Preliminary||Provides a tracking and reporting mechanism to ensure that critical performance requirements of a system, sub-system, or configuration item are properly identified, allocated, budgeted, estimated, and measured throughout the development activity.||Design|
|Software Development Plan||Final||Same as preliminary under Gate 2.||Design|
|Software Product Specification||Final, baselined||Same as preliminary under Gate 2.||Design|
|Interface Control Document||Final, baselined||Same as preliminary under Gate 2.||Design|
|Installation Plan||Final||Plan for installing the system at user sites, including preparations, installation procedures, interconnections with existing systems, and conversion of data from legacy systems.||Develop and Test|
|Test Procedures||Final, baselined||Describes the test preparations and test procedures to be used to perform during verification of configuration items, segment/sub-systems, and systems.||Design|
|Risk Assessment||Updated||Same as preliminary under Gate 1.||Design|
|Control Gate 4 - Deployment Readiness Review|
|Critical Performance Measures||Updated||Same as preliminary under Gate 3.||Develop and Test|
|Training Plan||Final||Defines and evaluates the program that will be implemented to train personnel on the operations and maintenance of the system.||Develop and Test|
|Version Description Document||Final, baselined||Identifies and describes a software version consisting of one or more CSCIs. Used to release, track, and control software versions.||Develop and Test|
|Test Reports||Final||Record of the verification testing performed on systems, segments/subsystems, and configuration items.||Develop and Test|
|Training Materials||Preliminary||Materials developed to train personnel on the use, operations, and maintenance of the system.||Develop and Test|
|Technical Manual||Preliminary||Provides detailed technical information and procedure for the setup, operation, and maintenance of the equipment by trained technicians.||Develop and Test|
|User Manual||Preliminary||Provides detailed information for hardware and software that is run by the user and has a user interface requiring on-line user setup, input, or interpretation to displayed output.||Develop and Test|
|Sys. Ops. & Maint. Manual||Preliminary||Provides detailed information for hardware and software that is run by personnel in a computer center or other centralized networked operations center.||Develop and Test|
|Risk Assessment||Updated||Same as preliminary under Gate 1.||Develop and Test|
|Control Gate 5 - System Test Readiness Review|
|Test Reports||Final||Same as preliminary under Gate 4.||Implementation and Integration|
|Transition Plan||Final||Provides high-level planning information required to transition a system into operations at one or more sites. This document is useful when coordination is required for the transition of system into numerous sites, or when the transition of the system will be through an incremental development strategy.||Implementation and Integration|
|Training Materials||Final||Same as preliminary under Gate 4.||Implementation and Integration|
|Technical Manual||Final, baselined||Same as preliminary under Gate 4.||Implementation and Integration|
|User Manual||Final, baselined||Same as preliminary under Gate 4.||Implementation and Integration|
|Sys. Ops. & Maint. Manual||Final, baselined||Same as preliminary under Gate 4.||Implementation and Integration|
|Software Installation Manual||Final, baselined||Provides detailed instructions for the installation of software on a system, sub-system or configuration item.||Implementation and Integration|
|Critical Performance Measures||Updated||Same as preliminary under Gate 3.||Implementation and Integration|
|Risk Assessment||Updated||Same as preliminary under Gate 1.||Implementation and Integration|
|Control Gate 6 - Operational Acceptance Review|
|Operational Readiness Report||Final||Provides a record of the validation testing that was performed on the system in an operational environment during a controlled Operational Readiness Exercise time period.||Implementation and Integration|
|Critical Performance Measures||Updated||Same as preliminary under Gate 3.||Implementation and Integration|
|Risk Assessment||Updated||Same as preliminary under Gate 1.||Implementation and Integration|
Inputs, Outputs, and Exit Criteria
The inputs, outputs, and exit criteria for the Phases of the LCM are presented in the table below. Entry criteria must be satisfied before the review is conducted, and exit criteria must be satisfied before successfully concluding the review.
|LCM Phase||Inputs||Outputs||Exit Criteria|
§1 Statement of Need
§2 Lessons learned from other programs
§3 Initial risk assessment
§4 Proposed business plan
§5 Final CONOPS
|System Concept Control Gate approval|
§6 Formalized business plan
§7 Concept of Operations
§8 Legacy programming data and doc.
§9 Risk assessment and lessons learned
§10 Approved Project Plan
§11 Updated risk assessment
§12 Asset library
§13 Preliminary ICDs
§14 Preliminary System Specification
§15 Preliminary QA and CM Plans
§16 Preliminary Software Product Spec.
§17 Privacy Impact Assessment
§18 Approved documentation
§19 Project plan
§20 Preliminary System Specification
§21 Preliminary QA and CM Plans
§22 Preliminary ICDs
§23 Preliminary Software Product Spec.
§24 Risk assessment and lessons learned
§26 Acquisition strategy
§27 Bidders list
§28 Test & Evaluation Master Plan
§29 Final System Specification
§30 Prelim. Software Development Plan
§31 Prelim. Sys. Design Document
§32 Level 2 Reqs. Traceability Matrix
§33 Final QA and CM Plans
§34 Updated risk assessment
§35 Acquisition Plan Review Control Gate approval
§36 Acquisition strategy
§37 Bidders list
§38 Approved doc. from prior phases
§39 Risk assessment and lessons learned
§40 Contractual documentation
§41 Updated risk assessment
§43 Contract award to selected vendor
§44 Approved doc. from prior phases
§45 Prelim. Software Development Plan
§46 Prelim. Systems Design Document
§47 Prelim. Software Product Specification
§48 Preliminary ICDs
§49 Risk assessment and lessons learned
§50 Final Software Development Plan
§51 Final Systems Design Document
§52 Level 4 Reqs. Traceability Matrix
§53 Final ICDs
§54 Final Software Product Specification
§55 Interface Design Document
§56 Ops & Maint. Design Document
§57 Prelim. Critical Perform. Measures
§58 Security Plan
§59 Test Procedures
§60 Updated risk assessment
§61 Critical Design Review Control Gate approval
|Develop and Test||
§62 Approved doc. from prior phases
§63 Critical performance measures
§64 Risk assessment and lessons learned
§67 Installation Plan
§68 Training Plan & Prelim. Trng. Materials
§69 Version Description Document
§70 Test Reports
§71 Preliminary Transition Plan
§72 Preliminary Tech. & User Manuals
§73 Prelim. Sys. Ops & Maint. Manual
§74 Prelim. Software Installation Manual
§75 Updated risk assessment
§76 Updated Critical Perform. Measures
§77 Deployment Readiness Review Control Gate approval
|Implement and Integrate||
§78 Approved doc. from prior phases
§79 Prelim. Transition Plan
§80 Prelim. Training Materials
§81 Prelim. Tech. & User Manuals
§82 Prelim. Sys. Ops. & Maint. Manual
§83 Prelim. Software Installation Manual
§84 Critical performance measures
§85 Risk assessment and lessons learned
§87 Final Transition Plan
§88 Final Training Materials
§89 Final Tech. & User Manuals
§90 Final Sys. Ops. & Maint. Manual
§91 Final Software Installation Manual
§92 System Test Procedures, Test Reports
§93 Operational Readiness Report Products
§94 Updated Critical Perform. Measures
§95 Updated risk assessment
§96 System Test Readiness Review Control Gate approval
§97 Operational Acceptance Review Control Gate approval
§99 Approved doc. from prior phases
§100 Approved products
§101 Risk assessment and lessons learned
§102 Deactivation Plan
§103 Approved product modifications
§104 Updated risk assessment
§105 Disposal Review Control Gate approval
Gap analysis is a technique used to compare the current state of an activity within an organization with a desired end state. Analyzing the gaps between the current state and the desired state can provide high-level direction to guide the Bureau's transition strategy and to identify and prioritize transition activities. Gap analysis also helps scope the magnitude of required changes (e.g., number of applications that require integration).
We have organized this high-level gap analysis by the RM Lifecycle Phases. In the tables below, we provide a description of the Current State and Target State for each phase of the lifecycle and provide comments on the actions necessary to close the gap.
|Current State||Target State|
|Few systems within the FBI that generate records provide for the capability to designate information as records (either manually or automatically) and adequate records are declared and captured at most locations.||All FBI systems that produce records have the ability to declare a document a record. All records and recordkeeping systems integrate with an enterprise RMA that provides lifecycle management of the Bureau's records.|
|Recordkeeping processes vary by field office and when dealing with electronic records and desktop applications, FBI records often are not properly declared and managed. Because of the many different applications, media, formats, and locations, recordkeeping processes are not well defined nor consistently applied throughout the organization.||Recordkeeping processes are well defined and consistent throughout the organization.|
|Many IT systems produce records but only one has been certified under the Electronic Recordkeeping Certification (ERKC) process.||All systems/applications that are not fully integrated with the RMA are certified under the ERKC process.|
|Record metadata are not generally captured automatically nor linked to the associated record.||At the time of creation, a record's metadata is captured either manually or automatically and stored in a metadata repository. Records declaration and metadata capture are as automatic and as transparent to the user as possible.|
The RMD can help transition from inconsistent to consistent processes through continued education. FBI newsletters and other communication vehicles can be used to highlight success stories and available resources. RM policies, articles of interest, and updates can be posted on the FBI intranet site for organization-wide reading. Additionally, continuing the effort for more centralized storage and management of paper records will aid in the transition to more consistent and well-defined processes.
The key driver in the transition from the current state to the desired target enterprise RM system will be the successful capture of required metadata. At the time a document becomes a record, the enterprise RMA or native system/application must capture key record metadata elements. The RMA will use the metadata to manage the records throughout their lifecycle. Metadata capture requirements need to be incorporated during the requirements phase of the IT LCM program for all new or legacy applications.
To reach the desired metadata capture state, the RMD must finalize all metadata requirements, including the records classification/index scheme, and then acquire, integrate, and implement an RMA with required metadata capture capabilities. The RMA must be able to integrate with major applications/systems being used within the FBI. The RMD must continue stakeholder communication, secure stakeholder agreement on the RM EA integration and Transition Strategy, and begin executing the Transition Strategy.
|Current State||Target State|
|In general, FBI personnel adequately maintain and use records across the organization. Employees are able to find the records they need. However, this can require a substantial amount of time and effort, processes can vary based on location within the organization, and there is no way to confirm if all relevant records were located.||A centralized enterprise-wide electronic recordkeeping system, enabled by the RMA, provides storage, access, and management of the FBI's records, regardless of format, media, source, or location. Using the RMA search capability, employees are able to locate and have immediate access to records at their desktop.|
|Maintaining the FBI's paper-based record system is costly and inefficient. In addition, the decentralized, stove-piped maintenance processes and systems can cause significant delays in records processing and retrieval, make internal and external information sharing difficult, and impede the ability of employees to do work. This environment has made complex electronic records even more difficult to organize and access.||The RMA enabled by a metadata repository will allow users to search, cross-index, and locate information without accessing the legacy applications. Records from the content repository can be sent to the users desktop. The RMA and metadata repository will also support the FBI's DocLab paper records conversion projects and enable the ordering of documents in both paper and electronic form from the FBI's Paper Repository. By capturing required metadata, all documentation that may be created or received through the FBI's investigative or business processes can be electronically managed in an efficient, legally acceptable manner, while safeguarding privacy and other sensitive information.|
|The FBI has several systems that contain electronic records, but none of these systems meet the National Archives and Records Administration's (NARA) standards for an electronic recordkeeping system. Only the paper-based system has been approved by NARA. Thus, the FBI must maintain tens of millions of paper files. These papers are maintained and stored at 265 different locations including FBI Headquarters, field offices, large resident agencies, some Legal Attaché offices, Investigative Technology Centers, and various other off-site locations.||All FBI records are managed by the RMA. Records from ERKC applications are stored within their native systems. Paper records are maintained and stored in a centrally located paper records repository. The RMA, ERKC systems, and Paper Repository meet NARA recordkeeping standards.|
The key to transitioning to the desired centralized enterprise RM system will be the effective acquisition, design, and implementation of the RMA. The RMA implementation must go through the IT LCM process. In addition, the transition will depend upon the design and integration of the RMA's capabilities, content repository, and metadata repository. A phased integration of current record producing applications/systems with the RMA should be planned and executed.
RM requirements must be considered during the LCM process for new IT systems. Otherwise, expensive and timely modifications may have to be made to systems to meet the stated RM requirements. The RMD personnel play an important role in this process. The focus of RM personnel needs to shift towards advocacy, training, promulgation and monitoring of policy, and facilitating the inclusion of RM requirements during the LCM of new systems. It is important to ensure that electronic RM requirements and RMA integration are recognized in determining the functional requirements for new or upgraded systems. By giving records management a higher priority in the design and development of information systems, many of the problems seen in existing systems can be prevented from developing in the first place. Functional requirements can be built into the design and implementation of electronic systems more easily (and less expensively) than maintenance changes. Where new systems or modifications to existing systems are planned, there is an excellent opportunity to influence the requirements specification and design in ways that enable effective RM in the future. The RMD should continue active participation on the Enterprise Architecture Board, Solution Architects Working Group, and other communication forums to elevate RM issues.
|Current State||Target State|
|Records disposition depends on manual processes from FBI employees because most FBI systems that generate records are not capable of identifying records eligible for transfer or destruction based on records retention schedules and disposition instructions.||Disposition dates for records are calculated and captured automatically.|
|Some permanent paper and electronic records within the FBI are not transferred to NARA to be archived. In most of these cases, the records are not transferred because they are not scheduled. Lack of clearly defined and enforced processes leads to some significant FBI records, and most electronic records, remaining unscheduled. Since proper disposition depends on accurate scheduling, many of these records are not disposed of properly.||The RMD is notified by the RMA that paper or electronic record is due for disposition review. Paper or electronic record is determined by the RMD authority to be destroyed or sent to NARA for permanent storage.|
|There are no enterprise-wide capabilities to export records and metadata in a format acceptable to NARA or to maintain a record of all transfers and destructions.||Records are appropriately destroyed or transferred to NARA in an acceptable format. The RMA maintains a record of all transfers and destructions and provides certifiable proof of transfer or destruction.|
The key to closing the gap in the disposition phase will be to finalize the classification/index scheme to enable capturing the record type in the required metadata. The RMA can be programmed to automatically calculate disposition dates based on the metadata captured. In addition, the RMA can notify the RMD when a record is nearing its scheduled disposition date. Again, metadata capture will be the driver of this functional capability. In addition, NARA transfer requirements must be included in the RMA design phase.
|ConOps||Concept of Operations|
|CMB||Change Management Board|
|CRB||Contract Review Board|
|CSCI||Computer Software Configuration Item|
|EAB||Enterprise Architecture Board|
|ERKC||Electronic Recordkeeping Certification|
|ESAU/IA||Enterprise Security Architecture Unit / Information Assurance Section|
|FBI||Federal Bureau of Investigation|
|ICD||Interface Control Document|
|IMPRB||Investment Management/Project Review Board|
|LCM||Life Cycle Management|
|LCMD||Life Cycle Management Directive|
|O&M||Operations and Maintenance|
|OIPP||Office of IT Policy and Planning|
|QAP||Quality Assurance Plan|
|RAS||Records Automation Section|
|RMA||Records Management Application|
|RMD||Records Management Division|
|RTM||Requirements Traceability Matrix|
|TRB||Technical Review Board|
|WBS||Work Breakdown Structure|
Appendix D: Glossary of Terms8
Configuration Management. The discipline of identifying the configuration of a hardware/software system at each lifecycle phase for the purpose of controlling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the entire lifecycle.d
Enterprise Architecture. A strategic information asset base, which defines the mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs. An enterprise architecture includes a baseline architecture, target architecture, and a sequencing plan.c
Metadata. Data describing stored data: that is, data describing the structure, data elements, interrelationships, and other characteristics of electronic records.b
Process Management. The set of activities, methods, and tools applied to the definition, implementation, and monitoring of a process.d
Quality Assurance. A planned and systematic means for assuring management that defined standards, practices, procedures, and methods of the process are applied.d
Records. All books, papers, maps, photographs, machine-readable materials, or other documentary materials, regardless of physical form or characteristics, made or received by an agency of the United States Government under Federal law or in connection with the transaction of public business and preserved or appropriate for preservation by that agency or its legitimate successor as evidence of the organization, functions, policies, decisions, procedures, operations, or other activities of the Government or because of the informational value of the data in them.a
Records Management. The planning, controlling, directing, organizing, training, promoting, and other managerial activities involved with respect to records creation, records maintenance and use, and records disposition in order to achieve adequate and proper documentation of the policies and transactions of the Federal Government and effective and economical management of agency operations.a
Records Management Application. Software used by an organization to mange records. An RMA's primary management functions are categorizing and locating records and identifying records due for disposition. RMA software also stores, retrieves, and disposes of electronic records stored in its repository.b
Risk Management. The systematic application of policies, procedures, methods, and practices to the task of identifying, analyzing, evaluating, tracking, and monitoring risk.d
Service Domain. The collection of business oriented service categories that align service/component capabilities to a level in which they support the objectives and performance of the business components.c
1 Reference the Business Concept of Operations, December 20, 2004, andSystem Concept of Operations, January 3, 2005, for a more detailed discussion of the conceptual model underlying the three sources of records described in Sections 1.1 - 1.3 of this document.
2FBI Information Technology Life Cycle Management Directive (IT LCMD), Version 2.0, November 19, 2004, Appendix A, page A-3.
3 ReferenceEA Integration, January 10, 2004, pp. 12-16 for a mapping of RMA capabilities to Target EA Service Domains and Service Types.
4FBI Electronic Recordkeeping Certification Manual Version 1.0, prepared by SRA International, Inc., April 30, 2004.
5FBI Information Technology Life Cycle Management Directive (IT LCMD), Version 2.0, November 19, 2004, Appendix E, p. E-63.
6 The existing paper-based system would be available if the system development fails. However, because of the importance of having access to timely, accurate information for FBI mission accomplishment, the RAS believes a higher risk value is warranted.
7FBI Information Technology Life Cycle Management Directive (IT LCMD), Version 2.0, November 19, 2004, Appendix E.
8 These definitions were taken directly from the following sources.
a. Title 44, United States Code, Section 3301.
b. Design Criteria Standard for Electronic Records Management Software Applications,Department of Defense, DoD 5015.2-STD, June 19, 2002.
c. Enterprise Architecture Integrated Baseline Architecture Report, Federal Bureau of Investigation, Version 2.0, Appendix A, December 13, 2004.
d. FBI Information Technology Life Cycle Management Directive (IT LCMD), Federal Bureau of Investigation, Version 2.0, November 19, 2004.