Guerrilla Tactics – IG Whether or not they want it

On September 18 the Information Governance Initiative hosted a twitter chat to discuss their 1^st annual report. At some point in the chat I referred to myself as using Guerilla tactics to apply Information Governance practices in client projects.

Question 3 of the chat was “Do you have any active InfoGov projects under way at your organization?” Now, I’m a consultant so for me the question’s really about my clients’ organizations. My answer to the question was “No. My client has biz projects that are being framed by good #infoGov practices.” Followed by my comment “I am turning into an IG Guerrilla Tactician.”

Just because your client doesn’t have IG budget, programs, or projects, doesn’t mean that good IG practices can’t be infused into the projects that are happening.

I have yet to work on an Information Governance project for a client – they just don’t want to hear about it. That doesn’t mean that I execute projects while ignoring IG practices. For example: I am currently working on a couple of SharePoint projects for a client. One project is to develop a site for their regulatory team to build and submit applications to a regulator. The second project is to create and publish field reference manuals. Both of these projects have concrete business objectives; neither has any sort of IG or IM as part of the mandate. In fact, until I got involved no one was even thinking about applying any sort of overarching IG/IM policies or procedures into any of the projects, much less on an organization wide basis.

The client’s environment is rife with poor information governance and management practices:

• Content duplication;
• Emailing attachments instead of links;
• Information silos;
• Keep everything forever;
• No centralized accountability for information;
• Won’t mention the fustercluck that is their SharePoint environment;
• No metadata standards or taxonomy;
• Severely limited search capability;
• No use of automation for capture, tagging, sharing, or routing of information;
• A rudimentary file plan and retention schedule that is largely ignored;
• Etc.

The funny thing is that many people at the client know that much of what they’re doing is wrong, even if they don’t know why it’s wrong. What they don’t know is how to eliminate the bad practices and replace them with good practices (forget “best practices” they really only exist in theory). They also don’t know, in all cases, what a good practice is.

We start with Principles of Holistic Information Governance (PHIGs). The clients like them because they’re common sense and written in English; they’re also loose enough so they can be adjusted for the business being supported / addressed. We also use an iterative approach to designing and building the solution (it’s very agile-like) that involves all the major business and technical stakeholders (the pure tech stuff takes place off-line). Our focus in these projects, beyond solving the problem, is really on two things: 1) eliminating waste (effort and info); 2) delivering a solid user experience. We also impose a lot of rules around how information is created, managed, and delivered. To illustrate:

1. Thou shalt send links, not attachments (client VPN is an obstacle that’s being dealt with in a separate project);
2. Thou shalt use versioning rather than sending more copies with “v2_0_3_d_SOMEGUY_Edits” in the file name (change mgt and training required);
3. Thou shalt label thy contributions appropriately (we’ll help by implementing some workflows and forms);
4. Thou shalt not make copies when thou needst them not (metadata and user roles will help users find what they need, proper backup & restore will be implemented);
5. Thou shalt not keep thy stuff indefinitely (ah, retention and disposition policies will finally be enforced);
6. Thou shalt not facilitate unauthorized access to information in thy care and keeping (keep it in the repository, where it can be secured);
7. Thy content is not thine, it’s thy employer’s.

As we’re working on things like metadata models, user roles & groups, user interfaces, and other stuff, we’re doing so with the view that we’ll be creating a set of practices that the organization can adopt for all projects going forward. We’ve even got a couple of really hot SharePoint people on the project that are helping us to define repeatable SP practices. There’s only one tiny problem with our approach …

At a recent Steering Committee meeting, our venerable Project Manager invited two guest speakers: 1) Jason – to talk about SP standards and best practices; 2) me – to talk about PHIGs and IM best practices. Jason and I said the same things, albeit focusing on our particular areas of expertise. All was well until the VP of IT realised that while we were doing some really good things on the project, these things were totally under the radar. Much to her credit, instead of demanding that we revert to the client’s methodologies (which were in part responsible for the current situation), she began asking what needed to be done to leverage the good things we’re doing on this project and apply them across the organization.

So what’s next? Well, the client is having me get involved in at least one more of their projects; SharePoint will be the deployment platform and IG will provide a foundation. It’s not a SP or IG project; it’s an HR project that relies on information. Sometime in October Jason and I will be invited to speak to the corporate governance council; Jason will talk about SharePoint and I’ll talk about PHIGs. The whole point of our attendance will be about how to get this heavily regulated client to adopt good practices for managing their information and the technologies they use to access it. Pretty cool, I think (I might even wear a tie).

Sometimes you’ve just got to sneak IG into your clients’ projects the same way that you sneak veggies into a recalcitrant child’s diet.