Drafting a Function-Based File Classification Plan
With desktop management of electronic records now the norm, most organizations are struggling with growing volumes of records that are poorly organized according to individual users’ ad hoc file directory structures (FDS).
As these structures become more complex and harder to navigate, organizations are exposed to a number of risks:
Gerry van Houten
-
As employees copy records, folders, or groups of folders from one FDS to others for their personal use, divergences develop in the content of duplicated folders.
-
Employees use “archiving” folders as a dumping ground for inactive records. “Out of sight” becomes “out of mind” as employee turnovers lead to loss of knowledge about the purpose, content, and location of inactive records.
-
Employees store organization records in personal electronic work spaces or on hard drives, rendering these records inaccessible to other employees, who are sometimes unaware that the records even exist.
In 2007, the Ministry of Municipal Affairs and Housing (MMAH) began addressing these risks. As the first organization in the Ontario Public Service (OPS) to develop and implement a system of file classification plans, its explicit objectives were to share information across the ministry and prepare for implementing an electronic record and document management system, or an enterprise information management (EIM) system. For the MMAH and a wide variety of OPS organizations, function-based file plans took root.
Improving Business Efficiency
The regulatory environment had changed with the creation of the Archives and Recordkeeping Act, 2006 (the act), which is the legislative foundation for recordkeeping in Ontario’s “public bodies” (i.e., a ministry of the Government of Ontario, an agency, board, commission, corporation, or other entity designated as a public body by regulation).
The act defines a “record” as “information in any form, including a record made, recorded, transmitted or stored in digital format or in other intangible form by electronic, magnetic, optical or any other means, but does not include a mechanism or system for making, sending, receiving, storing or otherwise processing information.”
It stipulates that public bodies are required to prepare a records schedule that sets out each class of public records (i.e., records made or received by a public body in carrying out its activities, their retention period, and their eventual disposition).
Public bodies must meet the act’s requirements. They “shall ensure that their public records are preserved and that the information in them is accessible until they are transferred or otherwise disposed of in accordance with their approved records schedule.” Disposition of public records without the consent of the Archivist of Ontario is illegal.
As in any organization where employees are unaware of recordkeeping requirements, the risk of premature destruction of records or, conversely, their retention well beyond the needs of the business, is high.
The Freedom of Information and Protection of Privacy Act, 1990 (FIPPA) also has an important impact on recordkeeping in the OPS. FIPPA gives every person the right to access a record, except those individuals who are otherwise specifically exempt, and requires the protection of personal information. While FIPPA does not explicitly speak to recordkeeping, its provisions presuppose the presence of an effective recordkeeping system.
EIM implementation is an incentive for systematic file classification plan development. Although EIM systems offer effective tools to access records, reduced reliance on the classification system does not mean that classification becomes less important. OPS experience suggests that individuals tend to revert to the use of classifications to file and find records despite intensive training in the use of search tools/engines, so an intuitive classification system is still necessary in an EIM system.
More important, the classifications in an EIM system facilitate the optimization of EIM features and automated processes. They include contextual information (metadata), which describes the business purpose and content of the record that belong to it. Even if they are not used as a navigation tool, they are essential focal points for effectively using the search engine, identifying and administering user access groups, and assigning records retention periods and dispositions.
Committing to Project and Resources
Management commitment is essential because a file plan development project requires time and resources. To ensure success, management must:
-
Express clear support for the project and communicate this to staff
-
Allocate resources for file plan development, implementation, training, and ongoing monitoring and maintenance of the file plan
-
Assign appropriate leadership including a file plan coordinator (project leader) and project team
-
Acquire or develop expertise to develop the file plan
-
Ensure that IT support is assigned to support the implementation of the file plan on the FDS
File plan projects should follow project management principles, such as planning of project and communications; setting timelines and benchmarks; implementing, training, projecting closure and handover; and post-implementation review.
A variety of sources can be reviewed to understand an organization’s current recordkeeping practices and needs. This may include:
- FDSs and file lists
- Records schedules
- Descriptions of the organization’s mandate, services, program areas, responsibilities, and reporting relationships
- Subject matter experts
- Surveys and interviews
- Recordkeeping metrics as outlined in more detail later in this article
Developing Classifications
Consistent application of the same criteria and methodology is paramount. Although this article is oriented on electronic records, file plans can and should apply to all media. The key criteria are:
- Definition of business functions and processes (activities)
- Access and security requirements
- Records retention and disposition requirements
- Exceptions (e.g., records that can or should not be organized by business function or activity)
Defining the organization’s business processes is the first and the most basic criterion and should serve as the starting point for developing file plans. A file plan should be large enough to incorporate an entire function but be small enough to be manageable as a project.
Business activities form the basis for developing most primary (top-level) classifications (see Figure 1). Primary classifications should be generic enough to account for all records. Although secondary classifications are also generic, their scope is more specific because they are subordinate to the primary classification to which they belong. The file plan should include descriptions if the purpose and content of all primary and secondary classifications is not immediately obvious.
Figure 1: Sample File Plan
The top two levels should contain no records. Records are filed in folders at the third level or lower. Users should be able to create folders and store file records below the secondary classification although they should follow the file plan’s business rules.
In instances where information security requires protecting sensitive, confidential, and private personal information, an organization’s file plans should also document access permissions groups. Although it is technically possible to establish access groups at any level in an FDS, this practice is discouraged. If a file class requires its own access group, it must be created at the secondary level even if logic otherwise dictates that it should be subordinate to an existing classification. This leads to modifications in how functions-based classifications are expressed in the file plan. For example, every business function has an administrative function. Some administrative records are open to all staff while others are restricted.
Understanding Records Retention and Disposition
A file plan should build direct linkages between its classifications and record series found in approved records schedules. These linkages support identification of records that are either already subject to a records schedule or may require scheduling. OPS file plans usually establish retention periods and dispositions at the secondary level, rarely at the primary level (if the primary represents one record series), and never at the third or lower levels (i.e., the file class parts).
File plans should have the capacity to identify closed record series (file classes) (e.g., by creating folders named by the calendar or fiscal year, naming conventions that include the date in the filename). The preferred formats for naming folders by calenday and fiscal year are yyyy and yyyy-yy respectively.
Direct linkages between classifications and record series allow identification of their retention period and their mode of disposition (destruction or transfer to the archives).
EIM systems favor flat folder structures (four to five levels) based on an expectation that users will use other EIM features, such as the search engine or favorite folders lists, to find and file their records. Unless EIM implementation is imminent, OPS experience is that flat structures are very difficult to implement in a networked FDS and may require appropriate levels of training, monitoring, and business rules.
Some records cannot be classified by function. They include:
-
Case files that cross business processes or are shared by more than one organization
-
Cross-functional project files
-
Programs servicing multi-regional clients
-
Records documenting services provided to specific regions and municipalities
Classifications for such records may be created at either the primary or secondary level depending on the business context.
In the rare cases where large volumes lead to an inordinate concentration of records in one functional area, it is acceptable to promote the high-volume folders to a primary or secondary classification as a way to prevent folder structures from becoming too deep.
The terms used for file classes and their subordinate parts should indicate purpose and content. They should be concise, transparent, and consistently applied. Where possible, the terminology of relevant records schedules should be used. OPS file plans usually include a brief description as an additional support to users.
Another hazard of ad hoc file directory structures is the proliferation of abbreviations and acronyms. Over time, their meaning is often forgotten or lost, so they should always be spelled out and documented. Descriptive fields in file plans, metadata fields in an EIM system, and/or web lists and glossaries are the most common methods used to document acronyms and abbreviations.
Finalizing and Measuring the File Plan
Because team members still have to perform their regular duties, it normally takes three to six months to design and finalize a file plan. Several iterations are normal as part of an ongoing consultation and negotiation process between the file plan writer and staff. However long it takes, the development phase does not end until the responsible program manager has approved the file plan. Only then, should implementation begin.
The creation of new FDS based on the file plan will require IT’s support – particularly in the establishment of the access permissions groups.
The implementation of a new file plan-based FDS should focus on the creation of the primary and secondary classifications and their access groups. Staff should be able to create folders representing file class parts. This approach also supports the bulk migration of records from the existing file share. Staff should be given adequate time to:
-
Clean up the existing FDS
-
Migrate the records
-
Take training
The time needed to implement the file plan depends on the volume of records and the current state of recordkeeping.
To be able to show what changes resulted from the implementation of a new file plan/file share, it is important to measure the status of the FDS both before and after its implementation. Measurements may include the:
By far, the most important measurement is user satisfaction. Post-implementation feedback should result
in comments that the new FDA is intuitive or easy to use.
Cleaning, Migrating, and Disposing Records
Cleanup may take place before and/or during the migration of folders and records from the old FDS to the new shared folder structure. More cleanup before migration means less cleanup during migration and a more focussed approach to the migration. Cleanup should include:
-
Removal of transitory records (i.e., records with temporary or shortterm value) that are no longer needed
-
Disposition of records whose retention periods have expired
-
Deletion of empty folders
-
Consolidation of folders with few records into a higher-level folder
-
Renaming folders intended for migration to make them consistent with the file plan
The project team and management should agree on a date when the new shared folder structure will take effect and to inform IT support staff to place legacy shared folders on “readonly” status to prevent the addition of new records.
Some staff members should continue to have “modified” access so disposition of the legacy records can take place when their retention period ends.
There are three approaches:
- Migrate all files.
- Migrate the current year plus one or more previous years.
- Migrate on a go-forward basis, i.e., migrate files from the legacy system only when they are needed for current business purposes.
Depending on the nature of the business and its requirements, some combination of these approaches may also be used.
Legacy files may be left behind until they have reached the end of their retention period. To avoid the transfer of existing access restrictions, “copy and paste” should be used instead of “drag and drop.”
Reorganization of the existing FDS is an alternative to migration, but the risks of inadvertent loss or misplacement of records are also much higher.
Disposition of records must be documented and meet the requirements of an approved records schedule and relevant recordkeeping protocols. Disposition requires the agreement of the program manager.
In the OPS, disposition cannot take place without an approved records schedule. Unscheduled records require the public body to develop an appropriate records series and have it approved by the Archivist of Ontario.
Disposition of records should be a regularly scheduled event at the end of the calendar and/or fiscal year. In EIM systems, this process is automated through generation of a disposition report. The EIM administrator may delete records whose retention periods have expired with the program manager’s consent.
Monitoring and Maintenance
Changes to the shared folder structure require the agreement of the program manager or his/her delegate (e.g., file plan coordinator) and should be documented as amendments to the file plan. Only the person authorized to do so may add, delete, or alter classifications.
In EIM systems, the EIM administrator plays this role. Business rules may be needed. For example, changes to classifications could require an employee to submit formal change requests to the program manager or delegate. If the program manager approves the change, the request is submitted to the EIM administrator for implementation.
The program manager or delegate should monitor activity on the shared folder structure to ensure that users are following the documented business rules and naming conventions. EIM systems perform this function through audit trails.
Setting Recordkeeping Protocols
Business rules and practices manuals help regulate changes to the file plan and establish recordkeeping procedures for staff. The following are some issues that should be addressed:
-
Overall responsibility for the file plan
-
Change management, including communication of changes
-
Preventing ad hoc change at the top two levels
-
Access permissions and information security
-
Tracking drafts and versions
-
Naming conventions
-
E-mail management
EIM systems automate many aspects of filing procedures and file plan management.
Download the PDF version here.
Gerry van Houten can be contacted at gerry.vanhouten@ontario.ca.
From July - August 2010