CAUSE/EFFECT

This article was published in CAUSE/EFFECT journal, Volume 22 Number 4 1999. The copyright is shared by EDUCAUSE and the author. See http://www.educause.edu/copyright for additional copyright information.

Enterprise System Implementations: Lessons from the Trenches
by Jack McCredie and Dan Updegrove

In recent years many colleges and universities have undertaken large-scale administrative software initiatives. Some are considered great successes; others, less so. Years of experience with such projects, plus numerous discussions with colleagues at institutions in various stages of implementation, have enabled the authors to compile a set of practical guidelines for those who are in the midst of, or about to undertake, such initiatives.

At the 1999 Seminars on Academic Computing (SAC) at Snowmass, Colorado, we participated in a panel on implementing enterprisewide administrative systems (often called enterprise resource planning or ERP systems). Examples of such applications in higher education include comprehensive financial, human resource, and student resource management systems. Similar discussions at a meeting hosted by the National Association of College and University Business Officers (NACUBO) and at EDUCAUSE �99 provided opportunities for us to elaborate, clarify, extend, and formalize these ideas.1 These sessions enabled attendees to build upon the experiences of panel members as well as to learn from questions, suggestions, and comments from the audiences.

The goal of each of these panel discussions was the same--to share important lessons learned in the trenches of public and private universities that are implementing major campus- and systemwide administrative applications. These observations are not theoretical but are practical and experiential in nature (see the sidebar describing the authors� campus implementations). It is our hope that one or more of the following recommendations may help ERP implementers in higher education navigate some very exciting but dangerous waters.2

Develop an appropriate decision-making framework as early as possible; consensus decision making does not work for ERP projects.

A crucial early step in ERP implementations is the development of a decision-making framework that will be used throughout the project. Senior institutional management needs to approve this process and then actively support the implementation efforts throughout the duration of the project.

A problem that seems to crop up regularly in higher education is that often decisions are revisited several times. In other words, a decision is often viewed as only a �temporary indication of direction� that can be questioned over and over. To make the changes required in an ERP effort, important decisions often cut across many of the relatively independent departments in the institution and they must be made quickly. Senior management has to be part of the process.

Such decisions would stress the acumen of the most experienced project manager, assuming he or she actually has the authority to make them. In many colleges and universities, however, such decisions are debated by project teams, discussed by coordinating committees, deliberated upon by steering committees, and decided by whom? Identifying and documenting an actual decision is often difficult. One veteran observed, �In higher education, a vote of 34 to 1 constitutes a tie.�

Since an ERP implementation will probably require a new approach to decision making, you should strive to reach agreement on an appropriate framework as early in the process as possible and stick to it when the going gets rough.

Recruit recognized departmental leaders to participate in both the selection and the implementation processes.

Selecting and implementing a new financial, payroll, or student information system calls for the best, brightest, and most dedicated staff. A successful ERP project requires detailed knowledge of how an institution operates, clearheaded analysis of current shortcomings, creative vision for improvement, ability to bridge business requirements and software features, and willingness to work for months, even years, on a team under intense scrutiny and pressure. Fortunately, academe attracts many such people, although compensation policies may have to be adjusted to retain them or to fill key vacancies. These individuals have to be identified, recruited, and involved early in the selection and evaluation activities to ensure their �buy in� later in the process. People will not cooperate fully if they feel that a new system was forced upon them. In addition, make sure that several technical experts are part of the selection team so that marketing claims can be balanced against the technical realities that will be faced during the implementation. Be aware, however, that some of the most knowledgeable functional and technical staff may be too wedded to the status quo to make effective project participants. They might best be deployed on the important tasks of maintaining legacy systems.

Pay attention to project management and planning.

While there is an understandable urgency to �open the box� and get involved with technical work early, there is a clear, parallel need to engage the various constituencies in ongoing functional needs assessment and process evaluation. Do not underestimate how large and complex a business process reengineering project can be and how important it is to have experienced project management that includes effective risk assessment and sound contingency planning.

Unfortunately, spending for �project overhead� may be quite unpalatable for an institution that views ERP as a major opportunity to reduce costs or that has, in fact, been successful in streamlining administration. However, most ERP projects are very expensive, and investing in good project management tools and personnel early in the project is money well spent.

Do not underestimate the amount of hardware needed to provide the level of performance users expect from a modern enterprise application.

Advanced relational databases, complex graphical interfaces, ad hoc query capabilities, sophisticated authentication and authorization protocols, and hundreds of simultaneous online users all combine to chew up as much hardware as you can afford to allocate to a new enterprise application.

Accurate estimates of how much disk space, processor capacity, and network bandwidth will be required are difficult to make because often you are moving from old paper-based processes to new online methods and historical data are not available. In the marketing cycle, software vendors tend to downplay the need for adequate hardware because it increases the costs of implementing their systems. In addition, users can be unhappy about the performance of a new system compared with an older one because highly tuned, terminal-based legacy applications, although hard to learn to use, often have very good performance characteristics. New applications usually require a great deal of tuning to meet performance expectations.

Understand the proper role for consultants in your culture.

Your organization will need additional staff to implement a major new ERP. Normal production work needs to continue at the same time that the new system is developed, tested, and introduced. External consultants and contractors, although very expensive, can play invaluable roles in the implementation process, but you must understand how to manage and utilize them in your culture.

However, do not relinquish project leadership to outsiders! Your organization will have to live with the results of the implementation, and it must retain overall leadership of the process. Also, while external consultants can fill key roles, often faster than might be possible by recruiting permanent staff members, they do not solve the problem of who will fill these positions when the consultation is over. A good guideline is to use consultants as much as possible for temporary assignments that will not continue throughout or after the implementation. In other words, try to use them as true consultants, not as long-term additions to your staff.

Get external advice from peers.

Outside review teams are an integral part of the academic culture, and they can be used to great advantage at several stages of an ERP systems implementation cycle. Since many higher education institutions have completed significant segments of major new systems, an alternative to professional consultants for some purposes is to invite to campus a team of peers from another college or university. The members of such a team not only contribute to your environment but also learn from it. Their advice can be just as valuable as the more expensive words of wisdom from consulting firms. Obviously you need to achieve a balance between the skills desired from a consultant or a visiting team, their experience, and the cost of the engagement. The track record of peer advising visits that we have experienced in our own campus implementations has been very positive.

Be skeptical of vendor promises about release dates of new versions, future features, field support, and software quality.

Talk with other customers, product developers, and consultants with significant experience to understand the current status of the products you will be installing. �Marketeers� often promote futures and �vaporware.� Even the best are usually focused on the promises of release n+1. Intense competition can drive a vendor to concentrate on the bells and whistles of future versions rather than to focus on the mundane but critical issues of quality and supportability of the current version.

On-site customer visits to institutions similar to your own are perhaps the most valuable evaluation techniques available. Dig out good reference sites from lists of peer institutions, not necessarily from those provided by the vendor. When possible, negotiate a trial period or a prototype demonstration using your data in as realistic a setting as possible. Realize the potential instabilities that are likely when you become involved in a beta test for the next generation of an application. In other words, try to �open the box� as early as possible before you buy.

Be realistic about the life cycle costs and benefits of customizing an ERP application.

To achieve many of the potential benefits of a complex package, you should absolutely minimize the number of customizations you make to the package. When feasible, use as much of the �plain vanilla� version as possible. Benefits such as ease of initial and future release installations, remote customer support from the vendor, low-cost maintenance, and economical feature acquisition vaporize when you start to tailor an application to fit the unique requirements of your institution.

We all live in the real world, however, and few large organizations with functional units having strong customer-focused goals have the discipline to accept a given package �as is.� As soon as important users see what really comes out of the box, the pressures mount exponentially to make �just a few important changes.� This process is a very slippery slope that leads directly downhill to a highly customized, hard-to-maintain, and very expensive solution. Many colleges and universities are unable to resist the siren�s song of customization to fit the special needs of highly vocal, independent departments and colleges. However, the cost of choosing a customized path is very high and usually not well understood by senior management. Customization proposals should be escalated to a high level in your decision-making framework.

Make realistic compromises; the best can be the enemy of the good.

The path to a successful implementation is strewn with conflicting demands from many quarters. Several compromises must be made along the way, and not everyone will be happy with your decisions.

For example, testing, training, and performance tuning are obvious areas where, with additional time, more can always be accomplished to make an implementation go more smoothly. However, no matter how much testing is done, some bugs will remain in a large application when you �go live.� The only true test comes when hundreds, and perhaps thousands, of users begin stressing the system in production. The same observation holds true for training and tuning; there is no such thing as too much of either. However, you must decide when enough has been accomplished to make the �go live� decision. Another trade-off example is the decision of whether to allow a deadline for a milestone to slip a modest amount to avoid �burn out� of the project staff.

In many ways, an enterprise implementation is a highly political process, and just as in politics the art of negotiating good compromises is essential. Technical and functional project staff should be shielded, as much as possible, from the many political issues that are sure to arise. Their jobs are difficult enough!

Develop a special office environment for the project team.

It is commonly understood that ERP efforts require the expertise and energy of a wide range of personnel, from project managers to IT staff to central and school/departmental administrators to consultants on software, business process reengineering, training, and change management. What may not be so clear is that many of these individuals will need to engage 110 percent for months or years, and as a cohesive team. It is unrealistic to assume that they can remain at their regular desks, where they will be subject to �business as usual� distractions. Working together in the same office environment increases team building, develops new allegiances, and helps to develop more uniform work styles. In fact, moving key personnel to �the project office� forces action on �backfilling,� and the sooner the empty desks are filled (with a temporary promotion or a consultant or a retiree disenchanted with golf), the more likely the project staff can truly focus on the opportunities and problems before them.

Be serious about training.

It goes without saying that a new software system cannot be deployed successfully without significant end-user training. But how will the users be trained, classroom style and/or computer-based training modules? How long before rollout will the training take place? Too far in advance and much will be forgotten; too late will leave users unprepared. And how do you schedule the training as rollout deadlines slip? Will users have to learn a new operating system (perhaps their first experience with a mouse)? Beyond software, how will they be trained on the new chart of accounts, new or revised operational policies, the more rigorous password scheme, and the penalties for perusing another department�s data? Will training be mandatory? If so, what about faculty members who may also need training?

Departmental support providers, help desk personnel, and data center staff will also need thorough training. When you visit campuses during the software evaluation stage, be sure to ask not only project managers but also end users how effective the training was and how it could have been improved.

Communicate broadly about the complexity of the implementation process.

Implementing a new enterprisewide administrative application will be one of the most complex software projects in which you are likely to be involved. The technical components of the project are complicated, but most of the really hard issues will arise from the functional process changes and organizational adjustments that are inherent in these implementations.

Most individuals on the periphery of the project will not understand the intricacies of such a large effort. Faculty members who may be involved in various review committees are likely to be very critical of the amount of time, effort, and money required to rebuild a major part of the organization�s administrative infrastructure. Even if they are part of the communication process, they are likely to be unhappy about any large investment in administrative support. A coordinated communication plan is a good way to explain the goals, timelines, benefits, and problems of the project. An up-to-date Web site and extensive electronic mailing lists are helpful, and many projects find that a periodic newsletter is very popular. Regular reports to the executive levels of your college or university are absolutely essential.

Convert data early and often for testing and demonstration purposes.

Data conversion is one of the significant technical problems that will be encountered in a major implementation effort. The conversion process is one in which data elements are often �cleaned up� and improved because it is common to discover anomalies in historical information while examining it closely in preparation for a new system. Early in the implementation process is a good time to experiment with conversion utilities to explore their features, enhance them, or acquire new ones. Moving millions of records to a new environment is a major milestone, and the procedures must be extensively tested before the actual conversion process begins.

A significant benefit of early data conversion experiments is the opportunity to demonstrate elements of a new system, with your organization�s actual historical data, to broad audiences as part of the training and communication cycles.

Do not overlook information security and access control.

Many ERP systems replace old, obscurely coded, disparate applications running on proprietary operating systems with modern, integrated systems built upon relational databases on Unix and Windows NT platforms. One of the �gotchas� in this architectural transition is the loss of �security by obscurity.� These popular operating systems are vulnerable to security attacks from within or without. And modern powerful query tools, combined with integrated data warehouses, increase the risk that even authenticated users might be tempted to browse data they are not authorized to see.

Modern client-server applications require equally modern and sophisticated security architectures. Important security considerations include constructing firewalls to protect the databases, encrypting passwords and possibly all user transactions, protecting end users� computers, and so forth. Careful attention must also be paid to access control provisions because ERP packages as delivered may not provide the level of interdepartmental privacy demanded in some higher education institutions. Note that making changes in a vendor-supplied access control infrastructure can lead to costly customizations.

Phase in the modules; beware of the �big bang� approach.

There are some attractive reasons to consider an all-at-once or �big bang� approach to ERP projects: minimizing the overall project duration and concomitant disruption of campus operations, maximizing synergy among project components, minimizing required consulting expenses, and delivering the new software and business systems sooner rather than later. However, there are some even more compelling reasons to consider staging major ERP initiatives:

As the alumni advisory group commented on one of our campuses, �A �big bang� plan is predicated on suspending Murphy�s Law.�

Realize that integrated systems are a mixed blessing.

Generations of users lamented the limitations of �stovepipe� systems--payroll systems that didn�t share data, or even data definitions, with student systems and so forth. One of the promises of modern systems is integration--a common user interface, common query tools, and an integrated database. Integration has its costs, however; the software vendor has to integrate all the components successfully, and the customer often has to understand second and third order effects while making decisions about software implementation and process reengineering. Since �the customer� is typically a recently assembled team representing various campus constituencies and the next release of the software may be imminent, achieving such synoptic understanding--to say nothing of consensus on priorities--is a major challenge.

Recognize that many ERP projects are late and over budget.

Why is it rare for ERP initiatives to meet original time and budget commitments? Ed Yourdan�s book, referenced earlier in a footnote, describes many of the reasons for these phenomena, and the reader is directed to it for a more complete discussion. Initial project cost estimates and timelines are often unrealistic. The software is new and complex, so even if a careful assessment was done prior to purchase, the customers have much to learn and there are too few experienced consultants to guide them. It is usually clear that the software will require some process reengineering, and this may be a desired effect. But there is little experience with such reengineering in many higher education institutions, and there are many political pitfalls in the process.

Moreover, once unleashed, reengineering can create demands for customized software functionality, adding delay and expense to the budget. Integration testing and performance tuning of large systems are complex and time consuming while developing and deploying training programs are also costly. Key personnel discover that their new technical skills improve their salary prospects while vacancies may have to be filled by expensive consultants. Finally, as pointed out earlier, the consensus decision-making culture that serves universities well during most �peaceful� years is not well suited for ERP.

Understand that even steady-state cost savings are difficult to achieve.

Legacy environments are perceived as costly: Software is idiosyncratic and most likely heavily modified by long-departed programmers; operating systems are proprietary; ancient hardware consumes space, electricity, and maintenance dollars; time is wasted on duplicate data entry; data access is a trial-and-error exercise for all but a few gurus; and so forth. Moreover, there are substantial opportunity costs and risks to an institution lacking accurate data for planning, decision making, and service delivery. That said, few colleges and universities find that replacing legacy systems with modern client-server applications will result in immediate direct and measurable cost savings.

The reasons for this are many: Client-server systems require more powerful desktop computers, often with larger monitors and more memory and disk storage. Relational database systems consume enormous amounts of server disk storage and processor capacity. Hundreds of users exercising new query tools will stress all of your computing and communications resources. Servers will proliferate, with concomitant increases in systems management overhead. Relational database systems require additional administrators, open systems require security architects, and confused users require local handholding and more sophisticated help desks. License and support fees for state-of-the art software are substantial as are the compensation levels required to recruit and retain staff to operate and maintain the new environment.

New systems should add substantial functionality and information access for more users--administrators, faculty, and students--but, at least in the short run, we lack both the systems management tools and the experience to operate them at the same or lower costs as the legacy environments they are replacing. The benefits of these systems will be found in improvements to the fundamental business processes and the ability to provide better service, not from cost reductions in the computing infrastructure or in distributed departments.

Underpromise and overdeliver.

ERP projects are arduous and costly, so don�t add pressure on the project team and provide fuel for the skeptics by promising the sun, moon, and stars at the outset. Too many projects are launched with lofty rhetoric about �enhancing� and �transforming,� �state of the art,� �client-server,� �reduced costs,� and �service quality.� In this overheated atmosphere, even valuable early wins can look puny while delays and cost overruns can foment campuswide resistance, even ridicule. Better to target narrower and shorter-term accomplishments, achieve them while garnering the concomitant good will and momentum, and then expand the scope to include more customers, additional software functionality, or thoroughgoing reengineering.

ERP projects are best understood as foundations for long-term improvements in our colleges and universities, not short-term panaceas for decades of deferred maintenance of our administrative systems.

Understand your institution�s ability to absorb change.

One of the more common mistakes ERP project managers in colleges and universities seem to make is to underestimate the magnitude of the changes that a new system will spawn and to overestimate the ability of the organization to absorb these changes. At any point in time, a particular organization has a certain amount of resistance to change procedures that have been standard operating practices for years or even decades. Even if there is general agreement that these practices may not be working well, there is a built-in inertia that makes change difficult. Just as with Newtonian physics, an external force is needed to overcome this inertia, and for each action there will be an equal and opposite organizational reaction.

Recognizing these underlying organizational �laws� can help managers pave the way for change. There are good change management seminars and workshops available, and several universities have reported good experiences in using them. An organizational readiness framework should be an important part of the overall implementation strategy.

Plan on how to retain the valuable staff the project will develop.

Working on a major ERP implementation is a great way for functional and technical staff members to increase their market value. People who have the right set of technical and organizational skills and the temperament to perform under pressure and to stay engaged in these projects become very valuable. They will receive outside offers and headhunters will be recruiting all levels of the project team.

Therefore, it is important for both functional and technical departments to have recruiting, retention, and retraining plans already formulated when the implementation process begins. Stipends, reclassifications, significant pay increases, temporary assignments, training packages, bonuses, team and individual awards, and term contracts are some of the tools that are commonly used. Retraining senior employees is a good investment because they are strongly committed to your institution and its benefit program. Many of these techniques are not part of the standard human resource programs of colleges and universities and may require effective negotiation with your institution�s human resources department.

Recognize that the project will never be completely finished.

The process of administrative systems renewal is ongoing. Similar to developing the campus networking infrastructure, a new enterprise management system will never be completely finished. The process of changing the way that work is accomplished is a positive feedback system. Work redesign will impact a new system and lead to future system enhancements, and new features should lead to additional changes in workflow.

Managing expectations in such an environment is very challenging. For some individuals change is too rapid, and for others it is too slow. Regardless of the pace, change should become a constant feature of the administrative environment. One of the important benefits of a good administrative application is the flexibility to respond to, and to encourage continuous improvements in, the underlying business processes.

Maintaining morale of the implementation and post-implementation project teams in such an environment is also a challenge because they need to reach closure on parts of the system. The good news is that there will always be a high demand for their skills. Breaking the ongoing process into manageable chunks allows everyone to celebrate the completion of important milestones.

Despite all of the problems of implement- ing comprehensive new applications, many colleges and universities need to renew their administrative infrastructures to improve services, increase quality, compete against new forces in the education market, and in general manage their resources better. Implementing an ERP system is difficult, but with proper preparation it need not be a �mission impossible.� In 1999 only part of the story has been documented in the early days of these implementations. What remains is to study the benefits from these projects as colleges and universities learn to capitalize on their substantial investments.

Sidebars

University of California, Berkeley

The University of California, Berkeley, is in the middle of implementing a new financial management system purchased from PeopleSoft Corporation. Significant segments of the new system were implemented early in 1999, and additional modules will go into production during 2000. After the financial management system is in place, the campus will implement PeopleSoft�s human resources management system. Currently there are no plans to replace the comprehensive student information system that continues to evolve as an integrated application designed and developed by UC Berkeley. The UC Berkeley Extension Program has acquired PeopleSoft�s student administrative system.

Yale University

Yale University has recently completed a parallel implementation of the suite of financials (general ledger, purchasing, accounts payable, financial analyzer, and a new, co-developed post-award grants management system) and human resources/payroll applications from Oracle Corporation. Previously Yale deployed the SCT Banner student system and the Datatel Benefactor alumni development system. The Yale School of Medicine Faculty Practice and the Yale University Health Service have recently implemented the ambulatory care suite from IDX Corporation.

ERP Implementations: Advice from the Trenches

Endnotes

1 The authors express their sincere appreciation to the collaborators on the 1999 NACUBO, Snowmass, and EDUCAUSE conference panels. James Bruce, vice president for information systems, MIT; Marilyn McMillan, chief information technology officer, New York University; and Joseph Mullinix, vice president, Finance and Administration, Yale University, contributed many of the ideas and observations presented in the article. The exciting give and take of the panel formats makes it impractical to identify each individual�s contribution. The panels were a true team effort.

2 An excellent reference that explains both the source of many of the inherent problems of large complex projects and how to survive them is Ed Yourdan�s book, Death March--The Complete Software Developer�s Guide to Surviving �Mission Impossible� Projects (Englewood Cliffs, N.J.: Prentice Hall PTR, 1997). Also worth reading is Campus Financial Systems for the Future, published in 1996 by CAUSE and the National Association of College and University Business Officers. Although its focus is financial systems, the campuswide processes it outlines are equally applicable to enterprise systems implementations. It is available online at http://www.educause.edu/ir/library/html/pub5003/fis-home.html.

Jack McCredie ([email protected]) is associate vice chancellor, Information Systems and Technology, at the University of California, Berkeley, and Dan Updegrove ([email protected]) is university director, Information Technology Services, at Yale University.

...to the table of contents