Commentary

INDEX | ORGANISATION | TIME LINE | PEOPLE | STORY | RESEARCH METHOD | COMMENTARY | FINDINGS | HELP | BOTTOM
The commentary unpacks the reasons why the system was conceived, constructed and delivered. There were many interlocking reasons why events unfolded as they did but the commentary concentrates on those events that were critical, important or potentially important. Each event is categorised by the key underlying influence. The impact of these key influences on software development at X is discussed in the findings.

    C.1 Software conception or inception?
    C.2 Software construction or evolution?
    C.3 Software delivery or use?


C.1 Software conception or inception?

This section considers the decision to build an internationally distributed database system for the Multinational aspects of X's business. It asks the question: were the foundations for this software development based upon rational decisions reflected in the IT Strategy and Requirements Study or were there other influences?

So, why did X-Group decide to build a system for the Multinational Operations element of the business? What was the scope of the system and how was this established? In particular was the system designed to meet the operational needs of Services and underwriters or management information needs? Why did they decide to adopt a client-server architecture based on PCs and an internationally distributed database? Why did they decide to adopt a prototyping approach for phase I but a structured approach in phase III? Why did they choose to implement initially in the UK, Holland and the States and how was the division of work into phases arrived at?

C.1.1 Why build a system for Multinational?
The formation of X as a separate company and the arrival of Tim as MD provided the impetus needed for X to develop its own system and the IT Strategy really just reinforced this decision. Market considerations and the inadequacies of existing information systems indicated the need for a new system for Multinational even if this was difficult to justify in cost benefit terms. However the nature of the business, with special requirements for each large client, and the attitude of senior management explains why there had been no previous successful large scale computerisation of this area of X-Group's business.

C.1.2 What affected the choice of system boundary?
The original focus for the system as presented in the IT Strategy was for management information for Multinational but the Requirements study extended the system boundary to include much of the functionality of the existing operational system, Q&A. Unfortunately the operational needs of Services were not considered, perhaps because this group had only just been set up. It was not until the system had been in use for over a year that this deficiency was addressed. The scale of the system varied according to who was driving the vision. Under George's influence, the Multinational system became key to the success of X despite the serious problems with the use of the system highlighted in the Post Implementation Review.

C.1.3 What affected the choice of systems architecture?
With the benefit of hindsight, a client-server architecture seems entirely appropriate but at the time (1991-92) this technology was not so prevalent. One of the driving forces seems to have been the choice between the PC and the mainframe. The mainframe solution represented a loss of control by X to XUK, while the PC meant a quick system, owned by the business and developed by GIS. However technically inappropriate the PC solution, it would have been attractive to X, particularly to Tim who was trying to establish X as a new business independent from XUK.

The key decision to use a PC rather than Unix-based server for phases I and II was influenced by the increasing power of PCs, the team's familiarity with PCs and the relative costs, as use of a PC server allowed phase I to go in under budget.

The nature of X, operating in a global market out of many locations, favoured a distributed database solution. The change implicit in a new company was one of the reasons for choosing an open systems architecture.

C.1.4 What affected the choice of process model?
GIS had little experience of using rapid development approaches and was naturally risk-averse but despite this the Requirements study established the evolutionary prototyping approach that was used in phase I. The success of the Requirements study using a small committed team and the personal relationship between Gordan and David contributed to this decision. The Requirements study was also responsible for the ambitious decision to install in three countries in phase I based on business demands not feasibility.

Full evolutionary prototyping was not proposed for the Financial Accounting sub-system because of its complexity but the appointment of Colin as project leader led to a very traditional approach to development. The appointment of a methods expert as Multinational project manager and the organisational reaction from the technical problems of phase II, resulted in them adopting a more traditional approach to the whole of phase III.

Top


C.2 Software construction or evolution?

This section focuses on how the three phases of the Multinational system were built. It looks at what was actually built, how it was constructed and the development process and asks: was this a managed process based upon rational decisions or did the process evolve shaped as much by social factors as technical requirements?

So, what factors influenced the content and success of each phase? What affected the design and reliability of each phase? What influenced the process and management of each phase including the transition between phases? What influenced the composition of the development group?

C.2.1 What affected the functionality that was delivered?
In phases I and II the system was primarily a management information system and did not satisfy the requirements of operational users (either services or underwriting). The key reason for this emphasis was the prototyping approach and the people involved. In phase I the system designed was much bigger than intended primarily because of the lack of experience of prototyping and the enthusiasm of the individuals involved. The functionality delivered was influenced by the technology both in adding functionality and limiting what could be implemented. There were some detailed requirements that were difficult to define because of the nature of the problem domain.

There were largely unfounded suggestions that the missing functionality required by Services was not provided because of time pressures or because Services was structurally remote. However, data quality problems probably did limit the reporting capabilities provided early in the system and after phase II the instability of the system made the users wary of adding functionality.

C.2.2 What affected the internal design?
In phase I the use of prototyping led to a focus on external design so internal design was neglected. However, it is not clear that the more traditional approach adopted by phase III would necesssarily change the focus. One problem was that the technology they used made development easy and did not provide support for good internal design. Time limitations meant that the design flaws in phase I could not be corrected until phase II. A shortage of time was also blamed for the absence of full technical documentation but prototyping was probably a contributing factor.

The quality of design throughout the Multinational system was greatly influenced by the ability of the individual developers although experience was also important. The abilities required of development staff were many and did not always coincide with what they liked doing. Leaders of the developers should probably have been more aware of the design but experience of phase III shows that this was not easy.

C.2.3 What affected the reliability of the system?
The reliabilty of the Multinational system depended upon who you asked and when. The development team were very positive about phase I but retrospectively users were very critical. Phase II was regarded by everyone as unreliable but some users were far more critical than others and the development team felt that its good points were not recognised.

In phases I and II there was a lack of time and commitment to testing on the part of both users and developers. This was more significant in phase II because prototyping meant the system was exercised during development in phase I. By the time of the Unix conversion, they had all learnt from the experience of phase II of the importance of testing. The quality assurance function within GIS does not appear to have contributed either positively or negatively to the reliability of the system.

There were major problems with Sybase in both phases I and II which had a significant impact on reliability and which were largely out of the developers' control.

The Post Implementation Report highlighted the absence of effective project leadership as the biggest problem with phase II. Although Gordan's time was stretched and the team leader he appointed had difficulties establishing his authority over the team, the situation was not clear cut and this provided an effective scapegoat hiding some of the other problems. However, individual developers were critical in either alleviating or aggravating the problems of phase II. The complexity of the problem was important.

C.2.4 What affected the schedules?
There were scheduling problems caused by the lack of experience and difficulty of managing a prototyping project, but prototyping also enabled them to deliver a much larger system more or less on time. The first phase of Multinational came in on schedule mainly because the senior business user had experience of a previous project drifting. However the tight schedule of phase I did put a lot of pressure on staff leading to a loss of momentum between phases I and II. The loss of momentum was also fuelled by a loss of vision for the development.

The availability of staff impacted the schedules throughout the development particularly the time taken to recruit new project leaders and the involvement of the project manager in other projects.

The team consistently under-estimated the size of the problem and although this was partly because of a lack of familiarity with the technology, it was also because they under-estimated the complexity of the task. The different software systems used sometimes helped them meet tight deadlines and sometimes proved to be more difficult to use than anticipated. The schedules were also affected, but to a lesser extent, by organisational change and breakdowns in human communications.

C.2.5 What affected the composition of the development group?
The most important characteristic affecting team composition was ability and to a lesser extent technical experience. Although the people I was interviewing knew of my research interests, team issues were rarely raised. Although capabilities to manage a team were discussed, they seemed to be less important in practice than being tough enough. Seniority rarely seemed to be an issue in team working and so the prototyping methodology helped the careers of people on the team by giving them direct exposure to senior management.

The staffing recommendations of the Post Implementation Review following phase I were not heeded. By the end of phase II, the organisational importance of the system had grown and the resourcing recommendations of the Post Implementation Review were addressed. There were resourcing problems with phases I and II but I think these stemmed from organisational rather than recruitment difficulties.

Top


C.3 Software delivery or use?

This section investigates why there were so many problems getting many of the users to effectively use the system. Were these problems because of the way the system was installed or were there other causes? Throughout the study data quality within the system was poor. Why was this?

C.3.1 What affected the use of the system?
The attitudes of underwriters to using computers were widely regarded as one of the key reasons why the system was not used. In the UK, it did not seem to be an attitude to computers that was the problem but some underwriters did not see servicing as their business.

There was no lack of organisational commitment to the Multinational system but some senior individuals were not committed despite the use of prototyping. It is also true that system problems, of phase II particularly, caused people to lose faith in the system. However, the underlying reason for people not using the system was that it was not useful to them. In the case of the underwriters, the benefits were small and their lack of use meant that data quality was poor and this reduced the system's usefulness to other users.

Usage was also affected by the bad timing of the installation of phase I, insufficient consideration given to the resourcing of data loading and people's normal resistance to change. Training would have helped alleviate these problems but was very limited in phases I and II because there was a belief that prototyping reduced the need for training or a system manual. However, use of the system was encouraged by internal communications, which were generally adequate or good.

C.3.2 Why was the quality of the data poor?
The responsibility for data quality seems to have resided with the users rather than the development team and in consequence the problems were not really highlighted by the Post Implementation Reviews. Moreover, some of the senior management of X seemed to have a relaxed attitude to data quality and this affected the underwriters' attitude.

There were difficulties in loading the data because of the way in which X had developed from a number of distinct groups working with different procedures and classification systems. More particularly some key information was only stored in underwriters' heads. Some of the difficulties in defining the data were inherent to the business of multinational insurance.

The data converted from the old Q&A system was already of poor quality and was out of date. In addition data problems were introduced at conversion by a lack of understanding of the insurance business by development staff. This coupled with the decision to check the data at renewal meant that poor data quality in the UK persisted for over a year. Initially it was not possible for the users to correct some of the fields but when the validation rules were relaxed there was a further impact on data quality.

Top


INDEX | ORGANISATION | TIME LINE | PEOPLE | STORY | RESEARCH METHOD | COMMENTARY | FINDINGS | HELP | TOP

© Clare Tagg 2000