at at&t t ransmission systems business …web.mit.edu/jsterman/www/sdg/apex.pdfcustomer service...
TRANSCRIPT
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?