&
In the spring of 1991, a group of faculty and administrators of George Mason University formed a working group to investigate the university processes that were producing the most complaints, and to recommend changes in the design of those processes and the information technology supporting them. The first author of this chapter (Denning) was a member of that group. The group found that the notations discussed above were very powerful and enabled them to see exactly where organizational processes were incomplete or needlessly complex and thus to recommend specific actions to relieve the problems. The study also enabled the group to see what kinds of technology would be useful to support a proposed new process.
Curriculum management is the single largest process in any university. At George Mason University, it affects 21,000 students, 650 faculty, and many administrators daily. It encompasses advising, career counseling, plans of study, curriculum planning, and course scheduling. Breakdowns anywhere in this network of subprocesses produce unmet expectations, leading to dissatisfied clients (students) and performers (faculty). Because it is a long-term process, breakdowns can significantly delay students' graduations. As it is in many universities, this process is the subject of endless complaints from all participants. We chose it as the subject of our investigation.
The first step was to construct the map of the workflows as they are actually performed. The investigation was conducted by interviewing people from the student records (registrar's) office and from each of the schools. In each case we sought to identify who makes what kinds of requests of whom, how those requests are conveyed, how the participants reach agreements, what steps are done to carry out typical agreements, of whom the performer makes subsidiary requests, how the final results are conveyed, and how the loop is closed or not closed. As an interview proceeded, we sketched the loops and showed the unfolding map to those we were interviewing. As they began to see their own process unfold before their eyes, they were able to validate the map or tell us how to alter it. The ActionWorkflow Analyst tool can significantly accelerate the map-making process (Action 93).
The second step, conducted as part of the same interview, was to ask the participants to describe what breakdowns they were routinely encountering in their own processes and in the interactions with others on whom they depended. We asked them about their principal concerns. We also asked them to discuss what the most important constraints were that they felt they had to live with, both in terms of rules and of values. From these questions we were able to deduce which breakdowns were the most irritating, what was their cultural common sense they had, and what changes would be most valued.
The third step was undertaken only after the entire map was completed. We sought a new process that would produce the same overall result with significantly less complexity, notably the elimination of wasteful loops created to resolve breakdowns in the basic process. We asked what would have to change, both in terms of social agreements and technology, in order that people would accept the new process and begin practicing it.
In summary, the steps of the investigation were:
As a helpful guide in the redesign stages (e), we asked, "Who is already doing it in a way that produces the results we want?" We can then learn from that group.
The major complaints about the curriculum management process were:
To discover the loops of the work process, a subset of the working group met individually with the persons responsible for course scheduling in the Schools of Education (SED), Business Administration (SBA), Information Technology and Engineering (SITE), Nursing (SN), and in the Student Records (SR) office. The workflow maps constructed during these interviews are shown in the accompanying charts.
The first of these charts shows the main loop in the SR (Registrar's) office (Figure 1). Beginning 11 months prior to the start of the semester being scheduled, this office sends a request to all departments to draft an initial schedule. Two more drafts are sent to the departments for further comment and refinement. Between each of these "rounds", SR office personnel must work with individual departments to resolve conflicts -- for example, when the demand for MWF 10am classes exceeds available rooms. The "final" schedule is published in the preceding semester in time for students to register. Information flows between workflows and databases are shown as gray arrows.
The remaining charts show what happens inside the schools when these requests arrive. Figure 2 is typical; it shows the process within the school of business, which is similar to those within engineering and education. The seeds of the complexity can be seen in the early, incomplete loop where department chairs ask faculty to state their preferences for courses to teach and times to hold classes -- it is not clear that all faculty have agreed to state their preferences or that the department chairs are satisfied with their responses. The complexity reaches full bloom later, when the final published schedule is issued. Many faculty experience reactions from annoyance to outrage on seeing what is published there; they immediately enter into negotiations with the nearest "person of authority" (chair, dean, provost) to have the schedule corrected to reflect their preferences and needs, and they often do this without consulting with the person officially responsible for the schedule. In contrast, SN shows the least complexity (Figure 3); their highly structured program has limited options.
What is striking about the course-scheduling process is its complexity. It takes many pages of maps to display all the loops that sprawl over many units of the university. Many of the loops seem to provide only incremental improvements over the previous iterations. There are many special loops in which complaints are resolved. Given the lengthy cycle time of the process (eleven months) it is little surprise that there are so many last-minute changes.
In discussing with stakeholders why this process has evolved into its present form, we discovered these assumptions that are part of the unspoken background tacitly agreed to by everyone:
These assumptions constitute the terms of a "social contract" that keeps the current course-scheduling process in place. They are the starting point for re-engineering.
The most important assumptions are the first and the second. These assumptions appear to arise from the traditional assumption that faculty are responsible for determining the curriculum and know best what a good education for the students is. What new assumptions would lead to a simplification this process, possibly all the way to its theoretical minimum of a single loop? What changes of the habits would be needed to bring about these assumptions? How might the "social contract" be renegotiated to accomplish this? How might the conditions of satisfaction of students and faculty be made explicit?
To arrive at a simpler process, the group stated the result sought: design of a schedule that accommodates most student demand (operationally, 95% of students get a schedule that includes the courses they need each semester), requires minimal faculty effort to formulate (operationally, one round), and requires few last-minute changes (operationally, less than 1%). We asked who is already achieving these results. The School of Nursing (SN) is already doing this. Their process (Figure 3) is a blueprint for a process that can be extended for use by everyone in the university.
The SN approach is based on a distinction between two distinct responsibilities of the faculty: 1) to determine the curriculum, and 2) to cooperate with the students in delivering the curriculum effectively. The SN's success derives from the way they approach the second responsibility: the process of delivery is driven by student demand for courses to fulfill degree requirements.
The last chart (Figure 4) shows a possible revised process that incorporates the assumptions of the SN process. The entire process map has 50% less loops than the current map. This simplicity is achieved by transforming the basic assumptions to these:
The lead time to publish a schedule based in these assumptions would be much shorter than the current 11 months. The schedule could be published late in the semester prior to the one in which the courses are taught. The SN process is already built on these two assumptions.
A key enabling technology here is one that supports the formulation and storage of student plans of study. This would require computer systems in each department that would allow students to fill in template plans and confer with their advisors before filing or modifying them. It would require a distributed database system that could construct a unified view of all the department and school databases to estimate demand for each course and would allow each department to determine the demand for its courses. The presence of such technology would not suffice to produce greater satisfaction with curriculum management: the entire process must be redesigned.
We have shown, with examples of work processes of the university, how it is possible to observe and map large processes in a way that creates the possibility of redesign, not only for greater efficiency and lower waste, but more importantly for greater satisfaction of everyone involved in or with the processes. With these maps it is possible to connect negative organizational moods such as poor morale, distrust, resentment, waste, excessive cycle time, and low public satisfaction with breakdowns in workflow loops or with excessive complexity of the process. The Young & Rubicon study demonstrates clearly that redesigned processes in which the loops are regularly completed produce significant, measurable improvements in employee satisfaction (Marshak 93).
We have also shown that the existing process, no matter how dysfunctional or unsatisfactory, is held in place by its participants' habits, by organizational "culture", and everyone's shared sense of what is "right". Redesigning those processes is not simply a matter of drawing new maps and introducing new technology. It is also a matter of reorganizing people's practices and self-interest -- shifting their conditions of satisfaction. For this reason, we speculate that extraordinarily complex processes involving many departments and many people will be difficult to modify without providing technology that allows the participants to see significant personal gains in productivity within the new process.
With such technologies, it will be possible to manage organizational processes to systematically produce client satisfaction, to reduce cycle time, to increase productivity, and to quickly redesign the process to meet new conditions of satisfaction.
Back to the Workflow Module Map
MRH
9/27/94
