I wanted to try something a little different for this post. I’m doing an assessment of what went wrong with Alfresco for a Canadian university. They purchased Alfresco back in 2008/09, initially to handle some of their web content needs. Things haven’t gone so well. Below is a quick wrap up email I sent to the project sponsor after the first few days of stakeholder (patient?) interviews …
I just wanted to give you a quick recap of the last few days:
- Of the people I spoke to, no one advocated for getting rid of Alfresco
- Unless something to the contrary comes up in the next few weeks, there is no reason to believe that Alfresco is the problem
- Alfresco was likely the wrong choice back in 2008/09, but the product and company have since matured to the point where it’s no longer the case
- There is a general feeling that Alfresco is/was underfunded, under-resourced, and lacking in executive buy-in / mandate
- It appears that there is no executive support or commitment to mandating Information Management practices using Alfresco as a standard tool set to implement
- There was/is an element of Alfresco (or any ECM platform) being a magic bullet, rather than a platform on which to build solutions
- It seems that all the Alfresco initiatives over the years have been done as individual projects, rather than under a program of managing information
- The consulting services engaged focused on the mechanical & “how to” aspects of Alfresco and related tools, without any of the advisory & “what should we do, why we should do it” services
At this point it’s my opinion that the problems are cultural and environmental. If the culture and environment change Alfresco will succeed, providing the right resources are engaged in the right way. If the culture and environment don’t change Alfresco will fail, as will any other platform brought in.
On September 18 the Information Governance Initiative hosted a twitter chat to discuss their 1st 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;
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:
- Thou shalt send links, not attachments (client VPN is an obstacle that’s being dealt with in a separate project);
- 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);
- Thou shalt label thy contributions appropriately (we’ll help by implementing some workflows and forms);
- 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);
- Thou shalt not keep thy stuff indefinitely (ah, retention and disposition policies will finally be enforced);
- Thou shalt not facilitate unauthorized access to information in thy care and keeping (keep it in the repository, where it can be secured);
- 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.
Back in June (2013) during the ARMA Canada Regional Conference I attended a pretty good session delivered by Emily Gusba (Information Management Lead, GCDOCS Implementation at Natural Resources Canada). Emily was accompanied by Trevor Banks and Julie Colgan (ARMA Int’l President, Julie rocked as a last minute walk-on for Debra Power who is all better now). The session, titled Learning IT-ese, was about IT and RIM (Records & Information Management) having to work better, together. Essentially, the point was that RIM had to learn to speak IT.
Now, I’m all for IT and RIM working better together, but I don’t mean what you think they (see above) think you think they mean. Simply put, we’re not on the same page. Bear with me a bit …
IT and RIM are both service providers within their organizations, n’est pas? They serve the same clients, though they provide different but complementary services. RIM and IT also have a symbiotic (some would say parasitic, but that’s just mean) relationship with each other. The truth is that one’s not much good without the other.
RIM and IT need to join together, not to serve the purposes of RIM, but to serve the interests of the entire organization. Having RIM sit with IT to explain RIM’s wants/needs (in whatever language they choose) is, in a word, crap. IT and RIM need to approach stakeholders with a joint message; “Your stuff needs managing and governing and we’re the team to do it for you.” Yes, children, RIM and IT need to get together and become a formidable team. They need to approach the cheque-writers (notice Canadian spelling, thank you) as one.
When Marketing wants to migrate from one platform to another, RIM/IT needs to be in those meetings TOGETHER. When HR wants to implement a new HRMS, IT/RIM needs to be there to make sure all that information flows correctly throughout its lifecycle.
When I talk about RIM I don’t mean the RIM we knew from the paper days; I mean what RIM can and should be in 2013 and beyond. Drop the Records reference and focus on the Information and the Management, regardless of the medium that information is created or stored in. Join with IT to become IM&T (the M comes before the T because you need the management bits before the tools) and provide your clients the information services and governance that they need. In some organizations there still is, and always will be, the need for the Records part of RIM. However, the Records function really needs to be a subsidiary of the IM&T group.
If IT provides the plumbing, and information is akin to water, then RIM performs as the treatment facility. IM&T not only gets the information to you, they make sure that the information you get is clean and safe. (Sorry about the crappy analogy.)
Yes, RIM and IT need to work together, but not as two different parts of the organization. They need to join and serve the organization as a single unit. I’m not saying that RIM professionals ought to become developers or systems analysts. Nor am I advocating for IT professionals to become Records Managers or Archivists. What I am saying is that the IM&T TEAM needs to incorporate roles that address the Information Management and Governance needs as much as the Information Technology needs. Separating RIM from IT hasn’t really worked all that well after all, has it?
Over the last couple of days I’ve seen/heard some comments that Big Buckets don’t work well in Records Management. Uhm, you’re doing it wrong.
I suspect that a large part of the issue is that classification models are too granular and too tightly coupled to the retention schedule. I’ve been involved in a couple of projects where this was the case. One client understood this, made the necessary adjustments, and achieved success. The other client … held steadfastly to granular, overly complex schedules and models, and is only now (4+ years later) re-examining their original plan.
You wanna make big buckets work? Here’s some simple stuff you need to do:
- Simple, function based classification models;
- Uncouple classification from retention;
- Automate & hide RM tasks from users (they know what they’re working on and don’t give a rat’s ass about RM – I know, hard to believe);
- Classify on capture/creation;
- Check out the cool diagram;
- Review periodically.
Note: During a Google Hangout yesterday (featuring @cawprhyd, @tchernik, @lllivingston, and some others whose twitter id’s I don’t have handy) the subject of disposition reviews for automated disposition came up. My position is pretty simple – you don’t need them. Sort of. If you assume that classification and retention have been agreed prior to implementation, and that content is classified up front, there is no need to review. Of course, this works only on a day forward basis and requires that whatever tools you have in place can do the legal hold and suspend disposition processing / time clock when needed. You really should follow the twitterers that I’ve id’d here – they’re pretty smart.
By now all of you (yeah, right) have read my Principles of Holistic Information Governance (PHIGs) post, viewed the slide deck, and some of you attended the presentation I gave in Calgary. Based partly on the popularity of PHIGs, but mostly on my belief that they cover an important business and information management topic, I have decided to attempt to write a book based on PHIGs.
I’m not sure at this point whether it’s going to be tome-like or Cole’s Note-ish (bet on the latter ‘cause I’m kinda a lazy writer) or what the final format will be. I do know that it’s going to be written based on my consulting experience. I also know that my goal is to get people thinking about information and what it really means to their organizations. It may or may not include anecdotes from previous projects, but it will include (I hope) practical stuff that can be used.
Why am I telling you about this? Well, Bryant Duhon of AIIM told me to, and he knows a butt-load more about this writing stuff than I do, so I am taking his advice. Also, I wanna generate “buzzzzzzzzz” and get you excited. Probably the most important reason I am doing this (the blog post) is because I’d love to get your input into the book. I figure you’re the audience (paying, I hope) so you ought to have some say as to what goes into it.
So let me know what you think and what you’d like to see in the book and I’ll occasionally update how things are moving along. I’m looking forward to this thing, I hope you are too.
One last thing … I have no timeline for this book; it’ll be ready when it’s ready.
This may be the shortest post I’ve ever written.
This previous post was about the need for holism in information governance. This post brings up topics that you’ll have to deal with in defining holistic information governance. (I think I’ll refer to these as PHIGs – Principles of Holistic Information Governance). This isn’t going to be exhaustive or ultra-detailed; it’s just a list to guide where you need to pay attention.
Gartner defines information governance as the specification of decision rights and an accountability framework to ensure appropriate behavior in the valuation, creation, storage, use, archiving and deletion of information. It includes the processes, roles and policies, standards and metrics that ensure the effective and efficient use of information in enabling an organization to achieve its goals.
Principles of Holistic Information Governance
1 – Information is an organizational asset.
In the course of our employ we produce and receive information. It doesn’t belong to us, it belongs to our employers. As such, we need to treat it like any other corporate asset. Even if you use a personal device to produce the information, it still belongs to the organization.
Assets have acquisition costs, maintenance costs, residual value (sometimes), and get disposed of at the end of their useful lives. Tell me how this doesn’t apply to information.
If you do not understand this, stop reading and go away. There is no hope for you.
2 – Understand what you’re using information for.
How does information help you achieve strategic objectives? A government entity and a direct-to-consumer sales organization may use some of the same information, but they will use it differently and for different purposes.
Understanding what you’re using information for ought to help you understand what information you actually need.
3 – Understand where it’s coming from and where it’s going to.
Information doesn’t just magically appear; it comes from somewhere. You need to identify your internal and external information sources.
Most organizations don’t just fire information out willy-nilly. Information is intended for specific audiences, for specific purposes. You need to understand what effect your information is intended to have, and who you want/need it to effect.
4 – Understand when you need it.
The next person that says “I need this yesterday.” wins a smack in the head with a frozen mullet (the fish, not the hairstyle).
Information is needed at various points in business and decision making processes. Is real-time information really necessary or can you wait a few minutes or hours for it? Figure out when you actually need the information in order to make a decision.
5 – Understand who can and should be using it, and for what.
This is not just about security, though that’s a big piece. This is also about getting the information out to those that need it or to those that you want to influence with it. Think about it in terms of getting your message out to your target audiences.
Once the information has found its way to the audience, what are they going to do with it? Are they going to make a decision, buy something, receive a benefit…?
6 – Understand your social, regulatory, and compliance obligations.
Depending on what you do and for whom you do it, you have information related obligations. Some of these are imposed by statute, some by convention, and some are self-imposed. These obligations determine how long you must keep information, what you can do with it at the end of its life, and to whom you may or must disclose it when asked.
7 – Understand your information related risks (too much, not enough, disclosure, etc.).
If some of your information leaks, what’re the consequences and can you live with them?
If you’re overwhelmed by information how does it impact performance?
If you’re missing information can you still get stuff done?
How likely are you to be sued?
8 – Understand how stakeholders are interacting with it.
It’s not enough to know what your stakeholders are doing with information. You need to figure out how they’re doing it. It’s not enough to identify the types and locations of devices that stakeholders are using; you also need to find out if the interactions are passive or active.
9 – With few exceptions, information has a finite useful life.
Unless your information has historical/archival/archaeological value, get rid of it as soon as you can. It’s not just about the whole discovery/litigation thing; it’s also about de-cluttering and being info-efficient.
Information is a perishable good; once it’s stale or rotted, get rid of it.
10 – Make someone accountable.
Overall organizational performance, financial performance, legal, technology … they all have single-role accountability and responsibility. As, arguably, the second most important asset of an organization, information deserves at least the same level of attention as finance, IT, HR, legal, etc.
A C-level executive needs to be accountable for how information is governed and managed across the organization.
None of these ten “principles” is much good on its own; they only work as a whole. Other than the first and last, the key is to go only as deep as you need to in order to make things work for your organization. Nobody is expecting perfection; things just need to be good enough.
I’m not trying to downplay the difficulty in formulating information governance policies and procedures. However, much complexity can be avoided if common sense is applied and business objectives remain the primary focus.
PHIGs downloadable PDF
PHIGs – the new and improved slide deck …
It starts out really simple; build us a thing that allows some people (all with common objectives / properties) to do some business with us. Easy, right? It is so far. Then things get interesting.
As other business units hear about what’s going on they want in on the action. As the original business unit finds out what is possible they want to extend functionality and include additional stakeholder groups. As executives realize the possibilities they decide they’re going to hang the entire organization’s “social strategy” on this thing that really started as something truly simple.
In some cases projects morph into programs because they become victims of their own success. Normally this is not an issue for either the vendor/SI or the client. However, when the mindset going in is really that of a project, changing the mindset to one of a program is not the easiest thing in the world to do. Typically what happens is that you end up with a bunch of projects being executed, somewhat in parallel, with little real coordination, and a high risk level of failure for all the projects.
Everyone on the planet worth listening to regarding ECM has said that ECM is not a project; it’s a state of being (maybe not everyone said that). The point is that ECM is not a thing; it is a concept of how to work with information in all its glorious forms. When you start implementing ECM you need to approach it as a cumulative exercise, the value of which increases over time and scope (not by throwing more bodies at it).
Start with something small and simple. For example; replace that $80K photo copier / collator / hole puncher behemoth with a document management solution that lets you distribute stuff electronically. Sure you’ll raise the ire of those two old biddies whose entire public sector career for the last umpteen years has been to be the gatekeepers of that big-ass machine. So what? Work with them and turn them into your first user adoption success story. But don’t stop.
Each additional piece of effort needs to build on the success of preceding wins. It doesn’t matter if you’re building upon deployed solutions, lessons learned, change management, …., it only matters that you keep building and moving towards your eventual end goal. Hint: the goal line keeps moving.
One other thing that REALLY matters is to have a plan. Your plan will change. New stuff will come in, some stuff will get thrown out, and priorities will change. This-is-o-kay. It does not mean you develop a plan and then toss it. No, no, no. It means you develop an initial plan and adjust it as situations dictate. It also means that you better have a damn good change management plan in place.
If you do not have a plan and a program mindset, and you’re lucky enough to have a resounding success with your first ECM dalliance, and “they” want more, … if you are very, very lucky the worst that will happen is that you will end up breathless (like I get when I read The House that Jack Built to my daughter) and stressed. However, in all likelihood you will end up holding the bag for an unmitigated disaster. And you will deserve it for not having a plan.
Have a plan.
Have the right mindset.
Build on success.