ECM Survival Guide
Faced with increasingly complex document and information management needs, many organizations are exploring socalled enterprise content management (ECM) suites. The idea of ECM is simple: have one place where people can collaborate, solve problems, access reference materials, manage works in progress, develop learning curriculum, manage website content, organize records, manage email and engage in numerous other online knowledge and information management tasks and processes. However appealing the ECM seems to organizations, its selection and implementation is complex and fraught with challenges.
Before delving into the dos and don'ts, it's important to understand that ECM is more of a concept than it is an application or applications suite. Because underlying content processes are so complex and varied in any organization, it is unrealistic to expect that any single system will meet all requirements. There are vendors who sell a wide range of applications that are presented as an integrated suite; however, the reality is that these are typically applications that were developed by different organizations (or certainly groups within organizations) and may be less tightly integrated than one would desire or expect.
These "suites" are sometimes loosely bundled tools that have been assembled through business acquisitions by a vendor over time. Tight integration of newly acquired systems can take years. A vendor will claim to have a well-integrated suite, but even installation (let alone customization and application development) can become extremely complex.
According to Alan Pelz-Sharpe, principal at CMS Watch and author of The ECM Suites Report, "Almost all suite offerings are the product of multiple acquisitions — and integrating a company and its product is a massive job, you have different and often clashing cultures, let alone different code stacks and architectures. If a product was acquired in the last two years, it is almost certainly not fully integrated into the 'suite' offering — we know of products acquired 10 years ago that still stand alone."
The lesson is that ECM can be considered more of a class of technology comprised of various types of tools. Therefore, it is important to think in terms of specific functionality in support of business processes rather than acquiring the "Über application" that will be all things to all people. Think in terms of specific capabilities that users need for a particular business function. Those capabilities need to drive selection of software rather than the grand vision of a complete suite that can meet everyone's needs
The classes of tools that people consider as part of these suites include the following: web content management systems, intranet content management systems, document management, records management, digital asset management, email management, learning management systems and learning content management systems and collaboration. These systems can be used across a particular function and integrated into specific processes. For example, a web content management system could pull from a DAM, an LCMS and a DM tool. Other functionality that may be part of these systems to one degree or another includes rights management (both licensing of rights and controlling asset usage) and workflow or business process management (for integrating content into various business processes or managing content with respect to a process).
Based on the wide range of purpose and function that these technologies offer, it is important to focus on business needs and not on tool functions. Though this sounds and is obvious, it is very easy to fall into the feature/function trap. Why is this? Because organizations approach these projects as big-ticket infrastructure acquisitions. Therefore, people in the selection process try to abstract functionality to meet the broadest set of needs.
A better approach is to start with a specific business problem to solve with measurable/observable outcomes. List things you need to fix today: Sales people can't find sales proposals; customer service can't locate answers in support systems; designers are recreating graphic assets in the marketing department; marketing cannot control branding on websites; product managers cannot post up-to-date product information on the e-commerce site; general counsel cannot produce documents during litigation; regulatory affairs cannot demonstrate compliance due to labeling inconsistency; sales organization loses customers due to poor site usability; etc.
In each case, identify who is hurt by the problem. Who owns the issue? This is not an information technology problem but a business problem. Who are the business users and owners?
Very often we see information services (IS) or information technology (IT) leading the project — they get the production processes and the technology and understand metadata and info architecture; however, they don't necessarily feel the business pain.
Business users (marketing or sales, for example) can appreciate business impact (e.g., customer retention, increased revenue, brand management) but don't usually know what technology can do to solve the problem or understand how they might solve the problem. They are also usually less versed with what it takes to make things work — to operationalize the solution.
Though it does take more effort to align and achieve a common vision, it is very important to work collaboratively on a solution. It is important for IT to see the business side and for the business side to at least understand their role in technology deployment.
Once the problem is defined and stakeholders are brought to the table, develop use cases and user scenarios that will support your functions. These are the typical tasks that target users need to accomplish in their day to day work. Use cases can vary widely in level of detail and granularity. The level of detail will be driven by the type of application and specific capability you are enabling. The point is to use these scenarios to guide the vendor during presentations, demonstrations and bake offs. Ask for product demonstrations and cases that support the primary use cases. For example, develop demo scripts that ask vendors to show how an author checks content in for the first time and classifies it with metadata; show how review and approval workflow for a new member application; etc .
Maintain control of the buying process - don't be controlled by the selling process. Vendors have more experience selling their solutions than you do buying a solution. It is easy to go down the path of letting them show their product in their best light. Products typically demo well. Sales processes work to minimize flaws or missing functionality. Demo data usually works pretty well. What may not work is your process with a particular technology. Decide which of your processes need to be demoed with your data and scenarios, not the vendor's.
Some capabilities will require more sophisticated web content, tagging, production or authoring processes and may be far beyond your current maturity. The technology is an enabler, but cannot make up for a lack of governance or poor web operations. Part of the desired end state might be distributed authoring in regions and countries for example. Do the regions have expertise and personnel resources to fulfill new work roles and responsibilities? Do content authors understand tagging processes and the use of the taxonomies and metadata? Will someone take ownership for local content areas? Will groups have the bandwidth and leadership to continue to maintain taxonomies and update web functionality? If you bring in a consultant, will you have the expertise to continue once they leave?
A content management maturity assessment will help you determine how far along the learning curve you need to go in order to fully realize benefits. Without this baseline assessment, investments in capabilities may be lost due to ineffective supporting processes and internal staff capabilities. If the gap between current maturity and that dictated by the desired end state process is large, management will need to devote more organizational resources to the effort (training, support, change management, consulting resources, etc.).
Recognize that costs, investments and benefits will not be evenly distributed. Overall improvements may cause some costs to increase. There may be more upstream work to achieve a downstream benefit. In order to build a coalition that will survive the technology selection and deployment process, you need to be sure that there is enough WIIFM ("What's In It For Me") for the ones holding the bag, especially for change management costs. In some cases, work process design will have to change significantly, and conflicting objectives will need to be settled at a higher level. This may mean shifting resources or changes in job descriptions and job evaluation criteria. Success or compliance measures will likely have to change. What gets measured gets done.
There are a number of best practices around translating business requirements into more technical specifications. The following points will help guide you in what to do and what not to do:
Process => Key Improvement Goals => Use Cases => Key Features
- Utilize requirements traceability. Start with business processes, and identify key improvements goals for each (those having clear costs/value defined). Map use cases to these process improvements so you know what a use case is worth; then map features to use cases.
- Don't write requirements for things you don't understand. I've seen people invent approaches to workflow and ECM who clearly have never seen a real system in action — just some idea of "how it ought to work." Start with a clear understanding of and familiarity with ECM systems and how they work for your key use cases (e.g. collaboration, knowledge management, workflow, publishing, localization, records management, archive, etc.).
- Don't waste time writing feature requirements from the ground up — others have done this for you. Use a consultant that does technology selection for ECM to manage this, or buy a report/RFI from CMS Watch or other technology analyst. It's more important that you understand how features trace to business goals.
- Define your budget for software and services, and secure it before engaging vendors. Cost estimates can be gathered and budgets justified before engaging vendors.
- Define your IT environment — servers, OS, clients, browsers, security requirements, etc.
- Define the project start date and goals for when you need the solution deployed and generating results.
It's easy to get overwhelmed with vendor choices. In order to not have this happen, develop a short list before engaging vendors. ECM is a vast and cluttered landscape. Your unique requirements most likely are best met by just two or three vendors.
Another way to narrow the field is to find vendors that have expertise in your industry. This is about business process, not technology. Having examples of other companies like yours will go a long way to determining how relevant a vendor approach will be to your particular situation. You can also leverage the expertise of industry analysts to help validate the fit of a specific vendor to your needs. Look for case studies that resonate.
When sending out the RFI, don't send to 10 vendors. You will burn people out reading all those responses and spend a lot of time doing so. Use your short list. Don't use the RFI to get free consulting or to price shop. Put together a specific, phased project proposal, and get quotes.
If you find yourself spending a lot of time on a weighted feature scorecard to determine which vendor is best, you're probably doing the wrong thing. A short list of vendors with focused proposals and demonstrations should surface a clear leading contender. You should have a clear, good feeling about one of the vendors. Trust it; if it's really a "dead heat," go with price.
Hold vendors to their commitments, but recognize that there are always surprises. Change orders are normal when assumptions and expectations are not borne out in practice. Expect these, have a project owner to manage them, and have a funding method in place to allow for incremental costs as they come up.
A project roadmap should have clear expectations about when benefits start to accrue. Make sure that deployment plans include putting the measurement system in place and gathering data to show the benefits are accruing. Report these periodically to the project stakeholders. Track your progress and successes.
Read the article in DOCUMENT Magazine
Send to friend
