Blogs

Last week I talked about some of the opportunities and challenges inherent in the deployment of a records and information management program. This week I will share some tips for taking advantage of the opportunities and mitigating the challenges inherent in ECM implementations. Let me start by saying that I am not the first or only one to write about best practices in ECM deployment. There are several compelling methodologies out there, including Mike 2.0, the ECM Maturity Model (aka ECM3) and of course AIIM's own 12 Steps to ECM Success. The guidelines below are based on my experiences deploying a variety of ECM tools in a variety of different contexts. Consider these a practical extension to the work others have done rather than a replacement.

Guideline 1 - Set the Scene It’s important to help your organization understand what ECM is (and what it isn’t) before going too far. I blogged about my “elevator definition” of ECM in an earlier post and here it is again: Enterprise Content Management is about helping us manage our information better. It’s about helping us work together by providing simple tools to share our documents and communicate with one another. It also helps make sure that we’re in compliance with the rules that govern our organization by providing a secure central location to store electronic files and references to paper files so we keep what we need to keep and get rid of what we’re allowed to get rid of. I find this to be a good way of helping those new to ECM understand what ECM can achieve at a high level. This is also the first opportunity for any of the key people to voice their objections, which is absolutely critical to the success of an ECM (or any other) deployment. It is tempting to dismiss objections early on in a project…don’t do it! It is better to stop before you get started rather than fail two years down the road. If key people from both IT and the business don’t agree that the principles in the definition above are something they want your organization to achieve, I suggest you seriously reconsider whether an ECM project is right for you.

Guideline 2 - Start Small with Big Objectives in Mind My experience has been that global taxonomies and “big-bang” ECM deployments don’t work (or don’t work very often). Simply put, you don’t know what you don’t know going in. Conversely, there’s a risk that department-by-department or function-by-function rollouts create a disjointed approach to ECM that lands you in the same place you started; trying to figure out where the heck all of your information is stored. To maximize your chances of success, keep the big picture in mind when deploying your ECM system to specific departments or functional groups. I call this the Incremental Enterprise Taxonomy model; work with a small number of key stakeholders to develop a high-level taxonomy for your ECM solution then validate, change and revalidate the taxonomy through the course of each deployment (see Guideline 5 below for more on the care and feeding of your ECM system).

Guideline 3 - Get Management Buy-In This doesn't need to be the CEO(although that helps) but whoever is at the top of the food chain for wherever you are deploying ECM needs to be aware and onside with the program. They need to be involved in the creation of your ECM Vision Statement (or at least agree to it). If management support isn’t there, you’re dead in the water. The art of gaining management buy-in is an entirely different matter and is probably a good subject for a future blog post. For now, let’s just say that your ECM program must be closely aligned with your organizational objectives and must solve a pressing business problem.

Guideline 4 - Ask questions, design, revalidate, redesign, train, implement, support, repeat Good ECM implementations never end, they evolve. The most successful deployments I’ve seen are those that are always adapting to the changing needs of users and the organization they make up. One of the best ways I’ve seen to support this process is through an expert user community. This can be either a physical community or an online group (or ideally both) where users can share their suggestions for system or taxonomy improvements and can also share best practices.

Guideline 5 - Integrate ECM Processes into Work Processes as Much as Possible Ask yourself; what problem am I trying to solve? (Hint: refer to your ECM Vision Statement for the answer). Especially in the case of shared drive migrations, try hard to not ask your users to do more work, just different work when interacting with the ECM system. One of the most common mistakes I’ve seen is to force users to categorize content based on its retention period or record classification. Don’t get me wrong, this is critical information, it’s just that the vast majority of users don’t know much about the records classification scheme. I find it best to adopt a Stealth RM approach; work with users to structure the taxonomy such that RM attributes are inherited based on other properties (folder, document type etc.). Users are comfortable with those metaphors and so long as this information can be used to apply retention, everybody wins!

Guideline 6 - Don’t Get Hung Up on Technology ECM tools do what they do. There’s no question that some tools do certain things better than others and some are more mature than others in some areas, but the fundamentals are the same. Once you’ve chosen a tool, stick with it and give it an honest try. If things aren’t working, consider some of the ’soft’ issues; reconsider your training plan, reconsider your business alignment, reconsider your support processes. If none of these things are at fault, you may want to consider a ‘best-of-breed’ tool for certain functions. However, be careful to not create multiple repositories if you can avoid it and integrate wherever possible.

Guideline 7 – Know Thy Vendor, Love Thy Vendor, Help Thy Vendor Help You If you work closely with your vendor to help them understand the business problem you’re trying to solve, they will do their very best to help you solve it. It’s in everyone’s interest to have a success, so engage your vendor early. That said, ultimately this solution needs to be supported by you and only you, and it’s no big secret that vendor professional services teams don’t come cheap. Find the big areas where you need the vendor, lean on them to provide expertise but recognize where you need to own your own implementation. As a general rule, I find that vendors are great at the outset of a project to help get you going in the right direction and they’re invaluable for deep technical know-how, but you should probably own training, ongoing support and the second wave of implementations onward. I know this post has gone on a bit long but hopefully you found it useful. I will continue to flesh out some of the concepts raised here in future posts, but I’d certainly appreciate any feedback you have about anything I’ve posted here.