Successful EDM Implementation:

Initial Study

by Rainer Hoff, Ph.D., P.Eng.

February 1998

© 1998, Gateway Consulting Group, Inc.

This is part 2 in a series about successful EDM implementation. Part 1 and the methodology diagram is given in the Jan/Feb 1998 edition of Document Management.

An information systems project ("the Project’), either in the realm of electronic document management ("EDM") or product data management ("PDM"), has to begin somewhere. I’ve called the first phase an Initial Study and the resulting deliverable the Initial Study Report.

An Initial Study announces the beginning of the Project to your organization. You should expect to take a position on the following issues:

• goals
• objectives
• resources (for the Project, not the Initial Study)
• constraints
• assumptions
• related projects
• schedule
• scope

Goals

Goals are the set of major achievements that accomplish your organization’s mission and vision. For instance, if part of the organization’s mission is to "exceed customers’ quality expectations", then a Project goal might be "to provide accurate and timely management and dissemination of all quality-related documentation".

 

Objectives

Objectives are specific targets, which share the following characteristics:

• unambiguous and results-oriented
• measurable, verifiable, and not too numerous
• established by those involved in their achievement
• relevant, achievable and encouraging high performance.

For instance, Project objectives might be:

• to implement an electronic vault and manage the quality manual, all policies and all procedures
• to provide access to 100 users in the engineering and manufacturing organizations
• to reduce the time required for procedure review and approval by 50%.

It is essential to estimate the project cost at the Initial Study stage, since the project cost is the financial counterpart of the project scope—you can’t change the scope without an impact on cost.

The Project will require resources in the following areas:

• personnel (see "The Project Team" sidebar)
• hardware
• software
• training
• $$$

Itemizing the costs is very important, since this is the only way that the total costs can be estimated. It’s similar to buying a new car in a way—TV advertising may tout a $19,999 price for a certain car, but the "drive off the lot price" is $27,500, once delivery, taxes, alloy wheels, air conditioning, the CD player and other necessities are accounted for.

Constraints are mandatory conditions put on the Project. In order for the Project to be acceptable, every constraint must best satisfied.

Projects can be subject to, at a minimum:

• Resource Constraints: Year 1 budget is $1 million and 3 full-time equivalents may work on the project.
• Technical Constraints: There are many of these, and they are usually defined during the Requirements Analysis phase: e.g. "must support Sun’s NFS protocol"
• Schedule Constraints: First group of users must be on-line by Sep. 30, 19xx.

Technical constraints are often very firm. The other constraints may be relaxed by management action—a functioning system delivered on Oct 1 and costing $1.001 million would, in most cases, be seen as a remarkable success despite not satisfying the constraints exactly. But relying on management to relax constraints is not guaranteed (witness the schedule constraints imposed by the Y2K problem).

Projects exist within an environment and are impacted by events. Environmental features and events, which are external to the project, are generally not controlled by the Project team. Yet, the project’s success may be dependent upon certain events occurring. It is useful to list these assumptions. E.g.:

• We assume that Windows 95™ will be deployed to all desktops,
• We assume that the corporate strategy on electronic signatures will be completed by July.

Events controlled by the Project team should not be listed as assumptions.

Related Projects

Related projects should be identified. Often they compete with the Project for funding and other resources. Often they impact the technology infrastructure within which the Project is being deployed. Sometimes, there may even be a duplication of effort between the proposed Project and a related project.

 

Schedule

The proposed schedule for the project should be identified. Typically, we would create a Gantt chart showing realistic time frames for each task identified in the project methodology diagram (Jan/Feb 1998 Document Management).

With A Strategic Plan

Many large organizations have developed an Information Systems Strategic Plan. These strategic planning exercises seemed to reach their pinnacle when corporations were migrating from centralized mainframe architectures to more decentralized client-server computing. Many strategic plans identified Electronic Document Management as a specific initiative—some plans were more specific as to the application area where EDM might be deployed.

In this environment, the scope of an EDM initiative is easier to determine, since the context for the project has already been established.

 

Without A Strategic Plan

In the absence of a strategic plan, you must be careful in establishing the scope for the project.

Suppose you are a department manager, so that your "span of control" is your department. One option is to implement EDM within your span of control. The difficulty arises when information has to be shared across departmental boundaries—inconsistent technologies make this sharing much more difficult and expensive. It may be desirable to enlist the support of fellow managers to determine consistent technology standards.

Also, without a strategic plan, you will have to determine which potential application of EDM technology would be a reasonable starting point. Usually, a rapid payback project makes a good starting point.

 

Identifying the First Application

How do you identify the "low hanging fruit" that’s so desirable for a first application? Clearly, ease of implementation is a positive attribute—low complexity applications involving a low volume of documents are the easiest—the "low hanging" part. Also, the importance of the information conveyed by the application is a positive attribute—high usage documents, where distributed access is needed, provides the greatest benefit—the "fruitful" part. Table 1 is an excerpt from such an analysis for a Process Safety Management example. The low hanging fruit are at the bottom and the right hand of the table.

Case Studies

The following are a number of examples describing the outcomes from Initial Studies. For obvious reasons, these are anonymous. However, they provide learning opportunities.

 

Insufficient Resources

When a project is formulated, it becomes known what human resources are needed to ensure success, and sufficient resources might not be made available. What is also common is the "overflowing plate syndrome", whereby the organization has EDM, ISO 9000, PSM, SAP and BPR initiatives taking place concurrently, and the same people are involved in each.

Recommendation: If they aren’t going to be properly resourced, it might be better to do half the initiatives, and do them well.

 

Dying Systems That Won’t Die

Especially in the PDM world, we see more and more 1960’s vintage configuration management systems that are functionally deficient, inflexible and contain bad data. However, these systems have become so entwined with every aspect of the operation, it’s difficult to, for instance, "implement PDM".

Recommendation: The transition strategy from current to future systems is the key element of future work. This should be the first step in the requirements process.

A more painful example is when the legacy system is itself an EDM system. This is the situation that EDM pioneers are now facing—their 1980’s vintage systems are running on hardware and operating systems that are no longer supported.

Recommendation: This is actually a Business Case issue. You’ll have to bite the bullet at some point—get a head start and deal with it now!

 

Sticker Shock

The good kind of sticker shock happens after you’ve carefully assessed costs at the end of an Initial Study. You have data to pursue funding now or in the next budget cycle. The not so good kind of sticker shock happens when Initial Studies, Business Cases and Requirements are bypassed, and the total costs first come to light at the end of Vendor Selection (This drives the vendors crazy!).

Recommendation: Follow the Methodology!

 

The Corporate Connection

Work at one large company uncovered 68 separate EDM initiatives. Mostly these project teams were not aware of the other project teams—certainly none of them cooperated with each other.

Recommendation: Before initiating project team #69, explore the potential for a more collaborative, consistent approach (that actually worked in this example).

 

Well over half the Initial Studies, that the author has conducted, are with organizations and project teams who are not faced with the previously mentioned obstacles. They are ready to get started immediately.