How to Get from 1998 Style Records Management to Information Governance for 2018

9 minute read
Richard Medina avatar

Information Management, How to Get From 1998-Style Records Management to 2018-Style Information Governance
Are you still struggling with the records management problems of 1998? You're not alone.

Here are what we might call 2013 and 2018 information governance problems:

  1. The digital landfill problem. We have 50, or 100, or 1,000 TBs of documents all over the place in our various systems. How do we sort through it all and responsibly retain or dispose appropriately within our budget constraints?
  2. The “systems of engagement” problem. How do we do information governance on our dynamic, sometimes chaotic “systems of engagement”? They use social media, mobile devices and the cloud. We’re feeling our way with some deliberate initiatives to move our business forward -- but they’re also growing organically within and outside our organization. So our problem has three parts: a) How do we meet our governance obligations with our internal use of systems of engagement which we use for collaboration, interactive community building, etc.? b) How do we meet our obligations with our use of external SOE beyond the firewall, with customers, vendors and the public? c) How do we meet our obligations in how we’re integrating our evolving SOE into our more mature systems of record, which help to run our core line of business processes?
  3. The discovery problem. How do we prepare for and respond to litigation and other discovery, given #1 and #2 above?

Most of our current information governance technologies and best practices aren't up to addressing these 2013 and 2018 challenges. But I’d say the situation is far worse than this.

Most of our information governance technologies and practices would fail for records management in 1998 -- forget about 2003, 2013 or 2018. Take a look at most of the complaints about SharePoint’s adequacy for enterprise RM. The list includes usability in every RM activity, such as:

  • The dilemma that while a separate records repository -- a “Records Center” -- is untenable for the enterprise, going without one makes it almost insurmountable to get the RM job done
  • The unwieldiness of administering “types” (records series, classes, etc.)
  • The difficulties in getting either humans or machines to reliably declare and classify, etc.

These were some of the big problems back in 1998 for electronic RM. If you were around back then, think about what electronic RM problems you wanted to tackle. They probably included:

  1. Managing the electronic analogues of the documents your paper RM program had been managing. These were the high value, high risk, highly manageable documents you were already managing in paper according to your retention schedule.
  2. Managing the electronic documents, some of which were records, that were authored or modified by knowledge workers using MS Office and email.
  3. Managing electronic documents that were of lesser value, risk and manageability than #1 above, or were of possibly high value and risk -- but were mixed in with a lot of lower value and risk documents. So part of the challenge was sorting the haystack.
  4. Managing email, particularly the email messages and attachments that qualified as records, being of high value and risk.

These are all 1998 RM problems. They all increased in magnitude by 2003 -- with more records, desktop-authored documents, junky documents, and email -- and there were some additional problems.

Some of these additional problems were caused by the solutions themselves. Most of the email management solutions that were deployed in the early 2000s weren't able to scale or provide fast reliable access to the archived emails and attachments. So many users defected and redoubled their efforts at squirreling away messages and personal email archives, thus rendering disposition impossible. Other new problems arose because of new technologies -- like the internet.

The good news is that I believe with proper strategy and attention to execution, the better ECM/RM systems (like SharePoint) can tackle the problems of 1998 -- and probably 2003! I think most of the failures to successfully address the problems of 1998 are in execution rather than in a collective lack of knowledge in what to do well or a lack in today’s ECM/RM technology.

But most “best practices” for RM and information governance are not up to the task of addressing RM in 2013, let alone 2018. Or some of them are, but we aren’t thinking creatively and clearly enough to wield them effectively.

Most of the technologies relevant to 2013/2018 RM and information governance -- I’m talking about technologies like content analytics, content classification and RM for social media and mobile content -- are not exactly production-ready either. So we need additional creativity and rigor in thinking about how to address information governance during those periods when there are yawning gaps between what we’d like to do in information governance and what we can probably succeed at doing.

3 Ways to Get Beyond 1998

Here are 3 ways -- dare we call them “best practices”? -- to help you get beyond 1998 in RM and information governance, so you can address the information governance and discovery challenges associated with 2013 and beyond, particularly the digital landfill and systems of engagement.

1.Be clear about what problems any “Best Practices” were designed to solve and were actually successful in solving.

For a first approximation, we might divide history into five problem periods:

  • Pre-1998 (predominately paper RM)
  • 1998 (the four problems I outline above; also “EDMS”)
  • 2003 (the magnification of the four problems, plus the internet; also “ECM”)
  • 2013 (the magnification again of the preceding, plus the explosion of “Systems of Engagement” and the digital landfill)
  • 2018 (the magnification of the preceding, plus expected and surprising disruptions).

Now ask three questions of any information governance “Best Practice” you consider:

  1. Which RM problems, from which periods, was it designed to address?
  2. How successful was it in addressing those problems?
  3. Under what conditions was it successful?

Most RM “Best Practices” you assess were probably designed for different problems than the ones you want to address, or weren't really successful when implemented, or were successful but under different conditions than the ones you face.

There’s little empirical evaluation of “Best Practices” in any field, let alone rapidly developing areas of IT and information governance. So the “Best Practices” are often primarily the ones that have been most successful in reproducing themselves. None of this means that you shouldn't follow them. They may be the best practices you can get. But you should try to be clear about the limits of their applicability and how best to use them.

#2.Recognize that every option worth considering has Pros and lots of Cons.

The norm is that few options are excellent, even if executed flawlessly, and no options in ECM or RM are executed flawlessly. There are always deviations from the roadmap and compromises. So your decision making has to be subtle.

You are deciding among options the best of which is good but not great. Or you are choosing the least bad option.Or you should choose the option that looks pretty weak if all were to go 100% as planned -- but is the best option if you take into account the risk and cost of the initiative deviating from the plan.

Learning Opportunities

Therefore, downsides or Cons to an option are relevant and often important -- but they should not kill the option. Objections are just line items in the “Cons” column of your evaluation, to be weighed first against the Pros and then against all the other contending options.

#3. Be pragmatic.

Define your RM initiative objectives -- your ends -- so that they meet your organization’s needs and they are achievable. Achievability means that you probably have to reduce the scope from what you might accomplish if you had less restrictive budget constraints, less likelihood of initiative failure, with less negative impact from such failure.

Here’s an example. Records management includes both managing a retention schedule policy and executing (or “enforcing” or “fulfilling”) it. Execution today involves doing classification, retention and disposition of the files in a number of ECM systems and other repositories in the organization. That’s a 1998 problem that folks are still wrestling with.

But today in large organizations, with tens of independent business units, often across several countries and involving hundreds of repositories, both policy management and policy execution are very complex endeavors. It’s likely that if such organizations tried to tackle both policy management and policy execution, they would fail at both. So a strategy based on achievability might focus first on policy management (perhaps using a simple spreadsheet or a glorified spreadsheet application from IBM/PSS or RSD), and then incrementally address policy execution.

Being pragmatic means that you should be creative and rigorous. When you weigh your alternatives’ Pros and Cons, a solution that gets you only 80% of what you want but that can be almost certainly executed beats the solution that gets you 100% of what you want -- but has a significant risk of project failure and big negative impact when it does.

The problem with risk and risk assessment is this. Most technology vendors and folks involved in ECM/RM strategy and implementation don’t effectively take into account deviation from the roadmap. From the business case, to the rollout plan, to change management, to the technologies selected, the assumptions are that 1) the initiative will not stray significantly from the roadmap, and 2) if it does stray, the project benefit will track the deviation proportionately. Both of these assumptions are usually wrong.

The second assumption means that you get 100% benefit if you follow the roadmap faithfully, 90% benefit if you’re 90% faithful, 50% benefit if you’re half faithful, and so on. But this is almost never the case because complex initiatives and technology have lots of dependencies. So when things start to deviate, the problems and delays cascade, users get frustrated and defect, and you soon have a failed project. What starts as a relatively small deviation from the roadmap in a complex project with complex systems can leave the RM system difficult to use and thus nearly useless, causing mass user defections and project failure.

The moral of this point is to clearly understand how complex and thus risky your initiative is, and err on the side of simpler and safer initiatives. Plan your initiative so you can withstand serious and arbitrary delays or deviations and still declare victory

Finally, being pragmatic does not mean being shoddy, either by solving the problem at hand in a way that hinders other initiatives or the “big picture,” or by neglecting compliance obligations, or by accepting too much risk. Being pragmatic means assessing these three issues and ensuring that they constrain your approach. Then be creative and rigorous in how you develop and assess your options to achieve your RM objectives.

Title image courtesy of Tilemahos Efthimiadis (Flickr) via a Creative Commons Attribution-ShareAlike 2.0 License

Editor's Note: To read more from Richard, see his How to Succeed at Mobile Content Management

About the author

Richard Medina

Richard Medina is co-founder and a Principal Consultant at Doculabs. Doculabs is founded on three simple principles: objective recommendations, analysis grounded by benchmark data, and a specialization in content-based applications.