Here are some of the questions being asked about MIT's reengineering project, with answers provided by Professor James D. Bruce, vice president for information systems, who is program manager.
At the "town meeting" held by President Vest in November there was talk of a $40 million cut in expenses over three or four years and a reduction of about 400 jobs during that period. Isn't that what reengineering is all about-cutting the budget and the number of jobs? Let's just do it and get back to work.
The major problem we face is that many of our business processes were designed years ago, have not been reexamined for some time and have become overly complex. Now the world is changing. MIT and many other universities are facing a very fundamental and relatively sudden set of changes affecting their long-standing relationship with the federal government. Federal funding of research is declining. In such an environment, budget cutting and downsizing by themselves would be only stop-gap measures. The end of the Cold War and the shift in federal priorities, coupled with changes in how the federal government supports universities, means that we must find some new ways to provide support services for our academic and research programs. We must find new, more efficient ways to do our work. If we were simply to cut positions, we would find ourselves trying to do everything we now do, except with fewer resources and fewer people. That is no solution for the long term.
Just about everybody named to the Core Team has extensive information systems experience. Is reengineering just a way to get more of our work computerized?
There is no doubt that information technology will play a major role in reengineering. It is advances in information systems that will make possible much of what MIT needs to do in reengineering. But information systems skills were not a requisite for selection as a Core Team member. These people were selected because of their broad knowledge of the Institute and its processes, as well as their reputations for thoughtful, creative work. Many of them have worked in multiple areas at MIT.
Shouldn't there be some human resources people on the Core Team? Isn't the Institute going to provide support for those whose jobs might disappear?
The Core Team assignment is to identify the Institute's processes and map their functions. Once two or three processes are selected for reengineering, individual design teams will be appointed to reengineer each process. Human resources considerations will be very high on the agenda at that stage, and will be reflected in the membership of the teams.
Why aren't there any relatively new employees on the Core Team? Isn't there some value in having fresh eyes looking at how the Institute does business?
Once specific processes are selected for reengineering, the redesign teams assigned to that task will include "fresh eyes." For example, some of these team members will have nothing to do with that particular process. Their "fresh" look at the process will blend with those who have been running that process for some time and the result, we hope, will be a new way of getting unnecessary work out of the process.
What is the reengineering timetable? When do we know which processes are slated for a reengineering makeover?
The first "product" of reengineering, this one coming from the Core Team, will be a "why-are-we-doing-this" statement. The reengineering experts call this the "case for action." This statement should be ready before the end of April. That will be followed in the middle of May by the selection of the first two or three processes for reengineering. We expect each redesign team to take about six months to develop a prototype of the reengineered process. Implementation of those redesigned processes will take place over the following 12 to 18 months. When implementation begins for the first wave of processes, redesign of a second group of processes will begin. Altogether, it will take three or four waves of redesign to cover the basic administrative processes that will be reengineered.
How can those of us in the selected processes be heard on what we think should happen?
An absolute necessity for the success of reengineering, is clear, unambiguous and credible communication, both from the administration and the reengineering team to the community, and communication channels the community can use to reach the Core Team. We have established a voice mail number, x2-1700, (this is correct, the first number is 2) and by e-mail at . The name of the sender is masked during transmission to the e-mail box to ensure privacy. Correspondents may include their name in the body of the message if they wish. Anonymous questions received by e-mail will be reviewed and many will be answered in MIT Tech Talk. There will also be a series of meetings of Core Team members and those working in the process areas to be reviewed.
MIT couldn't have reached the pinnacle it occupies by accident. We must be doing quite a few things right. If it ain't broke, why fix it?
Change can be necessary even when there is a record of success. The question is, "Can MIT continue to be successful in a changing world?" It isn't whether something is or isn't broken that counts. The rules are changing, some have already changed, and we need to do things in different ways. In particular, we must simplify our administrative processes to find and remove work that once may have been necessary, but is no longer integral to the service being provided.
Reengineering might be okay for industry, but how can you apply it to processes that support an educational enterprise?
Many MIT processes are quite similar in their operation to those in businesses. Purchasing, accounting and finance, plant maintenance are just some examples. Not all the functions of a university will lend themselves easily to reengineering, but we believe there are many areas that can benefit from such an approach.
Wasn't Total Quality Management supposed to help MIT do a better job? What's happened to TQM? Was it just a "management fad" and isn't reengineering one too?
TQM has been applied with success in a number of areas at the Institute to achieve incremental enhancements in departmental processes. It will continue to be used in that way at MIT during as well as after our reengineering efforts are completed. However, some of our major Institute-wide processes may be badly out of sync with today's needs, and thus incremental change will never do the job. In those cases, we need to design the process from the ground up, asking ourselves how we would tackle the job if we began doing it today for the first time.
What has reengineering done for companies that makes MIT think it is worth such an extensive commitment on the part of the Institute?
There have been a number of reengineering successes in a variety of companies that have close parallels to processes that MIT is involved in. For example, Syntex Corp., a major pharmaceutical manufacturer, was able to sharply reduce its multi-year development cycle for new drugs. Hallmark once needed nearly three years to bring new products to market. Now they do it in about eight months. MIT doesn't manufacture pharmaceuticals or greeting cards, but admissions applications, benefits management, purchasing, accounting and scheduling are just a few of the processes that share some of the same functions as are found in business.
What does CSC Index know about MIT? Assigning an MIT graduate from its staff to work with our people is a plus, but one person really can't communicate the uniqueness of MIT to a big consulting firm.
We chose CSC Index because of its experience in business and because many of our administrative processes mirror the processes in industry. As for experience with MIT, Index has many MIT graduates in its ranks, starting with James Champy, one of its founders, who served as executive vice president of the Association of MIT Alumni and Alumnae for several years, as well as Walter Popper and Karen Temkin. More to the point, the work of reengineering at MIT will be done by people who are currently in the ranks at MIT. Index is here to help us, not to do the work for us.
A version of this article appeared in the March 30, 1994 issue of MIT Tech Talk (Volume 38, Number 27).