For the exclusive use of N. Sinden, 2015.

9-602-061
REV: MARCH 18, 2002

STEFAN THOMKE

Siemens AG: Global Development Strategy (A)
It was the spring of 2000, but even under the afternoon shade of the palm trees at the Oberoi hotel in Bangalore, South India, it felt like summer. Horst Eberl sat contemplating the recommendations that he and his subdivisional co-head, Karl-Friedrich Hunke, would be preparing for the Siemens
Information and Communications Networks (ICN) management board. Things were neat, tidy, and cool on this grassy side of the hotel. Just outside the main walls however lay the dust, pollution, and confusion of the Indian traffic. And if one took life in one’s hands by darting through the traffic, across the street lay Siemens’ regional development center in India, scattered among floors rented in three different office buildings. Two back-up power generators, as well as battery backup for all computers, helped ensure a reliable infrastructure for the 600 personnel here.
What vexed Eberl and Hunke was that Deutsche Telekom, Siemens ICN’s largest customer, was upset because of slow product delivery on a new telecommunications software product, the so-called
NetManager. For a variety of reasons the project had rapidly mushroomed in size and scope beyond what had been initially envisioned. To solve the problem, Eberl, co-head of ICN’s largest subdivision, had to travel some 7000 kilometers to this dusty corner of the world: despite the conveniences of email, telephone, and fax, there was little substitute for face-to-face interaction.
The Germans and Indians regarded each other with mutual respect and camaraderie. The Indians marveled at the meticulousness of the Germans, which had allowed them over four decades to assemble one of the world’s finest telecommunications systems. The Germans, in turn, appreciated the diligence and enthusiasm of Indian employees. Yet, both sides did at times find fault with each other. Quite often the Indians appeared more interested in pursuing entrepreneurial jobs rather than in working in one corner of the vast Siemens machine. And to the Indians, the Germans sometimes appeared disloyal by refusing to cancel pre-arranged long vacations at junctions critical to a project.
The Indians’ lack of experience with large telecommunications systems had led them to make several wrong assumptions about the current project. Would more personal interaction between the
Munich headquarters and Bangalore throughout the project have prevented problems from escalating to this point? Or perhaps, the Indians simply needed more time and project autonomy before graduating to a Center of Competence—the highest distinction of experience and technical competence within the global Siemens R&D network. Solving the current crisis would pave the way for smoother R&D management across national borders in the rapidly changing field of telecommunications equipment. It could also help point out the direction for future growth of the
Indian division, by now ICN’s third-largest regional development center outside Germany.
________________________________________________________________________________________________________________
Professor Stefan Thomke and Research Associate Ashok Nimgade prepared this case. HBS cases are developed solely as the basis for class discussion. Cases are not intended to serve as endorsements, sources of primary data, or illustrations of effective or ineffective management.
Copyright © 2001 President and Fellows of Harvard College. To order copies or request permission to reproduce materials, call 1-800-545-7685, write Harvard Business School Publishing, Boston, MA 02163, or go to http://www.hbsp.harvard.edu. No part of this publication may be reproduced, stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means—electronic, mechanical, photocopying, recording, or otherwise—without the permission of Harvard Business School.

This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens AG: Global Development Strategy (A)

Telecommunications Systems: The Invisible Hand
Telecommunications systems of the turn-of-the-millennium would have evoked far stronger emotions than 167 years ago, when Samuel Morse ushered in the telegraph era of telecommunications with the words “What hath God wrought!” Over the decades, millions of engineering hours and thousands of patents had gone into creating systems that could automatically connect telephone calls via digital “carrier switches”. These systems rapidly “routed” a call over a complex network of telephone lines in an optimal manner, while keeping track of each call for billing purposes. Consumers enjoyed low costs thanks to innovations such as digital switching and allowing dozens of conversations to be transmitted simultaneously over a single telephone line.
Equally miraculous was the systems’ reliability which allowed telephone users to take the presence of a dial tone for granted. Such was hardly the case decades earlier, or even in contemporary third world nations. (See Exhibit 1 for background on the early history of telecommunications.)
Large telecommunications systems operated smoothly thanks to their installation and maintenance by multinational giants such as Siemens, Lucent, Ericsson, and Alcatel. A telephone system had hundreds if not thousands of different features, most of which were invisible to casual users but not to the large and often national telephone operators that ran these systems around the globe. For decades, providers of these large systems enjoyed a cozy relationship with their traditional customers; relationships that often outlasted the up to 30-year lifespan of a telephony system.
In the mid-1990s, telecommunications had reached a new inflection point. The Internet now allowed for the revolutionary possibility of voice and data transmitted over the same broadband lines using the same protocols. Phone calls or faxes were traditionally handled over telephone lines but could possibly be handled much more cheaply over data lines and lower cost equipment employed for computer networks (see Exhibit 2 for information on service transaction cost). Siemens and other major telecommunications companies remained aware that over the next 5-10 years, Internet-based voice transmission could dominate their industry if quality and reliability problems were solved.
Already, the upcoming market fielded new terms such as “Voice over Internet Protocol (IP)” and customers could place telephone calls using their personal computers. Many at Siemens feared that the leap from old to new might prove too large for a company that by admission of a U.S. board member himself, people viewed as a “slow-moving dinosaur.”1

Building an Industrial Giant
In 1847 in Germany, Werner Siemens and J. Halske founded what was to be known as Siemens to manufacture and install telegraphic systems.2 Early orders came from Germany, Russia, and
England, with the company’s London branch even helping lay the first deep-sea telegraphic cables connecting England with America as well as India. Over the years, the Siemens family capitalized on several emerging technologies ranging from the telephone to electric power generation to the X-ray tube, laying the foundation for the company’s continued presence in these areas and leading Fortune magazine to typify Siemens’ strategy as “second is best.” The company was quick to produce an improved and patented version of Alexander Graham Bell’s telephone. In 1909, the company built an automatic telephone exchange to serve Munich’s 2500 telephone users.

1 M. Reardon, “Siemens’ Haunted History—As the company shapes its future, it’s still forced to confront its past.” Data

Communications, August 7, 1999,
2 Much of the early company history draws from “Siemens A.G.” Mirabile, L. (Ed.) International Directory of Company Histories,
V.II, Chicago and London: St. James Press, 1990.

2
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

602-061

The independence of Siemens’s foreign subsidiaries was reinforced during World War I, when the
British nationalized (temporarily) the London branch and Bolsheviks likewise appropriated the St.
Petersburg branch. Throughout the twentieth century, however, Siemens continued its international growth, with its presence extending even as far as Mars, through development of space probe technologies for NASA. Siemens dominated in areas such as telecommunications, medical technology, data-processing systems, manufacture of heavy electrical equipment, nuclear plants, and railroad equipment. The company had developed a legendary ability to manage large, complex projects and prided itself on quality and durability—its early mobile telephones, for instance, could still function after being hurled across a room at a wall. By 2000, Siemens was one of the top five electronics and electrical engineering companies in the world, with annual revenues exceeding 130 billion Euros3. It could boast some 464,000 employees scattered across 190 countries, with 57,000 employees dedicated to R&D alone. In 2000, Siemens held some 120,000 patent rights and spent over ten billion Euros on research and development. Its largest group, Information and Communications
Networks (ICN), employed 53,000 people, operated in 160 countries and had headquarters that spread over dozens of buildings at two fenced sites in suburban Munich, Germany (see Exhibits 3 to
5 for financials and corporate structure).
Siemens expanded its markets on the basis of technological competence and close relations with large customers rather than on aggressive marketing. Its conservatism extended even to consumer financing. “Siemens historically has guarded its credit rating,” according to Peter Kröbel, a U.S.-based director of international business development. This approach had kept the company from falling prey to traps such as extending credit to unstable Latin American nations as well as aggressive
Internet-related acquisitions that had ensnared many of its rivals.
In the 1990s, with a worldwide wave of deregulation affecting various industries including telecommunications, Siemens could no longer rely as heavily on its traditional relationships with large customers. With computer and telecommunications industries changing rapidly, productivity gains of as much as ten percent a year were often canceled out by price declines. 1998 marked a crisis point when net income slumped two-thirds from a 1996 peak of $1.36 billion. Siemens CEO von
Pierer acknowledged that “In Germany, competition was like a wind. Now, it’s a storm. And it will become a hurricane!”4
Industry observers often linked the company’s challenges to its geographic location: “Siemens’ problems are Germany’s problems. Its faults were typical of dozens of German manufacturers: great engineers, iffy marketing. High labor costs and taxes. Overregulation. Complacency after years of government coddling.”5 In response, Siemens shed some of the traditional German consensusbuilding style in favor of a US-style of management that by CEO von Pierer’s own admission was based on the General Electric model. The company officially launched a ten-point plan that called for, among other things: divesting poor-performing units in favor of strengthening remaining businesses with the potential to become world leaders in their field; setting tougher profit targets for managers; tying as much as 60% of managers’ pay to performance; trimming the high-cost German workforce and management by as much as a third; reducing overtime pay; adopting U.S. accounting principles; and more aggressively incorporating marketing into its product development processes.

3 While the exchange rate between Euro, German mark and U.S. dollar fluctuated, the following rate roughly applied: 2 DM =

1 Euro = 0.90 US$.
4 J. Ewing, “Siemens climbs back: the German electronics giant has embraced speed, innovation, and the art of pleasing

customers,” Business Week (International Edition), June 5, 2000..
5 Ibid.

3
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens AG: Global Development Strategy (A)

Amid this painful transition, the company betted much of its future on the vast but volatile telecommunications market as firms scrambled to build next-generation mobile networks and upgraded their networks to handle broadband multimedia services. With hundreds of billions of dollars at stake, players in this field faced costly consequences for misreading technology shifts. A conglomerate such as Siemens would have to battle New World telecom stars such as Nokia and
Cisco (see Exhibits 6a and 6b for switching equipment competitors and markets). By early 2000, von
Pierer’s strategic shifts appeared to have reaped dividends. Led in part by the mobile-phone business, its net income doubled in the first quarter of 2000 to $694 million on sales of $17 billion. A weak Euro had further helped by making its products cheaper overseas. Noticeably, the software component to Siemens’ projects had grown to account for almost a fourth of its revenues now.
In the United States, Siemens now became the largest foreign employer, with 73,000 people employed at 700 locations in all 50 states. Thanks to its acquisition of Westinghouse, its products accounted for nearly half the US power generation. In contrast, the ICN division’s 10% market share was well below its 25% share of the world’s telecommunications systems. As a result, the company sought to bolster its American presence through a series of strategic acquisitions such as Unisphere
Networks. Like many very large firms, however, Siemens was still burdened with too many middle managers who resisted changes necessary in a rapidly changing industry.

Siemens Information and Communication Networks (ICN)
Siemens ICN represented a natural outgrowth of Siemens’s work in telegraphy and telephony.
ICN could offer entire nations turnkey telecommunications switching systems based around its flagship product “EWSD”6, the best selling and most reliable telecommunications switch in the world. Each EWSD resembled a steel frame the size of a walk-in closet, with hundreds of horizontal slots containing removable modules (see Exhibit 7). An EWSD was scaleable to accommodate all switching needs in the range of up to 240,000 telephone lines (or “ports”). Hence, it could cost anywhere between $500,000 and $10 million, with a marginal cost of up to $100 per port.
Although the EWSD did not represent a pioneering effort, it demonstrated the ability of Siemens to be a fast and very successful follower. The technology had started out in the early 1980s as a hybrid analog-digital switching system (which in turn grew out of the EWSA, where the “A” stood for
“analog”). In 1981, because of technology breakthroughs by competitors such as AT&T, Siemens piloted its first hybrid switch in faraway South Africa. Despite advances in digital semiconductor technology in the early 1980s, the company hedged its bets by sticking to its hybrid approach, which relied on its decades-old expertise with electromechanical systems.
Then, one Friday afternoon in 1983, in a move highly unusual for Siemens, the head of ICN summoned all 1500 developers for an emergency meeting in the cafeteria, the only place where everyone could fit. He announced: “Stop all your work! As of today, all work on mechanical switches will cease; henceforth we will undertake only work on digital systems.” The announcement sent shockwaves throughout the multinational corporation used to a more gradual, consensus-based approach to technological change.
Altogether, over the next two decades, Siemens ICN invested over 30,000 staff years to create the fully digital EWSD. Its bold move of 1983 was to pay off handsomely. By 2000, ICN equipment controlled almost 300 million telephone lines and routed one in five phone calls worldwide. In its homeland Germany alone, EWSDs controlled almost 50 million telephone lines—representing two6 German acronym of Elektronisches Wählsystem Digital (in English: “Electronic Switching System Digital”).

4
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

602-061

thirds of the German market. Telecommunications systems had to provide a reliability of 99.999%
(referred to as the “five nines”), with a downtime of under five minutes per switch per year. Not surprisingly, the “fifth nine” was the hardest to achieve but also mattered the most to its large customers. To achieve this reliability while providing scores of new product features, ICN alone spent 270 million Euros on R&D per year.
EWSD hardware and software development followed a regular release cycle which was a major undertaking, utilizing up to 1,000 staff-years per release, with many subsystems developed from scratch. By the year 2000, ICN was already developing release 15.0 which would be made available to major customers around the world. Later system releases had offered new features such as voice recognition, traffic measurement, voice-mail boxes for end users, caller ID, and automatic dial back for missed calls. As a result of constant improvements, according to director of rapid prototyping Dr.
Hermann Granzer, “even after a decade, at a customer’s site an EWSD is similar to a brand new car with the new trunk, wheels, windows, and ignition system, and so on.”
By 2000, three-fourths of ICN’s eleven billion Euro revenues came from hardware and the remainder came from software. Siemens ICN employed about 53,000 people worldwide and was active in 160 countries where it sold telecommunications products with market cycles ranging from over a decade in third world nations such as Indonesia to as short as three months in Germany. Like its top competitors, ICN emphasized good service and maintained close links with its customers. It avoided outsourcing service work on its telecommunications systems to ensure the type of customer commitment that only its staff could provide over the years or decades to come. Its carrier switching
(CS) subdivision, headed by Horst Eberl and Karl-Friedrich Hunke, accounted for roughly 25% of
ICN’s 11 billion Euro revenue and was the largest and most profitable unit (see Exhibit 8 for ICN’s organization). To its wealthier customers in developed nations, Siemens offered almost yearly EWSD updates and other benefits such as free upgrades, discounts, or even free switches. For customers in developing nations, the most attractive offerings were reliability, durability, and prompt service. For many decades, Siemens even maintained at its Munich headquarters exact replicas of the large systems that it had installed in distant nations in order to expedite problem solving. Most field problems could be solved by customers reading through large product manuals, sometimes with help from local service teams. The harder problems would often have to be referred to any of
Siemens’s major R&D centers, a more expensive proposition, as it often pulled personnel away from new projects. The entire system of fault management was painstakingly monitored by “FEKAT,” a proprietary fault management tool devised and honed by Siemens over the past two decades.
In many ways the traditional German system of work—long, if not lifetime, mutual commitment and loyalty on part of employer and employee—suited a large organization such as Siemens well.
Individuals with this mindset would not mind dedicating their entire careers to tasks such as fault analysis monitoring or testing in a small corner of a giant ongoing system such as EWSD. A young employee could expect to work on an initial project lasting 1-2 years while being able to seek advice from a sea of experienced managers. The downside for employers was dealing with circumscribed workweeks and generous vacations. But as one manager himself put it, “Other people may live to work, but we Germans work to live!”
For Siemens ICN, however, gray clouds on the horizon loomed nearer with every year. Despite being a steady cash producer, EWSD faced a zero percent growth rate in the developed world. By the mid-1990s, with the growing importance of the Internet, management realized that EWSD would ultimately die out. The speed with which the Internet would begin to replace traditional data transmission, however, would catch ICN and its competitors by surprise. “We always saw it as a

5
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens AG: Global Development Strategy (A)

niche market,” according to board member Volker Jung.7 Even industry veteran Horst Eberl admitted that “if transmission of voice over the Internet matches the quality and flexibility of regular telephone, EWSD will die.” ICN, however, had no cash-out strategy except to sell as many EWSD units as it could, especially in fast growing developing markets such as China and Brazil. The company could also count on a large installed base that, especially in the developing world, might need servicing for years to come.
To prepare for the future, Siemens ICN launched a new hybrid platform named “SURPASS” which combined traditional EWSD and new broadband technology for data transmission that came in part from acquisitions in the US. Customers would be offered a very reliable and feature rich system solution that met all their data and voice transmission needs and thus resembled ICN’s strategy during earlier technology shifts.

Global Product Development and Project Management
Almost from its very inception Siemens viewed itself as a global organization. For two major reasons ICN conducted almost half its R&D efforts at 17 Regional Development Centers (RDCs) scattered across the globe (see Exhibit 9 for locations). First, because of local labor shortages, ICN could simply not centralize all product development at Munich. Second, having regionally-based managers, engineers and technicians facilitated rapid response to local needs such as EWSD customization. A de facto partition thus emerged with Munich taking leadership for creating and maintaining new releases of the platform product (baseline projects) and some major RDCs focusing on customization projects and field service (customer projects). Baseline projects were partitioned into subprojects and then placed with regional centers under the project leadership in Munich. Over the years, however, Siemens had followed a strategy of shifting more autonomy to its regional centers to strengthen its global presence. An important consideration for increased autonomy was a center’s technical and project management competence. As ICN’s Carrier Switching co-head Hunke observed: “In contrast to developing consumer products, telecom system development requires long experience, deep technical skills and the ability to manage complex projects.”
Out of a total of 60-70 customization projects per year, about 20 were self-financed by local companies’ sales budgets and required no financial support. In such cases, technical managers would start by talking with customers in the early planning stages for new releases. Customers, in turn, gave new product feature “wish-lists,” which often magically shrank in size after sales managers returned with a matching price estimate. Some leading customers served as test sites for new system features which gave ICN early feedback on problems.
Great variance existed between different centers: the Greek RDC, for instance, was flush with funds to the point of being able to buy out R&D centers from other companies; at the other extreme, the Hungarian RDC had plateaued in growth to sustain only 15-20 developers. The Indian RDC, though a relative newcomer, had grown to well over 600 people thanks to its access to a talented and inexpensive labor pool for software development. The Florida RDC was quite independent not only because it had been in operation for several decades but also because its responsibility for North
American marketing (see Exhibit 10 for various cost comparisons between ICN’s six largest RDCs).
Typically, German managers ran newly formed RDCs, but in later stages local managers gained more control. An ongoing tension was how much independence to provide each center: in general, the more customization an RDC provided for regional customers, the more independent it became.
7 W. Boston, “Too Big, Too Slow? Telecoms titans play catch up on the Net(?),” The Wall Street Journal, Europe, March 15, 1999.

6
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

602-061

How much direction to provide developers working on subsystems in different RDCs also proved an ongoing issue. Having Munich specify all parameters of a project upfront decreased regional flexibility but ensured high product quality. In many projects involving a high degree of innovation, however, it was impossible to do so. Nor was this always desirable. As Dr. Jürgen Klunker, a deputy director in the Siemens Carrier Switching group, wryly observed: “a false sense of security can be created from specifying everything!”
Munich headquarters typically coordinated cooperation between RDC’s through formal channels, including annual technical conferences at Munich involving representatives from different RDCs, as well as through facilitating informal, often serendipitous encounters between different RDC members at Munich. The biggest challenges in coordinating international efforts occurred because of interdependency of subprojects, delays in assembling crucial employees from differing countries, and international coordination overhead—which could cost as much as 15% of project budgets. The utopian ideal of “development around the clock “ by exploiting time zone differences rarely appeared to pan out regardless of which countries were involved. Of course, the potential always existed for cultural or linguistic differences slowing down coordination of work.
Munich coordinated project work through a matrix structure. Generally, individuals worked in different so-called “Centers of Competence” (CoC) groups which were divided along technical lines such as “systems architecture,” “systems testing,” “peripheral systems,” or “core processing.” Each
CoC controlled budgets and milestones for projects in its technical domain. This structure allowed groups to work on new product releases while simultaneously troubleshooting for products as old as a decade or more.
Some 90 project managers acted as midwives for subprojects, bringing them to fruition in line with milestones. More than 40 of these managers held multiple project responsibilities and twenty were involved with customization projects. Although most engineers or software developers knew their personal responsibilities and their immediate supervisors, they could not always identify exactly who was ultimately in charge. They could rest assured, however, that two or three levels above them conflicts over milestones or technical feasibility would eventually get sorted out.
At its Munich headquarters, ICN emphasized the need for solving problems through finding
“common understanding”. Every other Monday, CoC heads met with senior project management for up to four hours to focus on critical issues, especially involving larger subprojects. Higher level problems were resolved at a so-called “Development Board” which met biweekly. For projects involving other RDCs, Siemens ICN held meetings – either in Munich or at the RDC – every six weeks with all involved project managers. Unfortunately, decisions were often delayed for weeks because there wasn’t enough time to resolve all major issues between CoC heads, project managers and senior executives. Complicating decision-making further was that some regional development centers reported directly to independent Siemens companies located in their respective home countries instead of business divisions such as ICN. In such cases, some conflicts had to be settled at the corporate management board level.
At its American RDC, the company had experimented with the use of strongly defined project teams for each release of a product. Managers claimed to find, however, a decline in quality, increased duplication of efforts, and difficulty in motivating individuals to troubleshoot problems with older product releases. Nonetheless, for critical and time-sensitive projects, ICN was now using two or three “strong” project leaders who were individuals being groomed for upper management.
The motivation for change came from its 14-16 month long market cycles (in the form of new
EWSD product releases), which had led to analysts to worry about the company’s future. One industry observer noted: “There’s not much about Silicon Valley that will be familiar to Continental
7
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens AG: Global Development Strategy (A)

executives accustomed to gilded traditions of hierarchy, protected markets, and sacrosanct summer vacations.”8 Boca Raton, Florida: An Old RDC in the New World
Amid the stately palm trees and manicured lawns of Southern Florida, stood the second largest overseas outpost, the Boca Raton Regional Development Center (RDC), which was established in
1978. Some 2000 people (including 600 engineers and programmers) operated primarily in warm
Boca Raton, with access to three airports, and offered a fairly central location for the Americas and
Munich. Technologically, Florida hosted the American space program and had served as birthplace of the IBM personal computer.
Inside the Boca Raton RDC, workers operated in individual cubicles and managerial offices with open doors—a contrast to Munich, where all personnel worked in offices, with junior members sharing office space. Although many of the workers at Boca Raton were foreign-born, they had been to various degrees “Americanized” and acclimated to an informal environment of golf shirts and
Docker jeans. With personnel turnover averaging around thirteen percent per year, newcomers could find plenty of experienced employees for help with, what Boca Raton manager Kevin Holwell termed, “bewildering tasks such as figuring out whom in the Siemens Munich telephone book to call.” As with all RDC’s, the work of the Florida group centered around the EWSD. Munich engineers would transmit the software for each fresh release of EWSD by high-speed data lines to Florida. The
Boca Raton center would then, under project groups as well as Centers of Competence, spend up to a half year customizing the system for the US. To coordinate activities at a senior level, Boca Raton and
Munich held joint quarterly meetings with management, alternating between the two locations. Over the years, the center had accumulated the experience and technical skills to manage complex systems projects. As a large RDC, catering primarily to the vast US market with its unique industry standards, Boca
Raton often drifted technologically apart from Munich. Widening this drift was the need to keep pace with fast-moving competitors. Technologists at Boca Raton would on several occasions act first and then inform Munich. Some managers admitted to the existence of the “NIH or ‘Not Invented Here’ syndrome,” which led each side to duplicate certain efforts. As a result, the Boca Raton group had developed, for instance, some of its own fault analysis tools. One Munich manager described the situation thus: “If you ask an engineer in our Indian RDC to test 1, 2, 3, 4 … in a keypad, they will test 1, 2, 3, 4, and nothing else; but if you ask an engineer in our American RDC to test 1, 2, 3, 4 …, they will test 5, 6, 7, 8…!”
Boca Raton, like other RDCs, also developed specific applications requested by local customers. A prominent example was the “Remote Switching Unit” (RSU), which served as a stripped-down, inexpensive “mini-switch” that could hook up to 5,000 lines in a remote community to one central
EWSD via a “trunk” line. By linking several RSU’s to one central EWSD a telephone service provider could minimize the length of expensive copper wiring needed. Several of Boca Raton’s smaller customers had requested such a system to leverage telephone service coverage of their relatively few
EWSDs. Many other Siemens centers such as the Indian RDC were not considered for the RSU project, as they lacked the prerequisite hardware system design capabilities.
8 S. Baker, “Technology phone giants on the prowl: Europe’s titans are devouring U.S. high-tech Startups,” Business Week

(International Edition), March 22, 1999.

8
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

602-061

Starting June 1997, Boca Raton invested close to 400 person-years on the project. It divided work on the tens of thousands of lines of computer programming into independent subsystems that usually correlated with different areas of technical competence. A project manager kept the entire effort on track which involved coordinated development activities between the U.S., Germany,
Austria and Portugal. System developers shuttled across the Atlantic, supplementing their efforts through biweekly video conferences which were viewed as much less effective. To speed up development, all RDCs had access to remote system testing facilities on a mainframe computer in
Munich which allowed them to test their components 24 hours per day. Post-mortem analysis showed, however, that over five percent of staff years on the project were spent just traveling. The analysis also indicated that the dream of around the clock development of complex products—taking advantage of the world’s time zone differences—had remained just that . . . a dream.
Towards the end of the project, engineers worked 16- to 18-hour days. Intensive bonds developed during these periods between engineers, regardless of national origin, and each side could find much in their counterparts to admire. Many Germans, however, found the non-smoking policies or the lack of public transportation in Florida stifling. For their part, several Americans found it difficult to match Munich beer-drinking abilities. In the Oktoberfest crowds, one American visitor vanished, only to be found, after a tense manhunt, supine in the mud and nodding to a Bavarian band.
Although the RSU project finished with only a few months of delay, Munich and Boca Raton created a “Convergence Group” to stem the divergence between project management styles. As one
German manager observed, “we cannot get the Americans in line with our process; they don’t analyze things at the beginning of a project the way we do. We want our road maps; they will just proceed and then see what happens. Sometimes a week after starting a subsystem project we would get an e-mail stating ‘sorry, we can’t do this!’”
Every several weeks, engineers and managers from both sides convened in either Florida or
Munich. Both sides agreed to keep work styles on the EWSD base as similar as possible through, for instance, using similar testbeds and common Centers of Competence. With regard to software applications, in the words of Florida manager Keith Hohlin, however, they “agreed to disagree” and followed different development processes.

Bangalore, India: A New RDC in the Old World
After its independence from England in 1947—a hundred years after the founding of Siemens—
India developed one of the world’s three largest engineering work forces. Under a socialistic program, central government planners designated Bangalore in South India as the nation’s computational technology center. By 1990, Indian communications engineers had developed a low cost indigenous switching device that could economically link even impoverished rural villages.
Over the decades, however, the worldwide high tech explosion would lure away many programmers with substantially higher paying jobs. By the 1990s, up to a fifth of Microsoft software developers in the USA hailed from the Indian subcontinent.
Fears of a one-way “brain drain,” however, were mitigated by non-resident Indians investing in their motherland technological firms as well as the burgeoning Indian population’s ability to keep churning out talented programmers. Bangalore, with its relatively temperate climate thanks to an elevation of 1000 meters, good educational institutes, and growing cosmopolitanism became known as India’s Silicon Valley. It soon hosted leading multinational corporations as well as domestic companies. 9
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens AG: Global Development Strategy (A)

Siemens had had a presence in India for decades and enjoyed an excellent reputation. ICN’s
Bangalore RDC was set up in 1994 at least partly to avail of inexpensive—at 20% of the German labor costs—and readily available English-speaking software specialists. When work at Bangalore started, some German engineers admitted to feeling threatened about losing their jobs to low-cost Indian labor. To escape local corporate taxation, Siemens established the Bangalore center as an “Export
Oriented Unit” that would not sell product into the Indian market. Starting with just 20 individuals, including 12 German expatriates, the Bangalore center, eventually grew to over 600 strong to become
ICN’s fourth largest RDC worldwide.
The Bangalore center featured American-styled offices with employees in individual cubicles and managers in individual offices on the periphery. Siemens maintained an informal, relatively open atmosphere in which young employees could work without the pressures of bureaucracy. Only three layers of management existed here, as compared with seven in Munich. Overall, the Indian programmers, who were organized along the basis of projects, barely noticed organizational or management changes in Munich.
It took three or four months to get an Indian university recruit up to speed on a project, a year to get to full productivity, and up to a two years to gain proficiency in working with Siemens’s technology. Because Indian programmers trained on inexpensive personal computers they relied heavily on German guidance for working on large systems. With wages skyrocketing, by 2000, a fresh programmer could earn – in addition to health, housing, and vehicle benefits – about $6000 a year; a considerable amount in India (more than twice that of university professors). Salaries could double in three years based on performance. The average programmer worked 40-45 hours/week, but, with no unions to restrict their activities, would often work longer during crunch times with no overtime benefits.
Young Indians regarded Siemens as one of the best employers to work for in Bangalore.
However, with other competitors such as Lucent and Cisco bidding for newly minted software talent, the local job market heated up and Siemens could no longer count on having first pick. Already, by
2000, out of the top 30 most prestigious employers in Bangalore, Siemens had slipped from frontrunner status to a middle-ranking.

Early Experiences at Bangalore
The first sizable software project conducted at Bangalore for Munich involved the so-called
Advanced Multifunctional Operator Service System” (ADMOSS) project. The purpose of ADMOSS was to allow modern call centers to increase their productivity through capabilities such as facilitating telemarketing, interfacing with non-Siemens equipment, or large conference calls (see
Exhibit 11 for product description). ADMOSS was to field some 500 features, chosen from customer
“wish lists” compiled by Munich’s marketing group. Because Munich engineers for decades had only programmed larger computers, ICN sought to develop ADMOSS elsewhere. The task ultimately fell upon Bangalore, with its strength in personal computer programming.
Work in India started right after the RDC’s founding in 1994 and the project later peaked at 150 software developers. Initially, project management was “top-down,” with specifications for various subsystems transmitted from Munich at a high managerial level to Bangalore. Each team of Indian software developers, generally under supervision of a German expatriate or a senior Indian manager, worked from specifications for an entire subsystem. Munich would then test and integrate the work with other subsystems. To complicate matters, specifications were adjusted and fine-tuned throughout the project through a flurry of emails and faxes between Germany and India.
10
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

602-061

With such a highly complex project, according to senior project managers, “not all specifications were finished by our Munich office since we ourselves were not given enough time!” The first real workshop involving middle and lower level managers and programmers only occurred in late 1995.
Up to that point, according to Bangalore-based senior manager, A. Anuradha, “we were groping in the dark.”
Like their brethren throughout the world, Indian software developers had faced the frustration of stopping work because of budgetary cuts or because of changing needs of customers. On one occasion work on a billing application was stopped midstream after a half-year’s work because of the customer’s changing needs. Although this type of work interruption involved only some 15-20 personnel at Bangalore each year, programmers admitted to feeling “demotivated,” wondering about how much miscommunication might have been going on several thousand kilometers to the West.
Finally, when all two million lines of the ADMOSS computer code were melded together to attempt to create a seamless, integrated system, many problems surfaced. As it turned out, subsystems were far more interdependent than had been assumed. Since Bangalore developers worked thousands of kilometers away from the Munich test beds, testing of newly integrated system turned out to be a major obstacle. To worsen matters, visa restrictions and bureaucracy on the part of the German government made it extremely difficult to fly Indians developers to Munich.
For the few Indians who obtained visas, “the first trips were exciting,” observed Anuradha. “In fact, there was no substitute for going: this way we could see the full behavior of the system. But with things not working out, we had mixed feelings!” On one occasion, Indians temporarily stationed in Munich were flown to Nuremberg to help solve a customer’s problem that, on further investigation, could have been solved by the local service department, had it consulted the basic manuals more carefully. For the Indian team, however, this provided a welcome initial encounter with a Siemens customer.
ADMOSS was finally released to a German customer at the end of 1996 – about a year late. “This was with some embarrassment,” according to Hans Hauer, VP of software R&D, “because as
Germans, we expect delivery on time and with quality!” The system turned out not to be fully stabilized and kept crashing. Other minor problems also emerged. The user interfaces designed by the young Indian programmers were sometimes found to be “flashy and distracting, resembling video game interfaces.” “Overall, the customer was upset!” admitted Hauer. Munich immediately standardized user interfaces and also took control of documentation because customers found the
Indian-written documents too technical.
ICN managers also found visits to Bangalore more productive with several small meetings. An initial large meeting, in fact, proved a disaster since Indian department heads found it impolite to speak their minds in front of everyone. The groups, however, could never get as small as the
Germans would like primarily because of insufficient Indian personnel with large systems experience. With time, the Indo-German team corrected the system faults and delivered a stable, working system to Munich. ADMOSS ended up highly popular with customers. The Bangalore site remained active with after-sales service, eventually correcting over 90% of ongoing faults. By 2000, a skeletal crew of about 50 programmers in Bangalore and 20 systems developers in Europe maintained the
ADMOSS system and produced yearly updates.

11
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens AG: Global Development Strategy (A)

East is East, and West is West?
The ADMOSS project crystallized several problems in managing the Bangalore division. Primary among the problems was the high turnover rate among Indian programmers in the increasingly heated local job market (see Exhibit 10). With competing firms regarding Siemens experience highly, recruiters would entice young software developers with better salary offers. In this environment, annual turnover at the ICN Bangalore center could reach as much as one-third. Making it even harder to retain staff was the eagerness of Indian programmers to openly discuss salaries in the hallways or canteen. This surprised most Germans who had grown up viewing India as supposedly a “nonmaterialistic” culture. According to German expatriate Richard Bock, “the Bangalore programmers would even ask salary information of the Germans, who would become red in the face.”
The career-related impatience of young Indian programmers also caught the Germans by surprise.
The fresh recruits at Bangalore were sometimes shocked by the prospect of being on a project for over a year. For many of them, a “dream project” would preferably last less than a half-year long and involve “leading-edge” areas such as mobile communications or Internet protocols (rather than areas such as quality testing or integration).
In every other way, however, the Germans found the Indians polite – almost too polite. Siemens managers observed that the Indians rarely said “no” to any request, even if it turned out beyond their capabilities. Feeling cultural issues might be involved, developer Richard Bock was asked to
“decode” the Indian way of communication. Bock’s three years in India had tinged his English with a head-turning South Indian accent and taught him that “the cultural awareness materials and roleplaying exercises we engaged in at Munich were simplistic and out of date, and did not take into account the wide cultural variation within India. The warnings about Indian workers not being
‘well-motivated,’ applied perhaps to factory workers [in a socialist system], and not at all to our
Bangalore people.”
Bock was soon able to explain that the phrase “there is no problem” meant to Indians that, “we do not see any problems in the sub-system on which we have been working.” To the Germans, however, it meant, “within the entire system there is no problem.” A related issue involved the Indians’ understanding of fault analysis. To the Indians, the top priority was to solve a fault and not to take an additional four annoying minutes to document each of the hundreds of faults. To the Germans, however, tracking the faults themselves was essential for monitoring the health of systems development and maintenance. It also allowed informing customers about whether a fault was in the
‘analysis phase’ or in the ‘correction phase.’
Bock also found little substitute for face-to-face interaction: “Sometimes you think a point has been settled on the phone, but then three days later you may get a phone call asking, ‘why don’t we try this other approach?’ Programmers in Munich or Vienna will follow customer-defined specifications out of a sense of duty. But in India you have to give the workers a sense of belonging, through early workshops or other means; otherwise, if you ask for a fridge you might get a toaster!”
Few on either side, however, appeared willing to use cultural differences as an excuse for miscommunication, although such clashes were inevitable on occasion – for instance, when one orthodox Indian refused to pick up his official correspondence on astrologically “non-auspicious” occasions. Occasionally, Indians would interpret directness or bluntness on the part of a German as rudeness. Several Indian programmers admitted their frustration when, after learning to say “no,” their exercise of this magic word in order to extend a subproject deadline was once met with, “That is not acceptable.”

12
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

602-061

Overall, the Indians felt well-treated by their German employers. The Germans in turn remained relatively pleased by their enthusiastic, hard-working, and talented Bangalore programmers.
Expatriates essayed their hand at subcontinental passions including cricket and Indian food. They did receive a bonus “hardship pay,” which one expatriate earned after turning beet red from mistakenly swallowing an entire Indian hot pepper (a story the Indians relished in recalling).
Expatriate manager Ralph Sussick gamely earned his bonus by spending his first weeks apart from his family in an unlit apartment still under construction. The perks, however, included personal chauffeurs and entry into the highest levels of Indian society. Over the years, one German couple gave birth while in Bangalore, and even a few Indo-German marriages occurred.
Noting a complementarity between the German and Indian approaches to work and life, Indian manager Sai “Charlie” Sreekanth M., stated: “The Germans manage depth well; we manage breadth well. We idolize our ‘all-rounder’ – the person who does well in sports, debate, and academics. And socially, we’re happiest arguing about a great many things in coffeehouse settings!” This contrasted with observations that greatly amused Indians in Munich of certain German employees who with clockwork precision caught exactly the same commuter train everyday.
Managing breadth well implied that the Indians could cover for each other to keep a project rolling even in the midst of vacations, illness, or job resignations on part of any team member. The complementarity between the German and Indian approaches to career, however, allowed Bangalore project manager Santosh Prabhu to observe: “when I was working on a subsystem, I definitely found it simpler to have my Munich counterpart – who had been working on it for well over five years and thus knew it inside-out—make corrections and provide feedback about its eventual performance.”

The NetManager Project
The Germans created the world’s most reliable telecommunications systems over a period of decades.
Even they cannot be expected to produce a new system that is as highly reliable in just two or three years!
— Bangalore Software Developer
By the mid-1990s, personal computers had grown in power and capabilities to the point of controlling access to an entire switching system responsible for routing tens of thousands of calls. At
ICN, this realization gave birth to the “EWSD NetManager” project. The user-friendly and graphicsbased software product would offer telecom customers a complete range of facilities for performing all operating, administration and maintenance functions on EWSD network nodes and networks (e.g., integration of new telephone subscribers, billing, enable “traffic studies” to understand customer needs, and provide system surveillance). Not surprisingly, NetManager development required a deep understanding of EWSD technology and its 6,000 or so functions.
Creating NetManager would entail, however, programming in desktop computer languages and systems with which Munich product developers lacked experience. ICN over the decades had, after all, developed and refined its own computer language “CHILL” for its large proprietary operating system. It would have taken months to get up to speed with Windows-based systems, let alone learning to deal with quirks of an entirely different system (e.g., memory space problems that necessitated frequent re-booting of computers). Because of budget cuts at Munich, ICN senior managers deliberated over which regional development center should develop the NetManager.
Boca Raton and Bangalore emerged near the top of the pile of contenders. Some argued in favor of Boca Raton because of its greater experience in working on large, complex systems and its knowledge of EWSD systems. Others argued in favor of India because of cost advantages. By now,
13
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens AG: Global Development Strategy (A)

however, the cost advantages of working in India were rapidly diminishing thanks to roughly 25% annual wage increases for developers in Bangalore. In fact, after factoring in other costs such as information transfer, travel, job-training, and management costs, working in Eastern Europe was now perhaps cheaper than working in India. The NetManager assignment eventually went to Bangalore because of staff availability, familiarity of the Indians with personal computer-based programming, and budgetary restrictions at Western RDCs. Work at Bangalore commenced in early 1996 with an initial force of 30 programmers. The June 1998 pilot release involved some 300,000 lines of code and proved a hit at the customer test sites. ICN then apprised several important clients including
Deutsche Telekom about its forthcoming product.
The world of personal computing and telecommunications, however, had changed rapidly by now. What was envisioned as a simple, isolated, "low-end" product with low reliability gradually transformed into a complex and highly visible product for large customers. Where initially the
NetManager was meant to allow one personal computer to control just one element of the system, now it had grown in scope to enabling one PC to control a network using 20 servers and 30 terminals.
This implied that the entire project would no longer be shielded from the challenge of managing interdependencies with many other Siemens telecommunications products. It was no wonder that
NetManager, by spring 2000, would involve 60% of the Bangalore center’s staff.
Thanks to an old “testbed” sent by Munich after lessons learned from the ADMOSS experience,
Indian programmers could now test subsystems as they were developed. By November 1999,
Bangalore sent its complete NetManager Version 2 to Munich for testing. Typically Munich tested
“stability” (or reliability) of new software by installing and launching it on a Friday afternoon and hoping to find no errors in the test log on Monday. NetManager Version 2, however, ran only one hour before crashing to a halt.
A check of the test logs ultimately revealed a staggering 700 faults hidden at various points along some 600,000 lines of computer programming code, with 100 categorized as serious “Level I” faults.
Initial trouble-shooting indicated that each fault could not simply be corrected individually, since each correction could create ripple effects across the entire system. The Bangalore RDC quickly boosted its staffing on NetManager and software developers worked seven days a week to solve the crisis. Three Indian developers were sent to Munich for more than one month.
A late-November 1999 workshop in Bangalore involving managers from Munich and India tracked down the root cause of quality problems. As it turned out, the Indian group assumed, as in the case of most desktop computing applications, that the system would be shut off at night, and that it was acceptable for a desktop-based computer system to crash once a week. This assumption was further reinforced by an understanding that operation of the EWSD switch itself would not depend on NetManager. Furthermore, the Indian team underestimated system usage by an entire order of magnitude. “We were ignorant!” admitted an Indian programmer, “we didn’t think of asking what loads to test with, but Munich was also at fault for not telling us!”
Some of these erroneous assumptions could ultimately be traced to different work schedules. In the crucial summer months, many Germans went ahead with their several weeks-long pre-booked family vacations – often without leaving contact information – stranding the Indians. During crisis periods, Indian programmers, in contrast, typically took only personal leaves of two or three days, and worked 70-80 hours per week or even more. Balanced against this, however, was the ongoing high attrition rate in Bangalore.
In January 2000, Siemens, with one Bangalore engineer present, went ahead with the planned demonstration of NetManager to Deutsche Telekom. But even the Munich testers did not appear well-prepped for the tests, leaving Bangalore programmers to wonder why it had commenced in the
14
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

602-061

first place. The result proved disastrous: far too many reliability errors cropped up. Deutsche
Telekom halted the tests immediately.
In February, post-mortem analysis indicated that the old testbed sent to Bangalore was smaller than those used at present and thus could not detect all design problems. Another three Bangalore programmers went to Munich to help iron out the reliability wrinkles on larger testbeds. One of these was software manager Lalitha J.S., who recounted: “The Munich people were very nice. They did say that ‘these problems are causing us commercial consequences,’ but they never threatened our group or said, ‘Hey Bangalore, what’s up!’ The face-to-face interactions helped; otherwise, back home we were sometimes thinking, ‘were they making things up?”
Senior management set the deadline of August 2000 for fixing all version 2 faults. The top managers decided that the version 3 release planned for July 2000 should be scrapped and merged into a fully reliable version 4 product, promised to customers for Spring 2001.

Deutsche Telekom Calls
Eberl and Hunke knew that immediate action would be needed. The NetManager Project had clearly mushroomed in size and strategic importance beyond that initially envisioned. Deutsche
Telekom, ICN’s largest customer was demanding the product but also issued a warning that reliability problems would not be acceptable. As a result, some German executives had already suggested that NetManager development and project management should be moved to Austria,
Belgium, or Portugal. In the shorter term, they argued that further delays were inevitable even if the project remained in Bangalore and that decisive action was long overdue. In the longer term, this would also bring the system developers and programmers closer to Siemens’s major customers and smooth out coordination problems with India.
But already some 50% of NetManager resources, development and project management were based in Bangalore. Transferring these project activities back to Europe would involve a delay of several weeks during which time Indian and German software developers and managers would have to shuttle back and forth across the Arabian Sea. Relocating the NetManager project might also cast a pall over the Bangalore. Over the years, Indian managers had begun suggesting to change their RDC from a software development outpost for Munich into a center with status equal to that of, say, Boca
Raton. As one Indian manager, C.R. Rao, observed: “We would like to climb up the value chain to work with customers, create growth and career opportunities, and start charting our own destiny.”
Such an evolution would, among other things, require major investments and a significant expansion of system-testing and hardware design capabilities.
As an alternative proposal to relocating core NetManager activities to Europe, some Siemens managers suggested moving major project responsibility and accountability to Munich but leaving all development activities in Bangalore. While travel and coordination cost would increase, this proposal ensured strict project management and quality control while keeping Indian software developers on NetManager. It was unclear, however, if a project of such complexity could be managed by people living thousands of miles away.
In the meantime, the late afternoon pollution thickened as the traffic weaved without slightest regard for lane markings. If Bangalore was to grow into a world stature city, it would need to discipline its pollution and growing traffic.

15
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens AG: Global Development Strategy (A)

Exhibit 1

History of Telecommunicationsa

Prehistory +

Use of smoke signals, tom-toms, carrier pigeons, runners, horse-back messengers, and many other systems developed independently by many cultures for conveying messages across great distances.

Late 1700s

Visual systems used to convey messages over long distances. Semaphore system developed in France.

1820-1837

Hans Christian Orsted (Denmark) discovers that a wire carrying electric current can deflect a magnetic needle; Michael Faraday (Britain) and others refine science of electromagnetism. 1837

Cooke & Wheatstone (Britain) obtain patents for first telegraph. Samuel Morse, professor of painting and art in New York City, is granted patent on system for communicating information using electromagnets (represented on paper by dots and dashes). His first public transmission from Washington D.C. to Baltimore, “What hath God wrought!” ushers in telegraph era.

1847

Together with business partner Johann Georg Halske, Werner Siemens begins to manufacture pointer telegraphs, a product of his own invention, and lays the foundations for electrical engineering giant Siemens AG.

1876

Alexander Graham Bell patents telephone.
Originally intended to supplant telegraphy, the two technologies coexist for decades to come.

1877

First public telephone exchange installed. The first system (New Haven, CT) allows up to 21 callers to contact one another and is manned by human operators who must physically connect the caller’s line to the called party’s line. Quite rapidly, the system grows to accommodate hundreds of users.

1913

First electromechanical switches installed. By 1974, one of these systems can handle up to 35,000 calls.

1918

“Modulated carrier” technology allows for many different messages to be transmitted simultaneously over a single telephone line. Vacuum tube circuits amplify and regenerate weak signals to allow for more efficient signal transmission.

1947

Transistor invented. Allows for smaller, faster switching devices based on electronic, rather than on electromechanical, components.

1960s

AT&T introduces Electronic Switching System (ESS) that combines numerous new technologies including semiconductors for switching. Allows for up to 65,000 calls per switch

1976

Switching systems developed by AT&T that allow voice data to be digitized into smaller packets of information that can be sent from caller to called party through more flexible, efficient routes. These flexible systems allow for handling 100,000 lines and laid the basis for modern switching systems.

1980

Siemens ICN develops the EWSD digital electronic telephone switch which would become the most reliable and bestselling voice switch in the world.

aMuch of the timeline information is adapted from: The New Encyclopedaedia Britannica Macromedia, v. 28, “Telecommunications
Systems” 1997, pp. 473-504.

16
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

Exhibit 2

602-061

Cost per Service Transaction in Industrialized Countries (estimate)

Internet

0.05

Direct Mail

0.55

Interactive Voice
Response systems

0.56

Automated Teller
Machines

1.05

Call Centers

5.04

0

1

2

3

4

5

6

US$

Source: Siemens AG

17
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Exhibit 3

Siemens AG: Global Development Strategy (A)

Siemens Statement of Income (German Marks in millions)

Siemens Worldwide Income
(Year Ends Sept. 30)
Year

1999

1998

Net Sales

134,134

117,696

Cost of sales

(96,014)

(85,780)

38,120

31,916

Gross profit on sales
Research and development expenses

(10,240)

(9,122)

Marketing and selling expenses

(19,120)

(17,672)

General administration expenses

(5,185)

(3,616)

1,618

951

(2,570)

(883)

544

474

1,807

1,451

679

(451)

(40)

390

5,613

3,438

(1,965)

(780)

3,648

2,658

Other operating income
Other operating expenses
Net income from investment in other companies
Net Income from financial assets and marketable securities
Net interest income (expense) from Operations/Pension Fund
EBIT from Operations
Other interest (expense) income
Income from ordinary activities before income taxes
Taxes on income from ordinary activities
Income before extraordinary items
Extraordinary items after taxes
Net Income

(1,741)
3,648

917

Source: Siemens AG Annual Report 1999

18
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Siemens Corporate Structure

Exhibit 4

Corporate Structure
Managing Board
Corporate Executive Committee

Groups

Services

Energy

Power
Generation

Industry

KWU

Automation and Drives

Information and Communications

A&D

Information and
Communication
Networks

ICN

Health Care

Medical
Engineering

Corporate Departments

Financial Services

Med

Siemens Financial SFS
Services GmbH 1

Siemens Real Estate
Management
Siemens
Procurement and
Logistics Services

SIM
Finance

Human Resources

EV

Industrial
ATD
Projects and
Technical Services

Information and
Communication
Mobile

Licht

Osram GmbH

VT

Siemens
PL
Production and
Logistics Systems AG 1

Siemens
SBS
Business Services
1
GmbH & Co. OHG

Infineon
Technologies
AG 1

SQT

AT

Siemens Building SBT
Technologies AG 1

ZT

Siemens
Berufsausbildung

SIB

Planning and Development

ZU

Infineon
Common
Personnel Services

GPS

I and C
IC CAM
Corporate Account
Management

Siemens
Automotive AG 1

Technology

SU

1

Components

Transportation

Transportation
Systems

Siemens
Management
Consulting
Siemens
Qualification and Training

ICM

ZP

SPLS

Lighting

Power
Transmission
and Distribution
Verkehr

ZF

Legal Services

Corporate Offices e-Business eB

Procurement and Logistics

EL

LS

1

RWS

Information and
IK
Knowledge Management

Regional
Marketing Services

Regional Units: Regional Offices, Regional Companies, Representative Offices, Agencies

Accounting
Services

RMS

Management
MCP
Consulting Personnel

Services for Advertising and Information

SWI

Corporate
Communications
Economics and
Corporate Relations

UK

WPA

legally separate Group

ZU S 2 - September 29, 2000

Issue: October 1, 2000

Source: Siemens AG

This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

-19-

Source: Siemens AG Annual Report 1999

(3)

(2)

133,573

117,338

2,643

1,325

2,230

5,636

6,530

7,414

5,560

5,029

3,852

15,179

23,405

2,239

7,923

11,368

6,439

10,566

1998
74

(16,316)

235

314

1,275

359

93

9

14

2,782

2,468

607

716

375

2,111

2,253

385

1999
83

(14,909)

215

353

1,058

28

58

8

17

2,355

2,582

453

334

2,405

2,378

510

1998

Intersegment sales

131,327

(13,493)

1,619

2,788

8,261

7,158

7,980

6,389

5,808

7,055

19,145

24,029

8,334

2,511

8,054

13,820

6,358

15,511

1999

115,266

(12,266)

1,540

2,583

6,694

6,558

7,472

5,568

5,046

6,207

17,761

23,858

2,573

10,328

13,746

6,949

10,649

1998

Total sales

5,810

(326)

17

283

101

680

660

310

(122)

8

956

1,061

319

150

279

1,447

248

(261)

1999

EBIT

3,198

6

78

327

(852)

643

283

293

(746)

(258)

501

1,143

111

289

1,385

191

(196)

1998

-20-

Due to the short time of affiliation with Siemens, only the assets and liabilities of SBT were included in the consolidated financial statements at September 30, 1998.
Comprising substantially all of the former HL activities.
“Other” primarily refers to centrally managed equity investments (such as BSH Bosch and Siemens Hausgeräte GmbH, Munich), liquid assets of operations, corporate items relating to Regional Companies, and corporate headquarters.

Total

(1)

2,823

1,384

Electromechanical Components (EC)

Eliminations and other

2,474

Passive Components and Electron Tubes (PR)

(3)

6,799

7,887

Medical Engineering (Med)
6,986

6,380

Automotive Systems (AT)

Infineon (HL) (2)

5,794

Osram

4,273

Transportation Systems (VT)

16,677

Information and Communication Products (ICP)

Siemens Business Services (SBS)

23,422

7,618

Siemens Building Technologies (SBT) (1)

Information and Communication Network (ICN)

5,943
2,136

Production and Logistics Systems (PL)

11,567

5,973

15,437

Industrial Projects and Technical Services (ATD)

Automation and Drives (A&D)

Power Transmission and Distribution (EV)

Power Generation (KWU)

1999

External sales

Siemens Financials by Segment (German Marks in Millions)

Operations

Exhibit 5

602-061

For the exclusive use of N. Sinden, 2015.

This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

Exhibit 6a

602-061

Worldwide Voice Switch Equipment Market (1999) — By Supplier a Rank
1999

Supplier

Headquarters

1
2
3
4
5
6
7
8
9
10

Alcatel
Siemens
Lucent
Ericsson
Nortel
NEC
Fujitsu
Italtel
Nokia
Others

France
Germany
USA
Sweden
Canada
Japan
Japan
Italy
Finland

Voice Ports Shipped (in thousands)
Worldwide
%
Shipments
Share
18.1%
15.0%
13.0%
10.0%
8.3%
6.7%
4.5%
0.8%
0.4%
23.3%

100,965 a 18,244
15,135
13,083
10,051
8,361
6,797
4,559
778
383
23,574

100%

One voice port is equivalent to a single telephone line. Siemens EWSD systems are scalable to roughly 240,000 voice ports, with costs anywhere from $500,000 and $10 million, depending on the number of ports (with a marginal cost of up to $100 per port).

Source: Gartner Dataquest (estimate), Siemens AG

Exhibit 6b

Worldwide Voice Switch Equipment Market (1999) — By Region and Supplier

Supplier
Alcatel
Siemens
Lucent
Ericsson
Nortel
NEC
Fujitsu
Italtel
Nokia
Others

Europe
6,969
7,319
1,049
5,804
1,263
404
0
727
292
1623

North America
0
610
6,115
57
4,507
731
0
0
0
13,512

Latin America
563
247
434
1,180
558
740
11
46
0
4,911

Middle
East/Africa
2,051
2,203
54
256
627
635
53
0
0
5,879

Asia/Pacific
8,661
4,756
5,431
2,754
1,406
4,287
4,495
5
91
73,162

Ports shipped
(in thousands)

25,450
(25.2%)

12,767
(12.6%)

4,345
(4.3%)

5,879
(5.8%)

52,524
(52.0%)

Source: Gartner Dataquest (estimate), Siemens AG

21
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Exhibit 7

Siemens AG: Global Development Strategy (A)

EWSD Digital Electronic Switching System

• Open EWSD system with flexible hardware and software architecture
• The number of racks depends on the capacity of the system
• EWSD platform can accommodate fixed and mobile communications networks

• Open rack reveals a modular design
• Multiple modules make up EWSD system

• Each module frame consists of assembly rails, side section and guides for modules.
• System capacity can be increased by adding modules to each frame
• EWSD modules are controlled by software such as NetManager (developed in Bangalore)

Source: Siemens AG

22
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

Source: Siemens AG

Developm ent
Platform S ystem s
Quality and E nvironm ental
M anagem ent

Developm ent
Peripheral System s
Planning, Logistics
Policies and G uidelines
Special Projects

Product Line
M anagem ent

Exec utive Offices

Deve lopm ent
Syste m Applications

Syste m Integration/T est
Deve lopm ent S upport

Enterprise Netw orks (E N)

Softw are Com m unication
System s (Bangalore, India)

Developm ent
System S oftw are

Project
M anagem ent

Carrier S w itching Netw orks (W N CS)
H orst E berl (H ead)
K arl-Friedrich H unke (B usiness/Finance)

W ireline Netw ork
Com m unication (W N)
D r. W infrid B üttner (Head)
K laus H elsen (B usiness/Finance)

System
Engineering

Inform ation and Broadband (IB)

Inform ation and Com m unication Netw orks (ICN)
Roland K och (Chairm an)
Hans-W alter B ernsau (V ice P resident)
Jost S pielvogel (V ice P resident)

S iem ens AG
M anaging B oard
D r. H einrich v. P ierer (P resident and Chief E xecutive O fficer)
C hairm en of V arious D ivisions (IC N, Infineon, K W U, etc.)

Position of Carrier Switching Division (CS) within the Siemens Organization

T ransm ission (T R)

Exhibit 8

Integration, S ervices and Applications (ISA)

602-061

-23-

For the exclusive use of N. Sinden, 2015.

This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

Exhibit 9

Source: Siemens AG.

Manufacturing sites in 20 countries

Regional development centers in Europe, Asia, Africa, America, and Australia

LEGEND

Siemens ICN Regional Development Centers (RDCs) and Manufacturing Sites around the World

602-061

-24-

For the exclusive use of N. Sinden, 2015.

This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

Exhibit 10

Regional
Development
Center (RDC)

602-061

Internal Cost Benchmarks of Largest Regional Development Centers (1999)

Total Development Effort a for Siemens ICN-Wireline
(Person(Thousand
Years)
Euros)

Annual Cost of b One Developer
(Thousand
Euros)

Employee c Turnover
(% of
Total Staff)

Coordination d Cost
(% of
Total Effort)

Austria

500

50,000

100

4%

8%

USA

200

20,000

150

13%

3%

India

300

8,000

40

35%

15%

Belgium

100

10,000

100

12%

5%

Slovenia

90

5,000

60

5%

6%

Portugal

80

6,000

70

17%

6%

a

Effort used by ICN only; total size of development center may be significantly larger
Fully-loaded person-year (salary, benefits and overhead) c Annualized turnover (or attrition) of development staff d Travel, meetings, teleconferences, etc. incurred by Munich headquarters in supporting each RDC b Source: Siemens AG

25
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
602-061

Exhibit 11

Siemens AG: Global Development Strategy (A)

The Evolution of Call Centers in the Telephone Industry

Siemens transit exchange center Berlin, Germany, 1906

Modern call center at major
Telecom operator using
ADMOSS call service software and EWSD telephone switching system Examples of ADMOSS (Advanced Multifunctional Operator
Service System ) Call Center Solution Features:
• Call distribution system and queues (e.g., route call to operator with required language skills)
• Switching features (e.g., conference calls of up to 25 participants)
• Booking system (e.g., advance booking of calls between US and India)
• Directory assistance (e.g., number appears as SMS on mobile phone)
• Charging features (e.g., cost information available prior to call)
• Announcements (e.g., position of caller in queue)
• Internet services (e.g., caller contacts operator through Internet link)

Source: Siemens ICN.
26
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.

For the exclusive use of N. Sinden, 2015.
Siemens AG: Global Development Strategy (A)

Exhibit 12

602-061

Terminology

ADMOSS

Abbreviation for Advanced Multifunctional Operator Service System.
Siemens ICN software product used by call centers to manage telephone services such as directory assistance, billing, conference calls, etc.
ADMOSS is designed to be used with EWSD voice technology.

Backbone

Part of the communications network which carries the heaviest traffic.
The backbone interconnects the devices (switches and edge devices) to which customers are usually connected.

Bandwidth

Bandwidth is the width of a communication channel measured in “bits per second” or bps. High bandwidth implies that more information can be moved through a channel at the same time. Low bandwidth connections (e.g., phone dial-in) are typically fractions of 64 kbps
(kilobits per second). High bandwidth connections usually supply several Mbps (megabits per second).

Broadband

Transmission facility providing high bandwidth. Such a facility can carry voice, video, and data channels simultaneously.

EWSD

Abbreviation for Elektronisches Wählsystem Digital or Electronic
Switching System Digital. EWSD is a voice switch and Siemens ICN’s flagship product.

Digital subscriber lines
(DSL)

A technology that uses existing copper telephone lines to transmit voice and data at high speeds (up to 8 Mbps).

Integrated services digital network (ISDN)

Switched network allowing for provision of both voice and data services over copper wire (up to 128 kbps).

Internet protocol (IP)

The set of rules that specify how data is cut into packets, routed and addressed for delivery between different Internet nodes.

Packet switching

A way of sending data through a network to another location by subdividing the data into individual units or packets, each with a unique identification and destination address. Data is received by reassembling packets at destination.

Telecom Switch

A device that interconnects traffic (voice or data) from one port to another based on information within traffic (e.g. IP addresses), signaling (e.g. intervoice switch signaling) or predefined routes.

Voice switching

A way of sending and receiving voice through a network of telephone lines and switches. Voice switches reserve resources for the duration of a call which ensures high quality of voice transmission. In contrast, packet switching usually does not reserve similar resources, leading to dropped packets and delays and thus lower voice transmission quality.

Sources: S&P Communications Equipment Industry Survey 2001, Siemens AG, case authors

27
This document is authorized for use only by Nykolas Sinden in IT Services & Project Management taught by Robert Hornyak, Arizona State University from May 2015 to November 2015.