Electronic Records Management (ERM) Project Planning©
Prior to development of an ERM system a detailed planning process needs to be undertaken. As the intended image system may range from departmental use to enterprise-wide within an organization, and will have significant impact on the business operation, planning is essential to a successful effort. This resource paper applies to document imaging, document management, groupware, and workflow.
Project planning should include the following key areas:
Project Organization
The image project team should be an equal balance among three business departments. The three departments are:
Operations is generally considered as the department that conducts the business application. This group is responsible for using the information that arrives via paper or fax or electronic mail, they make decisions based on the information received, and they track and store that information using corporate databases, personal databases, and central filing areas.
Operations people know how they use information and what the current problems are in a business process. In planning for an image system, Operations should be the group that determines what work steps the new system should provide, how the information should be presented, and how a new system would improve upon the old work methods. Operations understands the "application."
As part of the image project team, the Operations group will be responsible for mapping the current workflow, analyzing the current volume of input documents, defining the current bottlenecks to processing work, and mapping out the costs of the current operation's systems. This group is responsible for making vendors understand the business in its current paper-based environment.
These same people should also be responsible for understanding how image technology will resolve current issues or problems. The Operations group needs to become familiar enough with the technology to assess how it would impact their current processes and what benefit it would provide. Operations should not be overlooked during the planning of the image system.
Operations would typically provide the following types of information:
The job of Operations is to describe for the vendors what it is they do, why they do it, and what is limiting that work in the current environment. Operations must also be familiar with the technologies that can resolve their work limitations in order describe to vendors what they hope new systems and technologies will provide for them.
Information Systems (IS) is generally responsible for supporting the corporate needs for information technology, which includes communications networks, central computer systems, personal computer systems, and software that is needed to accomplish the business objectives.
IS is chartered with understanding how the image system will fit into the current computer environment, what changes may be required to support the new hardware and software, and what will be needed to support the image system. IS will also be responsible to support operations once the system is installed. During the vendor identification period, prior to writing the RFP, IS may be responsible for reviewing vendors and their technology to determine which vendors are appropriate for the project's application.
As Operations views the company from their perspective of how to get the work done, IS views the company from the perspective of what tools are needed to support that work. If either group dominates the planning process, the requirements that both groups would normally contribute may be missing. The resulting system may not meet either group's expectations.
For their part of the RFP work, IS would be responsible for such areas as:
The third group in the planning process is the Procurement Department. Procurement is normally associated with post-RFP work such as negotiating contracts and payment schedules. However, Procurement can provide a valuable service during the planning of the system.
Procurement should be chartered with helping to identify vendors, developing prices for equipment, and ensuring that potential vendors are economically stable, in addition to the contractual work normally performed. Procurement should become a regular member of the team and participate in all of the meetings. During the RFP period itself, Procurement can become the channel through which vendors communicate with the technical team and in turn the channel for communications back to the vendors. While this may add a layer to the communications cycle, it also insulates the project team from the vendors who will most likely be more concise in their communications.
This is not to say that vendors and the technical team may not communicate directly. However, when that communication precipitates a change to requirements, then that change should be formally documented with all vendors acknowledging the change. Procurement, then, is responsible for maintaining the overall integrity of the proposal process.
Project Schedule
Developing a project schedule requires a basic understanding of the technology, its unique application to the project's requirements, and the vendor's history for development. The project team may also elect to do development in-house. If developed in-house, the internal resources, their history of development, and the learning curve must be taken into account when developing the project schedule.
The overall schedule can be broken into the following broad categories:
Project planning cycle. This period is estimated from the time the project is approved to the time beginning of the RFP or procurement cycle. Planning would include such items as the team becoming familiar with the technology, going to conferences and trade shows, having vendors make presentations, and visiting operational sites.
This phase must also account for the time taken to write and present a project justification to senior management, making mid-course corrections, and getting approvals. If a cost justification is required, additional time must be added to this phase.
Procurement cycle. Once the project and budget have been approved, the procurement cycle begins. This includes time for writing the RFP, allowing time for the vendor proposals, evaluation of proposals, and negotiation of contracts.
Project Start-up. The third period of time is the time from vendor award to project implementation and start. Time must be allowed for vendors, or the internal IS team, to build the business applications, install equipment, install communications links, train IS personnel, train operations personnel, and initiate project cutover. For some projects, the new system may be brought on-line in increments instead of an all-at-once switch over. There may also be a period of testing in which only parts of the system are operational while final checkout is performed prior to final vendor sign-off.
Project length is totally dependent on the situation and rules-of-thumb are not applicable. The time from beginning to plan to installed and work, however, may be over twelve months for large systems. Given this amount of time, contingencies must be planned for that may include budget reversals, personnel changes, and vendor (technology) changes. It is very possible that a vendor may announce a new product that causes a reassessment of the project requirements and goals.
If the project is going to involve extensive process reengineering, the schedule will be affect in two ways. First, prior to releasing the RFP, the reengineering must have been done in order for the vendors to have the information. As the goal of reengineering to make processes more efficient, the current work environment will be substantially changed. These changes need to be documented in the RFP.
Second, after procurement of the system, there will be more extensive training since the old processes and methods will be replaced by completely new processes and methods. Also, the cutover period may extend for some time as personnel adapt to their new environment. For projects in which the process reengineering is not so severe, training and cutover may be less dramatic.
Budget Development
As an integral part of the RFP planning process, a project budget must be developed in order to establish funding. The project budget may be broken into three distinct areas:
The budget process is a bit of a Catch 22. How do you estimate the cost if you do not understand the technology? Very often, electronic records management projects are underfunded
Project Team
The budgeting process must take in to account the time, resources, and personnel needed for the project work itself. The first job of the project leader is to develop a project budget that will include at least the following:
It would be reasonable for the project team to expect to travel to trade shows and conventions, travel to vendor headquarter sites, and travel to several sites in which image technology has been installed. The project team may also elect to purchase a small standalone imaging system to familiarize themselves and others with the technology, principles of indexing documents, testing rates (time) in which images will appear on a monitor, allowing operations personnel to "test drive" a prototype of the application, and other uses for a test system.
Based on the knowledge gained with a test system, the project team may have a much better understanding of the image system requirements, what is available from vendors, and how the operations personnel will respond to the technology. It may also be beneficial to test certain subsets of imaging technology such as optical character recognition, electronic forms, and computer output to laser disk.
Image System and Equipment
The project team is chartered with developing an estimate for how much the image system will cost. Without this estimate, there is no reasonable method for establishing a budget and setting aside funds. Therefore, one of the primary goals of the project team is to establish the overall system costs, which include at least the following components:
Developing system costs can be accomplished through a number of methods. The first is to work with several vendors to establish basic equipment and software pricing. Vendors will usually provide this as "one only list price." This is the suggested list price offered by the vendor for each piece of equipment and software. Getting these prices means that your budget will be conservative because final pricing may be lower but would not be higher.
The second method is for the project team to develop the equipment list and use an information service or a consultant to develop the pricing. This method may not be as accurate or up-to-date as working directly with vendors. Prices received by this method are generally as current as the last time the database was updated.
A second component to the establishment of budgetary pricing is the software development and project management costs. Software development may, in some cases, equal or exceed the price of the equipment and software. If this is not taken into account or is only given marginal attention, there is the opportunity for the final budget to be significantly low. The same is true for the project management aspects of the project. For a long-term project in which the vendor is expected to provide assistance and coordination during the development cycle, there may be significant cost associated with the vendor keeping a team of people together for development, the cost of travel, and the cost of writing project summary reports.
A third component to establishing a budget is whether the project will have extensive process reengineering. Process reengineering is difficult to estimate; especially if the project team is not familiar with the principles of the process and has not participated in a process-reengineering project. Briefly defined, process reengineering is defining the current paper-based environment against how work will be accomplished based on the image system technology.
For budgeting purposes, this is an extremely important set of information. For example, by automating certain processes, anywhere from 25% to 50% (in some cases even more) of the work in a department may be eliminated. The budget must then reflect this decreased number of personnel for such items as salary and overhead costs. Also, if there are fewer people, there will be fewer workstations and associated equipment.
In essence, the project team must model the intended operation as part of the budgeting process in order to establish the correct number of system components. If the system is being purchased based on potential cost savings, then these saving have to be calculated in order to determine whether the savings are great enough to offset the purchase of the equipment. If the savings are to be used to finance the system purchase, then the team will be required to develop a cost justification, which is discussed in the next paragraph.
Budget Analysis/Cost Justification
Many projects are funded because of the savings that can be generated by the new equipment. Many companies feel that if the equipment costs can be repaid through savings within two years or less, then the project will receive funding. Payback may be only one of the criteria set for capital acquisitions with other financial indicators such as internal rate of return, net present value, and return on investment also being considered.
Companies typically compare capital acquisition projects against all of the projects vying for company funding. In addition to being compare against each other, the projects must also meet or exceed what a company will make on its capital if the capital is left in current investment programs. In essence, if a project returns less than the money is currently making in an investment account, it would not be a good investment.
Developing a cost justification, then, is comparing the financial indicators of the image project against other projects and the minimum investment percentage that the company makes on its invested money.
Below is a brief review of the cost justification process. This is meant only as a general guideline, each company may have its own process and guidelines that should be followed. Prior to beginning work, the project leader should have agreement with the CFO and CEO as to what is being measured and how that measure is calculated.
All of the work compiled for the cost justification can be used, assuming the cost justification is positive, later in the study to develop the technical requirements section. Other sections of the study can be sanitized and used as background information in the RFP appendices.
A fair amount of work is needed for a cost justification. Prior to starting the project leader will need to work with the financial group, typically the Chief Financial Officer, to understand what information is needed and how projects are evaluated from a financial point of view. The information will be needed in order to start building a spreadsheet of the departmental costs:
The above elements are organized into a spreadsheet that totals costs for each unit of people, multiple departments, and finally a group or company. Only the business area that is being considered should be part of the study. For example, if the study is to image enable a claim's processing group, other departments of the company, such as accounting or human resources, would not be part of the study. Finding the information needed will require a certain amount of digging to get information not on the general budget reports. For example, paper and file supplies may be part of the corporate budget and not flow down to a department budget.
The typical cost justification will include the following major components:
Current Operations. The baseline for all of the remaining work hinges on establishing an accurate accounting of the current paper-based operations. Development of these costs includes:
Once the "cost" aspects of a department have been determined, then an accounting of the paper volume needs to be established. This will include counting the mail each day in the mailroom and developing a matrix of the number of pieces and their sizes. Other input should also be recorded such as fax, electronic mail, interoffice mail routings, and any other information that is needed by the business application.
One of the key aspects of understanding the current operations is interviewing the people who perform the work. Two basic types of information need to be established.
For each person who works with the paper input, each of their primary work functions needs to be documented and how long each function takes as a percentage of their whole job. For example, a customer service clerk may have the following duties:
Organize new accounts and file - 25%
Respond to customer questions - 45%
Photocopy and mail information - 20%
General support - 10%
For this clerk, we would then try to envision how the imaging system would affect his or her work. For example, for Task a, there would still be some organization needed but a significant amount could be accomplished by the image system. We may then estimate that 75% of Task a can be automated. For Task b, we may estimate that image will not reduce the number of calls, but it will reduce the amount of time spent in answering requests by 25%. Therefore, we can reduce Task b by 25%. This process needs to be repeated for each individual involved in the study.
The end result is that if there were eight customer service clerks in the current operations, their time may be reduced overall by 50%. This can be viewed in one of two ways. The first is that the number of clerks can be reduced by 50% with the remaining four clerks able to handle the present volume of work. The second view is that for companies undergoing high growth, the current number of clerks can handle approximately 50% more work before additional clerks are needed to be hired.
Strawman System Architecture. The system architecture is dependent on the information that results from the first step. Based on the reengineered processes and workflows, the basic number or workstations and other components can be derived. Based on the volume of input (paper, fax, E-mail), the number of scanners and associated data servers can be determined. Finally, based on the volume of work that needs to be processed each day, the size of the data server and associated communications network can be estimated.
Although this information is estimated, the basis for the estimate is sound and can be used by vendors in their own calculations when they respond to the RFP. One area that may be considered without regard to input volumes is whether certain components of the system should be redundant. For example, if the input volume is 20,000 pages per day, it would be possible to process this input with one scanner. However, the project team may determine that single unit components will be duplicated for recovery purposes.
In this example, instead of requiring one scanner with a process speed of 20,000 pages per day, the requirement would be for two scanners capable of 12,000 pages per day.
This type of thinking will allow the team to accurately develop the equipment list and system software. Once this list is compiled, pricing estimates can be assigned to the equipment.
Equipment Pricing. Pricing is a straightforward exercise in working with selected vendors. Several vendors should be polled and an average price developed. For example, data servers, workstations, scanners, and printers all have multiple sources.
The system software will be harder to get an average for since vendors pricing has a wider range than the hardware vendors. However, by contacting several vendors and using the information from the operations analysis, an image software vendor should be able to provide you with pricing for data base, image management and storage, and workstation software. Again, these prices should be averaged if possible and the average price used in the model.
The hardest component for pricing will be estimating the amount of development time required to build the application. Vendors and system integrators typically provide this service, or the project team can elect to assume this role. If the development is to be done in-house, then additional costs such as training, need to be developed. This component of the cost model should not be left out since it can equal or surpass the cost of the equipment.
Financial Indicators. Once all of the above information has been developed and estimated, then the numbers can be totaled and a financial analysis performed. The following indicators are the most commonly used indicators for capital acquisition projects:
Payback period. The payback period is the time required to recoup the initial investment in the system. For example, if the system cost is $500,000 and the system provides a financial benefit of $250,000 per year, the system would have a payback of 2 years. From a financial point of view, the sooner the payback the better value the project has. Projects are not decided solely on the payback, however, because this does not take into account the time value of the investment.
Net present value (NPV.) NPV is a formula that calculates the present value of the expected returns and compares this figure against the initial investment. NPV is expressed as a dollar figure. The general rule is that if the NPV is positive, the investment is sound.
Internal rate of return (IRR). IRR is a formula that calculates the percentage that equates to an interest rate. Generally, the IRR is compared to what the company's internal cost of money. The general rule is that if the IRR is equal or greater than the internal cost of money, then the project is sound.
The financial group may also ask to see the projected cash flow, the average annual savings, or other internal measurements that are normally used to evaluate a project.
After the cost justification study has been completed, it is possible to develop and test a number of possibilities. For example, what if the justification turned out negative? Using the work performed, the project team should be able to pinpoint the area(s) that were not providing the needed return. Using the existing work, the team could project what would be needed in order make the returns positive.
In addition to providing a sound financial foundation for the image project, the cost justification model provides you with the essential materials needed to proceed to the next phase of the project, which is to develop and write an RFP. The analysis will also provide you with base line prices and estimates for development work. This will be of enormous value when comparing vendor pricing in their proposals. If pricing is out of line in the submitted proposals, the project team should be able to identify where the discrepancies are and be able to question those pricing areas.
Process Reengineering
Process reengineering is an important part of planning the image project. Although the term has widely different interpretations, it is basically the reorganization of current paper-based workflow around the capabilities of the image system. This reorganization may range from simply replicating the current workflow electronically to starting with a clean sheet of paper and redesigning all process from the ground up.
How far the reengineering process is taken should be decided early in the planning process. The project team may consider three basic variations of process reengineering. How far the reengineering is taken will affect the project schedule, cost justification, and the requirements of the RFP. These variations are as follows:
Basic process reengineering. Implementing an image system will have some consequence on existing process and personnel. Personnel in the mailroom will sort mail differently and perhaps do the document scanning in the mailroom. Personnel in the records area change how they handle records and it is possible that the records area is eliminated. Personnel who use the paper-based information will receive that information differently then before.
This type of reengineering takes advantages of the basic services provided by electronic delivery of information. In planning for your RFP requirements, it is possible to layout the current paper-based activities and request vendors to include in their proposed solutions what reengineering will be needed to accommodate the image system. Asking vendors for this information will require vendors to think through your application and provide detailed business process improvements. Vendors who are not able to provide this level of detail may be suspect in their solutions and those solutions looked at more closely.
It will enhance the RFP's requirements, however, if the project team already has completed the reengineering and provides the vendors with a snapshot of the reengineered processes. The vendors would be required to validate the project teams reengineering or to propose new/additional views to reengineering the business processes.
On-going process reengineering. The project team may find that the company does not have the resources, time, and/or money to enter into a full-fledged reengineering project. In this case, the team may write an RFP for basic process reengineering, but also add a road-map for a five-year program in which a more complete reengineering is undertaken over time. In this case, vendors would be asked how their solution would address these long-term goals. Vendors would then be in a position to provide products with growth capability instead of products that closely matched the initial requirements.
For example, if a second department was going to be added to the image system after successful implementation of the first department, an upgradeable jukebox may be proposed.
By allowing the reengineering to happen over a specified period of time, the project team and company may learn more about imaging technology and its benefits. It may be possible to for the internal Information Services group to assume responsibility for future reengineering work and spreading the project costs over a longer period of time. This is also a more conservative approach to reengineering, but it requires the team to think through all of the processes instead of only the immediate project requirements.
Complex process reengineering. The third alternative is to undertake a ground-up restructuring of the department or enterprise-wide business. This type of reengineering analyzes each process, breaks processes into tasks, and further breaks tasks into steps. The purpose is to eliminate as many steps or tasks, through automation, as possible.
Complex reengineering also may make more use of technologies other then basic imaging technology and combine them through an integration effort. An example may be combining a intelligent telephone system with imaging so that when a caller inputs a personal identification number, the information is passed to the image server and the callers files are pre-fetched for the customer service agent.
Complex reengineering requires the project team to have done this analysis and work prior to writing the RFP. The requirements will then reflect the project team's finished model for the new business operation and vendors will be required to provide or team with other vendors in order to provide the solutions.
For the project team, reengineering must be considered as an essential part of the overall project. The requirements to vendors must be explicit on this topic as they will significantly alter vendor's proposal pricing. Although degree of reengineering performed will affect the hardware sizing estimates, it is the resources, time, and cost for designing and building a software solution that will have more affect on proposal pricing.
Backfile Conversion
One last area must be considered by the project team prior to writing the RFP. The team must evaluate the need to convert existing files for the image system. Conversion of files can take one of three approaches depending on the need to have those files on-line and available.
It may be possible for the image vendor to work with a company that specializes in backfile conversion and to have that company provide the equipment and personnel needed. In this case, the backfile conversion company will charge a fee for the amount of paper converted. This fee will be based on such criteria as total input number (paper, microfilm, etc.), degree of difficulty in making the conversion, the time period for the conversion, and a number of other decisions.
Like process reengineering, deciding on the conversion strategy must be decided upon prior to writing the RFP. Each conversion choice can be supported or discounted by performing a cost justification and modeling the activity of the files. The choice that is made by the project team will affect how the RFP is written and how vendors will respond.
Summary
The three areas of budget analysis, process reengineering, and backfile conversion are important steps to be considered when developing the requirements for an image system RFP. All three are somewhat intertwined and need to be considered together. The work done in the cost justification process will help the team to understand whether a simple or complex reengineering will be financially sound. Reengineering and conversion must be accomplished to some degree but how far should the project team go and on what basis do they make a decision? Performing the cost justification analysis will help the team understand these issues and allow the team to develop a sound and defensible position.
These inter-related issues are dependent on many variables that may not be intuitively obvious to the project team. The company's financial position, the team's experience, the project's complexity, and the technology must all be considered together.
©Copyright 1997 by Porter-Roth Associates.
All rights reserved. No part of this publication may be reproduced or used in any form or by any means, graphic, electronic or mechanical, including photocoping, recording, taping, or information storage and retrieval systems without the written permission of the author.