BSC Is Project

BSc_IS_Project By S.
Samina Student ID XXXXXX
UNIVERSITY OF Faculty of
BACHELOR OF SCIENCE IN COMPUTING MODULE ID - XXXXXX Project Report
TITLE OF PROJECT
Investigating the effects of organizational culture on IS project implementation and how this can be controlled by change management: A case of Waterfront UK Limited
Author's initials and surname S. Samina Students Registration Number XXXXXX Month and year of submission
FEBRUARY 2008
Page 1 of 66
BSc_IS_Project By S. Samina Student ID XXXXXX
Abstract
This project focuses on the effect of organizational culture on three aspects of Information systems project implementation (planning, stakeholder management and training). The implementation of an IS/IT strategy will result in lots of changes and issues occurring in an organisation that need careful consideration and management. Amongst one of these issues is an organizations culture. A roadblock to successful implementation of information systems / IT projects is the vulnerability of such initiatives to powerful, yet poorly understood, cultural influences [1]. If already-existing cultural patterns are inconsistent with new values and cultural implication of the impending change initiatives, then defensiveness, withdrawal, and distortion of important information may result [2]. These effects can powerfully inhibit an organizations ability to implement successful, durable IS / IT change. In this project, prior research would be utilized in the definition of culture and a way of understanding how culture is created and maintained is examined, this includes patterns of organizational metaphors, beliefs, thought, action and structures driven by corporate values. The secondary research will look at how models of change management can help integrate, incorporate and maintain an organizations culture after a major IS / IT reengineering, and recommend using a change control system to do this. Qualitative primary research will be gathered from a case study organisation by the use of interviews. These will look at the case study employees opinions and features of their change control practices. This evidence can then be compared to the existing research, to try to satisfy the projects aim and objectives.
Page 2 of 66
Acknowledgements
There are many people who have helped make this project possible. I would first of all want to thank God for his grace and guidance. My sincere thanks also go to my supervisor XXXXX, for her enormous support and interest in the project. I would also like to acknowledge the contributions of XXXXX and XXXXX who provided me with much advice. This project would not have been possible without the help of the members of staff and top management of both Waterfront Consultants UK Limited for their answers to all my enquiries, their willingness and co-operation in supplying me with the secondary research data and reports used in this project. For their ongoing support and excellent proof reading skills, I would like to thank my parents, XXXXX and XXXXX for their kind support and I am grateful to all my family and friends for their support and understanding throughout my preparation of this report.
Page 3 of 66
Table of Contents
Chapter 1.......................................................................................................7 1. Introduction.............................................................................................7 1.1 Problem Definition & Goals.....................................................................7 1.2 Aim.......................................................................................................8 1.3 Objectives..............................................................................................8 1.4 Discussion of changes to the Aims and Objectives....................................8 1.5 Indication of the following chapters and Structure....................................9 Chapter 2......................................................................................................10 Research Methodology...................................................................................10 2. Introduction...........................................................................................10 2.1 Secondary Research.............................................................................10 2.2 Primary Research.................................................................................10 2.3.1 Ethics and considerations when conducting primary research............11 2.3.2 Quantitative or Qualitative research methods...................................11 2.3.3 Sample for Primary Research..........................................................12 2.4 Limitations and Critical Analysis.............................................................13 2.5 Conclusion...........................................................................................13 Chapter 3......................................................................................................15 Literature Review..........................................................................................15 3.1 Introduction.........................................................................................15 3.2 Culture................................................................................................15 3.2.1 Critical Analysis..............................................................................16 3.3 Organizational Culture..........................................................................17 3.3.1 Stages in Development of Organizational Culture.............................17 3.3.1.1 Birth Stage..............................................................................17 3.3.1.2 Mid-life Stage...........................................................................18 3.3.1.3 Maturity Stage.........................................................................18 3.3.2 Shared Knowledge among Workforce..............................................18 3.3.3 Transmission Agents .....................................................................18 3.3.4 The learning Process......................................................................19 3.4 Main Cultural and Structural Problems in IS Projects...............................19 3.5.1 Symbols.........................................................................................20 3.5.1.1 Influence on IS Project: Daimler-Chrysler .................................20 3.5.2 Power Structures............................................................................21 3.5.2.1 Influence on IS Project: National Probation Service: NPSISS (CRAMS).............................................................................................21 3.5.3 Organizational Structures................................................................21 3.5.3.1 Influence on IS Project: Failure of Project Everest Ford Motor Company ...........................................................................................21 3.5.4 Control Systems.............................................................................22
Page 4 of 66
3.5.4.1 Influence on IS Project: Daimler-Chrysler .................................22 3.5.5 Rituals and Routines.......................................................................22 3.5.5.1 Influence on IS Project: Failure of Project Everest Ford Motor Company ..........................................................................................22 3.5.6 Stories...........................................................................................23 .........................................................................................................23 3.5.6.1 Influence on IS Project: Daimler-Chrysler..................................23 3.6 Change Process Models........................................................................23 3.6.1 Lewins Change Model....................................................................23 3.6.1.1 Unfreezing...............................................................................24 3.6.1.2 Moving....................................................................................24 3.6.1.3 Refreezing...............................................................................25 3.7 IS Project Implementation activities Utilized...........................................26 3.7.1 Implementation Planning................................................................26 3.7.1.1 Implementation Strategies........................................................26 ................................................................................................................27 3.7.1.2 Systems Development..............................................................27 3.7.1.2i. Life Cycle Models....................................................................27 i. Systems Development Lifecycle (SDLC)..............................................27 ii. Adaptive Software Development ......................................................29 iii. Problems Ascertaining Customer Requirements and Constraints.........30 iv. Implementation Strategy / Product Releases....................................31 3.7.2 Training.........................................................................................31 3.7.3 Stakeholder Management / Project Sponsors...................................32 3.8 Justification for Project Topic................................................................32 3.9 Conclusion...........................................................................................33 Chapter 4......................................................................................................34 Case Study Findings......................................................................................34 4. Introduction...........................................................................................34 4.1 Company Background and Problem Situation.........................................34 4.2 Strategic Outlook..................................................................................35 4.3 IS Implementation: Cross Functional Business Programme......................36 4.3.1 Systems Objectives........................................................................36 4.3.2 Implementation Planning................................................................37 IS Implementation: Cultural Issues & Changing Requirements ..............39 IS Implementation: Cultural issues & Scope Escalation..........................39 4.3.3 Implementation Strategy................................................................39 4.3.4 Stakeholder Management...............................................................40 4.3.5 Training.........................................................................................41 4.4 Application of Change Management Models............................................42 4.4.1 Levels of Culture: Values ...............................................................42 4.4.3 Lewins Change Model....................................................................43 4.4.3.2 Moving....................................................................................43
Page 5 of 66
4.4.3.3 Refreezing...............................................................................44 4.5 Conclusion...........................................................................................45 Chapter 5......................................................................................................46 Discussion of Findings....................................................................................46 5. Summary of Research Results.................................................................46 5.1 Secondary Research: Objectives............................................................46 5.1.1 Concept of Culture and Organizational Culture.................................46 5.1.2 Various cultural and organizational problems expected during IS project implementation...........................................................................46 5.1.3 Change Process Models & IS Implementation Activities.....................47 5.1.4 Overall Comments on Secondary Research......................................47 5.2 Primary Research.................................................................................47 5.2.1 Implementation Planning................................................................47 5.2.2 Implementation Strategy................................................................48 5.2.3 Stakeholder Management / Project Sponsorship...............................48 5.2.4 Training.........................................................................................49 Chapter 6......................................................................................................50 Conclusion....................................................................................................50 6.4 What Has Been Learned.......................................................................51 6.5 Conclusion...........................................................................................52 6.6 Future Work.........................................................................................52 Bibliography..................................................................................................53 Appendix A...................................................................................................58 Test Results: Waterfront Consultants..............................................................58 Appendix B...................................................................................................59 Screen Shots For Error Reports: Waterfront Consultants..................................59 Screen Shot: Manual Testing Error Report...................................................59 Screen Shot: Automated Testing Error Report..............................................62 Appendix C Project Progress Reports 1-3........................................................64
Page 6 of 66
Chapter 1
1. Introduction
1.1 Problem Definition & Goals IT plays a significant role in the overall re-engineering of the firm. Due to the fast pace of changing technology in todays world, many organisations find themselves at a stage where they may have to introduce, update and sometimes replace their existing IT / IS (information technology / information systems), to maintain their status and continue to be effective in todays competitive business environment [4]. Due to this, companies will find themselves at a stage where they have to manage an IT project to successfully implement a new system, or make changes to an existing system. Therefore, you would expect large companies to manage their IT projects and implement their IT systems effectively. However, there is the threat and vulnerability of such projects / change programs to powerful yet poorly understood cultural forces. If we acknowledge the potential causal role of culture in the success or failure of organization change, then it makes sense to investigate the strategies for examining and redesigning cultural systems as an integrated aspect of change management, this is what I intend to achieve in carrying out this project. The theories of change management will be applied to a case study of Waterfront UK Cross Functional Business Programme (CFBP) project, during my investigation, I realised how a good change control system contributed to the success of an IT project implementation. Different aspects of change as adopted by the company were analysed, these ranged from changes in the roles of individuals through to changes in the structure of the company. The change affected all aspects of the operations and functioning of the organisation. A series of critical success factors first had to be taken into account, these include; management buy-in and ownership, action to attract and keep the right staff to achieve change, employee ownership of change, effective organizational structures. Lewin /Schein change process model will be employed to encapsulate the IS project implementation phenomena. While some of the issues represented in this study have been addressed individually in previous studies, they have not been adequately viewed in the context of IS project implementation in a manufacturing setting.
Page 7 of 66
1.2 Aim To study the area of organizational culture and IS / IT project implementation, to assess how the culture of a firm influences IS / IT project implementation. It will then use a case study to help understand how change control can be used to manage the transition process, and therefore reduce the risk of an organizations ability to implement successful, durable IS / IT change. 1.3 Objectives 1. To discuss the concept of culture and organizational culture 2. Investigate the various cultural and organizational problems expected during IS project implementation 3. Outline and discuss the change process models utilized during IS projects and reengineering 4. Outline and discuss the three IS implementation activities affected by organizational culture utilized in this project 5. Analyze the implementation of Waterfront UK Cross Functional Business Programme (CFBP) and how successful was the planned change initiative 6. Outline any improvements for the future in the context of change management models utilized, approaches and IS project implementation 1.4 Discussion of changes to the Aims and Objectives The aims and objectives have been structured to allow the reader to gain an understanding of the topic of organizational culture and IS project implementation, and then focus on investigating how organizational culture affects IS project implementation. Upon the understanding of an organizations culture and ways in which it can be maintained, the final objective is to consider change control as a method for controlling the transition process, to reduce the risk of an organizations ability to implement successful, durable IS / IT change. The topic, aims and objectives has changed hugely from the original project proposal. This was as a result of a feedback received from my tutor who advised that the initial topic was too vague and wide and the need to investigate only one factor (organizations culture) rather than all the issues affecting IS project implementation.
Page 8 of 66
1.5 Indication of the following chapters and Structure Chapter Two outlines the research methodology used in this study. This chapter looks at how both the primary and secondary research was conducted. It also highlights the limitations and complexities that were found during the research phase of this study. It justifies why the research methodology was selected as the design for this study. The third chapter gives an overview of literature and previous studies relevant to establishing a theoretical background to the theme. This chapter discusses the secondary research findings. The fourth chapter is an overview of culture, its definition, models and concepts. The fifth chapter explains the background of the case study organisation used for the primary research, and discusses the key themes and opinions that were obtained during the primary research. The sixth chapter will look to what extent each of the individual objectives was achieved. It will also highlight any possible weaknesses within the research and draw on the findings from the primary and secondary research, to make an overall conclusion of the study.
Page 9 of 66
Chapter 2
Research Methodology
2. Introduction This section describes the research methods that have been conducted to achieve the projects individual objectives. The research was from both primary and secondary sources. The findings from these were cross checked and compared to achieve the aims and objectives of this project. This multi method approach is known as triangulation, and is used to produce a full and balanced study [3]. 2.1 Secondary Research A literature review was carried out, in order to provide secondary research for the project. This was done to gain a greater understanding and familiarity of the research topic. Also to gain an insight of the previous research that has been carried out in the topic area, also to help plan the primary data collection [7]. The secondary information was collected from the University learning centre and from the British library. The sources used for this was books, as there was a great amount of material on effective project management. A disadvantage of using these texts is that many may be dated. Also, due to IT being a fast changing industry, some of these texts may be out of date and irrelevant in relation to todays business environment. To compensate for this, literature from current journals was also examined. These included case studies of organisations that have encountered project failure. These were used to back up any claims the older literature made. All of the sources used to conduct the literature review were personally evaluated in regards to its respectability and reliability. This was to ensure that a quality literature review was produced. By completing a literature review the first three objectives had been met. It highlighted the issues that should be taken into account for when the primary research was conducted [3]. 2.2 Primary Research As objective four was focusing on a real-life situation, a case study was used to fulfil the objectives requirements. Yin (1993), describes a case study as looking at a real life program whose complexity cannot be captured by surveying, and that a case study is used to illuminate how, and why things take place. The type of case study that will be used is known as an individual case study which
Page 10 of 66
focuses on antecedents, contextual factors, perceptions and attitudes. This is used to explore processes and experiences [5]. This method will be used as the researcher is trying to understand the case studies change control processes and the users experience of those process. It must be recognised that this case study will not be holistic (represent a global level) as it is only focusing on one organisation [4]. The researcher is familiar with the company that was used for the case study. He has contacts within the company, in the course of enquiries to get research documents. Due to this, a more open and reliable response would be obtained from the research, as trust had been built up with the company in the past [3]. 2.3.1 Ethics and considerations when conducting primary research The researcher had to take into consideration the ethics of using a case study when obtaining primary data. Although I was reluctant in using the companys name, however, I was dissuaded from doing so by the personnel manager. But all of the participants of the study remained anonymous as recommended by Sapsford and Evans (1984), they were referred to by their job role. The researcher had to obtain authorisation to use the company as a case study for the research project, therefore permission was sought early in the study. The company has been informed of any information disclosed in this study. Also the intentions of this study have been fully explained to all concerned. The researcher must also not keep records of any of the interviews or company information for longer than is needed to comply with the data protection act [7]. 2.3.2 Quantitative or Qualitative research methods For the primary research qualitative research methods were chosen over quantitative research methods. They provide a greater detail of peoples understandings and feelings than quantitative methods can attain [8]. To obtain this qualitative data the researcher chose to perform a number of interviews. Arksey and Knight (1999) describes how choosing an appropriate interviewing approach is a skilled and difficult activity. The interview approach chosen for this study, were one-to-one semi structured interviews. These interviews were conducted as they provide a more exploratory and qualitative response than a structured interviews. King (1994) refers to semi structured interviews as qualitative research interviews. This exploratory approach allowed the researcher to follow a set of questions but also probe into areas of interest to the research topic [3]. The interviews were audio taped. These were then typed up using a transcript methodology which can be seen in appendix B. This ensured that the interviewer could give his full attention to the respondent and make sure that
Page 11 of 66
there was no loss of data. This would also enable any claims made by the researcher, to be effectively backed up. The interviews were constructed to follow the themes and findings that were brought to light by the secondary research, focusing on the main arguments that occurred. The questions were structured to allow correlation between the primary and secondary research. They were also asked to more than one interviewee, which allowed the comparison of opinions and feeling between each of the interviewees. The answers from each interview was discussed, compared and contrasted, in relation to each of the relating set questions. These findings were triangulated with the secondary research from the literature review, using a data triangulation method [8], in order to gain confirmation of the findings [10] and provide completeness [11]. By using a data triangulation method it helped to reduce bias and improve the validity of the research [12]. An alternative research method to interviewing, to collect primary data, may have been the use of questionnaires. This method was not chosen as it only allows limited answers to the given for each question. This is therefore not as flexible as a semi structured interview and does not enable the researcher to clarify ambiguous answers and misunderstandings [5]. There were also only a limited number of people within the company that had expertise in this area of the study. Therefore, a mass questionnaire would have been non-effective in receiving a qualitative response. The researcher had chosen to interview to show a willingness and commitment to the company. This enabled him to utilise his relationship with the organisation. This was done as it was believed that a richer response would be obtained, as the interviewer was present when the questions were asked. 2.3.3 Sample for Primary Research The sample interviewees were chosen in relation to their expertise of the research topic, as they all extensively interacted with the companys change control system. Change control is a very specialised area and many people do not understand its full scope or purpose. Therefore there were only a limited number of candidates available for interview. The following describes why each interviewee was chosen for the primary research. Change control manager: Due to their extensive knowledge of the companys change control processes. They understand the importance of having a change control system in place. The change control team manager must ensure that the change control system is working correctly to comply with the laid down quality control.
Page 12 of 66
Project manager: Responsible for the running of selected IT projects within Waterfront UK and depends on the change control system to place controls upon the project. System controller: This person relies on the change control system to enable changes that the users may request, to be made to the current system. The system controller requires a successful change control system to ensure the daily running of the business activities, and is responsible for the testing of any change made to the system. These people were interviewed on the same day, using the same interview method. One to one semi structured interviews with open ended questions. This was to ensure that there was consistency and integrity between the interviews [3]. The questions were also constructed in such a way that would allow the correlation and comparison of answers between each interviewee, to contrast each of the interviewees views. 2.4 Limitations and Critical Analysis A data triangulation method was used in order to gain confirmation of the findings [10] and to provide completeness [11]. This was also used to reduce bias and improve validity [12]. However, Fielding and Fielding (1986) have challenged this view of data triangulation, arguing that it only allows a fuller picture of the problem, by gaining depth and understanding but does not offer a greater accuracy. The researcher still felt that by using a triangulation method, the findings would be strengthened. It was therefore felt more beneficial to use this method, than not to. As the researcher had his own experiences and observations from his experiences working at Waterfront UK, the researchers views and interpretations may have been biased from his experiences [3]. The researcher was aware of this and worked to prevent any bias that may have existed, from entering the study. The researcher was aware that Waterfronts change control process or business practices would not be representative of all companies. A single case study does not provide a holistic view [4]. Using multiple case studies would have been a better way of conducting the primary research. Due to time limitations and lack of budget, the researcher was restricted to using only one company for this case study. 2.5 Conclusion Each of the research methods used was chosen in respect to their effectiveness in completing the criteria for each of the projects individual objectives.
Page 13 of 66
Considerations about the experience of the researcher and the availability and ease of use had also to be considered when choosing the research methods. This chapter has justified the use of each of the chosen methods, and explained how the researcher utilised each of these within this study. The main methodology mentioned in the proposal that I had intended to use in this study was of an entire case study method. Due to time limitations and lack of budget, the researcher was restricted to using only one company for this case study. It was also felt by completing the literature review and participating in the interviews the researchers understanding of the study would not benefit any further from applying these methods to the study.
Page 14 of 66
Chapter 3
Literature Review
3.1 Introduction This chapter gives an overview of the relating research fields with the purpose of achieving the first three objectives of this project. Charles Handy (1993) defines organisational culture as the shared values, assumptions, norms, and the personality of the organisation. This can be evident in the way the organisation conducts its activities such as the way it raises capital, the treatment of its staff, formal and informal relationship that exists within it [14]. 3.2 Culture According to Argyris (1994) in many organizations, IS project implementation requires a transition period of at least three to five years. Major factors contributing to the lengthening of this transition are the complexity, ambiguity, and power of organizational culture [1]. Yet, managers who embrace valuesbased change initiatives often have little awareness of the causal impact of cultural forcesvalues, assumptions, patterns of thought and actionon the success or failure of their plans [2]. If we are going to address cultural factors that affect the implementation of IS projects, then it may be useful to clarify what we mean by culture. Edgar Schein (1992) has proposed the following clarification of what we mean by culture. First builds a holistic context within which culture is to be understood: Culture somehow implies that rituals, climate, values, and behaviors which bind together into a coherent whole. This patterning or integration is the essence of what we mean by culture. [15]. Next he offers a formal definition of culture: A pattern of shared basic assumptions that the group learned as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to these problems [15]. Culture is built up through its continuing enhancement of an organizations ability to deal with its problems in a way that fixes its identity. While culture is a systemic phenomenon, its primary architects are those at the very top [15]. Schein models culture on three levels (Figure 1). The first level, artifacts, includes observable daily features of organizational life such as activities, rituals, jargon, office layouts, and so forth. The second level, values and beliefs, includes
Page 15 of 66
an organization's espoused judgments about what is good and bad, which make sense of how actions are evaluated as exemplary or ineffective. The third level, basic assumptions, includes our deepest and most comprehensive explanation of realityour views of fundamental truths about people and the world. This layer is usually tacit. Additionally, to be found in this deepest layer, Schein points out, are the mental models and value systems that actually drive organizational behaviour [15].
Figure 1: Layers of Culture (adapted from Schein, 1992) (Full written permission obtained from author) 3.2.1 Critical Analysis According to Pendegraft, (1996), the difficulty with examining and understanding the levels of culture as stated by Schein in Figure 1, is that rarely are all three levels out in the open. Certainly the level of artifacts is observable; it contains the manifestations of culture that we see around us, the things, adornments, relations, and ways of speaking and address, that characterize tangible life in an organization. But when we attempt to look beneath the artifacts to find out why they are there we enter a realm that is often at least partially hidden from conscious thought, even among members of the organization [16]. Directly beneath the level of artifacts from Figure 1, lies the level of values and beliefs.
Page 16 of 66
These are the values that the organization holds dear and espouses a will to enact in practice. Common values are promote honesty, respect the needs of co-workers, or strive for excellence. These values are usually highly visible, often prominently posted. Yet, research has found in Rugman & Hodgetts (2000), states that routine organizational behavior sometimes reflects other, hidden values, especially in situations of stress and uncertainty. In contrast to espoused organizational values, these shadowy, alternate values are rarely acknowledged openly, nor can we examine them directly. Instead, they must be inferred from patterns of behavior. An example of such a hidden value would be win, do not lose [14]. These hidden values often conflict with published espoused values. Moreover, when we choose to act consistently with hidden values, our actions will likely undermine other actions seeking to realize the espoused values of the organization [14]. 3.3 Organizational Culture According to Thompson & Strickland, (1999), organisational culture can be defined as the shared values, assumptions, norms, and the personality of the organisation. This can be evident in the way the organisation conducts its activities such as the way it raises capital, the treatment of its staff [18]. Organisational culture can also be broken down onto formal and informal relationship that exists within it. Formal relationship include the hierarchical work relationships within and between functional business areas, while informal relationships are created through people working and socialising with each other on a regular basis, and it cuts across functional barriers [18]. 3.3.1 Stages in Development of Organizational Culture Schein (1985) identifies organisations developing through the three stages of "Birth and Early Growth, Mid-life and Maturity". Schein doesn't believe that progression through each of these stages is inevitable. Changing an organisation's culture is possible, even inevitable. He proposes various change mechanism for each of the stages and places great emphasis and responsibility on the leaders for initiating and implementing these, often using organisational development techniques. Only at the Maturity stage when decline and potential termination is likely, does he proposed more drastic actions, such as "Coercive Persuasion", "Reorganisation, Destruction, Rebirth", "Bankruptcy and Reorganisation" (p272). 3.3.1.1 Birth Stage Birth and Early Growth covers the formative years, when new organisations are "dominated" by the vision and drive of their founder. Here according to Schein
Page 17 of 66
(and others), "Culture is a distinctive competence and source of integrity; .. the glue that holds organisations together", and "Organisations strive towards integration and clarity" (p271). Handy (1985) see this phase typically being "power-oriented, politically minded, risk taking, and rate security as a minor element in their psychological contract" (p189). A culture where organisations "judge by results and are tolerant of means". 3.3.1.2 Mid-life Stage During the Mid-life phase, when "the sheer numbers of non-family members over weighs the family members" (Schein, p283), the original culture has become absorbed and unconscious and then "Cultural integration declines as new subcultures are spawned. Loss of key goals, values, and assumptions creates crisis of identity" (p272). This is Handy's "role culture, often stereotyped as bureaucracy" (p190). This culture works by "logic and rationality" embodied in rules and procedures, and "rests its strength in its functions or specialities". Handy refers to Weber's (1963) definition of a bureaucracy. 3.3.1.3 Maturity Stage Finally, Maturity is reached when "the organisation is unable to growth because it has saturated its markets or become obsolete in its products" (Schein, p291). "Culture becomes a constraint on innovation. [It] preserves the glories of the past, hence it is valued as a source of self-esteem, defence" (p272). 3.3.2 Shared Knowledge among Workforce According to Goodstein et al (1993), an organisations culture is embedded in the minds of its employees. The norms within an organization are rarely written down; rituals and celebrations do not usually exist in procedure manuals; organisational metaphors are not found in corporate directories [19]. Organizations therefore depend on a stable workforce to communicate and reinforce the dominant beliefs and values [20]. The Organizational culture can literally disintegrate during periods of high turnover and precipitous downsizing because the corporate memory leaves with these employees [19, 20]. Corporate culture also weakens during periods of rapid expansion or mergers because it takes time for incoming employees to learn about and accept the dominant corporate values and assumptions. 3.3.3 Transmission Agents According to Hofstede (1991), an organisational culture is learned, so an effective network of cultural transmission is necessary to strengthen an
Page 18 of 66
organizations underlying assumptions, values, and beliefs. The cultural network exists through the organisational grapevine. It is also supported through frequent opportunities for interaction so that employees can share stories and re-enact rituals [20]. Senior management and executives must tap into the cultural network, sharing their own stories and creating new ceremonies and other opportunities to demonstrate shared meaning. Company magazines and other media can also strengthen an organisational culture by communicating cultural values and beliefs more efficiently [20]. 3.3.4 The learning Process According to Ridgeway et al (1997), individuals learn the values, expected behaviours, and social knowledge necessary to assume their roles within the organization through a process called organizational socialization. By communicating the companys dominant values, job candidates and new hires are more likely to internalise these values quickly and deeply [21]. People learn about an organisational culture through recruiting literature, advertising, and news media reports about the company [21]. During the recruitment process, some companies provide information about the way things are done around here. Even if this information is not forthcoming, applicants might learn from employees, customers, and others who regularly interact with the organization [21]. 3.4 Main Cultural and Structural Problems in IS Projects One of the dominant models in analysing cultural problems within an organization is the organizations cultural web analysis developed by Johnson and Scholes (1999). This model was utilized by KPMG in a survey by Casey (1999) in analysing the cultural fit and differences between Daimler and Chrysler during its merger. The factors identified in the cultural web analysis have a strong similarity to the factors found in the forcefield analysis.
Page 19 of 66
Figure 2: Organizations cultural web analysis (adapted from Johnson and Scholes 1999) (Full written permission obtained from author) 3.5.1 Symbols This would include titles, the type of language and terminology used, within an organisation. In the case of an organization there are many symbols of hierarchy or ways of doing things in either a conservative or informal and formal way [23]. 3.5.1.1 Influence on IS Project: Daimler-Chrysler According to Casey (1999), during the IS reengineering at Daimler-Chrysler, the differences in symbols and privileges between levels of management and executives led to mistrust, deep suspicion and undue delays in project implementation. In Daimler-Benz executives wanted to be addressed by their Doctor title and this did not go down well with executives of Chrysler who felt it was irrelevant [25]. This however led to instances where major key decisions where simply ignored by executives of Chrysler [25].
Page 20 of 66
3.5.2 Power Structures According to Ridgeway et al (1997), there are differences in power structures in different organizations depending on the structures in place. Top executives either work as a tight nit community working on a firm set of beliefs and assumption in terms of how the company should operate. On the other hand, Pendegraft (1996), states that in other organizations, executives are a select few, who are employed on the basis of achievements, reputation, level of prestige and ideology. These structures normally affect the long-term work ethics in place and bureaucracy [16]. 3.5.2.1 Influence on IS Project: National Probation Service: NPSISS (CRAMS) According to a report by the National Audit office (2001), sites lack of commitment from top executives as one of the reasons responsible for the failure of the national probation service IS implementation project. The report states deliberate decision and power tussle among top executives as one of the reasons in deliberately excluding the strategy board and IT manager from its key decision process [27]. 3.5.3 Organizational Structures According to Hofstede (1991), an organizations structure can either be hierarchical, matrix, flat, networked or T-formed. The hierarchical structures are those where individuals are part of a bureaucracy where a small group hold authority and are responsible for key decisions. While the matrix and flat is a decentralised structure allows authority to be dispersed throughout firm. Rosebeth Moss Kanter (1989) argues managers need to apply entrepreneurial principles to the traditional corporation, creating a marriage between entrepreneurial creativity and corporate discipline, co-operation and teamwork [20], as to do otherwise will stifle creativity. 3.5.3.1 Influence on IS Project: Failure of Project Everest Ford Motor Company According to Carr (2004), Project Everest embarked upon by Ford motor company, failed mainly due to the prevailing organizations structure at the time. Prior to the commencement of project Everest, the organizational culture at Ford was such that it prided itself in its empowered unit entity, there was fierce independence and competition among its units, largely encouraged by top management [28]. Although on the surface, commitment was high among top
Page 21 of 66
management, and there were efforts to propagate the same among its units, however, reports reveal that most of them were not as committed, in fact, there was a definite morale problem among members of staff on all levels [28]. The different perspectives of the stakeholders revealed fierce resistance mainly from the unit managers and employees who plainly rejected the idea on the grounds of lack of consultation. This was after over $800 million was spent [28]. 3.5.4 Control Systems This emphasises what is important to monitor in an organisation and what to focus attention and activity upon [18]. It intertwined between its Business strategy and its values as an organization. 3.5.4.1 Influence on IS Project: Daimler-Chrysler According to Casey (1999), a breakdown in the IS implementation as carried out by Daimler-Chrysler, was due to the fact that Daimler-Benz was guilty of focusing on enhancing shareholder value instead of stakeholder value on a positive note, Daimler-Benz focused its attention on high quality goods [25]. In this case, both Daimler and Chrysler are monitored on quality, profits, financial reporting and professional responsibility [25]. Some experts in the automotive field believe that Chrysler focused more attention on faster production and excessive research and development projects which in turn places less emphasis upon quality [25], this is the total opposite of Daimler-Benz where quality comes at a high price. This will prove to be a cultural problematic area [25]. 3.5.5 Rituals and Routines This includes events and formal processes which the organisation emphasises what is particularly important [16]. This would include relatively informal organisational processes, which include attitudes to change, training, chances of promotion, working hours, attitude to training, work conditions, drinks after work, working less hours and a chat around the photocopier. Similar routines take place across all the business entities of the organization. 3.5.5.1 Influence on IS Project: Failure of Project Everest Ford Motor Company According to Carr (2004), in the implementation of Project Everest, wading through the rituals, politics, cultural and inter-departmental / regional suspicions, was an accident waiting to happen and the steps that killed off the project [25]. The unit / regional managers and employees, saw the new information system as a threat, implying a loss of their jobs, distinct strategy and set pattern
Page 22 of 66
of productivity which they were already used to [25], thus leading to disintegrated work patterns they have been used to for decades, loss of entrepreneurial freedom, product competence and loss of our distinct strategy, which has been sustained for four decades [25]. 3.5.6 Stories According to Johnson et al (1999), stories are told by members of an organisation to each other, to outsiders, to new recruits and so on, which embed the present in its organisational history and so on and also flag up important events and personalities [23]. In most cases organisations have successes, disasters, heroes, villains and mavericks that have become part of the organisations folklore [23]. 3.5.6.1 Influence on IS Project: Daimler-Chrysler In recent history, Chrysler have almost gone bankrupt twice, perceived poor quality of product and has a villain in the form of pragmatic hands-on engineer Robert Eaton who effectively placed Chrysler into German hands, this has fuelled an anti-Daimler-Benz sentiment in US [23]. On the other hand Daimler-Benz made engines and components for the Nazi war machine during WWII, they have a maverick in the form of Juergen Schrempp who masterminded the largest automotive merger in history [23]. Stories and folklore should not hamper IS project implementation at all, as the organisation will be analysing the present and looking into the future and not the past. 3.6 Change Process Models One of my objectives is to consider change management as a method for controlling the effects of an organizations culture on IS project implementation. The dominant model of change management I would be utilizing in this project would be Kurt Lewin, this was developed in the 1930s and 40s. 3.6.1 Lewins Change Model This is a natural progression from Lewins forcefield analysis. According to Lewin (1952) the managed change occurs through the process of unfreezing the current situation, moving to a desired condition, and then refreezing the system so that it remains in the desired state [29]. Lewins model also recognises that change requires disequilibria between the restraining forces and the forces for change [29]. Effective change involves minimising the restraining forces as well
Page 23 of 66
as making employees more aware of the forces for change [29]. Even though this model is fifty years old it has stood the test time and is still popular as a conceptual framework [29].
Figure 3: Management of change (Lewin) (Full written permission obtained from distributor) 3.6.1.1 Unfreezing This is the process where top executives, senior management and change agents get their workforce in their respective organisations to recognise that the old ways of doing things are no longer satisfactory and to accept the need for change [29]. This way, all the stakeholders, all those to be affected by the IT / IS change and everyone associated with both organisation and its IS would be aware that change would be inevitable some day, and that the behaviour of the organization / industry would affect them in some way, shape or form [29]. This way with the involvement of the top executives, the stakeholders would have the impression that the change is in the best interest of everybody and that it would create the most profitable and competitive position for the organization [29]. 3.6.1.2 Moving The second stage is driving the necessary change or moving it to a new level. The change agents have to play a major role in this stage [25]; they must capitalise on the acceptance for the need for change and generate compliance and support throughout all the stakeholders [25]. Basically, this involves every physical and non-physical aspect of the organisation, and this is commonly known as organisational development [25]. Organisation development (OD) takes an open systems perspective and relies on many organisational behaviour concepts, such as team dynamics, perceptions, job design and conflict management [25]. Most OD activities rely on action research as the primary blueprint for planned change. Top executives and management would need to determine whether the change in question should be evolutionary (incremental change) or revolutionary (quantum change) [25]. Important Cross-Cultural issues on Organisation development:
Page 24 of 66
Criticisms According to Easton (1988), the main criticism of the organization development includes the following; 1. OD techniques mainly originate from the US and do not work as well in other cultures such as Asia 2. OD makes linear and open conflict assumptions about change; not held in cultures with high power distance and collectivism 3. OD needs a more contingency oriented perspective Field Theory The field theory is about understanding the group behaviour in an organization by understanding the field in which the behaviour takes place [19]. Group Dynamic Group dynamic is about understanding the dynamic between group members in order to change that dynamic [19]. 3.6.1.3 Refreezing The third stage aims to lock in new behaviour through a process of reinforcement and reward at the organization. During the refreezing stage, the organisation may also ensure that the new behaviours have become the operating norms at work, that the reward system actually reinforces those behaviours, or that a new, more participative management style predominates (Goodstein & Warner Burke: 1993) Resistance to change may be minimised by keeping stakeholders and employees informed about what to expect from the change effort (communicating); teaching employees valuable skills for the desired future (training); involving them in the change process; helping employees cope with the stress of change; negotiating trade-offs with those who will clearly lose from the change effort and using coercion [19]. I believe that organisational change should be a continuous process that is engaged continuously especially after the refreezing stage [19]. Attitudes must always be flexible and responsive to the opportunity for new approaches [19].
Page 25 of 66
3.7 IS Project Implementation activities Utilized 3.7.1 Implementation Planning Pinto (1998) argued that it is vital to thoroughly plan an implementation process. Implementation planning refers to the process of translating the strategy into a series of specific project tasks and when they are completed, the organisation will have a functioning IS. Most planning tasks are non-routine and multifunctional, often integrating various types and sources of data. Effective implementation planning requires the ability to forecast different growth scenarios. System developers have to ensure that implementation planning and goals are clear to all team members, e.g., senior managers and users [32]. 3.7.1.1 Implementation Strategies Organisations can adopt a variety of strategies by which essential changes can be implemented. The implementation strategies can be loosely arranged on a dimension from the revolutionary to the most evolutionary. The implementation team needs to select the route that the organisation can best accommodate. The more evolutionary the approach, the more time the users have to adjust but the more likely the momentum of the project is to be lost [22]. Five strategies proposed from Eason (1988) are;
The Big Bang - One of the most difficult kinds of implementation is when an existing system is being discontinued in its entirety as the end of one day and a new system replaces it on the following day. A highly publicised example in recent years was the overnight switch of the London Stock Market to electronic trading in 1986 [22]. Parallel Computing - One popular way of minimising the risks to the ongoing, work is to introduce the new system alongside the old one and to run them in parallel until everybody is confident that the new system will be effective [22]. Phased Introduction - The problems of making massive changes can be eased by phasing in the changes over a period. There are two ways in which large-scale changes can be subdivided to facilitate phased introduction. First, the functionality of the technical system can be introduced in phases so that the basic task processes can be supported in the early stages and subsequently facilities can be added which support, for example, decision-making tasks. Second, it may be possible to introduce the system in different parts of the organisation at different times [22]. A combination of these two approaches can also be used [22].
Page 26 of 66
Trial and Dissemination - This strategy explicitly recognises that will be teething troubles when a new system is introduced. By holding an essential trial or pilot project before embarking upon full-scale implementation. This strategy provides a valuable opportunity to prepare thoroughly for implementation before it is in the throes of full-scale change. However, many organisations fail to make good use of the opportunities that the trial presents [22]. Incremental Implementation - The alternative to a revolutionary change is gradual evolution. The growing sophistication and flexibility of technology is making the incremental implementation of system and increasingly practical proposition. When users are discretionary and powerful and their needs are varied, not to say idiosyncratic, the service has to be tailored to individuals [22].
3.7.1.2 Systems Development Every systems / software project has its own process [33]. The projects plan documents the process and provides a disciplined approach to organizing and managing an information systems project [33]. The existence of a plan does not guarantee project success [33]; the key to successful software management is generating and maintaining a realistic, usable plan and then following it through [33, 34]. Following the plan involves not only maintaining the plan itself, but also performing activities to measure progress and performance against the plan. Use the plan to assist in recognizing danger signals, and take early and appropriate actions to solve problems. In terms of systems development, most studies are concerned about development procedures and activities (Bingi, et al., 1999). Fitzgerald, Philippides and Probert (1999) argued that systems development was still a problematic area despite the great attention devoted to improving techniques and methods. The great hopes of improvements based upon new approaches and tools such as methodologies, object-oriented techniques and CASE, were not much seen in practice so far [33, 34]. 3.7.1.2i. Life Cycle Models All products follow some type of life cycle. Software / systems development projects are just one subset of IS / IT projects. A life-cycle model comprises one or more phases (for example, a requirements definition phase, a design phase, a test phase). Each phase is defined as the time interval between two scheduled events [33, 34]. i. Systems Development Lifecycle (SDLC)
Page 27 of 66
This is a framework for describing the phases involved in developing information systems [33]. It is essentially a once-through-do-each-step-once approach [33]. Simplistically, determine user needs, define requirements, design the system, implement the system, test, fix, and deliver the system. Some popular models of this framework include; waterfall model, spiral model, incremental build model and rapid application development (RAD) [33]. These lifecycle models are examples of predictive lifecycle, meaning the scope of the project can be clearly articulated [33]. For example, in the waterfall life-cycle model, the design phase is defined as the period between the software specification review and the critical design review (CDR) [33]. Within each phase, one or more activities are executed. For example, during the waterfall models design phase, the design activity is performed; the test planning activity for qualification testing may be done at the same time. In most cases, activities neither begin nor end precisely at the phase boundaries; rather, they overlap adjacent phases, as illustrated in figure 4 below.
Phases:
RQTS
DESIGN
IMPLEM & QUAL TEST
SYS TEST
ACCEPT. TEST
EFFORT
SSR
CDR
QTRR
ATRR
ORR
TIME Requirements Design Acceptance Testing Implementation Other
Activities:
Qual & Sys Testing
Page 28 of 66
Figure 4: Phases and activities in systems / software development (Adopted from Fitzgerald et al 1999) (Permission obtained from Journal distributor)
Advantages
Disadvantages
Most appropriate when ...
Well-studied, well-understood, and well-defined Easy to model and understand Easy to plan and monitor Many management tools exist to support this lifecycle model Most if not all requirements must be known up front Does not readily accommodate requirements changes Product is not available for initial use until the project is nearly done Project is similar to one done successfully before Requirements are quite stable and well-understood The design and technology are proven and mature Total project duration is relatively short (less than a year) Customer does not need any interim releases
ii. Adaptive Software Development In contrast to the predictive lifecycle models, the adaptive software development (ASD) lifecycle model develops a system in builds, but differs from the SDLC / Waterfall model in acknowledging that the user needs are not fully understood and not all requirements can be defined up front [33, 34]. One of such models is the evolutionary approach, agile software development, extreme programming, scrum [33, 34]. The user needs and system requirements are partially defined up front, then are refined in each succeeding build. The system evolves as the understanding of user needs and the resolution of issues occurs. Prototyping is especially useful in this life-cycle model. (The evolutionary development life-cycle model is sometimes referred to as a spiral development model, but it is not the same as Boehms spiral. Important attributes of this approach are that the projects are people driven, with emphasis on constant collaboration with the users to capture requirement all through the development process [33, 34].
Page 29 of 66
Advantages
Disadvantages
Most appropriate when ...
Not all requirements need be known up front Addressing high risk issues (for example, new technologies or unclear requirements) early may reduce risk Like the incremental life-cycle model, interim builds of the product facilitate feeding back changes in subsequent builds Users are actively involved in definition and evaluation of the system Prototyping techniques enable developers to demonstrate functionality to users with minimal of effort Even if time or money runs out, some amount of operational capability is available Because not all requirements are well-understood up front, the total effort involved in the project is difficult to estimate early. Therefore, expect accurate estimates only for the next cycle, not for the entire development effort. Less experience on how to manage (progress is difficult to measure) Risk of never-ending evolution (for example, continual gold plating) May be difficult to manage when cost ceilings or fixed delivery dates are specified Will not be successful without user involvement Requirements or design are not well-defined, not wellunderstood, or likely to undergo significant changes New or unproved technologies are being introduced System capabilities can be demonstrated for evaluation by users There are diverse user groups with potentially conflicting needs
iii. Problems Ascertaining Customer Requirements and Constraints Going through the Standish Group, CHAOS 2001: A Recipe for success, [40] revealed that from 1999 till date, a total of $3 billion had been lost on failed information systems implementation and further investigation suggested that
Page 30 of 66
70% of the project failures were down to poor management of the requirements and scope of a project [40]. User requirements are often not clear at the start, for a number of reasons: users may be unsure of what they want [40]; it may be difficult to identify their tacit knowledge about day-to-day processes; they may not have been consulted sufficiently; and they may be misunderstood [40]. Arguing in the same line, Mahoney (2000) and Lytinen (1999) in reviewing 100 failed IT projects states that most of the time at IS project inception, the customer may have only a general idea of the software requirements, suggesting that determination of the detailed requirements may follow later or may even be part of the ongoing process [43, 44]. Mahoney (2000) therefore suggests that it is imperative for systems / software developers to utilize an IS project methodology that would be flexible to get the end user involved throughout the products engineering life cycle [44], in that way the more likely the expected product will result successful [43]. This involvement is particularly crucial during the requirements analysis and design activities early in the life cycle [44]. It is also important to try to get end-user involvement at milestone reviews [44]. iv. Implementation Strategy / Product Releases Greer (1999) has listed 14 key success principles for information systems projects, with an admonition for the use incremental and phased software releases (as opposed to the big bang approach) either to satisfy early operational needs of the customer or as a risk mitigation technique (for example, to ensure the feasibility of high-risk requirements). The author argues that a phased approach would ensure the smooth running of the Business whilst implementation is going on [45], in addition for projects where the requirements are not very clear at the start integrating and testing the system in parts helps to localize errors and reduce debugging time. Early releases also help to build the customers confidence level, as well as that of management, that the project is on track [45]. 3.7.2 Training Training, in the context of IS implementation, refers to the provision of hardware and software skills sufficient to enable effective interaction with the system under consideration (Nah and Lau, 2001). They further argued that training plays a significant role in IS implementation success. Senior managers can allocate an on-site technical specialist in entertaining end-users queries during the implementation process. According to Wilson et al (1990), the outcome of this approach to training employees, is that it ascribes a sense of ownership and endusers will become independent and successful through the transfer of expertise and the company will in the process avoid a low morale build up which usually
Page 31 of 66
arises during post implementation projects [46]. This would also save the company huge cost as the users would be better prepared to handle problems with the system [35, 46]. 3.7.3 Stakeholder Management / Project Sponsors A recurring theme in the literature is the significance of integrating all stakeholders into the project (Pinto, 1998; Ang, et al., 2002; Kuruppuarachchi, et al., 2002). The list includes everyone who is connected with the IS project, these include; project sponsors, project manager, project team, support staff, suppliers and opponents to the project [36]. Glover, et al., (1992), found a lack of co-operation or commitment among the stakeholders to be the most common cause of an implementation failure. For instance the project sponsor has to be organisationally powerful so that essential decisions about the implementation can be taken and they can become an active promoter of the system amongst their peers [36]. They also have a crucial part to play in helping to derive needs analysis [36]. Securing management support is crucial for IS implementation. Winning the support of the decision-makers and senior management are often mentioned as critical prerequisites for initiating IS implementation (Ang, et al., 2002, Marble, 2003). Budic (1994) found continuity as a significant aspect of political and management support. According to Carr (2004), a proven strategy for getting commitment among stakeholders, is the adoption of a top down approach. With this approach, top management can communicate the strategy and commitment to all other members of staff to facilitate the change [28]. With the committed leadership they were more likely to commit the resources and be actively involved in monitoring the change by talking to staff, investing sufficiently and propelling the drive to introduce new initiatives [28]. On the other hand, prolonged implementation and changes in political climate can adversely affect the implementation of an IS [37]. Political and management support appears to allow development of a system, perhaps by indirectly inspiring financial and moral commitment to IS project as well as by increasing the likelihood of adequate user support [38]. 3.8 Justification for Project Topic No one could dispute that Information systems has become a forceful tool to gain continuous competitive advantage [28]. According to Carr (2004), as the
Page 32 of 66
investment in the technology grows, so does the need to carefully realise the factors of implementation process that are related to project success, or failure [28]. IS / IT projects are highly resource-intensive process often involving senior managers, system developers and end-users, thereby suggesting that analysis of the organizational cultures which affect such projects should be analysed in order to successfully implement the system. 3.9 Conclusion This chapter has examined and covered the first three objectives of this project. I have utilized the relevant literature to investigate and discuss the concept of culture, organizational culture and how this affects and influences information system project implementation. A number of change management models were also explored, thereby enunciating how these models and theories can be utilized in reducing the risk an organizations culture might bring to an information systems project implementation. By carefully following a described methodology, I have divided this field into various sections, and I therefore believe that all major topics of this project have been covered in respect of my first three objectives. In total, this chapter covered 39 references in the area of organizational culture. Of these, 15 were focused on the concept of culture and organizational culture, 8 looked at the effects to a number of information systems project implementation such as the Daimler-Chrysler, Ford motor company and the Boeing company, while the rest were focused on change management and its models.
Page 33 of 66
Chapter 4
Case Study Findings
4. Introduction This chapter aims to complete objective four by looking at the primary research and picking up on the key themes and opinions that was raised by it. Where possible it relates these back to the literature reviewed in the previous chapter. These findings will then be discussed and compared to the findings from the secondary research, and draw on the key issues raised. 4.1 Company Background and Problem Situation The Waterfront UK Company of Birmingham is one of the largest exporters in the UK and one of two leading clutch producers in the world. In the 1990s it acquired new muscle in trucks and heavy-duty vehicle production when it purchased its long time rival Cartrack International. A few years ago, company profits started to nosedive, but it intends to respond with two efforts, which involves critical roles for information systems. These include the design process for the double clutch plate lines of heavy goods vehicle, and the attempt to modernize its single plate production. For years, Waterfront UK had no serious competitors. Then Europarts International entered the commercial clutch manufacturing business, and by 2004 had already achieved a 28% market share. The competition between the two has increased in intensity. Both agree that demand for single and double clutch plates will triple over the next twenty years. Waterfront UK management have made automated design process a key focus for the future, because they believe this will be needed to produce the increased quantity of expected demand clients. Waterfront UK also believes that operational costs are a key factor and a newly designed IT strategy will greatly reduce these costs. Unfortunately for Waterfront UK, its production process has been very inefficient. By competing on price, Waterfront UKs profit margins have been cut very sharply. Why was Waterfront UK so inefficient? Mainly because it has been making clutches with the same hierarchical manual productions process used to make its famous single plates. Over the following decades, Waterfront UK had no competition and met no pressure requiring it to become more efficient. All this changed with the expansion of the EU, motor parts deregulation, and the emergence of Europarts.
Page 34 of 66
A major problem with Waterfront UK is its organization strategy, which is a hierarchical / distributed structure, whereby key decisions are made by a few at top management, almost all vice-presidents and departmental managers confer with the president daily, usually regarding the progress of products, employment and other key decisions. With different groups meeting at different times with the president, the groups were not formal or even based on functional problem lines. If one individual felt that a daily printout indicated a particular change, regardless of whether or not it affected his or her department, he or she would go to the president asking for the change to be effected. If another department manager or even a vice-president were present and disagreed, inevitably a fierce argument would develop in the presidents office. Critics have pointed to the presidents reputation as an "easy touch" for external suppliers, e.g. if a supplier had some previous tie from the old days or was remotely related to someone in his family, he would be assured of at least some orders, despite the fact that his prices might be higher than those of competitors. The information systems within Waterfront UK were such that each existing business units had its own information technology department responsible for each unit operations. Engineers worked in separate domains, based on their field of specialization. Some designed the clutchs parts, others assembled them, and others designed the packing crates. They rarely compared notes. If production engineers found a part that didnt fit, they sent a complaint to the designer located in another plant. The designer then pulls out the drawings, reconfigured the part to make it match drawings of the surrounding parts, and sent the new design back to plant. Warehouses were filled with paper. This fragmentation of data across the separate systems in each department implies that discrete business process from sales, production, finance, and logistics cannot be integrated into the company wide business process that flows across organisational levels. And this will have a negative impact on the organisational efficiency and business performance. Various departments will find it difficult to communicate and act on orders effectively worldwide. 4.2 Strategic Outlook A plan has been suggested that to develop the double clutch plate faster and at a lower cost. Waterfront UK should introduce a cross functional IT exchange across the organization. This is a centralized system whereby information system from all its functions / departments are integrated across the organization eliminating complex links between the company systems in different units. Discrete business / operations process and information from all the departments
Page 35 of 66
can be integrated and stored in a single comprehensive system, where they can be used easily by all employees. Working from a single source for product data would eliminate unnecessary inventory, ensure that duplicated resources are eliminated and reduced operations cost. This would enable everyone to work from the same data source, thereby reducing order processing time and downsized operations process. Through cross functional IT, electronic data interface which links with external suppliers is created, whereby customers can log onto the company system to place orders and alert management on levels of replenishment. This would lead to efficient customer service, customer satisfaction and retention, thus giving Waterfront UK an edge over its competitors. These proposed changes would suggest that IT would support organizations goals, whereby top management can keep an eye on company operations across geographical or business unit boundaries. This system unifies operations releasing information flows across the organization to support business goals. Functional boundaries are thus de-emphasised in favour of cross- functional coordination requiring that the manual manufacturing process will be replaced by an automated process thereby ensuring savings on overhead and high business turn over. 4.3 IS Implementation: Cross Functional Business Programme The Cross functional business programme is a Global Web-based Intranet Marketing Decision Support System. The system serves more than 35 marketing teams across Europe, offering customised views of market intelligence data. In addition, the new software was supposed to reduce paperwork, consolidate some 35 disparate purchasing and procurement systems into one Web-based system that would serve multiple tiers of suppliers, thereby speeding orders and clashing costs. The project supported the move to unify the separate marketing groups through encouraging a far more open communication system. The CFBP project leader has worked closely with Information Services International (ISI) built around ERP software, its main goals included; - unify dozens of legacy procurement systems, - standardize procurement methodology across its feudally, -run, fiercely independent plants, - take on direct, indirect, and MRO at the same time, rationalize its supply base while putting in the new system. 4.3.1 Systems Objectives
Page 36 of 66
Cost Control - Top management had projected that reduced costs were possible from rationalizing the supply chain and moving to guided sourcing. Guided sourcing, which their suppliers had to use, according to Paul Wood, Fords spokesman, saves money by cutting out expensive, off-contract maverick purchasing, and is one example of the kind of tighter rigour that now applies across the company. Such is the way the new system would work that no supplier can deliver if they cant quote an order number. This number has to be entered into the system in an authorized fashion. System efficiency One of the objectives is to use SAP ERP systems as its single front end systems to provide a consistent picture of production, finance and sales reporting. The software also includes EDI links with external suppliers and database links for internal suppliers, covering the core five processes: finance, sales and operations planning, procurement, customer order fulfilment, that way around 80 per cent of the corporate back office goes on R/3 all the finances, all order processing, all the production ordering, stores and logistics as well. 4.3.2 Implementation Planning Most of the implementation planning tasks were usually initiated and developed by the project leader. Prior to the implementation, there was no proper planning structure in existence. It was a one-man vision in charge of the department. System Development Waterfront adopted the traditional waterfall methodology in the design of the system. This included the six major phases in the waterfall lifecycle of the development of the software, these were; -Requirements gathering phase & Requirement definition -Design & coding phase -Testing phase -Live running phase
Page 37 of 66
Figure 5: Stages in the waterfall model
Summary description and discussion
The waterfall (single-build) life-cycle model is essentially a once-through-do-each-step-once approach. Simplistically, determine user needs, define requirements, design the system, implement the system, test, fix, and deliver the system. This model is illustrated in figure 5. Well-studied, well-understood, and well-defined Easy to model and understand Easy to plan and monitor Many management tools exist to support this lifecycle model
Advantages
Table 1.1 Summary of Waterfall Development Life-Cycle Model By using this methodology, discussion between the users and the developers was very limited.
Page 38 of 66
IS Implementation: Cultural Issues & Changing Requirements In between pre and post implementation, the company had made six changes to the project team and four weeks after project kick off, the president fired the project manager after this person had been on the job only four weeks and despite the fact that she held a three-year management contract for $100,000 per year, and as a result when the initial system was released, it was noted that the requirement for the front end to produce reports for management purposes was not adequately specified at the start of the project, nor was a subsequent requirement from the marketing team to develop standard reports using specialist software, known as GQL, which extracts data from databases. This was also due to the fact that the company received an unprecedented order for 6million clutch plates, this order needed to be mass produced and the company therefore had to change its requirement frequently even though development had progressed rapidly, the company had to invest extra resources to make the GQL software work satisfactorily as the initial release failed to meet this new requirement. There were other instances of poor specification of expected outputs, weaknesses in service monitoring and inadequate control by the company over the issue of purchase orders contributed to the higher than expected cost of the programme. IS Implementation: Cultural issues & Scope Escalation The project leader at the project inception left the organisation before the system was launched, leaving no standard and recognised process for the dissemination of information amongst the manufacturing and project implementation teams. The post implementation scenario started when the scope of the project was termed risky by then CEO Barbara Fletcher. Waterfront UK was an early adopter of SAP R/3. After the project began, Waterfront UK signed a large contract to supply 6million clutch plates to the Peugeot Automobile of Nigeria. This event exacerbated the need for an unprecedented volume of R/3 transactions. Although, prior to the contract, testing seemed to indicate that R/3 on HP9000 servers would be able to cope with the volume of transactions, however in 1997 R/3 could process only 10,000 worth of orders customer orders per night, compared with 420,000 under Waterfront UK's original mainframe system. 4.3.3 Implementation Strategy The Consumer Understanding Department has adopted the big bang introduction strategy in implementing the system. In this case, phasing in the
Page 39 of 66
changes over a period would have been the right choice as that would ease the problems of making massive changes. Nonetheless, the functionality of the technical system was not introduced in phases. Implementation Strategy: Events The decision to adopt the big bang approach backfired as the preimplementation testing was inadequate, partly because the requirement for the front end to produce reports for management purposes was not adequately specified at the start and lots of transactions not specified were added afterwards. As a result the company lost about $25million in sales as its system was down for six days. 4.3.4 Stakeholder Management Senior Management - It was revealed that prior to the inauguration of the project, a top-down approach was adopted in order to secure the support of top management. Nigel Taylor was appointed as CEO and champion of the project, with the objective of first of all communicate the strategy and secure the commitment of all senior managers all other members of staff to facilitate the change. Prior to the commencement of the project, with the assistance of the project leader, support was secured and this in turn suggested the support of the other teams within the organisations who would be required to assist in the project. Although senior managers were supportive and committed (to commit the required financial resources to the project), pressures from them alone were not sufficient to boost the lack of awareness amongst the end-users. Employees - Although senior management commitment was high, reports reveal that some users were not as committed. In fact, there was a definite morale problem among the warehouse employees. This was not surprising, since the project's Horizons warehouse automation integrated with SAP R/3 threatened their jobs. With the closing of three warehouses, the transition to the first automated warehouse was a disaster. Disgruntled workers damaged inventory, and orders were not filled, and mistakes occurred as the new system struggled with the volume of transactions. $34 million worth of inventory were lost. Regional Managers - On the professional level, the regional marketing managers would welcome the cross-functional change, as it potentially would give them the opportunity to monitor sales representatives and obtain current customer information. However, on a personal level, concerns would be if senior managers were prepared to back up their words with actions in respect of the reorganization. As it can be observed from the case study, the question arose
Page 40 of 66
with regards the uncertainty of where the responsibility for this project actually lies, is it with the CEO, the IS manager or themselves Unit Managers - For the unit managers, carrying out the Cross Functional Business Programme changes would call for redesigning the entire business process, which would inevitably stifle creativity and loss of distinct strategy, which has been sustained for four decades. Their argument had also been that their benchmark for success previously was to promote competence and creativity through separate departments and units. Operating as a separate business entity had afforded the unit managers the opportunity to develop a distinctive strategy for each department, which has a better chance to offer competitive packages, encourage product differentiation and offer entrepreneurial freedom. The IT manager The IT managers had re-skilling resource concerns, as implementation would require retraining a large number of employees to operate the new systems across the organisation and re-designing fundamental business processes all at once while carrying on business as usual. There would also be fears of potential loss of experienced employees who may decline training in the new system. In addition, like the regional marketing managers, the IT manager would be concerned as to whether the CEO will put the money where his mouth is. 4.3.5 Training Third, the execution of the project was an issue due to the shortage of skilled and knowledgeable personnel. Waterfront UK did not have the necessary skills in-house and was relying on Andersen Consulting to implement R/3 and integrate the ERP with an automated warehouse system from Horizons. Although at the height of the project there were over 50 consultants at Waterfront UK, many of them were inexperienced and turnover was high. Critics have however blamed the company for this, as top management disagreed on whether to train and retain the current employees or hire an entirely new skilled work force. Whilst the vice-presidents were in favor of the former, the president was in favor of the latter. As a result, rather than focusing on in-house training while the implementation took place, Waterfront UK employed the services of software giant vendor SAP supported by Andersen, it is reported that they however used trainees for the implementation and the perception of senior management afterwards that they felt being used as a "training ground" for "consultants who were very inexperienced". Similarly Waterfront UK claimed that SAP treated it like "its own research and development guinea pig".
Page 41 of 66
Its labor problems exploded when workers began leaving their jobs en masse from six of its Nigerian warehouses, which were scheduled to be replaced by the automated Accra centre, because of a "debilitating morale problem among departing workers, a lot of merchandise was dumped into trucks and arrived at Accra court house with packages damaged or broken open or otherwise unsalable as new product, [resulting in] a huge shrinkage in inventory" [41]. 4.4 Application of Change Management Models 4.4.1 Levels of Culture: Values Organizational Structure The organizational structure at Waterfront was the hierarchical / distributed structure, whereby key decisions are made by the president and a few at top management. IT is distributed across all the different departments as illustrated in figure 1 below. The company prides itself in its empowered unit entity, which has been a benchmark for success is to promote competence and creativity through separate departments and units. Operating as a separate business entity will afford the unit manager the opportunity to develop a distinctive strategy for each department, which has a better chance to offer competitive packages, encourage product differentiation and offer entrepreneurial freedom.
Figure 5: Distributed organizational structure As shown from the research, functional testing of software can be achieved either manually or automatically. The two approaches are complementary; automated testing can perform a large number of tests in little time, whereas manual testing uses the knowledge of the testing engineer to target testing parts of the system. 4.4.2 Levels of Culture: Assumptions & Artifact
Page 42 of 66
Observed Norms & Rituals - The biggest challenge to the project was selling process changes to the lines of business. Therefore, the project started with an emphasis on training. Waterfront offered an eight - week knowledge transfer course on the new system. Due to the past culture of independence and isolation of each department, the company also offered cross-functional training. The goals were to reduce the isolation of each of the various areas such as finance and engineering, and to help each to understand the impact of any change made by one department on the other department. 4.4.3 Lewins Change Model 4.4.3.1 Unfreezing Communication (internal PR) - In order to overcome resistance to change, the initiators had to communicate the rationale behind the change, mainly through the internal public relations network, creating awareness among members of staff at all levels. Top management commitment A supportive role from top management and positive leadership commitment was a catalyst for influencing all other members of staff to facilitate the change. With the committed leadership they are were more likely to commit the resources and be actively involved in monitoring the change by talking to staff, investing sufficiently, propelling the drive, introduce initiatives, and enthusiasm which will serve as an inspiration to other members of staff. Participation Another useful strategy was getting a but-in and full participation from other members of staff across the organisation, carefully explaining the benefits of adopting the change. This also included involving more senior managers by delegating their roles in both the communication process and the eventual success of the project. Divers methods (fun) A lot of different ways were employed to achieve this communication process, and part of its objective was to make it fulfilled, in order to establish a perception of an enjoyable process. 4.4.3.2 Moving The second stage in addition to driving the necessary change was to move it to a different level. This was achieved through capitalizing on the current acceptance to generate compliance and support. Some of the key challenges included;
Page 43 of 66
De-emphasizing Interregional Challenges - The toughest challenge was breaking down local cultures, according to Jill Olly: wading through politics and inter-regional suspicion required positive leadership from the C.E.O down to the unit managers. It wasnt painless. On the approach used he says: we had to sufficiently educate and communicate what was coming. People dont believe change is happening until it arrives. Unified Organizational Structure - The proposed organisational structure at Waterfront after the introduction of the CFBP was to be a matrix (centralised) system whereby information is integrated across the organisation eliminating complex links between the company systems in different units. Discrete business process and information from all the departments in Europe were integrated and stored in a single comprehensive system, where they can be used by other parts of the organisation. Waterfront achieved most of this process by transferring the Waterfront UK SAP R/3 programme, by modifying it to include SAP R/3, Microsoft office application and e- mail. Sadly the key initiator of this plan was sacked two weeks after for daring to challenge the status quo.
Figure 3: Cross-functional nature of the CFBP 4.4.3.3 Refreezing According to Lewins theory, the third stage aims to lock in the new change process so that it becomes part of the norms. The steps taken in this regard included; Secondment Training Initial training of staff on the new system was initially achieved by temporarily bringing staffs from the supplier to help operate the system pending the time internal employees got used and became familiar with the new system. In Built System Team Oriented Approach One of the benefits of the training programme and in-built functionality of the system, is that it created a working
Page 44 of 66
environment, which encouraged employees including the unit managers across its operations to work together without disunity. This was a deliberate approach as the system was designed to support a team approach, as all the units had to work from one repository and then share information across its units. 4.5 Conclusion From the case study and other sources of research, it can be concluded that utilizing Lewin and Scheins theories on change management is a good means by which to begin to grasp the many dimensions of change management, how it can be utilized to reduce the effects of organizational culture on IS project implementation. Whilst the transition process adopted by Waterfront started off with lots of aims and potential, however this was not sincerely and vigorously adopted by top management. This was evidenced in the non-implementation of the programme in the Far East and African operations due to economic reasons, coupled with the hiring of 380 workers in less than 24 months only to politely reduce the workforce by approximately 1/3 of this less during the following six months. Clearly, for a firm to be in vigorous pursuit of such change management strategies and have even the thought of hiring that many workers while retraining all the rest, seems to be, particularly in hindsight, fraught with incompetence and excessive risk.
Page 45 of 66
Chapter 5
Discussion of Findings
5. Summary of Research Results This concluding chapter of the individual project will look at what extent each of the individual objectives for the project was achieved and to what extent the aim of the individual project has been accomplished. It will then critically evaluate the project to find any weaknesses in the research and the methods used. It will then finally draw on the findings from the primary research and the secondary research and it will make an overall conclusion of this study. The second section discusses the relevance of Lewin/Schein change process model as a basis of understanding IS project implementation in Waterfront UK. 5.1 Secondary Research: Objectives 5.1.1 Concept of Culture and Organizational Culture The literature review provided a good grounding of knowledge to enable the researcher to understand the subject area and the key issues surrounding it. The research papers presented a definition of culture and a general map of organizations culture was presented. Based on the researched evidence from different authors, it is my opinion that culture has a strong cognitive element in that organizational culture guides the ways of conduct and behavior of the employees, and sets priorities to goals, approaches, and processes, thus affecting their work performance and practice. 5.1.2 Various cultural and organizational problems expected during IS project implementation The authors opinion on the various cultural and organizational problems expected during IS project implementation was very much backed up with lots of evidence from a number of IS implementation projects, which include; the national probation service IT project (CRAMS), and the business process reengineering projects of both the Boeing Company and Ford motor company, are examples of such projects. From the literature and evidence presented, I understand that organisational change incorporates wider factors such as culture, ethics, structure, strategy, management and human resources, the wider environment, and political and socio-economic issues.
Page 46 of 66
5.1.3 Change Process Models & IS Implementation Activities The research papers introduced me to a number of concepts, theories and frameworks. It has increased my knowledge on change management and culture, through the use of change management theories I was able to understand the practicality of the analytical tools which I demonstrated in the case study and primary research data. They are a good method to substantiate the findings of past and present research but very unhelpful for predicting the future. I also understood that management of change can be a continuous transition and at times hard to achieve. 5.1.4 Overall Comments on Secondary Research As always with researching literature the subject areas of culture / organizational culture, change management / IS implementation activities was vast and it was difficult to define a boundary to where the scope of the research should stop, but it was felt that all the research carried out was relevant to each of the project individual objectives. 5.2 Primary Research The primary research was used to explore the opinions of employees of Waterfront UK, who heavily interacted with and understood CFBP implementation project and the cultural effects. The research method used for the primary research was a set of one-to-one, semi structured interviews with open ended questions. Each of the interviewees was selected due to their knowledge of the CFBP system and their heavy interaction with it. This research revealed some very intriguing findings which were backed up with academic research in the literature review, these covered objectives one to four which I have stated below. 5.2.1 Implementation Planning SDLC / Traditional vs Adaptive Software Development The findings of the case study was in line with the literature reviewed, as Mahoney (2000) and Lytinen (1999) had argued that most times customers are not fully aware of their requirements at the start of a project, hence project teams should not continue with the sole use of the traditional planned driven requirements planning methods such as the PRINCE2, Waterfall model etc, this is in order to accommodate the changing customer requirements at different stages of the project lifecycle which is inevitable, as these methods which are currently
Page 47 of 66
been used for high profile projects are not designed to accommodate the changing needs in customer requirements e.g. it can be observed from the CFBP project at Waterfront UK that there were frequent changes in the requirements all through the different stages of the project especially with the receipt of orders which needed to be mass produced, and attempts to introduce changes midway were fraught with difficulties and eventual failure of the project. 5.2.2 Implementation Strategy The findings of the case study was in line with the literature reviewed, as Greer (1999) had argued for the use incremental and phased software releases (as opposed to the big bang approach) as the best approach during IS project implementation, as this would ensure the smooth running of the Business whilst implementation is going on [45], as the evidence from the case study went on to suggest that the plan backfired costing the company $25million in sales all the while the systems were down. On hindsight, a phased implementation would have been less risky and would have given the implementation team a chance to test transaction throughput more thoroughly. 5.2.3 Stakeholder Management / Project Sponsorship Employees - Although senior management commitment was high, reports reveal that some users were not as committed. In fact, there was a definite morale problem among the warehouse employees. This was not surprising, since the project's Horizons warehouse automation integrated with SAP R/3 threatened their jobs. With the closing of three warehouses, the transition to the first automated warehouse was a disaster. Disgruntled workers damaged inventory, and orders were not filled, and mistakes occurred as the new system struggled with the volume of transactions. $34 million worth of inventory were lost. This finding is backed up by my previous literature research into the cultural problems in organizations and how it affects IS projects. In chapter 3 (page 23) I had cited a finding by the author Carr (2004), where he stated that the fear of job losses, loss of routines by employees was one of the reasons behind the failure of project everest, as employees felt threatened and made sure the project was killed off. Senior Stakeholders - The findings of this case study was in-line with both the field studies and literature which suggest that a proven strategy for getting commitment among senior managers was to adopt a top-down approach to get the support first of all of the top managers and then their immediate subordinates and all those involved in the implementation [28, 31, 38]. First, it is because end-users are much more prone to act when their senior managers were interPage 48 of 66
ested in the outcome. Second, the capital sources required for the implementation to take place were increased significantly. However, if senior managers were only lukewarm in their support, the probability of the system not being implemented was high. Although the company started off well in this regard by appointing a vice president to get overall support for the project, however that was short lived as the companys hierarchical structure hindered meant that it was only a matter of time before his authority was undermined by the president. 5.2.4 Training The findings of this case study is consistent with the literature review on training, as Wilson et al (1990) states that training employees pre and post IS implementation ascribes a sense of ownership and end-users will become independent and successful through the transfer of expertise and the company will in the process avoid a low morale build up which usually arises during post implementation projects. This evidence of losses as a result of not adopting this approach was so glaring as the company had to depend on software vendors to operate the install and operate the system post implementation, and they took full advantage of their ignorance by bringing in unskilled consultants who helped exacerbate the problem. And the more hideous outcome was when workers began leaving their jobs en masse from six of its Nigerian warehouses, which were scheduled to be replaced by the automated Accra centre, because of a "debilitating morale problem among departing workers, a lot of merchandise was dumped into trucks and arrived at Accra court house with packages damaged or broken open or otherwise unsalable as new product, [resulting in] a huge shrinkage in inventory
Page 49 of 66
Chapter 6
Conclusion
Research Papers - My justification in choosing the research papers, is that for each paper that was of interest (i.e. covering software testing in general or manual & auto software testing in particular), by limiting my search to twenty years, there is a high probability that techniques which have been published before this date, and have made an impact, are likely to be established and thus published in text books. Functional Manual And Automated Testing Going through the Standish Group, CHAOS 2001: A Recipe for success, [122] revealed that from 1999 till date, a total of $3 billion had been spent on functional testing practice by organizations. This ranged from investments in automated tools and hiring of personnel for manual testing. However, despite this huge investment, most organizations still suffered quality issues as a result of in effective inconsistently applied functional testing practice. Hence my interest in this area, which was mainly to assess the use of both manual and automated techniques in the practice. This assessment was however concluded after submission of my extended project proposal. As at the time of submission of the project proposal, I had chosen automated and manual software testing, but was still not decided on the choice of practice whether functional or structural. Waterfront Consultants Case Study - With regards to my choice of commercial software as part of my case study, I was more interested in getting the perspective from users and developers of software as an addition rather than relying solely on academic journals whose experiments may be some worth limited. Methodology The reason for my choice of action research methodology, is due to my intention to carry on further research and improvement of this problem area, whilst engaging in continuous research study, this is in consonance with the aims of the methodology which is neatly augments the academic aspects of research in general with real-world relevance. In addition, the methodology
Page 50 of 66
supports carrying out research through a four-step process which best suited the structure of this thesis. 6.4 What Has Been Learned Project Management Skills I have learnt a great deal from the benefits of having a good structure in place while developing a project. At the start of semester C I outlined a time schedule of when and how each stage of the project would be implemented, this was submitted with the extended project proposal. This was followed and revised as needed and above you can see the first progression of the schedule version of events. Previously this was virtually absent in my life, I have never known what it takes to plan and have a schedule in place, and this meant that I was always behind schedule in every area of my life. Planning, implementation and achieving results Being the first independent stand alone project I am undertaking for my masters degree, I usually find it difficult studying independently without being in a teaching environment. But in working on this schedule, I was solely responsible in formulating, outlining and provision of all the milestones achieved thus far for the project. From the feasibility study, to the analysis stage and the confidence to actually believe in my abilities to carry out this project of such magnitude, this I consider a huge achievement. My achievement from the planning and implementation stages for this masters project include; My proven ability to work alone with the same level of motivation as being part a of a team, When left unsupervised I can be relied upon to be well disciplined and highly responsible, And have cultivated a good reputation for meeting deadlines (This is unbelievable for Fredrick to meet deadlines) Communication Skills and Persistence - Topic Research / Audience With IT Directors In researching similar and existing systems, I have had to take a bold step in speaking to and making enquires from companies that have already implemented similar systems. This process was not as smooth as expected, most times it involved having to manage constant rejections and humiliations from such companies, incur lots of cost in trying to obtain information. But my persistence paid off and I can confidently outline what I have learnt from this experience, which includes; strong interpersonal skills, Quick initiative and a strong persuasive and influential approach Resilience and problem solving Skills - The biggest problem that I faced throughout this schedule was the lack of available time to work on the project. For the majority of the time I was working on the college system, and this restricted me to only really working during college hours. And during this period I lost my mentor. Whilst I was bugged down with sorrow, pain and lots of hardship, I thought about quitting and asking for a long extension, but due to the pressure I became used to as a result of writing this project, I found I was
Page 51 of 66
able to look inwards and found strength to complete the project without having to rely on an extension. 6.5 Conclusion Manual testing and automated testing are really two different processes, rather than two different ways to execute the same process. Their dynamics are different, and the bugs they tend to reveal are different. Therefore, direct comparison of them in terms of dollar cost or number of bugs found is meaningless. Therefore, software testing is characterized by the existence of many methods, techniques and tools that must fit the test situation, including technical properties, goals and restrictions. There is no single ideal software testing techniques for assessing software quality. Therefore, we must ensure that the testing strategy is chosen by the combination of testing techniques at the right time on the right work products. 6.6 Future Work This thesis generates more questions than it answers and opens more doors for investigation than it closes. Example of an open question is how much of the application was exercised to get that result? For example, if a manual functional test finds 10 issues while covering 5% of its functions susceptible to vulnerabilities, that inspires a very different level of confidence than if the 10 issues where discovered while covering 80% of the functions using automated testing. Recent research from IBM has shown that it is possible to design a manual test case for a business process testing software, so that both manual and automated testing can be carried out on the same component and with the same process. To achieve this, test engineers can use WinRunner software or QuickTest Professional software to automate the existing components. This will form part of my analysis as I apply for my PhD.
Page 52 of 66
Bibliography
1 Heilpern, Jeffrey and David Nadler. 1992. Implementing Total Quality Management: A Process of Cultural Change, in Organizational Architecture. San Francisco: Jossey-Bass. Argyris, Chris, and Donald Schn. 1974. Theory in Practice. San Francisco: Jossey-Bass. Bell, J. (1999) Doing Your Research Project: A guide for first-time researches in education and social science. 3rd ed. Philadelphia, Open University Press. Yin, R. K. (1994) Case study research: Design and methods. 2nd Edition. California, SAGE Robson, C (2002) Real world research: 2nd Edition. Oxford, Blackwell Publishers Ltd. Sapsford, R. J. Evans, J. (1984) Evaluating a research report. London, Harper and Row. Hart, C. (2001) Doing a literature search. London, Sage. Arksey, H. Knight, P (1999) Interviewing for social sciences: An introductory resource with examples. London, Sage Publications. King, N. (1994) The qualitative research interview. London, Sage. Denzin, N. K. (1970) The research act in sociology: A theoretical introduction to sociological method. London. Butterworths. Jick, T. D. (1983) Mixing qualitative and quantitative methods: triangulation in action. London. SAGE Publications. Denzin, N. K. (1989) The research act: A theoretical introduction to sociological method 3rd edition. London. Prentice Hall. Fielding, N. G. Fielding, J. L. (1986) Linking data. London, SAGE Publications. Charles Handay (1993) Understanding Organizations, Penguin Books Schein, Edgar. 1992. Organizational Culture and Leadership, Second Edition. San Francisco: Jossey-Bass. PENDEGRAFT, N. (1996) Cultural analysis. Journal of Systems Management, April 1996, p14
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Page 53 of 66
17 18 19
RUGMAN & HODGETTS (2000) International Business: a strategic approach. 2nd ed., Prentice Hall THOMPSON A, JR. & STRICKLAND, A., J. (1999) Strategic management concepts and cases, 11th edition. Irwin McGraw-Hill. MA USA GOODSTEIN, L, D. & WARNER BURKE, W. (1993: pp.164) Creating successful organisational change. In Mabey, C. & Mayon-White, B. (ed.) (1993) Managing Change, 2nd edition., Open University, Paul Chapman Publishing: London HOFSTEDE, G. (1991). Cultures and organizations: Software of the mind. London: McGraw-Hill RIDGEWAY, C & WALLACE, B. (1997) Empowering Change. Exeter, Short Run Press Eason, K. D. (1988). Information technology and organisational change. London: Taylor and Francis. JOHNSON, J & SCHOLES, D. (1999) Strategic management. London, Prentice Hall Baker, P. (1998) Electronic Commerce Research Report 1998. KPMG Management Consulting CASEY, M. (1999) The true challenge in the DaimlerChrysler merger. Washington Post (31 March 1999) http://washington-post.com/newspress (Accessed April 25, 2004) INVESTOR RELATIONS (2000) DaimlerChrysler Story http://investor.org/98reports (Accessed 23 April, 2004) The National Audit Office (April 2001) The Implementation of the National Probation Service Information Systems Strategy. [WWW document]. URL http://www.nao.org.uk/publications/nao_reports/00-01/0001401.pdf Report by the Comptroller and Auditor General Nicholas. G. Carr (April 2004) Does IT Matter? Information Technology and the Corrosion of Competitive Advantage. Harvard Business School Press; 1st edition. LEWIN, K. (1952) Field Theory in Social Science. London: Tailstock.
20 21 22 23 24 25 26 27
28 29
30 31
Argyris, Chris, and Donald Schn. 1987. Organizational Learning in Pugh, DS, Organization Theory: Selected Readings (Harmondsworth, Penguin) Pinto, J. K. (1998). Project management handbook: the project management institute. San Francisco: Jossey-Bass.
Page 54 of 66
32 33 34 35 36 37 38
Hutchins, H. A. (1999). Seven key elements of a successful implementation, and eight mistakes you will make anyway. Hospital Materiel Management Quarterly, 21(2), 76-82. Bingi, P., Sharma, M. K. and Godla, J. (1999). Critical issues affecting an ERP implementation. Information Systems Management, 7-14. Fitzgerald, G., Philippides, A. and Probert, S. (1999). Information systems development, maintenance and enhancement: findings from a UK study. International Journal of Information Management, 19, 319-328. Nah, F. F. and Lau, J. L. (2003). Critical factors for successful implementation of enterprise systems. Business Process Management, 7(3), 285-296. Kuruppuarachchi, P. R., Mandal, P. and Smith, R. (2002). IT project implementation strategies for effective changes: a critical review. Logistics Information Management, 15(2), 126-137. Glover, H., Watson, H. J. and Rainer, R. K. (1992). 20 ways to waste an EIS investment. Information Strategy: The Executive Journal, 8(Winter), 11-17. Ang, J. S. K., Sum, C-C. and Yeo, L-N. (2002). A multiple-case design methodology for studying MRP success and CSFs. Information & Management, 39, 271-281. Budic, Z. (1994). Effectiveness of geographic information systems in local planning. Journal of American Planning Association, 60(2), 244-263. The Standish Group, CHAOS www.standishgroup.com, 2001.
39 40 41 42 43 44 45
2001:
Recipe
for
success
Implementation Insight (2002) Project CFBP. [Video VHS] Waterfront Media Archives. Implementation Insight (2002) Project CFBP. [Video VHS] Ford Media Archives. John Pollatto (August 2004) Ford Shelves Oracle-Based Procurement System. [WWW document]. URL http://www.eweek.com/article2/0,1895,1638160,00.asp Mahoney, J (2000): Identify misaligned roles that cause project failure, Gartner, TechRepublic. Project Management 1 Readings, Australian Computer Society Lytinen, K. Robey, D. (1999). Learning Failure in Information Systems Development: Info Systems J. 9, 85-101 Greer, M (1999): 14 Key Principles for PM Success, excerpt from Chapter 6, Handbook of Human Performance Technology. San Francisco, Jossey-Bass Press, Included in the Project Management 1 Readings, Australian Computer Society Wilson. D.C & Rosenfield R.H, (1990) Managing Organisations McGraw hill Limited
46
Page 55 of 66
47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62
Alavi, M. and Joachimsthaler, E. A. (1992). Revisiting DSS implementation research: a meta-analysis of the literature and suggestions for researchers. MIS Quarterly, March, 95-116. Allison, I. K. (1996). Executive information systems: an evaluation of current UK practice. International Journal of Information Management, 16(1), 27-38. Ang, J. S. K., Sum, C-C. and Yeo, L-N. (2002). A multiple-case design methodology for studying MRP success and CSFs. Information & Management, 39, 271-281. Barrow, C. (1990). Implementing an executive information system: Seven steps for success. Journal of Information Systems Management, Spring, 4146. Bingi, P., Sharma, M. K. and Godla, J. (1999). Critical issues affecting an ERP implementation. Information Systems Management, 7-14. Boland, R. J., Jr. (1978). The process and product of system design. Management Science, 24(9), 887-898. Budic, Z. (1994). Effectiveness of geographic information systems in local planning. Journal of American Planning Association, 60(2), 244-263. Campbell, H. J. (1992). Organisational issues and the implementation of GIS in Massachusetts and Vermont: some lessons for the United Kingdom . Environment and Planning B, 19(1), 85-95. Chan, C. and Swatman, P. M. C. (1998). EDI implementation: a broader perspective. Proceedings of the 11th International Conference on Electronic Commerce, Bled, Slovenia, 90-108. Churchill, G. A., Jr. (1995). Marketing research: methodological foundations (6th ed.). Fort Worth: Dryden Press. Davis, G. and Olson, M. H. (1985). Management information system conceptual foundations, structure and development, (2nd ed.). New York: McGraw Hill. DeSanctis, G. (1984). A micro perspective of implementation. In R. L. Schultz and M. J. Ginzberg (eds.), Applications of Management Science Supplement (pp. 1-27). Connecticut: J. Press. Easterby-Smith, M., Thorpe, R. and Lowe, A. (2002). Management research: an introduction. London: Sage Publications Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14(4), 532-550. Eva, M. (2001). Requirements acquisition for rapid development. Information & Management, 39, 101-107. applications
P., Gronhaug, K. and Kristianslund, I. (1995). Research methods in business studies: a practical guide. New York: Prentice-Hall.
Page 56 of 66
63 64 65 66 67
Ginzberg, M. J. (1981). Key recurrent issues in the MIS implementation process. MIS Quarterly, June, 47-59. Gottschalk, P. (1999). Strategic information systems planning: the IT strategy implementation matrix. European Journal of Information Systems, 8, 107-118. Gummesson, E. (1991). Qualitative methods in management research. London: Sage Publications. Hong, K-K. and Kim, Y-G. (2002). The critical success factors for ERP implementation: an organisational fit perspective. Information & Management, 40, 25-40. Huxhold, W. E. and Levinsohn, A. G. (1995). Managing Geographic Information Projects. New York: Oxford University Press. Huxhold, W. E. and Levinsohn, A. G. (1995). Managing Geographic Information Projects. New York: Oxford University Press. Hutchins, H. A. (1999). Seven key elements of a successful implementation, and eight mistakes you will make anyway. Hospital Materiel Management Quarterly, 21(2), 76-82. Innes, J. E. and Simpson, D. M. (1993). Implementing GIS for planning: Lessons from the history of technological innovation. Journal of American Planning Association, 59(2), 230-236. Jessup, L. and Valacich, J. (2003). Information systems today. New Jersey: Prentice-Hall. Jiang, J. J., Klein, G. and Balloun, J. (1996). Ranking of system implementation success factors. Project Management Journal, December, 49-52.
68 69 70 71
Page 57 of 66
Appendix A
Test Results: Waterfront Consultants
Page 58 of 66
Appendix B
Screen Shots For Error Reports: Waterfront Consultants Screen Shot: Manual Testing Error Report Remark: No Data found in the page Cost of Goods Sold Detail by Invoice
Page 59 of 66
Remark: DBI for receivables summary does not match revenue detail by invoice
Page 60 of 66
Remark: Sizzle Demo Data Configurator Request completes with error
Page 61 of 66
Screen Shot: Automated Testing Error Report Remark: When select template to use for time entry get fatal error
Page 62 of 66
Remark: Java Null error when submitting timecard and viewing timecard in SS
Page 63 of 66
Appendix C Project Progress Reports 1-3

Project Progress Report1
Work completed since last report
Abstract Chapter 1: Introduction - Problem definition & goal, motivation, report structure Chapter 2: Software Testing Techniques Manual testing techniques, automated testing techniques, benefits, constraints Testing tools Chapter 3: Literature Review - Introduction,
What I have learnt
Project Management Skills I have learnt a great deal from the benefits of having a good structure in place while developing a project. At the start of semester C I outlined a time schedule of when and how each stage of the project would be implemented, this was submitted with the extended project proposal. This was followed and revised as needed and above you can see the first progression of the schedule version of events. Previously this was virtually absent in my life, I have never known what it takes to plan and have a schedule in place, and this meant that I was always behind schedule in every area of my life.
Problems encountered and impact of these on schedule
One of the main problems that we encountered during the course of the project was having access to software testing fault reports at the right time. Initially the companies who promised me software faults data had given me a date of Thursday 21st June 2007. However, the date was postponed until Monday 25th June 2007. This was a draw back in that I am a week behind on my schedule, restricted in what I am submitting today and had to spend extra time in research, sleepless nights in order to meet this deadline
Work to be done over next period
Chapter 3 Part 1: Literature Review - Manual Test Techniques And Test Levels, Automated Test Techniques And Test Types Chapter 3 Part 2: Literature Review - Test Infrastructure And Environment, Test Strategies Chapter 4: Methodology - Case Study Under Review, Background System Set Up, Review of Functional Scope, Review of Test Strategy
Page 64 of 66
Project Progress Report 2
Chapter 3 Part 1: Literature Review Methodology, Definitions used, Software testing and Manual Software testing, Software testing and Automated Software testing, Test Levels, Test Types, Test Infrastructure And Environment, Test Strategies
What I have learnt
Planning, implementation and achieving results Being the first independent stand alone project I am undertaking for my masters degree, I usually find it difficult studying independently without being in a teaching environment. But in working on this schedule, I was solely responsible in formulating, outlining and provision of all the milestones achieved thus far for the project. From the feasibility study, to the analysis stage and the confidence to actually believe in my abilities to carry out this project of such magnitude, this I consider a huge achievement. My achievement from the planning and implementation stages for this masters project include; My proven ability to work alone with the same level of motivation as being part a of a team, When left unsupervised I can be relied upon to be well disciplined and highly responsible, And have cultivated a good reputation for meeting deadlines (This is unbelievable for Fredrick to meet deadlines)
With this phase of the project I revised the schedule in many different ways due to different reasons. For example some of my original estimates were not very accurate, as I had to revise certain aspects of my topic especially in chapter 2. This was done in response to feedback from my second marker. In addition, some of the tasks took longer than expected, this is because the some of topics in this schedule, were better suited to be done with the companies, as it involved interpreting company data and briefing me on some of the confusing aspects of the documents. This involved booking appointments to see the members of staff at a very busy period.
Chapter 4: Methodology - Case Study Under Review Background System Set Up, Review of Functional Scope, Review of Test Strategy Chapter 5 Part 1: Evaluation of Test Reports - Software Test Results, Analysis Chapter 5 Part 2: Evaluation of Test Reports Interpretations And Observations,
Page 65 of 66
Project Progress Report 3
Chapter 4: Methodology - Case Study Under Review, Background System Set Up, Review of Functional Scope, Review of Test Strategy Chapter 5 Part 1: Evaluation of Test Reports - Software Test Results, Analysis Chapter 5 Part 2: Evaluation of Test Reports Interpretations And Observations
What I have learnt
Communication Skills and Persistence - Topic Research / Audience With IT Directors In researching similar and existing systems, I have had to take a bold step in speaking to and making enquires from companies that have already implemented similar systems. This process was not as smooth as expected, most times it involved having to manage constant rejections and humiliations from such companies, incur lots of cost in trying to obtain information. But my persistence paid off and I can confidently outline what I have learnt from this experience, which includes; strong interpersonal skills, Quick initiative and a strong persuasive and influential approach
My mentor in the UK, Mrs Ifeanyinwa Irukwu died of breast cancer. This delayed my project for two weeks as I was forced to relocate to Birmingham temporarily and due to the cost, public transport was not affordable, and as a result did not have access to the universitys facilities.
Chapter 5 Part 3: Final Recommendation Chapter 6: Conclusion Conclusion, Justification, Achievement vs Planned Work, Critique, future work, Bibliography And Reference, Appendix
Page 66 of 66

BSC Is Project

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BSC Is Project

Hochgeladen von

Copyright:

Verfügbare Formate

BSc_IS_Project By S.

Samina Student ID XXXXXX

BACHELOR OF SCIENCE IN COMPUTING MODULE ID - XXXXXX Project Report

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

IMPLEM & QUAL TEST

TIME Requirements Design Acceptance Testing Implementation Other

Qual & Sys Testing

BSc_IS_Project By S. Samina Student ID XXXXXX

Most appropriate when ...

BSc_IS_Project By S. Samina Student ID XXXXXX

Most appropriate when ...

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

Figure 5: Stages in the waterfall model

Summary description and discussion

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX

BSc_IS_Project By S. Samina Student ID XXXXXX