If I had to encapsulate in one word everything I’ve learned about doing IG and related disciplines over the last 20 odd years, it’s that you should be pragmatic. Being pragmatic doesn't 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 being creative and rigorous in how you develop and assess your options to achieve your IG objectives. Here are three examples of such rigorous, creative pragmatism:
Always design your approach to optimize partial failure. Almost everyone – 100% of the vendors and 99% of organizations – assume 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, in that what happens is okay or even better than anticipated – but your final process always differs from how it was originally designed. And the impact, usually, is 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 really want “offensive” benefits in addition to “defensive” benefits, then do ECM first rather than IG. The past twenty years of EDMS and then ECM have demonstrated that leading with RM or IG is a bad approach if you want to meet significant offensive requirements in addition to defensive requirements. Leading with RM or IG is actually often a bad way to even meet your defensive requirements – if, for example, you try to implement RM or e-discovery technologies without having adequate managed repositories (and thus a fairly stable ECM program).
Recognize that most IG and RM “Best Practices” may not really deserve that title. But 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 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.
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.
#information governance #Toolkit #InformationGovernance #IG #ElectronicRecordsManagement