Extracted from a speech given to the 4th Information Management & E-Discovery Summit, Sydney, Australia, 10th June 2010.
Digital information is everywhere. One of the biggest problems for organisations is the volume of so-called unstructured information commonly found on network drives and in email folders.
Electronic document management systems (EDMS), often now known as enterprise content management (ECM) systems, are seen as the panacea to this problem, however unless they are mandated for all unstructured information, users will continue to have some level of discretion about what goes into them.
In response to this, organisations may implement an email archiving system to at least capture emails, or use back up tapes as a form of archive tape, or move information to some other form of long-term storage.
All of these options have shortcomings, not the least of which is that they may end up storing information for much longer than necessary, thereby exposing the organisation to the risk of this information being discovered.
So, you are probably a bit confused about what to do, and what direction to take.
(a) Acquire and implement a system in the hope that you can get users to put unstructured information into it, and somehow manage the information that’s not captured, including by using email archiving or network drive archiving/duplication?
(b) Acquire, implement and mandate a system across the organisation for all unstructured information?
(c) Don’t acquire anything, and risk manage it all?
If you decide to go with option (a), here are some suggestions for managing unstructured information more effectively in organisations.
Have a good information management strategy
Not everything (usually) needs to be managed in the same way. It would be an unusual organisation that wanted to manage everything in exactly the same way. Some information must be managed well, some less so.
A good strategy will show a good understanding of the following elements:
- Your organisation’s digital information assets.
- Your compliance requirements and standards, including records management best practice, standards and compliance needs.
- The way your users, and your organisation, currently do their work.
- Your current technological environment (your technological limits or opportunities).
- The external information management and electronic document management environment (what is happening out there).
- How contemporary electronic document management systems work, as they are not all the same.
And then develop your information management strategy and EDMS implementation plan accordingly.
Communicate this strategy through information provided via the intranet, all staff emails, desk drops, information provided through managerial meetings.
Make sure there is effective communication at all phases of the project
This is essential, almost critical to success. More is better. Best projects have very good communication.
Keep people informed and they will keep up with you. They may even use your system.
When considering change management, remember the technology adoption lifecycle and the five broad categories of users.
There will always be innovators, early adopters, the early majority and late majority and finally the laggards.
And yes, unfortunately, these are often (but not always) reflective of the ages of your staff. Target your changes, and the required training, accordingly.
Have realistic and understandable policies and procedures for managing electronic documents
A key element in any information strategy, therefore, is having and implementing an effective policy that addresses the management and retention of information.
But, make sure it is a policy that everyone can access, understand, and put into practice. Recent research conducted in Malaysia in 2004 and 2008 indicated that less than 50% of organisations had a policy for managing electronic documents, and of the 50% that did, less than 25% of respondents complied with it. The one’s who didn’t comply said they didn’t have the time, or found it too difficult, to do so.
Interestingly, the research also showed that most respondents said they wanted such policies in the form of guidelines for managing electronic records.
What does this research indicate to us? That good communication and effective change management are critical to support policies and help users to use systems to keep records; if you don’t have one, you probably won’t succeed.
Have a good, realistic defensible, and well considered project scope document
Don’t underestimate just how hard it is to implement these systems. After all, you are making a fundamental and sometimes unintuitive change to the way people manage information.
This is a key part of any proposed project. What are you trying to achieve?
Installing a new product is easy, changing staff behaviours is very difficult.
What’s your objective? Why is it your objective? Is it compliance, if so, compliance with what? There would be few organisations in Australia for which compliance with something is the only driver for an organisation-wide EDMS.
When defining the project scope and project plan, you should have a really good handle on the following:
- What information are we actually trying to manage?
- What are the actual compliance drivers? (see below)
- How do people actually manage digital AND paper information now?
- What are the risks with current processes and practices?
- What risks are you trying (or needing) to mitigate against?
- What is happening externally?
A simple rule of thumb that seems to work in most cases is this: the greater your risks of not complying or needing to be accountable (including because of anticipated litigation), the more likely your users will manage your information well.
Or, to put it another way, you are more likely – and probably should – spend most of your effort managing the information that you have to manage well.
There are several risks associated with users continuing to use uncontrolled systems such as network drives and email folders to manage records. Making them aware of these risks through policies, procedures or guidelines can be a good idea.
The risks are:
- Being unable to find and produce information required except through costly data recovery or forensic processes.
- Not meeting compliance requirements, that is, managing information poorly.
- Keeping information for longer than required.
The longer we keep information that doesn’t need to kept, the more we expose the organisation to potential embarrassment and expense through e-discovery and other forms of information retrieval.
Understand your real compliance requirements
What are your actual compliance mandates? If users know what they are, they may respond better to a new system. Often this is not well communicated.
It is very important to have a very thorough understanding of your actual compliance requirements.
And then, based on that understanding, take a risk based approach to the management of your information. This will in turn inform how you approach the issue of user uptake of a system.
In August 2007 the Management Advisory Committee (MAC) of the Federal Government’s Public Service Board published one of the most useful common sense documents to come out of Canberra, ‘Note for File’.
The report acknowledged the key difficulties faced by agencies in managing information, the problems of information stored unofficially on network drives and in email and other electronic systems. It recommended agencies take a risk based approach and prioritise their recordkeeping attention on activities that pose the greatest level of risk.
Get senior management support
Will your CEO use the system? If not, why not? My CEO uses our system. It’s a great selling point for staff.
Have end user participation and contribution from the beginning
This is part of good business analysis.
Understand your organisation and its business needs, preferably with some product knowledge behind you.
Find the key users, the early adopters. Consult. Listen. Identify problem areas.
BUT! Recognise that users are not always right and remember that customisation can be expensive.
Have well defined system requirements – but don’t over do it
Understand your business needs and define your requirements for a system carefully.
Understand and define what the relationship will be between the existing systems, drives and email folders and the new system, and how end users will work in the future. Storybook it even.
Many products probably already do what you want. These systems offer users folders containing documents, wrapped up in access, security and audit requirements, sharing and collaboration models, with retention and disposal capability.
The more you customise the base product, the more expensive and complicated it gets.
Find the product that best meets your needs
Find a product that is the best match for your business needs, not one that has the best marketing team, or is flavour of the month. Many products have been around for years. They started out as DM, became EDM, then EDRM, and are now ECM systems.
There is a lot of maturity in this market and, in recent years, a great deal of upheaval and acquisitions.
TRIM was bought by HP. Hummingbird and Vignette were acquired by Open Text. The old iManage was bought by Interwoven and became Worksite (and Mailsite), then was acquired by Autonomy. Documentum by ECM, and in the wake of those acquisitions Alfresco appeared.
Really get to know the product and what it does, including your infrastructure requirements
So, what’s the best system for users to use? One that meets your objectives. One that will:
- Meet your business, regulatory and litigation compliance requirements and standards for keeping, storing or managing information and records.
- Be used by users, with minimal training.
- At a cost that is affordable and gives true return on investment.
It doesn’t, necessarily, have to manage everything.
Don’t forget about recordkeeping requirements. If you follow the principles outlined in ISO 15489 you are more likely to have good records that will meet compliance requirements.
A realistic project plan AND change plan
Have a separate change and project plan, although they may be in the same document.
I’ve seen extraordinarily complex project plans for projects that didn’t succeed, and very simple project plans that did succeed.
Success can be as much about a great plan as it is about the people and resources doing the work, and the capability of the users in the organisation to change.
Failure, on the other hand, is often about poor scoping and/or scope creep, poor understanding of the organisation’s capability for change, poor change management, poor communication, user rejection, and, frankly, the wrong choice of technology.
As they say, successful projects have proud parents, the unsuccessful ones are orphans.
Have a great change management plan
You need a good change plan, especially for the late majority and late adopters. In fact, some people suggest you should only target these groups for change.
Change is not popular. People fear change and tend to be somewhat parochial and protective of the technology they have got used to.
Moving from a paper-based to an electronic-based way of managing information is, perhaps, one of the greatest challenges over the past decade.
Understand the technology adoption lifecycle.
Software – know your proposed or acquired product – well.
I mean, really well. How often do we see organisations evaluating and acquiring a system, and then engaging a systems integrator to implement a product, without having a good idea of how the product really works in the first place?
This is as much about the acquisition process as it is about the implementation process.
In one case I was involved in recently, the organisation spent a lot of money getting external consultants to help define the business requirements of the system, which were then passed to an integrator who did exactly what was required.
Problem was, the system then failed because it was not designed to work in the way that the users had requested, the consultant had defined, and the integrator had made it work. Find out how other organisations use the same product.
You should also know your vendor very well, too, along with any proposed systems integrator.
Customise only when necessary
This is an interesting one and in many ways related to the previous point. Clearly it is a good idea to engage staff in how they want a system to work.
However, many systems are, by default, capable of doing most of what the majority of users want without customisation.
You need to tread a very fine line between listening to users and implementing what they want.
The more complex your project in terms of customisation (in particular), the more likely it is the majority of potential early adopters will miss out.
Maintain sufficient flexibility to get your project over the line within time and budget.
In a case I was involved in last year, the organisation persisted in developing a complex and expensive set of customisations, when the product out of the box actually met 98% of user requirements.
Don’t forget about recordkeeping issues, including retention periods for the information. This is closely linked to your policy.
Remember, keeping records for too long can be just as risky as not keeping them, because it exposes the organisation to legacy information that should probably have been deleted.
Use qualified resources
Use qualified resources, people who have a good track record.
Post implementation evaluation of the project
Look around at other projects. Learn the lessons. Communicate them!