This post originally appeared on the CMSWire blog.
If I had to encapsulate in one phrase everything I’ve learned about doing information governance (IG) and related disciplines over the last 20-odd years, it’s that you should be pragmatic. Being pragmatic does not mean being shoddy – whether 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 being creative and rigorous in how you develop and assess your options to achieve your IG objectives.
Here are four examples of such rigorous, creative pragmatism:
Clarify the scope of IG, and don’t overreach.
Start with a clear definition of what you’re trying to do. The best general definition I've seen for information governance is Robert Smallwood's: "Information governance is the control of information to meet your legal, regulatory, and business requirements." It's a great start because it's accurate and simple: It avoids the trap of being a laundry list written in legalese.
But I’d respectfully tweak it to clarify it and guard it from overreach and failure. I’d say: IG is the control of information to meet your legal, regulatory and business risk requirements. Information governance doesn't address all your business demands; its primary focus is on "defensive" business requirements, as opposed to "offensive" business requirements. IG’s primary focus should be on controlling the risks and costs (primarily risk-related costs) of your information. It doesn't primarily address the offensive requirements of operational efficiency or meeting customer demands; its primary focus is not on helping you meet your sales numbers, improve the time needed to bring a product to market, improve customer retention, or rebrand your company. These may be secondary benefits of good information governance, but defense should have priority.
This narrowing of focus is critical, as no other discipline in your organization can do the job of information governance – a job that’s becoming very complex, very quickly. If your IG program succeeds at protecting your organization from information risk and risk-related costs, it’s a successful program. But if it fails to protect you — whether or not it improves the operational efficiency of some of your business processes — it’s a failure.
Always design your approach to optimize partial failure.
Almost everyone — 100 percent of the vendors and 99 percent of organizations — assumes that your new processes and technologies will work as advertised. They then analyze the risk reduction and efficiency impacts based on that assumption in their business cases, operational planning, etc.
But the systems never work exactly as planned, and the implementation never follows the roadmap exactly as designed. It may be an acceptable or even happy failure, if what happens is okay or even better than anticipated, but your final process always differs from how it was originally designed. And the impact is usually bad. So be sure to model failure and “half-baked” scenarios — scenarios where you have to stop at various points in your roadmap. Make sure you can optimize a completely uneventful, successful implementation. But have lots of “Plan Bs.”
If you want "offensive" benefits as well as "defensive" benefits, do ECM first.
The past 20 years of enterprise document management systems and then enterprise content management (ECM) have demonstrated that leading with records management (RM) or IG is a bad approach if you want to meet significant offensive requirements in addition to defensive requirements. In many instances, leading with RM or IG is actually a bad way to meet even your defensive requirements — if, for example, you try to implement RM or e-discovery technologies without having adequately managed repositories (and thus a fairly stable ECM program).
Recognize that most “best practices” may not deserve that title.
Most “best practices” you may be considering for IG and RM were probably designed for different problems than the ones you want to address — 1994 or 1999 problems, rather than 2014 problems. Or they weren't really successful when implemented. Or they 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 IG. So many of the “best practices” are 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.
I’m acutely aware that the last point may apply to everything I’ve said in this article. So this is probably a good place to stop.