D-4573 v.4

IMPROVING PRODUCT DEVELOPMENT INTERVAL

AT AT&T TRANSMISSION SYSTEMS BUSINESS UNIT

Elizabeth M. Krahmer

Rogelio Oliva

System Dynamics Group

Sloan School Of Management, E60-3rd Floor

Cambridge, MA USA 02139

Phone: (617) 253-3797 Fax: (617) 252-1998

October 1995

* This work has been supported by the National Science Foundation and AT&T.Special thanks to the people at AT&T Merrimack Valley Works that have assisted insetting up interviews and collecting data, especially Len Winn, Bob Hough and AlHofmann.

D-4573 v.5

2

Prologue

Purpose and Method

This paper is part of a series of case studies being written on the subject of Total Quality

Management and Sustainable Improvement Efforts by the System Dynamics Group at the

Sloan School of Management at MIT. This research is supported through funding by the

Transformations to Quality Organizations program of the National Science Foundation and

the associated corporations. This study, which focuses on product development, is one of

three examining the improvement efforts undertaken at AT&T’s Transmission Systems

Business Unit. The other two studies examine improvements in manufacturing and supplier

quality.

The case study has two components: The first section describes the interval reduction

initiatives in the product development area at Merrimack Valley Works with particular

emphasis on the descriptions provided by the people who participated in the programs and

longitudinal data. In the second section, the data are analyzed to make sense of the

dynamics of the improvement efforts using causal loop diagrams.

The primary data collection method was interviews, which were performed in a semi-

structured fashion. The basic interview protocol is shown in Appendix A. Subjects were

asked a number of standard questions. Given the nature of the research, the interviewees

were not required to stay with the standard questions. If the interviewers felt that they were

pursuing a profitable avenue, the interviewee was allowed to continue in that direction.

Notes were taken at each interview. The interviews were transcribed from notes, and

quotes were taken from the transcription. Several interviewees were subsequently contacted

to clarify issues and elaborate on particular points. Quantitative data were obtained from the

company.

D-4573 v.5

3

Part I: The Data

I. Introduction and Background

AT&T History and Divestiture

AT&T, Inc. (formerly American Telephone & Telegraph Company) was formed in 1877 as

the Bell Telephone Company based on Alexander Graham Bell’s famous telephone patent.

AT&T’s early success was based on its technological innovations and “customer first”

focus. Over time, the company developed through internal growth and acquisition into

three main divisions: Bell Laboratories, the research and development arm; Western

Electric, the manufacturing activities; and local and long distance phone service.

The research prowess of Bell Labs heavily influenced AT&T’s character. Bell Labs’

innovations led to the creation of long distance telephone service and permitted AT&T to

gain control of local, independent operating companies. A strong Bell Labs culture evolved

that valued product quality and reliability. The leadership of Bell Labs gave AT&T an

engineering perspective on business, which persisted through much of its history. Not

surprisingly, many of the statistical methods for maintaining quality were developed by

AT&T employees, among them, Walter Shewhart, W. Edwards Deming and Bonnie

Small.

Following World War I when telephone service was nationalized, AT&T operated as a

private monopoly. The monopoly regulation reinvigorated AT&T’s commitment to

customer service but insulated the company from the usual market pressures to limit

inefficiencies. For example, Bell Labs continued to introduce new technology but at its

own pace and with extensive product development staffing. At this time, Western Electric

held a monopoly position as the only legal supplier of telephone equipment in the US.

D-4573 v.5

4

In the 1960s and 1970s, low-cost, long distance competitors, such as MCI and Sprint,

challenged AT&T’s monopoly rights. In 1984, AT&T finally settled a prolonged legal suit

with the Justice Department that led to the divestiture of the Regional Bell Operating

Companies (RBOCs). AT&T retained ownership of Western Electric, Bell Labs, and its

long distance phone services. Western Electric experienced a sharp and immediate decline

in sales as the RBOCs switched their equipment purchases to other global suppliers,

including Northern Telecom and Alcatel. Due to the loss of market share and profits,

Western Electric needed to dramatically change its business in order to survive. In

September 1995, AT&T announced a corporate breakup; as a result, the equipment

manufacturing and associated product development functions will be spun-off into a new,

yet to be named telephone equipment company in the next 12-18 months.

The Site

Prior to divestiture, Merrimack Valley Works (MVW) operated one of AT&T’s largest

facilities with over 12,000 employees. Based in North Andover, Massachusetts, the facility

houses the manufacture of transmission equipment, long distance digital switching

systems, lightwave systems as well as wire and coaxial cable systems. A co-located Bell

Labs product development center develops new transmission-type products. Finally, the

facility includes some manufacturing operations of components for another division. The

product development supporting the transmission equipment manufactured at MVW is

conducted not only on-site but also in New Jersey. Although the site headcount had fallen

to about 6,000 in 1994, MVW reported gross sales valued at over $1 billion along with

sizable contracts for new and existing products.

The divestiture effected MVW in several ways: First, MVW was forced to lay off workers

during the mid and late 1980s as new entrants captured market share and reduced demand

for AT&T’s network systems hardware. In 1988, the Network Systems Group, to which

MVW belonged, was reorganized into product-based business units. Accordingly,

D-4573 v.5

5

switching equipment manufactured at Western Electric was combined into the Switching

Systems Business Unit along with switching-related Bell Labs research. MVW, along with

a portion of a manufacturing plant in Oklahoma City, and associated Bell Labs operations

in New Jersey and European operations formed the basis of the new Transmission Systems

Business Unit (TSBU), headed by a new President, Peter Fenner.

II. Recognizing the Importance of Quality and Cycle Time

As one of his first actions, Pete Fenner held an off-site “Vision Quest” for his 30-person

Leadership Team in March 1989. Using outside facilitators, the Leadership Team

developed a mission statement for TSBU that outlined the unit’s purpose (Why are we

here?) and vision (What will it look like when we achieve it?). It also established a

consensus on five core values:

• Teamwork

• Customer Focus

• Quality

• Cost Consciousness

• Personal Responsibility and Ownership

The Leadership Team committed to address a number of business issues, including quality

and time to market. Several members of the Leadership Team agreed to spearhead specific

quality efforts.

The focus on quality was not new to the employees in the TSBU. Throughout its history,

Bell Labs has been well-regarded not only for its state-of-the-art research but also for its

outstanding product reliability and safety testing. In addition, senior management at MVW

had introduced Total Quality Management (TQM) programs into the manufacturing

operations in 1983, the year before the divestiture. TSBU contracted with W. Edwards

Deming to conduct seminars for 2,000 employees. The seminars generated few immediate

results, and the program was terminated. From 1986 to 1988, a second TQM initiative was

D-4573 v.5

6

launched; TSBU headquarters mandated “Quality Architecture Teams,” similar to quality

circles. With a focus on quick fixes, little training and lack of implementation strategy, the

Quality Architecture initiative generated frustration and little change (McPherson, 1995).

Given the previous quality improvement attempts, developing employee support for new

quality efforts became a management concern. In late 1989 and early 1990, two events

helped galvanize support for quality improvements. The first was the release of the first

customer “report card.” To the surprise of many, price was not the top customer concern;

rather quality/reliability and features/functionality were paramount. One interviewee

described the latter concern as, “The customers wanted what they wanted and they wanted

it when they wanted it.” As a developer noted:

We needed to compete with the Japanese. Bell Labs had the latest technology, but itwas no good if the customer did not see it. AT&T was not perceived as having thelatest stuff.

To recapture the RBOC customers, such as BellAtlantic, BellSouth and Pacific Telesis,

TSBU’s quality needed to be enhanced and time to market reduced.

A mock MBNQA application process also generated momentum behind quality

improvement efforts. Fenner brought in certified national MBNQA examiners to train

TSBU managers on the Award criteria and evaluation process. On the last day, a MBNQA

examiner scored the mock application and provided extensive feedback. One attendee at this

session remarked: “Fenner sent his executives the message that he wanted TSBU to obtain

the award in four years.”

Following these events, Fenner held his Leadership Team to their commitments to pursue

change. Several initiatives were undertaken, including a supplier quality program, a “One

in 10,000” challenge to reduce the lifetime return rate on printed circuit boards, an order

accuracy program, a product development interval reduction program known as Achieving

Process EXcellence Teams (APEX), and numerous Quality Improvement (QI) teams. The

D-4573 v.5

7

QI teams, using a problem solving technique called the QI story, were modeled after an

initiative at Florida Power & Light (FPL), an electric utility. As a result of the efforts,

TSBU reinvigorated its business and associated processes. In 1992, TSBU won the

Malcolm Baldrige National Quality Award in recognition of its excellence in total quality

management. The significant reduction in product development interval and sustained high

level of product design quality contributed to TSBU’s success.

The following three sections describe the efforts to improve quality in the product

development area. Section three discusses the founding and development of APEX teams.

The influence of the FPL initiative are depicted in section four, and finally, the response of

APEX teams to the FPL initiative and the dissolution of APEX are covered in section five.

III. The First Initiative: Interval Reduction Initiative

The Interval Review Meetings

Bill McCurdy, a Vice President from Bell Labs, responded strongly to the Customer

“Report Card” and the Vision Quest in early 1989. To address the current slow product

development interval, he asked three people to be champions for interval reduction: the

head of manufacturing at MVW; the director of the Bell Lab’s radio systems development

work, and Al Hofmann, a New Jersey-based Bell Labs director with direct development

responsibilities. According to Hofmann, McCurdy focused on time to market as a critical

competitive advantage for TSBU and directed the three champions to reduce the Product

Realization Process (PRP) interval -- the time from specifications of conceptual designs

until release to manufacturing -- by 50% in three years (1989-92).

The interval reduction champions began their efforts by calculating the PRP interval. The

lack of precise and uniform interval data was a significant problem. They used existing data

collected from 1986 to 1989 and also looked at the inventory of current projects. They

categorized projects into full and incremental systems development and estimated that the

D-4573 v.5

8

full system was taking 39 months to develop. Reducing the interval from 39 to 19 months

from 1989 to 1992 became the goal of the interval reduction initiative. As Hofmann

recalled:

The interval data was imprecise and not complete. The 39 month estimate may nothave been a pure or certified number, but I thought it was a pretty good number,and we needed to put a stake in the ground.

From March to September 1989, the champions organized several Interval Review

meetings to examine selected product development time concerns. The meetings generated

an inventory of ideas for interval reduction. Hofmann became the sole champion after one

leader retired and the other changed jobs. Hofmann described his work on the Interval

Review meetings:

I called meetings, but we were making no progress. There was no systematic wayto look at the root causes and develop countermeasures. In September, BillMcCurdy took me out to lunch, or you could say “out behind the woodpile.” Weboth recognized that the current approach was not converging, and we agreed thatwe needed to do something more structured to move the initiative forward.

We brainstormed and decided that we had a systems engineering problem thatneeded systems level thinking. We decided that I should work with Luis Boza ofQUEST Consulting.1 He was very good at creating order out of a complexproblem.

Product Realization Process (PREP) Teams

In the following months, Hofmann and Boza conceived of a new approach that entailed

conducting pilot product development projects. A team of product developers would

identify the best practices from existing development projects and then apply them to

“demonstration” subprocess, such as integrated circuits or software within one or two new

development projects. The demonstration subprocesses would serve as “laboratory

vehicles” to communicate the potential for interval reduction. One interviewee explained:

1 QUEST Consulting is an AT&T internal consulting firm that offers extended training, facilitation, andproject management services to AT&T business units.

D-4573 v.5

9

The idea was to examine independent, unrelated subprocesses and apply theinsights to a new project. Initially, four subprocesses -- wired equipment,integrated circuits, circuit packs, and software -- were selected as pilot areas. Theseprocesses were viewed as being on the critical path for interval time. The plan wasto do a larger trial project later that would incorporate the improvements from eachof the smaller pilot projects.

The PREP approach matched the organizational structure of the product development

function in TSBU: The business unit provided a variety of products of differing sizes and

transmission characteristics. Each product line had a full staff of product developers, each

working on a component of the product. Multiplex, cable and radio products were

developed in MVW, while lightwave and cross-connect systems were based in Holmdel,

New Jersey and digital loop carrier products in Whippany, New Jersey.

According to Hofmann, he recognized after a few months that the PREP approach could

fail given the attitudes of the product developers:

I became concerned that the developers would resist the improvement lessons fromthe pilot projects. The 1,600 research developers in TSBU in the ten product areascommunicated infrequently, and projects tended to be run as “fiefdoms.” Anattitude prevailed that “we do not do it that way in our area.” In this environment,improvements needed to be your fiefdom’s idea to be worthwhile.

Due to his concerns, Hofmann contacted Boza to rethink the interval reduction initiative.

Inception of APEX Teams

The reexamination of the PREP initiative by Hofmann and Boza led to the creation of a new

program known as Achieving Process EXcellence (APEX) teams in early 1990. One

interviewee highlighted an idea that influenced the design of APEX teams:

One PREP project was headed by a creative product manager. He came up with theidea of bringing together subject matter experts from AT&T Microelectronics andother projects for a series of meetings to help him on his PREP initiative. This ideaclicked. It gained better results and led to a team approach.

Hofmann elaborated on the outcome of his meetings with Boza:

Luis and I brainstormed for days on how to get traction given the sociology of theenvironment. We were having to think like social workers. We developed a

D-4573 v.5

10

problem statement: ‘Everything takes too long’ and defined the root causes. We feltit was important to bring together the people that did the actual work from all thedifferent projects. These teams of experts were important to collect data, identifyimprovements and disseminate information back to the individual projects.

In his interview, Hofmann indicated that he had recognized the need for a structured

methodology to guide the teams and selected Process Quality Management and

Improvement (PQMI). Developed by Harold Brewster, PQMI focuses on identification and

analysis of processes and provides techniques for shortening interval. At the time, 200-300

people in TSBU had recently attended the two to three day workshop. One interviewee

assessed the PQMI training:

At the PQMI workshop, you had to grapple with what is a process and how do youmake an improvement. Many people did not realize before that what they weredoing was a process.

Hofmann and Boza assessed the key subprocesses within product development interval and

decided to establish a team for each major subprocess:

• Integrated Circuits

• Circuit Packs

• Software

• Front-End Process

• System Verification

• Wired Equipment

Hofmann envisioned each team as consisting of well-regarded specialists in that particular

subprocess. In order to overcome the fiefdom mentality, the team members would be

drawn from all of the current product development projects. Hofmann selected leaders for

the proposed APEX teams. He noted:

I intentionally picked people who were well-known, high visibility hot shots. Somewere project managers, while others were functional experts. I wanted people whowere recognized as having their heads screwed on straight ... When people told methat it looked like too much work, I offered to contract with QUEST Consulting forfull-time facilitators to support the teams.

D-4573 v.5

11

In the first quarter of 1990, the first pilot APEX team was launched in the area of Integrated

Circuits (IC). Hofmann indicated that he “rigged the game” by selecting the PREP project

manager who had conducted the original subject matter expert meetings. Hofmann then

invited IC subject matter experts to join the team; the members included supervisors,

functional managers, lead engineers, and lead developers. Hofmann reported that he

carefully ensured that each APEX team had representation from all of the development

projects. At this stage, Hofmann imposed on some managers to “volunteer” members. He

also planned the implementation process:

I intentionally did not create all of the teams at once. I started with one and investeda lot of time in making sure it was a success.

In the following quarter, two additional teams were formed, with a total of six teams

formed by the third quarter of 1990.

The Initial APEX Efforts

Based on PQMI methodology, the APEX teams adopted a process approach to addressing

interval problems. Early efforts focused on understanding local best practices, identifying

opportunities for improvement and external benchmarking. For most teams, the first task

involved documenting local best practices. Specifically, they analyzed the current situation

by describing in detail the key subprocesses within their domain and determining the

associated intervals. Accordingly, each APEX member collected information on his/her

project to identify and rank improvement opportunities. One APEX leader reported that his

team spent most of the first year documenting the development practices within TSBU and

credited the PQMI training and methodology with helping with the task.

Interviewees reported several important benefits from the study of local best practices:

While the APEX members had initial difficulties understanding the different “language and

customs” of members from other projects, they soon became stimulated by interacting with

people with similar functional expertise and work challenges. The APEX meetings became

D-4573 v.5

12

“colloquia” for comparing processes. One QUEST facilitator described the benefits of

bringing together people from different projects but with similar expertise:

The exchange of ideas between people that did the same job was valuable. Eachperson brought a different perspective. It was amazing the number of novel ideasthat were generated by people talking about their processes with other experts.Everyone was able to come away with some new ideas.

After the review of local best practices, the APEX team members identified opportunities

for reducing interval and suggested improvements in their individual projects. An

Integrated Circuit Team member recalled:

There were many intangible successes, like communication between organizationsin Transmission Systems. We would share software drivers and emulators. As aresult, we were able to lower the cost of R&D and improve processes like testprocedures.

Several interviewees observed that project staffs were receptive to APEX team suggestions

since the changes were being suggested by a team composed of their own “family”, i.e.,

project members as well as “foreigners” from other development projects.

Benchmarking of outside firms and other AT&T operations became the next APEX focus.

The APEX leadership approached firms with similar processes, some of which were

competitors, to request permission to tour their facilities. Prior to the first off-site visits, a

couple of teams received benchmarking training through QUEST. The Circuit Pack APEX

team conducted one of the first external benchmarking programs. They examined six

outside firms and eight other AT&T operations in 1990. One APEX leader described the

response to the first outside benchmarking trips:

Some in Bell Labs had an “it’s not worthwhile unless it was invented here”mentality. The APEX members were generally more willing to consider ideas thatdid not originate at Bell Labs, but they were still shocked to discover howsignificantly AT&T lagged behind best industry practices in some areas.

As a result of the internal and external benchmarking work, the APEX members’ analytical

competencies grew and, as one interviewee mentioned, “APEX became a process for not

D-4573 v.5

13

only identifying best practices but also the conditions under which the best practices could

be achieved.”

Developing Ongoing Commitment to APEX

The extensive time commitment and persistence of Al Hofmann and members of the APEX

leadership helped the APEX effort develop momentum. Several APEX leaders commented

that Hofmann’s commitment of time and support was essential in sustaining the APEX

effort in the first two years. He made numerous phone calls to his peers and his superiors

to procure funding and time off from other responsibilities for the APEX team members.

He regularly sent notes of appreciation to APEX participants and encouraged managers to

recognize their staffs for their APEX work. In addition, APEX effort benefited from the

full-time facilitation support of QUEST. The four to five facilitators were funded by a

roughly $1 million tax on all development projects, representing less than 1% of the annual

TSBU product development budget. One QUEST facilitator recounted:

At first, people were volunteered for teams by their managers, and people felt thatAPEX was a flavor of the month project ... Hofmann put in a huge amount ofpersonal time. He was committed to spend one-third of his time, but he often spentmore. He worked hard to show that management cared. People then believed thatmanagement was serious.

The APEX teams, however, faced resistance from some managers and product developers.

One APEX leader described:

Management encouraged people to work on APEX, yet they were still expected todo their core job as normal. Many people worked evenings and weekends to catchup on either their development work or APEX. Some organizations did allocate anhour a week for APEX, but that was not enough.

Another APEX leader explained the pressures that APEX leaders were experiencing from

more senior management:

This APEX stuff is hard for Corporate America. It is a hard sell, especially whenpeople are under pressure to fulfill their development responsibilities. [The APEXleadership] felt safe enough that we could keep day-to-day problems solved and doAPEX.

D-4573 v.5

14

A QUEST facilitator noted that the APEX members faced competing work stresses:

The work flow was definitely bursty ... There were periods when some membersworked full-time on APEX, for example, when there was a benchmarking trip ...There were definitely work crises and crunches. For example, the systemverification APEX team members worked on testing system design. When aspecific project got to this stage, then there was often a crunch, and people wouldmiss an APEX meeting ... Some people may have felt pressure from theirsupervisors to do [development] work, but I did not hear complaints.

Over the first year, teams developed regular working arrangements with many teams

holding full-day monthly meetings with people from MVW as well as New Jersey and

other research locations traveling to a common site. A QUEST facilitator estimated that the

APEX leaders and members spent on average 20% of their time on APEX issues.

Despite the competing work pressures, new team members continued to join APEX for a

variety of reasons: Several product developers -- both APEX and non-APEX members --

remarked that people were primarily motivated to join APEX teams for career advancement

reasons. One APEX member mentioned teamwork and comradeship as a key factor.

Another APEX leader held a differing view:

As a result of the growing success of APEX, people started to “self-identify”themselves for teams. These folks were really motivated; they generally came to theteam with ideas that they were eager to implement. They were the ones who activelygot things done.

Despite the differing motivations of team members, several interviewees commented on the

free-rider problem, in which some members did not actively contribute to the work of a

team but attended meetings in order to get credit for participating. One APEX member

described:

The APEX effort was an almost impossible task. It was too big. There was aproblem that each person had an incentive to do his day-to-day work rather than dothe work for an APEX team since APEX took time away from their projects. Therewas a “free rider” problem.

D-4573 v.5

15

APEX Project Reviews

Over time, APEX teams developed new ways to diffuse the lessons gained by individual

teams to the rest of the research and development community. One prominent practice,

“APEX Reviews,” entailed having APEX teams conduct examinations of ongoing

development projects. Hofmann explained how the idea for the reviews evolved:

I was talking to my boss about one of my development projects. He suggestedhaving one of the APEX teams audit my process. It was a great idea, so I dideverything I could to make sure it succeeded.

I approached one of my project leaders, who was also an APEX leader. He hadbeen given the goal of completing his development project in 14 months. I told himto rally his engineers. I wanted the audit of his project to be a resounding success.The Circuit Pack APEX team conducted the review in November 1990. The projectstaff felt the review was beneficial and agreed to institutionalize 30% of therecommendations. That is a high percentage. The review helped [the project leader]get his project done with a remarkable interval of only 15 months. I heavilypromoted this success; it was really a win-win across the board.

After the first review, Hofmann encouraged APEX members to invite other APEX teams to

review their projects and make recommendations. A procedure developed whereby a

project could request a review from the Front-End Process APEX early in its development

process and subsequent reviews by other teams, such as integrated circuits, software,

and/or system verification. The review format eventually constituted six to eight APEX

members spending one or two days examining the project using an APEX Project Review

Checklist. The teams designed the checklists to include the best current practices. The

review teams would use their collective backgrounds and previous benchmarking

experience to develop recommendations. The project staff would respond to each

recommendation by deciding whether or not to accept the proposed change and developing

an implementation plan. An example response is displayed in Figure 1.

D-4573 v.5

16

Will Consider27%

Inappropriate2 %

WillImplement

42%

Disagree1 %

AlreadyImplemented

28%

Figure 1. EQ APEX Project Review ResultsSource: TSBU APEX Superteam Quality Improvement Story 1992, pg. 17A

An APEX leader characterized the review process as “peer consultation” with project and

APEX team members sharing ideas and concerns. In the view of several APEX

participants, the project staffs generally appreciated the advice they received from

experienced APEX practitioners. One APEX leader described the review process:

It was not like a dreaded audit. People were excited to be reviewed. It was likehaving the top coaches and players auditing the Celtics. The APEX team acted likeinternal consultants. The reviewers actually knew what they were doing and couldgive useful suggestions for improvements.

Another leader said:

An advantage of the APEX reviews was that people were given advice by peersrather than by supervisors. Hence, people were not defensive regarding their work,but open to suggestions for improvement.

The reviews did not always live up to their reputation, as one technical supervisor reported:

I did not have a good experience with the APEX process audit. It was a good idea,but there was weak follow-up, and it did not necessarily identify significantproblems. In my case, I received a favorable audit, but I later got into scheduledifficulties. The project took a lot longer than expected.

D-4573 v.5

17

The APEX reviews became a widely used practice within product development. The

number of APEX reviews increased from 10 in 1991 to 23 in 1992 and about 60 in 1993.

Expanding the “Divide and Conquer” Approach

Hofmann and Boza originally conceived of the APEX teams as an effort to divide interval

into its key subcomponents and then confront the issues that lengthened product

development time within each subprocess. By 1991, several APEX leaders recognized a

need for additional teams in order to better “divide and conquer” the interval problem. The

new teams would allow the APEX effort to address subprocesses, such as product

delivery, documentation and customer support services, that were not addressed by

existing APEX teams. An APEX leader highlighted the mentality that the APEX leadership

wanted to overcome with the supplemental teams:

Before the divestiture, Bell Labs really ran the place. AT&T was technology driven.The Transmission Business Unit had $3 billion in revenues and spent $400 million[13%] in research and development. The product managers would first worry aboutfunding the R&D for the product and worried about other issues later. As a result,logistics elements, such as documentation on the product, would not be available ontime, resulting in products shipping to customers without documentation. As amatter of fact, final products would often become generally available, lackinglogistical support elements, such as ordering, delivery, installation, and training.

To confront deployment and integration issues, three more teams were created:

Requirements and Architecture, Product Delivery and Project Management. Hofmann and

other APEX leaders also established the Super Team in April 1991 to coordinate the efforts

of the individual teams. It was chaired by Hofmann and composed of the team leaders,

QUEST facilitators and a few other active APEX members. In mid-1991, the team structure

consisted of:

D-4573 v.5

18

Requirements Architecture

Front End Processes

Product Delivery

System Verification

Software

Wired Equipment

Circuit Packs

Integrated Circuits

Project Management

Figure 2. APEX Team Structure. 1991Source: TSBU APEX Superteam Quality Improvement Story 1993, pg. 7

IV. A Second Initiative: Florida Power & Light Training

The Florida Power and Light Training

As noted earlier, several quality improvement programs were initiated in response to Pete

Fenner’s Leadership Team retreat in March 1989. One active program was inspired by a

January 1990 visit by TSBU executives to Florida Power & Light. FPL had recently

become the first non-Japanese firm to win the Deming Prize, Japan’s top quality award.

The AT&T executives, impressed by their visit, decided to attend seminars FPL was

offering on two key concepts: Quality Improvement Stories and Policy Deployment. The

Quality Improvement methodology or “QI Story” is a seven-step process that permits a

team of workers to analyze a problem and identify countermeasures in a highly structured

fashion. Policy Deployment is a management process aimed at planning and executing

significant improvements in business performance. In response to demand from AT&T and

others, FPL formed Qualtec as a consulting and training division; AT&T proceeded to hire

Qualtec to provide 3-day quality seminars to senior and middle managers.

D-4573 v.5

19

The FPL Training employed a top-down approach with managers in manufacturing,

product development and support areas being trained to educate their own staffs. As a

result, the training took place over a six to nine month period. The training for product

developers in MVW commenced in mid to late 1990. A management team composed of

product development technical supervisors as well as factory managers from MVW

received in-depth training along with a site visit to Florida Power and Light to assess their

success with total quality management. The group, which included several APEX

members, had an opportunity to benchmark FPL’s processes, and one interviewee

commented that he had had an opportunity to see first hand the financial difficulties that

FPL experienced after its successful TQM implementation.

The drive to earn the Deming Prize had distracted FPL management from some important

business issues. In response to $752 million in write-offs in non-utility-related investments

in insurance, real estate and cable television, and employee complaints about the QI

program, the new FPL CEO cut headquarters staff from 25 to 4 and de-emphasized TQM

efforts. One AT&T product developer, who visited FPL, reported that he left with the

feeling that the FPL initiative was “hype.”

While the FPL training translated into an active and successful program in the

manufacturing operations at MVW (McPherson, 1995), the reception to the training in

product development was mixed. One interviewee said:

The TQM material resonated well with the R&D people, since they tend to beanalytical and could see the long term benefits.

Another product developer characterized the overall response:

There were those that embraced the QI story enthusiastically. There were also a lotof people, probably the largest portion, who were interested in the stuff as timepermitted. The last group were cynical. Overall, the training had a qualitative effect.The overall impact is that we became more attentive to the product developmentprocess.

D-4573 v.5

20

QI Teams in Action

After the training, the product development staff became aware of the need to participate on

QI teams. There was no formal structure for creating QI teams, instead individuals could

suggest an idea and start a team to write a QI story. While not officially a job requirement,

product developers were informed by management that they were expected to have a QI

story on their list of annual personal accomplishments. Some managers were more

stringent than others in demanding participation on QI teams. Technical supervisors

reported feeling pressure from senior management to promote QI teams among their staff.

QI teams proliferated; participation rates in product development were estimated at between

50-85% in 1991-92. One technical supervisor portrayed the QI story’s impact:

I think that people saw this as an opportunity for corrective actions. The QI storieswere supposed to allow organizational changes... to cut through the red tape. Youcould work on a committee and make a real difference. Since the problem washighlighted by a QI team, there was a critical mass, and management was underpressure to take action.

Another manager volunteered:

One example of a successful QI story in product development was the ComputingExpenses Team. It fit the textbook case for a QI story. The team examined the costof computers and computer services. Through the use of QI techniques, the teamwas able to identify considerable cost savings of over $1 million.

I think that the QI story has actually added a lot. There was push-back from manyof the mid-level managers, but the more senior managers have adopted the format.We now receive information from Vice-Presidents presented in the QI format. Itclearly outlines their biggest problems and what countermeasures they plan toundertake. It provides a really good perspective.

Some product developers were not so impressed with the QI story methodology or the

heavy emphasis placed on QI teams by management:

We had to participate on QI teams. One can not be against QI around here. It issacrosanct. It is like being against motherhood and apple pie.

To the Bell Labs people, frankly, it was insulting. We had structured, organizedthinking already. We did not need a 5th grade system to drive a logical process.

D-4573 v.5

21

Throughout 1991 and 1992, QI teams worked feverishly with managers encouraging

developers to “really do it.” After TSBU received the Malcolm Baldrige National Quality

Award, participation in QI teams waned in 1993. When questioned about the cause of the

decline in participation, interviewees indicated that there was still a need for improvement

after the MBNQA but that there was a perception that QI teams were being misapplied and

work pressures were too high, as comments from two technical supervisors indicate:

We had QI teams looking at the number of water coolers and fax machines. Whenpeople’s loaded salaries are [as high as they are], they should not be spending timeon things like this.

QI teams are being used less frequently due to schedule pressure. It is hard to findtime for teams. There is a real crunch right now. I tell my people to forget about QIfor now; we can not risk missing important delivery dates. It is hard to get a balancebetween getting the development work done and improving quality.

Others reported that the QI teams had been successful in catching the “fat rabbits” -- as

AT&T employees call easy-to-correct, high-payoff improvements. One APEX member

provided another reason:

I guess the QI story was dropped because management paid less attention to them.The QI discipline was not natural. On the other hand, APEX ended up having a lifeof its own. It had its own terms and discipline.

V. APEX Teams Revisited

APEX Responds to the QI Story

As part of the roll-out of the FPL initiative, QUEST facilitators attended Qualtec training in

February 1991. Since senior management strongly encouraged employees to utilize the QI

Story methodology to analyze problems and identify countermeasures, Hofmann requested

that the work of APEX teams be translated from the PQMI to the QI Story format.

Although the approaches were similar, PQMI had a heavier focus on process identification

and analysis, while the QI Story emphasized problem-solving and implementation. One

QUEST facilitator characterized the transition:

D-4573 v.5

22

It fell on the QUEST facilitators to retrofit the existing APEX effort into the QIstory format. It was not easy; the steps did not exactly match up. The work did helpus identify some things that we had skipped using PQMI. Once the QI stories weredeveloped, it was easy to use the QI story format moving forward.

We developed QI stories for the Super Team and the individual teams. Somesubteams also had their own story. Over time, some of the teams would considerone QI story to be essentially finished and would do a new one. Their early workwould be reported in the QI story as Phase I with the new QI story being Phase II.

The QUEST facilitators also tied the APEX teams into the Policy Deployment Matrix under

the interval reduction goal. In addition, they developed a QI story for the Super Team and

each individual team; each story detailed the past, present and anticipated future activities of

a team. While the APEX teams shifted to the QI story methodology, the teams did not

adhere fully to the rigid QI story format. One technical supervisor stated:

In the QI teams, we had to vote on the importance of a factor to a QI story. Thiswas a form of accountability for errors. Sometimes, if the errors were coming outof manufacturing, those people were reprimanded. In APEX, the story was notpresented that way, so people were not made to look bad and were not gettingblamed. We could then concentrate on finding solutions.

Over time, some APEX and QI teams began to work together as people recognized the

relative strengths of the two efforts. QI Teams were used to address specific problems,

often within a single development project and were disbanded once they completed their

narrow task. In contrast, APEX operated like a think-tank, studying a complex issue in

detail and then suggesting both immediate and longer term countermeasures to shorten

interval or improve processes.

Achieving the Original Goals

In 1992, TSBU received three honors recognizing its quality accomplishments: ISO-9000

registration, the Massachusetts Quality Award and the Malcolm Baldrige National Quality

D-4573 v.5

23

Award.2 APEX played a significant role in achieving ISO-9000 in under one year by

providing documentation on existing local practices. In addition, APEX teams were cited

an important contributor to the Baldrige Award. An excerpt from the Baldrige Award

feedback stated:

Nine APEX teams address improvement of design and product introductionprocesses using Quality Improvement Stories, process performance data, andbenchmarking information. All major business projects are represented on theseteams. “Super teams” make sure these efforts are integrated. Results in reduction ofinterval are excellent.

One QUEST facilitator recollected:

I had been involved in writing a chapter of the MBNQA application and in talking tothe examiners. We did quite a bit of celebrating with picnics and the BaldrigeAward jackets. There was so much new work to do on APEX teams. We did notslow down or reduce our efforts after the Award.

The APEX teams also reached another significant milestone in 1992; they succeeded in

achieving their three-year goal by reducing interval on full systems from 39 to 20 months.

Inte

rva

l (m

on

ths)

0

5

1 0

1 5

2 0

2 5

3 0

3 5

4 0

Full newsystem

Incrementalsystem ICs,Hardware,Software

Incrementalsystem

Hardware,Software

1986-89

1Q91

3Q91

2Q92

4Q92

Figure 3Source: Bailey, Donnell, and Hough, 1994, pg. 21

2 ISO-9000 originiated as a certfication required to sell prodcts in European Union countires and is nowrequired in other overseas markets. ISO demands that product development processes have well-definedprocedures and that as these procedures are follwed they are documented in detail.

D-4573 v.5

24

The achievement was accomplished despite the increased complexity of the products

developed.

Inte

r-C

on

nec

ts P

er S

qu

are

Inch

0

10

20

30

40

50

Projected

1980 1983 1986 1989 1992 1995

Figure 4. Complexity of Circuit PacksSource: TSBU Malcolm Baldrige National Quality Award Presentation 1992

When questioned whether interval reduction arose from improved processes due to APEX

or QI teams or from greater development work intensity, one APEX leader conceded:

That question is like trying to figure out if it is helpful to send your children to agood school so that they have a better life. You do not want to take the risk. Webrought the interval down, but we do not know if it came down due to competitivepressure or APEX work.

According to Hofmann, the APEX leaders and QUEST facilitators had increasingly become

the driving forces behind the APEX effort by late 1991; their leadership permitted Hofmann

to switch to a more supportive and responsive style of management. By late 1992,

Hofmann indicated that he had successfully initiated and nurtured the APEX teams, and

APEX members took pride in their accomplishments. The teams were essentially self-

directed, and Hofmann was feeling overloaded by his other job commitments. He

requested that his APEX responsibilities be turned over and was eventually replaced by two

new co-leaders in May 1993.

D-4573 v.5

25

Setting New Objectives

Reducing the product development cycle time had been the rallying cry of the APEX teams

for its first three years. After the teams achieved their primary goal, Hofmann challenged

the teams to develop their next three-year goal. Initially, the teams adopted the goal of

another 50% reduction from 1993 to 1995, implying a 9.5 month target.

Throughout the APEX initiative, the leadership placed a heavy emphasis on interval

reduction, so the computation of the announced interval metric was important. One

interviewee explained how interval was computed after the initial calculation:

One of the QUEST facilitators kept track of the interval. In the first year, we weresloppy. The interval times were self-reported by the projects, and we used the sign-off date on the survey form as the completion date of the project. This caused someinaccuracies in the interval data. We then got better and issued definitions to helppeople compute interval, tracked the numbers on a spreadsheet and questionednumbers when they did not seem right. Essentially, the interval started when theproduct architecture was complete.

In early 1993, the APEX leadership decided to revise the definition of interval to match the

start of a project to the newly introduced GATE process. The GATE process established

periodic checkpoints at which the business feasibility of a potential product was re-

assessed. One QUEST facilitator explained:

In 1993, we moved to using the GATE process to measure interval. We measuredinterval as [the time between two specific gates]. We thought it would be a bettermeasure, but some of the projects had not adopted the GATE process, so APEXactually helped speed the adoption of the GATE process.

Rather than using the date that the first product was produced in the factory, the new

interval measurement extended the end of project to the date that target manufacturing yields

were achieved. Hofmann estimated that these changes in measurement added five months

to the interval so adjusted the current estimate of interval from 19 to 24 months. While the

APEX leadership reported that the new interval measurement was designed to increase the

consistency and accuracy of interval measurement, some non-APEX members did not

interpret the change in this fashion. One product developer complained: “The project

D-4573 v.5

26

managers in charge of the development projects were gaming the interval metric in order to

look good.”

In August 1993, the APEX leadership decided to maintain the 50% reduction in three year

goal, but adopt the new interval measurement. The new goal became to “Break the One

Year Barrier.” Hofmann explained the rationale behind the one-year target, “This new goal

was quite compelling. Not only was it psychologically appealing, but it also permits a

project to be completed within a single annual budget cycle.” The APEX leadership also

decided to expand the objectives of APEX to address concerns over customer and

employee satisfaction. The QI stories document an increased emphasis on providing “The

Right Feature Set for the Customer.” In addition, they state the results of the 1992

employee survey, in which AT&T personnel expressed lower job satisfaction than the

highest employee-rated companies. The APEX leadership responded by emphasizing

“Getting It Right the First Time” product design. An APEX leader explained the new

emphasis:

If we did not do it right the first time, then there was rework and that increasesinterval. We had been in the habit of designing a device and then testing it to findthe flaws rather than trying to figure out what we really wanted in the design andmake it that way to begin with. It is actually very demotivating for people to dowork, have it be wrong and then have to redo it. Get it right the first time helps byreducing interval and increasing job satisfaction.

In addition, APEX teams adopted a goal of reducing manufactured product cost, and it

included cutting total R&D expenses. In 1992, they announced a goal of cutting R&D costs

by 5% in TSBU, and they continued the focus in subsequent years. One APEX member

commented: “TSBU started questioning whether we could afford our R&D, so we focused

on trying to cut costs and eliminate redundancies.” Given the high number of developers

per project, TSBU operates with significant weekly development costs. Shortening

development interval could, therefore, result in significant cost savings. In addition, faster

time to market provided another financial benefit of preventing AT&T from losing sales to

competitors.

D-4573 v.5

27

The QI stories developed by the individual APEX teams and interview data indicates that

the teams also supplemented the primary interval reduction goal with team-specific

objectives. An APEX leader and a QI story indicated a concern that developers were

“throwing the designs over the wall,” leaving flaws to be discovered later in the process.

Both the Integrated Circuit and Circuit Pack Teams addressed the concern by setting yield

improvement objectives. For these two groups, test yield in the factory was a metric that

was as -- if not more -- important than product development interval. One interviewee

explained why the emphasis on first pass yield became a priority:

When you look at the new MVW VISION assembly line, we were moving to apurely automated system. We needed top quality parts in order for the line tooperate. The quality needed to be 99.99% for each component to achieve a 95%first pass yield. We initially had a 85% first pass yield at the end of the line. Thiswas unacceptable.

Taking APEX to the Next Level

By late 1993, the environment had shifted. AT&T announced a reorganization that would

take place in January 1995, fifteen months away. The reorganization would combine

TSBU with the Switching Systems (SSBU) and Operations Systems Business Units

(OSBU) to form a Global Public Network (GPN) organization. A new marketing approach

would be implemented based on Customer Business Units (CBUs), which would sell

telecommunications solutions to customers. Their new products would consist of bundled

goods and services from Offer Business Units (OBUs) as well as outside vendors. The

new GPN OBU would consist of manufacturing and product development functions from

the TSBU, SSBU and OSBU organizations.

The new marketing approach emphasized products built on generic platforms that could be

readily customized. While early APEX process improvements involved converting to best

industry practices, the new business strategy demanded that the product development

process be redesigned, common product platforms be developed, and more emphasis

placed on reuse of existing work or “multi-use” of new work. The “multi-use” activity

D-4573 v.5

28

entailed having developers from several projects co-produce a new design for use in several

projects. With the lack of communication between fiefdoms prior to APEX, reuse had not

been readily adopted. Multi-use was practiced but was not the norm. Due to the APEX

teams, multi-use could more readily be adopted, and projects became more aware of

opportunities for reuse.

To prepare for the new business environment, the APEX teams focused on the issues of

integration and long-term planning, spawning several new initiatives and APEX teams and

subteams. The Super Team formed the “Glue Team,” indicating its new focus on the

connections between the subprocesses. The Glue Team’s mission was to take a “systems

level view of APEX” and to confront the issues that crossed APEX team boundaries. To

better integrate processes, the APEX leadership looked at “Closing the Loop” in the

product development process by using more feedback from customers to guide the Front-

End Process. In addition, a new Product Integrity team was created to examine product

documentation, customer training, ordering, installation, operations and technical support.

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

1H88(n=1)

2H88(n=3)

1H89(n=4)

2H89(n=1)

1H90(n=6)

2H90(n=7)

1H91(n=4)

2H91(n=10)

1H92(n=6)

2H92(n=3)

1H93(n=4)

2H93(n=9)

1H94E(n=5)

2H94E(n=5)

Figure 5. TSBU Product Development Interval 1988-94Source: TSBU Superteam Internal Document

Another major initiative was the integration of several similar process management and

documentation tools within TSBU, such as the GATE process, and requirement and

D-4573 v.5

29

architecture specifications developed by APEX as well as ISO-9000. To date, the three

tools had exhibited some synergies: As noted, APEX members felt that the rapid ISO

certification would not have been possible without the prior process documentation done by

APEX teams. Similarly, one product developer stated that the ISO-9000 emphasis on

documentation had helped them avoid shipping defective products. The APEX leadership

perceived that even more gains could be realized from greater integration of the processes.

One APEX leader stated:

By having the same facilitator for the Requirements and Architecture [R/A] APEXand product delivery, it was hoped that the R/A APEX team could develop into a“central intelligence” for the whole product development process and helpsynchronize activities.

The integration effort was not an easy task to sell to management. The project wasreally tough to keep going since the benefits were for so many people. If youlooked at it, the near term benefit to any one person was zero, so no one wouldwork on it or pay for it. It is a common good, like clean water. It is too much toeveryone’s benefit. This initiative was ended by the GPN merger, and [thefacilitator] was sent off to another project.

A Policy Statement initiative evolved out of the APEX Project Review process. In the first

few years, APEX team members would update their Project Review Checklist to reflect

new improvements. By 1993, they would identify major policy changes and submit them

to the Super Team for endorsement and dissemination to the individual projects. The Super

Team would then issue a policy statement requested that the new procedures be adopted on

all new product development projects. Some technologies or processes were designated as

“default,” forcing a project to justify a decision to use an alternative. APEX teams

monitored the projects for compliance. In two separate interviews, one APEX leader

explained:

For APEX members, the ability to set business unit-wide policy gave them a senseof power and recognition ... The APEX policies are generally followed. If a projectdesign got into difficulties, it was okay if the project used the APEX policies. Ifnot, the projects could be in trouble.

One major policy required the estimated initial first pass yield on every new designto be at least 85%. A low yield creates a poor flow in the plant, so a high yieldestimate is important. This requirement dictated technology, devices and design. If

D-4573 v.5

30

project designs did not meet this requirement, they would have to be re-architectedto meet the yield requirement ...

The policies were and are tremendously controversial. In fact, I had part of adiscussion about first pass yield recently. The value of the policies is that they causepeople to talk about the consequences of design choices early in the productrealization process. This stimulates a meaningful discussion between manufacturingand design that had not happened before.

A final significant APEX thrust was globalization. In October 1992, Transmission Systems

operations in Europe created an APEX structure. Four “sister” teams were developed in

Europe in the areas of software, system verification, hardware and integrated circuits. The

European teams participated on the Glue Team and also met with the U.S. teams once a

year to share information and techniques.

The End of the APEX Era

Despite the enthusiasm of the APEX leaders for their new initiatives in 1994, there was a

growing sense among several members of the APEX leadership that "we are not getting

anywhere." The distribution of work within the teams became more lop-sided with a few

people taking on large quantities of work and more and more people "riding along as

passengers." The APEX teams were experiencing difficulties in finding replacements when

people stepped down from teams. The interviews revealed numerous reasons for the loss

of momentum. APEX leaders offered differing reasons for the slowdown:

This was a volunteer effort. After a while, the “glitter had tarnished” for some.They felt that trying to create change in a sea of resistance was overwhelming.Some got burned out. Others bowed out due to excessive work loads in theirprimary jobs. There was a high turn-over in the APEX membership. However, thatwas not all bad since it resulted in new people, new ideas, new directions.

APEX participants became demoralized by seeing APEX leaders removed fromtheir positions when their development projects ran into difficulties.

APEX had simply bitten off more than it could chew when it took on the integrationinitiatives. The final projects were too much for everyone’s good for anyone towork on them.

The new leaders were not as strong or committed as Hofmann.

D-4573 v.5

31

An APEX team member explained:

APEX was an extracurricular activity, for which people were receiving nosupplemental compensation or time allocation.

The GPN management disbanded the APEX teams in December 1994, when TSBU

became part of GPN. Some teams were merged into Functional Excellence Teams (FETs),

a new structure that sought to combine APEX teams with Process Management Teams

(PMTs), a team approach used in the larger Switching Systems Business Unit. One APEX

team, Product Integrity, became its own FET. The FETs prioritized the quality

improvement opportunities from PMTs and APEX teams and implemented a portion of the

proposed countermeasures. Several APEX members expressed regret, stating that the FETs

closely resembled PMTs, which were more short-term oriented and ill-suited to address the

longer-term, more complex issues that product development was confronting. A QUEST

facilitator observed that the APEX teams and PMTs reflected their respective organizations.

TSBU had a diverse product line and promoted autonomy, experimentation, and creativity,

while Switching, with its one large development effort, valued standardization and

hierarchical managerial control. One APEX team member lamented:

There was no strong leadership that could weld the various FETs into an integrated,coordinated activity. As such groups reverted to the old paradigm of focusing in ontheir individual functional nested interest rather than trying to optimize the deliveryof the whole..

The APEX era was associated with a period of significant reduction in product

development interval. The following diagram depicts the trend in PDI for both incremental

and full systems, commencing in 1988. The figure depicts the product development interval

for both full and incremental systems. PDI is defined as the time from GATE III to GATE

V. Since the GATE process was introduced in 1992, the PDI data from prior years was

recomputed to match the GATE criteria by AT&T QUEST facilitators.

D-4573 v.5

32

D-4573 v.5

33

Figure 6Source: Adapted from Internal AT&T document

Most of the interviewees commented that APEX had improved their individual and project

work processes although at least one person felt that APEX had made no noticeable change

in processes or environment. Some APEX members reported improved job satisfaction as

they spent less time redoing work and more time on high level issues. In addition, APEX

members reported benefiting from having earned respect from their peers and access to the

ear of selected high level management. For some, the work had resulted in better

performance appraisals and may have long term career benefits.

Other former APEX members expressed optimism about the future. One technical

supervisor was excited that a FET was finally going to examine circuit design in more

detail. Hofmann enthusiastically noted that he had recently been invited to head the System

Verification FET and that he was eager to get involved. Another product developer

observed that the nature of the FETs has been changing and that they are starting to

resemble APEX teams in nature. He smiled and commented: “There is a mating dance still

going on.”

D-4573 v.5

34

Part II. Analysis: Sustaining the APEX Effort

In the second part of the case study, the key dynamics underlying the reduction in product

development interval (PDI) at AT&T Merrimack Valley Works (MVW) are analyzed using

casual loop diagrams. While the causal loops and associated descriptions of the diagrams

were discussed with several MVW managers, the specific dynamic relationships presented

in the analysis were developed by the authors based on interview and longitudinal data.

The following discussion initially will review the traditional Total Quality Management

(TQM) methods used to precipitate and perpetuate self-improvement initiatives. The

conventional techniques will then be contrasted with the methodology employed by the

Achieving Process EXcellence (APEX) teams in order to identify the different dynamic

attributes. Finally, the unanticipated counterforces that slowed the momentum of the APEX

program will be assessed.

I. The Self Improvement Dilemma

Many TQM programs rely on “self-improvement” as a fundamental concept. TQM experts

assert that the employees doing a job are the best-informed experts and that they should be

responsible for identifying the improvement opportunities and implementing the associated

countermeasures (Juran, 1974; Ishikawa, 1985; Deming, 1986; Shiba, Graham and

Walden, 1993). Diagram 1 depicts the traditional conflict that employees confront when

deciding how to allocate their time between the process Improvement Effort and their

normal ‘day-to-day” work, which for AT&T product developers is known as Development

Effort.

The balancing loops (B1D, B2D, B3D) represent the employees’ effort to deliver the

expected day-to-day work. If the Demand for Development increases beyond current

development capacity, the employees’ experience Development Pressure. Initially, the

D-4573 v.5

35

employees will respond to the work pressure by increasing the intensity with which they

work (Loop B1D) and the percentage of the work day spent on Development Effort (Loop

B2D). The development effort produces Development Results that alleviates work

pressure. Should work pressure continue, the employees respond by working overtime,

thereby raising the Total Time Available to complete development work (Loop B3D). The

response mechanisms to Improvement Pressure (B1I, B2I and B3) are assumed to be

comparable to the mechanisms for Development Pressure. The two efforts are limited by

the total amount of time available to employees to do their work.

Overtime

B1I

B3I

B2I

WorkEfficiency

ImprovementEffort

MaximumTime

Available

DevelopmentEffort

DevelopmentPressure

ImprovementPressure

Total TimeAvailable

Fraction ofTime to

Improvement

B 3 D

ImprovementResults

Demand forDevelopment

Work

B 2 D

B 1 D

R 1

DevelopmentResults

+

+

+

+

++

-

+ +

+

-

+

+

+

-

+

-

+

+

Diagram 1. Feedback loops controlling the time allocated to development and improvement efforts under theself-improvement scenario.

Arrows indicate the direction of causality. Signs (“+” and “-”) at arrowheads indicate the polarity ofrelationships: a “+” denotes that an increase in the independent variable causes the dependentvariable to increase, ceteris paribus (and a decrease causes a decrease). Similarly, a “-” indicates thatan increase in the independent variable causes the dependent variable to decrease. Reinforcing looppolarity (denoted by R in the loop identifier) indicates a self-reinforcing (positive) feedback process.Balancing (B) loop polarity indicates a regulating (negative) feedback process.

D-4573 v.5

36

The TQM rationale for self improvement programs is captured in the reinforcing loop

resulting from the responses to work pressure (Loop R1). Improvement Effort generates

enhancements in product development processes. The Improvement Results allow greater

Work Efficiency, which permits product development work to be completed with less

development effort. By augmenting efficiency, more time becomes available for

improvement efforts, generating a self-sustaining, continuous improvement mechanism.

Many TQM initiation strategies recommended by experts rely on the self-sustaining

improvement dynamics (R1, B1I, B2I, and B3I) to serve as the engines to drive

improvement programs.

Prior to initiating improvement efforts, organizations typically work to satisfy the

development demand without any substantial benefits from process improvement. To

capitalize on the benefits of the process improvement programs, TQM gurus encourage

company executives to “jump-start” and then sustain the continuous improvement effort

(Juran, 1974; Ishikawa, 1985; Deming, 1986). Specifically, they recommend:

• Management should indicate the need to improve processes and, if needed,

lighten the day-to-day work expectations—increase the Improvement Pressure

and reduce the Development Pressure (Management Support in Diagram 2);

• Reward and compensation systems (Improvement Incentives) should be

established, which recognize improvement efforts and results. For the incentive

system to be effective, the rewards for improvement should be attractive relative

to the Development Incentives (Loops R1I and R1D, respectively).

With these signals in place, it is expected that the employee Commitment to Improvement

will emerge; employees perceive the benefits of improvement results and allocate more time

to improvement efforts (R2I). The traditional TQM programs also rely on stated

improvement goals, that are periodically adjusted as milestones are achieved, to maintain

Improvement Pressure and generate continuous improvements.

D-4573 v.5

37

R2I

R 1 D

DevelopmentIncentives

ImprovementIncentives

R1I

ManagementSupport

Commitment toImprovement

B1I

B2I

WorkEfficiency

ImprovementEffortDevelopment

Effort

DevelopmentPressure

ImprovementPressure

Fraction ofTime to

Improvement

ImprovementResults

Demand forDevelopment

Work

B 2 D

B 1 D

R 1

DevelopmentResults +

+

++

+

+-

-

+-

+

-

-

++

-

++

+

+

+

Diagram 2. Feedback loops describing the mechanisms to ‘jump start’ the self improvement programs3

II. The APEX Experience

Several attributes distinguish the APEX product development interval (PDI) reduction

initiative from the traditional self-improvement model described above. The drivers

underlying the traditional model do not adequately explain why the APEX teams sustained

their improvement effort under seemingly adverse conditions:

• The impetus for the interval reduction effort from top management (Peter

Fenner) and the Vision Quest meeting. The APEX effort was not presented

strongly to the product development engineers (PDEs) by senior management as

a top priority, instead it was driven by the commitment of time and effort from

one director, (Al Hofmann), a few senior managers as well as the full-time

work of the QUEST facilitators. The APEX effort developed momentum slowly

3 The loops that describe the ‘overtime’ response to increased work pressure have been removed to simplifythe diagram.

D-4573 v.5

38

since PDEs were hesitant to participate in a project that could be a “flavor of the

month” effort.

• Local management support of the APEX initiative was modest and quite

variable, and it tended to emphasize the day-to-day development work over

improvement efforts. Some managers did allocate one to two hours a week for

their staffs to participate on APEX teams.

• Interview data suggests that the traditional incentive/compensation strategies to

accelerate improvement participation were not in place.

• The stated goal of reducing PDI by 50% from 1989 to 1992, while serving as a

source of inspiration for the improvement effort, also placed additional work

pressure on PDEs to complete development work in a shorter time period. As

the three-year deadline approached, the PDEs felt compelled to allocate more

time to development rather than improvement and to increase overtime.

• When engineers or managers missed deadlines, some were pressured to drop

APEX team activities.

R2I

ManagementSupport

Commitment toImprovement

B1I

B2I

WorkEfficiency

ImprovementEffort

DevelopmentEffort

DevelopmentPressure

ImprovementPressure

Fraction ofTime to

Improvement

ImprovementResults

Demand forDevelopment

Work

B 2 D

B 1 D

R 1

DevelopmentResults

PDI Goal +

+

+

+

+

++

-

+

+

-

-

+

- +

+

+

Diagram 3. Mechanisms employed by APEX leadership to “jump-start” the interval reduction initiative atAT&T TSBU in 1989-90.

D-4573 v.5

39

The Drivers of Improvement

While the APEX initiative lacked the improvement incentive mechanism and pronounced

management support advocated by TQM experts, other mechanisms contributed to its

success:

1) The Establishment of a New Metric

Prior to divestiture, AT&T maintained a reputation of product excellence but not market

responsiveness. In reaction to the post-divestiture environment, the TSBU senior

management set the goal of reducing product development interval (PDI) by 50% in three

years. The APEX leadership then compiled interval data in order to determine their current

status; and interviewees reported surprise at discovering that a full system required 39

months to develop. During the first three years of the APEX initiative, the Product

Development Interval Goal became a rallying cry for the APEX program. The APEX

leadership continuously monitored the progress in achieving the PDI goal and, when

needed, refined the metric to more precisely measure the PDI. This focus encouraged

elimination of the initial ‘slack’ in the product development processes. Accordingly, the

establishment of a new metric drove the PDEs not only to improve the development

processes but also to work harder on the day-to-day development tasks. As one APEX

leader indicated, work pressure may be as much a factor in the interval reduction as process

improvements.

2) Adaptive Methodology

To ensure that the PDI goal was achieved, the APEX leadership became committed to

upgrading the APEX methodology. Unlike many TQM programs that provide a highly

structured yet rigid analytical process, the APEX initiative was supported by a flexible

methodology. When the initial interval reduction meetings and subsequent pilot project

D-4573 v.5

40

approach of PREP failed to produce improvement efforts due to the fiefdom and “not

invented here” mentalities, Hofmann, with the advice of Boza, examined the Adequacy of

Methodology. As a result, Hofmann reported that he and Boza examined the “sociology of

change” and intentionally altered the approach. Specifically, they adopted the “Divide and

Conquer” strategy by establishing an array of APEX teams, each focused on improving a

different subprocesses and staffed with highly respected representatives from each

development project (Loop B1M). At that point, the Methodological Sophistication of the

APEX initiative matched Organizational and Technical Complexity of the issues they were

confronting, and improvement results could be obtained (Loop B2M).

Rather than adhering to the initial sharing of experience and benchmarking techniques, the

APEX leadership continued to adapt the methodology as they confronted issues of

increasing complexity. For example, they added Project Reviews, created the Glue Team,

and introduced individual team objectives, policy statements and foreign teams. These

changes enabled the APEX teams to better address the product development integration

issues arising the 1994-95 period. The repeated Upgrading of Methodology helped sustain

the APEX program by generating improvement results despite the greater complexity of

issues being addressed.

3) Improvement Results Generate Personal Rewards

A powerful driver for the effort was the recognition of improvement results that APEX

participants received from fellow project members as well as peers working on other

projects. The APEX members felt appreciated by other product development engineers

(PDEs) who benefited from the sharing of experiences and benchmarking information

provided at APEX meetings and through Project Reviews. The peer recognition and job

satisfaction mechanisms sustained and, even, enhanced the APEX team members

commitment to the APEX effort (Loop R3I). Three characteristics of the Bell Labs product

D-4573 v.5

41

development culture explain the success of peer recognition in motivating process

improvement efforts:

• Because of the nature of their work, which entails developing products that will

be delivered to the market in one to three years, PDEs have a sense of the long

term perspective and are more willing than many to make the initial investment

in process improvement without seeing immediate results.

• PDEs are analytical problem solvers. Job satisfaction increases when people

have interesting problems to address. Examining work processes was an

appealing and natural challenge for PDEs. Reducing inefficiencies and rework

enhanced job satisfaction, particularly when the changes impacted their own

processes. The improvement results, thereby, strengthened commitment to

undertake additional improvements.

• Supplemental compensation is not a powerful motivator for PDEs, who are

already relatively highly paid. Peer recognition and the benefits of sharing

experiences with PDE colleagues seem to be much stronger motivators for the

product development community.

Upgrading ofMethodology

MethodologicalSophisticationB 2 M

Adequacy ofMethodology

Organizationaland Technical

ComplexityPeer Recognition

and JobSatisfaction

R2I

ManagementSupport

Commitment toImprovement

B1I

B2I

WorkEfficiency

ImprovementEffortDevelopment

Effort

DevelopmentPressure

ImprovementPressure

Fraction ofTime to

Improvement

ImprovementResults

Demand forDevelopment

Work

B 2 D

B 1 D

R 1

DevelopmentResults

PDI Goal

R3I

B 1 M

-

+

-

+

+

+

+

+

+-

+

-

-

+

+

-

++

+

+

+

+

+

+

+

Diagram 4. Feedback loops driving the improvement efforts under interval reduction initiatives in place atAT&T TSBU in the 1989-94 period.

D-4573 v.5

42

The Counterforces to Improvement

Several mechanisms appeared to have reduced the effectiveness of APEX teams during

1993-94. A change in leadership may have contributed to the loss of momentum, but its

impact was limited since the APEX teams had developed to the point that the APEX leaders

and QUEST facilitators, rather than the top directors, were directing the activities. Several

additional factors contributed substantially to the leveling off of the product development

interval in the 1993-94 period:

1) Demand Tidal Wave

Commencing in 1989, the TSBU organization experienced sharp growth in demand for

products arising from exogenous environmental changes:

• the rapidly changing telecommunications market, generating demand for

broadband products to accommodate internet, video-conferencing, etc.,

• the surge in orders for telecommunications equipment from overseas markets,

• the winning of the Malcolm Baldrige Award in 1992 attracting quality-

conscious customers, and

In addition to the surge in external demand, two senior managers reported that AT&T

responded to the enhanced PDE work efficiency by increasing its Willingness to Accept

Orders rather than reducing its PDE headcount.

D-4573 v.5

43

Upgrading ofMethodology

MethodologicalSophisticationB 2 M

Adequacy ofMethodology

Organizationaland Technical

Complexity

Peer Recognitionand Job

Satisfaction

R2I

ManagementSupport

Commitment toImprovement

B1I

B2I

WorkEfficiency

ImprovementEffortDevelopment

Effort

DevelopmentPressure

ImprovementPressure

Fraction ofTime to

Improvement

ImprovementResults

Demand forDevelopment

Work

B 2 D

B 1 D

R 1

DevelopmentResults

PDI Goal

R3I

B 1 M

B 2 S

B 3 S

B 1 S

Tangibility andProximity of

Results

EnvironmentalChanges

Willingnessto Accept

Orders

Time Requiredfor

Improvement

-

+

+

+

+ +

+

+

-

+

+

+

+

+

++

-

+

+

-

-

+

- +

+

+

+

+

+

-

+-

Diagram 5. Feedback loops controlling the time allocated to development and improvement efforts underinterval reduction initiatives in place at AT&T MVW in the 1989-94 period, including unanticipated

feedback loops activated by the initiatives.

Accordingly, the success of the APEX improvement effort created additional demand for

development work and increased the time needed for development work. As a

consequence, PDEs were pressured to reduce the time available for improvement, thereby

slowing the progress of the interval reduction initiative (Loop B1S).

2) Confronting Process and Technical Complexity

The original PDI goal announced for the APEX effort was realistic as significant ‘slack’

existed in the product development prrocesses. The early successes of the APEX initiatives

were enough to activate the self-improvement mechanisms. Together, with the QI teams,

the APEX effort caught many “fat rabbits” in the first three years. The APEX leadership

then was forced to shift from the “Divide and Conquer” strategy directed at improving

subprocesses to an approach that focused on integration issues. The change shifted the

APEX effort outward in both the technical and organizational complexity dimensions of the

Schneiderman’s process complexity matrix (Diagram 6):

D-4573 v.5

44

MultipleOrganizations

Technical Complexity

Org

aniz

atio

nal C

ompl

exity

SingleFunction

Simple Complex

IndividualMachine

ProductDevelopment,

Customer/VendorPartnering

Wafer FabCrossFunctional

Increasing Half-Lives

Incr

easi

ng H

alf-

Live

s

OperatorErrors

14 18 22

7 9 11

1 3 5

Estimated Half-Lives

TC

OC

Diagram 6. Adapted from Schneiderman (1991)

Schneiderman (1991) asserts that the time required to realize improvements increases with

the complexity of the problems addressed. By confronting more complex challenges,

APEX teams were expanding theTime Required for Improvement and slowing the rate at

which Improvement Results were generated (Loop B2S). One APEX leader described this

phenomenon as: “the feeling was that we were not getting anywhere.” Since the APEX

participants were still expecting the same rate of improvement, they became frustrated and

less committed to APEX teams when the improvement gains were not as forthcoming. As

they obtained fewer improvement results, the members also received less encouragement

from their peers and felt less committed to the APEX effort.

3) APEX is too much to “Everyone’s” Benefit

The expanded goals for the APEX initiative had a second effect on the reinforcing

mechanisms required to sustain the improvement process. As more complex issues were

being addressed, it became increasingly difficult for product developers to relate the

D-4573 v.5

45

benefits -- both potential and realized -- of improvement efforts to their development work.

Unlike the early process improvements that directly improved an individual’s work

processes, the later improvements often improved the coordination of the overall

development process or benefited other projects. Without high Tangibility and Proximity of

Results, it became difficult for APEX members to maintain motivation and commitment to

the initiative. Since the expected marginal benefits of Improvement Efforts were low, each

member had an incentive to behave as a “free rider,” receiving recognition for the

improvement results of his/her whole team without making the personal commitment to

undertaking improvement effort. Instead, each free rider maintained his/her time investment

in development work. As a result, the improvement dynamics were furthered weakened

(Loop B3S).

D-4573 v.5

46

References

AT&T, Transmission Systems Business Unit APEX Teams, (1992, 1993, 1994) “QualityImprovement Stories.” Internal AT&T documents.

AT&T, Transmission Systems Business Unit, (1992) “Malcolm Baldrige National QualityAward Presentation,” Internal AT&T document.

Bailey, Susan R., Augustus J. Donnell and Robert M. Hough, (1994) “Process Control(ISO 9000) and Process Improvement (APEX) in the Transmission SystemsBusiness Unit,” AT&T Technical Journal, 73 1:17-25.

Deming, W. Edwards (1986), The New Economics for Industry, Government Education,Cambridge, MA: MIT Center for Advanced Engineering Study.

Ishikawa, Karu (1985), What is Total Quality Control? The Japanese Way, EnglewoodCliffs, NJ: Prentice-Hall.

Juran, Joseph M. (1969), Managerial Breakthrough: A New Concept of the Manager’sJob, New York: McGraw Hill.

Juran, Joseph M. (1974), The Quality Control Handbook, Third Edition, New York:McGraw-Hill.

McPherson, Aaron F., Total Quality Management at AT&T, Master’s Thesis, Sloan Schoolof Management, Massachusetts Institute of Technology, 1995.Schneiderman, A.(1988) Setting Quality Goals, Quality Progress. April, 55-57.

Schneiderman, A. (1991) A Model for TQM Problem Solving, Unpublished Presentation.

Shiba, Shoji, Alan Graham and David Walden (1993), A New American TQM: FourPractical Revolutions in Management, Portland, Oregon: Productivity Press.

D-4573 v.5

47

Appendix: Structured Interview Questions

I. Introduction and Background

II. Could you tell us about your background with AT&T and current responsibilities?

III. What was your exposure/involvement with quality initiatives?

IV. For each initiative:

What was the trigger(s) for the initiative? Were there critical players?

Was there an initial Strategy formulated for implementing the initiative? What wasit? Who developed it?

What kind of training did you receive? How was it received?

What other methodologies were relied on?

What kinds of teams were formed? How did people join teams? What percentage ofpeople participated on teams?

Did teams persist? why or why not? What forces sustained or put pressure on theinitiative?

What were the improvement goals? Did it tie to the Policy Deployment Matrix?

Did they evolve over time?

What kind of recognition did people receive? What kinds of incentives toparticipated? Did they change over time?

What level of management support was there? Did the level of supportchange over time?

How did the initiative relate to efforts in manufacturing? sales? suppliers?

What metrics were used?

What were the results of the initiative (positive and negative)?

What data is available that supports the results?

How did the initiative relate to other (competing or complementary) initiatives?

V. How did the Malcolm Baldrige National Quality Award process impact the efforts? ISOcertification effect the process?

VI. How was the product development process improved/changed by the efforts?

VII. Is there anything we missed?