Information Technology Excellence: It's Not Instant Pudding, Applying TQM to IT

|-------------------------------------|
|  Paper presented at CAUSE92         |
|  December 1-4, 1992, Dallas, Texas  |
|-------------------------------------|


INFORMATION TECHNOLOGY EXCELLENCE: IT'S NOT INSTANT PUDDING
Applying TQM to IT


Linda H. Fleit
EDUTECH International
Bloomfield, CT 06002


Total Quality Management, the Deming Method, the Parable of the Red 
Beads,.... Just new bandwagons and buzzwords or truly something worth-
while we can use to guide our information technology efforts? This paper 
presents an exploration of TQM as a new and intriguing way to pursue 
excellence and the ways in which TQM can be productively applied to 
higher education information technology.

Icy fingers grip your heart. You've just returned from lunch and sitting 
on top of your stack of messages is one from the president, saying she 
wants to see you right away. With lightning speed, the three or four 
reasons she might have called you race through your mind... She wants to 
congratulate you on your success in developing the new tuition billing 
system. She wants to talk about putting a workstation on her desk. She 
wants to talk about training her secretarial staff in WordPerfect.

Deep down inside, you know it's none of these things. By the time you 
get to her office, you've begun to hear whispered rumors in the 
hallways. The president's secretary greets you with sympathy in her 
eyes. You walk into the inner office, and there they sit: the president, 
the vice president for development, and one of the trustees. How could 
this have happened, the vice president for development says to you. How 
could the last set of special donor acknowledgments have gone out in the 
mail, over the president's signature, riddled with errors, including 
mistakes in the dollar amounts received and the spelling of some of the 
names. The donors have been calling, he says, confused and annoyed.

You try, of course, to put the best face on it with them, try to look 
like you knew all about this and that a fix was already in place, try 
very hard not to be defensive or to shift the blame onto the development 
staff for not checking the letters before they went out, and of course, 
try to assure the president that this can never, ever happen again.

By the time you leave her office, you are wondering not how it could 
have happened; there are many ways this problem could have happened, 
unfortunately. Rather, you are wondering, how could you have been 
blindsided this way? Why the heck didn't someone on your staff let you 
know about it before you found out from the president?

Your staff knew what was going on. But instead of telling you, they were 
trying to fix it themselves. They didn't want to bother you. Your door 
was closed. They thought it was a minor problem. For any number of 
reasons, they didn't let you know. You were left vulnerable.

The bottom line is that after all of your hard work, your major 
investments of time and energy, and your dedication to what you thought 
was right, you've just moved back about ten steps. You've lost 
credibility with the person with whom it counts the most. Try now going 
into that meeting next week to explain the new capital expenditures you 
need to hook up the remaining buildings to the campus network. Try 
asking that your department be exempted from the campus-wide hiring 
freeze.

This mess will get cleaned up, of course, and you and your staff will 
survive. Until next time. The question is, does there have to be a next 
time? Do we have to take it for granted that there will always be a 
certain number of errors in the computer center? Do we have to assume 
that information technology is inherently troublesome?

We're going to take a look at that issue today, because as information 
technology professionals, we owe it to ourselves, to our departments, 
and to our institutions to examine ways to ensure that the work we do 
consistently meets the goals that itshould. There's a lot of evidence 
that we are perceived by our institutions as either not setting--or not 
meeting--appropriate goals.

And why is it so important that we do? Why has this taken on, in fact, a 
most critical importance in the last few years? Because our institutions 
are struggling. We see it every day. Enrollments are down. Tuition 
income is down. Donations are shrinking. We are hearing that some of our 
educational programs don't mesh with real world needs. That our colleges 
are not keeping up with the times. The public is looking very critically 
at institutions of higher learning. So are federal and state 
governments, which are themselves under pressure to assure that tax 
dollars are being spent wisely.

These are critical issues. These are the issues your president is 
thinking about late at night. There doesn't even have to be a crisis of 
incorrect donor acknowledgements; pressures of all kinds are impelling 
presidents and other decision-makers at our institutions to look very, 
very carefully at the value of information technology.

Two of the most frequently asked questions on our campuses today are: 
"What are the benefits of information technology to this institution?" 
and "Have all of our expenditures (mostly large, and certainly larger 
than in many other areas of the institution) been worth it?"

Oh, certainly, the president knows that the school needs the services of 
a strong computer center. He knows that a payroll can't be produced 
without a computer, or a tuition billing. He may even know that a good 
library can't get along without computing anymore. But does he or she 
think of the IT area, the way it is currently run, as an asset to the 
institution or as a drain?

The president of a major midwest multi-campus university told me 
recently that he would like to curtail all further expenditures on new 
technologies for two years. "We have so much technology already ... and 
we don't use a lot of it," he told me. "Someone probably knows how, 
but we really don't have the expertise and the training to make this 
stuff work for us. I'd like two years of no new technology just to catch 
up."

That's not much of an endorsement for continuing to grow the information 
technology area. And he's not alone. An article not long ago in The 
Chronicle of Higher Education put it this way: "The computer center has 
replaced the library as academe's bottomless pit."  

So the question for us is, how do we ensure that our information 
technology departments are genuinely useful to our institutions? How do 
we avoid running a "bottomless pit"? How do we make the benefits of 
technology so obvious and so outstanding that everyone will want to move 
forward, including the president?

My answer is that our information technology organizations need to reach 
a considerably higher peak of excellence than the one most of them are 
on at the moment. My purpose today is to talk about a concept and a set 
of tools called "Total Quality Management" that may help us as we 
strive to develop excellence in the waysin which we manage and use 
technologies within the higher education community.

You've already heard probably about TQM in a variety of places, and some 
of you may have already written it off as a fad. Let me assure you that 
I am also very wary of management fads. In the last ten years alone, 
we've seen a slew of them: One-Minute Management, Management by 
Objectives, Management by Walking Around, Bottom-Up Management with Top-
Down Planning, Management by Neglect, and of course, the ever-popular 
Mushroom Management, which is keeping everyone in the dark and throwing 
fertilizer at them at regular intervals. 

I think we are rightfully reluctant to hitch our wagons to any one set 
of principles without a highly critical look at their actual short and 
long-term value. We have been bombarded in the last decade with faddish 
programs, systems, and processes--none of which seems to make a bit of 
difference in the stark light of day. Nevertheless, I am convinced that 
Total Quality Management has the potential to move us in a positive 
direction toward excellence.

For one thing, TQM is a system that has worked well for several decades 
in other parts of the world, and has become very popular in our country 
in the last few years. Clearly, the focus up until this point has been 
in the business and industrial sectors, but higher education itself is 
beginning to embrace TQM; we're seeing things like a recent issue, for 
instance, of The Bulletin of the American Association of Higher 
Education devoted to TQM in the collegiate environment. 

Total Quality Management, known to some people as the Deming Management 
Method, was developed by several people, most notably W. Edwards Deming. 
Deming gained fame in the 1950's by enabling Japanese industrial systems 
to achieve their reputation for quality. In fact, they were so pleased 
by his work that they awarded him the highest honor to be given to a 
non-Japanese: the Second Order of the Sacred Treasure.

Deming's theory has been reworked and expanded upon by a number of 
people, and has been synthesized any number of times into some number of 
components. You may have heard about the "fourteen points for 
management" or the "ten components of Total Quality Management" or 
other descriptions of the basic elements of TQM. Basically though, it 
comes down to three critical issues.

The first is that whatever you do, what ever business you are in, your 
work must be driven by, and focused toward, the customer. You have to 
know who your customer is, and even in a college or university setting, 
where you might think that the answer to this obvious, knowing who your 
customer is isn't always easy to do. We'll talk more about that issue in 
a bit.  You have to know what your customer wants, you have to know what 
your customer needs, you have to know what your customer values. Most of 
all, you have to know what your customer thinks quality is.

The second critical issue surrounds process. TQM is based on the 
principal that process, or the flow of work activities, is the critical 
factor in attaining quality. Even more importantly, the process needs to 
be guided by a truly customer-oriented focus.In serving the customer 
efficiently, we need to minimize unnecessary complexity, reworks, and 
the need to scrap whole projects.

But how do we ensure that we are serving the customer? And how do we 
enhance our efficiency so that we don't make the same mistakes, cover 
the same ground, and waste our efforts--over and over again? TQM 
attempts to address these concerns by concentrating on two important 
factors: design and output.

Design refers to what it is that we intend to do. In programming, for 
instance, it would be defined as the intended characteristics of the 
program being produced. Questions to be asked include: Does it meet the 
customer need? Do we know how to program it? What do we need--from 
materials to brain power--to program it correctly?

Output refers to the actual product. For the output of a programming 
project, we can't just look whether it works during the testing phase; 
we also have to look at look at things like structure, maintainability, 
and documentation--in other words, the totality of the output. 

Both of these characteristics, design and output, must work together in 
harmony. It is quite possible for a product to be superlative in its 
output characteristics, but lacking in design. A good example might be 
an elegantly crafted program that produces student bills. It could be 
absolutely beautiful in its craftsmanship, but if it doesn't include 
housing charges or financial aid awards, it might not be what the user 
wants. And if it fails to meet the primary goal of serving the customer, 
then it doesn't matter how elegant it is, it has failed.

The third critical issue in TQM is staff involvement. Many of you may 
have read a recent article in our newsletter, The EDUTECH REPORT, which 
talked about a recent fire at Fordham University. One of the authors, 
Walter Weir, Fordham's executive director of computer and information 
management systems, made this point: "When the fire occurred and we had 
to send our network people in to repair the damage, no one had to stand 
over them and say, `You do this and you do that.' Each one knew exactly 
what needed to be done and got on with doing it. They had the right 
tools and they had the authority; as a result, they were able to save us 
from what could have been a major catastrophe for this university. In 
fact, they were able to resolve it in such a fast and expeditious 
fashion that many people were totally amazed." Why did this happen? 
Because months before, they had instituted TQM in their department, and 
by the time of the fire, had already been actively engaged in team 
building and individual empowerment. The results really paid off in a 
tangible way for them.

So that's all there is to it. Customer focus, process improvement, and 
staff involvement. Sounds kind of like motherhood and apple pie, doesn't 
it? Of course, it's not that easy.

In a recent Computerworld  article, Joshua Hammond, president of the 
American Quality Foundation, made a crucial point about quality. He was 
talking aboutbusinesses, but I think we can extrapolate to include 
ourselves as well. 

Hammond stated that, "The problem is that many companies are chasing 
this goal without a clear sense of where they are trying to go or how 
difficult a journey they should expect." In other words, as Deming 
himself said, it's not instant pudding. You can't just simply mix all 
the ingredients together and hope for the best. It takes real work.

Let's revisit each of the three critical components of TQM and see how 
they apply to what we do in IT. The first one is customer focus.

Peter Drucker, the management guru, made these comments in one of his 
books, The Marketing Concept, "Every successful organization has always 
asked: Who is the customer? What is the value to the customer of what we 
do? How does the customer use what he or she acquires? And, what does 
the customer need?"

Let's look at the first one. Who are IT's customers? On one hand the 
answer is obvious: IT's users, or customers, are students, 
administrators, and faculty. But that's only if you cut it one way, and 
describe the user base along functional lines. You could also put it 
this way: our customers are mainframe users, minicomputers users, and 
microcomputer users. Or you could say your user base is made up of three 
groups: potential users, infrequent or undemanding users, and very 
frequent or demanding users. Or you could say your customers are in two 
groups: happy and unhappy.

It matters very much who your customers are, because it has implications 
for how you organize your services, and what services you provide. For 
instance, one of the classic organizational issues is whether there 
should be combined or separate computing centers for faculty and 
administration. Well, if an administrator who is using a Macintosh for 
analyzing downloaded data from a large IBM mainframe has to go to the 
academic computer center for assistance with a Macintosh problem because 
that's the only place on campus that anyone knows about Macintoshes, 
there is reason to question whether that division between academic and 
administrative makes sense anymore.

There are any number of ways you can define who your users are. The 
important thing is that you do it so that it makes sense for your 
institution.

The next question we have to ask is whether it is the users, or 
something else, that really drives our work. Do we have the idea that we 
have to lead the users in order to make progress, or do we let the users 
always take the initiative? We worked with a school earlier this year 
that was one of the first to institute telephone registration. In fact, 
they put telephone registration in almost as soon as the technology 
became available. In looking at the institution in some depth, one of 
the things we discovered is that the project had been initiated, and 
led, by the IT folks, with the registrar a somewhat reluctant 
participant, and the deans brought along literally kicking and 
screaming. Then it turned out that among other things, the student 
information system did not have automated transcripts or on-line 
grading, both of which were rather high up on the registrar's list of 
priorities. The telephone registration projectwas a big one, and took 
lots of hard work and plenty of resources. Were the IT people heroes 
when they made it all work? Anything but. They were leading the users 
with an IT agenda, according to the things IT thought were important to 
the school.

And that leads us into the area of performance judgements. Do we use the 
customer's criteria to judge our performance, or do we use our own? 
We're measuring CPU cycles and network bandwidth but they're measuring 
how many attempts it took to get a file transferred from Mac WordPerfect 
to DOS WordPerfect. We have to learn that excellence in information 
technology comes from one thing only: customer satisfaction; not from 
the number of MIPS in the computer center, not from the speed of the 
campus network, and not from the number of lines per day the programmers 
code.

The second critical issue is process improvement, and its two 
components, design and output. One of the things we often miss is 
linking the design to its purpose. Somehow we got the idea that solving 
the technical problem means solving the problem; in fact that is rarely 
the case. One of the most interesting experiments that Deming conducted 
has come to be known as the "Parable of the Red Beads." This 
experiment is critical to understanding the operating philosophy of TQM.

In this experiment, we have several thousand beads in one container, 
most of which are white and some of which are red. Management has 
decreed that we must collect only white beads, because that is what the 
customer wants. We are given another, larger container and a paddle with 
holes in it that are just smaller than the beads. The task is to pour 
the beads, in a precise manner dictated by management, into the larger 
container, then to extract only the white beads, using the paddle. Of 
course, inevitably some red beads will get into the extracted group. Our 
work will be monitored by two quality control inspectors. It is the role 
of the first inspector to record and count the number of red beads on 
the paddle each time it is removed from the larger container. The other 
inspector verifies the first inspector's tally and is ultimately 
responsible for reporting the final count. In addition, although both 
inspectors continually urge the workers to improve quality, they are in 
competition with each other to uncover mistakes made by the other.

Not surprisingly, the quality of results produced in this situation 
varies, even though each worker adheres to stringent guidelines. After 
each worker had some number of tries, it is possible to establish data 
to show the results attained by each worker, and by the group as a 
whole, and to establish upper and lower control limits.

I know--we don't simply separate red and white beads as we manage 
information technology. Life would be a lot simpler if we did, or if our 
complex responsibilities could be reduced to assembly line logic. But 
can we take anything away from the Parable of the Red Beads? Deming 
suggests we can learn five important truths from his experiment. The 
first is that variation is part of any process. Quality will vary. 
Mistakes will happen. This is as true in our computer centers as it is 
on the assembly line. Perhaps truer--we have so many possibilities for 
error!

The second point is that, in order to plan effectively, we must be able 
to predict and measure results. Deming has said, "In God we trust. All 
others must use data." Andwith good reason. The quantitative 
measurement component of Deming's philosophy is one of the most 
distinguishing aspects of it.

Third, in general, the system in which workers must perform is beyond 
their control. They work under strict guidelines, and the system, like 
the container of red beads with white ones among them, is riddled with 
defects. 

This leads us to the fourth point, which is an important one. By and 
large, in this experiment, only managers are in a position to change the 
system. They control the procedures and the rules. Even the most 
talented and skilled workers are powerless to change the monolithic 
system in which they perform. 

The fifth point is that some workers will consistently be better than 
others. I'm sure you know what I mean. There are people in any 
department to whom we inevitably turn when a job needs to be done 
correctly the first time. And there are others whom we watch closely to 
try to guard against serious errors.

This understood, Deming concludes that we should accept variation in 
human ability, as much as possible, and look instead at the system, or 
the process. It is the system that must be shaped, first to meet the 
needs of customers, and next, to accommodate the true abilities of 
workers. The single most important message here is that the system 
should be viewed as a whole, that it can be improved, and that dents in 
quality come from flaws in the process.

The third critical issue is staff involvement. One of the myths about 
quality is that in order to achieve a higher level of quality, we need 
more, and perhaps better, people than we have at the moment. In 
contrast, one of the principles of TQM is that quality can be achieved 
with the people we have right now, through better training and 
development. Two key components work together: individual empowerment in 
concert with team building.

Let's look at the first one: individual empowerment. Basically, this 
means giving staff members the opportunity to influence what's going on 
around them. Instead of simply doing work that they are assigned by a 
higher-level person, staff members help shape the very goals and 
objectives of the IT department itself. After all, with the emphasis on 
customers, who they are and what they need from us, who better to guide 
that direction than the people who have been working most closely with 
the customers all along? Who is likely to know better the needs of the 
Registrar than the programmer/analyst who has been working on the 
student information system for the last two years? Who is likely to know 
better what the students who use the computing labs need than the 
student lab assistants?

Organizational models are changing. The staff in information technology 
needs to take on a new and crucially important role. They are there not 
simply to take orders from above or to be informed of the latest round 
of decisions made by others. Rather, they are there to be aggressive in 
contributing to problem solving, to taking new initiatives, and to being 
much more self-directed than has ever been the case before in our 
traditional hierarchical organizations.
But with less management control comes an equally important steadying 
device, to make sure that individual empowerment does not go off in 
different directions. That device is working in teams, one of the 
cornerstones of the TQM philosophy. Now, many of you might say, well, at 
least that tradition is already well-entrenched in higher education--
everything is already done by committee. But this is different. TQM 
teams are not committees in the sense that we know them. They are self-
directed work groups. They are not necessarily made up of people 
"representing" different constituencies the way most committees are; 
they are made up of task-oriented people involved with a particular 
process and who want to get a particular problem solved. And they do not 
go on forever. They are formed specifically to tackle a quality issue, 
and when they have done that, they disband. It is this kind of 
collaboration that gets things done.

There are great benefits to be derived from substantive staff 
involvement. But we have to remember that none of this will happen 
without the one crucial item that we have traditionally given short 
shrift to in the past: training. It seems that whenever IT budgets get 
tight, or whenever something has to be curtailed for whatever reason, it 
turns out to be training. That isn't going to work anymore, and we have 
to see training take on a new priority in our striving for excellence. 

The new world of computing demands that computer professionals be not 
only technically talented and up-to-date, but that they also be respon-
sive, cooperative, user-oriented, and able to see beyond just their own 
concerns. Attitudes such as--software is hard to write, therefore it 
should be hard to use; or, time spent in non-programming activities like 
documentation, meetings, and listening to the users is time wasted; or, 
the more elegant and sophisticated a program is, the better--have to be 
done away with, and the staff who still hold these attitudes have to be 
retrained. Their departments and their institutions, as well as they 
themselves, have to make this commitment.

Okay, so what's the next step? If you think TQM might be important, you 
may want to take some time to learn more about it. Needless to say, 
there is a lot more to TQM than just these three components of customer 
focus, process improvement, and staff involvement. There is a whole 
range of tools and techniques, statistical analysis methods, Pareto 
diagrams, affinity charts, benchmarking, and on and on, all of which 
will be helpful in terms of actually implementing TQM. In fact, George 
Bateman of the University of Chicago Business School gives a full-day 
seminar on this as a preconference workshop before the CAUSE and EDUCOM 
conferences, and from what I understand, the CAUSE staff is planning to 
make a videotape from that seminar for CAUSE members. There are two or 
three books focusing on TQM in higher education that are quite good 
also. You may want to check these out. The first one is called On Q: 
Causing Quality in Higher Education, by Daniel Seymour, published by 
Macmillan. The second is from the College and University Personnel 
Association, CUPA, called Applying the Deming Method to Higher 
Education. And the third is published by Jossey-Bass through the 
Association for Institutional Research; it's called Total Quality 
Management in Higher Education. Each of these books is also loaded with 
references to other books and publications that will lead you even 
further into it. 

On the other hand, by now you may be thinking that TQM is interesting, 
but .... You may be also thinking of the reasons that it just isn't 
going to work for you. Before you make up your mind, I'd like you to 
consider some of these issues.

First, I know you're already too busy to get into something new. I know 
the fire-fighting that goes on in IT, and I know the pressure-cooker 
atmosphere that has developed, especially with shrinking budgets over 
the last couple of years. But this may be exactly the reason you need 
something like TQM. At a community college in the midwest that we did 
some work at recently, after studying some of the problems with IT that 
the school was experiencing, it seemed to us that the institution lacked 
a cohesive focus for IT, and that lots of people were doing lots of 
things, but without the benefit of a strong, unified direction. We 
suggested that they create a function, not a position, but a function, 
which would help bring focus to this area. In giving them some of the 
specifics about what this function would look like, we said that a 
majority of the time of the person or persons filling this function 
would be spent among the user community, listening. Unfortunately, most 
of the people who were currently responsible for providing computing 
services took great exception to this; one of them in fact said, "How 
can we possibly spend our time listening? We are already too busy 
doing." But of course, this was at the very heart of the problem. How 
could they know they were spending their time doing the right things, if 
they weren't listening to the users?

With TQM, we've identified a purpose: to serve the customer and to do 
the work that is customer-focused and customer-driven. In addition, by 
changing the system, we can build quality into the process, reducing the 
need for endless checks, double checks, reworks, and throwaways. We 
can't let the rush of day-to-day work and a fire-fighting mentality 
allow us to wear blinders forever. I think we need to take the time to 
step back, remove the blinders, and see what is happening all around us. 

The second issue I'd like you to consider is especially for those of you 
who are stuck on the word "customers," or who don't want to think 
about TQM because it's too business-oriented, and "after all, we're 
just a service within an educational institution." I urge you to 
rethink that position. Consider that it's entirely possible that one of 
the reasons that information technology departments are not thought of 
with the highest esteem throughout higher education, and are too often 
thought of as part of the problem rather than part of the solution, is 
because we have never had any competition. We have had a captive 
audience all this time, and this has given us the unparalleled 
opportunity to be less than excellent. Until we start thinking about 
running IT the way a competitive business should be run, we are likely 
to remain in that deadly trap. It is not a coincidence that at the very 
same time our institutions are questioning the value of information 
technology, that outsourcing is on the rise.

Third, if you are thinking that no one else on campus cares about TQM, 
you could very well be right. But that doesn't matter. You can do it 
anyway. TQM will require an investment in time and possibly in money, 
but once the investment starts to pay off, others outside of IT will 
start to care. You can be the ones communicating quality to the rest of 
the institution. Even the president may be swayed into thinking that IT 
really does have genuine benefit.
And finally, for those who are thinking that TQM is just a fad, you are 
probably right. I think the chances of this being a long-lasting set of 
tools or techniques with this particular set of perspectives is small. 
Twenty years from now, or even twenty months from now, you may not often 
hear the words Total Quality Management anymore. But what definitely 
isn't a fad is what's underneath TQM. The underlying principles of 
customer focus, process improvement, and staff involvement will remain, 
and that's what we have to concentrate on.

We should rely on common sense. What could be more sensible that looking 
at our mission, and focusing on the customer? What could be more right 
than asking the hard questions that lead us to restructure our systems 
to serve the customers' needs, and mesh with the abilities of our staff?

Let me just say a few words to wrap up. IT people have the toughest jobs 
on campus. These words on the slide are from a Federal Express ad, and I 
think they apply better to IT that almost any other area I can think of. 
"It's your job not to screw this up or make any mistakes or drop the 
ball or blow the game. Do it faster and quicker and more reliably and 
more efficiently. Do it right, first-rate, top-notch, without a hitch, 
and absolutely flawlessly. Botch this one and you are out of here, 
history, finished, terminated, toast, lunch, gonzo, dead, kaput. And one 
more thing, DO IT FOR LESS MONEY than you've ever done it before!"

It's a big, tough job. TQM will not, contrary to what some quality 
experts may breathlessly assure you, change everything overnight. But 
its guiding principles will allow us to make some important improvements 
and to take some important steps toward achieving excellence. TQM is 
just one set of tools you can employ to help you do that. It is a 
current set, it is based on some good principles, and it is building up 
a decent track record in other enterprises. But it is only a tool, a 
technique, not an end unto itself. Results are what count. The person I 
quoted earlier, Joshua Hammond, also said, "Excellence is not a 
program; it's an attitude."

We have to do this. Our institutions are in trouble, and they can't 
afford us to be one iota less than excellent. Our colleges and 
universities have, for years, benefitted from your work in the use of 
technology. Today, they need your commitment to assuring that the 
technology and the technology services you provide meet the goals of the 
institution. The achievement of excellence in information technology is 
an issue that directly impacts the role our colleges and universities 
will play throughout the next century. In some cases, it may even be an 
issue of survival.

I'm confident that we can make excellence happen. Thank you.