The Learning Initiative at the AutoCo Epsilon Program, 1991-1994
George Roth
Art Kleiner
Center for Organizational Learning
MIT Sloan School of Management
30 Memorial Drive
Cambridge, MA 02139
May 8, 1996
Several Excerpts of "The Learning Initiative at the AutoCo Epsilon Program, 1991-1994" are presented below. You can obtain the entire document by completing an order form and sending $60 to the MIT Center for Organizational Learning.
- The Learning History Disclaimer
- Facilitation Guidelines: Learning History Dissemination Workshop
- Forward
- Executive Summary
- Preface
- Chronology
Origins of Epsilon's Learning Project
Theme 1: Hard results, soft concerns
- Learning in the core team (Jan. 1992 - Sept.
1992)
- The system map (Learning Team Meeting, August,
1992)
- The transition to openness
- Creating the atmosphere of trust and cooperation
- A mandate that "bearing bad tidings" would be safe
- Ongoing sharing of information and perspective
- A culture of greater inclusiveness
- Deliberate encouragement of informality and friendship
- A mindset that "no one has all the answers"
- Behavioral versus technical: a zero-sum game?
- The dilemma of integrating process and engineering
knowledge
Epsilon's Noticeable Results, 1991-1994
A learning history describes what happens in a learning and change process, in
the voice of participants. It documents "hard" facts and events, and focuses on
what people thought about events, how they perceived their own actions, and
differences in people's perceptions. By recreating the experience of "being
there," the learning history helps readers understand what happened in a way
that helps them make more effective judgments.
Learning is not always an easy process. It involves taking on the mindset of a
beginner, letting go of what you have worked hard to "know," and a willingness
to examine situations which aren't turning out as intended. When people try
new behaviors and do things different they often make mistakes -- in fact,
mistakes are inevitable. In typical business settings, however, mistakes are
covered up and undiscussable.
The people who tell their story in this learning history have made mistakes,
and they have also had successes. Those experiences are communicated here.
Thus, the learning history workshop seeks to create an opportunity to talk
openly about what has been learned, and to extend this discussion into its
implications for current and future issues.
When you read this document as a learning history, in preparation for a meeting
in which you can discuss its contents, we ask you to do two things.
First, consider it as a vehicle to better conversations. Read
the document in parallel with other members of your team. Plan a couple of
hours dedicated to coming together to talk about what you read and how it
applies to your current efforts (see attached "Facilitation Guidelines:
Learning History Dissemination Workshop"). As you read the learning history,
notice what triggers your emotions - surprise, joy, anger, sadness, fear and so
on - and mark those areas in the text so that you can go back to them later.
Prepare yourself for how you might talk to your colleagues about your reactions
and thoughts in reading this document.
Second, as you read, take on the mindset of a beginner. Listen
to what people say, and wonder why they said what they did. Try to suspend your
judgment; don't automatically condemn those who made mistakes, or assume you
know why mistakes occurred. Think about how a particular story is similar and
different from issues you have encountered. Come to the workshop prepared to
learn with one another the events which took place and their implications.
Come with questions that might help you understand and empathize with the
points of view that are very different than your own.
You may find yourself wanting to talk about the material in this learning
history with others before the Dissemination Workshop. However, in doing so we
ask you to consider that you are dissipating the energy you bring to the
workshop that will combine with others in collectively making sense. Later, if
you have found the learning history document and the conversation it generated
helpful, then you might want to suggest other people form groups and have
conversations after reading the learning history.
[Back to the Abbreviated Table of Contents]
Individuals in a team or organization all have different prior experiences and
attitudes. Even when they have taken part in a long mutual history, they often
perceive the events differently. In the complexity of typical business
settings, most people don't have the time, tools and common experience to
effectively compare their understanding of what happened. The learning history
dissemination workshop is a "managerial practice field" where people can come
to a shared understanding of a learning and change process.
To reach a shared understanding of a complex process, it is necessary to slow
down the conversation which people typically have in reacting to the written
document. Slowing down the conversation allows people to talk about their
perceptions of what happened, the interpretations and attributions they made of
events, and the generalizations they have for moving forward. Everyone
attending the workshop has a responsibility in creating conditions that promote
learning for themselves and others.
We suggest the following process to facilitate the Learning History workshop.
This process is meant to provide general guidelines for the flow of
conversation, not a rigid segmentation of what we talk about.
Phase One: "What happened?" and "Why?" The conversation is best
initiated when people link their comments to what is written in the learning
history. We generally ask people to describe what surprised them. Stick to key
events and descriptions, noting issues that involved learning. In particular,
where do you find yourself quickly moving to judgments, blaming people for
mistakes, wanting to "fix" things, provide expertise, or otherwise intervene in
the described situation?
As people talk, they are adding their own interpretation and attribution to
what is written. Often they may be different that what is written in the
learning history's left hand column. How is what was described similar or
different from what you experienced? Where do you have very alternate
interpretations from participants (in the right hand column) or learning
historians (in the left hand column) say? How do notes that people made in left
hand columns compare?
The facilitator will ask where it was in the text that people found themselves
reacting in different ways. He will ask exactly what words led to their
interpretations. By going back to that text, we can clarify the
perceptions and judgments people bring in their reactions from those that are
found in the learning history.
Phase Two: "So what?" and "What next?" Can generalizations and
implications be drawn from this learning history? What are the implications of
the experiences portrayed in the learning history for present initiatives? How
typical and significant are the alternative interpretations that came up in
this workshop? In this phase we link the past with the present and future.
What are the important questions for people to think about as they leave the
workshop? What are the responsibilities of people in the workshop in causing
the conditions described? Can we identify in ourselves, or help others see,
the implications of our behavior patterns that limit our options? What will
help us all move forward?
The facilitator will be helping individuals and the group consider how their
comments link to their responsibilities. What might be the causes of the
behavior patterns the group wishes would change, and what responsibility do
people have, or could they take, in bringing about desired improvements? The
facilitator will also remind the group of time boundaries so that next steps
can be planned.
[Back to the Abbreviated Table of Contents]
The organizational learning history you are about to read emerges from a unique
collaboration among practitioners, academicians and product development
professionals. It is an important document because it lays out the dilemmas,
paradoxes, and human emotions associated with teamwork in today's complex
organizations. Our future will most certainly depend on how well we learn to
manage conflicting needs in large systems.
This study is more about learning how to learn, than about the nuts and bolts
associated with designing and building great automobiles. More often than not
you'll conclude it's not about who is right or wrong, but about a world of
perception and interpretation. For me, this is a human story because it
reveals how different attitudes, beliefs, and assumptions rise to the surface,
and may rule the day.
What's especially revealing is how the product development function is
demystified as an exact science of equations, engineering procedures, and
computer-driven technology. Instead, you'll find dedicated people at all levels
relentlessly seeking alignment, recognition, and assurances that the day's
effort will yield value-added results over chaos and self-interest. This
dedication also requires a balanced perspective. We can be extremely efficient
by way of quality, cost, timing, and flexibility. But, these objectives must
be in service to the customer. Outstanding teams of the future will need to
balance multiple initiatives more than ever before.
For me, this learning history is about a beginning, not an end. We are
building on what we've learned with this first MIT effort by applying the
methods and tools in two other vehicle programs. Additionally, there are many
organizational learning projects going on in the Company outside of product
development. Perhaps this will enable us to see the connections among all
these efforts and move to yet another new level of understanding.
Senior Vice President -- Product Development
[Back to the Abbreviated Table of Contents]
We believe that their experience has three main lessons for managers at their
company, AutoCo, and in the rest of industry:
That's why even a busy manager or executive might find it useful to read the
eighty-page historical account of another group's change effort. By seeing the
struggles, doubts, misunderstandings, and varied points of view of the Epsilon
project, as told in participants' own words, you might get a sense of
what would be necessary to promote higher performance in your own projects.
What worked for Epsilon might not necessarily work for you, but the general
attitude toward exploration, and some of the inter-management dynamics, seem
fairly universal.
When executives gave final approval for Epsilon's development budget, in which
styling, market positioning, and expenditures were set, the program was already
many weeks behind schedule. At the same time, "process improvement" as an
endeavor was beginning to gain importance and attention at AutoCo. Making a
great car wasn't enough; you also had to improve AutoCo's process capabilities.
Seeking a better process for developing vehicles, the Epsilon researchers
explored tools and techniques gleaned from the work of MIT's Center for
Organizational Learning. They integrated program management and training
together, so that all work on the car might involve systems thinking and
collaboration. Early efforts were focused on bridging the barriers between
functions: creating a shared vision of the new vehicle, collocating engineers
in one large multi-functional building, and bringing design engineers into the
market research process at an early stage. As the team progressed, its vehicle
development metrics went from low initial scores to setting new company records
for prototype-build parts availability and quality.
The Epsilon program completed its assignment at the end of 1994. The vehicle
launch, which took place a week earlier than scheduled, was truly a
"non-event," without the crisis atmosphere that normally leads to legions of
engineers camping out at the manufacturing plant. However, the Epsilon results
also included controversy. The launch coincided with organizational changes at
AutoCo, in which Epsilon team leaders did not receive accolades for their
accomplishments. As team members were assigned to new positions, some wondered
if their efforts were valued or appreciated. Yes, they had broken performance
records; but they had also broken some behavioral norms. For example, reports
of problems had been deliberately brought to the surface earlier than usual.
This had saved money and improved quality in the long run, but had also led to
the appearance that the Epsilon program was "out of control."
What would another team need to repeat Epsilon's success -- and avoid its
failures -- in the future? We believe the learning history shows that one of
the greatest single factors was this: Epsilon's leaders designed their work as
a learning process. Reading the learning history, you will see a sense of
humility and mutual engagement at work. Team members recognized that they had
endemic problems which went beyond strict engineering issues, into issues of
organizational communication. They also recognized that no one on the team had
all the answers. Answers would have to emerge from the give-and-take between
members of the team. The learning labs, which brought people together to work
on Epsilon-related issues in an atmosphere of systemic understanding and
dialogue, were powerful precisely because they codified the sense that, "We're
all in it together, because we are all connected together."
Organizational learning is a process of collective sense-making. You don't just
produce results; you produce a "theory of how you got there." If Epsilon's
participants seem uncommonly reflective for auto engineers, that is not merely
a result of the learning history effort, which asked them to look backward. It
also stemmed from their work on the team, and also, arguably, from the new
atmosphere at AutoCo. At least officially, if not yet in complete practice, a
manager's ability to create results depends on combining technical expertise
with the ability to navigate past the stumbling blocks of "control management"
and the functional hierarchies.
Some critical ideas from the themes of the AutoCo Learning History
This learning history is organized by the key concepts, or themes, which
were important areas in describing and explaining the Epsilon program's
achievements (see "Noticeable Results" on page for specific measurable
accomplishments).
Lesson 1: Bring the senior members of the team together in cross-functional,
"shared vision" meetings a long time before the rest of the effort begins, so
that they can design the evolution of the process together.
Lesson 2: For senior leaders, "walking the talk" is not a trivial matter. It
will require concerted effort and mutual partnership. But it will make a huge
difference.
Lesson 3: "Learning labs" may use a variety of techniques, including
computer simulations, but the key principle is inviting more in-depth
conversation, across functional boundaries, on business-related issues in a
risk-free setting accessible to all.
Lesson 4: The success of even the "hardest" engineering prototypes depended on
cultivating "softer" skills of involving people and managing the flow of
information among them.
Lesson 5: An atmosphere which encourages experimentation, particularly across
traditional boundaries, leads to benefits that the senior leaders can't
necessarily predict or plan for.
Lesson 6: An innovative team like Epsilon needs an advocacy from above that
fulfills both a spirit of mentoring and provides counsel on how to handle
larger system implications.
What kind of knowledge can an organization develop so that it can reliably
reproduce excellent results? An organization needs more than conventional
"lessons-learned" or technical knowledge. And it also needs more than the tacit
knowledge, kept below the surface, of "how things are done around here" -- the
knowledge which unknowingly influences collective behaviors.
An organization needs "actionable knowledge" --
knowledge that covers generally tacit issues such as relationships and working
habits, that are brought to the surface, examined collaboratively, and
communicated. Such knowledge is part of the system which leads to success or
failure; it provides the key for repeating successes and avoiding failures. By
drawing on the concrete experiences of the Epsilon team, this learning history
is designed to bring forth conversations in other teams which can bring forth a
knowledge that helps them learn and function more effectively. (Some initial
questions for moving forward with learning initiatives, to be considered and
discussed after reading this history, are framed in the "Appendix" section on
page .)
The leaders of the Epsilon Program worked to change their style first. Only
then did they encourage other people to change their styles. The general
expectation had been that the learning labs and use of learning tools would be
the critical factor that influenced behavior. Instead, we of the learning
history team heard again and again that the changes in senior managers'
personal behavior was a critical force. This change in behavior among the
Epsilon team leaders allowed others on the team to change, be more open, and
share their difficulties and mistakes rather than avoid embarrassing
situations. That openness, in turn, gave Epsilon its capability for quality,
its flexibility, and its inspiring atmosphere.
[Back to the Abbreviated Table of Contents]
The name of the company, AutoCo, is a pseudonym for an automobile company.
Epsilon is also a fictional project name, as are all other formal names used in
this document. People in the learning history are identified only by their
titles. The company, program, and people are disguised to provide anonymity,
protect AutoCo's need for confidentiality, minimize distraction and help the
reader to focus his or her attention on the universal themes herein.
This document was written by a small "learning historian" team composed of
people from AutoCo and from MIT. We developed the learning history in the hope
that it could help other teams and individuals at AutoCo, and other companies,
to benefit from this program's experience.
A learning history is a new format for presenting the story of a project. It is
designed to portray the project as participants experienced it, and to invite
readers to draw their own conclusions. In this history we make the
"sense-making process" visible -- we report not just what people did,
but how they interpreted events around them and what reasoning led to their
decisions. To gather this information, we interviewed over fifty individuals.
The interviewees included engineers, process leaders, content leaders (see
Sidebar: "Content leaders" and "process leaders" page ), and managers at all
levels and functions within the Epsilon team, along with suppliers, engineers
from other functions, senior AutoCo management, and other key figures at
AutoCo. We also reviewed transcripts of meetings, interviews, program
documents, and speeches given by key participants during the program. People's
perspectives and attitudes varied; we have made an explicit effort to include
as wide a range of points of view as possible.
[1]
The value of this document depends on the conversation it generates: How can
AutoCo's Epsilon experience provide a useful example for your team or
project? We ask readers to suspend their assumptions -- about automobile
companies, management, engineering, and all other aspects of vehicle production
-- so that they can focus on what happened, how people described events, how
they felt and what their attributions were.
The learning history report starts with an overview, and then there is a
chapter describing the origins of the Epsilon learning effort. (The critical
events and observable measures which provide data on how the Epsilon program
progressed, "Noticeable Results" are listed at the end of this document, on
page .) The subsequent sections represent themes -- key concepts which
represent the underlying significance of this project, and which emerged from a
close reading and examination of the materials collected in our research. We
present each of these themes in the form of a "jointly-told tale," separating
the researchers' comments from participants' narrative. There are four
different types of material in these "jointly-told tales:"
Footnotes
The learning history team used a grounded theory, qualitative data analysis
methodology to discern key concepts and patterns. See Strauss, 1987, Qualitative
Analysis for Social Scientists; Corbin and Strauss, 1990, Basics of Qualitative
Research; Miles and Huberman, 1994, Qualitative Data Analysis, and Glaser and
Strauss, 1967, The Discovery of Grounded Theory. In analyzing of large
quantities of qualitative data with a team of inside and outside learning
historians, we have found it helpful to think in terms of meeting three
"imperatives" -- research (loyalty to the "data"), mythic (loyalty to the "story"),
and pragmatic (loyalty to the audience's needs). Each of these imperatives
represents a set of "pure" priorities -- all important, and all in contention
with each other. They can't be approached simultaneously. They are attended
to in sequence, but there must be deliberate, balanced consideration of all
three, in every phase of a learning history effort.
[Back]
ATTENTION: The Learning History Disclaimer
You can read the following learning history the way you would read an ordinary
report. However, if you read it that way, we do not believe that it will
provide the intended value. Facilitation Guidelines: Learning History Dissemination Workshop
These
are the general guidelines we suggest for discussing a learning history.
To make use of the experience captured in a learning history, readers of a
learning history need to come together and openly and honestly discuss their
reactions to the stories and what lessons it holds for them. Forward
AutoCoExecutive Summary
This is the story of a group of 300 people, the Epsilon program management
team, charged with meeting the typical "tight" deadlines to get a vehicle out
the door. They resolved to do it without the costly, hectic, last-minute
"heroic" efforts that had dominated most automobile launches in the past. They
discovered, along the way, that this meant not just developing new management
techniques and a "systemic" understanding of their work, but recreating their
interrelationships with each other, and with the rest of the company.
It's easy to simply state these premises. And they seem reasonable; even
self-evident. But how do you get people to put them into practice?
Third, the analytic tools provided techniques for taking the
philosophy and putting it into action. Managers "taught their talk" in
innovative managerial practice field sessions for program engineers.
The fifth theme examines the partnerships that were
created
-- functionally based people were drawn together in ways that bridged
differences and focused on action with collaboration.
Preface
This document is a learning history of collaborative efforts undertaken by
AutoCo and the Massachusetts Institute of Technology Sloan School of Management
Center for Organizational Learning. These efforts took place between 1991 and
1994 on the Epsilon vehicle development program. The project's objective was:
To develop and study learning capabilities in a product development team of
more than 300 people, while having a positive impact on business results. The
purpose of this document is to report on those efforts and create materials
from which other interested teams might learn.
In reading the two column format of the "jointly-told" tale sections, you will
find yourself having to make a choice. Which column do you read first? Do you
skip back and forth, and when do you do so? There are no "rules" for reading a
learning history; different people read segments in different orders. As you
make your way through the story, however, please pay attention to your own
reactions. How credible do you find the story? How would you have dealt with
the problems that faced the Epsilon team? How can their experience help inform
the decisions that you (and your associates) have to make in the future? It is
through the discussion and dialogue with colleagues, about the contents of this
document, that we believe your own and your team's learning will best be
served.
-- AutoCo Epsilon Learning History Team
Five internal AutoCo
team members
George Roth & Art Kleiner
|
Note how seeds were sown for some time before a project opportunity emerged at
AutoCo. The company "pulled" the effort in, rather than being "sold" a bill of
goods.
As at other large companies, AutoCo internal "change agents" had to consciously decide between a "bottom-up" or "top-down" approach in any given initiative. From the beginning, this effort took the "bottom-up" approach. This meant it would be easier to implement, but harder to expand to fit the larger AutoCo system. Note how this very concrete learning effort begins with three abstract "governing ideas." It's not clear to outsiders whether a concept like "thinking differently" meant the same thing to different AutoCo managers and executives. |
AU Manager: We had just finished our first executive education program for
the top 2000 people worldwide. It was a gathering from the four corners of the
world, and it was quite a happening. The question was, what should be in the
second round?
We decided on a "bubble-up" rather than "top-down" model. We went around the world and interviewed executives and asked them what was on their minds. What would be of the greatest interest to them? Three issues surfaced: globalization, thinking differently and leadership. Underlying the first two issues was the pervasive issue of change. We then went about exploring what would be a senior executive program built around these three themes. There was controversy in presenting them to the top of the house because the top felt they might not be ready to get into all this subject matter. Nevertheless, they said, "press forward." |
|
AutoCo called upon well known academics and consultants as part of an
education program for senior managers. Each issue had its own leading "expert,"
with the exception of systems thinking, which had two strong voices:
Peter Senge and Russell Ackoff.
These two experts held, in common, the view that an organization's work could not be understood in fragments. AutoCo's managers responded to this message because it helped with the perennial problem of miscommunication and conflict between functions. Intellectually thought provoking and personally compelling, but very abstract, the ideas in systems thinking were flavored by their academic origins. AutoCo managers were intrigued but they challenged the academic stance by asking, "How are these abstract concepts applied?" |
In the arena of "thinking differently," we came across two outstanding voices:
Peter Senge and Russ Ackoff. The more we dug into the area, the more we found
a very significant message coming out of Senge's and Ackoff's world views.
By late 1989, early 1990, we had both Senge and Ackoff doing a program at our center every other week. In our analysis of participants' reactions, there was a large voice saying, "The ideas are intriguing, but I don't see how I would play them out in my ballpark -- on Monday morning!" In all fairness, we had asked both Senge and Ackoff to take us on a broad journey, and not to focus specifically on application. It's not surprising that participants were intrigued with it, and saw its depth, but they were right in feeling that there needed to be an ability to see further down that chain of, "What happens next?" |
|
The AU Manager took the response of senior executives as a challenge to
find a way to operationalize systems thinking throughout AutoCo.
The comments people asked about application led to their being critically challenged.
|
That's when I formulated the challenge for myself and AutoCo University to
continue to pursue this subject area. I had the good fortune to be able to sit
in on numerous sessions with Peter and Russ, and in the fifth or sixth session,
the ball bearings started to rotate in unison.
I asked Ackoff publicly, "Russ, I've been sitting here for several sessions, it's an outstanding message, but I'm still having trouble digesting it and its implications." Russ turned to me and said, "Well, that's because you'll never get it." I turned beet red. Here I was standing in front of 50 executives, and the room was dead silent. Then Russ let me off the hook. He turned to the group, and said, "And you won't get it, either. We have built up over 400 years of methodology of 'reductionist' thinking. It is so powerful, so pervasive, that probably your children and their children will have a much easier time. For you folks, it's going to be tough grind." Down to my socks, I understood that you can say you understand it, and still not understand it. The implications were absolutely profound. Organizational learning didn't mean letting go of analytical processes. It meant complementing and supplementing them with synthesis or systems thinking. It's not such a clean thing -- "Just throw out all the traditional tools, my past life -- and switch into new formulas." It means learning something in addition: the "and," not the "or." |
AutoCo's introduction to systems thinking thus represented a challenge: How could the organization make use of systems thinking in a business context?
In 1991 a diverse group of AutoCo managers attended a series of five two-day training sessions on the core competencies of a learning organization run by the founding staff from the Center for Organizational Learning. To the surprise of the AU manager, given the abstract nature of the materials, the first audience exposed to the concepts was receptive. This audience was composed, in part, of managers from product development. In particular, the Epsilon Program Launch Manager expressed keen interest. He was responsible for the vehicle development program to design and build the next model of the Epsilon luxury car.
|
Past experiences in developing cars were powerful influences in trying to
create a better approach on the Epsilon program.
Do the ways in which success is achieved in large corporations have to have task oriented, replicable type answers to be accepted? |
Launch manager: I had worked on the Delta program [another vehicle program]
for several years as the Business Planner and Launch Manager.
We had discovered, a year before Job One, that the program was 17 months
behind schedule. So we quickly organized a 100-person launch team and we
put the program back on schedule, with quality that was better than the
first car. We met all of our program objectives except cost, which we knew
from the beginning we could not meet.
I remember a meeting where a Vice President listened to us present the reasons for our success [on the Delta program]: team leadership, and the fact that everyone had the same goals and knew that they depended on each other. "That sounds really great," he said, "but what did you do?" He finally said it must have been a fluke, and that was the end of it. There was no learning from the experience. It bothered me a great deal. AutoCo is in love with managing by crisis; without a crisis, we don't know what to do. I resolved to learn how to produce a car launch without a crisis. |
In July 1991, the AU Manager, along with an internal consultant working with the Launch Manager, wrote a letter to Peter Senge, director of the MIT Center for Organizational Learning. They requested an active relationship between MIT researchers and the Epsilon Program.
Project Engagement Clinic
The formal partnership between the two organizations started with a project "engagement" clinic in September, 1991. The goal of this clinic was to engage one another in asking difficult questions about readiness for learning, and explore possibilities for a partnership which sought business improvements and research results. Attending the meeting were the key people in the project -- the Program Manager, Launch Manager, and Body Engineering Manager for the Epsilon Program, two internal consultants on process improvement (who were to integrate systems thinking at AutoCo) and five researchers associated with the MIT Center for Organizational Learning. One researcher had visited AutoCo and conducted interviews in advance.
These interviews were summarized in a report that singled out several key issues:
- The Launch Manager wanted the MIT project to focus on improvements in the
Evaluation Prototype [EP]. If the EP could be made to "work" as it should, the
car would be successful, he said. He wanted to create a climate within the team
which reinforced more effective cross-functional communication, more
responsibility for objectives, and less "games-playing."
- The Epsilon Program Manager (the Launch Manager's boss, with overall
responsibility for the Epsilon project) believed that concentrating on one
prototype, like the EP, was too narrow. He felt it was necessary to look at
AutoCo's product development paradigm. Present product development management
practices controlled resources ineffectively, treated suppliers with
indifference or hostility, and had a history of not achieving quality, cost and
time objectives. The Program Manager mentioned the inability of a program to
reach a point where management could say, "Enough changes this time."
- AutoCo's vehicle program management needed to see tangible improvement. The
new product development program officially involved a 48-month time period,
which was compressed to 42 months, and had very ambitious deadlines. Chronic
dependency on "heroic" efforts took key people away from the planned product
development process. Some people felt certain that it was just a question of
time before a real crisis became obvious.
- MIT's researchers wanted the project to further the investigations being done
in the Center for Organizational Learning. Supporting research would require
more than a relationship where MIT played the role of expert consultant and
AutoCo took the role of client. Instead, both organizations would have to
collaborate in a systemic approach to improving the product development
management practices and understanding the results that were achieved.
Measurement would be important in determining if improvements occurred over
time.
Sidebar: What are "learning laboratories"? |
||
|
||
| For more about the learning labs at Epsilon, see Theme 3: Learning labs: Teaching techniques for thinking differently. For theoretical information on designing managerial practice fields and learning labs see Kim and Senge, "Putting Systems Thinking into Practice" in System Dynamics Review, 1994, Vol. 10, Nos. 2-3, pp. 277-290. |
After meeting for eight months, the core learning team designed a series of learning laboratories, through which engineers on the program were to learn and apply techniques of systems thinking, working with mental models, and team learning. Those learning laboratories took place in September of 1992 and February, May and August of 1993. The efforts of the Epsilon program to apply organizational learning concepts spanned the following three years.
[Back to the Abbreviated Table of Contents]
Theme 1: Hard results, soft concerns
When the Program Manager was appointed as manager of the Epsilon program, his
ambition was to develop an excellent vehicle and a process which
valued and inspired people on the team. This section describes the challenge
facing
Epsilon: To achieve "hard" results (producing high-quality technical parts,
sub-assemblies, and a complete vehicle efficiently) through an emphasis on
concepts that many people termed "soft" (good communication, openness, honesty
and trust.)
Learning in the core team (Jan. 1992 - Sept. 1992)
The core "learning" team began with an awareness that they faced "real internal
conflicts." The Epsilon program was unofficially expected to be a
"Lexus-fighter at the price of an [American luxury car]," although as a
front-wheel drive car with its planned variable costs, it would be difficult to
compete with the Lexus.
The core team members all felt a high level of frustration, and a sense of urgency, since the program was already late. They recognized the dilemma of being a pilot learning project; they could already see that their effort might mean "taking on" AutoCo's overarching culture. This culture included a strong reliance on hierarchy and functional authority -- an expectation that the boss is on top of technical details and makes decisions. On top of that, the core team members had difficulty communicating with each other. "I couldn't talk to [the Finance Manager] at first," the Program Manager noted, "in less than a high-decibel range."
At the beginning of 1992, the core team met every one or two months, working with a variety of communication and conceptualization techniques such as the ladder of inference, the left-hand column, role-playing, and system mapping (see systems archetypes and "ladder of inference" and "left-hand column" sidebars on these pages). Their ability to communicate improved, and they began to focus in on their most serious problems.
To give them a broader perspective, several members of the core team interviewed a dozen people from the rest of the Epsilon project, asking: What did people feel their greatest challenges and strengths to be? The team returned for a working session in March of 1992, ready to pick two or three problems and start fixing them immediately.
The lead MIT Researcher reported his impressions of the team: bright people, burdened with frustration and puzzlement but not resignation. The interpersonal dynamics typical in a product development environment were evident in this program.
| The comments of the researcher were typical of the ways managers from different functional areas talked about and reacted to one another in AutoCo. | Researcher: The participants had locked horns and couldn't get anywhere. [The Launch Manager] told me much later in the process that [the Program Manager] was ready to hang it up after a few months. But he saw enough value to keep him going. In one critical incident, early in the sessions, we used a ladder of inference and left-hand/right-hand column exercise to begin to look at the ways in which finance and program management couldn't communicate. |
|
Using tools to understand one another's positions allowed people from
different
functional backgrounds to work together more productively.
The Learning Organization work assumed that openness of communications, and the willingness to address assumptions, would lead to workplace efficiencies and effectiveness. How valid is this assumption? |
The exercises opened things up so that they could really look at their
assumptions.
Program management revealed how they assumed that the finance people "want to
hold us to [American automobile] costs." Essentially, program management
thought that finance didn't have a clue (and didn't care) about what it took
to build a car. "They just want to meet the numbers."
The finance people showed their assumptions about the program managers: "These program guys don't care about costs. They don't want to work to get to the kind of car that we said we were going to do. They won't control costs." |
| If people could see issues from one another's perspectives
would it allow them to work better together? A sound logical argument was necessary to convince the team to apply the tools in the service of improving their abilities to work together. |
I said, "Look, we're here to do something different from the way you continually do things." Instead of having a normal "let's-solve-it" style consulting project, I suggested that we "try to understand our own assessments of the problem. We are blind to the limitations of our assessments, and thus we can never see what is really happening. Yet we design solutions based on our own individual assessments." The core team members understood that argument, and went along with another round of experimentation. |
|
Tools from Total Quality Management were used. A learning tool is one which
people share with one another to work more effectively together. Learning tools
are spread freely to create shared insights, not used by one person to gain an
understanding which he or she uses to manipulate or change others.
See affinity diagram sidebar. The "KJ diagram" combines the intellectual-rational thought process with intuitive-emotional feeling data. It is generally used to process a group's own thoughts and observations; here, they used it to make sense of their interviews. | I had them break up into two groups (because there were so many of us) and each group did a "K.J." We used the technique to sort through the information gathered from inter-viewing Epsilon team members. "Listen to what you think people are trying to say," I said. "Get away from thinking only rationally about the comments. How do they feel to you?" We went through a "scrubbing" process [rewriting the statements to be clear], then grouped them intuitively. This is usually a very frustrating and bewildering process, especially for an engineering or action-oriented group, because everything is interconnected and diffuse. |
| The K.J. diagram incorporates multiple people and multiple perspectives and appeared to have brought to the surface an interrelated and interdependent set of problems. | Our theme question was, "What is the biggest weakness with our product development process?" And the overarching answer that emerged had to do with lack of trust and openness. This was unspoken before this point, and I think it wouldn't have been captured otherwise. |
| The researcher focused on problem articulation rather than problem solution (see Sidebar: Problem solutions, versus problem articulation). | Now they couldn't accuse me of "making them" pay attention to this
trust issue. They had seen firsthand, how it was at the core of their own
problems.
This incident made a lasting impression on [the Program Manager], and changed the dynamics of the relationship with Finance, which was very important. |
| Are these three key issues important on any product launch? Are they endemic to the product development process? Do they stem from AutoCo culture? Are they worth taking time to deal with? |
Program Manager: There were really only a few core issues. The rest of the
problems all generated from those.
|
The system map (Learning Team Meeting, August, 1992)
Now the "core learning team" engaged in a "systems mapping" process, to connect
the concerns of trust and openness that had surfaced in the K.J. diagram with
other symptoms in product development, such as the chronic critical problem of
late parts.
|
See the core team's view of "parts behind
schedule."
Focusing on one key problem -- in this case lateness of parts -- again showed the interrelatedness and interdependencies of all the problems facing the team. |
Program Manager: We weren't sure what to do next. We didn't know how to "change" fear or mistrust. So we started to look at a key problem: Why we were always late. No matter what we did, no matter how we approached the problem, parts were chronically behind schedule. We began to share our views about why. Over the course of a day, we built up a diagram of the system. |
| The K.J. and causal loop diagrams appear to have not only influenced how people thought about the problems, but also their perception of problem symptoms. | When one engineer changes parts, that part usually affects somebody else. The "A" engineers can't start part of their work until the "B" engineers solve their problem. Parts get late. This leads to pressure to get back on schedule, so we compress the supplier time. But then something else would become late, because we would be putting all our resources on the part that was late. When parts get so late that we can't recover, we revise the build schedule. Then people feel they have more time, so more parts get late. Worse still, the next time you have a build, people will assume you're just going to revise the schedule again, so they don't even try to meet the dates. |
|
How can a team effectively build a group understanding of a systemic issue,
so all members "own" that understanding?
This story of the finance manager's role was often repeated to illustrate how the system dynamics work is valuable to a cross-functional team. Finance people typically don't get involved in engineering change processes; here, that involvement helped build a deeper understanding of systemic issues. The researchers proposed that a shared image of the system would allow people to operate in a coordinated fashion. The hierarchical and autocratic management culture at AutoCo reinforced the engineering culture to limit discussions of problems until there were known solutions. |
We eventually got all this into a complex chart. We all understood the whole
system as it related to us, and we had all contributed to this map.
The map became critical. And the person who pointed out the key leverage point wasn't an engineer, a development manager, or a planning manager. It was the finance manager. She pointed out that just before the "reporting of lateness," there's usually a delay. The reason for the delay is: people are afraid to be criticized. There is a basic cultural commandment in engineering -- don't tell someone you have a problem unless you have the solution. You're supposed to solve it -- and then tell them. But during that delay, nobody knows about the problem, and nobody can react. That delay automatically compounds delays in other loops going on through the system. |
| The systems map was described by most people as enormously useful. When a group "sees the same picture, and comes to the same conclusion," is it the visual (like the system map) that helps them focus on issues systematically? Or is it the conceptual link? | Program Manager: We all saw the same picture, and we all came
to the same conclusion: This was a leverage point for us. We began to look
at how we could structure the project to ease that delay, and we concluded
that our real leverage was in improving the communication process,
improving honesty, and improving trust.
We had begun to build these in the core team, but they didn't exist between the functional groups in the rest of the team. But we knew that building trust was possible, because, after all, if we hadn't shared our views of the system honestly, we would never have gotten to this point. |
| Another factor accelerating the decision to promote open communication was the increasing complexity of automotive technology, particularly with fast-changing subsystems such as the electrical system. The better the team became at working together, the better it would deal with intricate components which cut across two or more functional roles. | Program Manager: Only a small [percentage] of the members of the team actually worked for me, where I could promote them and give them their performance reviews. Most of them worked for other functional organizations -- finance, assembly, body engineering, climate control, plastics. If I just pulled the team together the normal way I would get what we always get. People would protect the objectives of their organization. They would work on the product, but their organization would come first. My greatest leverage was to make them view the other members of the team as people with whom they had a personal relationship. If I could make them feel that they depended on each other, and that they wanted to help each other as people, that would counterbalance the material reward from their functional organization. |
| Was the statement that "we don't know how to make open communication work" a barrier which kept people from believing in the possibility of open communication? | We had been talking about open, honest communication around this company for as long as I've been here and I've been here 29 years now. We don't know how to do it. This was the first time I thought it might really work. |
The transition to openness
Converting to an atmosphere of honesty and trust was an ongoing process, with
many setbacks, continuing throughout the forty-two month program.
|
A premise of the learning organization is that the boss isn't the one with
the answers. Bosses are teachers and coaches who help others learn and apply
their learning.
What model of teachers are they using? Teachers of children? Or, teachers of adults? Manager's prerogative is typically that of being the decision-maker. Making those decisions was thought of as creating a codependency between manager and employee -- employees look to managers for decisions and managers expect they make the decisions. To the Program Manager and the Launch Manager, "empowerment" meant the recognition that engineers (and others on the team) needed to make decisions and feel responsible for those decisions. The launch manager saw the group's behavior as "dysfunctional." But how "functional" was it within the context of the larger AutoCo culture? |
Launch Manager: In one of our earliest design reviews in February, 1991, folks
were standing around saying, "What do you want us to do?"
I said, "Wait a second. You're the engineer. What do you think is the right thing to do for the customer and for the company? What is your recommendation?" They couldn't answer that question. I realized then that this team needed a lot of help. They were accustomed to putting all the alternatives together and the planning manager or Program Manager would decide. I knew I had the prerogative, based on my experience and knowledge, to tell people what should be done. But I told them I would reserve that prerogative for when I was willing to challenge them. I didn't want to make decisions that they should be making. I realized over a period of time, that AutoCo wanted to "empower" its teams, but on this team, people didn't feel empowered to do anything. That was our first realization that this was a dysfunctional group, probably very typical of most groups. |
| Involving people in making decisions implies that leaders make their reasoning process explicit or, as in this case, justify it as "reasonable." | Content leader: Every once in a while we bosses have to grit our teeth and swallow a decision that the team made, even if we personally think, "Well I'd rather not go on that path." If their thinking is reasonable enough, and they haven't missed any obvious issues, then my objection is just a matter of: "I would go the other way." |
|
The behaviors associated with letting people make their own decisions can
appear messy to outsiders -- not the calm where a boss calls the shots and
all the action occurs below the surface.
|
Launch Manager: A new project manager, after sitting on a very typical
discussion,
ran up to one of my team leaders and said, "My God, your program is a
disaster. You're not going to make it."
The team leader said, "No, this is the way we always talk. Everything that we know is thrown on the table. We thrash about, and issues sound a lot worse than they really are. This is our way of sharing what's going on." The project manager said, "You've got to be kidding me. If anybody had said anything remotely like that on [my previous program], he would've been killed. Problems would have to reach a level of disaster before people would ever talk candidly." |
| Engineer: Every day someone comes in and says, "That was a really stupid thing you said in that meeting the other day. We all talked about it and we think this..." I may say, "Yeah, you guys are right," or maybe I don't agree. But at least nobody has any problem coming in and saying, "I don't agree with what you said," or "Other people think this," or "You didn't think about that." And it helps. | |
| These comments are typical of the remarks made by engineers about trust and openness; they were gathered throughout the stages of the car project. | Engineer: When an engineer goes on vacation we cover for him. We all work as one, which I think would be pretty unusual in most other jobs. |
| Engineer: You don't hear dialog like, "People from body engineering are dragging their feet," or "Those hard noses from Assembly." We got that out of the way up front. Now we can get together and do the job. |
Creating the atmosphere of trust and cooperation
Based on interview data, the following factors appear to be important in
creating an atmosphere which leads to trust and cooperation. These factors
related to behaviors which the core team sought to practice throughout the
program. Each point is described and illustrated in a section which follows.
- A mandate that "bearing bad tidings" would be safe;
- Ongoing sharing of information and perspective;
- A culture of greater inclusiveness;
- Deliberate encouragement of informality and friendship;
- A mindset that "no one has all the answers."
- Leaders who modeled the desired behavior;
- The conversational tools of the learning lab;
- Collocation*.
A mandate that "bearing bad tidings" would be safe
The Epsilon leaders had to start by mandating that there would be no punishment
for candor, bringing in bad news, or raising uncomfortable questions.
|
How does a team effectively change its culture from one that expects
everyone to "have the answers" to one that encourages people to experiment
and raise issues before the answers are certain?
This comment was one of many illustrating how engineers came up with and contributed new ideas because they felt they would be heard. |
Content leader: If people know that they're not going to get punished
(for taking risks), they'll try harder. We had all kinds of ideas coming out
of the woodwork that people had been keeping in their hip pockets. The net
we use for umbrella storage was an idea of one of the engineers.
Engineers [on other projects] don't generate ideas like that; they wait for you to tell them what to do, so if it screws up they can say it wasn't their idea. |
|
Does admitting that as the boss you don't know the answers help?
If the boss doesn't know an answer, how would that evaluation affect the engineers? |
Team leader: [The Program Manager] always gave us a strong feeling that he wouldn't treat you like you were an idiot if you didn't know the answer. Or if you came to him for help, he would try to help. |
Ongoing sharing of information and perspective
Taking the time to share information from different aspects of the development process with a broad range of people appears to have created greater awareness of program issues as a whole. Efforts were made for people to become aware of everyone's role in light of the overall program goals.
| One of the questions the managers considered was whether taking the time to share information broadly could be made up by people working more effectively together? | Finance Manager: We had a better understanding of why each of us does what we do. This understanding was helpful in the long term, because it gave us a base of trust and understanding. I think it started to reduce people's sensitivities a little bit. You understand why something happened. If it wasn't necessarily what you liked to happen, at least you understood why. |
| Could managers sharing more openly result in others sharing their information more openly, countering a larger cultural tendency to hide problems? | Internal consultant: When a supplier has a good relationship with the engineers, the supplier will say things like [for example], "You didn't hear it from me, but something is going to be late and somebody's lying to you. Don't tell anyone I told you." |
A culture of greater inclusiveness
Including people, not just on the basis of who needs to know to do their job,
appears to have created an atmosphere where people were more aware of the whole
of what they were trying to achieve.
|
Team work was a much talked about concept at AutoCo. However, there were no
common standards or definitions of team work, and it was often managers promoting
their management style that led to contests over who had created effective teams.
|
Content leader: I think if you talk to any [Epsilon team member], they'll
say, "Oh yeah, we've got fantastic team work." Well, every program's got
team work.
On this program, [the Program Manager] provided a strong network for team work. He allowed it to happen easily. It's more than just collocation or expertise. For instance, take the EP prototype build; chassis engineering was given credit for having 100% of their parts there, and that was the first time something like that has been accomplished. And that says a lot about the strength of the engineering community as well as others who helped with that endeavor. It's like every day you're putting on your Epsilon suit and you're going in there and you're going to make a difference. [The Program Manager] made the program very, very inclusive. He was adamant about having suppliers in there for [internal prototype meetings]. The meetings up front were pretty boring but Epsilon seemed to achieve their success because of the meetings. |
Deliberate
encouragement of informality and friendship
Some attributed the quality of the Epsilon team process (at least through first
production prototype [1PP]) to collocation. Some attributed it to the people
who had been chosen for the team, and the quality of the engineers. Others
argued that the team appointment process was random; indeed, Epsilon probably
didn't get the "best" engineers, who would have gone to a higher-visibility
product like
Theta [1] or Sigma. No matter the cause, there was
an atmosphere of informality and friendliness which promoted good working
relationships among team members. Managers invested in and sought to actively
encourage the development of a climate which allowed people to work more
informally with one another.
|
Off site meetings where people were in residence were typically frowned
upon at AutoCo because of cost implications.
The time and effort the core team put into developing relationship and open communication was not valued by all team members. |
Engineer: There was a three-day off-site [Oct. 1991], where you basically had to walk away from your desk, designs and drawings. A lot of the team thought it was a waste of time; I think a lot of people walked away still not exactly sure what [the Launch Manager] and [the Program Manager] were trying to do. To me, the most critical thing that happened there was it really glued the team together. It was the first time everybody looked around and really realized they were all in this boat together, and it was powerful. |
|
How important is it to develop a focus on the personal as well as the
professional relationship?
|
Some of the dynamics and camaraderie and friendship came from living together at the hotel for three days, eating together, working together, and going and having a beer together. There's something about friendship outside of the work place that I think really helps build trust. If you met new people and had a beer with them or whatever, then two months later if you had a problem with an issue on the job you felt a little bit more comfortable approaching them. And I think it's human nature that if you get an opportunity to know a little bit more about a person's family and their interests outside of work, you trust them more than a total stranger. At the off-site we started talking about visions, and what the car was going to be, and everybody's roles and I think it created the bond. It was a reality check: This group of people was going to build this car and either make it a success or not. |
A mindset that "no one has all the answers"
The managers told people that they didn't know. They needed to learn too, and
they needed to create the conditions where their teams could learn. This
statement supporting "not knowing," ran counter to the expectations most
managers and engineers held -- of one another, their system, and themselves.
| How can business culture learn to acknowledge and accept mistakes in a constructive way? |
Vehicle development team leader: This was foreign to a certain degree; it
was uncomfortable that the boss was learning with us. He didn't have the
answers. We were going to do this together. As uncomfortable as it was
on one hand, it was exciting on the other, because all of a sudden we
felt like we were paving new ground. We weren't just being fed "the
right thing to do in a corporate environment today."
Some of the appeal may have to do with the word "failure." If you stumbled, it wasn't perceived by [the Program Manager] as a failure. Instead, the reaction was: "It was a good honest effort, I appreciate your energies, and what have we learned from this?" |
Behavioral versus technical: a zero-sum game?
As the Epsilon program developed, the core team placed strong emphasis on what
they called "process" issues --explicitly learning how to improve human
communication skills, decision making methods, and understanding of each
others' points of view. This emphasis on behavioral considerations--people and
process--was neither familiar nor well understood in AutoCo, which has a
heritage of strong technical and engineering achievement. In the larger company
culture, most people felt that time was scarce and thus needed to be invested,
as much as possible, in technology and engineering.
These thoughts about time were based on an implicit assumption that behavioral and technical skills were caught in a zero-sum game; one could only be improved at the expense of the other. In contrast, the Epsilon team leaders believed that a well-designed learning process would result in engineering and people skills reinforcing each other. Technological capabilities could be more easily applied, and have greater impact, as engineers' people skills improved and they developed the capacity to handle systemic and interrelated issues.
|
Does the AutoCo culture hold an assumption that developing process knowledge
and understanding among people detracts from engineering knowledge and
technical achievement?
The comments here were echoed by many people at AutoCo: "First handle the technical and then, if you have time left, you can work on the behavioral." Do "process people" sometimes assume that their work is denigrated by the larger culture, when in fact it is not?
Is there an assumption that resolving the tradeoff between technical and behavioral needs would extend a manager's work beyond the hours available in a day? |
Vice President: The first thing we have to do is make sure that people really
understand the engineering processes -- DVP&R, QOS, prototype process,
change control, the timing discipline, and so forth. If you asked me,
"Do I do that before I do any teamwork and team building?" -- the answer
would be an unequivocal yes. I think if you don't have a fundamentally
strong engineering framework, then no amount of team building or team
process will ever overcome that weak system. You'll fail. The team will
thrash about with all kinds of good intentions.
Now, the converse, I guess, is -- assuming you have a fundamentally solid engineering process -- that as you encounter difficulties or fall behind in one area, team building and the human side of teamwork come into play. A team can rally, help each other overcome difficulties and move on. As I understand organizational learning, it preaches an appreciation for the other person's point of view. If you, as a team person, understand that your action or non-action causes another person a problem, then you will try hard to make that not happen. That understanding comes from team building experiences. The team is a very large family that's working together. How you measure that understanding, I don't know. Program Manager's Boss: I could tell that the Vice President was really interested in getting this car program implemented. I think there were times when he was concerned that the team was spending too much time on the soft stuff and that could get in the way of hard results. I have been very supportive of this work, but at the same time continued to stress to [the Program Manager] that he had to get results. |
The dilemma of integrating process and engineering knowledge
Despite the team leaders' intentions to have process knowledge and engineering knowledge reinforce each other, the synthesis was imperfect in practice. In at least one case, there were complaints that the engineering knowledge was short-changed. This had to do with the team's change of structure -- bringing engineering and process authority together, assigned to one group of people -- without looking closely at the assumptions that these people would hold about one another.
| Not all engineers felt included. The fact that Launch and Program Managers were not engineers meant that they didn't jump into difficult engineering problems and participate in resolving them. Instead, they put them back on the team. As the comment shows, some engineers did not feel free to raise this problem. | Content leader: But when it came to dealing with some of the particularly difficult engineering issues, we were left out in left field, and we had no one to go to. I don't think it was [the Program Manager's] problem to get involved with these issues, because he doesn't know about engineering. But we should have been able to discuss the problem [that engineers felt unsupported.] I think after a while we recognized it and we avoided [discussing it]. |
Bringing the process leaders and the content leaders together on a team, it was thought, would allow them to recognize one another's blind spots and develop an appreciation for how the other side saw things. This, however, did not always happen.
|
The contrast between process knowledge and engineering knowledge was prominent
within the Epsilon team as well as in the larger organization. People seemed
to be experts at one or the other, but not both. Communication was not strong
between the two groups of experts and some issues may have been overlooked.
How can we design learning so that technical and process knowledge reinforce each other? Could members of both groups be empowered simultaneously? |
Content leader: There were some rough roads on this program. There used to be a
conventional breakdown of car program management. You'd have separate managers
for business planning, vehicle engineering, launch, and vehicle development.
On Epsilon, they tried to combine all those skills into one person. This was the first time they tried that management system and the way they implemented it didn't work very well. It worked in fits and starts. The real engineers all ended up reporting to the Chief Engineer, and the planning types ended up reporting to [the Launch Manager]. [The Launch Manager] is not an engineer by background. The planning people worked with the Design Center effectively, and knew how to talk about the features of the car, but they didn't have the background to say, "OK, now we need A and B completed by this time and we always have problems with B, so let's concentrate our efforts there." We found out after a three-month delay, for example, that some engineering issues affecting the audio system were not being elevated to the Chief Engineer's level of discussion. Some of the vehicle leaders didn't seem to know enough to bring up the right questions. They should have had much more deliberate communication between the groups from the beginning. |
[Back to the Abbreviated Table of Contents]
Sidebar: What are systems archetypes? | |||
| |||
| See Peter Senge, The Fifth Discipline (1990; Doubleday), p. 93-113 and 378-390; Daniel H. Kim, Systems Archetypes: Diagnosing Systemic Issues and Designing High-Leverage Interventions (1993, Pegasus Communications); and Senge et al, The Fifth Discipline Fieldbook (1994, Doubleday), pages 121-150. |
[Back to the Abbreviated Table of Contents]
Sidebar: What are the "ladder of inference" and "left-hand column"? | |||||
|
[Back to the Abbreviated Table of Contents]
Sidebar: What are "affinity diagrams" (K.J.'s)? |
|||
|
|||
 |
[Back to the Abbreviated Table of Contents]
Sidebar: Problem solutions, versus problem articulation |
|||
|
|||
|
|||
| For more information on the "problem solving treadmill" concepts, see Daniel Kim's articles, "Using 'Fixes that Fail' to get off the problem-solving treadmill" and "Fixes that Fail: Oiling the Squeaky Wheel-- Again and Again..." in the November 1990 and September 1992 editions of The Systems Thinker, Pegasus Communications (Cambridge, MA). |
[Back to the Abbreviated Table of Contents]
Sidebar: The core team's view of "parts behind schedule" |
|
| This picture is a simplified version of a causal loop diagram produced by the Epsilon core team. The key problem is the central concern, "parts behind schedule." At the left are a series of forces (many involving exponential growth) that contribute to increasing numbers of part changes and late decisions. At the right are many of the "fixes" that the conventional system uses to "solve" the parts behind schedule problem, and the unintended consequences of those fixes (staffing shortfalls, the taking up of supplier time to help engineering) that actually make the problem worse. Adapted from "A Framework and Methodology for Linking Individual and Organizational Learning Applications in TQM and Product Development," by Daniel H. Kim (1993, MIT Ph.D. dissertation, p. 282-296). |
[Back to the Abbreviated Table of Contents]
Sidebar: "Content leaders" and "process leaders"? |
|||
|
[Back to the Abbreviated Table of Contents]
In part as a result of earlier delays the MP drawings were sixteen weeks
behind, but the first MP build was completed only four weeks behind
the original schedule. The quality of the MP prototype build and maturity of
its design allowed extensive testing to be done much earlier than is normally
possible.
The new owner vehicle assessment (NOVA) scores for VP were 96, compared to an
average of 108 for other vehicle programs (lower scores mean higher quality
ratings). The NOVA scores for the earlier build had been substantially
worse than average; they were 145, compared to an AutoCo average of 105.
Top AutoCo managers made what were described as uncharacteristic
acknowledgments that the Epsilon program was performing well.
1 "Colocation" means that people from the
diverse engineering functions developing the car (i.e. chassis design, air
conditioning, suspension, alternator, sound systems, dashboard subsystems,
etc.) work from offices in the same location. Team members are physically
placed together, during the time it takes to design the car, instead of coming
together only for formally scheduled meetings. [Back]
[Back to the Abbreviated Table of Contents]
[Back to the Abbreviated Table of Contents]
1 "Theta" is a code name for a highly successful and best-selling
vehicle which AutoCo produced in the mid 1980's. The success of Theta is
credited with putting AutoCo in a financially solvent position and allowed
investment in other vehicle development programs. In order to achieve its
success, the Theta program "broke" a number of product development rules.
Although not always judged as successful in its product development efforts
(milestones, timing, quailty, warranty and so forth), Theta was highly
successful in the marketplace. The team that "went all out" to get Theta to
market was not highly acknowledged within AutoCo for what was widely thought to
be a heroic effort. A number of the managers on the Epsilon program, including
the Program Manager, had previously worked on the Theta program.
[Back]
[Back to the Abbreviated Table of Contents]
Epsilon's Noticeable Results, 1991-1994
This list of noticeable results was collected and amended through the learning
history interviewing process. People were asked to comment on items, their
significance, and if it was familiar, describe how it was accomplished and what
if any role they and others they knew had in it. The items in this list are
observable events or objective measures which provide data on Epsilon program
progression.
The noticeable results are measurable and provide firm indication of the
Epsilon program's achievements. These noticeable results were used to focus
description and evaluation in interviews. What transpired so that these
results were accomplished, how they were interpreted, and what they mean has
been the subject of this learning history.
Appendix:
Some initial questions for group discussions prior to moving forward with
learning initiatives
This learning history presents a story of what happened in the Epsilon Program.
It also provides a context for considering important issues which surface as
business organizations undertake explicit learning efforts. Provided below are
four questions applicable to what happened with Epsilon, which can also be
taken as a starting point for management teams considering either leading or
supporting process innovation efforts:
Notes
* "Colocation" means that people from the
diverse engineering functions developing the car (i.e. chassis design, air
conditioning, suspension, alternator, sound systems, dashboard subsystems,
etc.) work from offices in the same location. Team members are physically
placed together, during the time it takes to design the car, instead of coming
together only for formally scheduled meetings.