THE COST SIDE OF THE EQUATION
Calculating the cost of the project is generally much easier than figuring the dollar value of anticipated benefits. One does not usually have to rely as much on "crystal ball" estimates when working with cost projections. So, why then are the majority of major system implementation projects significantly over budget? I believe this boils down to three major causes: (1) certain costs are purposely understated in order to secure project approval (is begging forgiveness later better than pleading your case up front?), (2) costs are understated because they are calculated with the optimistic vision that everything will go as planned (it never does!), and (3) major line items are simply overlooked because of inexperience (oops, we didn't anticipate that one).
Project costs fall into three basic categories: capital expenditures, one-time project expenses, and ongoing support activities. Front-end capital expenditures are amortized over the anticipated life of the system. One fairly common cost allocation error is that the amortization period often exceeds the system's actual life span, so being conservative at the outset will make life easier down the road. One-time project expenses can either be capitalized or expensed. Ongoing operational and support costs are most often the line items that are understated or overlooked because many people don't see them as a cost of doing the project. They are, however, a very important component of the true cost of ownership.
Capital expenditures typically include the following: computer hardware, application software, operating system and utility software, database management system software, communications network (internal and external), and facilities preparation (rewiring, remodeling, etc.). These costs are typically the most visible and the easiest to estimate. Some vendor proposals will offer "bundled" pricing, which may include training and implementation services along with the hardware and software to provide a single investment figure for the whole package. Bundled pricing generally provides more bang for the buck than line-item pricing, but caution must be exercised to make sure that the "package" includes most of what you need to get the job done without lots of extra bells and whistles that you would not purchase if they were priced individually.
The one-time project expense category is the area most prone to massive budget overruns. Hidden costs and excessive optimism are very common in this area. One-time project line items generally include outside consulting, travel expense to investigate alternative systems, training and education (managers as well as system users), systems development (software customization and/or modification, custom add-ons, report writer specification, etc.), integration of new software with existing subsystems that will be retained, implementation assistance, data conversion, initial new data file building, temporary help to free up project team member time, and new procedure documentation. Keep in mind that the more grandiose the plan, the tougher it is to control implementation expenses. Resist the urge to introduce
too much new functionality all at once, and keep software modifications to a bare minimum to prevent an explosion of unanticipated project costs.
Perhaps the most common of the underestimated expenses is the value of the time of existing employees who will work on the project and the time needed for learning and adapting to the new system. The value of this time is real, and it should be accounted for. The true cost of training goes beyond the formal classroom training on the new system—people productivity WILL go down as the company begins working in a new system environment. The value of existing employee time should not be viewed as a sunk cost—it's a day-to-day operating expense. A prime example of misjudgment in this area involves the use of outside experts such as consultants and subcontractors as an alternative to using existing employees on selected tasks. Here's an example: A company may reject the idea of using an outside expert to get a particular task done in a month for $5,000 because it is seen as in incremental expense. So they use existing employees who do not have the required expertise, but whose time is seen as sunk cost, to get the task done. Seldom does anyone do
an accounting later to find out that the task actually took three months and consumed $12,000 of payroll expense! In retrospect the $5,000 consulting fee would not only have been justified, it would have been a terrific bargain.
The ongoing costs that will be incurred once the system is up and running are needed to complete the true "cost of ownership" picture. Line items in this category typically include annual license fees for software (application software, operating systems, databases, utility software), application software maintenance fees (to secure ongoing vendor support, software fixes, upgrades, etc.), hardware maintenance agreements, taxes on fixed assets, and the cost of technology "caretaker" support (database administrators, systems programmers, network administrators, etc.).
This ongoing caretaker support is one that can present a few ugly surprises to unsuspecting management. Many systems will require ongoing postimplementation support that is not factored into original estimates. Resources are needed to maintain the operating environment, install new releases and/or fixes, monitor performance and modify the programs, procedures, and reports. The big question affecting ongoing cost of ownership is, will this system require additional staff and/or periodic consulting expenses?
Money that is likely to be spent with the software vendor after the system is implemented should also be factored into the cost of ownership. Annual software maintenance agreements are generally changed at the rate of 12 to 18 percent of the current list price of the product (as opposed to the actual price you negotiated for the purchase). Software maintenance agreements can include support services such as hotline, new releases, software fixes, user meetings, and literature. Many companies allow their maintenance contracts to lapse to save money and regret it a year or two later when the next release looks irresistible. It is best to take the conservative approach and plan to retain the annual maintenance agreement for the
life of the system.
SUMMARY—CRITICAL SUCCESS FACTORS
The optimal cost justification exercise will be honest, conservative, and exhaustive. Fudging the numbers on the front end to make it look like a better deal will come back to haunt you during the toughest part of the project. Being overly optimistic by expecting that all the pieces will fall neatly into place as the project unfolds sets the stage for constant reshuffling. Failing to anticipate all of the potential line item costs can result in forcing compromises that can seriously endanger the odds of success.
One very beneficial step that is almost always overlooked, but can be very helpful, actually happens after the project is completed. This is a post implementation audit that answers the question, did we get what we said we were going to get? Since this happens long after the fact, the audit itself will not help the justification. However, if the project team and management commit to it, and everyone knows that there will be accountability down the road, people will give the justification a much higher degree of credibility. Words come cheap, but a "stake in the ground" that sets up some metrics to be measured before and after the project will do wonders for establishing ownership. The stronger the belief at the project's inception that it is well worth doing, the more effort people will be willing to put forth to make sure it succeeds.
From a big picture perspective, the project manager and chief sponsors should avoid falling prey to the "conquer the world" syndrome. It is impossible to know exactly how you will want to be running things a few years from now at the time you are initially planning the project. So, its best not to try doing everything on day one. Trying to implement too
much new functionality during the initial stage or planning to modify the software package as part of the implementation task are the two things that most often lead to disaster. If software is installed in its "vanilla" form and nonessential new functionality is implemented in a phased approach, the odds of keeping the justification expectations in line with reality increase by several orders of magnitude.