Coffee klatch's quality qualms - a continuing series of articles describing a fictional company's implementation of client/server systems - Technology Transfer - Column

In 1992, the fictional Acme Services struggled with the issues of implementing client/server systems. In 1993, starting with this issue, and continuing every other month, we will follow Acme Services as the company deals with other concerns that may arise in a rapidly changing information technology environment. Today, the topic is quality.

Sam, the Systems Man, liked to keep his hand in technical things. He usually spent lunchtime experimenting at his terminal. This morning, though, his boss had asked him about quality, and how his group was implementing quality processes. Sam wanted to talk to his colleagues about this.

When he asked Frank the Follower and Lou the Lifer if he could join them and two other managers in the coffee shop, they were surprised. "Of course you're welcome to join us," said Lou, head of application development. "We don't see enough of you. What's been going on in the systems area?"

"Not a lot -- same old thing," Sam replied. He thought for a moment and then continued, "I guess the big thing now seems to be quality -- you know, the new management style and Deming's theories and all that."

There were groans around the table.

"Really? So what are you doing about quality?" Frank asked somewhat snidely. Frank manages a group of mainframe developers.

"I'm not really sure. You know, we all went to training a few years ago, and it sounded so exciting. Some of Deming's ideas sounded good. But when I got back to the office and tried to put some of those ideas into practice, it was not as clear as it should have been."

"So what prompted this sudden interest?" Lou asked.

"Don the Director talked to me this morning about quality," Sam replied. "It seems that his boss, Betty the Businesswoman, was visiting a friend of hers from that insurance company across town. Betty told Don that they have been using quality to improve system reliability and availability. I'm not sure what they have been doing, but Betty was impressed. She wants to know what we have been doing."

QUALITY IS NOT EASY

"This must be a trend," Lou interjected, "I was visiting with one of our users last week. I think you all know Ronald in customer service." They all nodded their heads. Lou continued, "Ron told me that they have been applying quality processes for some time now. They have been tracking all customer complaints and creating statistical control charts. They have been searching for the root causes of customer problems. Ron indicated that they have been able to take corrective action on some of the most prevalent problems. He said they have almost eliminated some types of complaints, and have saved time on rework."

"Yes, but they are not in data processing," Frank said, somewhat defensively. "They have something they can measure. They also have a fairly simple process they can control. It's just not that simple in data processing."

Lou responded, "Ron said it took quite a while to do all the work, and some of the changes affected other departments. He indicated that quality isn't easy, but it seems to be worthwhile in his department."

Sam jumped into the conversation. "There are things we can measure and analyze," he offered. "We have been thinking about doing an analysis of all the outages on our online system. We should be able to categorize failures and search for root causes. From this, we hope to create action plans to prevent some outages."

"But," Frank interjected, "you know what causes most types of outage. We've been analyzing failures and taking corrective action for years."

"It is different, though," Sam said. He was excited. "Ever since we went to the quality workshop last year, I've been thinking that there is more to it than just resolving outages. It seems we need to categorize our causes into areas like 'process,' 'people' and 'standards', and then attack them systematically. I'm a little skeptical, but it seems that we should be able to find root causes and address them."

"You're right," Lou said. "Otherwise everything always comes down to, 'So and so messed up.'"

Sam apologized. "I'm sorry if it has looked like we've been finger-pointing. I've asked my system programmers to try to dig deeper into the causes of some system failures, hopefully to find ways to improve processes. Unfortunately, not everyone understands that we're not trying to find fault with people, but with processes."

PROCESS MAPPING AND EMPOWERMENT

Frank shook his head, "Lou, I remember what they taught us in those classes. It all sounded so good and some people are getting it to work. But, between you and me, I haven't been able to apply much of it. Everything requires measurement, and I don't have much that is concrete enough to measure. How can I apply statistical process control unless I have something to measure?"

Edna the Entrepreneur, manager of technology research, was sitting at the next table. She had been listening to everyone's thoughts. "I think I share Frank's concerns about measurement," she said. "My group does a lot of R&D. When we explore new technology, we never know how well it will work or whether it will ever be practical. It is hard to measure our work directly.

"Instead of concentrating on measurements," Edna continued, "we have concentrated on process mapping and empowerment. We have looked at our inputs and outputs. We have identified our users, and we have tried to find out what they really need. Along with this, I've tried to empower my people and give them the authority to get things done. I included more money for training in this year's budget, and I will be trying to do some cross-training. Even though I'm struggling with some parts of quality management, I've found a few things that seem to make sense in my area."

One of the managers spoke up, "Well, we've looked at defect reduction and tried to apply it in the programming area. We have estimated the number of lines of code we produce."

At Lou's look of dismay, he sighed. "Yes, I know we probably should be using function points," he said, "but we can estimate lines of code fairly easily. We have a tool to count lines at the beginning and the end of a development cycle. Then we check the system problem log for application-related problems, or what we call defects. We then match the two and come up with a 'defect per thousand lines-of-code' measurement."

Edna asked, "What about things like errors in documentation or in screens and reports?"

"We track these, too, with measures of errors per page for documentation and errors per display."

Frank interjected, "But that seems like a lot of overhead. And I'm not sure our users really care. I think timeliness is a bigger issue."

"That's true," Lou answered. "Reducing project cycle time is another measure of quality. Frank, how long do your project teams typically spend in the analysis phase?"

COPYRIGHT 1993 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group