Skip navigation
College Quarterly
Summer 1995 - Volume 2 Number 4
Re-engineering: A Support Staff Perspective
by Margaret R. Wale
Re-engineering: The Official Definition
The fundamental rethinking and radical redesign of business processes to bring about dramatic improvement in performance. Hammer and Stanton (1995), p.3.

Mohawk College of Applied Arts & Technology, just like every other community college in the Province of Ontario, is facing reduced funding at both the federal and provincial level and relentless budget challenges along with increased demand for higher enrollment. All of this is being done amid pressure from all sides for increased access, credit for prior learning, the social contract, etc., etc. It was recognized by Mohawk that with all of the internal and external strains and tensions, the only way to stay competitive was to change fundamentally the way we were doing business. As a result, the corporation decided to enter into the Re-engineering Process.

The Process at Mohawk College

The staff of the College had been hearing rumours about “Re-engineering” for quite some time and nobody really knew what this meant. We knew that there had been a project ongoing for some time called the Information Resource Management Team. We knew that this was a Corporate Information System and that it was somehow linked into Re-engineering, but nobody was clear on what this all signified. We were then informed that the Director of Human Resources would be visiting all campuses to explain Re-engineering, why Mohawk was going to do it, who would be involved, and we were all ...INVITED!

At these information sessions we learned that one of the major components of our Re-engineering would be the Integrated Corporate Data Base System which was called SWiSS. This acronym stands for Single Window information Student System and would enable users to do a vast array of things which were previously done on several different stand-alone data bases which did not speak to each other, or things which were done manually. This system had been in the design phase for quite some time. We also learned that there would be three Pilot Teams which would consist of employees from all of the constituent groups (Administration, Faculty and Support Staff) and we were asked to submit our names if we were interested in being part of a team. We were also told quite clearly that Re-engineering was not about downsizing, rightsizing or any of the other “sizing” words, and that this process would not lead to job loss.

There was a great deal of trepidation and anxiety across the College with the usual dose of scepticism. But, there was also a seed of optimism from those who felt that we had to change the way in which we were doing business. This just might be the opportunity some had been looking for to be on the front line of change, to work outside the traditional boundaries, and perhaps even to have an impact on the organization. One of the most attractive aspects of this project to many staff was the fact that it had been made very clear to us that this was a corporate initiative and had come from the President of the College. This is one of the most important tenets of Reeningeering and it certainly was a strong factor for the staff at Mohawk College to enable us to “buy-in” to the concept. The general feeling was that if the President was mandating this project, it would definitely get off the ground.

In August of 1993, the composition of the three teams was announced and, true to the stated concept, the teams certainly were a cross-constituent mix. The team to which I was assigned was the Brantford team. Brantford Campus is the second largest campus of Mohawk College, and also the campus at which I work. This team consisted of an Academic Chair, a Campus Manager, support staff, and faculty. The Director of Human Resources had, by this time, been seconded full-time to the Re-engineering effort and would be heading up all of the teams along with an outside consultant who would also attend all team meetings. Each team member got a letter from the President of the College expressing congratulations and thanks and outlining what was expected of us. It included a clear-cut mandate as well as reporting structures. If we didn't know before, those of us on the teams were certainly aware from this point on that we had committed ourselves to something extraordinary and with full backing of the corporation.

The teams began to meet separately and commenced what we lovingly referred to as “Boot Camp”. This initial phase consisted of getting used to each other, discovering what was expected of us and finding out exactly what this “thing” called Re-engineering really was. Operational issues were discussed such as the fact that we would meet regularly for a full day, once per week and that there would be other assignments as necessary. There was discussion around what this would mean in terms of our regular jobs. For faculty members it meant that they would have to be freed up from the classroom for at least that one day. There was an attempt made to replace some support staff team members on their job where it was feasible.

As a team we had to discard all of our old notions about how things worked within the organization; we had to learn to “think outside the box” which became our mantra. We also had to realize that this was not a committee as we were used to thinking about groups within the college. This group would not be operating in the traditional sense at all. It was actually quite a heady feeling for support staff on the teams to realize that these teams would be working in the true collective sense with no hierarchy. The downside of this was that we also quickly realized that there would be no coffee and muffins in the morning, and no lunches supplied. This was our first introduction to the fact that everything we were about to do was on a “zero million dollar budget”! That was to be our biggest challenge (not the coffee and muffins) but the fact that we knew up front that there was no money for major change and that all of our ideas had to be innovative and “do-able” with the existing dollars available. A daunting task!

Another thing we learned very quickly on the teams was that if you had a suggestion to make or an idea to explore, you had to be prepared to do the legwork as well. There was no one to designate to do your “homework” and there was a lot of homework to be done. We were also told at our inaugural meetings that communication would be a big issue on the teams. We would be going out and interviewing staff across the college to try to get background and information for various ideas we were working on and it was reiterated time and again that we would communicate, communicate, communicate. Without the communication we would only be building an atmosphere of distrust.

Within three months, very clear recommendations were coming out of all of the teams and these were accepted by the corporation. Once a recommendation had been accepted the teams then had to work on the process. It was realized that the original three teams were not necessarily the most appropriate in make-up to deal with the specific recommendations. There were two additional teams struck with some shuffling of the original members. Each team arrived at a different process which they wanted and felt best suited to tackle.

The Brantford team decided to tackle the issue of Client Service Representative and SWiSS. Our team was joined by a member from the Systems and Programming Department (S&P) who couldn't wait to get actual “users” to be the guinea pigs. The concept of a Client Service Representative (CSR) was an integral part of the original vision. A CSR (along with the Corporate Data Base and the SWiSS system) would enable the organization to provide many of the services in our view of the “Almost Perfect College” in a one-stop shopping mode. When we started to think about what could be done with this information system, we wanted it yesterday.

The team I was on dedicated itself to assisting in the development of the SWiSS system, working very closely with S&P and in fact, becoming the user experts of this particular system as it was being built. The SWiSS system is an object-oriented system and was being built in stages as S&P staff were available to do the programming. Our team was making decisions (in consultation with S&P) about what could be built next and examining the processes surrounding a specific object that were currently being used in order to adapt the system and reengineer the process. It was decided in May of 1994 that the team would begin to devote its efforts toward the CSR process (using SWiSS), with a view to implementing this change. We brainstormed all of the current processes used for the various activities which we envisioned a CSR doing and relooked at the entire concept of a CSR, fashioning it to reflect the vision of the team members, many of whom were intimately involved in many of those processes currently. We looked specifically at what would be involved, what tools would be needed to do this job, and a reasonable time frame for implementation. We developed three different scenarios: (1) the way in which processes were currently handled, and by whom; (2) an initial scenario which incorporated process changes we would recommend and utilization of the SWiSS system to perform those processes which had already been incorporated into the system; (3) a second proposed scenario which would see implementation of the full vision of a CSR with all of the SWiSS system built to accommodate these processes. The true one-stop shopping model.

When the team started to look at an individual process there was, as you might well imagine, suspicion and uneasiness when we began asking questions. Again, - remembering communicate, communicate, communicate, - we were very clear (in our minds) that we were being very open but this did not always allay fears. It became plain to us that everyone was fine with Re-engineering until we started to “touch” their stuff (understandable given today's climate of job insecurity). People realize that things need to be changed, but they want to change somebody else's job, not theirs. Again, this is understandable and we on the team were very aware of and sympathetic to this. Many times within the team setting we had to discuss our own jobs and whether there was any value to them, which was very difficult but not nearly as difficult as discussing the job of the person sitting next to us. If we had not been able to see the overall vision and hold tight to the premise that Re-engineering is not downsizing, we would not have been able to entertain the ideas which we put forward.

An immediate and especially interesting phenomenon was that, once we started to look at a process, there would be almost complete abdication of responsibility by the “corporate owner” of the process. Although an area had corporate responsibility for a process and received the revenue, once the team started to Reengineer the process there seemed to be an assumption that we were now the ones to run the process and set policy as well. This was the first time that our team was exposed to this phenomenon but we now see it in almost every process we reengineer; the difference is that we have learned to adjust to it and have developed strategies to counteract it. There seems to be a fine line between implementing a new system change (when you are not the stakeholder) and being seen as the owner of the process. Our main strategy is again the communication issue; we have to communicate continuously to the stakeholders that they are still corporately responsible for the process but we are “assisting them” with the changes.


After two years of being involved in the process of Re-engineering, I feel that one of the greatest advantages has been the clear illustration that a group of cross-constituent employees can work together to Reengineer a process, work out the bugs with the staff involved in the usage of the process, and be successful without a major upheaval to staff or students.

It appears that Re-engineering will continue to be the way in which Mohawk conducts business for some time to come. We have seen many Re-engineering teams spring up to look at a specific issue or process, do the work necessary with the appropriate players, and disband when their mandate is completed.

The one ingredient absolutely necessary to make Re-engineering work is the “Corporate Buy-In”. Support of the corporation for this process is essential to enable the teams to have the necessary authorization to carry out their “Vision”. If the support is not available at the top levels of management the Re-engineering process is destined to fail, no matter how capable the teams are.


Hammer, M., & Stanton, S. (1995). The Re-engineering Revolution: A Handbook. New York: Harper Business.

Margaret R. Wale is Liaison & Career Services Officer at Mohawk College in Brantford, Ontario.