How to Successfully Implement Document Management

Home/Publications/Best Practices Newsletter/1999 – Best Practices Newsletter/How to Successfully Implement Document Management

CIDM

October 1999


How to Successfully Implement Document Management


CIDMIconNewsletter Judy Glick-Smith, Center Associate

An Electronic Document Management System (EDMS) is a user-centric information system that provides access to all information from one interface-a single point of access-without regard to content or format. Because electronic document management (EDM) is a system, the only way to successfully implement it requires vision and a system life-cycle approach. If you can build your EDMS well, it can become the beginning of the corporation’s knowledge base.

The electronic document is the building block of the EDMS and of an organization’s knowledge base. Electronic documents can take many forms-text, images, facsimiles, video, audio, voice mail, email, programs, or virtual reality. According to Tom Koulopoulos in Electronic Document Management Systems: A Portable Consultant, EDM is “the embodiment of personalized information systems, since it represents the user’s own proprietary knowledge base.”

If you are a technical communication manager, and you have begun thinking about the usefulness of implementing an EDMS for your technical information, you must recognize that your system has the potential for becoming a corporate-wide system for organizing all types of diverse knowledge. It can also become the knowledge workers’ means of publishing and receiving the information they need to do their jobs.

For EDM to be successfully implemented, users must buy into the concept that it is a system. Otherwise, they will “fall back to old ways of managing their information, or worse yet, choose solutions that cannot be supported or integrated with other enterprise systems.”

Before we discuss how you can implement an EDMS, here are some important terms:

Document Management. The ability to automate the end-to-end life cycle of any document type in a common enterprise repository. Document management enables an organization to assemble and publish information dynamically, according to its business policies and processes.

Virtual Document. According to Jeff Barton, Texas Instruments, “Content is maintained in one or more places, wherever it is most appropriately maintained, and is later pulled together into the output `document’ via a process. This process can be directed by the authors of the content, other editors, or by programs triggered by events, which themselves might be triggered by entries into databases or other means of control.”

Just-In-Time Documents. Also, according to Jeff Barton, “The right people maintain the right content at the right places and times to produce raw material for other people to draw upon from the right places at the right time to produce the `documents’ that do not, literally, exist as discreet collections of input until the output is requested.”

Object-Oriented Database Publishing and Content Management. Content management or OO-database management refers to the process of storing document components as separate objects within a database to facilitate virtual documents and just-in-time documents.

The implementation of document and content management requires that you use a rigorous systems development life cycle methodology. This article describes each of the following steps in detail:

1    Conduct a needs analysis and develop a requirements definition/information plan based on the needs of the people who will be using the EDMS. Decide on how you will measure success.

2    Design your system before you decide on a product.

3    Send out an RFP to EDMS software companies.

4    Decide on a product based on your requirements and design.

5    Train your team on using the tools.

6    Plan your implementation.

7    Implement the system.

8    Test the system.

9    Prepare a maintenance plan.

10    Measure your results.

If you are creating a documentation database, the phase approach means that you will spend about half of your time planning, about a quarter of your time implementing the database itself, and another quarter of your time testing. The testing might include making certain that your database feeds information correctly into the templates you’ve developed for electronic books, print, or even a help system. System testing might mean making sure that your end users are getting the information they expect. You may also need to ensure that the system is scalable to large amounts of information in the database.

When you have determined that EDMS is the solution, start small. Limit the implementation to one department or one application. Starting small allows you to retain control, particularly if this is your first systems implementation. I base this recommendation on the system development literature. For example, according to Patterns of Software Systems Failure and Success, the more complex the implementation, the higher the likelihood of failure. In Quality Software Management: Volume 1 Systems Thinking, Gerald Weinberg states that, “as the size of a system grows, the complexity required to control it grows nonlinearly. Any particular human brain, however, has a relatively fixed capacity….Once the complexity

[surpasses this capacity], the system is too complex for that brain to control perfectly.”

A needs analysis is the beginning of the planning process. And, it is the most important part of the implementation process. In his classic, Managing a Programming Project, Philip W. Metzger points out that “poor planning boils to the surface as a source of problems more often than any other problem” in systems development. Conducting a needs analysis tells you where you are today, enables you to envision where you want to be, and tells you what you need to get to your vision. During a needs analysis, you will: perform an audit, document workflow, establish metrics, envision where you want to be, identify what you need to get to your vision, and develop an information plan or requirements document.

The purpose of an audit is to determine where you are today in the following areas: human infrastructure, technological infrastructure, and information development and publication process.

In evaluating the human infrastructure of your organization, ask the following questions and document the answers:

  • What is upper management’s commitment in this endeavor?
  • Are there training issues in your organization? Is your organization involved in a cross-training plan? Is there a mentoring program in your organization?
  • What are the work habits of employees?
  • Is there an active policy of continuous process improvement?
  • Is there a commitment to cycle time reduction?
  • What is the organizational structure? Are there any major changes happening or about to happen?
  • How does your organization measure performance?
  • What is your organization’s financial orientation?

In evaluating your organization’s technological infrastructure, ask the following questions. You will want to solicit your IS department’s help in answering these questions:

  • Does your IS department use a system development life-cycle (SDLC) methodology that you can adopt for this project?
  • What is the current hardware configuration and architecture? Are there limitations in purchasing or integrating new hardware?
  • What software does your organization already have? Is there an approved list of software within your organization? What are the procedures for purchasing and implementing new software?
  • Does your organization have an intranet? What is the corporate strategy for using the intranet?
  • What are your system security policies and procedures?
  • Who handles network administration? Will you need to interface with this group during implementation?
  • How is data storage and retrieval done now? Could there be other groups within the organization that have already implemented some form of document management or content management?

The third part of the audit involves an evaluation of the workflow involved in the information development and publication process:

  • Do you have policies and procedures in place?
  • Do you have information development and publication standards?
  • What is your process for data gathering?
  • What is your process for information development and publication?
  • How do you deliver information to your customers?
  • How do you measure the effectiveness of your process?
  • Does your department practice continuous process improvement and work on ways to reduce cycle time?

In technical communication, workflow analysis is what we call user-task analysis, with the added dimension of analyzing the flow of documents through each process. Implementing a workflow analysis, according to Koulopoulos, “provides a tool set for the proactive analysis, compression, and automation of information-based tasks and activities.”

For any system development, just as in any publication design effort, the first step is to identify the end user. The next step is to identify the tasks associated with a system and the documents associated with each task. At this point you can develop a user/task matrix. For more information on how to do this, see JoAnn Hackos’ Managing Your Documentation Projects. This matrix, along with the knowledge of the documents associated with each task, will tell you what information the users need to perform their jobs.

Workflow tools are available to help with this effort. Keep in mind that implementing a new workflow involves the same degree of planning as implementing an EDMS. If you do not plan workflow implementation, the results will be less than satisfactory. According to Koulopoulos, 67 percent of the obstacles identified by evaluators and users of workflow are due to organizational culture. Koulopoulos’ book, EDMS: A Portable Consultant, describes workflow implementation in detail.

Koulopoulos argues there are two sets of metrics to use in justifying a new technology: “the current metrics based on existing systems and costs,” and “the future metrics based on new opportunities and potential.” The first is easier to quantify, but the latter has the greater return on investment.

After the workflow and user/task analysis, you will see where process improvements can be made. Based on the information you gathered in the audit, document the efficiencies you would like to achieve. Then, create a picture of a streamlined process.

Based on the information you have gathered and the vision you have for improvement, ask the following questions about an EDMS implementation. Put the answers to these questions in a document, such as the information plan in Hackos’ book. The information plan will become your requirements document.

  • What are the design implications?
  • What are the system usability requirements?
  • What is your revision process?
  • What production concerns do you have?
  • Does your organization have localization and translation issues? If so, what are they?
  • What will your training requirements be after implementation?
  • What are your media requirements?
  • What constraints and potential pitfalls can you anticipate?
  • What technology is required to implement EDMS?
  • How much storage will you need to implement EDMS?
  • Who makes up the project team and what are their responsibilities?
  • Who makes up the review team and what are their responsibilities?
  • What is the preliminary implementation schedule?

Once you have your requirements document, develop design specifications for your EDMS. Within these specifications, document how you want the user interface to look. Also, identify the relationships among information that will reside in the EDMS. The more specific you can be, the better. Note: At this point, you have not looked at any EDMSs, because you are only working at the conceptual level.

Use your requirements document and your design specifications to develop a Request for Proposal. After doing some research (see sidebar), choose five to ten products that seem to match your requirements. Investigate further the vendors who respond. Look at their products; visit other companies that have implemented their products. Include your IS department in the decision. There may be hardware, software, or architecture issues that need to be addressed.

The more detailed and stable your requirements document and your design specifications are, the more accurate the proposal you will receive from vendors. In Rapid Development: Taming Wild Software Schedules, Steve McConnell says “If you insist on fixed-price bids on the basis of a vague requirements statement, you’ll get high bids from the competent vendors. The only low bids you’ll get will be from vendors who don’t understand software development well enough to know the risks involved in incompletely specified software.”

When you feel as though you have accumulated all the information necessary to make the best decision, decide!

After you have ordered the software and while IS installs it, send your implementation team to the software vendor’s classes on how to implement. Here they will learn how to turn the conceptual design specifications into reality. If you cannot spare the resources to do this, most software vendors have teams of people who can implement your system as you designed it.

You have the tools you need, and you know how to implement. Now is the time to document exactly how you are going to structure your information, develop the user interface, and populate the database. As you begin implementation, test as you go. Track your progress. If you begin implementing without a plan, you are doomed, at worst, to failure and, at best, to having to correct mistakes after implementation. Both can be very expensive.

As in any other system implementation, test the system against your specifications. According to Frederic Brooks, The Mythical Man Month, “failure to allow enough time for system test, in particular, is peculiarly disastrous….delay [at the end of the schedule] has unusually severe financial, as well as psychological, repercussions.” Hint: Use end users to help populate and test the system. When you do so, you effectively train them on the new system.

System implementation does not end when you flip the switch. There will be adjustments based on process changes, software upgrades, and content relationship changes. Make a best attempt to identify the different ways the system might be affected by change and develop an action plan for each situation.

After implementation, measure your results. Measure every six months to see if there are improvements over time.

Selling the Concept

You can use a number of methods to get buy-in from management on implementing an EDMS. Remember, while management is always concerned with productivity, quality, and customer service, it all boils down to the bottom line. You must be able to show them how an EDMS will save them money or help them generate revenue.

One way to get their attention immediately is to build a prototype. Emphasize the idea that this implementation will help the company strengthen its competitive advantage. Inform them that there are tools to make some of the documentation effort automatic. But, most important, show them that their return on investment will come quickly.

Justification is not just a technology issue. It is a business issue that spans every aspect of an organization. Metrics are the only sure way to justify an EDMS project.

Bibliography

Brooks, Jr., Frederick P. 1995. The Mythical Man-Month: Essays on Software Engineering, Reading, MA: Addison-Wesley.

Hackos, JoAnn. 1994. Managing Your Documentation Projects, New York, NY: Wiley.

Jones, Capers. 1996. Patterns of Software Systems Failure and Success, London: International Thomson Computer Press.

Koulopoulos, Thomas M. and Frappaolo, Carl. 1995. Electronic Document Management Systems: A Portable Consultant, New York, NY: McGraw-Hill, Inc.

McConnell, Steve. 1996. Rapid Development: Taming Wild Software Schedules, Redmond, WA: Microsoft Press.

Metzger, Philip W. 1981. Managing a Programming Project, 2d ed., Englewood Cliffs, NJ: Prentice Hall.

Weinberg, Gerald M. 1991. Quality Software Management: Volume 1 Systems Thinking, New York, NY: Dorset House Publishing.