Reviewing The Siemens Information And Communications Network Information Technology Essay

Siemens Information and Communications Network are composed of several regional development centers around the world. One of those, located in Bangalore, India, was given the tasks of developing two large scale Softwares during the 1990s. The first of those, called ADMOSS (Advanced Multifunctional Operator Service System) was designed to facilitate modern call centers with some 500 features. The second one which followed after five years was called NetManager, it had a user-friendly, and graphics based user interface and some 6,000 features regarding administration and maintenance of EWSD network-nodes and networks. Both of these projects suffered huge deadlines-slippages, faulty design (at least initially), undetected-till-last-stage errors, embarrassment with customers and miscommunications between ICN’s Munich headquarter and its Bangalore’s development center1. The following is an attempt to analyze the issues, their causes and possible avoidances for any similar projects.

By the late 1980s Munich has recognized the talented human resource available in India. It was huge, both in terms of head-counts and knowledge. It was cheap, initially available at just 20% cost of a similar German software developer, which later in decade increased to 25%. It also had unmatched performance, in personal computers programming, in which ICN has deficiency in available human resource. Most ICN developers had worked on large systems and had little to no experience of personal computers programming. In contrast, Indian programmers have grown up experimenting with earlier version of desktops and laptops and by 1990s have reached level of expertise in some areas. Capitalizing on this resource, ICN decided to have the two projects done in India, in spite of huge cultural incompatibilities, language problems, physical distance and visa issues.

The first project given to Bangalore was in no way any minor thing. It was made for existing and large customers of Siemens that heavily depend on it. It might be a non-optimal decision made by Munich but being risky it also promises huge benefits at end.

ADMOSS had to facilitate telemarketing interface with non-Siemens equipment and handle large conference calls for example, among its other tasks. No surprise that at peak, 150 software developers were working on ADMOSS in Bangalore alone, in addition of local and German managers, testers and other supporting staff.

The project was managed centrally by Munich, sending specifications for each of the subsystem to a high managerial level in Bangalore. This decision of central management was made perhaps due to initial distrust by Germans on Indians as it was their first encounter with them. In India, each subsystem was managed by a German or Indian manager who works with little co-ordination with each other. Once a subsystem is developed and tested locally is sent to Munich where it is integrated with the rest of the system. This method, though gave high power to Munich and enforced strict quality control has a design flaw, a programmer might be expert and identify flaw in the subsystem he has worked on, but cannot easily identify any integration errors. This method would have worked if Munich had a good size of its own programmers who tackle all the integration errors.

The matters became more complicated due to the fact that the requirements of the software were not totally finalized at the start. While programmers are accustomed to “run-time” wishes made by clients given after the development has started and try their best to accommodate that, in large systems such as ADMOSS which also requires very large scale of precision (99.999% or “five nines”) its very hard to accommodate that once a system is already in development. While the project was being developed, a ray of emails and faxes kept coming with change requests resulting in inevitable design flaws and test failures. Later on, the developers had to work long hours to wrinkle out those design flaws to ultimately produce highly reliable software. If we try to find who is responsible for that, the blame comes on the marketing team in Munich that may have over-promised and was definitely not documenting and discussing every requirement with client. Some blame also goes to the client, who being a large corporation itself and had used software since a long time should know that run-time modifications often corrupt the project and requires heroic efforts by programmers to save the day.

On one occasion, work on a billing application was stopped midstream after half a year’s work because of customer’s changing needs. Although this type of work interruption involved only 15-20 personnel at Bangalore each year, a programmer admitted to feeling de-motivated wondering about the intensity of miscommunication between Bangalore and Munich. This sometimes leads to the problem discussed later, “high employee turnover”, where programmers attempt to shift to those jobs where requirements are perceived as stable.

Finally, there was problem of lack of sufficient attention given by high managers in Munich. In the words of a senior project manager, “not all specifications were finished by our Munich office since we ourselves were not given enough time!”

Finally, when all two million lines of ADMOSS code was compiled together to create an integrated system, many problems surfaced. Major of them are: subsystems were found to be more interdependent on each other than desired, and, test criteria and tools were different in Bangalore and Munich. The first of these appears to be a shortcoming on part of developers in Munich who were responsible for integration of the subsystems and in a significantly smaller way on the subsystems developers in India. The second one, is definitely a management lapse made by Munich headquarter, the same test beds as used in Munich must be provided to Bangalore at the initial stage to ensure local error-testing and removal. That would have saved a lots of monetarily and temporal costs that the company had to finally bare.

ADMOSS was finally released to the German customer at the end of 1996. As Hans Hauer, VP of Software R&D put it, “This was with some embarrassment because as Germans we expect delivery on time and with quality”. The system turned out not to be fully stabilized and kept crashing. There were some minor problems too, like the user-interface being unprofessional, as the client commented, “flashy and distracting, resembling video game interfaces”, too technical style of documentation etc. When we analyze the causes of these problems a few things come up: first, the part of embarrassment due to delay is a fault of Indians but not much because at least six months efforts were lost not by any mistake of programmers but by a huge blunder made by client and sales team (discussed above). Second, the part of embarrassment due to delivery of a low quality product is fault of Munich who delivered a product not fully tested. Third, the inappropriate design of user interface is perhaps due to non-sufficient communication about its requirements made by managers to the programmers. In absence of any stated and restricted user interface requirements, the programmers made the user interface as they liked it which of course not satisfied the customer. Fourth, Indians attempt to make documentation too technical for customer is perhaps due to language problem and cultural mismatches, which can’t be blamed to any party.

In spite of all of these issues, 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.

The second project given to Bangalore was called NetManager. It would be a user-friendly and graphics-based software product that would offer telecom customers a complete range of facilities for performing all operating, administration and maintenance functions on EWSD nodes and networks (e.g. integration of new telephone subscribers, billing, enable “traffic studies” to understand customer needs, and provide system surveillance etc among its 6,000 functions).

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. Munich learned from the past project and gave Bangalore the same test-bed it was using so that developer can test the system as they develop it.

By November 1999, Bangalore sent its complete NetManager Version 2 to Munich for testing. Typically Munich tested “stability” (or reliability) of new software installed by launching it on 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 1” 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.

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 were 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 the ongoing high attrition rate was in Bangalore.

As we analyze the issues and their causes, it is found that although the requirements were stable this time, which was a huge accomplishment on part of marketing team and upper management, it was not fully communicated to developers. This can be traced to faults of middle and lower management. As was in the user interface design of ADMOSS, since requirements were not explicitly stated the programmers made their own assumptions which (like in previous project) didn’t match the requirements of the company or the customer.

Another cause was often unavailability of appropriate personnel at Munich for communication because at the most crucial summer season of development they are out on long vacations. They do so often without any means of communication left. In that case, a developer would either have to wait for the person to return (which was of course unacceptable) or make his or her own assumptions to continue with the development. The solution is either to reschedule the vacations time period to some less crucial months (lets say spring) or the person keep in contact with ICN through a phone. In case of a vacation trip to very remote location where telephone is unavailable, the person should call to company as soon as he reaches a near city or village with a telephone line. This lack of professionalism on part of Germans resulted in Indians taking no annual vacations, working double hours a week than they are paid for and taking the pain of late modifications in design and code.

On part of Indians, the high turnover was a very big issue. Once a developer hop to a better paying job, almost entire computer code written by him or her immediately becomes useless for sometime until some other programmer “decrypt” it and in some cases even rewrite it. This may have resulted in delays and design flaws when somebody try to modify an already made design in his or her own way not thought by the original designer no longer in company.

In January 2000, the NetManager was finally demonstrated to the client. Lots of errors came up. They were traced down to two root causes. First, the German testers presenting the software to the client were not well-prepared. Second, the test-bed provided to Bangalore by Munich in 1996 had gone outdated by now and was not the same test-bed Munich now uses or was used in the demonstration to client. Both of these causes can be easily traced to the faults on part of Germans. The testers had no acceptable reason for unpreparedness. The high management responsible for updating Bangalore with test-bed was ignorant towards this duty.

We can conclude that, having worked together for well over half a decade the cultural differences between the two countries were handled well. With time Indians understood what is expected from them and Germans spent substantial time and money training its people to “decode” Indian communications. A German spent 3 years in Bangalore becoming expert in South Indian English accent and understanding of local culture and hidden meanings of phrases etc. But there is a limit to what humans can accomplish, the physical distance between Munich and Bangalore remained a reality, advent of faxes, telephone calls, emails and even video calls can never substitute face-to-face communication. Two developers working together on the same computer (as in Extreme Programming2) cannot be substituted with two developers chatting on an Instant Messenger (such as hotmail or yahoo) even if through Remote Desktop Sharing they can actually view each others’ computer screen and run actions on it. It is also learned that human conflicts in most cases can only be solved with real, face-to-face communication. In absence of hyper-fast physical transportation (such as one that reduce travel time between the two cities to less than one hour) and no visa restrictions the problems faced by ICN in development of ADMOSS and NetManager are very likely to raise its ugly head time and again.