Blogs

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

1. We have 50, or 100, or 1,000 terabytes of documents all over the place in our various systems. How do we sort through it and responsibly retain or dispose appropriately within our budget constraints?
2. 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. How do we prepare for and respond to litigation and other discovery, given #1 and #2 above?

My colleague Joe Shepley recently posted You Can’t Do Records Management in SharePoint, and cites Bruce Miller’s discussion of the RM shortcomings of SharePoint. We can extend their argument and say the upshot is that not only SharePoint, but also most of our current information governance technologies and best practices aren’t up to addressing the 2013 and 2018 challenges. And I’d extend it further and say the situation is even worse than this.

Because it’s not that SharePoint – and the other technologies and practices we have – will be inadequate for 2018, let alone 2013. It’s that SharePoint deployments usually fail at RM for 1998, let alone 2003. Most of the problems Joe Shepley and Bruce Miller raise were serious challenges for RM in 1998. The list includes usability in every RM activity, the dilemma that while a separate records repository is untenable for the enterprise, going without one makes it almost insurmountable to get the RM job done, the unwieldiness of administering “types”, the difficulties in getting either humans or machines to reliably declare and classify, etc.

If you were around back then, think about what electronic RM problems you wanted to tackle. These probably include:

1. Managing the electronic analogues of what your paper RM program had been managing. These were the high value, high risk documents you were probably 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, 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 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.

Here are Some Recommendations for Addressing 2013/2018 RM Problems

#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 4 problems I outline above; also “EDMS”)
• 2003 (the magnification of the 4 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 3 questions of any information governance “Best Practices” you consider:

1. Which RM problems in 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.  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.

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.

In a previous post and records management listserv discussion, I asked if anyone had seen any organization where “documents under legal hold” were categorized and thus treated as records:

I have a serious question and wonder if any of you folks have seen the following. We have and it’s worked in very specific circumstances -- where Legal is very strong from an organizational standpoint, RM is in good shape from an operational standpoint (the company's records are in pretty good order), but the company's e-discovery and general litigation readiness situation is in bad shape. The idea is to define “documents under legal hold” as records.

I'm wondering if any other folks have seen this approach, and whether it has worked. I'm also interested in your assessment of the impact of its clash with standard -- or best -- RM practices.

We (Doculabs) came upon this solution already in place and working. It’s a creative solution, possibly a temporary solution, to an organization’s serious problems with litigation readiness. It also dramatically clashes with standard and generally accepted “Best Practices” for both RM and e-discovery. But given recommendation #1 (don’t take “Best Practices” at face value) and #2 (every worthwhile option has plenty of Cons), we should dig deeper. I asked for Pros and Cons and got some. None of the Cons individually disqualify the approach or settle the matter, though most of them were relevant and important. A proper evaluation of this idiosyncratic approach to legal holds would weigh the most important Pros against the Cons, and then weigh the result against the most viable alternative approaches.

My point here is not about the ultimate wisdom of “legal hold records” as an approach to e-discovery. My point is that nothing less than such developing and then rigorously evaluating creative solutions to challenging information management problems has a chance against the problems of 2013 and 2018.

#3. Be pragmatic and control risk.

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 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.

#4.  How to be Creative and Rigorous

I’ll address how to be creative and rigorous when addressing the information governance problems of 2013/2018 in an upcoming post. But here’s a preview. I focus on two fundamental problem solving methods that have served ECM/RM well when used judiciously:

1. Divide and Conquer: Break a big hard problem into smaller easier problems
2. Hammer and Nails: Solve a hard problem with a successful method that has worked on a different but similar problem

These methods aren’t guaranteed to produce the best result – but they have a good chance of yielding an adequate result, which is good enough as we begin tackling the problems of 2013/2018. They both have begun yielding promising results for the three problems I outlined at the top of this post, particularly #1 (how to sort and defensibly dispose of a giant pile of files).