The Art and Politics of Re-Engineering Under Crisis Conditions Copyright CAUSE 1994. This paper was presented at the 1993 CAUSE Annual Conference held in San Diego, California, December 7-10, and is part of the conference proceedings published by CAUSE. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, that the CAUSE copyright notice and the title and authors of the publication and its date appear, and that notice is given that copying is by permission of CAUSE, the association for managing and using information technology in higher education. To copy or disseminate otherwise, or to republish in any form, requires written permission from CAUSE. For further information: CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303449-4430; e-mail info@cause.colorado.edu THE ART AND POLITICS OF RE-ENGINEERING UNDER CRISIS CONDITIONS Lynn A. DeNoia Bryant College Smithfield Rhode Island Re-engineering an entire college administration can be daunting -- wholesale change is intimidating and unwelcome to many. Common wisdom from the literature suggests that re-engineering should take place in times of stability and good fortune. In practice, there may be little motivation short of crisis for even launching an encompassing re-engineering project. This paper describes how Bryant College got started on such a project, the crisis conditions under which the project is proceeding, and the lessons we have learned to date. MIS Project Background In early 1991, Bryant College's administrative information system (IS) consisted of a set of independent modules for major functions, each with its own internally defined, flat data files. Most had come originally from a package purchased in 1986, but had been extensively modified. Custom linkages had been built between modules to copy data from one area to another. People were reasonably satisfied with existing functions, but requests for changes and enhancements were being met very slowly, or not at all for lower priority offices. In fact, the combined backlog of requests and necessary systems maintenance was estimated in excess of 200 days of programmer/analyst effort. New leadership in the Development, Alumni, and External Affairs Division found the available IS functions to be inadequate for a proposed major fund-raising campaign. Their inquiry about possibilities for improving existing or acquiring new systems provided the impetus for a College- wide review of administrative IS needs. The Executive Director for Information Technology (EDIT) asked Vice Presidents to name representatives from major administrative offices to an Administrative Systems Advisory Committee (ASAC). The ASAC, which was first charged with articulating needs, became an important forum where members learned from each other about how the College did its business and how similar many of their needs were. The EDIT then involved ASAC in development of a Request for Proposal to replace the existing administrative systems with a comprehensive set of applications built on an underlying, integrated database. Pricing was requested for initial purchase of Alumni/Development support alone, and for acquisition of a complete system to handle student information and services, and College financial support functions as well. By the time they completed functional evaluation of the candidates, ASAC members concluded that enrollment management might benefit from a new system as much as, or even more than, Alumni/Development. Consequently, ASAC recommended acquisition of a complete new administrative management information system (MIS), and the EDIT proposed it to senior management. The proposal was endorsed by the Board of Trustees in May 1992, a contract was negotiated, and system implementation got underway. Admission and Development, the two sources of College revenue, were targeted for first implementation. College Context: Crisis and Opportunity In addition to declining demographics, for which we had been planning, Bryant has also been faced with a Northeast regional economic slump and a significant, unexpected loss of student interest in undergraduate business majors, our academic specialty. Much of the motivation for the new MIS came from interest in acquiring better tools to support improvements for the Admission and Financial Aid Departments in marketing and recruitment of new students, key activities in our consolidated approach to enrollment management. We also expected to contribute to retention by improving the timeliness of, and enhancing services to, continuing students. During the fall of 1992, following budget cuts and administrative staff reductions, the College faced growing organizational unrest among its faculty and staff. While the EDIT had always intended for the MIS project to provide an "excuse" to foster examination of business processes, College economics and politics made that more important and more difficult at the same time. The pressure was on all areas of the College to cut costs, increase revenues, and generally do more and better with fewer people. In retrospect, it is easier to see that most participants did not appreciate the time or effort involved in shaping and learning a new system, much less in re-engineering our business. We continue to be faced with constraints on staff time and resources, needing to run up the learning curve and maintain business operations both, in offices already feeling overwhelmed by short staffing. Project Approach and Major Players The Executive Vice President (EVP), with primary responsibility for enrollment management and particular focus on recruiting, became the senior-level project champion. The EDIT took overall responsibility for project success, beginning with hiring a Project Manager to be responsible for the team of programmers and analysts. This person was selected by a search committee composed of two IT staff and three ASAC members who would be users of the new system. The EDIT also requested full-time assignment of a Team Leader from user ranks to guide users in shaping the student information system. We described the roles of these latter three as: chief politician, chief technical expert, and chief user advocate. Together they formed a management triad for project direction and execution, picking up leadership for the project from the ASAC. Because she had chaired ASAC through that activity, the Team Leader easily carried forward the collaborative and educational advantages of ASAC's participation in the MIS selection. Her first task was to fill all the code tables that tell the software package how Bryant wants to work. She drew representatives from every administrative office involved with students to form a Coding Committee. Together they examined and agreed on values for over 100 system tables, while the EDIT had ASAC went on to formulate policy recommendations for who would have access to what data for what purposes. Guided by the software vendor, all administrative offices participated in an overall project schedule planning exercise. Discussions of work breakdown into tasks and relative timing were later held by the Project Manager with individual offices. The schedule was then adjusted to fit work around periods of peak office activity. The order of implementation reflected expectations for benefit or internal software linkages, e.g., we put admissions first and the group of financial aid, accounts receivable, residence life, and registration second. One thing we failed to do, however, was incorporate the process review and analysis activities overtly into the project schedule -- not even as placeholders for time or staff assignments. Getting Started -- Admissions and Financial Aid With our eyes on the potential benefits of making new tools and capabilities available to people responsible for ninety percent of College revenues, we jumped into implementation of the admissions module for the full-time undergraduate Admission department. The first target date, to capture data and generate correspondence for prospective applicants, was missed by three months, primarily due to late delivery, installation, and debugging the setup of hardware. Beyond this, IT did not fully understand, until the module went into live operation, that Admission staff expected to get exactly the same reports (content and format) from the new system as came from the old one. We did discover that management commitment to process review was inconsistent across departments, however, as soon as the EDIT convened a group to assess alternative approaches to data entry. No commitment to consider or implement change was generated. At the time, the perspective from the Director of Admission was that people could not appreciate how different the new system might allow things to be until they had "put their hands on the keyboard" to gain experience. This tended to drive us to take an incremental, rather than a synoptic, approach. While software implementation activities were focused on undergraduate admissions, we took a different approach with Financial Aid. A faculty member from the Computer Information Systems department offered and was encouraged by the EDIT to begin from a process review perspective. He interviewed Fin-aid staff and documented their existing operational procedures, data flows, and decision processes, and fostered discussions about what improvements they would like to make in their services. People concluded that improvement would be more likely if changes crossed departmental boundaries instead of being confined within Financial Aid. By this time, however, pressure on IT to address Admission's issues was so great that no forum was provided to extend the Fin-aid discussions to the related departments. All IT support for Financial Aid became focused on adapting to the new federal rules under the Higher Ed reauthorization. In an attempt to consolidate articulation and understanding of Admission's expectations, the EVP was eventually called on to moderate development of a "contract" between Admission and IT that listed functions and reports required to make the software implementation "successful." All available programming resources, including an outside contractor, were then assigned to Admission to clean up outstanding items. A new schedule was proposed, naming a new target for complete live operation by Admission and, after discussions with other departments, dropping the next modules back about six months. The EDIT suggested separating Admission, as Phase I, from the next modules, as Phase II, to formalize what had been learned into a different model for project leadership and management. Toward the end of the period of intensive focus on Admission, the EVP and EDIT agreed on a quick review by an independent consultant of the project status and recommended schedule and management changes. Interviews were arranged, recommendations received, and proposed changes endorsed. The consultant assisted us to focus and articulate what we had learned so that it could be captured and put to use for the remainder of the project. Lessons Learned Probably the most basic lesson we have learned is: (1) effective re-engineering is difficult to accomplish as a byproduct or side effect of another project. The level of commitment for time and resources must come from the top down and be consistent across the College. Our financial concerns made the dollar investment in acquiring the IS hardware and software paramount in most minds, focusing staff time and energy on opportunities for cost recovery or revenue enhancement rather than service or business improvements. It is critical to set the context and project philosophy to emphasize customer service enhancement and job effectiveness, NOT the information technology tools. Today this seems rather obvious, but when we started, little practical guidance was available in the literature. The most important lesson we have learned to date is: (2) there is a huge difference between user participation and user control. User departments at Bryant were accustomed to asking IT for data or functions, having IT go away and make it happen. Previous system conversions had been done over a week-end and were largely transparent to user operations. The EDIT's inclusion of ASAC, not just in evaluating candidate systems, but in making the final selection, can now be seen to fit a familiar pattern of user control, although the process was quite different. The departures came when control transferred to the project management team, and substantial user participation was required, first for coding and then for implementation tasks (such as training each other, learning the query language, documenting procedures, etc. -- things that had been done for them by IT in the past). In retrospect, we had gone from one extreme to another, from complete user control and little participation, to little user control with major requirements for participation. We've found that an important companion to control is: (3) users need to be accountable to each other for system decisions that affect overall project implementation schedules. We really caught ourselves on this one -- with IT, particularly the programmer/analysts, taking all the heat for missed target dates, when users had actually been expanding their expectations and functional demands as they learned more about the new software capabilities. The more energy IT invested in Admission, for example, the less time was available to prepare for the next set of modules. IT staff became incredibly discouraged at not being able to finish things on time, Admission got no nearer to completion, and other users began to lose interest, feeling we would never get to them or would not be able to meet their needs either. A lesson it has taken us some time to appreciate is: (4) our vendor did not understand what was involved in, or assume adequate responsibility for, ensuring the success of our project. Phase II -- What We Plan to Do Differently After more than one year's work on Admission, the EVP has reconvened the ASAC with a longer-range charge to advise the EDIT on administrative technology needs, serve as a clearinghouse for information related to campus-wide administrative computing, and keep the EDIT apprised of issues. For the duration of the MIS implementation, a subcommittee of the ASAC, called the MIS Steering Committee, will be responsible for guiding the project by defining the scope of activities, setting priorities, and monitoring progress. Membership on the Steering Committee includes a representative from completed modules, to provide insight from experience, and representatives of the modules currently being implemented. The Committee will be chaired by the Dean of Administration; the IT Project Manager and the vendor account representative will provide resources. We thus return control of the project to the first-line users, giving them back responsibility, and matching that with accountability, for project decisions. The first task for the reconvened ASAC is to review and finish documenting their policy recommendations for data access, privacy, and security. The EDIT will also ask ASAC to consider the questions raised by senior management about how much process review and design the College can "afford" right now. Our impression is that only a grassroots commitment could rekindle enough enthusiasm to carry the re- engineering effort forward. My concern is that, while necessary, it may not be sufficient so long as a crisis attitude prevails. Every office needs to continue operating with fewer staff, making project time difficult to carve out of routine office duties. This is the new reality, however, and we must learn to cope with it better. Upper level management commitment for any re-engineering is vital; it remains to be seen whether ASAC can generate it. This is another, although possibly local, lesson: (5) it is difficult, if not inappropriate, for re- engineering leadership to come from IT. On the other hand, upper management support is clearly necessary, as demonstrated by the success of a process review completely separate from the MIS implementation. A registration process study group was charged by the EVP to examine the various ways and places we perform student registration (full-time undergraduate, part-time undergraduate, graduate, continuing/ professional) and to recommend appropriate consolidations for economy of operation and improvements in service. The MIS Project Manager was a member of the committee, but served only as a consultant on how the new MIS might support any changes under consideration. This group's work was incorporated into a recent restructuring of the Academic Affairs division, but has not been used to advantage as a prototype for other process review activities. For phase II then, the EDIT will try to focus IT's attention on serving customers with the software implementation. We need to capitalize on what we learned with Admission, including creating more formal "contracts" to specify functions and reports that will constitute "successful" implementation. These will be developed under the supervision of the MIS Steering Committee to ensure College objectives and schedules are met and that required resources (IT and administrative staff) are available or can be obtained. In addition, IT needs to pay more attention to the time required for users to develop a level of comfort in understanding the new system capabilities before certain decisions about the suitability of functions and operations can be made. During phase II, IT must: 1. Focus on the user by: placing early attention on user needs and expectations; finding ways to build credibility and forge alliances within each user department; paying attention to user business requirements and perspective. 2. Stay grounded in reality by: pairing up visionaries with detailed pragmatists ensuring that planned changes are realistic (e.g., in Admissions, we assisted with redesigning their application form so that data on the form matched the order of items in the new data entry screens). 3. Build user investment by: putting their hands on the system as soon as possible, and guiding them to see it as part of the solution rather than a new problem. 4. Find ways to bring underlying assumptions to the surface by: writing things down (the "contracts"), working beside users in their environment, and checking, checking, checking with those users. 5. Keep things moving by: involving users continuously, building on project momentum, and especially enlisting and encouraging user "champions." 6. Capitalize on user strengths by: encouraging and harnessing user enthusiasm and creativity, making a concerted effort to "see it their way." 7. Encourage the celebration of victories by acknowledging the effort, investments, and progress made by all involved with aspects of the project. Meanwhile, the Steering Committee will be intimately involved with the detailed progress of the MIS implementation. They will report to ASAC at least quarterly, creating a vehicle to communicate that progress widely. We hope that users of modules still to be implemented will develop a better sense of what it takes to achieve, and the likelihood of, success for their areas. Each will serve on the Steering Committee as we move to their module in the implementation plan. The Steering Committee will also report to the EVP quarterly so that progress can be communicated to the rest of senior management. We expect to use broader communication of objectives, responsibilities, target dates, and progress to focus the community on the MIS implementation as a College- wide, not an IT, project. A Parallel Implementation One of the reasons we are disappointed with our progress on the student services and information side is the contrast with our Alumni/Development experience. This area has a much smaller, more tightly knit group of people (consisting of only two rather than twenty department/offices), who were coming from old software that provided separate files for alumni, donors, and giving history, along with some transaction processing. Little customization or enhancement had been done because there had not been consistent leadership in the division for long enough periods. We used a parallel project approach with a team leader for implementation and a user committee to specify the necessary code values. In working with Alumni/Development staff, we found that the size of the gap between an inadequate old system and a very sophisticated new one was a definite bonus. Reviewing and changing how they did their business became an integral part of discovering how to set up and use new capabilities to advantage. User expectations about the learning time and energy required were more realistic from the beginning, and there was no history of having IT "do it for them." The software modules require outside linkage only to the General Ledger; otherwise they are self-contained. Because this mirrors our organizational structure, it was easy for users to accept -- they did not have to coordinate with formerly independent offices to make the system effective. Successful implementation of very sophisticated functions was achieved in less than one year. Major benefits of the process and system are quickly being demonstrated. Although key users left the College during the implementation period (the team leader and several directors), we have restructured and combined staff functions from previously distinct areas to reduce the total number of positions and still operate better than ever before. Our first supported phonathon is currently in progress. Conclusions -- While They May Seem Obvious... To re-engineer successfully, we now understand better that one must: 1. Emphasize enhancement of customer service and improvements in job effectiveness -- not the information and technology. 2. Get users invested in designing and becoming part of the solutions -- instead of allowing them to wallow in the problems. 3. Coach IT staff into a user-based, customer-service perspective -- instead of allowing them to concentrate on installation of technology. 4. Formalize the process of discovering assumptions, articulating expectations, and building shared vision -- instead of assuming that everyone is moving in the same direction toward the same goals. 5. Create formal, public user stakes in the project. 6. Find ways to create early successes, even if small, and publicize, publicize, celebrate -- don't assume that successes are obvious or that everyone notices them. 7. Make sure that project management is handled by a team with a strong, consistent vision, operating with a single philosophy, and communicating clearly among themselves and with others -- not simply a group of people cooperating during a project term. 8. Set goals realistic for both the people and the institutional setting, and try to establish metrics for assessing benefits to be achieved. Don't allow the vendor to set goals, and don't follow someone else's plan -- it is rare for sister institutions to have similar enough characteristics. 9. Have everyone who is affected by the changes participate -- even if they argue that their contribution will be minor. 10. Recognize the enormity of the effort: the time, energy, people, and physical resources required -- there is no "free lunch." Above all, expect that re-engineering will be a complex, often bewildering, and typically threatening "change process" for both IT and users. We've found that the management key to successful re-engineering is to reduce the associated personal, process, and organizational uncertainties. We should manage the risks and let the participants design and manage the processes.