November 1999

Volume 15
Number 8

Avoiding Problems in Implementing AIS Software

Joel M. Smith, Mira Costa College

The article entitled ADelays, Bugs, and Cost Overruns Plague PeopleSoft=s Services@ in the September 24^th edition of The Chronicle of Higher Education reported on the frustrations that administrators at a number of institutions have experienced, and are continuing to experience, in implementing a new generation of administrative software from PeopleSoft. Some, but not all, of the difficulties reported in the article have been encountered by those of us in the California community-college system who are now implementing not only PeopleSoft but also other such software.

As the article noted, a number of structural features of that class of software can lead to cost overruns and dissatisfaction with the results of its implementation. These features include the complexity of the software, the difficulty of deciding about initial configuration options, the dangers of choosing to customize the software, and the realities of coping with bug fixes and updates to the software. However, the article did not give details about how to avoid the problems it described.

Even worse, without more information, the article might lead an administrator new to dealing with this class of software to the incorrect conclusion that he or she must simply choose the right softwareCi.e., something other than PeopleSoftCto avoid the problems described. That conclusion would be unfair to PeopleSoft, a company that has worked closely with higher education in recent years to produce high-quality, innovative products for our administrative purposes.

More importantly, the notion that there is a product from any vendor that will work right out of the box with few dangers of cost overruns or of dissatisfaction with the results is simply mistaken. Administrators who reach that conclusion will make bad decisions for their institutions. Many of the dangers described in the article are inherent in the nature of this genre of software. Installing a complex administrative-software system that is sufficient to meet the needs of a modern college or university requires more-sophisticated knowledge and tactical decisions from us than have been required of college administrators in the past.

While it would be nice if we could depend on software vendors to educate us about the prerequisites and ramifications of choosing, implementing, maintaining, and using their products, we cannot. Salespeople say what we want to hear. For example, they often emphasize the very features of the systemsC e.g., ease of customizing the products to the potential buyer=s current business practicesCthat will lead to serious problems down the road. They know we want to hear that we really don=t have to change our ways to use their software.

Nor can we depend on the consulting firms that make their living implementing administrative software to give us the complete story about deploying the systems. After all, by far the biggest cost in any such implementation is often the exorbitant fees we pay consulting firms to help us set up and customize the software. Although they can be valuable partners, their interests do not always coincide with ours.

Ultimately, we have to depend on ourselves to know as much as we can about the strengths and weaknesses of the software we are considering.

There are a number of good software systems, including PeopleSoft, that institutions can purchase. The problem is that it is all too easy to implement any of them using strategies that will lead to both short- and long-term problems. To prevent the problems, administrators need to understand the complexity of the systems, the dangers of customization, and the critical nature of documentation.

First, the software packages are complex systems. Changes made to computer code or data-base structure in one part of the system can affect other parts. That is both good and bad news. It makes fixing some problems easy. One community college solved performance problems throughout its PeopleSoft system by making fairly simple changes in the programming commands that put data in and retrieved data from the underlying Oracle database. But changing code to fix one part of the system can produce problems in another part.

Knowledge of that aspect of large-scale software should result in some concrete administrative strategies. Changes to the software must be made serially, be heavily documented, and be tested carefully for unexpected consequences. If the staff of a consulting firm or the institution=s own information technology staff is allowed to operate in any other wayCe.g., to make many changes at the same time, or to fail to document changes carefullyC unexpected problems and cost overruns are likely to occur.

Second, implementation decisions must be made with future maintenance in mind. Failure to understand that fact is the most serious mistake administrators can make in implementing such software. For example, PeopleSoft allows the customer to customize its software or to create new applications to use alongside those that the company has developed.

However, customizing a commercial application creates significant difficulties when the vendor releases a new version. That version might contain new features that conflict with the changes you have made, or that remove structures you have depended on in your customization of the product. If you have customized the software, your information technology staff will have to spend a great deal of time evaluating the relationships between your customizations and the vendor=s changes before you can proceed with any upgrade. The more changes you make, the more time it will take to go through the process every time you upgrade your software.

Even though PeopleSoft provides sophisticated tools to help with the process of comparing your software with the new version, upgrades of extensively customized systems can take months. That is true for all of PeopleSoft=s competitors, too. If you don=t have enough computing staff members to perform the upgrades, you will have to pay for high-priced consulting help.

Here again, knowledge of the details should lead to concrete strategies. You should change your business practices to match your software, instead of customizing the product. That is going to be uncomfortable for many staff members, but not as uncomfortable as not being able to upgrade or patch the software because you don=t have the resources to update a customized product.

Any good software will include ways to tailor it to your needs that don=t involve customization. For example, with PeopleSoft, you can write your own self-contained subsystems that don=t cause the difficulties described above at upgrade time. In any system, you can use the report-writing tools to create custom reports that extract just the information you need without customizing the software.

Third, documentation of set-up decisions and changes is critical to a successful implementation. That may sound obvious, but the reality is that neither consultants nor information technology staff members like documenting, so it seldom gets done well, if at all. Poorly documenting the implementation of a complex administrative software system leaves the institution at the mercy of information technology staff members, who are notoriously difficult to retain these days. Even worse, failing to create clear, usable, comprehensive documentation means that the software cannot be upgraded without figuring out how it was set up in the first placeC which takes time and money.

When software implementations go bad, the temptation is to blame the software. Some faults do indeed lie there, but many others lie in our administrative decisions. We expect complex software systems to work right out of the box. We fail to arm ourselves with an understanding of the details of the systems we have chosen. We train our staffs insufficiently or incorrectly. We choose the comfort of customizing software to the way we=ve always done things over the difficulties of using the basic, easily upgradable product. We let staff members get away with poor documentation. We turn too many tasks over to consultants, so that our staff members are lost when the consultants leave.

The technological sophistication required to implement administrative software is greater than that to which academic administrators are accustomed. But no piece of shrink-wrapped software alone can provide the functionality we need to serve students who live in the information age. We have to develop the more-complex strategies required to implement and manage the tools of this age. 

Joel M. Smith is dean of academic information services at Mira Costa College. This article is based on a letter written originally to The Chronicle of Higher Education.

Top of article

The Edutech Report is a monthly publication of Magna Publications

The EDUTECH REPORT is published each month by Magna Publications www.magnapubs.com, 2718 Dryden Drive, Madison, WI 53704; 800-433-0499. President:William Haight whaight@magnapubs.com; Publisher: David Burns dburns@magnapubs.com; Managing internal editor: Rob Kelly robkelly@magnapubs.com. Content provided by contributing editors Linda Fleit lfleit@edutech-int.com and Thomas Warger twarger@edutech-int.com. Subscription Customer Service custserv@magnapubs.com. Copyright 2004. All rights reserved. Authorization to photocopy items for specific clients is granted by Magna Publications for users registered with the Copyright Clearance Center (CCC) Transactional Reporting Service, provided that 50 cents per page is paid directly to CCC, 222 Rosewood Drive, Danvers, MA 09123. Phone: 978-750-8400; www.copyright.com. For those organizations that have been granted a photocopy license by CCC, a separate system of payment has been arranged. One-year subscriptions: $199. Discounts available for multiple subscriptions.