Download Enberg, C., Lindkvist, L., and Tell, F. (2010), Knowledge Integration at the Edge of Technology: On Teamwork and Complexity in New Turbine Development, International Journal of Project Management, 28, pp.756-765

This article appeared in a journal published by Elsevier. The attached
copy is furnished to the author for internal non-commercial research
and education use, including for instruction at the authors institution
and sharing with colleagues.
Other uses, including reproduction and distribution, or selling or
licensing copies, or posting to personal, institutional or third party
websites are prohibited.
In most cases authors are permitted to post their version of the
article (e.g. in Word or Tex form) to their personal website or
institutional repository. Authors requiring further information
regarding Elsevier’s archiving and manuscript policies are
encouraged to visit:
http://www.elsevier.com/copyright
Author's personal copy
Available online at www.sciencedirect.com
International Journal of Project Management 28 (2010) 756 – 765
www.elsevier.com/locate/ijproman
Knowledge integration at the edge of technology: On teamwork and
complexity in new turbine development
Cecilia Enberg, Lars Lindkvist ⁎, Fredrik Tell
KITE, Department of Management and Engineering, Linköping University, Sweden
Received 2 February 2010; accepted 25 May 2010
Abstract
This paper takes an empirical point of departure in the development of a new steam turbine. Project work here relied on a process of iteration
between a small core group of team members with extensive experience and team members with less of that currency. In this project, the core
group had a major integrative role, whereas other team members were mainly responsible for the specific tasks assigned to them. Quite a few of
the latter category felt uneasy about their role and felt ‘decoupled’ from the project. In our analysis we use the Teamwork Quality (TWQ) construct
proposed by Hoegl and Gemuenden (2001). In conclusion, our findings suggest that in highly complex projects of this type, team-based
knowledge integration need not presuppose equality of participation and we introduce the notion of a Segregated Team to account for these
findings.
© 2010 Elsevier Ltd. and IPMA. All rights reserved.
Keywords: Knowledge integration; Product development; Projects; Teamwork
1. Introduction
Product development projects typically call for the integration of a wide range of specialised knowledge bases. Moreover,
it has been suggested that the degree of integration of such
dispersed knowledge can explain differences in product
development performance and that the firm's knowledge
integration capabilities can be vital to attaining competitiveness
(Carlile and Rebentisch, 2003; Hoopes, 2001). However, the
question of how knowledge integration is enabled in different
types of project settings has not received much attention.
Instead, there has been a tendency to treat all projects as similar
and equal (Shenhar, 2001; Sauser et al., 2009). Carlile and
Rebentisch (2003, p. 1182) suggest that “current frameworks of
knowledge transfer and integration do not apply with equal
explanatory power to both simple and complex knowledge
integration tasks” and that those frameworks which exist seem
⁎ Corresponding author.
E-mail addresses: [email protected] (C. Enberg), [email protected]
(L. Lindkvist), [email protected] (F. Tell).
mainly to mirror situations which would be characterised as
being rather simple and comprising limited uncertainties.
In this vein, the specific purpose of this paper is to explore the
issue of team-based knowledge integration in a product
development project — the Turbine project — characterised by
high levels of uncertainty and complexity. The project managers
and project members repeatedly stressed that the task assigned to
them involved “working at the edge of technology” or “at the edge
of what is possible”.
[In this project] you are really at the leading edge of
technology and knowledge. […] The nature of work is such
that you always try to push the frontiers of what is possible.
(Experienced project member, aero)
Although, their subjective opinions cannot be taken as a fact,
our case study observations largely substantiate them. Among the
risks associated with the project were limited knowledge about
issues that concerned extensive vibration excitation at high
volume flows and only partly validated tools for aerodynamic
calculations. In order to develop the new steam turbine, many
different domains of technical expertise were needed, ranging
0263-7863/$ - see front matter © 2010 Elsevier Ltd. and IPMA. All rights reserved.
doi:10.1016/j.ijproman.2010.05.003
Author's personal copy
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
from knowledge about mechanical integrity and aerodynamics to
blade design, design layout and testing. Project members were
strongly specialised and all of them had deep knowledge of their
domain of expertise. One basic challenge facing the project was
how to handle the contradictory demands of aerodynamic
efficiency and mechanical integrity (MI). Thus, apart from
working at the edge of their competences, project members from
‘aero’ and ‘MI’ had to manage a difficult trade-off, which could
not be resolved in a classical optimization manner.
2. Team-based knowledge integration
Turning first to the issue of integration, we should first
acknowledge its very long history in the literature. Lawrence and
Lorsch (1967), Thompson (1967) and Perrow (1970) were all
concerned with the issue of how to achieve activity integration.
With regard to what would affect the mode of integration that
should be adopted, using slightly dissimilar terminologies, they
all recognized contingencies such as complexity, uncertainty, and
interdependencies. Building on these classical sources, Grant
(1996) took integration-thinking a step forward by adding the
‘knowledge’ issue to the previous focus on activity integration. In
his view, due to the difficulties and high cost of transferring and
sharing tacit knowledge, such transfer should be avoided where
possible. Hence, knowledge integration should be concerned with
the use of appropriate mechanisms for managing knowledge
complementarities to be chosen in a cost-economizing manner
(Grant, 1996; Postrel, 2002; Enberg, 2007; Schmickl and Kieser,
2008). For example, while contingencies such as minimal
interdependencies and limited complexity would allow for the
use of cheap mechanisms (such as rules, roles and routines),
severe “team interdependencies” would call for expensive and
communication-intensive mechanisms, such as “group problem
solving and decision making” (Grant, 1996, p. 114). As our
interest lies in high complexity contexts, his advice would thus be
that we have to rely on the communication-intensive and
expensive team option.
A similar reliance on the team recipe is suggested by
Grandori (2001). Like Grant she acknowledges the tacit-explicit
knowledge distinction and looks upon the choice of (knowledge) integration mechanisms as an economizing endeavour.
However, unlike Grant, who takes type of interdependences as a
main contingency, she focuses on knowledge-related contingencies, such as the degree of knowledge differentiation and
knowledge complexity. The first dimension, differentiation,
refers to differences in technical specialities and cognitive
orientations among individuals and includes differences in
languages, the perception of relevant information, the theories
and practices used and the types of results pursued. As
differentiation increases, “the possibility of mutual understanding, of succeeding in decoding the messages, of utilizing the
knowledge of others, decreases” (Grandori, 2001, p. 390). The
second dimension comprises two components; namely computational complexity and epistemic complexity. Computational
complexity refers to the number of elements and symbols
involved and the possible connection between them. The
second component, epistemic complexity, adds the aspect of
757
knowledge tacitness. Thus, when knowledge differentiation is
high and is combined with high computational/epistemic
complexity — teams are appropriate, says Grandori (2001, p.
394). However, neither Grant nor Grandori provide much detail
as to the nature or characteristics of teamwork that may actually
bring about a functioning process of knowledge integration in
such kinds of difficult development contexts.
Typically, in the literature on teams and project teams, the need
for close interaction between all members is emphasized.
Katzenbach and Smith (1993, p. 9), for example, state that “real
teams are deeply committed to their purpose, goals, and approach.
High-performance team members are also very committed to one
another. Both understand that the wisdom of teams comes with a
focus on collective work-products, personal growth…”. Moreover, Nonaka and Takeuchi (1995, p. 242) argue that “the product
development project emerges from the constant interaction of a
multidisciplinary team whose members work together from start
to finish”. These accounts of teamwork promote the image of an
interaction and communication context that underlines its
compositional homogeneity and the equality of its members
with regard to their authority and ability to contribute. Yet, while
such features may be both common and benefit practice, they are
expressed quite generally, making it difficult to use to them in
order to discriminate between teamwork practices which mirror
those characteristics more or less closely.
Furthermore, as shown by the extensive overview provided
Hoegl and Gemuenden (2001), while the general importance of
teams to the success of innovative processes is well documented
in the literature, prevailing studies have a tendency to
demonstrate the link between the mere existence of a teambased organization and innovative performance, and pay little
attention to specifying in more detail what facets of teamwork
may have contributed. As a remedy, they propose a Teamwork
Quality (TWQ) construct comprising 6 facets: communication,
coordination, balance of member contributions, mutual support,
effort, and cohesion. Based on their survey study, they also
report that TWQ was positively related to project success
(including team performance and team members' personal
success). In our view, this is a very helpful construct, which is
useful in characterising team operations in the Turbine case.
In the following analysis, we will use this construct to
indicate to what extent a team should be considered ‘integrated’
or ‘segregated’. As defined in most dictionaries, segregation
refers to the, more or less voluntary, physical separation of
groups and individuals (NE, 2010). This concept is often used in
analyses of segregated housing areas, racial segregation, etc. In
such contexts, it often carries an additional connotation of lack
of interaction and non-equal opportunities among various
groups. In the Turbine project, all the team members were colocated, and our choice to use the TWQ construct to account for
segregation facets in the Turbine project is thus a means to
recognize these additional interaction/equality aspects.
Focusing on its quality of interaction and equality features,
we below present the six facets that make up the TWQ construct
in a shortened version (Table 1).
As will be detailed in the case section below, the Turbine
project team relied very much on a process of iteration between
Author's personal copy
758
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
Table 1
Facets of Teamwork Quality (Hoegl and Gemuenden 2001, pp. 437–438).
Communication
The possibility for all members to communicate formally
and informally with all other members
Coordination
The synchronization of individual contributions and the
need to agree on work break-down structures, schedules,
budgets, and deliverables
Balance of member The possibility of all members to bring in their views and
contributions
ideas, unrestrained by hierarchy and dominating others
Mutual support
The existence of cooperative frames of mind and mutual
respect
Effort
Everyone knowing and accepting the work norms
concerning sufficient effort
Cohesion
Team members' sense of togetherness, belonging, and
desire to remain on the team
a small core group of experienced team members and other team
members with less experience but with a deep knowledge of
their specialist areas. Here, the core group had a major
integrative role, whereas other members were mainly responsible for the specific tasks assigned to them. Quite a few of the
latter felt somewhat uneasy about their role and expressed that
they felt ‘decoupled’ from the project. It seems that this division
of labour between core and non-core members was an important
means of managing a continuous process of trial-and-error,
comprising both an intentional and unintentional generation of
deviations, which nurtured the process of sense-making
predominantly among those more experienced. Yet, although
the team appeared to display many signs of segregation, it was a
team where all the members were needed and important, and
despite the complexities and tensions that accompanied the
project, it was brought to a successful conclusion and those
involved opined their satisfaction, in particular with the
technical solutions finally elaborated.
3. Data collection
The study of the Turbine project was conducted at PowerCo,1
a global developer and manufacturer of power generation
equipment. The study was inspired by ethnography (Alvesson
and Deetz, 2000) and one of the authors was co-located with the
project team during the period from July 2002 to July 2003 — i.e.
during the concept and detailed development phases of project
work. During this period, the project members were intensively
engaged in trying to solve the technical problems and set the
design layout of the new steam turbine. During the first months of
fieldwork, our focus was on the efforts at building an
understanding of the context of project work and how product
development projects were conducted at PowerCo. The intranet
and shared databases were browsed for policies and manuals
related to product development and project work. Informal
conversations with the two project managers (one on them whose
role was more that of a general manager and the other one who
had the responsibility for the flow path design) took place on three
occasions. Furthermore, secondary material, like presentations,
1
PowerCo is a fictive name.
results and notes related to the Turbine project, were studied to
gain an understanding of its particulars.
In October 2002, we started to attend the weekly project
meetings (called aero/MI meetings2). After having been present as
an observer at six project meetings, one general progress meeting
and one LP-review meeting,3 a first round of interviews was
starting by the end of November. Nine semi-structured interviews
were conducted; seven interviews with the project members who
were most intensively involved in the project at the time (i.e. those
who were dealing with the flow path design from an MI or aero
perspective) and one with each of the two project managers. Our
questions centred on issues of coordination and cooperation and
each interview lasted for approximately 2 h. These interviews
largely formed the basis of our understanding about the roles and
tasks of different project members and the prevailing pattern of
interaction between experienced and less experienced project
members. After (and partly in parallel with) this first round of
interviews, followed a lengthy, intense period of work, extending
throughout Spring, when often, several meetings were held each
week. Meetings had to be attended somewhat selectively in this
period as beginning in February, a second round of interviews,
comprising six additional project members were also conducted.
Both the project meetings and the last round of interviews helped
to further clarify the pattern of interaction between the different
groups of project members that had previously been discerned.
Project work progressed at a reasonable pace and the last
project meeting we attended took place June 24, 2003, as the
Turbine project had then passed the concept phase and was halfway through the detailed development phase. By that time a total
of 32 meetings had been attended; 27 weekly aero/MI meetings,
two LP-review meetings, one concept review meeting, one
general progress meeting and one STECO-meeting.4 In May–
June 2003 we wrote a lengthy report about the Turbine project,
which was distributed to the project managers and the project
members. This report then constituted the basis for a workshop at
PowerCo in August 2003. Putting all of this together, we believe
that we had a good opportunity to gain the kind of in-depth
understanding that is a qualitative mark of any single case study
(Dyer and Wilkins, 1991) (Table 2).
4. The Turbine project
PowerCo develops and manufactures power generation
equipment. At the time of the study, its sales approximated €21
billion and the company had about 100,000 employees in more
than 70 countries. In about year 2000, there was a significant
2
Aero/MI meetings involved project members representing aerodynamics
and mechanical integrity, the project managers and sometimes project members
representing other disciplines. Such meetings were held every week and
focused on project progress and the agenda for the next week.
3
A general progress meeting involved members and managers of various
projects from different locations and several projects, including the Turbine
project, were discussed. LP-review meetings (LP refers generally to ‘low
pressure’ turbines) served to discuss technical issues related to the Turbine
project with experts from different parts of the organization.
4
STECO was the steering committee of the Turbine project.
Author's personal copy
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
759
Table 2
Overview of data collection.
Period of time
Number and type of meetings
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
3 informal meetings with project managers
1 general progress meeting
February 2003
March 2003
April 2003
May 2003
June 2003
August 2003
4 aero/MI meetings, 1 LP-review meeting
4 aero/MI meetings
1 aero/MI meeting
2 aero/MI meetings, 1 concept review meeting,
1 LP-review meeting
3 aero/MI meetings, 1 STECO-meeting
1 aero/MI meeting
5 aero/MI meetings
3 aero/MI meetings
4 aero/MI meetings
downturn in the market for power generation equipment which
resulted in decreased demand for steam turbines. The North
American market, which a few years earlier had constituted the
most important one in terms of sales, was shrinking drastically.
Instead, Europe and Asia were increasingly seen as promising
future markets. However, while the emphasis among North
American and European customers was on high efficiency and
serviceability, Asian customers stressed low cost. This meant that
it became unclear what features of steam turbines PowerCO
should focus on. This was a difficult situation, as the company
was losing market shares on a shrinking market and as they were
also lagging technologically behind their competitors.
Generally, our steam turbines have no obvious technological
advantages and when it comes to efficiency our steam
turbines are behind those of our competitors. (Managing
Director, R&D department).
To deal with this situation PowerCo thus realized they had to
develop a more competitive steam turbine. Yet, as suggested
above, it was unclear whether customer demand implied that
they should focus on offering a turbine at a low initial cost or a
technologically advanced turbine with substantially improved
efficiency. In the light of this background, PowerCo decided to
initiate the Turbine project.
4.1. Project goals and stages
The project's target was stated in terms of developing a 50/
60 Hz Low Pressure (LP) steam turbine with increased
efficiency, an increased exhaust area and a blading cost increase
of less than 15%. In a sense, this goal mirrored the market
uncertainty regarding the trade-off between low cost and
efficiency. However, while it expressed the need to increase
efficiency, it did not present any indication of how much it
should be improved. Yet, it was recognized from the outset that
the project had to come up with a significantly ‘better’ turbine, a
task that seemed quite risky in particular considering PowerCo's limited knowledge of issues that concerned extensive
vibration excitation at high volume flows and the development
of reliable tools for aerodynamic calculations. In addition, there
Number of interviews
Other activities
Collecting secondary material.
Attending information sessions.
Observation of every-day work.
Informal conversations.
7 interviews
1 interview
1 interview
6 interviews
Writing of company report
Workshop
were quite a few challenges of a more general character, such as
the shortage of personnel, the tight deadline and the tight
schedule allowed for the ex works.
4.2. A multi-disciplinary challenge
The Turbine project involved highly specialised engineers
from different knowledge areas, most of whom belonged to the
basic disciplines of mechanical integrity (MI) and aerodynamics
(aero) or to related sub-disciplines such as blade design, design
layout and testing. Most members of the Turbine project had a
similar educational background, as they had a university degree in
mechanical engineering or turbo-machinery. However, most of
them were strongly specialised within their basic discipline.
Moreover, even within each discipline, project members were
specialised — in the sense that there were differences in
experience and competence.
The development of a functioning, reliable and efficient steam
turbine involves elements of aerodynamics, design and mechanical integrity. Although at the general level, it is fairly easy to
understand the workings of a steam turbine, it involves numerous
technical interdependencies that impact on each other in complex
ways and often, project members have to handle contradictory
demands. For instance, while rotor blades at the inlet area are
always equipped with shrouds to reduce losses, rotor blades at the
exhaust area are several times longer, less compact and object to
higher frequencies. Thus, while putting a shroud at the end of such
a blade will most certainly contribute to better efficiency it is less
suitable from a mechanical integrity (MI) perspective as it results
in higher material stress, which impacts on the durability of the
turbine. As suggested by this brief example, there is an inherent
trade-off between efficiency (a main concern of the aero-group)
and mechanical integrity (a main concern of MI-group). It was
even suggested that aero and MI “live in different worlds”.
It's difficult […] because efficiency is mainly done by the
aero group and we MI guys are just a bit of disturbance for
them, so most things that we propose are, how can you say,
counterproductive […] because MI in the end gives you
some limitations to the aerodynamic freedom and that is
Author's personal copy
760
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
always an argument between aero and MI […] We [MI] have
to go to the limit. (Experienced project member, MI)
Furthermore, the changes in the market had an impact on
how the trade-off between efficiency and costs should be
considered and handled. Market changes in the direction of
higher demand for efficiency implied that MI people were put
under pressure to “swallow some frogs”, i.e. to go a bit beyond
what they consider advisable from the perspective of material
integrity and reliability.
4.3. Work at the edge of technology
The Turbine project thus involved a couple of trade-offs. First,
a market-induced one which was related to efficiency and low
cost, and second, a technological one regarding aspects of
aerodynamics and MI. In addition, the project required development work which called for ventures into unchartered territory.
For example, the project members had to develop the longest rotor
blades ever applied in the history of the company. This was a task
with extraordinary requirements particularly with respect to issues
of mechanical integrity and it led them to investigate the possible
use of titanium instead of steel, a material of which they had no
former experience, in the rotor blades. Since the project members
had to generate new knowledge as part of the endeavour, there
were seldom any norms or standards against which they were able
to compare and evaluate the results of the different design options.
Furthermore, there were no possibilities to actually test the
different design options in real life as it would have been too costly
and time-consuming to build a prototype for test running. Hence,
project members had to rely to a great extent on results from
computer modelling and calculations; and they also had to live
with uncertainty. The Turbine project was described by the project
members, not only as “extremely complex” but they also
frequently stated that the task assigned to them involved “working
at the edge of technology” or “at the edge of what is possible”.
[In this project] you are really at the leading edge of
technology and knowledge […] The nature of work is such
that you try to push the frontiers of what is possible.
(Experienced project member, aero)
The Turbine project also involved the development of much
of the software that was needed for modelling and calculating
the different design options. It was often noticed that this
software had its own inaccuracies, and occasionally contributed
to increased, rather than decreased, uncertainty.
[The software] has its own shortcomings and tolerances…
and inaccuracies… so that in the end you will get results that
you should always be a bit sceptical to […] we are also
working on alternative tracks in order to make sure that if
we find serious shortcomings and risks, that we have
alternative tracks. […] it's very complex to model all these
things and then the programs have their own inaccuracies
and so on. (Experienced project member, aero)
Actually, it seems that the project members more often than
not encountered difficulties when trying to make sense of
computational results. On some occasions, the difficulties were
related to problems of understanding whether the results
obtained were desirable or not, e.g. this was often the case
when analysing models and calculations that concerned erosion.
Only a few years previous to the study, erosion could not be
modelled and had therefore not been an issue when developing
a new steam turbine. Project members were not sure whether the
problem was due to the software tools used for modelling and
calculation, or whether it was actually due to the technology.
However, even when the software used was considered reliable,
and people thought they “knew the theory behind”, model-based
experimentation often produced unexpected results. Such experiments thus provided more information, but increased rather than
decreased uncertainty. However, such results were often welcomed
as they supplied input for thought and evidenced the need for more
in-depth inquiry. Model-based experimentation involving many
variables and intricate interdependencies may thus bring about
‘interesting’ deviations, due to the fact that people, erroneously,
believe that they know the underlying theory.
Experimentation, however, was also used in situations where it
was not possible to estimate any clear expectations from theory.
Such experiments could sometimes generate outcomes which were
far beyond the imagination of even the most knowledgeable project
members. Even if people were well aware of the separate impact of
each variable on other variables, the system-wide implications of
their compound interactions soon became incomprehensible as the
number of variables increased. Hence, in modelling various
features of the trade-off between issues concerning aero and MI, the
variable set-up could result in a multiplying interactivity.
4.4. A team of non-equals
In the Turbine project, members with different expertise had
different roles and responsibilities. When observing the way in
which experienced and less experienced project members
respectively participated in project meetings, we noted that
not only their knowledge domains mattered, but also their
experience. Experienced and less experienced project members
were responsible for widely different types of tasks. Less
experienced project members were responsible for the execution of well-defined work packages, the results of which were
handed over to the experienced project members for analysis.
Although less experienced project members were invited to
present their work, they were seldom involved in discussing and
analysing the results of this work.
…that is clear that they [the less experienced project
members] also want to do some work on the whole without
being controlled, or told what they should do. That means
that we have to look for work packages that they can do on
their own, like calculations or studies, smaller studies and
investigations […] where it is clear, not too many changes in
the design, three, four areas and calculate this. (Experienced
project member, aero)
A few knowledge sharing efforts took place between
experienced and less experienced project members but the
knowledge shared was limited and unequally distributed.
Author's personal copy
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
Because I think that they exchange a lot of useful
information … when they are talking about numbers but I
don't understand what it is about, the pressure clearance or
whatever. (Less experienced project member, MI)
Similarly, when asking the project members how they made
sense of computational results, those with much experience
suggested that they relied on ‘a gut feeling’, whereas less
experienced members replied that they lacked any kind of
guidance for evaluating the results of their computations.
Unsurprisingly, the less experienced project members considered
themselves to be ‘decoupled’ from the project although they were
formally full members. The image of ‘decoupledness’ provided
by the less experienced project members was also acknowledged
by the experienced.
4.5. Experienced members' interaction
While the work of less experienced project members was
predominantly of an individual character, the work of the
experienced members was more interactive. Lukas, one of the
more experienced project members, stressed the importance of
the fact that he and his fellow team members were co-located
and could “discuss together […] until we come up with
something and come down to something, which means an
alternative, what we can do”. The core team, he explained,
should remain a multi-disciplinary one, a team of people with
their own deep specialist knowledge, but at the same time in
much of their interaction they were dependent on an underlying
tacit understanding of each others' working practices.
If I make a calculation, if the mean is 300, that means a lot
of things to me and I know that if it's Valentin who has
worked with it, then I know what he did and the process is
clear. If I told him just to make [a certain kind of
calculation, explained only briefly] then I know that he
knows that I mean a stress calculation 2D and frequency
calculation 2D for the system, and that means a process. So
there are a lot of things which are unsaid. (Experienced
project member, MI)
At project meetings, discussions were focused on identifying
and making sense of problems from the basis of computational
results which were represented in for example graphs and
diagrams. Drawings and sketches were also frequently used.
Those project members who gave a report of their work
frequently put slides and printouts on the table or took a piece of
paper and a pencil to illustrate what they meant. The other
project members gathered around the table and leant forward to
have a closer look. The discussion about what design options
were technically feasible or not centred about such illustrations
and the computational results which they somehow mirrored.
Based on these illustrations, which served as a kind of boundary
objects, experienced project members could then decide which
values needed to be changed before a design option could
constitute “a promising alternative”. Yet, that did not mean that
they knew how to change the design in order to reach the
desired, or at least an acceptable, solution.
761
The use of illustrations was thus a way of handling the
complexity of the issues and the many technical interdependencies that existed. The project members argued that the
illustrations helped them make sense of what was said and done
in a way which would not have been possible if they were only
given verbal information.
If you look at the actual things we are talking about, they may
be quite complex so they need some kind of simplifications or
at least representations in order to make them understandable.
You can't say stiff or less stiff or…in a way that helps
somebody else…so you have to show them this curve, look at
this and this… (Experienced project member, MI)
Basically, they somehow had to learn from computational
results and step-by-step exclude design options which were not
suitable. The development of the new turbine thus mirrored a
kind of trial-and-error process and — an iterative process of
approaching a good enough design alternative, rather than
finding the best solution by means of an optimization
endeavour.
4.6. At the end
Eventually, the Turbine project resulted in a very successful
design concept. The final design solution involved a straight
root, a double coupling concept (i.e. both snubber and shroud)
of the last stage blade and used a steel material instead of
titanium. Proudly, one of the project managers stated that “it is
the largest blade you can make with this material”. He went on
to say that the discussions about cost versus efficiency and risks
had been never-ending, but that the final solution arrived at was
better than expected with respect to both efficiency and costs.
PowerCo, he continued “can now increase the operating range
of its turbines due to better mechanical integrity”. Thus, both
aero and MI seemed satisfied with the final solution and even if
the time and cost targets had been exceeded, the project
managers were happy with the outcome of the project.
When the Turbine project formally ended in December 2006,
two turbines had already been sold and work on the first
commission was due to start by the end of 2007. Luckily, the
market situation had then also changed for the better.
At the moment, we are struggling to keep our commitments.
We are too successful. We have too much to do. We have a
very good order intake and I'm afraid that we will end up
with penalties as it will be difficult to keep our promises due
to the order intake. (Project manager 1)
5. Concluding discussion
The Turbine project proved to be a challenging undertaking.
New turbines are not introduced on a frequent (or regular) basis;
e.g. on the roadmap for the coming five years, the Turbine
project, with an estimated duration of three years, was the only
development project planned. As a result, the experiences and
lessons learned from previous development projects were both
Author's personal copy
762
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
unequally distributed among project members and likely to
become a bit obsolete, if not simply forgotten. Moreover, the
project involved working at the edge of technology, which
implied creative work to come up with an innovative
technology which, to use the terminology of Rosenbloom and
Christensen (1994), was not only new to the firm but also to
some extent ‘new to the world’. This implied working with
materials, which Power Co as well as their competitors had
limited experience of, and relying on newly developed methods
and tools which were un-sufficiently validated.
In the case story, we provide a significant amount of detail
about the preconditions that prevailed as well as the way in
which knowledge integration was enabled. Below, we turn to
the opposite approach and try to account for our observations
using just a few conceptions. First, we try to substantiate our
claim that this project was associated with profound uncertainty/complexity. Second, we focus on the issue of identifying the
prevailing pattern of team-based knowledge integration.
Finally, we propose the notion of a Segregated Team and
discuss its applicability in contexts such as the one represented
by the Turbine project.
5.1. A highly complex project
We use the notion of complexity in an over-arching sense as
comprising the “overall difficultness and messiness of the
overall project” (Williams, 1999, p. 271). In our interpretation
then, the Turbine project involves both ‘structural’ and
‘dynamic’ complexities. In the case of the former, the traditional
view is to recognize the number of elements and the degree of
interdependencies between elements (Simon, 1962; Baccarini,
1996). But, following Grandori (2001) we would also include
how varied or ‘differentiated’ these elements are.
In our view, the Turbine project scores high on structural
complexity. Considering the large number of interdependent
subtasks and the high degree of simultaneity among them, the
multitude of variables involved in modelling the aero and MI
considerations, the presence of complex interaction effects, etc.,
clearly indicate that the Turbine project scores high on the firstmentioned structural aspect. With regard to ‘differentiation’, we
notice that MI and aero members represent quite different fields of
expertise with a different focus; to maximise reliability and
efficiency respectively. Furthermore, a similar observation can be
made with respect to differences between the experienced and less
experienced project members. The experienced project members
had a gut feeling for what information was relevant and succeeded
in making sense of it while the less experienced members had
difficulties sorting out the relevant cues from the information
provided and understanding its implications. We therefore
suggest that knowledge differentiation should be considered to
be high.
Yet, although the above analysis makes sense, it does not
capture the full flavour of the preconditions that prevailed in this
case. It was often the case that project members had knowledge
about specific cause–effect relationships, but experienced a lack
of understanding of the compound cause–effect relations. For
example, the degree to which a small change to the shape of the
blade influenced frequency families, erosion, mechanical
integrity and ultimately, efficiency was largely incomprehensible. As a result, sometimes very surprising but ‘interesting’
outcomes from experiment and tests were obtained due to the
impossibility of assessing the multiplying effects of small
design changes in one part of the flow path channel on other
parts of the system. We suggest that ‘dynamic complexity’
would be a fitting term for the presence of such unforeseeable
and unimaginable multiplying effects of small changes. This
notion of complexity would be well in line with the discussion
in Tsoukas and Hatch (2005), who point out that complex
systems tend to be non-linear and fractal, exhibit recursive
symmetries, be sensitive to initial conditions and be replete with
feed-back loops. In such contexts, there will be “no proportionality between causes and effects. Small causes may give rise
to large effects.” (op cit, p. 238).
As Weick (2001, p. 155) discusses, making sense of
computations and results is difficult in such contexts, since “so
little is visible and so much is transient”. In the Turbine project,
the turbine existed only in the form of CAD-models during the
development process and the only way to test different variants
and the assumptions from which they were modelled, was
through simulations. This in turn was a difficult undertaking, not
least because the tools themselves constituted new technology
and were subject to their own shortcomings, tolerances and
inaccuracies. As mentioned in the case section, much of the
experienced project members' knowledge was tacit, making them
rely much on their ‘gut feelings’ and their sense of what other
experienced members knew as they interacted. When ambiguity
derives from unexpected and confusing information rather than
from a lack of information, sense-making is needed; “to remove
ignorance, more information is required. To remove confusion, a
different kind of information is needed, namely, the information
that is constructed in face-to-face interaction that provides
multiple cues” (Weick, 1995, p. 99).
5.2. A segregated team
Following Grant (1996) and Grandori (2001), group problem
solving and teams would constitute appropriate mechanisms for
knowledge integration in such highly complex contexts. Both
writers think of this mechanism as a last resort expensive choice.
Considering “the high costs of consensus decision making given
the difficulties of communicating tacit knowledge” (Grant, 1996,
p. 115), this kind of mechanism should be used only where the use
of cheap options such as rules, routines, etc., do not suffice.
Similarly, Grandori (2001) considers the choice of the expensive
team option as a necessity in such difficult contexts. It seems that
the preconditions that prevailed in the Turbine case, would make
it sensible to rely on the team as a basic knowledge integrating
mechanism. Grant and Grandori characterise this mechanism as
‘communication intensive’, they do not however penetrate it
much further. Hence, in the analysis of the Turbine case we below
turn to the TWQ construct by Hoegl and Gemuenden (2001),
which represents one way in which the Grant/Grandori
framework may be developed.
Author's personal copy
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
With regard to the Turbine project as a whole, our analysis of
the six TWQ facets, suggests that this team was very much a
‘segregated’ one. As evidenced in the case description, the
experienced and the less experienced project members assumed
responsibility for widely different types of tasks. While less
experienced project members worked in comparative isolation
and were granted little responsibility for activities aimed at
knowledge integration, the more experienced project members
worked intensively together and had key roles in bringing about
knowledge integration. Less experienced members had limited
opportunity to voice their ideas and views in discussion with
those who were more experienced. This was because at times
they did not quite understand the subject being discussed and
other times as they were simply not invited. As a result, they
were hardly seen or treated as ‘full’ members of the team with
equal opportunities to engage in ongoing communication and
interaction. Within the core group of experienced members,
however, the opposite situation prevailed. Here, people were
involved in frequent interaction, discussing their ideas in a
respectful manner, etc.
As a result, while the Turbine team as a whole appeared as a
quite segregated one, in which many of the members was denied
having a say in many vital issues and leaving them with a
feeling of being decoupled and not full members of the project,
the opposite situation prevailed among the members of the core
team. The less experienced members did not really constitute a
specific sub-group, and while there was certainly some
interaction among them, this was rather triggered by efforts to
manage their individual assignments. Despite this, all members
of the Turbine project were necessary in a complementary
fashion and the combined effort was achieved in an iterative
manner, in which the less experienced project members were
given assignments, formulated by the core team members, who
were the main integrators. We would like to refer to the type of
team that resulted from this division of labour and interaction,
and which constituted the mechanism by which knowledge
integration was enabled, as a ‘segregated team’.
The six-dimensional TWQ construct by Hoegl and Gemuenden (2001) is used below to illuminate some basic features of
the pattern of segregation of the Turbine team (Table 3).
Thus, our findings thus suggest that the core group was not at
all segregated, but instead should be seen as a fully integrated
763
group. It is here we find the experienced project members with
deep individual and idiosyncratic knowledge bases which they
were able to apply to make sense of computational results, to
define work packages and thereby enable the integration of the
specialist knowledge of their less experienced colleagues. The
people in this group could communicate freely, have the
possibility to influence the organization of work, introduce their
ideas, be respected and feel like full and equally valuable
members of the Turbine team. Their interaction took place at ad
hoc or regular project meetings during which people from aero
and MI discussed problematic issues from their different
perspectives, using previous experience and exemplars to try
out ideas or to find out “what direction to take”. Often, these
efforts had little to do with finding one best way. As one project
leader said, it was more about finding “a demarcated field on
which to play”. Although the experienced project members
worked together in an interactive and responsive manner, it was
still important that each of them retained their distinctive
competences; achieving a high degree of knowledge base
similarity was not something they pursued beyond the minimum
degree needed to enable their cross-disciplinary communication
(Lindkvist, 2005). Hence, their interaction was honouring the
virtues of both responsiveness and distinctiveness (Orton and
Weick, 1990) in a semi-coupling manner (Lindkvist et al., 1998).
5.3. Why a segregated team?
A first indication of efficiency would be that the project was
completed within a reasonable time and it was generally
regarded successful from both a technical and from a sales point
of view. While this by no means proves that the project process
could not have been even more efficient, a successful outcome
makes it meaningful to try to account positively for the degree
of success actually achieved. This would suggest that ‘the team’
and more precisely a segregated team would be an appropriate
knowledge integration mechanism in the case of the Turbine
project. Hence, while we generally agree with both Grant and
Grandori on the appropriateness of the team option in a context
characterised by high complexity, we also add to their ideas by
pointing out that in such cases the teams may be quite
segregated. Furthermore, the division of labour guided by this
segregation principle, is not quite the same as the often referred
Table 3
TWQ facets regarding less experienced and experienced team members.
TWQ facet
Less experienced (LE) members
Experienced (E) members
Communication
Members had limited possibilities to communicate
with other members of the project team
Members had little influence on work organization
Members could easily communicate
with all project team members
Members had extensive influence on
work organization
Members could freely express their views
and ideas
Members enjoyed respect for their knowledge
and their contributions to problem solving
Members were motivated and put in great effort
Members felt integrated in the ‘core’ of the team
Coordination
Balance of member contributions
Mutual support
Effort
Cohesion
Members were severely restrained regarding their
opportunities of bringing in views and ideas
Members enjoyed respect primarily for carrying
out assigned tasks
Members became somewhat demotivated
Members felt ‘decoupled’, did not have a sense
of being ‘full’ team members
Author's personal copy
764
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
to idea of hierarchical decomposition. As stated by Kratzer et al.
(2008, p. 540), “hierarchical decomposition serves the managerial purpose of having largely autonomous acting and highly
specialized teams whose work proceeds parallel”. Such a view
indicates a major initial effort by project leaders, followed by
periods of increasingly stronger significance and influential
power of the specialised sub-teams. As illustrated by the
Turbine case, however, there was no decomposition of the
entire project task into subtasks assigned to parallel teams, nor
was it the case that the project leaders, or the core team, over
time lessened their influence. On the contrary, as the project
proceeded, the knowledge integration processes that emerged
followed in a more and more subtle and complex trajectory,
leaving those less experienced farther and farther away from
those more experienced. Instead of converging in understanding
and participation, the experienced and less experienced project
members drifted even further apart. It was not until the final
phase of detail specification, when all basic problems had been
solved, that the core team relaxed their impact and control.
Generally, there appears to be some rationality behind using
a segregated team instead of a more integrated and homogenous
one in situations characterised by a high degree of complexity.
Apparently, most engineering firms would rely on some kind of
a competence based hierarchy among their employees, and as
often claimed, sometimes the fate of development projects
depends on a very few highly experienced and skilled
individuals, who are crucial. As a result, competence will not
be uniformly distributed and communicating across different
knowledge bases and competence levels will tend to be a costly
affair. Excluding those who are inexperienced from discussions
should thus save time and money. Expensive communicative
effort will then only be granted for the interaction between
experienced members, whereas those who are not so experienced may work alone with more focus on their assigned tasks
(Enberg et al., 2006). Yet, the roles of the core integrators and
the technical specialists were clearly complementary and vital to
the operation of the project team.
Interestingly, although the Turbine project as a whole scored
extremely low on the TWQ indicators (Hoegl and Gemuenden,
2001) it was successfully concluded. Such a result gains support
in a multiple case study of construction projects (Baiden et al.,
2006, p. 22), showing “that fully integrated teams are not
necessary for effective team operation within the industry”.
Furthermore, a questionnaire study of software development
teams, using the TWQ construct, reports that teamwork quality
actually has a negative moderating effect on the relation between
creative-thinking skills and team efficiency (Hoegl and Parboteeah, 2007). Hence, using a highly ‘integrated’ instead of a
‘segregated’ team may not always be beneficial. In particular, our
own study of the Turbine project here suggests that a segregated
team might be an appropriate design solution in a highly complex
knowledge integration context.
Finally, it should be pointed out that using a strongly
segregated team may be a viable solution in the short run, and
projects of course by their very nature tend to be just that, i.e.
subject to tight limits of both time and budget. However,
segregation may come at a price. As described above those who
are not really let in and involved will tend to become somewhat
demotivated and less committed to achieving the global project
goal. Apparently, this may mean that novel and potentially
valuable ideas from these ‘outsiders’, are being ignored, and
that it becomes less easy to counteract the development of too
strong ‘group think’ (Janis and Mann, 1977) tendencies of the
core group. In our case little was done to counteract such
consequences. Another thing that tends to be neglected in such a
segregated team context, is the long-term development of
personnel. Here, much more of master–apprentice-like learning
could have been carried out as the Turbine project went on.
However, although the firm did recognize such a need, it was
seen as something that should not be dealt with within the
context of the ongoing project.
References
Alvesson, M., Deetz, S., 2000. Doing Critical Management Research. SAGE
Publications, London.
Baccarini, D., 1996. The concept of project complexity — a review.
International Journal of Project Management 14 (4), 201–204.
Baiden, B.K., Price, A.D.F., Dainty, A.R.J., 2006. The extent of team
integration within construction projects. International Journal of Project
Management 24, 13–23.
Carlile, P.R., Rebentisch, E.S., 2003. Into the black box: the knowledge
transformation cycle. Management Science 49 (9), 1180–1195.
Dyer, W.G., Wilkins, A.L., 1991. Better stories, not better constructs, to
generate better theory: a rejoinder to Eisenhardt. Academy of Management
Review 16 (3), 613–619.
Enberg, C., 2007. Knowledge Integration in product development projects. Ph.D.
dissertation, Department of Management and Engineering, Linköping University,
Sweden.
Enberg, C., Lindkvist, L., Tell, F., 2006. Exploring the dynamics of knowledge
integration: acting and interacting in project teams. Management Learning
37 (2), 143–165.
Grandori, A., 2001. Neither hierarchy nor identity: knowledge-governance
mechanisms and the theory of the firm. Journal of Management and Governance
5 (3–4), 381–399.
Grant, R.M., 1996. Toward a knowledge-based theory of the firm. Strategic
Management Journal 17, 109–122 (Winter Special Issue).
Hoegl, M., Gemuenden, H.G., 2001. Teamwork quality and the success of
innovative projects: a theoretical concept and empirical evidence. Organization
Science 12 (4), 435–449.
Hoegl, M., Parboteeah, K.P., 2007. Creativity in innovative projects: how
teamwork matters. Journal of Engineering and Technology Management 24,
143–166.
Hoopes, D.G., 2001. Why are there glitches in product development? R&D
Management 31 (4), 381–389.
Janis, I.L., Mann, L., 1977. Decision Making: a Psychological Analysis of
Conflict, Choice and Commitment. Free Press, New York.
Katzenbach, J.R., Smith, D.K., 1993. The Wisdom of Teams — Creating the
High-performance Organization. McGraw-Hill, London.
Kratzer, J., Gemuenden, H.G., Lettl, C., 2008. Balancing creativity and time
efficiency in multi-team R&D projects: the alignment of formal and informal
networks. R&D Management 38 (5), 538–549.
Lawrence, P.R., Lorsch, J.W., 1967. Organization and Environment: Managing
Differentiation and Integration. Division of Research Graduate School of
Business Administration, Harvard University, Boston.
Lindkvist, L., 2005. Knowledge communities and knowledge collectivities: a
typology of knowledge work in groups. Journal of Management Studies 42 (6),
1189–1210.
Lindkvist, L., Söderlund, J., Tell, F., 1998. Managing product development
projects: on the significance of fountains and deadlines. Organization Studies
19 (6), 931–951.
Author's personal copy
C. Enberg et al. / International Journal of Project Management 28 (2010) 756–765
Nationalencyplopedin (NE), 2010. http://www.ne.se/lang/segregration.
Nonaka, I., Takeuchi, H., 1995. The Knowledge-creating Company — How
Japanese Companies Create the Dynamics of Innovation. Oxford University
Press, New York.
Orton, J.D., Weick, K.E., 1990. Loosely coupled systems: a re-conceptualization. Academy of Management Review 15, 203–223.
Perrow, C., 1970. Organizational Analysis: a Sociological Review. Tavistock
Publications, London.
Postrel, S., 2002. Islands of shared knowledge: specialization and mutual
understanding in problem-solving teams. Organization Science 13 (3), 303–320.
Rosenbloom, R.S., Christensen, C.M., 1994. Technological discontinuities,
organizational capabilities, and strategic commitments. Industrial and
Corporate Change 3 (3), 655–685.
Sauser, B.J., Reilly, R.R., Shenhar, A.J., 2009. Why projects fail? How
contingency theory can provide new insights — a comparative analysis of
NASA's Mars Climate Orbiter loss. International Journal of Project
Management 27 (7), 665–679.
Schmickl, C., Kieser, A., 2008. How much do specialists have to learn from each
other when they jointly develop radical product innovations? Research Policy
37 (3), 473–491.
765
Shenhar, A.J., 2001. One size does not fit all projects: Exploring classical
contingency domains. Management Science 47 (3), 394–414.
Simon, H., 1962. The architecture of complexity. Proceedings of the American
Philosophical Society 106 (6), 467–482.
Thompson, J.D., 1967. Organizations in Action. McGraw-Hill Book Company,
New York.
Tsoukas, H., Hatch, M.J., 2005. Complex thinking, complex practice. The case
for a narrative approach to organizational complexity. In: Tsoukas, H. (Ed.),
Complex Knowledge — Studies in Organizational Epistemology. Oxford
University Press, Oxford.
Weick, K.E., 1995. Sensemaking in Organizations. SAGE Publications,
London.
Weick, K.E., 2001. Technology as Equivoque: sensemaking in new technologies. In: Weick, K.E. (Ed.), Making Sense of the Organization. Blackwell
Publishers, Oxford.
Williams, T.M., 1999. The need for new paradigms for complex projects.
International Journal of Project Management 17 (5), 269–273.