Back to Basics - The Keys to a Successful ECM Strategy (Part 2 of 2)
Last time I talked about some of the opportunities and challenges inherent in the deployment of ECM. So, what are the best practices to take advantage of the opportunities and mitigate the challenges? Let me start by saying that I am not the first or only one to write about best practices in ECM deployment. The gold-standard ECM methodology is probably the work done by the good people at AIIM. Their 12 Steps to ECM Success is a great reference for any ECM deployment team.
The eight guidelines below are one level of detail deeper than AIIM and are based on our experiences deploying a variety of ECM tools. Consider this an extension to the work that AIIM has done, not a replacement. With that said, I hope you find these guidelines useful. 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 - Identify your Objectives Lloyd Lim over at ECM-Blog.com suggests that organizations start with an ECM vision statement. This should be a short, clear statement that quickly identifies the purpose of the deployment and is used to get buy-in from everyone; from sponsors to end users. Some examples ECM vision statements include:
“We will replace our departmental shared drive with our ECM solution by the end of next year.” Or perhaps something a bit less ambitious but equally valid:
“All of our project documentation will be managed by <insert ECM tool name here> by the end of this quarter.” The important thing is to give everyone on the team a touchstone to come back to if ever questions arise about why the organization is taking on an ECM initiative.
Guideline 3 - 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 4 - Get Management Buy-In This doesn’t need to be the CEO 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 5 - 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 6 - 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 7 - 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 8 - 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 recognize that 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.