Taking too long? Close loading screen.

January 2, 2017by arma_admin

From Chaos to Order






In 2011, the Sunshine Coast Regional District (SCRD), in British Columbia, embarked on a project to restructure the shared drive used by all its employees. The new shared drive went live for staff in March, 2012 and by December of the same year, all records were migrated to the new drive. This case study features the SCRD’s management of electronic documents, how the new drive was restructured and the lessons learned from the project.



Incorporated in 1967, the SCRD is one of the smaller regional districts in British Columbia, encompassing almost 3800 square kilometres of land and providing services to more than 28,000 residents. There are about 250 employees spread over 14 sites and nearly 200 use computers in some fashion and therefore generate electronic documents.

Regional districts are similar to counties in other parts of Canada, providing municipal-style services to unincorporated areas as well as providing region-wide services to member municipalities. Local governments, including regional districts, are often segregated along business lines. The SCRD has 98 diverse and entirely distinct business units including:

  • Accounting, payroll, financial and investment services;
  • Legislative services and bylaw compliance;
  • Solid waste management;
  • Water supply and distribution;
  • Parks planning and management;
  • Four distinct fire departments;
  • Five separate recreation facilities; and
  • Transit

Each of the departments has very specific needs with regards to managing records and often these needs are driven by external legislation. As an example, our Fire Departments not only respond to fire and accident calls, they also need to be able to manage their radio licenses, leases for radio towers and they have acquired their own records management system (Fire RMS). This software is to specifically manage their emergency records and is maintained and operated by an external service provider. In addition to the four fire departments directly operated by the SCRD, there are also two independent fire departments – Sechelt and Pender Harbour. Although all six departments operate independently, the SCRD operates a service for all of them to provide 9-1-1 dispatch and to maintain the dispatch radio network, which is handled through third party contractors.

However, as we are legally one single organization, the information must be treated consistently with respect to handling, classification and retention, regardless of how or where it is created.

At the time the SCRD embarked on the shared drive restructure project, there was no system in place to manage electronic records. The details of the state of the SCRD’s electronic records will be provided later in this article.

The classification schedule from the Local Government Management Association (LGMA) of British Columbia’s Records Management Manual was being used for hard copy records, which are maintained in a central file room and an in-house inactive records centre. The structure of the schedule is such that it reinforces the concept that the SCRD is ultimately one corporation, even though it usually thinks in a compartmentalized manner. As an example, under the large function “Engineering and Public Works”, there is a primary 5280 Environmental Management and secondaries related to air quality, chemicals, noise control, and so forth. Retention is applied at the secondary level. See Figure 1.


Before the SCRD started the shared drive restructure project, finding a document was like finding your way through a maze. The original shared drive, called “H:” was established in 1994 to take advantage of a new Novell Netware file server. There were about 35 computers all at one site and all running DOS. Creating the shared drive was intended to eliminate the “floppy disk shuffle”.

The H: drive structure was modeled around the approximately 22 major departments that existed at that time. The contents of the departments’ folders were intended to be transitory – conceptually, draft documents were prepared within a department’s private folder and the final edition eventually moved to a shared access folder. Shared folders were organized by year and originating department, much like how the SCRD organized its correspondence files at that time. Any sensitive files, such as Human Resources, remained on floppy disk and were stored under lock and key.

The hard copy was considered the ‘R’ecord and the electronic version was simply for retrieval convenience and to allow reusing well-formatted documents such as agendas and minutes (this occurred long before Microsoft Word Document Templates existed).

Over time, the SCRD added dBase databases and other structured data systems such as Accpac. Those systems also stored their data on the file server where it was reliably backed up and protected against corruption.

There was a file name limitation of eight characters, with a three character extension. DOS did not require the three character extension to reflect the application used to create the file.

Therefore, when working with WordPerfect documents, it was often used to store the initials of the document creator.

The H: drive grew and evolved resulting in:

  1. ‘Walled gardens’, where departments could and did do anything they
  2. Folder structures that ‘evolved,’ theoretically to match a department’s

As technology changed, and with the elimination of the restrictions in file name length, users found they could create subfolders and include information in the subfolder title that more correctly belonged in the file name itself, such as creating “Year” folders instead of putting the year directly in the file name.

In 1998, the SCRD experienced a sudden and dramatic corporate restructure. The H: drive no longer substantially followed the SCRD’s organizational structure. With this change, and with ongoing growth in the size of the organization, there was an increasing need for collaboration across the departments. To handle this need, a set of “teams” folders were created, with explicit permissions granted to specific users collaborating on select projects. The H: drive and the SCRD’s organization structure continued to diverge as new services and departments were added without modifying H: drive.

Most importantly, permissions were modeled around the “named user”. Complications arose when a user left the organization or when collaboration on a project transferred to another employee.

By 2012, the H: drive contained over 465,000 files in over 40,000 folders. Due to the volume of files:

  • Duplication was rampant – some staff copied a document to where they thought they would be sure to find it again; and
  • Disappearances were frequent – other staff would find a document and then move it to where they thought it belonged, without advising the author of the

Since no rules had been developed to explain how records were to be saved, there was simply no way to train new staff on how the shared drive worked, what was to be saved there, or how it was to be saved.

Because of the walled gardens and lack of naming conventions, it was extremely difficult to find an electronic version of a document when the corresponding hard copy was destroyed. This made it impossible to apply the SCRD’s retention schedule to electronic documents.

As a result, the SCRD faced numerous issues:

  • A lack of confidence that the searches for electronic documents were sufficiently complete for either Freedom of Information requests or litigation and claims;
  • Concern there may be violations of the Freedom of Information and Protection of Privacy Act of BC (FOIPP) – some personal information collected in the course of business was stored in open folders;
  • Information leakage – some personnel documents and in-camera minutes were stored in open folders, permitting access beyond the required staff;
  • Zombie documents proliferated – if documents otherwise eligible for deletion were not saved in the appropriate folder they could linger forever, shambling back out into the light at exactly the wrong time;
  • Lost files, including the SCRD’s bylaws;
  • Volume of password protected documents grew and effectively became invisible to searches;
  • Collaboration between departments was difficult – resulting in documents being emailed between staff, which were then named and saved in different folders, amplifying the duplication problem; and
  • Proliferation of subfolders with a user’s name (for example, Jane’s Stuff).

Due to the lack of controls on subfolder creation, the H: drive had evolved unbelievably deep folder structures. SCRD staff lost files because the length of the file names, which included the file path, was so long.

All minutes and agendas were stored in a central folder, and correspondence was organized by year and month, then by originating department. So, staff had to remember the month they wrote a letter in order to find it again – and by the time the restructure project was started, there were almost 230 months from which to choose.

Figure 2 is a circular treemap, which is a graphical model that attempts to summarize the overall structure of a shared drive. The central back dot is the top level of the drive and moving outwards each ring represents a level of folders, so folders-within-folders quickly build out as ‘spikes’. The overall size of a spike indicates the depth of a subfolder tree needed to reach that folder. Figure 2 captures all 40,405 nested folders in H: drive, where every branch of folders has been growing independently of all the others. Particularly evident is the lack of symmetry, including seemingly random excursions as far as 14 folders deep. Every asymmetric aspect is an exception and has some unique reason for existing that must be contemplated when navigating – yet that reason is likely only known to the person who created the subfolders. It is also worth noting that records could be spread out across any levels of folders, anywhere, not just in the final folder of a particular path.



Figure 3 extracts the 8500 folders in the Infrastructure Department walled garden (the portion of the overall graphic outlined by the red wedge). The tiny black line on both scales of the treemap identifies an example folder at the end of the deep spike:\Infrastructure\Sustainability\1425-20 – Public Education Program\Admin\Email Saved\Recycling Feedback\General\For Curbside Pick Up\Roberts Creek




In 2003, consultants were hired to evaluate the SCRD’s requirements for an electronic document and records management system (EDRMS), which led to the preparation of a draft Request for Proposals. The consultants also included design recommendations for the new administration office building that was under construction. While the design recommendations were incorporated, the EDRMS funding was frozen by senior management as it was felt the project represented too much change for staff when combined with the move to the new building.

In 2007, a budget was put in place for a full-time Records Management Technician, with the goal of achieving two major projects: to inject the LGMA classification schedule into the H: drive and to implement an EDRMS. In 2008, a budget submission for an EDRMS was again submitted, but was not approved. And, in 2011, the SCRD Board of Directors approved $10,000 to improve the structure of the H: drive.



With the SCRD Board of Directors’ approval of funding, the restructure project was initiated. Two committees were struck: the steering committee and the working committee.

The steering committee consisted of the Corporate Officer and her Deputy, the Records Management Technician, the Manager of Information Technology (IT) Services and two of her staff. The Corporate Officer and IT Manager were tasked with communicating to SCRD management critical aspects of the project, such as:

  • Why the project was needed;
  • Timelines;
  • Work each department would need to accomplish;
  • Budget and staff

The steering committee quickly determined that the H: drive could not be fixed and that a new shared drive was required – the N: drive.

It was critical that the steering committee understood each other’s perspective in order to accomplish the goals of the restructure project. From an IT perspective, with storage becoming ever cheaper, Records can be kept forever as capacity is not an issue, search technology is improving very quickly, and there are innovations in computational knowledge extraction.

Records and Information best practice requires that Records be managed from creation to final disposition – just because we can maintain everything forever does not mean we should.

The working committee consisted of at least one representative from each department – the representative would be that department’s advocate during the project. In addition to bringing their department’s needs and wants for the shared drive forward to the committee, the representatives communicated to their respective departments the reasons why the project was needed and how the SCRD would accomplish the change. As well, the representatives were to communicate specific processes each department was required to accomplish such as:

  • Reviewing files in their H: drive folder and deleting what they could; and
  • Determining the subfolders the department would need in the new shared drive so the drive could be seeded before

A price request, project outline and desired outcomes were sent to several consultants. A request for proposals was not needed as the project budget of $10,000 was below the threshold set by the SCRD’s Purchasing Policy.

A consultant was hired in September, 2011. By November, 2011, on-site work had begun.

The on-site work included folder structure revision and enhancement, as well as interviews with staff to solicit specific knowledge of each department’s requirements. The original timeline was to implement the new shared drive structure on January 1, 2012; due to staff and consultant workloads, cut-over was achieved March 1, 2012.

The steering committee decided it was important to set a target date when the H: drive would disappear and felt six months would be sufficient – August 31, 2012. The H: drive would then be completely deleted by December 31, 2012.

The desired outcomes for the project were:

  • Resolve internal collaboration issues;
  • Implicitly purge electronic files that were beyond retention;
  • Reduce information duplication;
  • Improve the quality of search results;
  • Provide certainty for Freedom of Information and litigation searches;
  • Preparatory work for the eventual import of electronic files into a formal EDRMS; and
  • Rudimentary ‘knowledge capture’ from senior employees nearing

The project outline seemed simple:

  • Create a new folder framework;
  • Determine lower level folder structures;
  • Create a draft design of the folder structure;
  • Determine and document permissions;
  • Set up the new folders and infrastructure;
  • Train staff;
  • Migrate to the new folder structure; and
  • Delete the old

However, the scope of the project was quite large as it included all electronic records and email, as well as providing the ability to restrict access to confidential records.

In creating the folder framework, the SCRD required the consultant to design a high-level folder structure that would be universal across all departments. The consultant met with the steering committee to gather the requirements for the folder structure.

Part of the project outline was the requirement that the consultant help the steering committee adapt the LGMA schedule for use with the SCRD’s electronic documents. Using the same schedule for both paper and electronic would reinforce for users the concept that the information was the same, only the media was different.



The initial high-level folder structure used the 16 functional folders from the LGMA schedule:

  1. Administration
  2. Assets and Procurement
  3. Buildings, Facilities and Properties
  4. Community Services
  5. Finance
  6. Human Resources
  7. Information Systems and Service
  8. Infrastructure
  9. Land Administration
  10. Legal Matters
  11. Legislative and Regulatory Affairs
  12. Parks Administration
  13. Planning and Development
  14. Protective Services
  15. Recreation and Culture
  16. Transportation and Transit Service

The lower level folder structure would be specific to each department. To accomplish this, the consultant conducted a file and document analysis and interviewed staff in each department.

In the LGMA classification schedule, each primary has a “general” secondary. Wherever possible, this was eliminated to encourage staff to file in an appropriate secondary without a default option.

An absolute limitation on tree depth was imposed – function, primary, secondary and optional folder. Figure 4 shows the folder structure for grants received from organizations.


While staff had access to and could create files within any pre-existing secondary or optional folders they could see, any modification, addition or deletion to the folder structure would be made by the Records Management Team. The team consisted of the Record Management Technician, Corporate Officer and Deputy Corporate Officer. The ability to create subfolders was removed to ensure that the N: drive would not have the proliferation of subfolders that the H: drive had. There were some exceptions when the volume of subfolders required daily was high – such as building, zoning and development permits. Subfolder creation requests were sent to the Records Management Helpdesk and the final decision rested with the Records Management Team.

As previously mentioned, some modifications of lower level folders were required to accommodate departmental needs. Figure 5 shows the modifications necessary for zoning applications – very complex items that require several subfolders. Using the traditional LGMA structure, subfolders would not be possible as that would violate the rule “four levels of folders”.

Figure 6 shows the modifications required to accommodate the segregation of operations, which allowed subfolders for each waste water treatment plant. In this case, while each waste water treatment plant operates independently, each operation is essentially the same. Therefore, each secondary has the same subfolders.




A vast amount of business knowledge is contained in email and users tend to hoard them, in keeping with the adage, “If in doubt, keep it.” This creates problems when there is a conflict between policies and corporate needs. There is also the perception that emails are ‘different’ from other electronic documents. And, classifying email is hard – there can be a rich variety of content in a chain of messages, making it difficult to identify a principal classification.

The SCRD has regularly conducted training for users on specific rules for how and who should be saving emails:

  • The originator of an internal email would save it in the N: drive. Recipients would delete the email;
  • Recipients of external email would save the incoming email in the N: drive. If there was more than one recipient within the SCRD, the first person named would save it;
  • All emails would be saved in the Outlook or .msg format to preserve headers and metadata;
  • Inboxes had a 500 Mb limit applied to encourage saving in the N: drive. If the limit was exceeded, emails could be received but not

Unfortunately, this training and the specific rules have produced low quality results when there are large numbers of emails to move into the shared drive. Without automation, it will be difficult to improve.

Originally the steering committee decided that when sending emails internally, hyperlinks were to be used and any attachments would be stripped. This was to decrease the amount of file duplication as the attachment lingered in the sender’s “Sent Items” as well as the recipient’s “Inbox” and possibly already existed in the N: drive. A Microsoft Exchange transport rule can easily be built to block attachments. It was also determined that many system functions operate via attachments, such as Calendar appointments and vCards (virtual business cards in Outlook), so the transport rule was built with a size threshold. The result: the Exchange transport rule was considerably more complex than originally anticipated.

Discussion with the working committee determined that attachments were necessary for consistency if an email was sent internally and externally. This often occurs when distributing agenda packages to SCRD committees as well as when sending certain types of information. Therefore, the rule to strip attachments for internal emails was relaxed. The staff were trained to include a hyperlink, but if there was an attachment it was allowed to go through. The sender received an automated warning and a copy of the email was placed in an inspection folder for later review to measure compliance.


Microsoft New Technology File System, (NTFS) was introduced in 1993. It is the suite of mechanisms by which Microsoft ‘Server’ operating systems, and now all versions of Windows, store and retrieve persistent data, such as files on disk. NTFS includes an extremely flexible permissions or ‘access control list’ framework that allows for almost any conceivable arrangement of access and change control.

However, their complexity massively increases the risk of unintended consequences, especially when maintaining them manually. Mistakes in permissions create holes; users will discover them and probably will not mention what they have discovered. Essentially, the user may believe, “The system didn’t prevent me, therefore it must be permitted”. It is necessary to ensure permissions are structured so they can be applied consistently:

  1. Do not allow ad-hoc exceptions, if at all
  2. Make the permissions predictable and pattern
  3. Use tools such as Somarsoft DumpACL, Hyena, or Powershell to audit the file system permissions after they have been established, if building the permissions
  4. Leverage inheritance (see Figure 7).


Determining how to handle the SCRD’s confidential documents required long discussions. Human Resources’ internal records had to be restricted to Human Resources, but how could access be restricted to personnel documents that managers create? Should the manager of one department be able to see the personnel documents relating to another department? What about supervisors? How could litigation, claim and accident files be efficiently managed when access would depend on who was involved?

Ultimately “restricted” functions, which paralleled the unrestricted functions, were created. Following permission management best practices, access to those “restricted” folders was explicitly granted to job roles, rather than named users, to reduce ongoing maintenance risks.

It was made clear to users that just because they did not want anyone to “see” a document, it did not make the document confidential. FOIPP was used as the guide to identify what was confidential.

This structure had the added advantage that the Microsoft Search indexer could reliably exclude all the restricted files and a second, separate index could be created that only includes them.

Figure 8 shows the structure in Legal Matters (Restricted) function; only the Chief Administrative Officer (CAO) and the Corporate Officer have top level permissions. Access to the subfolders would depend on who is involved and permissions would be set on a case by case basis. For example, the Transit Supervisor has access to the Transit accidents but not the Fleet accidents.

Understanding and leveraging NTFS ‘permission inheritance’ is crucial – defining them at the right point in the folder tree minimises maintenance effort and risk of errors.




With the restricted folders, the final result was 24 top-level folders:

  1. Administration
  2. Administration (Restricted).
  3. Assets and Procurement
  4. Assets and Procurement (Restricted).
  5. Buildings, Facilities and Properties
  6. Community Service
  7. Finance
  8. Finance (Restricted.)
  9. Human Resources
  10. Human Resources (Restricted).
  11. Information Systems and Service
  12. Infrastructure
  13. Land Administration
  14. Legal Matters
  15. Legislative and Regulatory Affairs
  16. Legislative and Regulatory Affairs (Restricted).
  17. Parks Administration.
  18. Planning and Development
  19. Protective Service
  20. Protective Services (Restricted).
  21. Recreation and Culture
  22. Recreation and Culture (Restricted).
  23. Transportation and Transit Service
  24. Transportation and Transit Services (Restricted).



Prior to the cut-over to the N: drive, all staff were required to attend Managing Information in N: Drive Training (MINT) – and were appropriately rewarded with mints, chocolate mint cookies and mint tea! These rewards were enthusiastically received by staff and similar marketing tools have been used effectively for other RIM training.

Support from senior management for this training was crucial; without attending MINT staff would be lost once the N: drive went live. Once staff attended the training, IT provided them with read-only access to the N: drive so they could explore and become familiar with it.

There was some push-back with a few staff members and certain managers. Some of the concerns were legitimate, such as lost productivity, or that there was no budget to bring in relief staff. However, some staff simply refused to do the training because they did not see any value in the project. To ensure the success of the project, it was decided that training was mandatory and those who continued to refuse training would not be using a computer.

Training was done by department, which allowed the training to focus on the department’s specific questions.

To accommodate all staff:

  • Training was scheduled over a six week period and training space was dedicated to the project;
  • Presentations and discussions were used, as learning the concepts was the focus, not how to use Windows;
  • Staff from remote sites came in to the main office; and
  • Staff working outside the main office hours were specially scheduled to be able to attend.

The training included:

  • A basic overview of records management and legislation requiring the management of SCRD records;
  • Why the shared drive needed to be cleaned up;
  • New rules for the new drive;
  • Requirement to use hyperlinks instead of attachments when sending internal emails;
  • Naming conventions;
  • An overview of the classification schedule;
  • How to classify their documents; and
  • Instruction on basic Windows concepts (hyperlinks, shortcuts and searching).

All attendees received a cheat sheet to help them find where to save files and a list of acronyms and abbreviations commonly used by the SCRD. The training, cheat sheet and acronyms were also available on our intranet.




Because the H: drive had never been purged, departments were encouraged to review existing files and clear out “the garbage”. Several departments were enthusiastic about the change and some even rearranged their folders on the H: drive to reflect the new structure. Some departments dedicated specific staff to purging and preparing to move files, some said everyone would be responsible for their own files, and some hoped the whole thing would just go away!

After training, any time an attachment was emailed internally, the sender received an automated warning message.

Prior to this project, IT had been using conventional ‘roaming profiles’, whereby a user’s personal files (My Documents etc.) were copied down from a central server to the desktop they were logging on to, and back at the end of the session. This was upgraded to ‘folder redirection’, whereby user’s files were always saved directly to a central server. This allowed implementing file system quotas on personal folders, as a pre-emptive strike on hoarding.



At 11:50 pm, February 29, 2012, the H: drive permissions for all users were reset to Read and Delete. At 12:01 am, March 1, 2012, after a very large deep breath, the Read-only flag was removed from the N: drive.

All users were now able to create/read/write files on the N: drive. All users were also able to read/delete anything on the H: drive, with the exception of Human Resources, certain databases, and the “Teams” folders.

On the first day after cutover, the Records Management Helpdesk had over 250 requests, not all with a professional tone. As the SCRD only has 250 employees, the number of requests the first day was, essentially, a one to one ratio to the number of staff. Those staff that had not yet taken the training couldn’t understand why they could not create subfolders anymore. People had trouble finding files and several demanded that the H: drive be re-instated. The Corporate Officer, in response to the first such demand, suggested that, as it had only been 45 minutes, they might want to wait a little longer. In addition to staff’s frustrations, we found there were some permission errors.

During the first week, special ‘one on one’ training was done with staff who had not attended MINT. As they were already frustrated, they were not very receptive to the changes. However, this special training did contribute to the decline in the number for helpdesk requests. By the end of the first week, the number had dropped to about 75 per day.

Many users had problems conceptualizing that they did not need subfolders. The steering committee felt that if files were named correctly staff could use Windows Explorer to find what was needed.

Many departments had not provided a list of required subfolders, such as the need for vendor names in several secondaries. Had the list been provided prior to cut-over, the subfolders could have been seeded. After cut-over, the Records Management Technician had to create the folders individually and then set permissions on each folder. In Restricted folders setting permissions could take hours or days.



There were some staff who continued to resist the implementation believing that their position/job duties allowed them special privileges – such as being able to have more than four levels in a folder tree or being able to save to their C: drive. In these instances the parties and their managers were reminded of the new policies and procedures.

Other staff began using My Documents for storing their files. To discourage this practice, a 500 Mb soft limit was implemented. IT ran regular reports to find the offenders.

  • Over 400 Mb – the offender was given a warning email, cc to RIM;
  • Over 490 Mb – another warning email was sent, cc to manager and RIM;
  • Over 500 Mb – RIM discussed the problem with the

There were some staff that consistently exceeded the 500 Mb limit, despite having been spoken to by their managers. In those cases, the violator’s account was disabled until the user met with RIM and IT to: 1) determine the ongoing problem, and 2) provide extra training to the violator.



As the migration of files to the N: drive and the purge of the H: drive progressed, staff were kept informed of the progress via the intranet. This was to try and help them see the “big picture” as time passed. Figure 9 is an example of the update provided to staff.

No statistics were kept as to the number of records deleted from H: drive vs. those moved into N: drive. Approximately 98% of the folder growth in N: drive was due to the migration from H: drive and only 2% could be attributed to new folder creation.

As the date for the demise of the H: drive approached, staff tried to circumvent the system and they were pretty creative about it. As the Corporate Officer stated, “Never underestimate the creativity of those who wish to circumvent the system.” Instead of moving required documents into the N: drive, some uploaded them to an FTP site or moved them to their C drive; and some even moved them to the staff photos folder on the intranet. Unfortunately, sometimes documents were lost before IT or RM became aware of the attempt at circumvention.

Some staff also started saving documents to USB keys, CD’s and removable hard drives. It was made clear that this was unacceptable. Senior managers were very supportive in making their staff move the contents into the N: drive. However, if they did not know it was happening, it was difficult to stop.

Staffing became an issue as well. Some managers advised that their staff were too busy to deal with the H: drive and there was no budget to bring in extra staff to assist with moving the files.

These were valid issues, but they were the same ones faced by all departments. Proactive departments assigned staff to work on the move over a period of time.

As the deadline approached, managers were given some options to assist with the staffing issue:

  • Assign the task of moving the documents to a staff member and arrange one on one attention with the Records Management Technician; or
  • Ask the Records Management Technician to do the work – but it would be outside her normal hours and the department would be responsible for paying the

No manager chose either of these options.

There were people who simply refused to recognize there was an issue. In one department, the manager advised that all the necessary documents had been moved and what remained could be deleted. When the steering committee checked with department staff, they were advised there was a huge volume of documents that still needed to be reviewed.

Originally, the timeline to unplug the H: drive was six months after implementation of the new shared drive. After two extensions November 30, 2012 was the date that the H: drive would be disabled. A week prior to the deadline, a further extension was requested. As the options for helping to move files had not been used, the CAO decided the deadline would stand.

It was assumed that by the November 30th date the H: drive would be empty – all necessary files would have been migrated to the N: drive and any ROT (redundant, obsolete or transitory) would have been deleted. This was a completely erroneous assumption. On December 1, 2012, a review of the H: drive showed some important records remaining, including some critical to ongoing litigation. The project team took on the responsibility of moving those documents to the N: drive.



There were some unpleasant surprises after the H: drive disappeared:

  • While the volume of requests to the Records Management Helpdesk diminished dramatically, it did not dissipate. Subfolders still needed to be created on a regular basis, especially new case files. That demand continued to put pressure on RIM as it was added to the already long list of regular duties;
  • Because some staff were still not well versed in Windows and some staff still thought they were “special”, the time invested with those individuals remained high;
  • Requests continued to be made to search the H: drive for specific files. Unless it was related to litigation or some other pressing issue, those requests were denied;
  • Some staff continued to resist the N: drive, preferring to use removable mass storage. When discovered, sanctions were taken to rectify the situation. However, short of disabling everyone’s ability to use removable devices, no solution was found to eliminate this



This was the first corporate-wide RIM and IT project. As such, there were many lessons learned.


There needed to be more comprehensive project marketing to senior management, managers and staff. All three levels needed to understand the reasons behind the project, the benefits to them, what the project’s goals were and how those goals would be achieved.

In addition, for most people, a uniform file and classification system is an abstract concept. More education on why the structure was being imposed as well as more of a focus on how the structure worked would have eased much of the users’ frustrations.



The degree of buy-in at the senior management level varied considerably based on the individual’s past experience. If they did not see the value, there was no reason to motivate their staff to do the work. In addition, the makeup of the senior management team changed during the project.

Those departments that had functional and well protected “walled gardens” did not see the need for change. However, for those who were on the outside of those “walled gardens”, the need for change was self-evident.

Withdrawal of support part way through would have sunk the project. Being more aware of those individuals who weren’t supportive of the project would have helped. An absolute necessity was the support of the CAO to back the project when complaints were received about the extra work being required.



Time allocations needed to be a priority – up-front and visible dedication, not “borrowed” from other existing allocations. Staff with domain expertise needed to be assigned to work on the project and their day job transferred elsewhere. Unless the staff member supported the project, or they were dedicated to it, working off the side of their desk automatically made the project a low priority task.

Staff costs and downtime should have been budgeted. Managers were expected to draw on funding that had already been defended to the SCRD’s Board of Directors on the basis of other work commitments. This project was outside the scope of each department’s Human Resources plan. There was a misconception by a few managers that, in essence, this project ‘stole’ money from their budgets without their active participation and in doing so, led to frustrations and resentment.



The representatives on the working committee needed to have been chosen more carefully. Most managers appointed one of their clerical staff. In some cases that was the best decision, but in other cases, their clerical staff were: a) not sufficiently computer literate, b) did not fully understand the implications to their department, or c) were not aware of all the information their department needed or produced. This led to the creation of folder structures and classifications that did not meet the department’s needs and caused frustration for their users; the steering committee should have sought approval from each manager prior to finalizing the folder structure.



Most staff used Windows tools on a daily basis but were unfamiliar with much of its functionality. Concepts such as shortcuts, hyperlinks, searching and ‘scopes’ were unfamiliar to a large percentage of staff, which was surprising to the steering committee. Therefore, the N: drive training was expanded to include some of these concepts and staff were encouraged to take the Windows course offered through the SCRD’s corporate training program.



Different departments managed the same records differently:

  • Human Resources treated criminal record checks as part of an employee file, with FOIPP obligations satisfied;
  • Checks on volunteers were managed by individual departments – some recorded the check as being satisfactory, and then destroyed the document. Others retained the original document;
  • Some volunteers were also employees – the same document would exist twice, and would be managed inconsistently based on the ‘hat’ the individual was wearing at the time the check was performed.

These differences still need to be explored and processes put in place so the same type of document is treated consistently throughout the organization.



FOIPP requires that confidential information protected by the act must not be disclosed. Every claim, accident and litigation potentially involves a unique set of staff and the resulting confidential information that must be protected in order to comply with FOIPP. Therefore permissions on restricted folders needed to be assigned on a case by case basis. Certain permissions were implicit – for example, the Purchasing Officer would have access to bids in progress. However, the vast majority of restricted folders have unique and distinct permissions. The N: drive model required an inordinate volume of folders to implement the appropriate segregation of permissions.

Folder traversal, or clicking through subfolders, in restricted folders was disabled to prevent information leakage via folder names. This prevented ‘browsing’ into permitted folders.

Therefore, unless a user had their permissions set at the top most branch of a folder tree, they were unable to navigate to the restricted folder they needed. The user had to be provided a shortcut which allowed them to ‘jump’ to the restricted folder. Creating the shortcuts rested with the Records Management Technician and was time consuming.



Although it was made very clear in the training that ‘Records Belong to the Corporation’, and this position continued to be reiterated with staff, many still struggled with the concept. Some staff didn’t feel the need to follow SCRD naming conventions and some continued to think there was no problem with copying and/or emailing documents for disclosure outside the organization. There was still some confusion as to what constituted a record vs. a transitory document.

Education and training was critical. Every new staff member who would be accessing a computer attended N: drive training (MINT), usually in the first week of their employment. They only had read-access until the training was complete. All managers and supervisors accepted this as part of the on-boarding process. However, there was a need to work with Human Resources to coordinate new hire start dates so training sessions consisted of more than one person at a time.

The MINT sessions for new staff were expanded to include training on protecting privacy, phishing, and managing hard copy records.

There were funds budgeted for corporate-wide records management training to continue to build on the concepts that had been already introduced to all staff. It was important that staff hear the message from a fresh perspective – an outside expert.



For all practical purposes, IT staff cannot be kept out of ‘restricted’ file locations. In essence, one cannot lock out the locksmith. This came as quite a surprise to many managers, and it was a point that needed to be driven home.

RIM staff are responsible for managing all structure and performing purges of files, but are not supposed to be aware of the contents (or, theoretically, the existence) of ‘restricted’ files. IT are the administrators of all software, so have access to virtually everything contained within the software.

While RIM and IT staff at the SCRD are union members, essentially they have access to personnel records. As a result, IT and RIM staff have both an ethical and legal responsibility to protect personal and privileged information. It is worth investing in tools and architecture to demonstrate the separation of roles has been maintained:

  • Create distinct ‘Directory Maintenance’ users with full access to all folders, but require RIM staff to log in as a separate Directory Maintenance user to perform structural modifications and purges; and
  • Deploy file access auditing software such as Netwrix or Varonis, to track Create/Read/Update/Delete events on restricted folders by any user, including the system administrators.

These proactive steps will help to answer questions about activity by any user or involving any file, not just demonstrate the integrity of the locksmiths.



Despite the challenges, the restructure project had many successes. Although the SCRD did not maintain statistics on duplication and version forks, they were noticeably reduced. For the most part, there was staff buy-in, and in discussions with staff, they found the new structure to be much more intuitive, efficient and easier to navigate.

Switching from assigning specific permissions to named users to assigning users to roles, and granting permissions to those roles, has dramatically improved the ease of user account maintenance for IT. By changing how permissions were assigned, it:

  • Automatically ensured consistent access to information for users who shared the same job function;
  • Created a clearer explanation for why a user might have privileged access; and
  • Reduced the need for both IT and the user to know in advance exactly what they might ultimately need access

Also, by having default-deny restricted folders, managers had to follow proper procedures for managing that access – employees could not be quietly moved to a different job as they likely would not have the access they needed. Once a staff member was moved to a new position, the access associated with their old job fell away. As an example, one of three Infrastructure Services Secretaries could post into the Transit Dispatcher position. Their previous access to records such as in-camera minutes and agendas would fall away, and FOIPP-protected Transit customer information would become accessible, all with two clicks.

The individual file count has shrunk from 460,000 to 202,000 files, with 80% of the reduction occurring in files that had not been modified in more than seven years.

By far, the two biggest successes this project has realized are:

  1. The retention schedule could be applied to electronic
  2. There was a uniform, logical, predictable folder

Below is a representation of the folder structure prior to and after restructure. Note that the “spikiness” has been eliminated and the new structure is consistent and predictable – now never more than four nested folders need to be contemplated when navigating, and no records or individual files will ever be encountered until the 3rd or 4th level.


In July, 2014, the SCRD put out an RFP for an EDRMS. In discussion with the various vendors who bid on the RFP, they agreed the work done on the shared drive would ease the transition to an EDRMS as it was an importable structure.

The lessons learned from the restructure project were incorporated into the implementation plan for the EDRMS and the SCRD went live with “Dr. Know” on May 19, 2015.



The SCRD’s restructure project was a great success, moving the organization from chaos to order. We will continue to build on this success, evolving our RIM practices, workflows and training as technology changes.