A Methodology for Evaluating Existing Information Systems As Recordkeeping

Systems – 2002 Version

The Indiana University Electronic Records Project

INTRODUCTION
In using this methodology it is important to recognize the collaboration between archivists
and the IT community, whose vocabularies at times do not quite match. This methodology
is centered around archival and recordkeeping concepts, but facilitated by practices
common to the IT community. Perhaps the language is most at odds with the term record.
In the IT context a record might be thought of as a data structure representing an element
of a file. However, in the context of this methodology, a record is evidence of a business
transaction. An understanding of this usage of record is essential for success with the
methodology, as is an understanding of other terms (which can be found in the glossary
and throughout the text) and of the Functional Requirements and Metadata Specifications
(also in the appendix and discussed later in the text). In general, the focus here is on
information as it satisfies requirements of authenticity and evidence.
Several phases and tasks for the methodology have been identified. Involvement in the
information system’s design stage makes the process much easier to implement. In most
cases, designing a new system involves incorporating your requirements or specifications
and the results of your business process models into the design of the new system. A
methodology for analysis of new systems is outlined in a separate document. Analysis of
existing systems is normally a more time consuming, more difficult process. It involves
not only specifying requirements and metadata specifications and a list of records to be
captured. It also requires an analysis of how the present system is managing the data. In
essence, the process involves analysis of “what is” as depicted by models and system
documentation with “what should be” as defined by the requirements, specifications and
models. More specifically, analysis of existing systems includes the following activities:
1) a description and analysis of the business processes by means of a technique known as
“modern structured analysis,” 2) a description of how the information system is presently
managing records of the identified processes, 3) an evaluation of the information system
against the Functional Requirements and Metadata Specifications in the context of the
identified business processes, and 4) recommendations for intervention to satisfy the
Functional Requirements and Metadata Specifications.

Although represented in the text as distinct phases, the reality is that thought processes
don't necessarily work in a step-by-step fashion. A methodology may portray a progression
through specific steps, but a person using the methodology should be able to consider
multiple factors at any point through that progression. The entire methodology document
and supporting materials should be reviewed and understood before proceeding with its
use.

1
Step 1: DESCRIBING AND MODELING BUSINESS PROCESSES
In this initial step of the methodology, the primary goal is to construct a representation of
the logical processes of the business, i.e., to create a conceptual model of the work or
activities that must be undertaken no matter how the information system is implemented or
who does the work. To identify these processes, the methodology uses concepts derived
from "modern structured analysis" techniques such as those advocated by Stephen
McMenamin, John Palmer, and Edward Yourdan. This form of analysis has been defined
as “a process-centered technique that is used to model business requirements for a system.
The models are structured pictures that illustrate the processes, inputs, outputs, and files
required to respond to business events.” [Jeffrey L. Whitten and Lonnie D. Bentley,
Systems Analysis and Design Methods, 4th ed. (Boston: McGraw-Hill, 1998), p. 122.
Description of the business requirements is undertaken by means of a process known as
decomposition . This process is a means of developing a top-down analysis of the
business system, and of breaking down the business system into smaller and smaller
processes and sub-processes. In accordance with “modern structured analysis”
techniques, the IU methodology decomposes logical processes (business activities that
must be undertaken no matter how one implements the system) into three components:
Functions, Event Processes or Transactions, and Elementary Processes. In other
words, business systems are comprised of functions, which are decomposed into business
processes, which ultimately are reduced to business events, which normally represent a
single process responding to external and temporal inputs and result in one or more
outputs known as elementary processes.
In the decomposition process, the activities at the highest end of the business system are
known as business functions. A function is a “set of related and on-going activities of the
business. A function has no start or end; it just continuously performs its work as needed.”
(Whitten and Bentley, Systems Analysis and Design Methods, p. 218). Functions normally
are decomposed into sub-functions or into a more discrete and related set of on-going
activities. Functions are named with nouns that describe the entire set of activities.
Examples of functions and sub-functions from the business area of Office of the Registrar
include: Function: Student Recordkeeping - Subfunctions: Official student record
maintenance, student degree maintenance, current semester information maintenance.
Functions consist of business processes that respond to business events. A business event
is “something that ‘happens,’ and that causes business data to change.” Whitten and
Bentley, Systems Analysis and Design Methods, 3rd ed., p. 524). An event “is a logical unit
of work that must be completed as a whole. An event is triggered by a discrete input and
is completed when the process has responded with appropriate outputs. Events are
sometimes called transactions.” (Whitten and Bentley, Systems Analysis and Design
Methods, p. 218). There are three basic types of inputs that will trigger a business event
or transaction: an external event that is initiated by agents outside the system being
reviewed, a temporal event that is triggered by the arrival of a predetermined point in
time, and a state event that is triggered by a system’s change from one state or condition
to another. Most events or transactions are represented by a single process, although
occasionally, the event may include two or three processes. An event process or
transaction is described in a single sentence that identifies the individual or agency
initiating the action (subject-phrase); the official action (verb-phrase); and the individuals
2
or objects acted upon or interacted with (object-phrases). Examples of event processes or
transactions taken from the Office of the Registrar work area include: For Subfunction:
Student grades and credit maintenance, the event processes or transactions include: 1)
Post grades for students upon completion of course work (Input: grade roster from faculty
member, and Output: Create a grade and credit record); 2) Assign credit for student work
done at other academic institutions (Input: Record of work completed at another
institution, and Outputs: Create a credit articulation or evaluation report, and modify
student record to reflect the decision).
An event process is further decomposed into elementary processes, which are defined as
“discrete, detailed activities or tasks required to complete the response to an event.”
(Whitten and Bentley, Systems Analysis and Design Methods, 4th ed., p. 219.) In other
words, elementary processes are the outputs generated by the business event. Types of
elementary processes include: creating a new occurrence of an entity (add), updating an
occurrence of an entity (change or modify), and deleting an occurrence of an entity. The
methodology omits any processes that do nothing more than move or route data, thus
leaving the record unchanged. Elementary processes are named with a strong action verb
followed by an object clause that describes the work being performed. Examples of
elementary processes from the Financial Aid work area include: Create report listing
federal aid recipients with unsatisfactory academic progress, record appeal information in
student’s financial aid record, complete work-study verification form received from
employer, and provide certification information to the lender.

Record creation occurs at the event or transaction level, and the actual records to be
analyzed are those documents received as inputs to the system and those records created
as a result of the outputs or elementary processes generated in response to the external or
temporal event. For example: The business event “processing an appeal” is initiated or
triggered by a student or his/her parents, and the input document is the appeal letter
received from the student or the parents. The outputs or elementary processes of this
event are 1) Making and recording a decision on the appeal, 2) Modifying the student’s
financial aid data based on the appeal decision, and 3) Notifying the student about the
decision. The appeal letter, the decision document, the modified student record, and the
notification are the records of the process.
Eventually all this business process information is described or depicted in models or
representations that illustrate, usually through the use of pictures or symbols, the various
components and relationships of the processes. Models designed to “depict the system
independent of any technical implementation” are known as logical models or essential
models. (Whitten and Bentley, Systems Analysis and Design Methods, 4th ed., p. 210.)
And of the logical models, it is the opinion of the Archives staff that the most valuable
models for archivists are those that focus on system processes, specifically business
function decomposition diagrams, business event diagrams, and business process data flow
models. In the IU methodology, staff normally create functional decomposition and
business event diagrams.

What types of information are contained in these models, and what do the models look
like? To answer these questions, let us review the products Archives personnel created
for the business function “Student Recordkeeping.” As a first step, business processes for
this function are defined in a short narrative statement. Eventually this information is used
3
to generate a functional decomposition diagram for the function. A partial diagram for the
function “Student Recordkeeping”contains the following information and is represented in
the following manner.

Function: Student
Recordkeeping

Sub-Function:
Semester Data
Maintenance

Event Process: Dept. Event Process: Event Process:

Modifies Course Faculty Modifies Student Modifies
Inventory. Class Schedule Course Selections

Sub-Function:
Student Record
Maintenance

Sub-Function:
Grade and Credit
Posting

Event Process: Event Process: Event Process: Event Process: Event Process:
Assign Grade for Assign Grade for Assign Grade for Assign Grade Assign Grade for
Withdrawal Completion Transfer Work Changes Other Credit

Sub-Function:
Degree Recording
Sub-Function:
Academic Profile
Maintenance Sub-Function:
Sub-Function:
Enrollment Degree Certification
Certification

Event Process:
Create Academic
Event Process: Profile Event Process: Post
Event Process: Post
Modify Academic Dept. List of Degree
Degrees From
Profile Recipients
IUCare Application

Event Process: Post Event Process: Post

Certification From Dept. Certification
IUCare Application Data

Once the functional decomposition diagram is created, staff generate descriptions of the
business event processes, including information on the inputs and the various elementary
processes or outputs. Initially this data is captured in a simple form that includes the
following categories of information for each event process: Name of process, input
4
activities, input record, output activities, and output record(s). Once this data is gathered,
staff creates business event diagrams for each of the sub-functions. For the event
processes “department modifies course inventory,” and “processing an appeal received
from a student,” the models contain the following information and are represented in the
following manner.

Business Event Diagrams - Sub-function:

Semester Information Maintenance - Event
Process: Department Modifies Course
Inventory

Updates to Course Inventory

Academic Unit

Process: Modify Course

Modification Confirmation Inventory

Inventory Updates

System Containing
Course Inventories

5
 Business Event Diagram - Sub-Function -
Financial Aid Awards - Event Process:
Processing an Appeal Received from a Student

Notification of Decision

Student
Appeal Notification Process Appeal

Record Appeal Information into Student's Record Modify Student's Record

System Containing System Containing

Student Financial Aid Student's Financial Aid
Record Record

Record Decision on Appeal into Student's Record

System Containing
Student's Financial Aid
Record

WORK STEPS:
1. Project staff selects a business area for analysis.
2. Analyst reviews existing functional decomposition models, process models or data flow
models, event diagrams or event lists, and other available documentation describing
business processes. It is particularly important to review process models created when the
system was designed.

6
3. Analyst conducts interview(s) with one or more staff from the business area to gather
information about major business functions and event processes. Again it is extremely
important to keep in mind that what we are asking staff to describe are business
requirements and not a list of implementation procedures. Initially, staff to be interviewed
should understand the responsibilities of the entire business unit for identification of
higher-level functions and events. As needed, other staff may be identified as appropriate
resources for identification of elementary processes.
Questions to be asked in every case:
** What are the major business functions and subfunctions of this business unit?
** What are the business processes undertaken to implement these functions? In other
words, what are the event processes or transactions involved in performing this function?
** What are the business events that trigger an activity and cause records to be produced?
** What are the elementary processes that are initiated in response to these events? These
processes will include: creating a new occurrence of an entity (add); updating an
occurrence of an entity (change or modify); and deleting an occurrence of an entity.
4. Analyst creates a narrative statements describing 1) the various business processes for
the function(s) under review, and 2) each event process transaction, including information
on the name of the event process, input activities, and output activities.
5.Analyst creates a functional decomposition diagram that depicts the relationships
between and among functions and business events or transactions for the function(s) under
review.
6. Analyst creates models or depictions of the business event processes, including
information on the inputs and the various elementary processes or outputs.
7. Analyst creates a list of the records that are created as products of the processes under
review.
8. Analyst compares any logical models of business processes created when the system
was designed with the business models generated during interviews with system managers
and identifies and describes any differences in the two models.
9. If there are differences in the definition of processes and records creation, the analyst
will work with record creators and data managers to reconcile difference and come to a
agreement on the products of the business processes.

WORK STEPS: TIPS

Examine functions proposed at a particular level to see if they fit within a higher
level function. Even a major business area typically has only six to twelve first-
level functions. Second-level functions typically have between three and eight
third-level functions. (Low numbers are very common.)
Be as comprehensive and complete as possible. Assure that the list adequately
accounts for all major activities of the area. An outline form is appropriate for
representing the relationships between functions and sub-functions. As with an
7
outline, balance is expected but not symmetry. Functions at the same level should
have roughly the same significance, complexity, etc. However, one second-level
function may have two or three third-level functions while others may have eight
or nine.
Without experience it is difficult to tell when the functional decomposition is
complete. The function list should be reasonably complete, but will not be
exhaustive. In general a third-level decomposition should be sufficient, but it may
be necessary to go further to gain enough detail for the identification of
transactions in the next task.

REQUIRED MATERIALS:
1. Functional Decomposition models, Process models, or other descriptions of the
business requirements.
2. Other documentation that depicts or models the business requirements, such as Event
lists, Event-Response models, and Data Flow models.

DELIVERABLES:
1. Decomposition descriptions and diagrams of business functions, event processes or
transactions, and elementary processes currently being undertaken.
2. Lists of the records that are being produced by the elementary processes.
3. If required, descriptions or depictions of how the current business processes differ from
the set of business requirements created in the systems design stage.
4. If required, a description of how differences in the analysis of business processes were
resolved.

ROLES AND RESPONSIBILITIES:

Conducted by: project analyst
Reviewed by: project staff, business area staff
Approved by: project staff
Information resources: business area staff

8
Step 2: ANALYZING THE SYSTEM IN TERMS OF THE IU
RECORDKEEPING REQUIREMENTS
The goals of this step in the methodology are twofold: a) describe or model how the
existing system is presently managing the records created by the business processes
identified during the analysis conducted in Step 1; and b) analyze these results in terms of
the IU Functional Requirements.
In defining how the system is presently managing records, the analyst will rely heavily on
relevant documentation on system functionality and operations. Where documentation is
non-existent or lacks detail, the analyst will interview knowledgeable staff who understand
how data is processed and managed in the system.

The goal in this step is to determine how the system is how the system is managing the
records under review. To determine this, the analyst will ask a series of questions derived
from the IU Functional Requirements document. The Functional Requirements are system
level requirements, and therefore are meant to be applied at a much higher level than the
individual record. In other words, for all the Functional Requirements the analyst will
begin by reviewing and analyzing how the requirement is met at the highest-level sub-
function for the business function under review. For example, in the decomposition model
depicted above, this would mean analyzing as a body all records produced by the three
sub-functions and the six business transactions for the high-level sub-function “Degree
Recording.” If during the analysis it becomes clear that the records produced in the
course of completing lower-level sub-functions are managed differently than the records of
related sub-functions, the analyst will then proceed to analyze the records at the next
lower level. For example, in reviewing the system for the requirement “Authenticity,” the
analyst discovers that rules for modification of records for the sub-function “Enrollment
Certification” are different than for the sub-function “Degree Certification.” Once this
difference is discovered, the analyst would immediately adopt a strategy of reviewing
separately the products of business processes for each of the lower-level sub-functions.
Similarly, if different procedures are undertaken at the level of the business transaction,
then the analyst will begin the analysis of the system for that requirement at the level of the
business event or record level. However, this will be a rare occurrence. In the vast
majority of cases, the analysis of the system in terms of the IU Functional Requirements
will be at the highest sub-function level.

WORK STEPS:
1. Analyst gathers available documentation on systems, standards, procedures, retention
schedules, etc. Prominent categories of documentation include: Processing descriptions
with models, if available; procedure manuals and workflow models relating to routing,
inputting, updating, saving and deleting records; procedure manuals relating to backing-
up, migrating, purging, exporting and restoring data; documentation on data and data
models to determine what types of informational value may be present in records;
procedures that define access and use of records, and training procedures; existing
disposition schedules and laws, policies and best practices related to recordkeeping;
9
policies and procedures dealing with security and authorization mechanisms;
documentation describing predefined reports and inquiries; and documentation describing
specific applications that are part of the system, including on-line processing transactions
and batch jobs.

2. Where documentation is unavailable or lacks details, the analyst interviews staff and
administrators who are familiar with the how the system processes and manages data and
records.

3. Using the functional decomposition analyses and system documentation, the analyst
reviews how the system is managing records in accordance with the “Requirements for
Electronic Records Management Systems.”

REQUIRED MATERIALS:
1. Functional decomposition analyses from step 1.
2. System documentation.
3. Other documentation (e.g., procedure manuals, policies, retention schedules).
4. Notes from interview with staff and administrators
5. IU Functional Requirements statement.

DELIVERABLE:
1. This document will be organized at the highest level sub-function, and only will include
analysis at lower levels as needed. Within each sub-function, the responses will be
arranged according to the list of Functional Requirements and will address the issues
defined for each requirement. For each requirement, prepare a brief narrative statement
describing how the system does or does not meet the requirement.

ROLES AND RESPONSIBILITIES:

Conducted by: project analyst
Reviewed by: project staff, business area staff, computing services staff
Approved by: project staff
Information Resources: business area staff, computing services staff

STEP 3: ANALYZING HOW THE SYSTEM IS DOCUMENTING RECORDS IN

TERMS OF THE IU METADATA SPECIFICATIONS
10
The goals of this step in the methodology are twofold: a) describe or model how the
existing system is presently documenting the records created by the business processes
identified during the analysis conducted in Step 1; and b) analyze these results in terms of
the IU Metadata Specifications.
In essence the goal is to determine if the “evidence” required to document the business
transactions exists and in what form. In other words, the primary objective is to
determine whether the metadata category or element exists for that record or class of
records. The goal is not to determine whether the value provided for that metadata
element is correct or incorrect. As in the previous step, the analyst will rely heavily on
relevant documentation to determine how the system is presently documenting records.
Where documentation is non-existent or lacks detail, the analyst will interview
knowledgeable staff who understand how data is processed and managed in the system.

In reviewing the documentation and determining how the system is documenting records,
the analyst will be guided by the specifications for recordkeeping listed in the Metadata
Specifications statement. Records within business events and even business sub-functions
often will include the same types of metadata. This is particularly true for so-called
“management” metadata that document why and how records will be accessed and used,
disposed of, and preserved. In most cases, the type of metadata collected to document
these activities will be the same for many, many records within a business process. Even
audit trail metadata documenting activities performed on individual records is predictable
because so much of this type documentation is collected automatically by the system and
applied to many records within a business process. Finally even types of metadata that are
unique to a specific record, such as the unique identifier, can be analyzed at the aggregate
level by asking the question: for records of this class or function, does the system assign a
unique identifier. Again, it is important to remember that what we are analyzing is
whether the system collects or creates this category of metadata and not whether the
metadata value is correct or not. Accordingly, as with the functional requirements, the
analyst will begin by reviewing and analyzing how the metadata specification is met at the
highest-level sub-function for the business function under review. If during the analysis it
becomes clear that the records produced in the course of completing lower-level sub-
functions are documented differently than the records of related sub-functions, the analyst
will then proceed to analyze the records at the next lower level. For example, in reviewing
the system for “Disposition” Metadata,” the analyst discovers that within the sub-function
“Enrollment Certification” retention periods are specified, while for the related sub-
function “Degree Certification” retention metadata is not present. Once this difference is
discovered, the analyst would immediately adopt a strategy of reviewing separately the
products of business processes for each of the lower-level sub-functions. Similarly, if
types of metadata collected at the level of the business transaction are different, then the
analyst will begin the analysis of the system for that specification at the level of the
business event or record level.

11
It is also important to determine the nature of the logical relationship between the record
content and the metadata. Is the metadata part of the record? Is it electronically linked
to the record? Is the metadata a paper record whose location is electronically linked to
the record? Or is there no logical relationship between the metadata and record?

WORK STEPS:
1. Analyst gathers available documentation on how the system documents data and
records. Prominent types of documentation include business process models, data models,
and data dictionaries.

2. Where documentation is unavailable or lacks details, the analyst interviews staff and
administrators who are familiar with the how the system documents data and records.

3. Analyst reviews how the system is documenting records in accordance with the IU
Recordkeeping Metadata Specifications.

REQUIRED MATERIALS:
1. Functional decomposition analyses from step 1.
2. Documentation on how the system is documenting records.
3. Notes from interview with staff and administrators
4. IU Metadata Specifications document.

DELIVERABLE:
Responses will be organized at the highest level sub-function, and only will include
analysis at lower levels as needed. Within each sub-function, the responses will be
arranged according to the list of Metadata Specifications and will address the following
questions: a) Does the metadata exist? B) What is the logical relationship between the
metadata or a citation to the metadata and the record content?

ROLES AND RESPONSIBILITIES:

Conducted by: project analyst
Reviewed by: project staff, business area staff, computing services staff
Approved by: project staff
Information Resources: business area staff, computing services staff

12
Step 4: EVALUATE THE SYSTEMS IN TERMS OF THE "FUNCTIONAL
REQUIREMENTS FOR EVIDENCE IN RECORDKEEPING"
How effectively does the existing system satisfy the requirements of a recordkeeping
system? In this step, the results of the analyses conducted in steps 1 and 2 are evaluated in
terms of various categories of compliance.

WORK STEPS:
1. Project staff review documentation produced by analyst in previous steps.
2. Project staff interview analyst, if necessary.
3. It may be necessary to conduct additional interviews with record creators or to review
the documentation so as to gather more specific or detailed information. Even with the
best efforts of the analyst in preparing documentation for the evaluation, the evaluator(s)
may require additional information or interpretation in order to evaluate correctly the
evidence collected during the previous analyses.
4. For each sub-function the project staff evaluates the systems according to the following
criteria: How effectively does the system satisfy the requirements of a recordkeeping
system? For each of the Indiana University Functional Requirements, what evidence is
there that the system satisfies that Requirement? Do not respond with a simple yes or no;
generate a brief narrative statement with specific examples of evidence that the
requirement is fulfilled or not fulfilled. In addition, classify the level of compliance in
terms of one of the following three categories: 1) satisfied, 2) partially satisfied, and 3) not
satisfied.

REQUIRED MATERIALS:
1. Documentation from steps 1 and 2.
2. Other supporting documentation accumulated in previous phases.
3. Indiana University versions of Functional Requirements.

DELIVERABLE:
1. A document that for each high-level sub-function that describes the nature and level of
compliance with each of the IU Functional Requirements.

ROLES AND RESPONSIBILITIES:

Conducted by: project staff
Reviewed by: archivist
Approved by: archivist
Information resources: project analyst

13
Step 5: EVALUATE THE SYSTEMS IN TERMS OF HOW WELL THEY MEET
THE IU METADATA SPECIFICATIONS
How effectively does the existing system satisfy the IU Metadata Specifications. In this
step, the results of the analyses conducted in steps 1 and 2 are evaluated in terms of
various categories of compliance.

WORK STEPS:
1. Project staff review documentation produced by analyst in previous steps.
2. Project staff interview analyst, if necessary.
3. It may be necessary to conduct additional interviews with record creators or to review
the documentation so as to gather more specific or detailed information. Even with the
best efforts of the analyst in preparing documentation for the evaluation, the evaluator(s)
may require additional information or interpretation in order to evaluate correctly the
evidence collected during the previous analyses.
4. For each business event the project staff evaluates the systems according to the
following criteria: Is the appropriate metadata (context, structure, and content) being
captured and preserved inviolate by the existing system? For each of the Indiana
University Metadata Specifications, what evidence is there that the system satisfies the
Specification? Again, do not respond with a simple yes or no. Create a brief narrative
statement with specific examples of compliance or non-compliance. In addition, classify
the level of compliance in terms of one of the following categories: a) Metadata is
available electronically with use of record; b) Metadata is available in electronic or paper
format, and there is a logical relationship between the metadata or a citation to this
metadata and the record itself; c) Metadata is available in electronic or paper format, but
there is no logical relationship between the metadata or a citation to the metadata and the
record itself; d) Metadata is not available anywhere.

REQUIRED MATERIALS:
1. Documentation from steps 1 and 2.
2. Other supporting documentation accumulated in previous phases.
3. Indiana University versions of the Metadata Specifications

DELIVERABLE:
1. A document that for each event process or transaction describes the nature and level of
compliance with the IU Metadata Specifications.

ROLES AND RESPONSIBILITIES:

Conducted by: project staff
14
Reviewed by: archivist
Approved by: archivist
Information resources: project analyst

Step 6: RECOMMENDATIONS
Once the analysis of how the information system is managing records of the various
business processes is completed, staff meet to determine what recommendations will be
made for improving the performance of the system. We recognize that not all the problems
identified in the evaluation process will be of equal rank or of the same level or degree of
seriousness. Therefore there are three categories or levels of recommendations: Highest
Priority Recommendations, Concerns, and For Your Information. When making
recommendations for changes to recordkeeping systems keep in mind the costs/risks and
benefits associated with implementing that particular recommendation. We also recognize
that institutions will not likely implement every recommendation we make. The decision to
implement will be based on a variety of factors, including an appraisal of the value of the
records, costs and benefits, risk of retaining or disposing of documentation, and
organizational needs and priorities.

WORK STEPS:
1. Project staff reviews the evaluation document for evidence of functional requirements
and metadata specifications that have not been met.
2. Project staff prepares a set of recommendations for improving the system based on the
three categories listed above.
3. Project staff prepares a report and presents the recommendations to appropriate
parties.

REQUIRED MATERIALS:
1. The evaluation document from Step 3.
2. Documents from other phases if necessary

DELIVERABLES:
Report of recommendations in the following format:
Introductory statement describing the scope and objectives of the evaluation process
Specific recommendations organized into the categories of: Highest Priority
Recommendations, Concerns, and For Your Information. Each recommendation will
include an explanation of the problem and recommendations on how the unit might
15
address it. This document along with a short cover letter outlining the process is then
forwarded to the appropriate data stewards and managers for their review. Soon after
transmittal of the report, a meeting will be scheduled to discuss the various
recommendations and implementation strategies.

ROLES AND RESPONSIBILITIES:

Conducted by: project staff, project analyst
Reviewed by: archivist, business area staff
Approved by: archivist
Accepted or Rejected by: business area staff
Information resources: project analyst

16