Challenges in Complex Product Development

Peter Schneider-Kamp(Supervisor: Peter Bollen)

June 11, 2002

Abstract

In an ideal world new product development would be carried out by a smallproject team of highly qualified individuals working in near-isolation for a fewshort months.

In the real world the development of complex products demands hugeproject teams probably spread over half the globe and consisting of more orless committed and otherwise busy individuals from dozens of partner andsupplier companies working for years.

In this paper we examine the challenges associated with complex productdevelopment and in how far traditional new product development methodscan be applied. By analyzing the product development process employed bythe Apache Group for the highly successful open source Apache Web Serverwe learn about a different approach to managing complex product develop-ment.

We devise organizational principles derived from the presented open sourceapproach which can be helpful not only in the context of Open Source Soft-ware development but also more generally in the development of complex andinnovative products.

1

Contents

1 Introduction 2

2 Challenges in Complex Product Development 32.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Channel Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Airbus A380 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.3 Intel Itanium . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.4 Microsoft Windows XP . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Major Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.1 Managing Large Product Development Teams . . . . . . . . . 42.2.2 Dealing with Long-Term Commitment . . . . . . . . . . . . . 72.2.3 Complex Supplier Relationships . . . . . . . . . . . . . . . . . 8

3 Open Source Software Development 93.1 Apache Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Apache Product Development Process . . . . . . . . . . . . . . . . . 103.3 Apache Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Implications for Complex Product Development 134.1 Specific to Apache and Open Source Software . . . . . . . . . . . . . 134.2 General Strategies for Complex Product Development . . . . . . . . . 13

4.2.1 Asynchronous Communication . . . . . . . . . . . . . . . . . . 134.2.2 Project Management Committees . . . . . . . . . . . . . . . . 144.2.3 Aggressive User Feedback . . . . . . . . . . . . . . . . . . . . 14

5 Conclusion 15

1 Introduction

Increasingly, successful innovation depends on a company’s ability to develop com-plex products. This is especially true for organizations in the engineering domainwhere the explosion of available knowledge demands ever more complex products inorder to gain and keep competetive advantages.

Obviously developing complex products introduces new challenges into the productdevelopment process. In the following section we identify and analyze some of themajor obstacles posed by a number of real life cases.

In section 3 we learn about the open source software development process by ana-lyzing the organization of the Apache Software Foundation and the development ofthe Apache Web Server software.

Based on this analysis section 4 concludes in how far the strategies used by Apachecan be applied to product development in general.

2

2 Challenges in Complex Product Development

2.1 Examples

The following examples are taken from projects finished or started during the last10 years. We have consciously selected examples from different industries to avoidover-specialization.

2.1.1 Channel Tunnel

After more than 200 years of planning and three unsuccessful attempts, one of themost ambitious civil engineering projects everwas completed in Summer 1994.

Figure 1: “Chunnel” cross-section

More than 13,000 engineers, technicians andworkers[1] employed by 5 British and 5 Frenchconstruction companies and their numeroussubcontractors built the first ground link fromFrance to Great Britain — the channel tun-nel (see figure 1).

During the 7 years of construction the estimated costs of £4.8 billion increased to astaggering £10.5 billion — at that time the most expensive construction project ofall times.

2.1.2 Airbus A380

In a five-year project commercial air-

Figure 2: Schematic view of the A380

craft manufacturer Airbus has 800 en-gineers and 1000 suppliers working to-gether in order to develop the new A380series of passenger and cargo planes(see Figure 2). Approximately $ 12billion will be spent on 9 stretch andshrink versions.

To make sure all important customerrequirements and environmental obli-

gations can be fulfilled the project team also contains representatives from 20 majorairlines and 50 large airports[2].

2.1.3 Intel Itanium

Well-known microprocessor manufacturer Intel Corporation has increased the num-ber of transistors per processor from 2,300 in 1971 to about 42 million in 2001. Thisamounts to a 20,000-fold increase – an indicator for the increasing complexity ofchip design.

3

So it comes as no wonder that Intel in 1992 set up a project team for its next-generation microprocessor architecture iA64 that during its 9 years of developmentpeaked at 800 design engineers and assistants[3]. The first processor scheduled forlaunch in 1998 was designed to run at an utopian 600 MHz clock speed.

During the long-term commitment for iA64 the competition with Advanced MicroDevices on the 32-bit microprocessor market accelerated the speed of advancementfor its old iA32 architecture.

When the first iA64 processor, the Itanium, launched with three years delay in 2001,the iA32 microprocessors had long since broken the 1GHz barrier and topped out attwo times the speed of the Itanium. As a consequence the Itanium become a majorflop.

2.1.4 Microsoft Windows XP

During the last decades the domain of software engineering has arguably seen thefastest increase in complexity. Software systems have become the most complexsystems constructed by human engineering ever.

In 1992 industry leader Microsoft needed a ‘mere’ 450 employees working for threeyears in order to design, code and test the new Windows 95 operating system con-sisting of 11 million lines of code.[4]

Microsoft’s newest flagship Windows XP introduced six years later contains approx-imately 3 times more code. And Microsoft had more than 5000 employees involvedin the project to be able to complete it in less than 3 years time.[5]

2.2 Major Challenges

In the cases above we can repeatedly identify three major challenges for the productdevelopment process caused by the complexity of the products:

1. Managing large product development teams

2. Dealing with long-term commitment

3. Complex supplier relationships

We explore this challenges and possible options of handling them seperately in thefollowing sub-sections.

2.2.1 Managing Large Product Development Teams

In the cases of complex product development given above the team sizes span ap-proximately one order of magnitude — from 1,000 to about 10,000 team members.

4

Now managing projects and teams has long since become an own management dis-cipline. We specifically only deal with the additional challenges found in managinglarge product development teams1.

So, what are the additional challenges in large product development teams?

Division of Labour With development teams comes the need for division oflabour. The traditional three stages approach of decomposition, seperate develop-ment work and integration is of limited use in large teams. The complexity ofintegration at the end of the development cycle increases disproportionately to thesize of the team.

In [4] Cusumano shows how Microsoft handles large product development team man-agement.

For a new product development project a clear vision in terms of product features isgiven. Strict limits are set on personnel and time consumption. Then decompositioninto small modules takes place — both according to function and to object hierarchy.These small modules are worked on in parallel by small sub-teams.

Now at Microsoft, instead of waiting until all modules are finished and then inte-grating them into a single product, the integration step is performed daily. Due tothese frequent synchronizations it is ensured that the seperate modules can alwaysbe integrated with only a trivial amount of effort.

Orchestration In a typical product development context orchestration betweenthe seperate product development projects is often needed[6].In addition to company-level orchestration, in large teams orchestration on theproject team level may be necessary in order to keep all subgroups pulling andpushing into the same direction.

An approach developed by Intel during the iA64 development is the use of TPWs(Team Planning Workshops) as described by Derringer in [3].The main idea is to hold a daylong workshop with short 10-minute presentations onall relevant topics for the whole team in order to clarify what the goals are, how thework is divided, who makes the decisions and which trade-offs have to be made tomake the development effort and the product successful.

Another approach described by Henke in [7] is the use of a project team level or-chestration unit which they call PMT (Project Management Team). This unit isresponsible for managing the cross-functional sub-teams. We learn about a similarapproach derived from the organization of the Apache Group in section 4.

1For general information on project management you can find plenty of links and articles athttp://www.projectmanagement.com.

5

Team Composition Teams used in the development of complex products areusually cross-functional by nature and in many cases also contain members fromdifferent companies. Especially in industries like aviation or civil engineering wheresuppliers play a crucial role representatives from partners and suppliers can be partof the development team.[7]

Based on a survey of product development professionals, McDonough describes themajor factors for the success of cross-functional teams.[8] He divdes them into StageSetters, Enablers and Team Behaviours:

• Stage Setters are important aspects in the creation of a cross-functional team:

– Goals establish a common ground for team members, help structure tasksand focus effort.

– Empowerment of team members leads to greater commitment and satis-faction as well as better informed decision making.

– Climate is created by the management at the inception of the team anddeveloped further by the working of the team. A good climate should giveteam members both a feeling of urgency as well as excitement over theproject and provide a trustful and communication-enabling environment.

– Human Resources are important because having the ‘right’ people on theteam is a necessary prerequisite to project success.

• Enablers are persons that have a major influence on cross-functional teamsuccess:

– Team leaders enable team members to contribute and cooperate. Theyshould posess an open and apolitcal style of leadership.

– Senior Management supports the cross-functional team with needed re-sources and encourages and motivates project progress.

– Champions are team members that take a strong interest in the project’ssuccess. Only by their commitment the Stage Setters can unfold theirwhole potential.

• Team Behaviours are the result of Stage Setting and Enabler support:

– Cooperation, i.e. good communication and mutual support, between theteam members gets the team’s work done.

– Commitment of the individual team members is important to increaseteam performance.

– Ownership is a feeling that can be created by having clear, focused goalsand a good climate. Only with ownership the individual team memberswill unfold their full potential.

– Respect is important for trust and open communication inside the team.

6

This finding of success factors is compatible with the notion of TWQ (TeamWorkQuality) introduced by Hoegl und Gemuenden in [9]. Each component of TWQ canbe viewed as a result of multiple success factors postulated by McDonough.

• Open and direct communication is a consequence of good team leadership,respect between the team members and a good climate.

• Good coordination can be achieved in an environment where everyone coop-erates in order to achieve a common goal. A feeling of ownership improvescoordination.

• A balance of member contribution is a consequence of mutual respect and goodteam leader ship.

• To facilitate mutual support a trustful climate is needed and the right peoplehave to be on the team.

• For making sure all efforts are directed towards reaching the common goal,commitment to the project and a feeling of ownership are necessary. Empow-erment of team members helps to create this and champions can also be a goodcatalyst.

• Finally, the existance of team cohesion depends on the feeling of ownershipand the team climate.

The approaches to cross-functional team organization mentioned above assume thecomposition of the product development team to be rather fixed once it is set up bymanagement[8].Small turnovers or additons are handled by an appropriate human resources strategy.

In the reality of long-term development projects with large teams, the team compo-sition can almost be guaranteed to change over time. We explore a flexible way tohandle team member turnover in section 4.

2.2.2 Dealing with Long-Term Commitment

A typical problem with long-term commitment is the binding of resources. Here weassume that the use of resources is well justified and the long-term commitment isnecessary to enhance the company’s core competencies[10].

Two other challenges in long-term product development that can be derived fromthe cases above are the management of uncertainty (Airbus A380, Channel Tunnel,Intel Itanium) and the need for the provision of an emergency brake (Intel Itanium,Channel Tunnel).

Managing uncertainty While a large-scale long-term product development ef-fort is under way, watching changes in the market or in the available developmenttechniques is of great importance — the costs of failure are very high[11].

7

Often with new technologies that are used or developed in such a development effortthe market can change in reaction to competitors’ introduction of related productsrelativating or even obsoleting the demand for one’s own product. Depending onindustry political influences can be even more important.One way to deal with this is to make the overall planning process iterative and repeatit every few months[3].

Emergency brake In long-term, high-risk product development efforts it is alsovery important to provide an emergency break. The merits of the project have tobe assessed continuously. It must be avoided that the assessing person is overlycommited to the project’s persistance. Instead an environment has to be createdin which a project is allowed to fail. Cancelling a development project that hasbecome irrelevant or impossible to complete economically is better than to keepgoing whatever the price.[12]

2.2.3 Complex Supplier Relationships

We focus on the challenges in developing an emerging product for an emerging mar-ket, on the topic of supplier costing, and we explore where outsourcing can be used.The handling of supplier relationships and dependencies between hundreds of sup-pliers or subcontractors — as in the Airbus or Channel Tunnel case — is beyondthe scope of this paper.

Emerging product & emerging market In the development of a complex prod-uct for an emerging market, development has to integrate the customer into the de-velopment process in order to get the requirements right and educate the customerabout using the product.[11]An extreme case is the Channel Tunnel where there is only one customer and itis obvious that development has to co-opt him. But also in cases where a genericproduct is developed this can be necessary.It depends mainly on how well the requirements for the product are known andon how knowledgeable the customers are. In the Intel case the requirements areclear and the typical user does not know a great deal about chip design. On theother hand in the development of the Airbus A380 large airlines are the principalcustomers and they are quite knowledgeable. And for sure their requirements arecomplex and demand direct involvement into the development process.

Supplier costing In any complex network of suppliers allocating the appropriateslice of the profit cake is non-trivial.

A scheme that can take into account both the need of the supplier and of the origi-nator is target costing[13]. Here the basic idea is that the originator calculates howmuch he can afford to pay for the supplied component or service and tries to find asupplier who can offer it at this price.

8

The affordable price can be calculated by taking into account the estimated salesprice, the variable costs per produced product and the fixed costs divided by theestimated sales volume. The originator has to decide on a profit margin and then todistribute the affordable cost to the seperate components.

This is a nice theoretical concept, but for complex products distributing the afford-able cost to the components is a non-trivial problem in itself. And as neither theactual sales price and volume nor the real fixed and variable costs during the prod-uct life cycle (including marketing, support, disposal etc.) are known, it cannot beapplied without further refinements.

Outsourcing Naive approaches to outsourcing demand that everything that canbe done cheaper — or better and at the same cost — by some supplier should beoutsourced. But in practice making one dependent on others by outsourcing com-petencies has a cost that is neither negligible nor easy to calculate.

According to den Hertog and Huizenga[6] there are three types of competencies.

1. Core competencies are those competencies that your competitive advantageand many of your products or services rely on.

2. Enabling competencies are often concerned with sensitive know how and stronglyrooted in core competencies.

3. Exchangeable competencies constitute everything that your company needs inday-to-day operation but can be exchanged without seriously affecting the corebusinesses.

In general it is a bad idea to outsorce any activities connected to the core competen-cies of your company. Outsourcing enabling competencies is also not recommendedas it may lead to destruction of capital and social problems.

Exchangable competencies though can and should be outsourced — if economicallyfeasible.

3 Open Source Software Development

Apart from some highly visible projects (Linux, Mozilla) the better part of the inter-net infrastructure is built on Open Source Software[14]: e-mail (sendmail), domainname service (bind), webserver (apache) . . . to name only a few.Obviously the Open Source Software development process2 has produced some highlysuccessful software products of quite large scale.In this section we analyze the way open source software development takes placein the context of a typical large scale project. The project we have selected is theApache Webserver.

2For a critical discussion of the open source phenomenon as well as pointers to relevant literaturesee [15] and [16].

9

3.1 Apache Background

In February 1995, as a reaction to the stagnation in development of the NCSA httpdserver, a group of volunteers from different organizations, e.g. Elsevier, MIT andSun Microsystems, founded the Apache Group in order to develop a free, standardweb server.Coordinating the activities of this globally distributed group, whose compositionwas subject to continuous change, was seen as a major challenge and lead to thecrafting of a sophisticated development process.As you can see in figure 3 history has proven the project a grand success. Alreadyat the beginning of 1996 the Apache Web Server dominated the net with a marketshare of about 30%.

Figure 3: Netcraft Web Server Survey February 2002[17]

In spite of the success of Microsoft’s IIS (Internet Information Server), Apache hasmanaged to expand its marketshare to more than 50% leaving the second runner IISfar behind at about 30%.In 2000 the development community for the Apache Web Server consisted of 25core developers, about 400 other developers and more than 3000 people filing testreports.[18]Employing their core competence of building stable open-standards infrastructuresoftware in addition to further improving the Apache Web Server Apache Grouptoday develops many ambitious and successful XML tools and delievers the currentreference implementation of Sun Microsystem’s Java Servlets[19].

3.2 Apache Product Development Process

The Apache Group identified three major development constraints[20] for the designof the development process:

1. Global distribution

2. Voluntary organization environment

3. Heterogenous development platforms

Global Distribution means developers have varying work schedules and are spreadover multiple time zones. This makes synchronous communication not only expen-sive but also hard to coordinate.

10

Keeping a development process going in a voluntary organization environment isalso hard. Developers come and leave as they wish (or as their other tasks demand)and there are almost no central institutions like management and administration.

Finally it is important that in spite of the heterogenous development platforms thedevelopers can share a common set of development tools.

The Apache Group addresses these constraints by basing their process on three basictactics:

1. Asynchronous communication[18]

2. Role sharing and rotation[20]

3. Use of ubiquitous tools[20]

Asynchronous communication enables developers to choose when they want to com-municate. In order to avoid starving of the process, time limits for response areset. The voting process[19] for decision making for example sets a 48 hours limit forreviews. If enough reviews have taken place in that time frame, the missing votesare counted as “abstain”.

As a consequence of volunteers running the show, Apache Group implemented rolesharing and rotation. The heart of this tactic is to assign organizational roles notto one project member, but to a committee[19]. The rationale for this is discussedin more detail below.

Finally, in order to address the need for a common set of development tools, ApacheGroup makes use of ubiquitous tools for communication, development and coordina-tion, e.g. SSH (Secure Shell) for remote access, CVS (Concurrent Version System)for coordination of the code base or Bugzilla for problem reporting. These are ei-ther available for all major platforms3 or can be used over web interfaces from anybrowser.

With regard to the rest of the development process — especially division of labour— Apache uses an approach quite similar to Microsoft’s Synch and Stabilize[21].Although builds are not neccessarily created on a daily basis, just like at Microsoft’srigid rules are in place to ensure that the seperate modules always can be integratedwithout trouble.4

Of course, the organization of the Apache Group has to reflect this developmentprocess. In the following subsection we explore its organizational implementation.

3SSH and CVS as well as the compilers and build tools — in short all the software needed bya normal developer — are pre-installed on almost all modern systems

4For a comparison of Synch and Stabilize to Open Source Software Development see [22].

11

3.3 Apache Organization

Designing a good process alone does not guarantee success — the organization hasto offer a base on which the process can proliferate. After taking a short look athow the Apache Group deals with strategy and personnel policy we then focus onproject and knowledge management.

In June 1999 the Apache Group has incorporated to become the Apache SoftwareFoundation — mainly in order to provide organizational support and to have anon-profit corporation for holding the intellectual property rights. The Board ofDirectors, effectively consisting of core developers, has taken responsibility for thevision and the strategy of the Apache Group’s development efforts.

Naturally, in the context of volunteerism, there is not much “management” can doabout personnel policy but to make sure that contributions are recognized and thattrust and good intentions as well as common sense dictate interpersonal relationships.

In the realm of project management though, something had to be done. Traditonalapproaches with a project manager leading a project team are bound to fail. Firstdue to the asynchronous communication and partly also to the volunteeristic natureof the involvment, the response time of a single project manager or team leader wouldbe much too slow. Secondly the team cannot consist of a certain fixed number ofdevelopers, but is subject to continuous change.The solution employed by the Apache Group is to replace the project manager bya PMC (Project Management Committee). Naturally, for any one project this con-tains the people most involved with the project’s day-to-day operation. Today thereare 7 main PMCs — one for the overall planning of product development and 6 foreach of the major projects, i.e. the web server, APR, Jakarta, Apache Perl, ApachePHP, Apache XML. The larger projects also have a number of sub-projects withtheir own PMCs.

Bearing in mind the problems caused by team member fluctuation a well-workingknowledge management is paramount for the Apache Group.Communication between developers is almost exclusively accomplished by personale-mail, usenet discussions and mailling lists. But these communication methods areby their very nature volatile and do not pose any help in creating an organizationalmemory. To turn this problem into a feature great care is excercised in archivingand making efficiently accessible the discussions that take place in mailing lists andusenet newsgroups.Design and implementation rationales are either explicitly documented in the user-level documentation or if unappropriate in the logs of the CVS. Finally, to make surethat known bugs, issues or user requests are not subject to organizational oblivion,users and developers report them directly into the Bugzilla data base.

12

4 Implications for Complex Product Development

On our quest for generally applicable product development principles we will analyzewhich of the principles employed by the Apache Group are specific to Apache andOpen Source Software development and which can be used as general strategies forcomplex product development.

4.1 Specific to Apache and Open Source Software

In principal none of the elements in Apache’s organization or development processthat we have described are really specific to the Apache project itself.

Some aspects, like the voluntary organization environment, are unlikely to occuranywhere but in true open source software development projects. We can still gen-eralize the strategy of role sharing and rotation though.

The aggressive user feedback achieved by opening up the development process itselfto the users requires an open source environment. But there are ways of installingsuch environments in the realms of proprietary software.

Large companies can use open source principles internally [23] thereby fostering reuseand feedback of users from other parts of the organization.

A second approach is to make the platform one’s proprietary software products runon available as Open Source Software. A good example is Jabber, Inc. who have opensourced the XML platform for their software in order to co-opt user competence.[24]

4.2 General Strategies for Complex Product Development

Now we show that the principles of asynchronous communication and project man-agement committees can generally be used in complex product development. Addi-tionally we try to generalize the aggressive user feedback strategy of Open SourceSoftware development.

4.2.1 Asynchronous Communication

Synchronous communication requires that the communication partners are availableat the same time and dedicate full-time to the communication. Because response isimmediate rich information can be communicated. But having to coordinate largergroups of people, this places a restriction on the reach5 of synchronous communica-tion methods. Examples are face-to-face conversation and telephone calls.

In asynchronous communication these restrictions do not exist, but as an immediateresponse cannot be guaranteed, it may take longer time. Examples are email or web-based data bases.

5For a discussion of richness vs. reach trade-offs see [25]

13

Now it is naive to assume that replacing face-to-face conversation and traditionaltelecommunication by email and web-based data bases will lead to a better commu-nication alone.But using asynchronous communication methods for non-trivial, non-time-criticalcommunication improves reach and gives the communication partners time to re-search and consider their responses, thereby effectively also improving the quality ofcommunication.Also, the better archiving possibilities associated with asynchronous communicationprovide for a better organizational memory.

4.2.2 Project Management Committees

Assuming long-term commitment and large product development teams, the needfor orchestration and flexibility in team composition arises.

As noted above, PMCs (Project Management Committees) can be used similar toPMTs (Project Management Teams) as orchestration units on the project teamlevel. But in contrast to PMTs they consist not of managers but of normal productdevelopers.

As a consequence all essential roles can be shared in PMCs. This leads to a reducedimportance of the individual, and thereby to a trade-off between increased flexibilitywith regard to changes in team composition and increased difficulty in attributingresponsibility.

In very large teams it is also possible to replace the single orchestrating PMC bya hierarchy of PMCs. Here the trade-off is between central project managementcompetence and distributed self-administration.

4.2.3 Aggressive User Feedback

Utilizing aggressive user feedback for development the way Open Source Softwaredevelopment does for many companies is not a realistic option, as certain functionalor operational knowledge cannot be revealed to users.But often many parts of the development process can be opened up to both usersand suppliers. Only those parts where your competitive advantage lies are worthhiding. This is similar to the notion that outsourcing core competencies is not agood idea.

E.g. for Intel it would be possible to open up most of its microprocessor designspecifications as its real advantage lies in knowing how to design and produce suchecomplex structures.

Actually this principle is already partly employed by Airbus in its A380 development.But instead of just assessing customer requirements from the airlines, Airbus couldhave them actively co-design the plane to their likings.

14

5 Conclusion

In this paper we have identified and analyzed three major challenges posed by com-plex product development and have discussed traditional ways of dealing with these.By generalizing development principles employed by the Apache Group we havefound three additional principles that address these challenges, that is to say theuse of asynchronous communication and project management committees as well asproviding support for aggressive user feedback.

References

[1] C. S. Harris. Channel tunnel facts. Summarizing report, Geology Shop, UK.http://www.geologyshop.co.uk/chtunfacts.htm.

[2] Groupement des Industries Francaises Aeronautiques et Spatiales. Gifas info1671. News booklet, June/July/August 2000. http://www.gifas.asso.fr/

english_version/gifaspdf.

[3] Pamela H. Derringer. Team tactics at intel. Projects At Work, 2(1), January2002. http://www.projectsatwork.com/january2002/april_cov.htm.

[4] Michael A. Cusumano. How microsoft makes large teams work like small teams.Sloan Management Review, 39(1):9–20, Fall 1997.

[5] Dan Richman. Global release tomorrow for what gates calls ‘best ever’ os.Newspaper article, Seattle Post-Intelligencer, Seattle (WA), USA, October 24,2001. http://seattlepi.nwsource.com/business/43916_xp24.shtml.

[6] J Friso den Hertog and Edward Huizenga. The Knowledge Enterprise: Imple-mentation of Intelligent Business Strategies. Number 2 in Series on TechnologyManagement. Imperial College Press, London, United Kingdom, 2000.

[7] John W. Henke, A. Richard Krachenberg, and Thomas F. Lyons. Cross-functional teams: Good concept, poor implementation! Journal of ProductInnovation Management, 10(3):216–239, June 1993.

[8] Edward F. McDonough III. Investigation of factors contributing to the success ofcross-functional teams. Journal of Product Innovation Management, 17(3):221–235, May 2000.

[9] Marting Hoegl and Hans Georg Gemuenden. Teamwork quality and the successof innovative projects: A theoretical concept and empirical evidence. Organi-zation Science, 12(4):435–449, July-August 2001.

[10] C.K. Prahalad and Gary Hamel. The core competence of the corporation.Harvard Business Review, 68(3):79–93, May–June 1990.

[11] J. Tidd, J. Bessant, and K. Pavitt. Managing Innovation: Integrating tech-nological, market and organizational change, chapter 7, pages 161–195. Wiley,Chichester, UK, 1997.

15

[12] Barry M. Staw and Jerry Ross. Knowing when to pull the plug. HarvardBusiness Review, 65(2), March–April 1987.

[13] Robin G. Cooper and Regine Slagmulder. Develop profitable new products withtarget costing. Sloan Management Review, 40(4):23–33, Summer 1999.

[14] Bruce Perens. Open source definition. http://www.opensource.org/docs/

definition.html.

[15] Bertrand Meyer. The ethics of free software. Software Development, March2000. http://www.sdmagazine.com/documents/s=746/sdm0003d/0003d.htm.

[16] Nikolai Bezroukov. A second look at the cathedral and the bazaar. First Mon-day, 4(12), December 1999. http://www.firstmonday.dk/issues/issue4_

12/bezroukov/index.html.

[17] Netcraft. Web server survey, February 2002. http://www.netcraft.com/

Survey/.

[18] Audris Mockus, Roy Fielding, and James Herbsleb. A case study of open sourcesoftware development: The apache server. Proceedings of the InternationalConference on Software Engineering, 22:263–272, 2000.

[19] The Apache Software Foundation, March 14, 2002. http://www.apache.org/.

[20] Roy T. Fielding. The apache http server project: Lessons learned from col-laborative software development. Presentation slides, University of California,Irvine (CA), USA, October 26, 1998. http://www1.ics.uci.edu/~fielding/talks/apache98/.

[21] Michael A. Cusumano and Richard S. Selby. Microsoft Secrets: How the World’sMost Powerful Software Company Creates Technology, Shapes Markets, andManages People. The Free Press, New York (NY), USA, 1995.

[22] Shahzad Malik and Jose Ruben Palencia. Synchronize and stabilize vs. open-source: An analysis of 2 team-organization models when developing consumer-level shrink-wrapped software. Research report, Carleton University, Ottawa(Ontario), Canada, December 6, 1999.

[23] Scott W. Ambler. Reuse through internal open source. Software Development,December 2000. http://www.sdmagazine.com/documents/s=737/sdm0012p/

0012p.htm.

[24] Jabber Inc. The jabber essays, March 23, 2002. http://www.jabber.com/

open_source/index.shtml.

[25] Philip Evans and Thomas S. Wurster. Blown to Bits: How the New Economicsof Information Transforms Strategy, chapter 3. Harvard Business School Press,Boston (MA), USA, December 2000.

16