A Community College's Focus on BPR: Doing More with Less

This paper is the intellectual property of the author(s). It was presented at CAUSE98, an EDUCAUSE conference, and is part of that conference's online proceedings. See http://www.educause.edu/copyright.html for additional copyright information.

"A Community Collegeï¿½s Focus on BPR: Doing More with Less"

Gayle Jaacks and Michael Kurtz
Western Iowa Tech Community College
Sioux City, Iowa

It is often anticipated that the software will make life easier. The reality is that "paving over the cow path" with new technologies seldom causes significant improvements in productivity. Institutions must streamline processes, eliminate duplication of efforts, and examine outdated or inefficient processes. This presentation will give an overview of the project timeline, organizational structure, and tools used to guide Western Iowa Tech Community College through reengineering efforts, including the "doï¿½s and donï¿½ts" of BPR as they relate to a mid-sized community college.

Introduction

In 1992, Western Iowa Tech Community College moved from a semi-home-grown MIS system called the "Kirkwood System" to a third-party package, Datatelï¿½s Colleague. Over the past six years, Western Iowa Tech Community College (WITCC) has committed extensive personnel and financial resources to the computerization of records. Western Iowa Tech fully implemented the Datatel system and integrated it into the business operations of the college. The system is used in 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 Datatel system is the heart of the collegeï¿½s data-collecting, storing, processing and retrieving activities. The college continues its commitment to the computerized, integrated record keeping system by implementing each system upgrade, therefore moving to the most current version of Datatelï¿½s new Student System.

In the spring of 1997, WITCC found itself again faced with a strategic opportunity for change. The "new student system" release provided by Datatel 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, WITCC 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, the college could have made minor improvements to its business processes in order to take some advantage of the new softwareï¿½s functionality. The third option was to take a full critical review of the collegeï¿½s business processes and reengineer them. These options were presented to the college executive leadership with a recommendation to take advantage of the situation and reengineer the business processes of the college.

Early in this process, the President of the college adopted the concept of reengineering the college. This early acceptance by the senior administrator was going to 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 that really meant and how this project would affect their lives and the college for years.

The Model

One of the problems facing the organization was overcoming the perceived shortcomings of the last large-scale software implementation. Although the college had successfully implemented smaller releases of the software, the last major MIS software implementation was the conversion from the "Kirkwood System" to Datatel. During that implementation, two MIS professionals were responsible for the success of the implementation. The IT Department took high ownership in the project and although the implementation was a success, it was dubbed the "IT Departmentï¿½s" system. IT was blamed for any flaw in the implementation and viewed as the only resource to make decisions about the MIS system. This lack of ownership within the college as a whole could be viewed as the biggest problem resulting from the original implementation. The college was determined to solve that problem.

The model that was designed and later adopted for this 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 model 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 and work with every one of the implementation teams. This would provide an entire perspective for each of the functional areas. The idea was that Accounts Receivable might have some good insight on the Admissions process or the Degree Audit people might have an idea for Registration. This part of the model was similar to the original implementation. Originally, the college had implementation teams that consisted only of those people directly associated with the function: admissions staff were on the admissions group and A/R staff were on the A/R group. This cross-functional concept was designed to produce a better-rounded result.

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 high criticism, of the original implementation was a scarcity of testing. The testing teams would be responsible for testing the decisions made by implementation teams.

Finally, the last part of the model called for user teams. These would consist of the end-users of the software. These user teams would be trained to use the software.

This model was presented to the administration and a modified version was approved for the implementation. The college saw this project tying directly with the upcoming NCA self study and visit 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 was not going to be fully trained in all aspects of the project. This group consisted of the senior college leadership excluding the President and including the Director of IT. It would also come to 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 responsibility. In the original implementation, it was clearly the responsibility of the two IT professionals that were hired specifically for the task. This was 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 was in the position of ï¿½Systems Analyst/Programmerï¿½ and was mainly responsible for the business office 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 systems analyst/project manager, and 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 their current duties between 50% and 100% 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 them up to speed. If the person had too much experience with the system, it would be difficult to shed their prejudices and accomplish a true reengineering project.

The Director of IT was eliminated from the choices of project leaders because of the political baggage that came 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 others with the skills were too busy with other projects to free up 100% of their time for 18 to 24 months. There was an option available within the Data Analyst/Project Manager position because she had studied the theories of Business Process Reengineering and consulted with the President on the philosophies of BPR. 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 this would not have moved the project out the hands of IT and into the hands of the end users. The solution was to move her out of IT. She would lead the project and report directly to the Executive Vice President. According to BPR best practices, the effort must be a top-down model, supported by the executive leadership, clearly communicated to the organization, and not led by technology.

The President and executive council openly supported the project through meetings with the team members in the early phases of the process. The plan included physically moving that office to another area, thus divorcing the project from Information Technologies.

The implementation was to focus on a cross-functional model. The challenge was taking theory to reality. The President, having been a part of the planning phase, continued to be instrumental in the project. According to BPR theory, successful business process reengineering must be "top-down" to be successful, and the President was outwardly in favor of using this software implementation to reengineer the college's business practices.

Choosing the Right Team

Choosing the implementation team members, who became known as the PIT Crew (Project Implementation Team), was the project's first visual 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. Rogers offers the concept of Time of Adoption of Innovations which categorizes population, identifying only 2.5% of the population as innovators, 13.5 as early adopters, 34% as early majority, 34% late majority and 16% laggards. Applying this to the team members, we would assume that 16% of the WITCC population fall within the categories of innovators and early adopters, while 50% 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 innovators, there was the operational function of positions: Who has the 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, key administrators fell into the category of late majority; therefore, additional members were added focusing on their perceived ability to accept and effect change. In total, 12 members were included on the project implementation team.

The members were divided by functionality of the college and the software. The twelve teams were 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 member took the leadership of at least one module and added members to their team from across the campus that 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.

The first tool developed, the Approach Document, was the first assignment for the PIT Crew. The purpose of the Approach Document 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 college-wide and resides on the project's web site (www.witcc.com/general/datatel, Approach Document).

Another communication tool was the quarterly newsletter. The purpose of the newsletter was to keep the campus informed of the project's progress. (www.witcc.com/general/datatel/, Newsletter). Also, a monthly timeline was developed (www.witcc.com/general/datatel, Timeline), with activities and outcomes for each month. In addition to the Approach Document, timeline and newsletters, the project's web site includes 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 and held most meetings in that room. This allowed the team to paper the walls with timelines, process maps and issues lists.

For the team's communication with one another, a Datatel shared folder in the college's GroupWise system (an integrated e-mail, voice mail and fax system) was created. In this folder we kept meeting minutes, posted questions and kept documentation. 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 was the use of Microsoft Project. This was used to schedule and track the data conversion process for the Technical Team. There were over 60 conversion processes 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 (www.witcc.com/general/datatel). This list was the culmination of the many expectations that the project would provide for the college. 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 are tools 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 stages 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 (www.wticc.com/general/datatel, Phases).

The first phase was entitled "Get Ready," and 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.

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 includes placing the processes' tasks and the people involved in the processes on post-it notes. The people are placed on the left side of the grid and the tasks are on the top of the grid. Visually following a process from beginning to end and observing how processes take place, where hand-offs occur and where possible bottlenecks occur become apparent. This visual interactive team activity caused those involved to identifying cumbersome and inefficient processes, identify bottlenecks and make recommendations for change. Most teams completed process maps on 40% to 70% of their processes. Three teams evaded this activity, protecting their "sacred cows." It is now apparent that they will not do any process improvement, let alone BPR. Process mapping was a difficult concept to have the late majority and laggards accept, not only because of their nature not to accept new things, but because this is very threatening for those who believe that exposing their processes to others could call for change. It is also important to remember that fifty percent of the population avoids change, and of those, 16% will sabotage any effort toward change to retain their comfort level.

Those who completed process maps were the most advanced in their ability to process improve or process reengineer. One challenge was to have late adopters and laggards believe 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. 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.

Phase III, "Getting Crazy," became the most challenging phase. Test terms were an activity where specific term events were identified and simulated from start to finish in a compressed time frame. For example, on a Wednesday we admitted 10 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 planned for three times with each term becoming more complex.

Test terms were not only important for testing, but 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 integrate individual teams together replicating the reality of an integrated system. All team members participated in the test term; therefore, they could all be able to see how the pieces fit together.

Reality Check

In the middle of Phase III, the Executive Vice President, Executive Director of Information Technologies 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, under-directed, 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 Wednesday meeting was held in a computer lab and was devoted solely to software issues.

The most difficult problem to fix 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 re-evaluated our live date. In addition, from the lack of time perception, the attitude arose from the PIT Crew that they would simply survive the implementation and "make this work like before." The executive leadership’s concern was that efforts to reengineer were compromised. At the time of this writing, we have hired a consultant to objectively evaluate the situation and provide guidelines to move the PIT Crew in a positive direction toward meeting the project goals.

The final phase (Phase IV), "Get Live," is preparation to go live. During Phase IV, the schedule calls for the final data conversions to be run, procedural manuals written, and end users trained. At this writing, we have not entered Phase IV.

What Worked and What Didn't

During the early phases of the project it became apparent that more of the PIT Crew were late adopters than expected. In our estimation, when evaluating twelve members, the breakdown consisted of no innovators, four early adopters, four late majority, and four laggards.

In two situations, there was proof that the model could work if you had adequate staff from which to select the leadership. Two people were technically illiterate and unfamiliar with the area that they agreed to lead; however, they are early adopters and are considered successful leading their module. They completed the process mapping and have ownership in three BPR efforts that came from the project.

When the leadership is dictated solely by position and there are no possible replacements, it is very difficult to ask the late majority and laggards to become creative, innovative risk-takers based on the fact that they were chosen for a model. Resistance to change is a powerful tool. BPR is a threatening proposition even for the most secure leadership. Expecting change from those who are resistant becomes an impossible task, even with supportive top-down leadership.

We extended what Datatel recommended to be a one-year project to eighteen months to facilitate time for investigation and process reengineering. The reality is that we used the additional six months for formation, team selection, writing the Approach Document, and some basic training. If we were repeating this, I would recommend six months of intensive training on the fundamentals and theories of Business Process Reengineering, team building, and team training.

In addition, release time must be given to those who are assigned leadership roles in the project. 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.

Conclusions

At the time of this writing, a full evaluation of this business process reengineering project cannot be accomplished. It will take 2-4 years after the implementation is considered complete to fully appreciate the results from this project. We can, however, draw some preliminary conclusions, as well as point out many of the things that we would have changed.

Perhaps the strongest conclusions can come from the size of the organization and the scope of the project. Both of us would agree that if we had to do it over, we would spend more time picking the right personalities for the implementation. The institution’s size limits the number of personalities available to choose from, and therefore had a dramatic effect on the project.

Making a single person responsible was a mistake. The Core Team concept may have worked better if the entire team would have been held accountable for the results. As a result of the single point of failure, the rest of the team had someone to blame when the going got tough.

The most useful thing we learned is that you can't make people become creative innovators. You must select them for your implementation team regardless of their positions. Even when your President insists they become an innovator, if they are not, leave them to the operational functions of the college and solicit their help regarding operation and policy, and leave the reengineering up to those who find it as natural as breathing. You only have between 16% and 32% of your resources to choose from. Choose them wisely.

As the authors of this paper we offer some predictions. The software implementation will be a success. The measurement of that success will be compared to each individual’s expectation. The BPR project may not be appear to be as wide spread as we had hoped, but the exercise of taking a critical look at processes will linger beyond the live date. Each time you challenge an organization to take a critical look at themselves, to confront old beliefs, to question practices and policies they become 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 in the 22^nd century.