5 Things – Innovation
This was taken from the next to last slide (full presentation available here) from my keynote session at the IRMS Conference in Brighton, UK from 15-17 May, 2016. These things were also included in the ebook Digital Transformation in Action by John Mancini, that was put out in advance of the AIIM Conference in April 2016.
These are five things, in my view, that you need to do if you want to foster innovation, transformation, and disruption (the good kind) in your organization.
- Focus on value, forget risk. – If your entire approach to managing information is based on minimizing risk (litigation, leaks, etc) you are never going to be able to focus on leveraging the VALUE of your information ASSETS. It’s the value that’s going to enable you to innovate and transform your business.
- Start Something. Anything. – Sitting around navel gazing is going to result in you being crushed. Pick something small, easy, and safe, but with tangible benefits and get going.
- Don’t try to change the world. – Closely related to “Start something.” Trying to change the entire organization is going to take time and resources, so don’t try to do it all at once. Start with something that you know isn’t working optimally and change that. Then move on to the next thing, and the next thing, and the next thing, ….
- Blow stuff up, make people cry. – Change, disruption, transformation, and innovation require that things get messy and people get upset. Don’t worry about it. Find the internal champions and sponsors that’ll have your back. Maintaining the status quo hasn’t worked up until now, what makes anyone think it’s a reasonable path forward?
- Get out of the way! – You want your people to innovate, transform, and disrupt, but you’re still relying on out-moded and out-dated managerial structures. Stop. Create an atmosphere that encourages people to go out on a limb and try something new. Give them the freedom to try, but define some reasonable boundaries for them.
The ducks may or may not have appeared in a previous “5 Thoughts / Things” post, but my 4yr old liked them so there they are.
Adopting ECM – A Case Study in Failure
Earlier this year I completed an assessment of Alfresco for a university client. The university licensed Alfresco several years ago and did not have much success. They hired me to find out why, and what to do about it. The options they wanted to look at were to continue on with Alfresco or switch to SharePoint. An option they weren’t willing to consider was a cloud based option. I gave them one anyways, based on Box. Unfortunately I was asked to remove that option from the final report. Oh well.
While the platform in question was Alfresco, I can’t stress enough that the failure had nothing to do with the platform. Under the circumstance nothing would have succeeded. You can read a bit about it in an earlier post here.
I’m trying something a little different; because of my altruistic nature I am making the final report available as a downloadable PDF. I figure there’s stuff in it that many could use, and perhaps critique that would be helpful.
I want to thank Laurence Hart for his contribution to the report and the overall project. Thanks, Laurence. You can follow Laurence on twitter at https://twitter.com/piewords and check out his blog at http://wordofpie.com/.
Anyways, just follow the link and you ought to get to the report (no fees, no signup, no tracking). Feel free to provide feedback.
University ECM Assessment – I’m using Box to share this content. Please let me know if you have any issues.
Image: “Paris Tuileries Garden Facepalm statue” by Alex E. Proimos – http://www.flickr.com/photos/proimos/4199675334/. Licensed under CC BY 2.0 via Wikimedia Commons
YOU are the problem
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.
Guerrilla Tactics – IG Whether or not they want it
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.
Get Sh!t Done – Right People Do Right Things
This is a response to this post by David Spinks of Feast and The Community Manager. Simply put, David points out all that`s wrong about a “Get Sh!t Done” mentality. Obviously, GSD’s not worth a S if the capabilities and tools aren’t in place to enable getting stuff done. It also helps that you’ve got an actual clue about what stuff should be getting done, when.
In my personal and business lives (going back to my mid-teens) I’ve been a coach, team lead, mentor, father (still am), team member, and manager. I’ve worked on dozens of projects in many countries and industries, many of them with a great sense of urgency to GSD. I do not, however, have much experience with startups. In all of those roles and projects I’ve been told, and told others, to “get sh!t done.”
Regardless of the business, there is always pressure to get sh!t done. Whether it’s getting a product out the door, processing a benefits application, getting a website updated, implementing software, putting together a budget, crafting an HR policy, … whatever, people need to perform and things need to get done. It doesn’t matter if the organization is a startup, an established multi-national, or a government entity; the expectation is that things get done.
“Get sh!t done” needs to be prefaced with an understanding that the right stuff is getting done and the right people are being tasked to do it. What makes people right for getting it done? They have the necessary skills, capabilities, attitude, and time to get it done. If they don’t, and they are still being asked to get it done, it’s their manager’s fault, unless they’ve lied to their manager.
If someone is told “GSD” there has to be an assumption that the doer has the necessary resources and skills. If not, either the manager is mismanaging or the intended doer needs to pipe up and articulate any deficiencies in resources or capabilities.
There are type A’s and type C’s out there, just as there are people who will always be less productive than others. Why they’re like that may be interesting to discover, but is ultimately a waste of time (unless it’s a temporary blip brought on by circumstances). What’s more productive is to determine whether or not they fit in the organization. Depending on the dynamics of an organization, having people that aren’t type A, super-productive-ambitious may actually be a good thing. As a manager you need to know how to deploy them correctly and keep them motivated; you need to find out what their capabilities and limits are. If they don’t fit in to how things need to be done, you need to get them out of the way. As long as everyone is working towards the same overall objectives, things are good.
Get sh!t done is a tactic. Shipping a product or some software code is not the goal; the goal is profitability. In the case of government, the goal is delivering services and governing without wasting taxpayer funds. Lots of little sh!ts need to get done to meet organizational goals; simply living a mantra won’t get you there.