ECM Projects Best Practices - Managing Vendor Selection

This article originally appeared on DocumentMedia.com as "Pulling a McGiver" Parts 1 & 2

Faced with increasingly complex document and information management needs, many organizations are exploring so called ECM suites – Enterprise Content Management.

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 web site content, organize records, manage email, and engage in numerous other on line knowledge and information management tasks and processes. 

However appealing the concept of ECM seems to organizations, selection and implementation of ECM is complex and fraught with challenges.  In this article, we’ll talk about the challenge of ECM, consider how to go about selecting tools and avoiding the pitfalls of the software purchase process and ways to gather and prioritize requirements.

The Concept of ECM versus the Reality of ECM Applications

Before delving into the do’s 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.

“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 2 years it is almost certainly not fully integrated into the 'suite' offering - we know of products acquired 10 years ago that still stand alone....." according to Alan Pelz-Sharpe, Principal at CMS Watch and author of The ECM Suites Report. 

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.

Focusing on Core Needs

The classes of tools that people consider as part of these suites include the following: (the purpose of this list is not to provide an exhaustive list of functionality but to differentiate one class of tool from another)                                                                                                                                                                  

Web content management systems (CMS)– primarily focused externally and customer facing.  Web content management apps may need to serve up content that is created in one instance and repurposed in multiple contexts.  E commerce may present multiple contexts – for  example comparing products, shopping and browsing, developing promotions, etc.  Product content will be created and managed in one place and when updated, propagate changes throughout the site.

What this means is that the way of structuring the content – the content object model – will be more complex.  The site may do business in multiple languages and geographies.  This type of system is designed differently than other types of content management. 

Intranet content management systems (also a CMS)– This can be the same type of tool as web content, but usually has a simpler mechanism for assembling and reusing content.  An intranet typically does not require the same level of complexity as externally facing applications.  Using a web content management system that allows for complex content assembly and reuse for an intranet may create more administrative overhead than is necessary.

Document management  (DM)– Document management systems may be part of intranets and external web sites, but will provide functionality around things like check in and check out and version control and work with complete documents (word, pdf’s,  spreadsheets, etc) as opposed to web page content.  Sophisticated document management systems may allow for complex document assembly for things like proposals and contracts.  The working object and end result is a document as opposed to a web page.

Records management (RM)– records management can be very challenging because anything and everything can be promoted to an official “record”.  Email, intranet pages, documents, even instant messages and voice mail may become a record in certain contexts.  What distinguishes a record is that it becomes locked down, cannot be edited or updated, has an audit trail and a retention schedule. 

Digital asset management (DAM) – DAM systems are used primarily to store and organize images, video and audio content.  Though a class of content management system, a DAM allows for more visual presentation of assets (thumbnails) ways of browsing images (thumbnails, galleries, preview and carousel functions) and ways of translating formats and resolution and handling extremely large files. 

Email  management – email management can mean anything from email marketing campaign management to email archiving and storage to customer interaction management.  These are vastly different applications and serve completely different purposes.  The first is focused on outgoing customer communications and the second on managing employees email files, the third on incoming customer support email communications.

Learning management systems (LMS) and learning content management systems (LCMS)– These are also different types of tools that are sometimes lumped into a single category.  An LMS can manage online and instructor led classroom training including course scheduling and student progress.  An LCMS actually manages content used to create courses based on a learning object model.

Collaboration – Collaboration is another ambiguous term that usually refers to allowing users to create and control team spaces or on line work spaces.  Users can create their own organizing principles (directory structures, tags, taxonomies and metadata) and therefore team spaces can get messy.  The trade off is the ability to react quickly and assemble a team versus the need for a strict structure.  A wiki is a form of collaboration tool and certainly a blog will fall into this category. 

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).

Define business goals

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 infra structure acquisition.  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 a support systems, designers are recreating graphic assets in the marketing department, marketing cannot control branding on web sites, product managers cannot post up to date product information on 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? 

Bring your stakeholders to table

Very often we see Information Services (IS) or Information Technology (IT) leading the project – they get the production processes and the technology, they 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 get alignment and to 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. 

Build user scenarios

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.

Consider organizational maturity

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)

Design the Organization

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. 

Developing Technical Requirements

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

• Requirements traceability - Start with business processes, and identify key improvements goals for each (which have clear costs / value defined).  Then 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.

• Define the project start date and goals for when you need the solution deployed and generating results

Narrowing the pack

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.

The RFI Process

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

After the sale – manage scope

Hold vendors to their commitments, but recognize that stuff happens.  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, have a funding method in place to allow for incremental costs as they come up. 

Measure results

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.