Avoiding the Perils of Imaging System Implementations.

AT THE CORE:

THIS ARTICLE EXAMINES:

* the functional requirements of imaging systems

* how to build a budget for acquiring and implementing an imaging system

* common implementation problems and how to deal with them

Almost every imaging system implementation has at least one minor calamity. Common pitfalls can include

* vendors or IT not fulfilling commitments

* functionality or quality not satisfying expectations

* overrun budgets and insufficient funding

* missed deadlines and slipped schedules

Imaging projects commonly have problems for many reasons. Imaging technology is changing very quickly, and new hardware and software products are released every month. A second major cause for problems is that a typical imaging system involves so many components: workstations, servers, networks, client software, server software, scanners, jukeboxes, and now the Internet. If any one piece is not exactly right, then the entire system can fail.

These two key issues cause a host of other challenges. The fast-changing technology requires IT staff, salespeople, integrators, and users to be constantly on a learning curve. As soon as they become familiar with one system, it is replaced by a new and improved technology. Because so many fast-changing technologies are coming together in an imaging system, the likelihood increases that somewhere in the many combinations, two parts will not work together.

Over the past decade, four primary strategies have repeatedly helped minimize the fallout from these problems:

1. careful planning

2. building strategic alliances

3. developing fall backs and contingency plans before they are needed

4. constantly managing expectations

Careful planning is one of the most important elements of a successful implementation project. Some of the planning needs to be done before the first dollar is spent on the project. A project has a much better chance of success if someone has documented, in detail, the project scope, system requirements, budget, schedule, business case, and technical feasibility before requesting funding. As obvious as it may sound, these first steps are frequently not accomplished until the project is authorized. At that point, the project may already be in trouble because the executives may have a different project in mind. If these tasks are completed first, you are more likely to be successful building support for the project and ensuring that the project will have sufficient funding.

The Scope of Work

Make certain the stakeholders agree on what problems you are trying to solve. Then build consensus on the details of the scope of work. Many elements need to be considered when defining the scope. These elements include determining who the users will be, what documents will be imaged, and how much backfile, if any, really needs to be converted. A layer of details lies below each of these topics. Documenting these items early in the planning phase provides a foundation for successive deliverables such as the request for proposal (RFP). While fleshing out the scope, consider issues such as what sort of access each user will require, who will do the scanning and indexing, how long the documents need to be kept on the system, any hard deadlines associated with a specific deliverable, and so on.

Functional Requirements

Before selecting a technical solution or issuing an RFP, the functional requirements must be documented. As the name suggests, keeping the requirements specification functional is generally wise. That is, it should specify what is needed from a user's perspective rather than specify any one technology. For instance, if letter-size images need to be fully displayed within four seconds of initiating the request, state that as the requirement, not that the storage media must be some specific type of fast hard drive or RAID.

The list of items to specify within the functional requirements can be staggering. Some lists contain more than 400 items. However, the abbreviated checklist in Figure 1 will help project leaders to start defining the functional requirements.

FIGURE 1: Functional Requirements Checklist

Document Management Requirements:

* Will the system need to support multiple revisions?

* Is revision management required to be associated with the check-in, check-out, and reserve of documents?

* Are compound documents needed? What are the components and what degree of publishing sophistication is required?

* What is the anticipated nature of the preconstructed searches?

* How much power should the system have with regards to constructing new searches?

* Is hard-copy document management required too?

* What are the requirements regarding archiving and deleting documents per a records retention schedule?

Imaging Requirements

* What is the daily volume of scanned documents?

* Is the volume large enough to justify a sophisticated workflow for scanning, indexing, and quality control?

* Does the nature of the application indicate a high degree of customization for scanning and indexing documents?

* Are red lining, markup, and/or annotation tools required?

* Are engineering drawings that require a large format viewer included?

* Are scaling, despeckling, hole-filling, or rotating of documents needed?

* Scan to print or just scan to network?

* Is optical character recognition (OCR) needed to convert images to text required for full-text indexing and full-text retrieval?

Indexing Requirements

* Should indexing and searches be case sensitive?

* Is a folder metaphor sufficient for organizing the images, or is more sophisticated indexing needed?

* Are approximate (fuzzy) searches needed?

* Is an indexing thesaurus needed?

* Is custom validation of data for indexing needed?

* Are full-text indexing and full-text retrieval (FTR) needed?

* Are multivalued attributes (a.k.a. repeating fields) needed, as would be the case when a single document needs to be indexed by multiple validated authors or subjects?

Printing Requirements

* Is there a requirement for high-volume printing?

* Is there a need to fax images or documents?

* Is there a need to publish compound documents?

* Is there a need for scaling and rotating document for printing?

Administrative Requirements

* How simple does the administration need to be? (How well trained and sophisticated will the administrator be?)

* How should departments, groups, and individual users be organized?

* How will the documents be organized and indexed?

* How detailed do the security options need to be?

* Will the administrator need to be able to change document types and validated fields?

* What reporting capabilities will be required?

Integration

* What level of integration is required with your mail system?

* What is the need for access over the intranet/Internet?

* Is integration with an enterprise information portal required?

* Is document management integration with Microsoft Office or other standard desktop applications needed?

* Is integration with other in-house systems needed?

Routing and Workflow

* Is canned workflow for standard document management activities such as approvals sufficient?

* Are well-proven development tools for custom workflow needed?

Systems Development

* What special features will lead you to customizing the system?

Indexing

A key to the success of every imaging system is the way in which documents will be indexed. Indexing can be the greatest expense associated with an ongoing imaging system. If it continues to be too expensive, it can kill an otherwise excellent application. If indexing is insufficient, users will have problems finding documents. Therefore, balancing the ease of future access with the cost of indexing is very important.

In general, letting users input keywords does not provide for convenient retrieval. In most cases, using index values from a validated list is much better.

In many cases, the indexing data already exists in another system, such as an ad-hoc document tracking application or a database, associated with the operation that generates the document. Whenever possible, try to utilize such information from other systems to avoid keystrokes. If nothing else, pull the validation tables from other systems.

In some cases, bar codes can be printed on source documents prior to adding handwritten signatures or annotations onto the forms to be scanned. In these applications, you may be able to automate the indexing. Regardless, you need to look at indexing as part of the planning process and see what can be done to minimize the costs before you start.

Developing a Plan

Developing a detailed step-by-step plan is key to successful project management. Although every project will involve different phases, tasks, and steps, some will always need to be delineated. Every plan should minimally include developing the requirements, having the integration team and users working together to design the system, the actual implementation, user testing, documentation, and training.

How these phases are broken down will depend on the complexity of the installation. Items such as complex configurations and custom coding, backfile conversions, and data loading need to be carefully considered and broken into subtasks within the plan. If the system is going to require a significant amount of coding, then a prototype and a pilot phase should be considered. In more complex systems, the recommended approach is to build a usable portion of the system, release it for testing, and then utilize the feedback to prioritize the remaining portions of the system. Then continue building and testing one piece at a time. Putting the conceptual plan into a project management software file will allow the presentation of the project in a professional manner.

Building the Budget

Building the budget can be one of the toughest parts of the project. "Going cheap" to ensure approval and show a good return on investment is very tempting. However, in the long run, having a complete budget that will be sufficient to cover every anticipated cost, plus something left over for contingencies, is usually much wiser.

Key to the budgeting exercise is making certain that you know what you need to budget. Are you responsible for information technology (IT) cost and user labor? In some organizations, the IT department will pay for necessary upgrades to the servers, new servers, network upgrades, and the IT labor associated with a project, and then charge back to the user department, using some sort of pro rata calculation.

After developing the requirements and discussing them with vendors, an idea emerges as to what the software and services will cost. However, these costs are only parts of the total picture. Figure 2 is a partial checklist of items that need to be considered when building the budget.

FIGURE 2: Budget Items

* network upgrades

* server upgrades or new servers

* storage systems-redundant arrays of inexpensive disks (RAID); standard disks drives or optical disk jukeboxes

* scanners, including scanning software, boards, and cables

* backup devices, usually tape or redundant optical unit, and software

* desktop upgrades -- RAM, monitors, graphics boards -- or new desktop systems

* IT labor

* user labor

* consulting

* software (server, client access, Internet, database, operating systems)

* hardware maintenance

* software upgrade insurance, maintenance, or subscription services

* conversion services -- pull, prep, scan, index, QC, de-prep, refile

* system design

* installation

* integration

* configuration and custom coding

* data loading

* testing and documentation

* training

* custom enhancements and ongoing support

* tax

* freight

* contingency -- at least 20 percent of total

Other important issues to consider when building the budget include

* Tax, freight, and contingency are the most often omitted budget items. Sometimes selling contingency by creating a single line item of tax, freight, and contingency together at 25 to 30 percent of the project total is easier.

* When looking at server software, make sure you know the price for the client access licenses (if any) as well.

* Do not neglect making an estimate for the network traffic and required storage needed for the images. Remember that images require a large amount of space and need big pipes to move quickly. Work with the IT department to determine whether a network upgrade is likely to be necessary. Network upgrades can be long lead-time projects.

* Do not forget media costs for optical disks when considering jukeboxes.

* The installation of client software can be very expensive. For some sites it will be possible to use Ghost[TM] or some other automatic network-based installation product. Theoretically, installing the client software off the network drives "by hand" may not be too expensive. However, PCs may take days to straighten out. Budget extra to deal with these desktop issues. Also note that even though a personal computer may have had problems before, the perception will usually be that the new software caused the problems.

* Involve IT, users, vendors, and others in the development of their part of the budget. Allow them to critique the budget being developed for them, and in so doing, get their buy in.

* Be generous with the time for testing and training. You may not need as much as you budget in every area, but one small part often exceeds budget tremendously.

Ensure Feasibility

With a rough plan and budget, seeing whether the original justification and timetable are still operative is a good idea. Is a good return on investment still possible? Can the project still be sold, based on the anticipated budget and timetable? Will IT staff still be available to support the installation and ongoing use? The political waters need to be tested to determine whether sufficient support from users and management still exists.

One aspect of the feasibility is the compatibility of the candidate system solutions with your organization's infrastructure. That is, how easy or difficult is implementing in your environment going to be? Checking references' sites is an excellent way to compare how proven and stable competing technologies are. Find out what problems each site had installing and maintaining the system. When checking references, compare your site with theirs in terms of infrastructure and technical expertise. Note any significant differences and assess the consequences.

Internal support is very important once the system is installed. You need to know what your IT staff is comfortable supporting, in terms of the server, network, intranet, database, and client configuration (the desktop and software).

Document the Justification

In most cases, an adequate return on investment (ROI) is necessary in order to proceed with the project. Each organization has different guidelines for developing the ROI, and you need to understand what your organization expects. Having said that, here are some basic, universal pointers:

1. Consider everyone who will benefit from the system.

2. Start a list of departments that will benefit and list all benefits they may reap.

3. Categorize these savings as hard-dollar savings, soft-dollar savings, or strategic benefits. Hard-dollar savings are benefits that directly impact the budget. These benefits include equipment and floor space the organization will not need to buy (not just "funny-money" savings). If your organization will need to keep the whole building because of long-term leasing commitments, the space savings need to go into the soft-dollar savings category. If the system will save the cost of leasing another building, this amount is truly a hard-dollar savings. Other hard-dollar savings include any reductions in real costs for hardware, software, and maintenance as well as committed headcount reductions.

Soft-dollar savings include equipment and floor space the department can give up and may no longer be charged for, but for which the company or agency is still responsible. It also includes reallocated headcount -- labor savings where headcount reductions are not committed, but there are still clear labor savings. Typical soft-dollar labor savings include those associated with the reduction of misplaced files, the reduction of lost files, or a reduction of administrative staff to manage the files. It may also include potential liability avoidance and potential savings during litigation.

Strategic benefits are often the hardest to quantify. These benefits can include faster order processing, improved customer service, satisfying more customer service requests without a call back, improved safety, enhanced staff training, and so on. To quantify these benefits, consider potential ties to increased sales and the loss-avoidance of sales. For instance, if the number of customers with complaints who decide to buy from the company again jumps from 20 percent to 40 percent because of improved customer service available after the imaging system is installed, what would the company gain? Try to find a member of the operations staff to help quantify the monetary value of these benefits. Not only will it help you do a better job, it will lend more credibility to the numbers as well.

Building Support

As you continue preparing for the project, start to build support at all levels. You may find that your list of potential supporters includes an odd list from user departments, the IT department, and your department, as well as consultants and vendors. The latter may be very valuable in helping you develop successful strategies for gaining internal support. Usually they have been involved in the process before, can assess your specific situation, and make suggestions.

One of the most critical areas in which to develop support is within the IT department. Start working with them early, get their input, and make them part of the team. In working with them, try to involve them in a positive way, making the project exciting for them. Try to select technology that is familiar to them so that supporting you will be as easy as possible for them. Another motivator to get IT managers on board is having a budget that will help support their staff.

Friends and Foes

In any organization, some individuals are interested in protecting you, like your ideas, support new technologies, or recognize that they will benefit from the system. Recognizing supporters is important, whether they are management, potential users, or peers. Bring these people on board as part of the team. Let them know about the project and get their feedback. Ask for their ideas and suggestions. See if they have similar needs that may be satisfied by leveraging the system after your initial implementation. These approaches will help to make them part of your close-knit crew and build an esprit de corps.

Another goal should be to win over key detractors. One of the best techniques is to look for motives that will make a former detractor an integral part of the proposed solution. For a skeptical manager, find a way to show how the system can save his or her department money or improve operations. With potential users, see if you can make their jobs easier. Through extra time spent in analysis, you may find a change in the process that makes their work far less tedious. Use good people skills and show that you value their input. Act on any good ideas they have to improve the system. Sincerely recognize any help they provide. Letting users know you will make certain they get a significant desktop upgrade as part of the project -- faster machines and large monitors -- has also been known to ease tensions.

Sometimes peers, competing for the next rung up the ladder, can be the most challenging detractors to win over. Look for ways that they may be able to leverage your investments to improve their area of responsibility. You may have success getting them on board by making them part of the project team and by giving them the credit for any ideas that may have come from meetings. If it makes sense, consider involving them or their staff in the training your staff will receive. Letting them see that you have management support also helps. Your own subordinates may also be faultfinders and critics of the project. Sometimes they feel left out, so make sure they are part of the team. You can try giving them additional responsibilities related to the project. Also, remember to provide them with credit when due and to act on their positive input.

The Imaging Steering Committee 

After working individually with each manager that will be involved in the project, consider establishing a formal imaging steering committee. This committee brings together the key players, provides a framework for future decision making, and solidifies your support. It also lets you get everyone together so that you can manage their expectations regarding the potential risks the project entails.

They need to be told that system components can become obsolete mid-stream so that no one is surprised if this situation occurs. You may want to discuss each potential problem examined in this article. Then, talk about facets of the project approach that mitigate each risk. These items can include a contract that includes a guaranteed functional scope of work at a set price, contingency budget, back-up resources, and the utilization of standards for data and images.

The Imaging User Committee

If the system is going to span multiple groups, consider having an imaging user committee. This committee typically consists of the first-level supervisors from each group. This committee can iron out common concerns, agree to priorities, and share experiences. It is also the correct group to develop an indexing glossary. When systems are going to be used beyond one department, everyone must index documents with the same conventions: the goal of the indexing glossary. For instance, the glossary can define whether employee social security numbers are entered with two dashes, two spaces, or none of the above.

The Request for Proposal (RFP)

As stated earlier, a well-documented scope document and set of requirements are key stepping stones on the path to a successful implementation. These items can be reformatted, along with additional information, into a detailed RFP. The RFP formally requests that the vendor, value-added reseller (VAR), or system integrator produce a document (the proposal) that details exactly how they will satisfy the requirements, exactly what the project will cost, and how long it will take. Therefore, the RFP needs to document every aspect of the scope in detail, including what you will be supplying and what the vendor needs to supply, in terms of hardware, software, and services.

Starting with the work already completed, continue to detail all functional requirements. Again it bears repeating that requiring specific models of hardware should be avoided. Instead, the RFP should specify the number of images to be scanned per day, if color images are required, quality, size, and so on, rather than a specific model of scanner. Models can change during the process. What is typically desired is for the vendor to meet the business requirement. In other words, specify what you need, not how it needs to be done. An exception to this recommendation is the need to specify the IT infrastructure -- your organization's requirements with respect to networking, servers, databases, and operating system.

The RFP must also clearly define vendor, user, and IT responsibilities. It should give a timeline and note any required milestones and deadlines. It should quantify users, documents, and departments. You should know where every user will be sitting and what they will be using the system to do. The RFP should appropriately note indexing requirements and the size of backfile conversion (if any). It should include a test plan. The test plan includes a complete range of tests, giving specific input to the system and the required anticipated results. Consider including a training plan. If you do not detail the training plan, then at least include exactly what you will require for training (e.g., three system administrators, three scanning personnel, 10 users for in-depth training, 50 users for basic training).

Once you have completed the RFP (or a detailed scope of work for a no-bid situation), circulate it for comment. Once again, work with the people you want to support you and get their buy in. Supporters include the sponsoring executives, your management, the users, and the IT department.

Selecting a Vendor

For most installations, selection of the primary system integrator and the right software products are the most critical decisions that need to be made. A good system integrator is one who is not only competent but also values the relationship with the client more than a quick profit. You should be looking for another team member who can help you and is willing to work with you when requirements and solutions change.

The Process

A typical vendor selection process may consist of the following steps:

1. Develop a long list of potential vendors.

2. Check references to compile a short list.

3. Send request for proposal to the short list.

4. Evaluate proposals. Do additional reference checks.

5. Select the preferred vendor.

6. Negotiate contract.

Alternatively, the RFP or a questionnaire can be sent to the long list, the results of which are used to pare down the list.

Checking References

This step must be taken very seriously with your short list. Checking references properly requires considerable time and dedication. Five or more attempts may be needed to reach someone on the telephone to finally discuss the vendor's past performance with the reference account.

Prior to making the first call, develop a script. Write down all questions that you want to ask on a worksheet. If you make all questions seem positive, you may be more likely to get an honest response. Include room on the worksheet for jotting down responses. Then make copies to use during the telephone interviews with the reference sites. Make certain to take careful notes. Forgetting details is easy, and with so many calls the various references can blur together.

One key question to ask is what they left out but wished they had included in their RFP or contract. Also ask what other vendors they have worked with or considered. You may be surprised to find out that one of your other vendors may also have worked with this site. Whenever possible, find reference accounts not provided by the vendor. Checking around with your intelligence network, you can almost always find some additional references for a seasoned vendor. When looking for additional references, do not forget members of your local ARMA chapter. Consider carefully the references provided for projects that are most like your own. A company that did a great job scanning documents is not necessarily the best choice for building a complex networked imaging system.

Comparing Alternatives

As you develop the RFP, you should also start to document the criteria that will be used to select the vendor. The selection criteria can typically be categorized as follows:

* ability to meet functional requirements (how good the proposed solution is at meeting the objectives)

* cost

* vendor stability and financials (includes VAR and selected software manufacturer)

* ability to execute the job with available resources

* history and references

Often the technical or functional merits are measured to the nth degree. Although this level of scrutiny is not without value, avoid overemphasizing the first two criteria in the previous list. Look at the vendors' stability and how well they have done on past similar jobs. As stated before, one of the best ways to make this evaluation is through thorough reference checks.

A number of methodologies use the selection criteria, the results from reference checks, and other "tests" of the alternative proposals to reach an "objective" decision. Most of these methodologies are based on weighting the criteria as to how important they are for your installation. For instance, if the use of Sybase as a database is mandatory at your site, then the solution's ability to support Sybase as a database should be weighted very high. Each alternative is given a raw score and then given a weighted score, based on the product of their raw score times the weight of the criteria. Although this process may sound complicated, implementing it on a spreadsheet or database tool is very easy. Be certain that you include in your criteria the results of the reference checks, compatibility with your specific computer infrastructure, the solution's ease of use, ability to get support from the vendor, and known future requirements.

As you develop the criteria and weights, involve users, management, and the IT department in the process. You want everyone to agree on how the vendor is to be selected so that fewer problems arise when the selection is actually made. It is also a good way to share responsibility for the choice. As you work with others, be sure to keep an open mind. Also consider the potential adverse consequences associated with each alternative -- the vendor going out of business, discontinuing the product, or having too many other assignments to execute your job. For each adverse consequence, consider its probability and impact. In the case of very close scores, the winner may be the proposal with the least potential downside.

Building a Contract

Two goals to remember when building a contract are:

* Be fair.

* Be detailed and complete, including everything expected of each party.

The basis of the contract can usually be the RFP and the vendor's response (the proposal). Often additional details need to be included. Some of these may have been discovered during the reference checks. Your organization's IT or procurement department may require additional terms and conditions. If the project has been bid at a flat rate, make certain that you negotiate the rate for any additional work you request from them that is out of scope. Also negotiate a payment schedule. For services bid at a flat rate, consider breaking payments into three payments of 30 percent each at key milestones, and a 10 percent hold back on services for 90 days after system completion.

Planning for Contingency

Develop a backup plan for every aspect of the project. During vendor selection, identify a second vendor. You may need one if you cannot negotiate with the first-choice vendor or the first-choice vendor cannot fulfill the mandatory obligations.

You also need to plan for staff turnover. Think about who could best replace every person involved on the project if that person left. Think about how you can get the potential replacement personnel trained before you need them. You can be prepared when someone unexpectedly leaves the company. Do not forget about finding a backup for yourself; you may be selected for another position.

Also consider finding additional skilled contract programmers to "pinch hit" when needed. These individuals will ideally be found already working with the chosen vendor. You may also find great independent programmers during your reference checks. Extra contract programmers can be selectively used for many difficult situations.

* The IT staff get swamped with a new project.

* Another department needs to get set up, but it was not included in the plan.

* The data preparation needs a small program to do some automated merging and purging.

* You need an independent tester.

As discussed during the planning phase, including contingency budget and calendar time is always recommended.

Plan Using a Methodology

For more than 20 years, IT professionals have recognized the importance of using a methodology for each project. These methodologies vary in specifics, but they all include the concept of breaking down a project into its component parts, evaluating the component relationships (precursors and successors), and assigning the appropriate resources, budget, and schedule to each component. The major components of a large imaging project may include:

* design

* prototype

* code

* test

* document

* train

* pilot

* production implementation (conversion or commissioning)

* enhancements and maintenance

The Pilot System

As recognized in the previous list, installing a pilot system may be advisable. A pilot system has two functions. First, it gets most of the functionality to users as quickly as possible, which is important when the system may require a large number of custom features that will delay the ultimate release. Second, the pilot gives users an opportunity to comment on a working model. Although a pilot system may not have all the features of the final system, it should be robust enough to provide value and simulate the final system. In other words, the pilot provides a tradeoff between the features included and the need to minimize its cost and reduce the time required for putting it together.

The pilot user group will ideally involve between five and 20 tolerant users -- and include at least one skeptic. Starting with minimal required functionality, the project can use feedback from users to determine which additional components to complete next. In general, you want to give users the biggest bang for the buck as quickly as possible. Do not be surprised if users decide that some additional enhancements are not worth the money, once the bare bones system is piloted. Alternatively, they may recognize the need for a feature they had not thought of during the design phase. A pilot may not be necessary for smaller "vanilla" imaging systems, but this iterative process of build, test, release, get feedback, and then build some more (based on users' feedback) will allow your organization to maximize their ROI on major projects, especially ones with extensive customization requirements. It will also minimize the surprises, while maximizing the visible progress.

During the pilot, be sure to confirm your expectations for network traffic and document storage. Calculate how these items will scale up and determine whether they will be a problem. The sooner this issue is recognized, the better!

If you do choose to pilot, make certain the design is scalable. Do not put in a software package or infrastructure that you know in advance is not scalable to your ultimate goal.

The Project Work Breakdown Structure 

Phases appropriate to your project need to be broken down into tasks and steps. Using a project management tool, the project manager must create a very detailed project plan. This plan includes scheduling all resources from the vendor, the users, and the IT organization. Generally the lowest level task or step should have a duration of no more than two weeks. Tasks may need to be broken up further to delineate clearly who is responsible for what.

Again, getting buy-in on the project plan from users, vendors, IT, and management is important. Make sure everyone gets a copy of the plan or, at least, their scheduled task list. As you schedule, do not be too aggressive. Recognize that people will generally not be able to devote eight hours a day to your project. Provide contingency for sick days and personal time. Find out when individuals' vacations and leaves are scheduled and allow for these in the plan.

Tracking Against the Plan and the Budget

Once created, you will need to update the plan frequently to see how the actual project execution is meeting your plan. Frequent updating is important so that you can find the tasks that are slipping. You can deal with a task that is not being completed fast enough earlier in the project much more easily than later.

Tracking the budget as the project progresses is also important. Having your initial budget in a spreadsheet makes this process relatively easy. The first column contains what you anticipate the budget to be; title it "Plan." Then add a second column titled, "Actual to Date" and a third column titled, "Outlook." Initially, each row in the "Actual to Date" column will be zero, and each row in the "Outlook" column will be identical to the amount under the "Plan" heading. Then, as payments are disbursed, the amounts spent on an item will go into the "Actual to Date" column, and the "Outlook" will be changed to reflect the updated total amount anticipated for the item during the course of the project. At the end of the project, the "Amount to Date" will be identical to the "Outlook."

Using this method is relatively simple and gives you the ability to tell immediately if you are in trouble and what components of the project are contributing to the problems. However, this method is only workable if you develop a detailed budget. Every cable or board that will be ordered or invoiced separately should have been included as a separate line item in the budget. Tracking is difficult when a single line item is made up of half a dozen entries, with a large paragraph of notes to the side.

Continuous Communication

Nobody likes to be surprised or kept in the dark. Therefore, constantly letting people know the status of the project is desirable. E-mail provides an efficient and convenient means for keeping everyone informed. You may want to create multiple distribution lists so that you can direct information to the specific parties that need to know. Everyone may need to know about a schedule change; however, the executives probably do not care that a particular system routine needs to be updated on the scanning workstation.

Backfile Conversions

If you are going to scan and index a significant backfile, you probably need to consider a service bureau. They can provide high-volume conversions at a reasonable price. Like most businesses, they are constantly looking for ways to cut costs and raise revenues. If poorly planned, having your scanning and indexing done by an outside service bureau can be a frustrating experience. They may cut corners not explicitly required in your contract or add charges you did not anticipate.

Avoid quickly signing a purchase order and starting to scan documents. Using a selection process similar to that used for the system integrator is usually desirable. This process includes developing a RFP or request for quotation (RFQ) and checking references. You need to be especially careful to specify exactly what you need. Restapling, for example, takes time and costs money. Reassembling documents and putting them back into the drawers exactly the way they were originally filed may also be expensive.

Getting a quote on everything you need before you begin is most effective. Changing vendors midway through the project may be difficult if an extra charge seems exorbitant and you do not have the leverage to negotiate it lower. The specifications you might include are detailed in Figure 3.

FIGURE 3: Backfile Conversion Task Specifications

* taking files out of drawers

* special preparation (unfolding, using a razor blade to remove codicils, etc.)

* unstapling and restapling

* black and white scanning at specific dots per inch (dpi) (200 dpi and 300 dpi)

* scanning color documents or photos

* document rotation

* despeckling and cleanup

* optical character recognition (OCR)

* indexing (specified in detail)

* format of images (TIFF with CCITT Group IV compression)

* format for indexing data

* naming convention for images and indexes

* media for returning the electronic data (images and indexes)

* returning files in order

* replacement into drawers

In terms of image quality, you will also need to specify what you expect. One test that can work: "Any information legible on the original shall be legible on the scan." Also make certain you have a process in place for doing quality control checks, both on the vendor's side and yours.

In addition to scanning, the vendor will probably do your indexing, which must be done absolutely without errors. If the indexing is not done well, you may never be able to find your documents again. If you have existing tracking data for the documents (in a database or spreadsheet), offer to supply these for validation. Anything you can give the service bureau to make its job easier and more accurate will be to your benefit. Whenever possible, get at least two fields indexed for each document. This method can prevent disasters if one field is discovered to be ambiguous. If the vendor is going to charge based on keystrokes, consider developing short indexing codes to save keystrokes.

Again, thorough reference checking is critical. When checking on the vendor, ask the references about problems, surprises, unanticipated costs, and what they would have done differently. Then do a small batch of sample files with the vendor.

Integrator's Involvement with Scanning

Chances are likely that you will need your integration vendor to perform the batch loading of the images and indexing into the imaging system. Therefore, you should have the vendor approve the scanning and indexing specifications in the RFP/RFQ and review the contract for the scanning service bureau. Get your integrator to also spec out or approve the format and media for the data. You should also include the required coordination with the scanning and indexing service bureau in the system vendor's scope of work, along with the sample data loading test and the final data loading.

Common Problems

Any image system implementation will encounter problems. Some of the more commonly occurring problems include IT backlog, budget cuts, incompatibilities, difficult installations, discontinued products, disgruntled users, training challenges, and indexing costs.

IT Backlog

Regardless of the commitments made by the IT department or how good the planning, computer departments get more requests than they can handle. Crashing systems, new technologies, and loss of key employees -- none of which are directly linked to your system -- can cause your project to bog down. When IT cannot help, you have three alternatives: 1) Spend more money to get contracted resources to step in; 2) have IT management divert resources to your project, or 3) slip the project schedule.

If the sponsor is willing to increase budget to hire contractors and you have someone available who can do the work without causing political conflicts, this alternative is usually favored. If the cost is minor and you have had an under-run elsewhere, all the better. Be sure to document what has happened and who authorized the expense, and issue a revised budget.

The next option is often best explored in the imaging steering committee. Having set up this committee, you should now be able to call it into action. You can see whether management is willing to make the project a top priority and make IT staff available. If other projects are in process that all agree are more important, document what has happened and the management consensus and issue a new schedule. Be sure to let users know why the project is delayed. Do not blame it on anyone; just communicate that the other projects are currently more critical to the organization.

Budget Cuts

With organizations constantly rearranging their priorities, facing a reduction in budget is not unusual for a project. When this situation occurs, recognize that you cannot do the same amount of work for less money. Figuring out what needs to go when the budget is cut is in your best interest.

Depending upon the project, you can cut scope in a number of ways. Cutting might mean fewer systems, fewer departments, fewer users, or less functionality. Devise a proposed solution and present it to the imaging steering committee. Then get their buy-in and revise the plans. You may need to renegotiate with various vendors to accommodate the reduction in scope. Having been fair with them at each step along the way may help make this change less difficult. Once everything is settled, document and distribute the results so that everyone knows the new project scope.

Incompatibilities

An old joke has often passed around in the imaging business: "What do you mean we don't have standards, we have hundreds to pick from." Although incompatibility issues have been reduced, unfortunately, too many incompatibilities between software components, as well as between software and hardware and hardware to hardware, still exist. Scanners, scanning boards, and software; imaging systems and jukeboxes; Internet imaging solutions and specific Internet server software; and even networks and databases can still introduce incompatibilities.

Sometimes in the middle of a project, a new release of a software package will no longer support your hardware, database, or other key component. Try to identify these potential problems prior to making purchase decisions. Make certain the system integrator and software manufacturer know beforehand exactly what they will need to interface with. Up front, you should, if possible, make the system integrator responsible for these problems as part of the contract. You should also discuss the possibility of these types of problems happening with your sponsors and the imaging steering committee. Therefore, if you need to use contingency budget and revise the schedule, you will more easily be able to go forward quickly without finger pointing or blame.

Difficult Installations

When installations take longer than usual, it is often because of the specific infrastructure into which the software is being installed or a lack of competency of the installation team. In most cases, having more experienced and knowledgeable professionals carrying out the installation can dramatically speed up the installation.

Assessing the competency of your resources is strongly recommended. Do you need more resources or better resources? Will having others involved help either to assess the situation or to be part of the solution? Usually some careful politics are needed to obtain a better resource, but it can really be worth it. Getting the right person for the job can make an amazing difference when the process gets stuck.

Occasionally, the implementation is just going to take more effort than was scheduled or budgeted. In these cases, you will need to work together to come up with a new plan. See if some items can be done in parallel with the task, so as to avoid slipping the overall completion date. If it makes sense, also consider bringing in additional staff to help with the task.

Discontinued Products

Every year a few major vendors go out of business or are acquired, and some of their products are dropped. Such transactions usually do not happen without warning, so try to avoid getting caught in this by doing your research. The larger software companies are all publicly traded, and you can view their financial statements. Companies with lower sales and profitability may be questionable. Very fast-growing companies with higher sales are not usually going bankrupt. Try to find someone inside the company to discuss their current situation with you.

You can take a number of steps to minimize the impact if the imaging software is discontinued. Keeping the index in a documented relational database format will make exporting the data to a new system easier. Keeping the images in a standard format, such as TIFF, and using only standard CCITT Group IV compression will allow you to move the images to almost any of today's imaging systems with minimal effort. You can also contractually require that the software code be kept in escrow, but this measure can be of minimal value if a company is not available to support and upgrade the product. You can hire the company's former employees to keep the system functioning for the short term, but you will need to convert sooner or later.

Your best defense is to do your homework up front. Again, you should have a second choice for software as you start the project and manage expectations early on so as to minimize the political fallout.

Disgruntled Users

Avoid underestimating the impact that unhappy users can have. Change is difficult for many people, and the chances are good that someone in the user organization will feel very threatened by the system. You should start to worry about this problem at the very beginning of the project. The best thing to do is to listen to their fears and concerns. Then consider how you can turn the change into a benefit for them. Can you improve their job in any way? The previous "Friends and Foes" section gives several suggestions to help sway challenging users.

Training Challenges

The speed at which some people learn to utilize an imaging system and the difficulty others have getting up to speed can be truly amazing. Each situation must be evaluated individually. If a person has a history of taking a while to come up to speed but is a very fast and talented worker, then you need your trainer to continue working with them. An alternative is to designate as the trainer a close associate of the individual needing training. The final resort is to replace the person and find a job for which he or she is more suited. Replacement can be difficult; how-ever, it is usually well worth it in the long run.

Indexing Costs

The time and expense to index documents is frequently underestimated. It can be truly the most expensive facet of the system. Several ways to reduce indexing costs include:

* Automate the indexing. This solution is usually the best, if it can be done cost-effectively. Anything you can automate or copy into your database can produce immense savings. If the document identification can be automated with bar codes or patch codes, the cost of indexing can be significantly reduced.

* Index at the file folder level instead of the document level. If the folders are not huge and users are currently finding the information at the folder level, indexing the entire file folder as one multi-page record, rather than indexing every page or document in the folder, may be very acceptable.

* Drop some indexing fields. You will need to be careful not to drop any fields truly necessary to find a document. However, some fields are initially added "for information" about the document, rather than to find it. Developing a prototype without these fields and getting feedback from users may be worthwhile.

* Use OCR and full-text retrieval. Although this method sounds like a wonderful solution, the results tend to be lackluster. OCR is a less-than-perfect technology. Character combinations such as "rn" can get blurred together as an "m." Handwriting is rarely acceptable. Add the problems with searches, not unlike an Internet search, and it can be a disaster. However, it can be helpful when validated index fields are also used to refine a search and good scans of printed originals are input to the OCR.

Each situation is different, and no one solution will always work. In some cases, paying a consultant or the manager of a scanning service bureau to give you some additional ideas as to how to reduce indexing costs may be worthwhile.

* Set appropriate quality control standards. Quality control costs can also blossom out of proportion to what was anticipated. In some cases the increase is because the staff does not understand the requirements of the scanning and quality control process. The objective should be to make certain the pages can be read, not to make them attractive. Some organizations remove all speckles, even though they do not impact legibility of the documents. This work is usually most prevalent with large format drawings.

* Evaluate scanning and indexing workflow. Investigating workflow alternatives may also pay off. Would having the scanning station operator perform some of the image quality control be cheaper? Should quality control be checked when the indexing is done? Before? After? Again, paying the manager of a reputable scanning service bureau or a consultant for recommendations may be a worthwhile investment.

Conclusion

Maybe some day most large imaging systems will be turnkey installations. For the foreseeable future, however, they will continue to be filled with pitfalls. No one can anticipate everything that might happen. However, by following some basic strategies, such as careful planning, building strategic alliances, developing fall backs and contingencies before they are needed, and constantly managing expectations, one may successfully pilot an imaging project to success.

Michael Adler, CDIA, MIT, PE, is the owner and a senior consultant with The Adler Group in Calabasas, California. A certified document imaging architech[TM], master of information technology, and professional engineer, Adler has more than 12 years experience in information management and specializes an imaging, document management, and workflow systems. He is a member of the Association for Information and Image Management (AIIM International) and ARMA International. Adler has a master of science degree in engineering from the University of California at Los Angeles. He may be reached at [e-mail]