Continue in 2 seconds

Vendor Evaluations, Part 1: Functional Requirements

Published
  • February 01 2003, 1:00am EST

Getting your arms around enterprise content management (ECM) problems is never easy. There are so many factors – from security and scalability to usability and policy definition – which must be managed simultaneously that just scoping and defining the objectives of an ECM solution is a project in itself. This article is the first in a series that describes how to manage and execute the early stages of ECM deployment with an emphasis on vendor selection and initial deployment. The first step in the process is defining the functional requirements of the ECM solution and defining how to choose among your application options.

With so much already written about functional requirements, why bother discussing it any more? It is because we still have trouble getting it right. Many organizations are adept at defining strategic IT initiatives and aligning those with business objectives; but mapping those objectives to tactical, implementation-oriented actions is a challenge. We can easily assume that an objective such as "improve cross-functional collaboration" includes a host of features we expect while glossing over the nuts-and-bolts implementation issues that eventually must be faced. The best way to ensure we deliver what our organizations need is to identify exactly what problem will be solved, how a solution will fit in the organization and how we will choose among possible solutions.

Step one is to define exactly what problem will be solved in operational terms. This means going beyond the "improve knowledge sharing" stage to the "enable engineers and analysts to find information related to projects, product development and market research currently stored across two document management systems, three relational database applications and e-mail public folders" stage. Equally important is identifying what the solution will not do. Initially stating that "phase 1 will not include a directory or taxonomy of projects and products" helps to set boundaries which, in turn, helps to manage expectations. Once an operational definition of the ECM application purpose is in place, the next step is to define architectural requirements.

ECM systems are not islands unto themselves. From a functional perspective, we must understand what information will move in and out of the ECM system. How will it operate with legacy systems? What is the high-level migration plan? Is there overlap in functionality with existing systems? Will the ECM put additional load on the network, servers or other applications? Who will manage the new system? Sketching out the place of the ECM application within the context of related applications is essential to effectively evaluating your options.

Once you know what particular problem the ECM system will solve and have a rough outline of how it will fit into the large IT environment, the next step is to decide on an evaluation strategy. Because the ECM market is broad and evolving, the good news is there is probably a solution to your problem. Having a clearly defined tactical objective will provide the basis for making the first cut at possible solutions. If your focus is improving team performance, then concentrate on collaboration tools; if knowledge sharing and information retrieval is your objective, then look to search, taxonomy and expertise-finding applications (so much for the easy and obvious part).

There are many options with regard to evaluating ECM tools. Analyst reports, case studies, vendor references and trade journal articles are all good starting points, but nothing compares to in-house evaluations. To truly understand how an ECM system will operate in your environment, get it into your environment. Only then can you understand how well it works with your enterprise directory or single sign-on system; how it manages access controls to your information; what is involved in integrating it with your portal; and, most importantly, how it handles your data. The one cardinal rule of in-house evaluations is to never, under any circumstances, depend solely on vendor-provided data or non-production data. This is not because of problems with other data sets; they just are not what the ECM system will have to deal with when it goes live. Working with production data forces us to deal with data integration issues, access controls, data quality control and other factors that are easily missed when working with canned data. The purpose of the in-house evaluation is to understand how well a system meets your functional requirements checklist and also to identify unforeseen issues with other applications and infrastructure.

Next month's column will outline how to design and execute an in-house evaluation for enterprise content management systems.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access