Perspectives on Managing an Electronic Document Management Project

InfoManagement Direct, December 2005

William Laurent

Electronic document management (EDM) has become a critical cornerstone of the data warehousing landscape. However, many companies are still undertaking large EDM projects for the first time and finding that seasoned expertise in EDM project management (as well as integration and development) is often not found in house. EDM systems have certain unique and idiosyncratic pitfalls and issues - from the initial analysis/design to final integration testing and production release - that the data warehousing project management professional should be familiar with. EDM systems are usually strikingly different from one implementation to the next, with a changing cast of exhaustive obstacles with each new installation. Although EDM structures may be simple off-the-shelf implementations, they are usually complex systems tailored to reinforce and tightly fit/integrate with a company's workflows and processes. Likewise, system documents themselves may be completely static during their lifecycles, but are more often collaborative in nature (sometimes intensively so), supporting corporate workflow and cooperative tasks. As project manager (PM) you may be tasked with commanding numerous components of an EDM project, which could include elements of training, software, hardware, development, documentation, testing, conversions, support and beyond. Let us look at a handful of the more important challenges that you, the PM, should be ready to tackle.

Setting Expectations and Getting Buy-In

If you are having a difficult time aligning current and proposed technical infrastructure and IT investment priorities with document management business requirements, you may want to consider a hybrid EDM solution. This will be especially relevant if you are already starting with a large body of paper documents that populate the voluminous chambers of the corporate information center. Many times it will not be easy to justify the expense of converting large numbers of archived and/or inactive paper documents (or future paper documents) into digital formats, let alone the cost of the analysis to determine and identify candidate documents for conversion. A hybrid solution - where many documents remain in paper format while other more recent and robust ones are scanned into the repository - may be a good compromise! For hybrid systems that will store a portion of newly created documents in paper form, metadata about the new paper documents should still be tagged in the EDM system going forward so that these documents can be effectively tracked and requested electronically.

A huge paradigm shift may be needed in the minds of the targeted EDM user community. You may need to spend time winning their hearts and favorable opinions. Some future users of the system will invariably be upset that they now have to officially check in records or documents to support their business processes. The "big brother" complaint may rear its head, especially if audit reports (which will expose people and processes that are not properly checking in documents as required) are brought into the equation. Conversely, you may find yourself up against a "packrat" mentality: users may be unhappy that certain documents will be destroyed in accordance with a document retention schedule. Fortunately, the case for both retention and destruction of documents is usually persuasive because it is driven not only by core operational needs, but also by internal and external legal and compliance concerns.

A detailed and specific document retention policy should be meticulously crafted and promoted throughout the enterprise so that all employees clearly understand document lifecycles and protocol. This policy will clearly define all criteria and circumstances under which documents should be saved, the retention schedules for each document type, and best practices for check-in and check-out. It will define stewardship, ownership and dependencies of documents. Also defined will be exception rules and "grandfather" clause exceptions for legacy documents. In addition, it will be important for the policy to list explicit descriptions of what types of documents should not be stored in the system. (For instance, public records and forms that can be freely downloaded from the Internet probably should not be taking up space and have attached metadata in your document management repository.) Once your document retention policy is in effect, enforcing adherence to the policy will be an ongoing mission that will require proper vigilance.

As with any large-scale data warehouse effort, it is vital that all levels of management are on board with their full backing and sponsorship if large EDM endeavors are to be successful. This may be tricky because document management systems and their underlying retention policies (and enforcement of those policies) tend to encroach on people's "turf" by abolishing various traditional management hierarchies, sometimes adding new ones due to additional audit and compliance requirements. Everybody in the company must understand the strategic importance and compelling need for the proposed EDM solution if it is to be an unqualified success.

Business Continuity and Document Security

When paper documents are moving about an organization, it can become very difficult and cumbersome to create a permissioning model that controls and restricts their access. However, once they are converted from paper to electronic format, it becomes much easier to effectively attach access and entitlement controls to the documents and their associated metadata. Because security can occur at the document level, document field level or on a document's metadata, permission and security models can become complex and unwieldy very quickly. Always be sure to define security needs very early in the project and don't make it an afterthought when embarking on an EDM venture.

With paper-based documents, it is near to impossible to replicate all files for safe-keeping, let alone employ business continuity (BC) best practices and fundamentals. However, when the same documents are in electronic form, disaster recovery (DR) and BC options are exponentially increased. Typical BC/DR methodologies (replication, redundancy, failover clustering, etc.) will apply to EDM architectures; however, supplemental server infrastructure may sometimes be prudent. For example, it is often wise to dedicate separate physical servers for both document files and document metadata. Supplemental records management software (if needed) may be installed on an additional server.

Systems Integration 

Page 1 of 2.