Magazine article Information Management

Case Studies in Managing Change

Magazine article Information Management

Case Studies in Managing Change

Article excerpt

[ILLUSTRATION OMITTED]

I was once a part of a RIM department that provided a textbook example of how not to launch a new tool and a new paradigm to go with it. Years later, I took part in a very successful implementation of a strategy change that included an end-user behavior reset and adoption. In this article, I discuss why one change-oriented project failed and the other thrived.

A Failed Approach

The textbook failure--mea culpa--was in transitioning to a new document management system (DMS) in a politically driven government agency with about 600 staff. There was a newly elected mayor and a newly appointed agency president.

The Environment

The electronic records infrastructure was made up of rogue file shares on numerous onsite servers. The program deliverable required a transition from this unregulated, decentralized approach to a centralized DMS with unified taxonomies and retention that would manage records in place and provide robust searching capabilities to find and share documents.

RIM Objective

Our task was to deliver this solution enterprise-wide. I arrived as the last member of a newly established records and information management (RIM) team. This wasn't to be merely a transition or migration of electronic records into a new solution, it would also be a paradigm shift in how people saved their work, with greater rigor around managing agency assets.

Further, most of the agency's work force members were seasoned users who had become accustomed to the way they had stored electronic records over the years. And that's what it essentially was--mere data storage.

Project Issues

I noticed issues from the beginning that led to the project's failure, including these:

We didn't prepare adequately. The RIM leads frequently met with the vendor development team and information technology (IT), but not with the users. They did not plan introduction meetings or quick announcements at an all-hands meeting to introduce this project, even though it affected everyone. There were no change roadmaps, no behavior studies or analytics, or even heat maps to promote the transition.

We did not promote the project. This seemed to be a highly confidential project with little publicity even though it was to be delivered to all internal users. Data was pulled from the back-end for strategizing, but there was no transparency with those outside the team.

We did not allow users enough input. We selected individuals from different departments to be part of a pilot group to help develop and embrace this business shift, but these sessions were sporadic and driven by the solution, which didn't leave much room for input from the users. The message they received was, "Here is what you are going to do." This eventually led to one user saying, "This is simply not going to work and I won't do it."

We tried to do too much, too fast--and it was too complicated. As we created process workflow maps, I immediately noticed that our re-engineering plan was going to create culture shock for anyone creating and saving a document. We were trying to "boil the ocean" instead of taking small steps, building confidences, and collaborating on successes.

Despite the concerns I voiced several times, C-level staff took the aggressive stance that we were going to take advantage of the solution's sophisticated services. This meant changing users' practice of saving documents any way and anywhere they wanted to forcing them to use a micro-managed, metadata-driven repository. This was a complete disruption to the ecosystem. Users questioned the necessity of the change and asked how the benefit of making it would outweigh the burden.

It was a large burden: The design included thousands of retention categories, including more than 231 document types within a single department. To save a document to the tool, end users were required to populate 14 fields. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.