Software construction or evolution?
INDEX | ORGANISATION | TIME LINE | PEOPLE | STORY | RESEARCH METHOD | COMMENTARY | FINDINGS | HELP | BOTTOM
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?
C.2.2 What affected the internal design?
C.2.3 What affected the reliability of the system?
C.2.4 What affected the schedules?
C.2.5 What affected 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.1a Prototyping methodology
|
Method
 |
 |
The prototyping methodology had some very positive effects on the development. A lot was achieved in a short period of time and the project came in under budget. Prototyping was a catalyst for change within the organisation and encouraged discussion of business issues. It also allowed people to have a say in the development and so produced a system which was more oriented to the requirements of some users. As with most prototyping projects the impact of having a working system to comment on was much appreciated although expectations of the time taken to produce an operational system had to be managed. There was greater commitment to this system than previous attempts at computerisation.
The team had difficulty setting a reasonable boundary for phase I. This was partly because the initial scope was larger than they realised and also because they had difficulty stopping the prototyping process. Given the existence of the Q&A system it is surprising that they were not more aware of the size of the scope but I think this reflected a lack of clarity over the aims of the system. Shortly after phase I went live Gordan felt that the outcome justified the ambitious nature of phase I, because the linkages between countries made the system very impressive. One of the typical prototyping problems, which all those involved reported, was that the business users did not know when to stop and continued tweaking the screens.
Despite the increased functionality, phase I did not satisfy Services because it did not include all the functionality of the Q&A system. This was either because the system was not really intended for Services or GIS did not ask the right questions. They started with a blank sheet of paper letting the data dictate the approach, rather than studying existing procedures (this was actually undertaken as part of phase III). I do not think the involvement of business people removes the responsibility from the developers to see the big picture and point out to the business people the consequences of their decisions. The fact that the users did not seriously use the prototypes probably meant that these shortcomings were not picked up early enough for enhancements to be included in phase I.
In the development of phase II there were not the same prototyping workshops and, probably as a consequence, changes were made in phase II that the users were not aware of and did not like.
A wide variety of people were invited to the prototyping workshops but attendance varied and in the initial workshops there was a greater emphasis on getting management rather than underwriting input. David's view was that technical managers should know what they wanted of the system and the underwriters' role in design was to make sure the system was usable. I think it was this decision that made both phase I and II more management tools than operational systems. Unfortunately the managers overlooked the effort of putting data in in order to get information out. However, given the lack of interest in the development shown by the underwriters, I am not sure that their participation in the workshops would have made that much difference.
There were problems with the workshops: attendees did not always read the paperwork, had not necessarily attended previous workshops and had different interests and objectives. The workshops came to conclusions because of David's leadership but the system was probably effectively designed by those working full time on the project team.
David was senior but remote from the underwriters. He was also very 'strong-willed'. Keith was not representative of underwriter interests because of his commitment to computerisation and was considered by some to be out of date. While Lucy might have been expected to push the Services perspective she had no previous experience in multinational insurance and was very much David's junior. In contrast when Jenny replaced David, her Services background meant Services started being heard.
Another consequence of David's involvement was that phase I was bigger than intended because he stressed the user benefits and pushed to get as much into phase I as possible. However his seniority, authority to take decisions, and good relationship with Gordan did mean that phase I achieved a lot in a short timescale.
C.2.1c Development team enthusiasm
|
Belief
 |
 |
The commitment and enthusiasm of the development team also contributed to the development of a much bigger system than had been planned.
One of the consequences of involving business users in design in phase I was that technical issues were considered after functionality. This was regarded as an advantage because too early consideration of technical constraints would 'stifle the imagination'. However, the technology was an important factor in the growth of the functionality of the system and was one of the reasons why it became the core system for X. The McDonalds system and the Replication capabilities of the Unix version of Sybase were good examples of how technology enabled new functionality. In contrast, the continued problems with ad hoc reporting and the difficulty of using Q+E effectively illustrate the impact technology could have on functionality.
C.2.1e Nature of business
|
Domain
 |
 |
There were some areas where functionality was difficult to define. The reinsurers would not define their location requirements. Larger clients had to be handled individually in deciding exactly the level of detail to record in the system. For McDonalds, their biggest client, they actually produced a complete subsystem based on a cut down version of Multinational to handle McDonalds' specialised information requirements.
Lucy reckoned that shortage of time and the pressure to go live was one reason why functionality for Services was cut in phase I. Although some requirements were dropped because of time constraints, I did not get the impression from anyone else that time pressures were the reason why phases I and II were not more useful to Services.
Following the normal division of work in X-Group, Multinational Underwriting Services was created in Essex separating the operational side from the underwriters at board level. Moreover the head of department for Multinational Services did not seem to be involved in their work (perhaps because it was so different from the other servicing units at Essex). Given this structural separation the emphasis on the underwriting side in phase I is easy to understand but I do not think this was an important influence.
Data quality problems were probably a contributing factor in the lack of impetus on the development of reporting capabilities because many of the reports would be useless without good quality data. The impact of data quality on development was illustrated by the success of the McDonalds system, which did not involve existing data because it was a new programme.
One of the consequences of the problems with the system was that all users wanted stability, not more automation. I do not think this was because of the recommendation of the Post Implementation Report to get benefit out of the system before further automation, I think they just wanted a working system.
Top
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.
One of the most serious consequences of the prototyping in phase I was the poor database design. The screens were designed almost as if it was a throwaway prototype without carrying through the entity model developed in the requirements study into a detailed database design. The database grew in an ad hoc way so that its structure was not relationally sound. These problems were not caused by an initial lack of design but I think arose through a lack of experience with prototyping and fourth generation development tools. An outline design was produced before starting the prototyping, which included an entity model, content of screens and a summary of processing. However during prototyping the focus was on the screen design and associated processing and the system was designed by directly coding in Powerbuilder.
There were also problems with the software design although these were less acknowledged. The system grew rather than having a modular design and did not handle validation and errors in a standard way although visually it was generally consistent. Within phase I the design was not revisited until it was too late to do anything about it and from an external perspective the system was fine if slow. The exception was reinsurance which was rewritten during phase I because there were difficulties in defining the requirements.
The quality assurance review of phase I highlighted non-adherence to standards as one of the causes of the deficiencies in this phase. However there were no indications that non-adherence to standards was the cause of the database design problems. There were differences in internal development style, particularly in phase I, but these were due to the newness of the tool making overall internal standards difficult to develop.
The newness of the tool was also one of the reasons why technical documentation in phase I was deferred (with Quality Assurance agreement). Unfortunately this seems to have resulted in a lack of emphasis on technical documentation for which the team continued to be criticised. Although resource constraints were officially blamed, I suspect it was because a design document was not found to be necessary for prototyping. When I left they had just started to re-engineer a design document for the system for use during maintenance. Unfortunately I did not observe long enough to discover how useful this would be, but up to the point of my departure the developers had not highlighted their need for such a document. One of the advantages of fourth generation tools is that they can be self-documenting but there was no evidence that the team were using such features - I was never shown documentation produced from the system.
Although the general consensus was that the prototyping methodology was the cause of the design problems, it is interesting that the Financial Accounting sub-system specification did not appear to have an entity model. This was despite Colin taking over with his more traditional approach to development, his greater emphasis on formal documentation and the data modelling problems in phase I of the Multinational system. For this reason I have classified the impact of methodology on design as important but not critical.
One of the reasons for the design problems of phase I was the 'mirage' of tools such as Powerbuilder, which can make system building seem easy. The use of an object-based design in phase II was not always possible because they were learning as they went and the technology did not directly support the approach. Adherence to design principles depended upon the influence of the lead developers and the reporting side was separately designed by other developers. They did not use an object oriented language such as C++ because of lack of expertise and PowerBuilder was easier to learn.
Pressures to meet the schedule in phase I had serious implications on the internal design of the system; when they realised there was a problem with the database design there was no time to rewrite it. These same pressures also meant there was not time to explain or enforce standards leading to some differences in internal design.
The experience and abilities of each of the development staff had a considerable impact on the design of the system. In phase I they got to grips with the new tools quickly, but I suspect their inexperience with the tools, coupled perhaps with some inexperience in design, contributed to the poor design of phase I despite the high abilities of some staff. Phase II design benefited because the staff had greater experience with the tools. In some cases, ability was more important than experience in determining success; the Unix migration was completely successful despite the inexperience of the developer but reinsurance had to be rewritten partly because the person assigned to it was 'out of his depth'.
A lot was expected of the development staff: good technically (you could trust them to find and implement a solution), good analysts (could see things from the user perspective), have a wide view, good communicators both externally and within the team, committed. The numerous minor problems with phase II also indicates that they were not 'completer/finishers'.
The comment that the programmers liked variety not just 'boring old development' is revealing. Redesigning the system would have been seen as interesting and challenging but completing all the little details would not. The programmers talked about how a flair for programming should not stop you doing other things and how they preferred working with people rather than 'grappling with code on my own'.
One of the consequences of prototyping is a non-hierarchical structure because each of the developers needs to be able to take a lot of decisions and this was reflected in Gordan's approach. The lack of internal design in phase I was a reflection of Gordan's trust in the competency of the team which given their lack of formal training was perhaps misplaced.
The rewrite in phase II showed how easy it is for the leader of IT professionals to become unaware of exactly what they are doing. At X, there were ongoing debates over how much a project leader should be involved in the detail of design. I think that the lack of an entity model in the Financial Accounting sub-system design shows how hard it is for those in senior positions to really influence technical development even if they want to.
Top
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.3a Impression of reliability
|
Belief
 |
 |
The reliability of both phases I and II depended upon who I asked and when I asked them.
The view from the development team after phase I had gone live was that it was a good system and this view was echoed by the Post Implementation Review. In contrast the users were all (underwriters and Services) very negative about phase I retrospectively. They complained about the system having errors and miscalculating data and about it hanging and crashing. Although some of these problems were due to Sybase and were also reported by the developers, they did not appear to view them as severely.
With phase II there was agreement that it suffered from a large number of problems when it went live. Many of the problems were relatively minor but the situation was aggravated by the number of bugs and because bugs re-emerged that had already been fixed in phase I.
Different groups of users reacted differently to the problems of phase II. Although the underwriters used the system less than Services and were less dependent on it in their everyday life, they tended to be much more vociferous about the errors. This reaction may have been because of the different nature of their use but presumably the Holland underwriters had a similar use and they were more relaxed about the problems.
The situation in the City was exacerbated by Jenny who saw herself as the customer despite being committed to the system. In contrast Keith was always very positive. There was also some feeling that system problems were blown up and used as an excuse by senior management in Essex. Despite the problems, the good relationship between GIS and X was largely maintained.
The developers view of phase II was that it was a technically better system and that they were nearly successful with the installation. They were frustrated that the users failed to recognise the technical quality of the system because all they could see were the errors.
Testing is always a problem with prototyping because although the system automatically gets tested as part of the prototyping process, it is also necessary to do systematic testing at both unit and system level after prototyping is complete. There are indications that phase I suffered from this problem but that the system was fairly thoroughly tested during prototyping. This testing was largely done within the team (by Keith and David) and so did not really ensure user acceptance. The operational users found it difficult to use because there was never a fully operational test system.
In phase II business users were not part of the development team in the same way so that there was virtually no testing by users. Acceptance testing was not built into the plan because of the belief that there were no really new requirements. Phase II was tested by the development team but they found it difficult to test thoroughly because it was a Windows development and as in phase I it was difficult to distinguish between unit and system testing.
One of the other main differences between the installation of phase I and phase II was that in phase II there was an operational system and the team had the added complication of working on two systems. Configuration management is often a problem in such cases but does not seem to have been particularly problematical.
With the Unix migration they had learnt their lesson and testing was exceedingly thorough; they dedicated resources to testing and included parallel running and stress testing. The migration went fairly smoothly but took a lot longer than it needed to.
Phase I was not subject to rigorous user acceptance testing despite having the manager of Multinational as part of the team. The underwriters and Services did not really exercise the system properly because management were not committed to testing, the departments were busy and short of people.
C.2.3e Quality Assurance
|
Method
 |
 |
GIS's traditional internal quality assurance function appeared to operate largely in a monitoring role, checking that projects had standards and adhered to them. Quality Assurance was such that it was possible for the project team to cut corners and there is evidence that Quality Assurance was not generally regarded as critical by GIS. The most visible aspect of Quality Assurance was retrospective post implementation reviews but these were not particularly effective in bringing about change. However the problems of phase II were not attributed to failures in Quality Assurance.
There were two major problems with Sybase on Novell that eventually led to the migration of the larger servers to Unix. The first problem occurred during phase I and eventually Sybase solved this by installing a different communications protocol but not before the team had spent two weeks installing a trap in the software to report the error rather more gracefully to the users. The second problem occurred intermittently during phase II. It could not be reproduced and appeared to go away for weeks at a time only to recur several times on one day. In the end the second problem was only solved by migrating to Unix at great expense.
These two problems illustrate the difficulties of working with a complex layer of software. There was nothing that the development team could do to resolve the errors except hope that Sybase could solve the problem. As X-Group is a large company they did have some influence with Sybase although they did wonder whether they would have had better support from a more UK-based company such as Oracle. One of the frustrations for the developers was that the users could not usually differentiate between application and system software problems.
Apart from the problem with Sybase there were few problems with the technology and the networking worked well despite international differences in ISDN implementations.
The Post Implementation Report highlighted the absence of effective project leadership as the biggest problem with phase II. Although this was undoubtedly a problem the situation was not clear cut and it provided an effective scapegoat hiding some of the other problems.
David and Gordan's number two, Scott, left the project as phase II got underway and Gordan and his senior analyst, Stuart, were involved in new developments in addition to their work on Multinational. Despite this Gordan was still managing the Multinational project. Although a strong project leader coming in at this stage might have averted the installation disaster, in practice the problems occurred earlier in the development and stemmed from a lack of control over what was being built. In addition there was a lack of recognition by the team of the problems they were facing, perhaps stemming from a feeling that they were supposed to be getting on with things, rather than Gordan being unapproachable.
Individuals in the development team played a big part in the outcome of phase II. When Stuart was appointed to lead phase II, the team was operating on a basis of trust with a non-hierarchical structure. Given Stuart's character it would have been difficult for him to change the style at this stage. He had doubts about the team's ability to make the deadline but was prevented from making a realistic plan because of his lack of technical knowledge and lack of authority in the team. He felt that given the environment it was the responsibility of the individuals concerned to realise the complexities and raise doubts themselves with Gordan.
Two of the developers in particular helped the development to emerge successfully from the fallout of phase II. Gordan managed to absorb the hassle of the bugs protecting the team without going on the defensive and won the continued support of X management. Alan, despite being a junior in the team with little formal training in computing, managed to develop an effective system for handling bugs and getting them fixed even if the users sometimes found it inefficient reporting errors through Keith.
In contrast Kevin's lack of knowledge meant that errors reported to him bypassed the system whatever their severity. However this escalation may have also been due to his seniority because the same thing happened when Tim was involved in problems.
The individual developer's understanding of the business was generally regarded as very important to the development.
C.2.3j Nature of the problem
|
Domain
 |
 |
It is interesting to compare the implementation of the Unix migration with phase II. On the face of it, the Unix migration had the potential to be as problematic as phase II and the team were making the same reassuring noises before hand. In practice the Unix migration went very smoothly and with very few problems. The developers were very careful with the Unix migration because they knew that they could not afford another disaster, however my impression was that unlike phase II it just turned out to be a much easier job.
Top
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.4a Prototyping & project management
|
Method
 |
 |
The fact that phase I delivered on time despite being significantly larger than planned was attributed to the success of the prototyping methodology. The only reason the team could claim to deliver on time was because the original deadline was a bit vague and the system was delivered in two parts at the end of May and June.
Project planning did take their inexperience with the tools and prototyping into account. However, although progress monitoring at various levels was in place, they did not use it to establish a cut-off point to changes and let the project run on for too long so it was significantly larger than planned. There was a lot of pressure to deliver something before David left the department and to achieve this they worked long hours and phase I was installed although they knew that it needed improving technically.
Immediately following the installation of phase I there was a loss of momentum partly because X could not decide on priorities, but the developers needed a breathing space because they had been working at an unsustainable level to meet the phase I deadline.
Phase II began without detailed plans although there was an overall plan. Although the Post Implementation Review said this plan did not include 'sufficient contingency for the novelty of the tools and the team's lack of experience', I think it is more likely that it suffered from second system syndrome in that they thought they knew what they were doing. For example they under-estimated the difficulty of converting from phase I to phase II. It also sounds as though progress monitoring was less rigorous than in phase I and was based largely on trust, and, during phase II, some of the team were still working on enhancements to phase I which were made live during phase II. Phase II was launched before it was ready mainly because there was pressure to deliver on time and the delivery date had already been put back, but also the developers genuinely thought that it was alright, perhaps another example of second system syndrome.
Phase I was fortunate in that David had already experienced a drifting computerisation project and so knew the importance of keeping a tight control on progress.
One of the reasons for the loss of momentum between phase I and phase II was that Tim lost his vision of what they were trying to achieve and so could not decide priorities.
C.2.4d Availability of key resources
|
Resources
 |
 |
Throughout the development the availability of key resources (most often staff) impacted on the schedules. One of the reasons phase I was installed in two parts was because of the departure of a key analyst. The phase II installation went ahead as planned partly because Gordan was in America at the time and so could sort out any problems there and also because delaying the installation would have added at least a month to the delivery date because of Easter.
In June 1994, following phase II, the X Directors decided they needed to appoint a new project manager, but it was not until later in the year that Jane and Colin could be appointed to the development side and the new year before Neville was appointed to provide clout and focus on the business side. These delays in appointment caused the project to drift through lack of leadership.
Financial considerations also affected decisions: the reengineering for phase II was accepted because phase I came in under budget but when there were all the problems with phase II, X threated not to agree future budgets.
Gordan was distracted from leadership of the Multinational project in phase II because he was assigned the Marine investigation by senior management when Marine became part of X and business priorities changed. There was no logical reason why Marine should have been given to Gordan and David cautioned against it. Maybe this decision reflected a perception amongst senior management that Multinational was more or less finished and Gordan had built what was regarded as a successful project for X already, or it might just have reflected the risk taking attitude of senior management. Whatever the reason it looked as though they were set to repeat the mistake with Gordan's involvement with the City project during the period immediately following phase II.
Throughout the Multinational project, the team consistently under-estimated the size of the problem. In part this was because they wanted to be responsive to the users. In phase I they under-estimated the amount of work involved in installing the software because this also included installing seven local area networks in the UK, Holland and USA. With phase II they under-estimated the task because it included little new functionality. They may also have over-estimated the ease of using the tools. This was certainly one of the problems with the installation of Q+E for ad hoc reporting. In the case of the Financial Accounting sub-system I think the main reason was that they under-estimated the complexity of the task. This was aggravated by the aims of the system changing as X began to take greater control of its IT.
The impact of technology on the development schedules was mixed. Although the use of many different IT systems by the organisations which supported X undoubtedly made phase I more difficult to develop, these difficulties appear to have been managed within the schedule. Likewise the technical problems with Powerbuilder appear to have been contained and there was a general agreement that the speed of development was a result of using Powerbuilder. However, delays in the implementation of both Q+E and the Financial Accounting sub-system were partially due to difficulties of providing desired functionality using package software.
Communication deficiencies within the organisation do not seem to have generally affected schedules. Two problems were reported in the Unix migration: the start was delayed because Gordan did not realise he had authority to proceed and implementation was delayed because the right comms card had not been ordered.
C.2.4i Organisational change
|
Change
 |
 |
Although organisational change can impact on schedules, the only incident I recorded was the physical changes in structure in London in April 1993 which impacted on the networking which had already been installed.
Top
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.
C.2.5a Ability & experience of individuals
|
Individual
 |
 |
Ability, and to a lesser extent experience, were very important factors in determining who did what. In building the team, Gordan seemed to look for a blend of expertise covering technical and business aspects rather than considering personal team-working qualities. He also took into account an individual's commitment to the job.
Keith's situation illustrates how the value put on abilities depended upon who was judging them. During phases I and II Keith was an important and influential member of the team but with Jane's arrival he was sidelined and his attention to detail was not valued. The situation was reversed somewhat with Colin's involvement.
Kevin's appointment shows how important experience could be. His lack of IT experience meant he could not take effective responsibility for some complex managerial decisisons and distracted Gordan's attention away from phase II.
C.2.5b Personality & attitude of individuals
|
Individual
 |
 |
Team issues rarely came up in conversations about the development although individuals were often discussed. There was friction within the team during phase II but this was hardly mentioned. There was no evidence that this friction had any particular impact on the problems of phase II. There were problems between George and Terry which were scarcely directly mentioned although I think this was the main reason for the reduction in effectiveness of the IT Steering Committee during phase II.
They talked about project managers needing to be able to mould and motivate a team and have the project management skills of thinking across the project, planning, monitoring and communicating. However in recruiting there seemed to be an emphasis on toughness, which perhaps caused them to ignore other qualities. For example, Jane's technical background had a huge influence on the adoption of structured methods but I am not sure this is what they recruited her for. A key issue in Jane's recruitment was her 'toughness' but there is some indication that this meant she was better at communicating upwards than downwards or sideways. Similarly Neville seems to have been respected for his somewhat bullish attitude to management and this emphasis may have stemmed from Tim's personality.
Generally seniority was not an important issue in the appointment of individuals. Only Jane seemed to be influenced by people's seniority.
C.2.5d Prototyping methodology
|
Method
 |
 |
One of the positive spinoffs of the prototyping methodology was that fairly junior staff on both the user and development side had exposure to senior management; important both for recognition and career enhancement.
C.2.5e Post Implementation Reviews
|
Method
 |
 |
The Quality Assurance review did highlight the lack of leadership on the Multinational team in the Autumn of 1993 but this was not addressed until highlighted again in the Post Implementation Review almost a year later. Possibly one reason for this was that the QA person was not respected by Gordan because he was 'steeped in traditional development methods'.
The recommendations of the phase II review were heeded. It was used by X to bring the resourcing problems to the attention of the Directors who eventually addressed the report's recommendations with the appointment of Jane and Colin in project manager roles, the promotion of Gordan giving him budget authority, the establishment of a steering committee and the secondment of Neville. The report also contributed to the relocation of part of the development team in the City.
Towards the end of phase II, the complexity and size of the Multinational project increased as its role in X became more important. The recommendation to appoint a project manager was a recognition that Multinational had become a difficult project to manage. The size and importance of the project to X continued to grow, leading to greater emphasis on its management.
GIS intended that Manny should replace Scott in phase II but GIS could not release him from his previous job until January. By the time he arrived Marine was underway and Gordan decided that Manny was needed for that project. Gordan did not really push the issue hard because the structure made it difficult and he thought they could 'get away with it'. This resourcing problem was picked up as being one of the key findings of the Post Implementation report although the report itself says that 'the scale of the difficulties should not be overstated'. I feel that this was an easy target for blame and diverted attention from their problems of data entry.
The problems of Gordan serving two masters and the impact this had on resourcing were eventually resolved by Gordan being promoted and given the IT budget. The effect of this was noticeable by February 1995 with lots of contractors and consultancy being used in the project.
The project was affected by difficulties in recruitment and retention of appropriate IT staff. When Kevin left they realised that having a business manager with little IT experience as an IT manager had not been successful but could not recruit an appropriate replacement so they split his job. To recruit Jane they had to use a management consultancy agency and candidates were widely different. The person they recruited was very expensive (10% of the total annual spend). Even recruiting junior staff was not easy because it could take up to a year to train up a new member of staff and GIS recognised that staff needed to be moved fairly regularly to retain them. Having listed the problems, I do not feel that the project was actually greatly influenced by the difficulties of recruitment.
Top
INDEX | ORGANISATION | TIME LINE | PEOPLE | STORY | RESEARCH METHOD | COMMENTARY | FINDINGS | HELP | TOP
© Clare Tagg 2000