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.
Mount Holyoke College Reshapes Reengineering
by Madeline Carnevale, Sandra Berestka, and Debra MorrisseyReengineering projects at Mount Holyoke College led participants to conclude that business process reengineering (BPR) in higher education involves a magnitude of cultural change that differentiates it significantly from BPR in the corporate world. This article explores why reengineering principles themselves had to be reengineered at Mount Holyoke and describes two projects that were successful even though they did not follow the �rules.�
After a number of belt-tightening, budget-reduction years, Mount Holyoke College turned to reengineering in 1996 to reduce costs and improve quality of services. Those of us involved in the reengineering effort expected radical change. We trained in the methods of business process reengineering, had top-down support, and focused our efforts through a well-articulated plan. Despite all our training and preparation, our reengineering results deviated from that plan. We did not achieve the �radical change� we had expected and began to investigate the reasons.1
This article describes our preparations, the changes we found ourselves making in the process, the influences the academic setting played in the process, and ultimately our acceptance of divergence from traditional business process reengineering methodology. Two specific instances of reengineering at Mount Holyoke and how they varied from the formal process, yet remained successful, are presented.
The preparation
Mount Holyoke�s training in business process reengineering followed the design provided in Hammer and Champy�s Reengineering the Corporation where reengineering was defined as �the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in cost, quality, speed and service.�2
The college began by having senior staff and managers participate in a conceptual version of reengineering led by an outside consulting team. This helped them understand, support, and recommend further reengineering efforts. �Promoters� at the senior staff level were assigned to make budget and project priority decisions. �Leaders,� for training and specific projects, had reengineering built into their job responsibilities. The consultants also trained the leaders to be able to take over their new responsibilities. With all of this careful preparation, we felt confident in undertaking our reengineering assignments.
Administrators did an excellent job in reassuring staff that they would not lose their jobs as a result of these efforts. The college has not used layoffs as a means of budget reduction but has instead successfully used attrition and work reassignment. Because staff have confidence in this process, they maintain a more open attitude toward the changes resulting from reengineering projects. In fact they have initiated some of the projects.
Following are two examples of reengineering projects undertaken at Mount Holyoke College. The examples highlight the points of divergence from the Hammer and Champy process. The first example took place in the former technical services department of the library. The second example is the process of merging the entire library with the computing and information services organization.
First project: Redesign of a library department
In preparing to redesign the library�s technical services department, we read that radical redesign and sweeping changes were key elements of a successful reengineering project. Admittedly, those of us charged with restructuring technical services were dismayed after reading the literature. We knew that completely discarding our current processes and management structure wasn�t going to happen, given our environment. We were very uncertain, and perhaps doubtful, that our work as a restructuring committee would come anywhere close to a �successful� reengineering project.
We persevered for an entire year. We interviewed all department staff members to gather their ideas, toured other sites that had gone through a reengineering process, met with consultants, and learned workflow analysis. It was difficult work and sometimes contentious. Our work culminated in a written report that outlined a set of goals and then presented revised workflows based on the team concept.
Significant changes did not occur overnight. A flatter management style and team-based concept of work evolved over time. Was our reengineering project a failure? We thought so when we compared our slow progress to the kind of change delineated in the BPR literature. But in reality we had not failed. We were adapting a �lifestyle� of change, a style that was and is better suited to our academic culture. What follows are two BPR principles that we altered while still managing to effect significant change in the process.
Do not include in your reengineering process managers who fail to see the need for change.
What do you do with a valuable, respected manager who doesn�t see the need for a reengineering process? Do you exclude the person from the process as the literature would suggest? We weren�t comfortable with that approach and chose to include the manager on the reengineering team. The team consisted of three technical services staff, one public service staff member, and the head of technical services. Here are some outcomes of including the head of technical services on the reengineering team.
First, including a manager who doesn�t see the need for change will slow down your process. However, our experience tells us this isn�t always bad. Our department manager knew the history of why certain procedures were performed. The restructuring team was able to learn that history and decide whether or not the reasoning behind decisions of the past still applied today. We were forced to defend change and have real reasons for it. Though this made for a time-consuming process, we ended up with a better product.
Second, our current manager was able to consult and learn from the former head of technical services. Not only were they both on the reengineering team, they also worked together for an entire year before the management change occurred. A consultative relationship developed and continues today even though the previous manager now works in a different part of the organization. The outcome of these two individuals working together was that staff trusted and respected the process. Staff �buy in� occurred more naturally than expected. Transitioning from one manager to another wasn�t forced, which meant staff loyalties shifted more easily and distrust for the process dissipated. While this approach may not be possible in all situations, it is one to consider as you think about moving your reengineering efforts forward. Managers resistant to change may be one of your best assets if you approach their inclusion with respect, patience, and vision for how they can benefit your efforts.
Change should happen quickly.
As stated previously, change did not come quickly in our process. It took us three years to complete about 90 percent of our original reengineering goals. While our lack of speed was a source of discouragement, we no longer regard it as a failure of our process. Taking time to implement our goals allowed us to evaluate them and identify new and better goals along the way. Change became a continual process rather than a one-shot deal. Staff members fearful of change didn�t have to cope with it overnight. Over time our departmental culture migrated from one that was resistant to change to one that expects it. We consider this a positive outcome of a slower paced reengineering process.
Our department looks very different from a few years ago. We have three fewer staff positions than in 1995. Our director made it clear that cutting positions was not a goal of our reengineering process. However, achieving a more efficient workflow allowed us to relocate 2.5 staff to other areas of the organization and to not refill one part-time position. We continue to rethink our workflow as resources and needs shift. Teams of staff are �owning� their expertise and the management style is more collegial. We are a healthier group and fully expect that our work and responsibilities will continue to change.
Second project: Merging computing and the library
When Mount Holyoke decided to merge and reengineer the library with the computing organization, there were a number of internal and external factors that made it an ideal time to do so. These included a new college president, a new college librarian with a strong technology background, and a strong working partnership between the college librarian and the director of computing. The external factor was the rapid pace of technological change and the impact it was having on the academic world.
In this project, again we found it necessary to diverge from accepted BPR practice in at least two ways.
Start the project with a clean slate and make no assumptions about what the organization will look like at the end of the process.
As a service organization on a college campus we were not given this option. The provost, in consultation with the director of computing and information systems and the college librarian, decided to merge four groups: Library, Computing and Information Systems, Language Resource Center, and Electronic Services. The mandate was to merge the units while maintaining their primary roles of support for the academic program of the college. We were given six months to consult broadly both internally and externally and to devise an organizational structure which seemed workable.
An additional difficulty we had to address was that some groups on campus were not happy with the method used to make the merger decision. They felt the decision to merge the units should have been made only after consulting with the larger college community. During the six-month transition period an enormous amount of energy was put into communicating with the campus. Regular updates were made to the provost, to both faculty advisory committees (one for the library and one for computing), and to monthly faculty meetings. Choosing the name of the new organization was very politicized. There were faculty members who felt �library� should be prominent, others felt that �service� and �information� were essential in the name, and high-end users felt �technology� had to be included. The final result was a combination of the units� previous names: Library, Information and Technology Services (LITS).
Once the provost announced the merger, a transition team was formed. It was led jointly by the director of computing and the college librarian and included representatives from each of the units affected (five people) as well as three faculty members and two students. It is at this point that the restructuring work began. Although we were told which units had to merge, the functions and staffing of those component units were not predetermined by the decision to merge. The transition team appointed several task forces to work on particular issues and report back. The merger did not force any unnatural relationships. Personnel were placed based on skills and to some extent the interests of the staff member. At the time of the merger some functions or services could have fit into one of several units. The decision on where to place the function was made based on where it had previously been or in some situations it moved with a particular manager. These decisions were revisited at a later time.
Change should happen quickly.
Although the actual formation of the component units, the staffing of the units, and the choosing of a name were completed in six months, the implementation stage of the reengineering has become a life style. The academic year made it impossible for some processes to be implemented quickly. The academic budget cycle caused the implementation of a combined budget to be delayed until the following academic year. Yet another result of an academic year cycle was that the creation of a new faculty advisory group was delayed for 10 months. The faculty advisory groups for the library and computing met jointly during that time, and a new advisory committee for the LITS was elected by the faculty the following academic year.
During the first year we discovered that some functions did not fit well in their units. They were then shifted with the staff to another unit. At this point in reengineering, the initiative to shift functions came from the staff involved. In one example two managers approached the director to discuss the functions that did not fit in one unit but seemed more natural in the other. A second unit experiencing a number of vacancies used the opportunity to reconfigure the positions in the unit and to share responsibilities across the broader group with more cross-training.
The most time-consuming aspect of the restructuring was the merger of the library and information technology cultures. Within a month after the provost announced the merger, the merging units closed for a one-day staff retreat. This retreat focused on commonalties among the merging units, similarities in services, and what made these units a good fit. The staff retreat is now an annual event. Topics covered in subsequent years include a review of the organization, work plans, mission statements, working together, and understanding diversity.
During the first six months of transition all-hands meetings were held each week, updates were given on progress, and questions were answered. After the merger date the meetings became monthly and had a different content. As part of the cultural merge, each of the units in the new organization did a presentation to the staff on their unit, highlighting who they are and what functions they perform. As we move into the third year, the meeting format has expanded to include other campus departments. These discussions focus on what they do and how LITS can support them as well as particular issues that affect the organization such as preservation of electronic media and the year 2000 issues.
One of the tools that helped merge the cultures was the middle managers group, which consists of the managers from all the units, the director of LITS, and the senior technology planner. They meet every other week to discuss issues, to craft work plans, and to update the status of projects. The merging of cultures took time, but the group has become a cohesive team that works well together. This group is a good example of embracing differences in culture and using those differences to create a strong working team.
The organization flourishes in spite of the many internal and external pressures exerted on its creation. The benefits of change from this project include the following:
- The flexibility created by restructuring has allowed LITS to reduce positions by five and, even more importantly, to shift staff to where the demand is.
- Channels of communication are more evident between the campus and LITS. There are regular mailings from LITS to the campus on activities, accomplishments, and changes, and all units� work plans are posted on the Web every six months.
- LITS is in a better position to be flexible when dealing with the fast pace of technological change. This new organization is open to change.
- Reengineering has put LITS in a position of campus leadership on information, technology, and work restructuring.
Finally, and maybe most importantly, in the spring of 1997 the college was reviewed for re-accreditation. The accreditation committee noted in their report that the LITS organization �has achieved a level of deployment and support for information technologies that is certainly at the top rank of peer colleges and, by many indicators, is competitive with universities more widely recognized as leaders in the area.�
Reengineering in an academic setting
When we started making changes to the business process reengineering plan, we began to look for an explanation for the many differences between the academic and business settings that were causing these accommodations to be necessary.
Businesses often have to recreate a marketable product and capture customers with their first contact. In some cases corporations may be in life-threatening situations when they decide to employ process redesign. Because of the urgency they fund the project up-front, pour resources into it, move it along quickly, and make all the changes needed for implementation to roll out the radically new and improved product on which their existence depends.
While this may be the case for a few academic institutions, it was not for us. At this time we are not seeking to change our core product, which is education. We are more concerned with the products of �administrative support of the institution� and �marketing the institution to prospective students.� Hence Mount Holyoke College is not experiencing fast, radical changes but gradual, open-ended ones.
In contrast to up-front funding from businesses, most reengineering projects at Mount Holyoke College are expected to become a part of the normal budgeting process. Capital funding exceptions take place for large hardware or software system upgrades. This results in the research phase of the reengineering projects being on schedule, but the smaller projects then queue, waiting for appropriate budget cycles or grant funding. Grants have played an important role in providing additional staffing and resources to carry us through the implementation phases of reengineering. Two recent grants have provided the college with a Webmaster and a Web trainer.
Conclusion
After our initial disappointment in not being able to follow the Hammer and Champy program of reengineering and understanding the issues subverting the process, we were able to accept our need to reshape reengineering. Until Mount Holyoke College has a need to reengineer �education,� we can�t expect to have totally radical changes. We can experience creative change in our focus on improving administrative support services and in marketing the college to prospective students.
We have established a healthy rhythm of initiating, prioritizing, funding, and completing the research phase of smaller reengineering projects (see Table 1). A pattern is emerging that suggests it takes one to two years to complete the implementation of the proposed changes. We are very fortunate that the campus culture is poised, positioned, and prepared to continue making needed changes.
Table 1: Reengineering Projects at Mount Holyoke College
PROJECT RESEARCH IMPLEMENTATION COMMENTS Serials/Cataloging Department Redesign 1995-1996 1996-1998 Very successful Merging of Library, Computing, Electronic Services, and Language Learning Center 1996
1999-
1997-continuing Very successful, open for more modifications
Two departments now self-managed teams
Buy-Pay (purchasing process across campus) 2/97-5/97
8/99
Working on Web access pages On hold until new financial software is implemented.
Defining Phase II which will resurrect buy-pay
Financial Services Department 1997 Implementing Lawson software
6/99 implementation complete
Will change office procedures to match new software, workflow built in
Defining Phase II to bring workflow management to the desktop
College Catalogue Production 12/97-2/98
5/99
Working on Web database 2/1/00 - go live date Was on hold for staffing
Grant provided funding for database programmer
Student Systems Software 1997
Summer 99
Fall 99
Doing preliminary research until other projects clear Departments doing background for reengineering work Project manager hired and set-up budget approved Determining if should enhance current system or buy new Sidebar
Components of a Successful Reengineering Environment
You are done tightening your belt.
One of the tests for whether your institution is ready for reengineering, or a version of it, is that you are at the end of the belt-tightening process of budget reductions. For a number of years your institution has participated in staff attrition and flat budgets and you are convinced that you can�t redeem any more funds unless the processes themselves are streamlined and modernized.
You want to put more information into the hands of potential students and the campus community.
Your institution has passed the phase of saturating the campus with computers, and you are helping offices to transform processes so they are efficient and friendly for users. You are trying to take advantage of technology and put information directly into the hands of the campus community both for updating and inquiry.
You have strongly positioned �promoters.�
The key people to make reengineering a success are the promoters. They should believe they are responsible for selling the need for reengineering to the entire institution, starting from the top. They must also believe they will provide the recharging to keep it going. Promoters have to be positioned within the institution to be main influencers at all levels. They provide key budget, staffing, and prioritizing decisions.
Your project �leaders� have reengineering as a part of their jobs.
The number of qualified leaders to be developed depends upon the number of reengineering projects you want to undertake. In building a balanced team of leaders, choose individuals who have skills in technology, finance, human resources, change management, systems analysis, institutional views, and leadership--and who have strong �people skills.�
Your institution cares about staff.
Administrators have to do an excellent job of reassuring staff they will not lose their jobs as a result of reengineering efforts. Up-front training about all the options for change in job positions should be explored with staff. Information about exploring reassignment to another position, redesigning their jobs to fit into the reengineering plan, maintaining productivity during the months of transition, and basic change management principles should be communicated effectively.
Endnotes
1 The results of our investigation became the basis of a presentation at CAUSE98. The paper can be found at http://www.educause.edu/ir/library/html/cnc9863/cnc9863.html.
2 Michael Hammer and James Champy, Reengineering the Corporation: A Manifesto for Business Revolution (New York: Harper Business, 1993).
Madeline Carnevale ([email protected]) is director of Desktop Technologies; Sandra Berestka ([email protected]) is director of Serial and Monographic Services; and Debra Morrissey ([email protected]) is assistant to the director of LITS, in Library, Information and Technology Services at Mount Holyoke College.