managing complex development project

Managing complex developmentprojects: arenas, knowledge processesand time

Jonas Soderlund

School of Management, SE-58183, Linkoping University, [email protected]

The literature on project management has been dominated by techniques and methods for separatingactivities and making thought out plans. Closely related to this research stream is the research on productdevelopment, which seems to advocate somewhat of a different strategy where managing projects is amatter of enabling the crossing of functions and knowledge bases. This paper attempts to integrate thesetwo lines of research.

The paper is based on two in-depth case studies of project management in product developmentcontexts. The projects under study were highly complex and consisted of multiple interrelated parts,which called for tightly coupled organizational solutions. From our point of view, much effort by theproject management teams was put into establishing a project that was responsive and whereparticipating local units were oriented toward various global measures.

In our conception, the overall deadline seemed to have played an important role for promotingcommunal and interactive problem solving. Furthermore, the deadline emphasized the need for globalarenas where the interactive problem solving could take place. It is argued that time-based controls set aglobal time for the project. The paper also demonstrates the importance of various global arenas, such astesting activities and project management forums, in order to keep track of time limits and to triggerglobal knowledge processes. Furthermore, based on the notion of separation and coupling of sub-systems and project phases, the paper suggests a model identifying four types of project organizations.The paper contributes to the knowledge on project management in complex product development.

Introduction

T he increasing projectification of industries hasled to some fundamental changes in the way firmsorganize product and process development (Midler,1995). For several reasons, projects have becomeimportant vehicles and mechanisms in many firmsoperative and strategic business activities. A productand system development project is a typical example.Due to a number of reasons, such as time-basedcompetition and fast technological progress, managingsuch a project poses a multitude of challenges. Forinstance, in the automotive and telecommunications

industries, a project is a complex endeavour involvinghundreds of engineers and a great number of sub-projects. The requirements of both meeting the overalldeadline and integrating the various knowledge basesinvolved stands at the fore of project management.In recent years the complexity of product develop-

ment efforts has escalated paired with pressures onrapid product development (Clark and Fujimoto,1991; Imai et al., 1985; Stalk and Hout, 1990).Empirical studies, for instance Gersick (1988, 1989)and Eisenhardt and Tabrizi (1995), suggest thatmilestones and time limits are important issues fororganizing such projects and also for speeding up

R&D Management 32, 5, 2002. # Blackwell Publishers Ltd, 2002. Published by Blackwell Publishers Ltd, 419108 Cowley Road, Oxford OX4 1JF, UK and 350 Main Street, Malden, MA 02148, USA.

Breaking projects into milestones with time limits is an important way of organising and managing complex projects.

product development. In our opinion, time-basedcontrol mechanisms should be focused in order tounderstand important aspects of project organization.Our argument is also that time-based controls havenot been researched thoroughly enough in previousresearch. Although several authors acknowledge theimportance of lead time (see e.g. Clark and Fujimoto,1991; Nonaka and Takeuchi, 1995), the significanceand function of the deadline as such and the milestonesalong the way have been given scant attention. Thispaper builds on the argument that time-based controlshave to be considered a key ingredient in theorganization of product development. Time shouldconsequently also be considered to be one of the mainfocuses of studies of project management.The project management literature generally focuses

on planning activities, introducing work breakdownstructures, Gantt-schedules, etc., very much in linewith a rational view of organizational processes(Burke, 1994; Cleland and King, 1968; Kerzner,1995). Such a view, however, presupposes that aproject is highly analyzable (Lindkvist et al., 1998).Hence, given that many projects are devices tofacilitate and manage integration in firms, moresophisticated solutions are required. Integration isthus not handled through the exclusive use of advancedplans but on principles that are characterized by ahigher degree of coupling due to the reciprocalinterdependence inherent in most complex productdevelopment projects (cf. Mintzberg, 1983; Thompson,1967). A key problem in project management researchis also that every project is treated similarly (see e.g.Shenhar, 1993). A basic assumption underlying thestudies reported in the present paper is that projectmanagement research is in need of a clearer con-tingency approach and theoretical concepts in order toanalyze the differences between projects. In this paper,therefore, a model identifying different project organi-zations will be suggested.In several engineering-intensive industries, products

tend to form complex systems (Hobday, 1998).Different authors have suggested alternatives forresolving the organizational problem caused by suchcomplexities. As argued above, scholars in projectmanagement advocate a planning-oriented approach(e.g. Burke, 1994). Some researchers in productdevelopment advocate modularization as a strategyfor handling such complexity (Sanchez and Mahoney,1996), whereas others acknowledge the limitationsrelated to extensive modularization in product devel-opment (Hobday, 1998). An alternative approachwould be the use of methods such as design structurematrixes, stand-alone cross-functional teams, etc. inorder to decompose the complex system into separabletasks and teams (Ulrich and Eppinger, 1995). Not-withstanding the efforts of such a priori efforts to solvethe complexity problem, the role of project manage-ment during the course of the project is considered to

be of great importance (see e.g. Wheelwright andClark, 1992). In order to understand the role and workof project management, we need more explicitly focuson the problems that face project management andhow the problems are handled and solved. As put byShenhar and Dvir (1996, p. 607), the wide deploymentof projects in organizations today, has not beenaccompanied ... by a parallel development in projectmanagement theory and as an organizational con-cept, project management is quite new and probablynot well-understood. We argue that in-depth studiesare required to improve our knowledge about projectmanagement in complex product development. In-depth studies of project management have also beencalled for by several researchers within the field ofproject management (see e.g. Lundin and Soderholm,1995; Midler, 1995; Packendorff, 1995).Our case-study firms, Ericsson and Volvo are

typical examples of firms relying heavily on projectmanagement in complex settings. These and similarfirms have to acquire, nurture and integrate a widerange of technological competencies in order tocompete (Granstrand, 1998). Ericssons activitiesinclude the development, production and installationof complete mobile telephone systems consisting ofradio-base stations, switches, etc. In the Japaneseproject, illustrated below, Ericsson was challengedwith a very complex product development task, whichinvolved coordination of the work of hundreds ofparticipants. The development activities covered thegeneration of new knowledge, but also to a largeextent the exploitation and re-combination of exist-ing knowledge bases. The situation was similar in theVolvo case, also illustrated below. The developmentof the new car model The Volvo S70 involvedhundreds of engineers and a large number of localunits and knowledge bases. The case studies indicatethat to understand these projects we should adopt aperspective that enlightens both knowledge andtime aspects. Specifically, we suggest, studies need toemphasize activities related to the global level con-cerning system-wide error detection and time syn-chronization to balance knowledge processes withglobal time limits.The paper points to the importance of different types

of arenas for handling the integration of distributedknowledge processes into a well-functioning whole.Moreover, the paper focuses on how project manage-ment uses these arenas as mechanisms for early errordetection between local units and local knowledgeprocesses. In our conception, project organization is animportant arrangement to manage the dispersed timeorientations and local knowledge processes withina firm. Further, to better our understanding ofproject management as an organizational concept, wesuggest a focus on issues related to how timeorientation and knowledge processes are handled. Inthe analysis section, we will therefore make use of the

Jonas Soderlund

420 R&D Management 32, 5, 2002 # Blackwell Publishers Ltd 2002

knowledge-based theory of the firm (Spender, 1996;Grant, 1996) and theories of time orientation inorganizations (Ancona and Chong, 1996) in order toimprove the knowledge of project management incomplex product development.

The coupling logic: a point of departure

In previous research we have elaborated on acontingency framework of complex product develop-ment projects (Lindkvist et al., 1998). In doing so werelied on a two-dimensional reasoning in order tohighlight important task aspects of projects. The firstdimension distinguishes between development pro-cesses that are systemic from those that are analyz-able. In this conception, systemic processes refer tosituations where work activities and causal relationsand sequences between them are difficult or impos-sible to specify in advance. The main reason is theexistence of severe and unforeseeable technical inter-dependencies. For analyzable processes, on the otherhand, such specifications are relatively easy to settle.The dimension of complexity used here is similar tothe writings of other organization theorists (see e.g.Perrow, 1970).The second dimension was built around the distinc-

tion between error detection and error diagnosticsdeveloped by Levinthal and March (1993). In errordetection situations, a low degree of technical knowl-edge generation is required in order to handle eachindividual error. A key problematic is, instead, toachieve a global, or system-wide, search for errors.Error diagnostics, on the other hand, illuminatesproject contexts that involve more fundamentaltechnological problems, where the detection of errorsis of less concern. The error problematics dimensionthus differentiates between project contexts thatrequire less knowledge generation from those wheredeep or specialized knowledge generation is essential.Relying on March (1991), we would expect errordetection to be a common feature of projects that arerelated to knowledge exploitation, while error diag-nostics would typically be paramount in projects thatare related to the exploration of new possibilities.We assume that a large number of product and

system development projects involve processes that aresystemic. Similar assumptions have been made byscholars on product development (Clark and Fujimo-to, 1991) and Complex Product Systems (Hobday,1998). The systemic character of such projects meansinter alia that it is difficult to make clear inferencesabout the relationships between the contributingparts and sub-projects. Furthermore, it would also beassumed that complex development projects aim atexploiting and integrating the distributed knowledgebases in a firm. This standpoint is, of course, morecontroversial. However, much previous research on

development projects have pointed to the core problembeing the integration of existing (technological) knowl-edge bases (e.g. Baba, 1990).The assumptions above suggest that the manage-

ment and organization of many development projectsis a matter of following a coupling logic. The couplinglogic stresses the need for a high degree of inter-functional responsiveness and downplays functionalautonomy and separation of activities. Organizing inorder to achieve responsiveness and error detectionstresses the need for frequent or continuous commu-nication between the various sub-projects and the needfor setting up arenas where such formal and informalinteraction may take place. It also stresses a differentrole of project management in facilitating theseprocesses. As it seems, organizing according to acoupling logic is very different from the logic typicallyadvocated in much project management writing.This article is an investigation into the management

and organization of coupled projects. The idea is todraw on case studies of two quite different projects inorder to illustrate the role and function of projectmanagement in such contexts. Our aim is also toelaborate on a conceptual framework for the analysisof different types of project organizations in order tounderstand the various roles and functions played byproject management. This will be done by (a) identify-ing and analyzing different types of project organiza-tions, and (b) suggesting an analysis of complexdevelopment project inspired by the literature on theknowledge-based theory of the firm and time inorganization.

Methodology and research setting

This paper is based on case studies of two developmentprojects in different Swedish firms; Ericsson Radio andVolvo Car Corporation respectively. Both projectswere of high strategic importance and were perhaps thetwo most important development projects carried outin the two firms respectively during the 1990s. The firstcase study is about the breakthrough in Japan forEricsson Radio. In 1992 Ericsson succeeded in winninga prestigious contract with Tokyo Digital Phone todevelop and install a cellular telephone system in theTokyo metropolitan area. The system was to be fullyoperative in 1994. The project forced managementto reconsider their traditional way of working withprojects and to implement a new one instead labelledthe fountain model with greater reliance onconcurrent work and inter-functional coordinationand interaction. As a result they managed to shortendevelopment time quite considerably and deliver thesystem on time. Important issues for the managementof the project was the use of deadlines and milestonesalong with increased overlap and interaction betweendifferent functional units.

Managing complex development projects

# Blackwell Publishers Ltd 2002 R&D Management 32, 5, 2002 421

The second case study is about the development ofthe car model Volvo S70, which was launched early in1997. The project was a great challenge to the projectmanagement team in terms of meeting the overalldeadline and handling the fast production ramp-upaccording to the high quality standards. The projectled management to try new forms of integration offunctional units.The two cases are different in many aspects, for

instance, in industry context, in customer base, intechnologies applied, etc. However, they are alsosimilar in several respects, for instance, both projectswere considered to be highly successful, both projectshad a high strategic importance and the projects showsignificant resemblance in terms of how they wereorganized and managed.Generally, our studies were guided by an ambition

to combine the ideas of grounded theory (Glaser andStrauss, 1967) with the ideas of reflexive interpretationas discussed by Alvesson and Skoldberg (2000). Thestudies started as single case studies where we focusedon describing the project process chronologically. Wewanted to obtain a rich story about the context,background and organization process of both projects.Because of this, the case descriptions below contain anumber of quotes from the project participants. Thekey informants in each of the case studies were theproject managers. In the Ericsson case we interviewedthe division manager, two other members of thedivision management team, five functional line man-agers, the project office manager, three projectmanagers and four sub-project managers. In total weconducted 32 interviews, averaging two hours each. Inthe Volvo case we did 16 interviews, averaging threehours. In the Volvo case we interviewed two membersof the top management team, three line managers,two project managers, four sub-project managers, onetechnical specialist and two team leaders. Everyinterview was tape recorded and transcribed by theprincipal researcher. Details about the projects arereported elsewhere (see Lindkvist and Soderlund, 1996;Soderlund, 1998).The chronological description of each of the cases

was condensed into a document of about 50 pagesrespectively. The documents were produced by theprincipal researcher in collaboration with one of theparticipants in the research team. The documents wereread by three people in each of the projects (in bothcases the main project managers and in the Ericssoncase also the division manager). This made it possiblefor us to correct any misunderstandings and furtherdevelop our knowledge about the projects. We alsodiscussed our tentative conclusions and within-caseissues with the company representatives. This processof starting with a within-case analysis followed theadvice provided by Eisenhardt (1989).In the subsequent phase of our research, we did a

cross-case analysis aimed at identifying the important

empirical patterns concerning the way the projectswere executed (see also Eisenhardt, 1989). The focus ofthe analysis was thus on these similarities, similaritiesthat we believe might be fruitful for further theoreticalconjectures on the viable organization of developmentprojects. These empirical patterns will be discussed in aseparate section following the case descriptions. Thefinal step of our analysis was to draw further on thegeneral insights generated from the case studies. Thesegeneral insights should then be connected to theoreticalframeworks and concepts that might be utilized andfurther developed in order to explain our case-studyprojects. One such general insight is a model identify-ing four types of project organization. Another one isan analysis of knowledge and time dimensions incomplex development projects.

The Ericsson case

The project was carried out under severe timeconstraints, which forced management to reconsidertheir traditional way of working. They went from awaterfall model to a fountain model, downplayingentry-criteria in order to start work with differentphases as early as possible and to integrate theknowledge from downstream activities with upstreamactivities.The project model used in the project just terminated

before the start of the Japan project the GSMproject was called the waterfall model, a label alsofound in much project management literature (e.g.Brooks, 1995). In this model the different activities andparts of the project were sequentially ordered andsharply separated from each other by well-defined exitand entry criteria. As a result later stages or down-stream activities did not start until the exit conditionsof earlier ones had been fulfilled. When such a decisionwas taken, the next (functional) unit assumed theresponsibility. This particular procedure is well illu-strated by the frequently used metaphor of throwingthings over the wall.The new model was labelled the fountain model.

Unlike the waterfall with water flowing sequentially,the image of the fountain was one of water streamingsimultaneously from many sources. Generally such amodel may be conceived of as one relying on work in amore concurrent fashion. As applied within Ericsson,the main difference between the models was in the waydownstream teams were involved early in the projectprocess. In fact, a basic idea behind the fountain modelwas to have much of the development and design workdriven by downstream phases. In order to have allparts of the project start early, entry criteria wereheavily downplayed. Another notable trait was theemphasis on feedback information, generated byfrequent milestones and practical tests of sub-partson a system-level. The various tests were not only

Jonas Soderlund


frequent but also carried out in quite public settings.As a consequence, it was made more obvious howdelays in one part of the project would affect the workin other parts or the pace of the entire project. Whereasin the waterfall model, delays and mistakes in onefunctional unit or development stage could be treatedlargely as their internal responsibility, the fountainmodel promoted communal responsibilities and a newway to combine knowledge from different local units.Figure 1 is a stylized version of the one used in theproject. The bars in the figure indicate the workprocess of a specific unit in the project.For several units in the Japan project this meant

that, as the figure indicates, they had to be involvedover a longer period than would have been the case ifthe waterfall model had been applied. This did not,however, imply that these local units were exposed tofewer milestones, tests and controls during the processpreceding the final, nearly simultaneous exit. Indeed,as indicated above, rather the contrary was true. It wasalso underlined that the fountain model would requirea more network-like organization, based on inter-functional integration and continuous dialogue.

The traditional waterfall model for the design workcannot be followed. In order to shorten developmenttime the various tests within the objects must beoverlapping. This requires tight communicationbetween the sub-parts concerned within each object.Production preparation must, for example, beinitiated at the same time as product design.Normally such an activity starts 1018 months afterdesign has started. The parallel design approach alsorequires that the integration and verification phasesmust begin as soon as possible. Normally such anactivity begins 1824 months after start of productdesign.

(Excerpt from Internal Document)

The fountain model implied that the way failureswere viewed had to be different. For example, one ofthe project leaders expressed it in the following way.

It is most important to realize that it is all a matterof doing right the first time. But it is just asimportant to realize that it will not work at once.

What you need is the courage to fail, and never giveup.

While the responsibility for many project activitiesand sub-parts of the product was clearly allocated toseparate functional teams, the relations between theparts and the teams could not be specified entirely inadvance. What kind of problems that would show upwhen integrating the pieces could not be anticipated.As a way of handling this problem, the metaphor ofpracticing the processes was used as an importantguide.

You have to find out what is easy and what isdifficult. Therefore you have to start with the partsthat are difficult and test and practice the organiza-tion. In one case we did some parts several timesover and over again. The people who are supposedto receive what has been designed in an earlier stepmust understand what they have received. For thisreason we made some parts run through the chainjust to check they were working. It is all a matter ofpracticing the processes early. You never hit thetarget the first time. We had to use very concretemodels, work very close to the processes of theorganization thats what I call active leadership

(Project Manager).

The integration of different parts of the projects andthe activities of local units required arenas whereinformation could flow between the phases of theproject. Management invented integrating mechanismssuch as the systems emergency ward, which was aforum for problem solving and discussions of all kindsof issues in the project. In these meetings, in someperiods held almost on a daily basis, every memberof the project could put a question on the agendawhenever necessary.To be able to handle this new way of working,

managers and members of the project were certainlybusy establishing communication channels and workmodels that cut across the organization. One of theproject leaders formulated the philosophy in thefollowing terms:

You have to get people to understand other partsthan their own. As an example the designer wants

Time

= milestones, tests of sub-parts, etc.

ExitEntry

Figure 1. The fountain model (stylized). Source: Internal Document.



functionality, whereas the production engineerwants a product suitable for production. The testengineer, on his part, wants a product that is easy totest. It is all about getting these people to worktogether and getting a product that fits everybody.

The project management team saw it as one of itsmost important tasks to inform the organization aboutthe mission of getting Ericsson to Japan. A greatnumber of efforts were thus put into informationactivities in the project. Also at technical levels,information had to flow rapidly.

There was a constant need for information through-out the different phases of the project. For us inthe project management team it was a matter oforganizing the information flow to create a fast andflexible project. For example, we used video andtelephone conferences, project newsletters and shortmeetings, which were often held daily. Moreover, thesystems emergency ward was a forum where troublereports were dealt with. In this forum we had someof the most competent Ericsson people within thisarea. We could therefore respond very quickly andmake fast decisions

(Project Leader).

However, the project managers realized that infor-mation flows of various kinds would not be enough.They talked about practicing the organization inorder to get people to understand other parts thantheir own. They also realized the need for face-to-facegatherings with a practical and concrete focus. Whenthe first radio base stations were manufactured, theproject management team organized a quality demon-stration, which is a typical example of how processeswere practiced.

We ordered a radio base station from the warehouse.Everybody thought that it was destined for shipmentto Japan. However, we arranged a quality demon-stration in Stockholm and invited top management,quality managers, designers, etc. When we did thisdemonstration, it turned out that the product didnot work. There were all kinds of problems, such asmechanical problems, packaging problems, thingswere missing that created an enormous attention. Ithink this was the first time that the designers hadseen a complete radio base station

(Project Leader).

During the Japan project the deadline was verydefinitive and unambiguous. This provided the orga-nization as a whole with a very clear goal a fullyoperative system by 1 April 1994. The core of theproject management team was the project manager,who had experience from the GSM project, and twovery experienced project leaders. An important task forthe project leaders was to create a strong focus on thefinal deadline and the milestones along the way.

If we said that it was to be ready by Friday, we didnot accept anything else. If it did not work we huntedthe person responsible for the delivery no matterwhere he was. You have to get people to understandthat next week is too late. Trying hard is not enough.It is only success that counts nothing else

(Project Leader).

The Japan project was finalized successfully. Thesystem was put into operation on 1 April and theorganization has received recognition for the waythe project was managed and the successful outcome.The project has also led to several new organizationalpractices, which have been adopted and applied inother divisions within Ericsson.

The Volvo case

In 1991, the Volvo 850 was launched and the companyentered an extensive cooperation with Renault. How-ever, the cooperation was abruptly terminated in late1993 because the shareholders and employees of Volvodid not approve of the merger plans that the topmanagement of the two companies had worked out.This led Volvo into a rather complicated situationbecause joint-development activities were terminatedand the company was in urgent need of a new carmodel. Management discussed several options anddecided to prolong the life of the Volvo 850, launchingit as an almost new car under a new label, the VolvoS70. The car had to be improved in a multitude ofaspects and both interior and exterior designs had to bechanged and renewed. A development project wasinitiated in mid 1994 to develop a car that was readyfor market launch in the beginning of 1997. The projectforced management to reconsider several of its oldideas of working and organizing. For example, a tightoverall deadline and a fast production ramp-up wereconsiderable challenges facing the people in charge ofthe S70 project. The project was considered to be ofgreat strategic importance for the company and alearning opportunity for future activities, for instance,in terms of production ramp-up and project organiza-tion. The company was during this period of timeunder much pressure following the failed merger withRenault. Management had to prove that the companycould stand on its own feet and develop a car modelthat was a sign of the companys future ability todevelop cars on its own.

There were a lot of difficult things about this project.We were to terminate the production of the Volvo850 and only a couple of days later start fullproduction of the Volvo S70. If we wouldnt make itwed read about it in the papers and hear about it onthe TV news. Such a fast production start has nevertaken place in this company

(Sub-project Manager 1).

Jonas Soderlund


Due to these reasons, management attention wasvery high during the course of the project. The projectmanagement team also worked intensely with commu-nicating the importance of the overall deadline andthe importance of the production start. They wanteda shared view on the project, to develop a projectculture, a sense of urgency and improved sharedresponsibility.

As a project manager, its important to understandthat a shared vision and view is key. Weve got tosolve this project. We need to help each other. Weneed to talk to each other. We need to establishcontacts between different parts of the project. Forexample, its not sufficient that the manufacturingpeople do a good job in order for this project to besuccessful. Everyone has a part in it, and to getpeople to understand that was our main responsi-bility

(Project Manager, Purchasing).

Focus had to be put on the overall deadline and themilestones along the way.

Again, and again, its this thing with the time planand to get people to understand that the finaldeadline was December 10, 1996. It was the BigBang! At that time everything had to work. All thetests had to be made before that, and all details hadto be verified. The final deadline was non-negoti-able. It was a fact!

(Project Manager, Purchasing).

In the S70 project, much effort was put intoinformation sharing by establishing various channelsof information. Furthermore, the project managementteam knew that the design of a certain detail was notthe complicated issue, instead, they emphasized, thedifficult thing was to know what to do.

In a project like this, the network of contacts wasvery important, if not the most important thing. Thepure design issues were not very complicated, whatwas important was to know what to design, and tounderstand how it would work in the system thosewere the tricky issues

(Technical Project Manager).

Throughout the whole project, the project managerstried to establish a well functioning cooperationbetween the participating units within the project.Emphasis was put on the so-called design reviewmeetings and to get well-functioning communicationchannels on lower levels within the project wheremanufacturing and design were integrated.

We had morning prayers every Monday. A one-hourkick-off for the week. It was really good, relaxedand informal without official records. We answeredquestions like: what was ahead this week? All thesub-project managers participated. But we also had

project meetings once a week, and technical meetingseach week. We had more frequent meetings than isusual and we tried to keep them on a practical level

(Technical Project Manager).

Moreover, the role of project management ascreators of tension was emphasized by everyoneinvolved in the project.

Its important that manufacturing call for informa-tion and action in early stages of the project. Thatcreates a kind of tension, which is extremelyimportant in order to get something to happen andfor us to try new ways of working

(Project Manager, Geometry).

The Volvo case points to interesting issues concern-ing the work of project management and the impor-tance of time limits. One important question for theproject managers was to achieve an appropriate targetlevel for the different designers and engineers involved.The technical project manager expressed this particularproblem in the following way.

Designers have the tendency to search for the perfectsolution and not always for the solution suitable forthe system. They never finish. Its in the nature of adesigner not to complete but instead to keep onworking and developing the piece. The role ofproject management is to set the limits of what isgood enough.

Moreover, during the project process there was aconstant dialogue between the different sub-projectsand sub-parts of the project and the project manage-ment unit. Much attention was directed towardscommunication and to get upstream units to see thewhole picture. As explained by one of the sub-projectmanagers.

Its all about organization and communication andto get people see whats happening in production.Designers are good at many things but not onaspects related to the production process. Everyonethinks their part is working well but its all aboutverification. This means that we need to constantlydiscuss possible alternatives of action. For instance,which parts to change is dependent on the lead-timeof each part. Whether a certain part is consideredverified is thus very much a question of what otherteams have done


Furthermore, the project leaders emphasized theneed and function of such meeting and testing placesthroughout the life of the project. One of the projectleaders describes the philosophy in the following way.

The overall testing activities are excellent opportu-nities to bring together the various functions,determine the degree of progress and analyze howalternative solutions might interrelate at a certain



point in time. These activities are important devicesfor cross-functional discussion and problem solving.The project management team that uses theseactivities forcefully will make a better car


The Volvo S70 project was completed on time andwas considered a successful project. The project forcedthe company to adopt a number of important newways of organizing its projects. The general reason forthe good result was, according to the project manage-ment team, the many try-outs and test activities carriedout and the way production and design were inte-grated. In the interviews the project managers pointedto the public settings and practical gatherings inmoving the project forward. They also pointed to theimportance of meeting face-to-face and solve practicalproblems. One project manager expressed the generalidea in the following way:

Public settings are very important. It is important tofeel that youre part of an organization and why thisproject is important. Then it is important becauseyou see the consequences of what you do. We hadso-called supplier gatherings where we invited thekey engineers and key suppliers and worked on avery practical level. We checked and tested if thethings were working. This gave attention and wasvery good for the motivation spirit of the project.


Emerging empirical patterns

The projects presented above are similar in somerespect, but also very different. They are different interms of industrial context, in terms of products andtechnologies integrated, but they show some interestingsimilarities in project management logic and importantproject management mechanisms. In this section wewill point to the empirical patterns found in the casestudies.First, it seems appropriate to describe both projects

as carried out in a systemic complex situation. Second,the main question for the projects was not a searchfor entirely new knowledge, but more of integratingalready existing knowledge bases. The projects wouldthus benefit from the coupling logic discussed earlier.It seems plausible to suggest that both projects

described above were heavily influenced by tight timeconstraints. The strategic importance and the timeconstraints seem to have led to some profoundorganizational changes and rethinking. This was, forsure, facilitated by management commitment, topmanagement attention and good leadership performedby the project managers. However, in both cases, theproject managers acknowledge the immense impor-tance of tight deadlines in order to make things happenand to be able to try out new solutions. In the Ericsson

case this led to a totally new development model, thefountain model. In the Volvo case, this led to a newstrategy in terms of production ramp-up and use oftesting activities, such as tryouts. We would argue thatthe focus on time-based controls and deadlines isnecessary in order to understand the types of projectsstudied in this paper. As mentioned earlier, muchproject management and product development re-search has only given limited attention to time as anindependent variable for understanding organization.Furthermore, the tight deadline and the organiza-

tional innovations seem to have led to an increaseduse of different types of global arenas. This was, forinstance, important in the Ericsson project whereproject management relied heavily on the work carriedout within the systems emergency ward and differenttypes of quality demonstrations. In the Volvo case,management relied, not only on several types ofmeetings, but also on practical tests such as try-outsand supplier gatherings. Interestingly, in both cases,the interviewees declare the most difficult thing asfinding out what needs to be done, not doing the thingitself. An additional salient feature was the down-playing of entry criteria in order to involve down-stream units as early as possible. This was not onlydone for speeding up the process, but for combiningdifferent specialists knowledge early on in the projectprocess. We would argue that these arenas representimportant project management mechanisms whichmust be explored in order to improve our knowledgeof project management in complex product develop-ment. Below we will further the theoretical interpreta-tion of project management in such a context.

A further analysis of the coupling logic

Analyzing the specific forms of project organizationthey represent different but similar departures from atraditional functional-sequential logic. Both examplesseem to be inspired by ideas of concurrent engineeringand are as such organizational solutions that elimi-nated buffers between functional units in order tospeed up signals of emerging problems. In the classicsequential waterfall model, on the other hand, feed-back and learning are locked-in and separated stage-wise or limited to the transitional stages of exit-entry.The fountain model, for instance, seems to haveproduced feedback that was more global. In essencethe model represented an effort to make the projectprocess more tightly coupled.One important challenge facing the project manage-

ment teams in the cases, seems to be to handle thecomplexity stemming from the great number ofunits and individuals participating in the projects.What seems to be important here is to get all thecomponents, such as hardware and software, interiorand exterior, to function well together, and to be

Jonas Soderlund


manufacturable and reliable. As the interviewees inboth case studies declared, in such complex situationsdoing things right the first time is probably notpossible. It was likely that dealing with many types oferrors would be unavoidable because of the difficultiesassociated with a priori specifying the outcomes of thecomplex interactions involved. Errors showed up atfunctional interfaces, when parts from different unitswere combined and integrated. However, while theseerrors were both numerous and hard to foresee,most of them were rather easily taken care of by theparticipating units. In such situations, communalproblem-solving activities as frequent testing of com-posite parts or whole systems, several tryouts andpracticing organization, became important projectmanagement events. These events also representimportant aspects of the knowledge processes takingform during the course of a project.

Projects and knowledge processes

As indicated previously, error detection versus errordiagnostics is probably a fundamental distinction ofknowledge processes in project contexts. By focusingon knowledge processes in project settings we mightrely on parts of the literature on the knowledge-basedtheory of the firm (Spender and Grant, 1996).According to Spender (1996), a knowledge-basedtheory of the firm can be seen as a platform for anew view of the firm as a dynamic, evolving, quasi-autonomous system of both the production andapplication of knowledge. Moreover, Grant (1996)emphasizes that the fundamental task of organizationis to coordinate the efforts of many specialists. Theknowledge-based theory of the firm identifies the firmsprimary role as integrating the specialist knowledgeof individuals into viable outcomes, such as goodsand services. The prime role of management in sucha perspective would involve the facilitation for thisknowledge combination, e.g. by establishing andopening up arenas and creating channels for informa-tion and knowledge sharing.Viewing the project managements primary task as

integrating the specialized knowledge of multipleindividuals suggests that, even with goal congruence,achieving effective coordination is problematic fororganizations. Furthermore, a knowledge-based viewof projects suggests a perspective on interdependenciesas an element of organizational design and subjected tomanagerial discretion rather than exogenously drivenby given task characteristics. A key problem here isthus to device mechanisms for the combination of localunits or individuals specialized knowledge. Conse-quently, an important issue is to realize that processtechnology defines the technical aspects of productionand the types of specialized knowledge required for theprocess, whereas the task division between individuals

and local units and the specification of the interfacesbetween them is a matter of organizational design.In organization theory it has generally been assumed

that certain tasks require more personal and commu-nication-intensive forms of integration. For instance,Galbraith (1973) and Perrow (1967) stress that high-interaction, non-standardized coordination mechan-isms increase with task complexity and task uncer-tainty. It has also been shown that groups in situationsof crisis switch from a routine-mode to groupproblem-solving (Hutchins, 1991). However, knowl-edge-based literature also emphasizes that redundancyis an important issue related to every knowledgeprocess. This implies sharing information that goesbeyond the operational requirements of participants.In turn such redundancy creates opportunities forindividuals to invade one anothers functional bound-aries (Grant, 1996, p. 115). In understanding projectmanagement in complex development projects, wemust acknowledge its role for the organization andfacilitation of such knowledge processes.

A typology of project organizations in complexproduct development

In previous sections, we discussed important technol-ogy aspects of development projects and illustrated thecoupling logic with our two cases. In the projects understudy, there were several aspects that triggered thecoupling of local units. For instance, the tough timelimits paired with conscious managerial efforts topromote not only the overall deadline but alsofrequent, public milestones (e.g. arenas and manage-ment attention) along the way. These efforts seem toincrease complexity of the project process as they forceentry-criteria to be downplayed. Hence, several newparts of the projects had to be integrated and takeninto account. These parts also seemed to have alteredthe calculations and activities of earlier phases andthus created increased and necessary tension withinthe projects. The arenas functioned as a way tointegrate project phases by bringing downstream andupstream activities closer together early in the project.This would imply a device for achieving a type ofcoupling by combining the knowledge from laterphases with knowledge from earlier phases of theproject. Such coupling we therefore label coupling ofproject phases.Another coupling feature is the combination and

integration of different sub-systems. This wouldimply, for instance, the combination of knowledgeand interaction of engineers from different designpackages in a project, such as interior and exteriorteams in an automotive project, and base-stationengineers and switching engineers in a mobile phonesystem. Such combination of structural coupling,we label coupling of sub-systems. Based on this



coupling-separation analysis, we are able to suggestthe following model identifying four types of projectorganization.The different types of project organization could be

related to different types of project managementproblem and project management logic. In our case-study projects, much attention was directed towardsintegrating design and production as in the situationlabelled phased project organization. A typicalexample of a phased project organization would bea project where the interface between design andmanufacturing is relatively clear and well defined, orwhere interaction between these units is downplayedfor other reasons, such as local knowledge require-ments and priority. As emphasized by, for example,Wheelwright and Clark (1992), effective product andprocess integration is difficult in most circumstances,and particularly challenging in large, mature firms withstrong functional groups, extensive specialization andlarge numbers of people.In situations where the different sub-systems are

fairly separated, but the relationship between, forinstance, design and production is tightly coupled, wemight consider a modular project organization. Atypical example of a modular project organizationwould be a project where the interface between the sub-systems is well specified, or the need for coordinationbetween the sub-systems is limited for other reasons.Further, as argued by Hobday (1998, p. 706), despitethe trends of modularization, project managementskills remain at the heart of many companies, due tothe many difficulties in task specification and sub-system partitioning.The projects in the present study, however, were

fairly tightly coupled in both dimensions, i.e. asimultaneous tight coupling between sub-system teamsand project-phase teams was observed. In such asituation we might consider a project organization thatis multi-coupled. Project management thus had todeal with several interface problems and system-wideproblems that concerned both the relationship betweensub-systems and the relationship between downstreamand upstream activities. The typology presented would

increase our understanding of different types of projectorganizations and the various roles played by projectmanagement.

Projects and time orientations

In the above section, we discussed project coordinationfrom a knowledge perspective. From our point ofview, in order to understand the project managementproblem, we need to understand issues related totiming and rhythm. In this paper, we argue that, notonly system-wide knowledge processes have to beemphasized, but also the importance of time aspects.There are several reasons for this. First, manydevelopment projects are carried out under the lightof an overall non-negotiable deadline. Second,projects often are complex involving several knowledgebases and a plethora of engineers with different timeorientations whose activities need to be synchronized.A fruitful lens to gain such an understanding is the

one provided by the concept of entrainment. En-trainment is, to use the writings of Ancona and Chong(1996, p. 251) the adjustment of the pace or cycle ofone activity to match or synchronize with that ofanother. The concept hence focuses on the dominantmacro cycles that capture the pace and cycle oforganizational activities. The cycles of, for example,local units within a project are captured by a pacer sothey get the same phase, periodicity, or magnitude. Apacer is in our case played by project management thatutilizes other sources in order to increase its power (e.g.gaining top management attention, and pointing to thebad effects of a missed deadline). The pacer sets adominant temporal order or macro-cycle that servesas a powerful mechanism for coordination of thatspecific unit or function. This was clearly pointed outby the project managers in Volvo and Ericsson. The(enforced) overall deadline, in these cases, seems tofunction as an overall pacer for the local unitsinvolved.As pointed out in the cases, the overall deadline

together with various public milestones and system-wide arenas not only provided the projects with anessential medium for information and interaction, butwere also mechanisms for pacing the whole project.Broadly speaking, we might view the overall deadlinesand milestones as a pacer that are enforced by the useof these global arenas. Obviously, the pacer is alsoimportant for the synchronization and adjustment oflocal times (Lawrence and Lorsch, 1967). The overalldeadlines were considered to be non-negotiable, thus,as our previous illustrations indicated, they implemen-ted a global time (cf. Ancona and Chong, 1996). Thesystem-wide arenas also seem to be of importance forthe overall (global) knowledge processes that evolvedand developed during the lifecycle of the projects. Theargument brought forward here is thus that the global

Separated projectorganization

Modular projectorganization

Phased projectorganization

Multi-coupled projectorganization

Sub-systems

Separated

Coupled

Project phases

Separated Coupled

Figure 2. Types of project organization: separated or coupled.

Jonas Soderlund


level within a project has to be emphasized in orderto understand project organization in these contexts,and, additionally, that knowledge processes and timeaspects are intimately related and central to such ananalysis.As discussed above, time limits are of the utmost

importance for project management in general and forresearchers that set out to understand the logics ofproject organization. As stated, there are two primaryaspects of time that are important for the under-standing of complex development. The first one is theoverall deadline, the other is the synchronization ofactivities within a project. Concerning the first issue,we mainly treat deadlines as important controlmechanisms that alter the calculations of actors andfunction as a trigger for action and rethinking. Forinstance, in our case studies, time limits were so tightthat a separated project organization could not beapplied. In both of the cases the compressed timeschedules provided opportunities to introduce newways of organizing which improved the collaborativespirit of the projects.Apart from this overall project deadline and various

milestones related to it, there was also a great numberof regular meetings and arenas where specialists fromdifferent functional units met. Many of these, such asthe quality demonstrations, supplier gatherings andvarious practical tests, functioned not only as arenasfor solving problems of a communal character, butalso played an important role in pacing the projectwithin the given time constraints. As shown in the casestudies, the use of publicly stated promises and sharedresponsibilities for producing technical solutions en-couraged extensive communication among the variousfunctional specialists. Instead of having each func-tional unit work separately, they were forced intoglobal thinking and discussions about what wasefficient from a system-wide perspective.

Concluding discussion

Our studies have indicated that the coupling logic isimportant for several reasons. By eliminating buffers,downplaying entry-criteria, knowledge is combinedand time-limits are enforced. Instead of functionalbuffers, system-wide arenas seem to be vital for thecoupling logic to function, for deadlines to be met, andfor global knowledge to be developed. Hence, from aknowledge perspective these project managementmechanisms not only function as simple synchroniza-tion devices but also as ways to justify what is trueand to absorb the knowledge from each local unit.Coupled projects are thus interpreted as means tocombine knowledge under situations characterized bysystemic complexity where error detection is the keyproblem. Important features of such coupled projects,we suggest, are the concepts of global time, global

knowledge processes and global arenas. Global timerefers to the effects and role of overall deadlines andmilestones, whereas global knowledge processes referto the combination of local knowledge and the system-wide error detection processes. The global knowledgehere is thus the understanding of the interrelationshipsbetween the different parts in the system. A key projectmanagement mechanism to handle the differences inrates of time and the global knowledge processes,seems to be the active use of different types of globalarenas. As suggested in this paper, we need, in order tofurther our understanding of project management incomplex development, put greater emphasis on thefollowing aspects:

* Global arenas for enforcing deadlines and mile-stones, and facilitating channels for global knowl-edge processes.

* Global time, such as deadlines and milestones forpacing the entire project.

* Global knowledge processes for combining distrib-uted local knowledge processes and for justifyinglocal knowledge.

Our case studies have pointed to the importance ofrelatively sophisticated principles of organizing knowl-edge combination in complex development projects.As a result, for instance, we interpreted the fountainmodel as representing a coupling logic suitable forerror detection in a systemic context. Furthermore, westretched the coupling logic by looking at projects asconsisting of different knowledge bases. Subsequently,a model identifying four types of project organizationswas suggested based on the separation-couplinganalysis. We argue that this typology contributes tothe knowledge of management and organization indifferent types of complex development projects.Based on our case study observations, we submit

that the use of deadlines, milestones and other time-based controls, not only helps pacing the entire projectin relation to its overall time limits, but also supportsparallel project work by encouraging inter-functionalcommunication and reflection. Hence, to understandknowledge combination within complex developmentprojects we need an understanding of the impact oftime-based control mechanism. It has further suggestedthat deadlines, and other time-based control mechan-isms, function as globalizing mechanisms. This type ofprocess is generally associated with knowledge andtime aspects of organization. Our studies indicate thatknowledge processes are in several respects dependenton time. For instance, knowledge is justified by otherlocal knowledge processes and thus dependent on thesynchronization of their activities. Further, what mighthave been justified given certain preconditions dependson the lead-time for the adjustment and co-adaptationof other parts. Here we see that it is not so much whatlocal units have done in isolation and whether theiroutput is in line with predetermined standards, but



rather right against overall efficiency criteria at acertain point in time.

References

Alvesson, M. and Skoldberg, K. (2000) Reflexive methodol-ogy. London: Sage.

Ancona, D. and Chong, C. (1996) Entrainment: pace, cycleand rhythm in organizational behavior. Research inOrganizational Behavior, 18, 251284.

Baba, M.L. (1990) Local knowledge systems in advanced

technology organizations. In L. Gomez-Meija and M.Lawless (eds.), Organizational Issues in High TechnologyManagement. Greenwich: JAI Press.

Brooks, F.P. (1995) The Mythical Man-Month. Reading MA:Addison-Wesley.

Burke, R. (1994) Project Management: Planning and Control.

Chichester: Wiley.Cleland, D.I. and King, W.R. (1968) Systems Analysis andProject Management. New York: McGraw-Hill.

Clark, K.B. and Fujimoto, T. (1991) Product DevelopmentPerformance: Strategy, Organization, and Management inthe World Auto Industry. Boston MA: Harvard BusinessSchool.

Eisenhardt, K.M. (1989) Building theories from case studyresearch. Academy of Management Review, 14, 532550.

Eisenhardt, K.M. and Tabrizi, B.N. (1995) Accelerating

adaptive processes: product innovation in the globalcomputer industry. Administrative Science Quarterly, 40,1, 84110.

Galbraith, J.R. (1973) Designing Complex Organizations.Reading MA: Addison-Wesley.

Gersick, C.J.G. (1988) Time and transition in work teams:

toward a new model of group development. Academy ofManagement Journal, 31, 1, 941.

Gersick, C.J.G. (1989) Marking time: predictable transitionsin work groups. Academy of Management Journal, 32, 2,

274309.Glaser, B. and Strauss, A. (1967) The Discovery of GroundedTheory: Strategies for Qualitative Research. New York:

Aldine de Gruyter.Granstrand, O. (1998) Towards a theory of the technology-based firm. Research Policy, 27, 465489.

Grant, R.M. (1996) Toward a knowledge-based theory of thefirm. Strategic Management Journal, 17, Special Issue,109122.

Hobday, M. (1998) Product complexity, innovation and

industrial organisation. Research Policy, 26, 689710.Hutchins, E. (1991) Organizing work by adjustment.Organization Science, 2, 1, 1439.

Imai, K., Nonaka, I. and Takeuchi, H. (1985) Managing thenew product development process: how Japanese compa-nies learn and unlearn. In K.B. Clark, R.H. Hayes and C.

Lorenz (eds.), The Uneasy Alliance: Managing the Produc-tivity-Technology Dilemma. Boston MA: Harvard BusinessSchool Press.

Kerzner, H. (1995) Project Management: a Systems Approach

to Planning, Scheduling and Controlling, fourth edition.New York: Van Nostrand.

Lawrence, P.R. and Lorsch, J.W. (1967) Organization and

Environment. Homewood IL: Irwin.Levinthal, D.A. and March, J.G. (1993) The myopia oflearning. Strategic Management Journal, 14, Special Issue,

95112.Lindkvist, L. and Soderlund, J. (1996) Its only success thatcounts! Department of Management and Economics,

Linkoping University (in Swedish).Lindkvist, L., Soderlund, J. and Tell, F. (1998) Managingproduct development projects on the significance of

fountains and deadlines. Organization Studies, 19, 6, 931951.

Lundin, R.A. and Soderholm, A. (1995) A theory of thetemporary organization. Scandinavian Journal of Manage-

ment, 11, 4, 437455.March, J.G. (1991) Exploration and exploitation in organi-zational learning. Organization Science, 2, 2, 7187.

Midler, C. (1995) Projectification of the firm: the Renaultcase. Scandinavian Journal of Management, 11, 4, 363376.

Mintzberg, H. (1983) Structure in Fives. New York: Prentice

Hall.Nonaka, I. and Takeuchi, H. (1995) The Knowledge-CreatingCompany. New York: Oxford University Press.

Packendorff, J. (1995) Inquiring into the temporary organi-

zation: new directions for project management research.Scandinavian Journal of Management, 11, 4, 319334.

Perrow, C. (1970) Organizational Analysis: a Sociological

Review. Belmont CA: Wadsworth.Perrow, C. (1967) A framework for the comparative analysisof organizations. American Sociological Review, 32, 194

208.Sanchez, R. and Mahoney, T.J. (1996) Modularity, flexibilityand knowledge management in product and organization

design. Strategic Management Journal, 17, Special Issue,6376.

Shenhar, A. (1993) From low to high-tech project manage-ment. R&D Management, 23, 1, 3237.

Shenhar, A.J. and Dvir, D. (1996) Toward a typologicaltheory of project management. Research Policy, 25, 607632.

Soderlund, J. (1998) Global times: on deadlines and knowl-edge integration in complex development projects, IMTE,Linkoping University (in Swedish).

Spender, J-C. (1996) Making knowledge the basis of adynamic theory of the firm. Strategic Management Journal,17, Special Issue, 4562.

Spender, J-C. and Grant, R. (1996) Knowledge and the firm:

overview. Strategic Management Journal, 17, Special issue,510.

Stalk, G. and Hout, T.M. (1990) Competing Against Time.

New York: Free Press.Thompson, J.D. (1967) Organizations in Action. New York:McGraw Hill.

Ulrich, D. and Eppinger, S. (1995) Product Design andDevelopment. New York: McGraw Hill.

Wheelwright, S.C. and Clark, K.B. (1992) Revolutionizing

Product Development. New York: Free Press.

Jonas Soderlund


Copyright of R&D Management is the property of Wiley-Blackwell and its content may not be copied oremailed to multiple sites or posted to a listserv without the copyright holder's express written permission.However, users may print, download, or email articles for individual use.

managing complex development project

Documents