Lucent Technologies OMC-2000

Rod Moyse 1and Annette Tassone 2

1 Lucent Technologies, GSM Systems Engineering, The Quadrant, Stonehill Green, Westlea, Swindon SN5 7DJ, UK. rmoyse@lucent.com

2 Lucent Technologies,

Advanced Development, Optimus, Windmill Business Park, Swindon, SN5 6PP, UK atassone@lucent.com

ABSTRACT

We describe our efforts to introduce user-centred disciplines as essential elements in the development of mobile telecommunications network management products.

INTRODUCTION

The organisation we wish to describe is the GSM Division of Lucent Technologies. This division has its World Headquarters at Swindon, UK, with development groups on several continents. There had previously been little HCI-related work carried out here, and the authors sought to establish Usability Engineering (UE) and Human Factors (HF) as essential parts of product development. We were based in two very different groups (Systems Engineering and Advanced Development), but our work was focused on a single product: the OMC-2000, and we will concentrate on this in our paper. Lucent Technologies as a whole is a US$26 billion global company with 128 years of experience. The company, with headquarters in Murray Hill, NJ, USA, designs, builds and delivers a wide range of public and private networks, communications systems and software, data networking systems, business telephone systems and microelectronic components. Bell Laboratories is the research and development arm ofthe company. As a whole the company employs some 150 usability engineers or similar staff.

THE OMC-2000

The OMC-2000 (Operations and Maintenance Centre) is the distributed software system which is used to operate and maintain the complex networks required for Lucent Technologies' GSM mobile telephone systems. A range of operators are concerned with Fault Management, Configuration Management, and Performance Management. The product has by definition been aimed at a narrow and highly technical sector of the mobile communications market. In this specialised market usability has not always been seen as a priority. As the market has matured and competition has intensified, the rules have changed so that usability is now seen as a major element of product quality, particularly where service providers wish to reduce costs by using less technically sophisticated personnel for routine system operation.

USABILITY MEETS ENGINEERING

For both authors the technical learning curve was daunting as we lacked the telecommunications background required for rapid assimilation. We relied on our initial usability evaluations and interviews to speed up the process. We kept on talking to the experts, casting our nets as wide as possible and synthesising the results. As in many technically-focused domains there had been pressure to view the product in terms of its individual features rather than in terms of the users and what they wished to accomplish. This gave us a product which had some major strengths in functional terms, but which also presented some significant usability challenges. As ever,

development resources were finite and hard choices had to be made between usability improvements and new product features.

The product teams had previously established the idea of using scenarios as a focus for specification and development decisions, but had again applied a largely 'engineering' view related to 'time on task' as an issue in competitive analysis, and to the testing of implemented code. Sustained persuasion was required to establish the idea of scenarios as a means of identifying usability issues, designing remedies, and then testing the result. In order to gain a clear view of the scope of what was required, we carried out an initial program which included co-operative evaluations, observational studies, a questionnaire survey, extended interviews, customer-written 'fault' descriptions, and the collation of documents from internal and external sources. The breadth of this reference proved a major strength in our subsequent campaign. The work and analysis was summarised in a report which raised the most pressing issues, giving a rationale for their selection, relevant scenarios, a statement of recommended solutions, and some prototype designs.

MAKING A DIFFERENCE

Following the initial work a sustained programme of lobbying and education was required to raise the profile of usability issues and to gain management and engineering support for the necessary solutions. Although each interest group may be striving for a better product, on any given day they may face pressures that seem more urgent and important than 'usability'. Customer site visits were a highly significant step here. If you come back to the office with clear and graphic evidence of customer requirements, it is hard to ignore. In some senses though, we were pushing at an open door. The need for a strong customer focus was well understood, and was reinforced by the overall company goals. The need for customer site visits was accepted, although these were, as usual, difficult to arrange. Scenarios were much in demand as a means to structure various forms of product testing, and work on a tool to support their wider use was welcomed. The use of new user interface technologies was mostly hampered by the technical challenges of integrating them with our complex, distributed product.

CONCLUSIONS

We are beginning to make a difference, and have established a much greater awareness of usability issues in our organisation. It has not been easy: there is no purpose in completing a report and waiting for something to happen. In order to get results you have to raise your profile and that of the problem, while gathering support for the changes that you believe to be necessary. It pays to stress the business case and to make contact with all the far-flung groups involved with the product as they may have much to offer. Any opportunities to build prototypes and showpeople what you mean should be quickly grasped as one visualisation can be worth hours of talk. Even when doing all the right things and winning support, you may still get stalled by something like an inflexible architecture. In th