C.3.1 What affected the use of the system?
C.3.2 Why was the quality of the data poor?
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.
![]() |
![]() ![]() |
![]() |
In the UK there is evidence that at least some underwriters were perfectly prepared to use computers. It was underwriters that wrote the systems used prior to the Multinational system and the underwriters adopted other aspects of Windows, such as email, introduced at the same time. Even Donald (who was regarded as one of the less enthusiastic underwriters concerning computerisation) said 'It is vogue to just moan about the computer and all the rest of it, but it's the easy thing to do, but most underwriters, I'd say, when it comes down to it will say that you've got to have one ...'. There was also a view that the various attempts at computerisation had left a poor image of IT in X but there is little evidence amongst the underwriters in the UK of this.
A more significant factor was the attitude of some underwriters to servicing the cases. Some of the underwriters in the UK believed in controlling their cases while others believed that getting the business was more important. This attitude may have been exacerbated by the decision to create Multinational Services; there was certainly a bit of a 'them and us' relationship between underwriters and Services. However, I think that the difference in attitude to the system exhibited by underwriters and Services was mostly due to the difference in the focus of their jobs.
![]() |
![]() ![]() |
![]() |
There was a view that one of the problems of phase II was that David was replaced by Jenny who was junior and less experienced. I am not convinced this was significant, both Jenny and Lucy from Services seemed to demonstrate commitment and enthusiasm for getting the system working.
![]() |
![]() ![]() |
![]() |
![]() |
![]() ![]() |
![]() |
The launch of phase II was particularly catastrophic. It raised unrealistic expectations, reduced motivation and gave the underwriters a reason to be critical. Attitude to the system was contagious - underwriters saw others having problems and so were not minded to put using the system high on their list of priorities. In contrast, Services and Holland, who were more committed to using the system, were much more sanguine about the errors.
One of the advantages of the Post Implementation Review was that it seemed to focus the venom and vitriol but it also seemed to reawaken discontent so that even when most of the bugs had been fixed the users were still fed up with the system and management re-considered its long-term status.
![]() |
![]() ![]() |
![]() |
The system was not useful as an information resource because much of the data they wanted to access was still held in manual files or was easier to access manually. In particular historical data about claims was not loaded. It was regarded as unlikely that the system would ever replace paper records. Very few reports were written for underwriters in phase I or II of the system and the absence of ad hoc reporting meant they could not write their own reports as they had with Q&A. Cases were easier to renew once they had been correctly entered into the system. However, loading the data was not easy because it was time-consuming to enter single bits of information about a programme. In phase I this was exacerbated by the speed of the system but phase II was still regarded as too slow by users.
The system was also limited in its usefulness to Services. The first installation of phase I was of no use to Services because it only contained quotes and clients. When the full version of phase I was installed it was not as useful as Q&A and this situation continued in phase II and had only begun to be addressed in phase III. The slowness of the system also impacted on Services because of the large number of screens that they had to use to process a single programme.
The problem with phase I and II was that they were designed from a management perspective but were not used because the data was incomplete. Underwriters were supposed to be entering some of the data but the system offered them little benefit. Services did use the system but found it less useful than Q&A.
![]() |
![]() ![]() |
![]() |
One of the reasons why the Claims aspects of the system were not used was because downloads could not match policy numbers because of the poor quality of the data in the Multinational system.
![]() |
![]() ![]() |
![]() |
Installation in Services was complicated by the need to convert the data from the Q&A system. Services, who were already short staffed and with a backlog, spent time getting the data up to date in the Q&A system and then had a period of two weeks in mid June when they could not use any system.
![]() |
![]() ![]() |
![]() |
![]() |
![]() ![]() |
![]() |
![]() |
![]() ![]() |
![]() |
![]() |
![]() ![]() |
![]() |
There was no user manual produced for phase I because there was a belief, attributed to Tim, that none was required because of the development approach. Unfortunately there were also some problems with the online help system in phase I and America particularly missed the manual. The role of a user manual was recognised by the team but it can not have been regarded as very important as it took over six months to produce and I was never shown a copy.
![]() |
![]() ![]() |
![]() |
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.
![]() |
![]() ![]() |
![]() |
Despite commitment to computerisation, senior management did not emphasize the importance of accurate data in the Q&A system perhaps because they did not have the same view of accuracy ('we don't deal in precise numbers, it's millions of pounds'). The loss of management commitment to the Multinational system when David left as phase I went live was regarded as one of the reasons the data quality was poor (although Jenny was temperamentally much better suited to getting the data right than David because of her Services background).
The problems of data quality were not really highlighted in the Post Implementation Review because it focussed on the development of the system. Even in early 1995 there was still confusion between the data quality problems and actually getting people to use the system. This perpective is reflected in the different ways the Post Implementation Review and Audit reports were handled. The Review was widely publicised but the Data Audit was kept under much tighter wraps.
In reporting the problems of data quality Colin attributed this to leadership problems but did not clearly identify who should have responsibility for it. The data audit was managed by the users so it would appear that they had responsibility for data quality at this stage. However, although the data audit found 'a lack of accuracy and attention to detail' and 'Mr Tim hit the desk over and over again', it took three months for X management to address the underwriters about the findings of the data audit by which time the impetus was lost. It also took three months between Neville being given responsibility for sorting the data out and it being announced.
Throughout the development the team seems to have regarded data quality as the users' responsibility although they scheduled time to assist the users. As I stopped observing, the X Director responsible for IT, gave the responsibility for data quality to the development team. Whether in other projects the team would assume this responsibility is questionable but from their experience with X, they would certainly treat data quality problems much more seriously from the start.
While setting deadlines seemed to motivate the developers to delivering on time, deadlines set for underwriters to get their data input correctly do not seem to have the same effect. Was this because there was more of a project mentality amongst developers? I am not sure even the threat of unemployment will ensure Neville succeeds; in phase I giving Tim the ability to look at any underwriter's business may have 'frightened the life' out of the underwriters, but it did not provide any impetus to them getting their cases in and up to date.
![]() |
![]() ![]() |
![]() |
![]() |
![]() ![]() |
![]() |
The original plan was that the underwriters would input the full details of new cases because this would help them understand the system, they knew all the details of the case and it would give them ownership of data on the system. Unfortunately many of the underwriters in the UK and most of the underwriters in the US did not respond. There was a move to underwriters only entering programme level information for new cases. However, the files were kept in London and the new Services staff in Essex had little experience of the complexity of Multinational cases so this had not proved successful by the time I stopped observing.
The formation of X and its widespread nature meant that before the Multinational system was implemented there were not agreed common procedures. In addition, the decision to continue to take IT services (and other business services) from local X-Group operations meant that the MIS must take feeds from a great variety of uncontrolled sources who were 'organisationally and culturally distinct'. Tim and David saw the introduction of the new system as an opportunity to establish common procedures in X particularly for accounting. The difficulties of establishing common procedures were illustrated by the underwriter files; although they talked about standard forms for underwriter files in London in March 1994, these did not become established until August 1994 and one of the problems faced by the data audit team was the proliferation and variation of underwriters' paper files.
It was also recognised that world-wide aggregation of X data would require a common classification system to be established as part of the new system, but when data was loaded different interpretations were put on fields so they were used inconsistently. Field interpretation also depended upon business policy and so could change if policy changed.
![]() |
![]() ![]() |
![]() |
![]() |
![]() ![]() |
![]() |
There was a view from developers and users that the data should not have been automatically converted from the Q&A system; at the very least they should have trialled the conversion to have identified the problems earlier. In phase II the data was converted again and further errors were introduced; some of these were caused by the poor structure of the phase I database.
![]() |
![]() ![]() |
![]() |
![]() |
![]() ![]() |
![]() |
It was definitely a bad decision to convert the data from Q&A with all its faults only to find that potentially it was not going to be checked for up to a year. Although the users still thought this approach was appropriate when viewed retrospectively, I feel that it would have been better to time the installation so that users would have been able to load the data immediately. This would have made it harder for data quality issues to persist. Holland took this approach (it was easier because they were smaller) and although their data still suffered some quality problems they seem to have used the system much more effectively.
![]() |
![]() ![]() |
![]() |
© Clare Tagg 2000