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.
Lessons Learned in Process Reengineering at a Community College
by Gayle E. Jaacks and Michael Kurtz�Paving cow paths� with new technologies seldom causes significant improvements in productivity. To truly benefit from implementing new systems or major system upgrades, an institution must streamline processes, eliminate duplication of efforts, and examine outdated or inefficient ways of doing business. This article summarizes the successful reengineering of business processes to take full advantage of new functionality in a vendor system upgrade at a mid-sized community college.
In 1992 Western Iowa Tech Community College (WITCC) moved from a semi-home-grown management information system called the Kirkwood system to a third-party software package, Datatel�s Colleague. Over the past seven years the college has committed extensive personnel and financial resources to the full implementation and integration of the system into most business operations, including admissions, registration, financial aid, registrar records, degree audit, accounts receivable, cash receipts, third-party billing, accounts payable, human resources, payroll, general ledger, budgeting, and purchasing. The system is the heart of the college�s data collecting, storing, processing, and retrieving activities, and WITCC has continued its commitment to a fully integrated information system by implementing each system upgrade through the years.
Thus, in the spring of 1997 the college found itself again faced with a strategic opportunity for change. The new student system release provided by the vendor was the most extensive upgrade to our systems since the original conversion in 1992. Datatel had literally rewritten every line of code in all the student modules including faculty information, curriculum management, recruitment/admissions, registration, academic records, degree audit, accounts receivable, cash receipts, third-party billing, and communications management.
WITCC had three models for the new software implementation. First, we could continue with business as usual and implement the software utilizing the same functionality as the old version. This would not have taken advantage of any of the new functionality of the software. Second, we could make minor improvements to our business processes in order to take some advantage of the new software�s functionality. The third option was to carry out a comprehensive critical review of the college�s business processes and reengineer them to take full advantage of the new functionality. These options were presented to WITCC�s executive leadership with a recommendation to take advantage of the situation and reengineer business processes.
We were fortunate that our college president was quick to endorse the recommendation to reengineer processes, as this early executive acceptance would be critical for the project to succeed. The president was convinced, and everyone agreed, that the college would embark down the road of business process reengineering. However, few people at the institution understood what BPR really meant and how this project would affect their lives and the college for years.
The model: widespread ownership
One of the problems facing the organization was overcoming the perceived shortcomings of the original large-scale software implementation. Although the college had successfully implemented smaller releases of the software, the last major system implementation had been the conversion from Kirkwood to Datatel. During that implementation, two management information systems (MIS) professionals were responsible for the success of the implementation. The information technologies (IT) department took strong ownership in the project and was viewed as the only resource to make decisions about the system. It was dubbed the �IT department�s system,� and although the implementation was a success, the department was blamed for any flaw in the implementation. This lack of ownership by the college as a whole could be viewed as the biggest problem resulting from the original implementation. We were determined to solve that problem.
Core team. The process reengineering model that was designed and adopted for the more recent implementation project involved a fully cross-functional team approach. It called for a core team of people from across the institution to represent the leadership of the project. This differed from the original implementation in which only IT staff were fully involved across all aspects of the project. This core team concept would require high commitment from the entire college staff.
As the model was designed, there would be implementation teams created for each of the different functional areas of the college. The model called for every member of the core team to attend meetings of and work with every one of the other implementation teams. This would provide an entire perspective for each of the functional areas. The idea was that the accounts receivable (A/R) area might have some good insight on the admissions process or the degree audit staff might have an idea for registration. In the original implementation, the college had had implementation teams that consisted only of those people directly associated with each function: admissions staff were on the admissions group and A/R staff were on the A/R group. The cross-functional concept was designed to produce a better-rounded result.
Testing teams. The next part of the model included a set of teams that would be formed from the implementation teams called testing teams. Another significant deficiency, or at least a major criticism, of the original implementation was a scarcity of testing. The testing teams would be responsible for testing the decisions made by implementation teams.
User teams. Finally, the last part of the model called for user teams. These would consist of the end users of the software, who would be trained to use it.
This team model was presented to the administration and a modified version was approved for the implementation. The college saw this project tying directly into the upcoming self-study and visit for accreditation in 2003. The modifications included adding a steering team to provide administrative oversight for the project. This team was to remove barriers and provide support for the core team when major college policy and direction were needed. The steering team, which was not going to be fully trained in all aspects of the project, would consist of the senior college leadership (excluding the president) as well as the director of IT, and would exclude anyone on the core team except the project director.
Choosing the right leader
The college also saw the need to make this project someone�s individual responsibility. In the original implementation, it was clearly the responsibility of the two IT professionals who were hired specifically for the task. This had been seen as a positive situation because they were well motivated to accomplish the goal. Only one of the two IT professionals from the original implementation remained at the college. During the original implementation he had been in the position of systems analyst/programmer, mainly responsible for the business and financial aspects of the system. By the time the new implementation process began, he had moved up in the organization and was the director of information technologies. The rest of the IT staff directly involved with this project consisted of a programmer, a data analyst/project manager, and a data analyst/programmer.
An IT staff member was viewed as the most obvious choice to take on the responsibility for the project. However, the college leadership felt that a more end-user-driven process would be better for the college because it would bring acceptance from the entire college community. It was determined that a person responsible for such a large project would need to be a current employee of the college. Bringing in a new hire for this task would waste too much time in organizational orientation. This person would have to be released from his or her current duties between 50 and 100 percent for at least 18 to 24 months. Having knowledge of the current system was a mixed blessing. If the person had no prior experience with the system, there would be considerable time required to bring him or her up to speed. If the person had too much experience with the system, it would be difficult to shed prejudices and accomplish a true reengineering project.
According to BPR best practices, the effort should be top-down, supported by the executive leadership, clearly communicated to the organization, and not led by the technology unit. Thus the director of IT was eliminated from the choices of project leaders because of the political baggage that would come with IT leading the project. Other people were also discussed, but those with the time available were not skilled enough to handle the project and those with the skills were too busy with other projects to free up 100 percent of their time for 18 to 24 months. There was an ideal individual available--the data analyst/project manager--because the person in that position had studied the theories of business process reengineering and consulted with the president on BPR concepts. This person was highly motivated and well skilled to handle a project of this nature. The big drawback was that she was a member of the IT staff and assigning her to be project manager would not accomplish the goal of getting the project into the hands of end users. Thus the solution was to move the data analyst/project manager out of IT to lead the project from a position reporting directly to the executive vice president.
The plan included physically moving her office to another area, thus divorcing the project from Information Technologies; the president and executive council openly supported the project through meetings with the team members in the early phases of the process to demonstrate support by executive leadership.
All the ingredients needed for success, according to BPR theory, were in place. The challenge was translating theory into reality.
Choosing the right team
Choosing the implementation team members, who became known as the PIT Crew (Project Implementation Team), was the project�s first visible beginning. The project manager and the president chose the team with input from college leadership. The selection was based on a combination of functional position and individual personality. When assessing possible members, we referred to Rogers� Diffusion of Innovations.1 Rogers offers the concept of �time of adoption of innovations� which categorizes the population, identifying only 2.5 percent of the population as innovators, 13.5 as early adopters, 34 percent as early majority, 34 percent late majority, and 16 percent laggards. Applying this to the team members, we would assume that 16 percent of the WITCC population fall within the categories of innovators and early adopters while 50 percent fall into the late majority or laggards. Keeping in mind the philosophies of business process reengineering, it was necessary to include as many innovators and early majority members on the implementation team as possible. In combination with identifying team members by innovation, there was the operational function of positions: Who had responsibility for the college�s administrative functions?
Essential people to have on the team were those knowledgeable from the areas of recruitment/admissions, registration, financial aid, accounts receivable, academic records, and curriculum. Other college operational functions were distributed between an academic dean, a records clerk, a registration supervisor, a transfer evaluations/degree audit coordinator, and a room scheduler, thus creating a need for additional team members to bring the appropriate expertise. As the operational college leadership was evaluated by innovation, key administrators fell into the category of late majority; therefore, additional members were added based on their perceived ability to accept and effect change.
In total, 12 members were included on the PIT Crew, categorized by functionality of the college and the software: recruitment/admissions, academic records, registration, accounts receivable/cash receipts, curriculum management, academic records, communications management, financial aid, degree audit, core demographics, faculty information, and technical team. Each of these 12 members took the leadership of at least one module and added members to their team from across the campus who would bring knowledge and perspective to the topic.
Choosing the right tools
Because the president set the project as a priority for the college, it was important to keep everyone informed. A variety of communication tools were necessary.
Development of the approach document was the first assignment for the PIT Crew. The purpose of this communication tool was to provide a history of the college�s MIS implementation, the strategic importance to the college of accessible and accurate data, the project�s organizational structure, the project goals, the roles and responsibilities of all organizational layers, the project obstacles, and the project budget. This writing activity was an important first step for the project because it provided a common foundation for the team members. This document was published and distributed collegewide and resides on the project�s Web site.2
Another communication tool was the quarterly newsletter, the purpose of which was to keep the campus informed of the project�s progress. A monthly timeline was also developed for activities and outcomes expected for each month. In addition to the approach document, newsletters, and timeline, the project�s Web site included the names of team leaders and members.
One of the administrative meeting rooms was named the �war room.� A computer was installed for testing, and the teams held most meetings in that room. This allowed the team to paper the walls with timelines, process maps, and issues lists.
For the team members� communication with one another, a project shared folder was created in the college�s integrated e-mail, voice mail, and fax system. In this folder we kept meeting minutes and documentation and posted questions. Since this was a shared folder for all PIT Crew members, anyone could read another�s minutes and stay informed about the entire project�s progress.
Another tool, Microsoft Project, was used to schedule and track the data conversion process for the technical team. There were over 60 conversion processes that had to take place during the five days of �down time� scheduled for the data conversion. It was critical that the data conversions be completed in the time allotted to allow the college to resume business on schedule.
Data conversion was scheduled to be completed five times prior to the live date. The time it took to run each of the 60 conversion processes was documented, assessing the ability to complete conversion in five days.
The steering team played an important role by developing a �critical issues� list. This list was the culmination of the many expectations for the project. The general expectation of �make reporting easier� was restated as �implement a reporting tool and train end users.� Specific tasks were assigned to each team, thus providing a measurement tool for success and completeness. Plan, organize, and communicate, communicate, communicate were tasks that would prove to be critical for the implementation.
Project phases
Rogers believes that consumers go through five stages in the process of adopting a new technology. The stages of adoption are awareness, interest, evaluation, trial, and adoption. Combining the stages of acceptance with the methodologies of BPR, the project was divided into four phases. The first and second phases were given four months each, allowing time for awareness, interest, and evaluation. The third and fourth phases were given three months for trial and adoption.
Getting ready
The first phase, called �getting ready,� focused on preparation. This included purchasing new hardware to accommodate the new software, installing an education account, completing the selection of the sub-team members, beginning process identification and mapping, writing the approach document, and completing conversion training. Phase I also included refining the critical issues list into a working guideline for the implementation team.
Getting started
During Phase II, �getting started,� the primary goals were to analyze process maps, develop test scenarios, build code tables, and complete the first data conversion. The teams were trained to identify processes and complete process maps. Forms were developed for each team to identify their processes. This included placing the processes� tasks and the people involved in the processes on post-it notes. The people were placed on the left side of the grid and the tasks were across the top of the grid. Visually following a process from beginning to end, observing how processes take place, the points where hand-offs and bottlenecks occur became apparent during this exercise. This visual interactive team activity caused those involved to identify cumbersome and inefficient processes, identify bottlenecks, and make recommendations for change. Most teams completed process maps on 40 to 70 percent of their processes, but three teams evaded this activity, protecting their �sacred cows.� Process mapping was a difficult concept for the late majority and laggards among the participants to accept because exposing their processes to others was very threatening and change was very uncomfortable. It is important to remember that, according to Rogers, 50 percent of the population avoids change and 16 percent of that change-aversive population will sabotage any effort toward change to retain their comfort level.
Those who completed process maps were the most advanced in their ability to improve or reengineer processes. One challenge was to convince late adopters and laggards that their processes could be accomplished better or more efficiently. It also became apparent that those who had been at the college the longest were convinced that their processes were the best they could be. A challenge at the other extreme involved those who were new to their position and were not familiar with the processes in their departments. Either scenario provided a learning experience.
Getting crazy
Phase III, �getting crazy,� was the most challenging phase. During this phase, specific term activities were identified and simulated from start to finish in a compressed time frame. For example, on a Wednesday we admitted ten students, built their academic programs, built the college calendar, registered the admitted students, billed their account, gave them financial aid, and sent an award letter. On Thursday we dropped and added five students into various courses, changed their academic program, gave them a refund, and completely withdrew two students. By Friday we graduated the students and sent a transcript. This concept of a �test term� was carried out three times with each term becoming more complex.
Test terms not only were important for testing but they created a common deadline for the individual teams to learn the software, make decisions, build codes, and identify processes in a systematic and integrated fashion. Because it was easy for individual teams to become focused on their module, the purpose of a test term was to bring individual teams together to replicate the reality of an integrated system. All team members participated in the test term so they all would be able to see how the pieces fit together.
Reality check
In the middle of Phase III, the executive vice president, director of IT, and the project manager distributed a survey to the PIT Crew members to assess their progress and determine if there were any adjustments necessary. As expected, the team members responded that they were feeling stressed, overworked, underdirected, and looking for someone or something to blame. Also as expected, the issues brought forward focused on lack of personnel, lack of time, and lack of direction. Three strong leaders believed that we would not make the live date while seven believed we would. The survey also indicated that the team would like more technical support from the IT staff.
The college leadership responded by adding a half-time IT position to support the project. Fortunately, someone with a great deal of Datatel experience was willing to work as needed throughout the implementation. Another change was to make the regular meeting time a work time, and deal with discussion issues electronically. We moved to having discussion meetings on an as-needed basis. The regular work meeting was held in a computer lab and was devoted solely to software issues.
The most difficult problem that needed to be addressed was people who believed they were overworked and overstressed. If left unattended, a self-fulfilling prophecy would prevail and perception would become reality. Determining if �not enough time� was perception or reality was a great dilemma as we reevaluated our live date. In addition, from the lack-of-time perception arose the attitude from the PIT Crew that they would simply survive the implementation and then �make this work like before.� The concern was that efforts to reengineer were being compromised. We decided to hire a consultant to objectively evaluate the situation and provide guidance to move the PIT Crew in a positive direction toward meeting the project goals.
The consultant made personal appointments with each team member and attended PIT Crew meetings to observe group dynamics. The primary goal was to determine if we should move forward towards the targeted conversion date or postpone conversion. The consultant�s intervention proved to be very beneficial; her presence alone made a strong statement on the project�s importance and that the leadership was going to receive an unbiased project analysis.
The consultant believed that the team members were much more prepared than even they believed they were, but that because of the desperate attempts of a few members (the laggards) to derail the project the PIT Crew was a dysfunctional team. The recommendation was to remain on target for the conversion date, add one additional technical resource to the IT department for technical support, and have the consultant continue to act as facilitator for team-building activities. The consultant�s intervention proved to put the project back on track.
Getting live
Phase IV, �getting live,� was the final preparation to go live. During this phase, the schedule called for running the last data conversions, writing procedural manuals, and training staff. During this time team members and staff worked hard to complete training and documentation, all the while dealing with the fear, frustration, and occasional panic attack of the few who continued to believe the �sky was falling.�
In early March of 1998 the old computer software system was taken offline and the IT staff began to complete the technical conversions of the software and data. The IT staff rotated 12-hour shifts, 24 hours a day, for five days. Final conversions were completed on schedule and within budget. The college opened for regular business on a Monday morning. A vendor consultant was on site for the first few days of �live.� This served mainly to calm nerves that any major issues were going to be addressed promptly by Datatel.
March represented a midterm conversion, so the administrative functions of the college were at a low point in the cycle. All registration activity had occurred on the old software and the grading process was completed on the new software. While the timing was beneficial from a workload view, we experienced some data conversion issues that might not have occurred if we had converted during a term break.
Post-conversion
The PIT Crew met three additional times after conversion and then disbanded. Training and technical issues continued to be resolved on an office-by-office basis, and six months after conversion some functional issues were still being worked through. Although no radical business process reengineering was noticeable, several offices contacted MIS and asked to resurrect reengineering ideas that were the result of the BPR endeavor. The add-on functionality of a report writer, online grading, early alert and referral, assessment testing scores, and Web interfaces are currently active topics.
Lessons learned
We believe it will take two to four years after the conversion date to fully appreciate the results of this project. We can, however, share some lessons learned to date and what we would do differently if we had it to do over.
You can�t turn laggards into innovators. Business process reengineering is a threatening proposition even for the most secure leadership, and there is no point in asking late majority and laggards to become creative, innovative risk takers. Resistance to change is a powerful force. Expecting change from those who are resistant is futile, even with supportive top-down leadership.
Function-based team selection doesn�t always work. The model can work if you have adequate staff from which to select team leadership, but our institution�s size limited the number of personalities available to choose from. During the early phases of the project, it became apparent that we had not achieved the balance we had hoped for: there were no innovators, four early adopters, four late majority, and four laggards. When the leadership is dictated solely by functional position, and there are no possible replacements, the results are problematic. If we had to do it over, we would spend more time picking the right personalities for the implementation, selecting them regardless of their positions. We would solicit the help of �laggard� functional personnel with regard to operation and policy, but leave the reengineering to those who find it as natural as breathing. You have only 16 percent to 32 percent of your resources to choose from. Choose them wisely!
Training in BPR and teamwork are as important as technology training. We extended what our vendor recommended to be a one-year project to 18 months to facilitate time for investigation and process reengineering. We planned that the change of software would become the catalyst for BPR. The reality is that we used the additional six months for formation, team selection, writing the approach document, and software basic training. We recommend six months of intensive training on the fundamentals and theories of business process reengineering, team building, and team training before any project-specific work begins. If possible, do not tie BPR directly to a technology change. When the timeline was short and the conversion was near, BPR efforts were diminished as a priority and the software conversion became the single focus.
Release time must be given to those who are assigned leadership roles. Making the project a priority but not realigning workload is a conflicting directive. Team leaders constantly struggled with balancing their already full schedules and finding the additional time to devote to the project. The difficulty for the steering team is defining �too busy.� The phrase is used for many reasons, and the perception of �too busy� is different for everyone.
Responsibility needs to be shared by the team. Putting a single person �in charge� was a mistake. The core team concept might have worked better if we had invested in the team�s training early, as the entire team could have been held accountable for the results. Because the single point of responsibility lay with the project manager, the rest of the team had someone to blame when the going got tough.
Executive support is critical. Tackling the combination of a major software conversion infused with business process reengineering is no light task. We were able to be successful because of the strong leadership and support from senior administration. In the face of great political pressure from inside the institution, the college president and executive vice president maintained their faith and trust in the IT team and the PIT Crew throughout the project.
Conclusion
The software implementation was a success. The measurement of that success will be compared to each individual�s expectation. The reengineering of business processes may not have been as widespread as we had hoped, but the exercise of taking a critical look at processes has had lasting effects beyond the live conversion date. Each time you challenge an organization to take a critical look at itself, to confront old beliefs, to question practices and policies, it becomes stronger. This project has done that for WITCC. The college will be a stronger institution for having gone through the experience and will continue to move in a positive, forward-thinking direction.
Technology driving change or people driving change will not be the dilemma but will be the partnership of the 21st century.
Endnotes
1 Everett M. Rogers, Diffusion of Innovations (New York: The Free Press, 1983), 247.
2 See http://www.witcc.com/general/datatel.html.
Gayle E. Jaacks ([email protected]) is director of Management Information Systems and Michael Kurtz ([email protected]) is executive director of Information Technologies at Western Iowa Tech Community College.