After years of consulting, I have learned that the biggest problem we face when looking at implementing a document management system is the status quo. People, whether happy with existing technology or not, have developed their own work methods, workflows and ways of collaborating with others. Many people are left to their own methods because the corporate mandated system does not exist, does not work or it increases the amount of work. For these people, their current personal “system” works, and they only grudgingly use the corporate “system” as little as possible.
When corporate comes in with a “new system,” the eyes roll and the phase, “Here we go again…” can be heard muttered by many. By now, many workers have gone through at least one document management system and may have gone through several–all of which have not worked in the eyes of the people who are asked to use the system.
“At my last job, we had XYS system, and it was a total failure, everybody hated it and nobody actually used it. I would do all my work offline and only upload the final document. I don’t think these systems work.”
The problem is that often the new system attempts to “pave the cowpath” (unlike the advice from Michael Hammer, which was to not pave the cowpath) and hope that people will follow a familiar work process but will have better tools to work with. This typically results in a mismatch between technology and business processing and begins to fail because people are doing essentially the same thing, but it involves more clicks to get to a document, “check” it out, get a link to send and return it to the “repository.” In my first SharePoint implementation, people basically refused to use it because it caused them extra work (clicks) over the beloved file share and “C” drive.
People understand extra work almost immediately and, just as immediately, revert back to their old way of doing things, such as emailing a document instead of sending a link, storing documents on their hard drive instead of the system library and avoiding workflow routines by emailing documents. In fact, in my opinion, email is still the primary application that people use for work and still want to use.
Why? Because they control it. It is their program; they set it up the way they want to work; they created their own “filing system” of folders and subfolders; and it works. They don’t want to index, or tag or look at a drop-down list of index values: They want to use email because they don’t have to do any of that extra work.
MORE: Keep or Destroy Documents? Is There an Answer?
Having just finished a project to implement a cloud-based document management system, I did an audit of the users and found that even though they clearly understood the benefits of the new system, and appreciated the new features, they still preferred in a day-to-day setting to revert back to storing document on their laptops/file shares and emailing documents instead of links. A simple review of emails sent confirmed this.
We did get tough on these people and made the share files read-only, which partly cured the problem, but we still had people using their hard drives for storage. We could “track” this by monitoring their usage of the cloud-based program by looking at their logins, uploads and downloads. After reviewing the report, I went to the various people who were not using the system and asked why.
For the most part, the answers were not consistent with the facts: “I wasn’t trained; I tried to do “this” and it didn’t work; or I was in a hurry and didn’t understand how to do the link-thing…” We did uncover some reasonable problems that were solved on the spot and some that actually needed to be looked into and solved. But to make the system really work and be used, we had to basically destroy the old system and make it so hard to use that the users were forced to use the new system.
While this sounds harsh, it is a fact that when people have used email and file shares for 20 years they are not going to switch over night. The key to success is monitoring for usage, patiently making corrections, doing spot training when needed, making previous work processes unavailable, actively solving user problems, and emphasizing the benefits. If you say, “You can lead a horse to water but can’t make them drink,” you have lost the users.
