Information Governance Insights: Failure Is Not an Option
An information governance program is a massive undertaking and, as with anything worth doing, there are a number of things that could go wrong. In this month’s article I’d like to look at a few of the more common issues you might encounter as you develop your program and offer a few suggestions on how to avoid them.
You can’t always get what you want
Oddly enough, the most common issue that comes up when implementing or redesigning an information governance program is a lack of clear goals, expectations or business requirements. The biggest reason for this is not speaking with the right people to gain that understanding. There’s a lot of reasons for this, but ultimately it is the responsibility of Leadership to take the time to meet with the program staff (or send a surrogate that has clear direction) to ensure there are no misunderstandings for the goals, expectations or requirements as to what is to be done. I know that should be obvious, but you would be amazed how often this doesn’t happen.
Another critical component of this issue is a failure to understand the impact of the changes you are making with the program will have on the strategy and architecture direction of the organization. Eventually the improvements you will make to your program will involve technology. You need to meet with the IT staff to understand how these improvements affect what they have planned. The other side of that coin is that they have plans of their own and you need to understand what they have in mind as well because there are things they are doing that affect your program as well. If you don’t get it by now, you need to TALK TO PEOPLE! COMMUNICATION IS GOOD PEOPLE!
Perfect planning prevents…
Information governance is many things and it is very easy to lose yourself in trying to do too much at once. The best way to avoid this is to take a step back and create a strategic plan. You have to look at everything that needs to be done and develop a plan that can be built on over a long period of time that offers measurable, cumulative value to the organization. That was a pretty important statement back there, if I do say so myself, you should look it over again. Go for a number of “easy wins” if you’re just starting to demonstrate to The-Powers-That-Be this “IG Stuff” is worth it and you know what you are doing before taking on something that will take most of the year to realize any benefit.
You can lead a horse to water, but…
Congratulations! You successfully navigated all the other pitfalls and moved your program along according to your plan! Unfortunately, nobody likes it and refuse to use your shiny, new process. It happens a lot. One of the common reasons of this is that many of the “improvements” actually add more work for the people that have to use it. You can mitigate this during the development phase of the implementation by understanding the affect on the staff the new process is creating and working to make it as user friendly as possible. This is where you must bring out your User Experience and Change Management skills to put yourself in the user’s shoes and do what you can to make the change as effortless and understandable as possible. Cursor movements, tabbing, field auto-population, standardizing workflow routing and comprehensive training go a long way to easing user concerns.
Allowing old habits to persist once a new system is in place is also a major cause of adoption failure. Most organizations have an intricate web of network drives, with an endless pile of personal folders, where the staff has squirreled away their secret stash of information they use to do their daily business process. They will never leave this comfortable environment for your nifty, new Electronic Document Management System willingly. Migrating all that junk into the new system is not the answer either because it is too time consuming and expensive. So what do you do?
A technique I have used successfully in the past is to set these network drives to “Read Only”. This preserves this important source of data, but doesn’t add to the problem. Then the staff can migrate what they need into the new system as they use it. Over time the migration will occur naturally and what is left can be disposed of after a certain time passes. Change management is all about the art of compromise. If you work with people, they will generally work with you.
These are some of the more common reasons projects fail and a few suggestions I’ve used to deal with them. The bottom line is these things happen and you need to be prepared for them when they do. Good luck!