ORGANIZATIONAL IMPACT ON PROJECT MANAGEMENT IN FINANCIAL DATA WAREHOUSING: A CASE STUDY
    Räkers, Marc, zeb/information.technology, Schlossstr. 22, 48455 Bad Bentheim, Germany, marc@raekers.com Rosenkranz, Christoph, University of Frankfurt, Mertonstr. 17, 60325 Frankfurt, Germany, rosenkranz@wiwi.uni-frankfurt.de
    
    Abstract
    Today s financial industry is fundamentally based on information technology. Most companies, especially banks, run data warehouses to achieve an integrated view on their whole business. These financial data warehouses have to cope with very different kinds of information provided by each business unit. As banking product portfolios are subject to frequent changes and warehouse requirements are enhanced permanently due to supervisory guidelines and internal reporting needs, data warehouse projects have to master various challenges over time. In order to obtain resilience, the organizational structure of data warehouse projects has to be aligned to team members roles, skills and required communication channels. We describe how communication problems can be identified by using the Viable System Model and examine how communication between project stakeholders influenced a project in an exemplary case study. We illustrate that the management of financial data warehouse projects has to deal with complex problems of knowledge transfer due to a gap of mutual understanding between project members from business and IT departments. Keywords: Project Management, Viable System Model, Financial Data Warehousing, Organization, Communication.
    
    1
    
    INTRODUCTION
    
    As organizations invest greatly in information technology (IT) in order to improve their operational and strategic position, information systems (IS) play an ever-increasing role in today s organizations and society (Laudon and Laudon 2005, p. 7). The interaction between IT and organization is very complex and influenced by many mediating factors, including the organization s structure, standard operating procedures, politics, culture, environment and management decisions (Laudon and Laudon 2005, p. 77). Banks are especially affected by these changes due to the nature of their marketable products, which are mainly immaterial. Consequently, the production process of a bank mainly consists of information processing, and IT has become one of the main factors of production in banking (Guo, Tang, Tong and Yang 2006). In order to cope with complexity, IS are often developed in the form of structured approaches (Hirschheim, Klein and Lyytinen 1995, p. 33). Projects are a structured set of activities concerned with delivering a defined capability to an organization based on agreed schedule and budget (Ribbers and Schoo 2002, p. 45). Complex IS development projects (ISDPs) are large scale projects with a significant and complex software component (BCS 2004, p. 7; Xia and Lee 2005). ISDPs are inherently complex because they must deal with both the technological issues and also the organizational factors that, by and large, are outside of the project team s control (Xia and Lee 2005, p. 46). Consequently, the complexity of IS development manifests itself in the high failure rate of ISDPs (BCS 2004; SGI 2001). But despite ongoing research into e. g. ISDP complexity (Xia and Lee 2005), the role of escalation in ISDPs (Keil 1995; Keil, Mann and Rai 2000) and project management in general (Kuntz, Christiansen, Cohen, Jin and Levitt 1998; Levitt 2004), there has not been much interest in the role of communication and coordination for ISDP success. In this paper, we examine the organizational impact of the communication behaviour on project success in a large implementation project within the European financial industry. Especially large banking groups with foreign subsidiaries have to deal with new regulatory demands, e. g. Basel II, IFRS or Sarbanes-Oxley Act. Therefore, one of the leading Austrian banks put up a multi-million dollar data warehouse ISDP together with a consulting company in order to fulfil the Basel II requirements specified by the local banking supervision authorities. Because the necessary adjustments influenced not only IS but also changed the daily business, all departments of the bank were involved in this project. The presented case is typical for recent projects in the financial sector. In addition, as the bank was in a post-merger situation and was the target of an acquisition during the project, the ongoing consolidation process in the banking industry is considered as well. In this context, the following questions were of special interest for our research: What information and communication problems did occur in the ISDP and what actions were taken to overcome these obstacles? Which are the major points of conflict with regard to communication within the ISDP? How should we organize internal communication and what kinds of communication should be used to become more effective within ISDPs? In order to develop a better understanding of the organization of a large ISDP and the demands for the involved managers and employees, we examine the explicit predetermined information and communication channels (e. g., meetings, requirements specifications and reports), but also take a look at informal communication behaviour, using additional information from project members. The remainder of the paper is structured as follows. The theoretical base for the research is discussed in the second section covering literature contribution. In addition, to conceptualize the organizational setting at the Austrian bank, we introduce the Viable System Model. Within the third section of the paper, the case is introduced. The fourth section of the paper applies and analyzes the case study in terms of the Viable System Model. We show why the Viable System Model is appropriate for analyzing communication problems and information channels within organizations. The final section summarizes the findings of the paper and draws conclusions for the research.
    
    2
    2.1
    
    RELATED WORK
    Information Systems Development Projects
    
    There are a lot of reasons for data warehouse projects to fail, when risks become problems (Adelman and Moss 2001) and known success factors are not met (Hwang, Ku, Yen and Cheng 2004; Wixom and Watson 2001). For example, one of the main tasks in data warehousing is to keep the ETL (extraction, transformation and loading) process running. Looking at the overall costs of a data warehouse project, the costs incurred by the ETL process have a major share (Kimball and Caserta 2004). The maintenance of the interfaces, transformations and load processes needs high-skilled employees capable of a lot of knowledge regarding the companies system environment, business needs and general data warehouse skills. This demand is a major problem for companies: data warehouse specialists are high-skilled and expensive professionals. A lot of companies cannot or do not want to afford an expensive specialist over time. On the other hand it is also quiet problematic to depend on a single specialist regarding such a vital system. Obviously, there must be a transfer of knowledge in order to educate other employees in tasks that are needed for daily data warehouse maintenance. In the end a data warehouse project is a special ISDP project. With regard to communication, according to Keil et al. (2000), escalation occurs in ISDPs especially if negative information and bad news are ignored or downplayed. Following Montealegre and Keil (2000), the de-escalation process that follows such behaviour is a complex, emergent process in which solutions emerge as managers begin to understand the problems. While de-escalation is an important process for already troubled projects, research should try to help ISDPs to avoid factors that ultimately lead to problems and escalation. There are a couple of factors influencing successful IS implementations (Yeo 2002). Although the necessary knowledge transfer between project members is identified as a relevant part of the software development process (Levina and Vaast 2005; Robillard 1999), the organizational impact of communication is not subject to recent research. The field in-between knowledge transfer, communication and organization needs further research regarding implementation projects. The relevant questions are closely related to boundary spanning (Aldrich and Herker 1977), i. e. boundary spanners bridge business and IT departments (Pawlowski and Robey 2004). Consequently, the focus of our research lies on the needed communication in given organizational structures of ISDPs to satisfy the observation that projects have to cope with given organizational boundaries. 2.2 The Viable System Model
    
    ISDPs can be analyzed by using many different lenses and points of view. For our research, we employ a systemic perspective and regard ISDPs as complex systems. Conant and Ashby (1970) made the point that in order to regulate (control) a system well, the regulator must work through a model of that system; and a model of a system must model every salient aspect or interesting feature of that system. In fact, this is a restatement of Ashby s Law of Requisite Variety: only variety destroys variety (Ashby 1964, p. 207). Variety is the number of possible states of a system and therefore a subjective measure for complexity. Following the Conant-Ashby-Theorem and the Law of Requisite Variety, for a system (e. g., an IDSP) to remain regulated (controlled), it is vital that the controlling element (the management) has as much variety as the element it is to control. Consequently, from a systemic point of view, the evaluation of management practices, information systems, and information and communication channels respectively all of them serving as variety attenuators and amplifiers becomes of great importance for management to adjust variety accordingly. Each information channel is a twoway communication loop of variety attenuators and amplifiers. Attenuators and amplifiers need to be designed; when they are not designed, they simply occur because Ashby s Law asserts itself (Beer 1979, p. 92).
    
    In order to model and analyze the information channels of an ISDP and to provide a rigorous theory for backup, we propose to apply the Viable System Model (VSM) (Beer 1979; Beer 1981; Beer 1985). According to Beer (1985, pp. 1-16), the VSM specifies the minimum functional criteria by which a given system (e. g., a company, an organization, or a project) can be said to be capable of independent existence. The VSM has its roots in cybernetics and describes the necessary organizational structure that is needed for a system to survive in a constantly changing environment. It consist of six main components (cf. Table 1), or sub-systems, and a set of information channels between the sub-systems. The essential principle for structuring within the VSM is based on recursion: each sub-system needs the same structure as the whole system, each level of organization is a recursion of its super-system (Beer 1979, p. 68). A system is viable if it is able to maintain its configuration over some time. The VSM has been previously applied in various research approaches in management science (e. g., Espejo and Harnden 1989; Jackson 2000). In information systems research, the VSM has been used especially in the context of information systems development (e. g., Kawalek and Wastell 1999; Vidgen 1998). From our point of view, the VSM serves as an underlying theory in order to map the necessary information channels within a project management team, and therefore helps in the process of building a model for controlling and managing the framework of interaction (Britton and Parker 1993). By applying the VSM in our case study, we demonstrate why the VSM is appropriate for modelling information channels and communication within project management teams.
    System System 1 Description On each given recursive level, Operational Divisions are responsible for certain parts of an organization s activities and have contact to the outside environment. The divisions are each managed by a divisional Management Unit. Together, they form an Elemental Organizational Unit. All Operational Divisions and divisional Management Units on one level of recursion together form System 1 (Beer 1979, pp. 94-97). Each System 2 conducts a service function for System 1 (e. g. Finance, Human Resources or IT services), and serves to damp oscillation and disruptions that occur between the divisions on an operational level (Beer 1979, pp. 176-186). System 3 supervises all internal operational activities of all divisions from a higher point of view of the total system. It optimizes the allocation of resources, assigns them to the divisions and regularly checks the use of these resources (Beer 1979, pp. 473-480). System 3* is the audit channel, which gives System 3 direct access to the state of affairs in the operational activities. System 3 can obtain immediate information by using System 3*, instead of relying on information passed to it by divisional management. System 4 deals with the diagnosis of the long-term connection of a viable system to its outside environment and its adaptation to future trends (Beer 1979, pp. 235-240). The ethos of the whole viable system is formed by System 5. It embodies supreme values, rules and norms for the stabilization of the whole system (Beer 1979, pp. 259-264).
    
    System 2
    
    System 3
    
    System 3*
    
    System 4 System 5
    
    Table 1.
    
    Components of a Viable System Model
    
    3
    3.1
    
    FINANCIAL DATA WAREHOUSING
    Research Approach and Data Collection
    
    A CASE STUDY
    
    The overriding concern of our approach is that the research we undertake should be both relevant to the research questions, as set out in the introduction, and rigorous in its implementation. Following this, we focused on how the information systems and information and communication channels at the bank actually worked in practice. In order to satisfy these objectives, we engaged into a case study. From our point of view, it is rather unlikely that a researcher is able to study a phenomenon in its envi-
    
    ronment in-depth by only measuring it without any impact on the phenomenon itself. Walsham (1995, p. 77) notes that the researcher in interpretivist case studies can either take the idealistic role of an outside observer or that of an involved researcher . Even if a researcher views him- or herself as an outside observer, he or she is in some sense acting by influencing what is happening in the domain of action, if only by the sharing of concepts and interpretations with the other actors in the case study site. Therefore, the conducted case study can be described as an action case study (Hughes and Wood-Harper 1999). Since one of the authors was involved as a consultant in a large financial data warehouse project (working as a project field leader of this project), we had full access to all operational processes, information systems, documents and reports of this project. Some of the actions mentioned in this paper were influenced by the author s decisions in the project. In addition, we had complete access to all project documents, project managers and team members of all project stakeholders. We approved our observations by open interviews with other involved team members to gather information from different points of view. Administrative documents (organization diagrams, the project handbook, project plans with estimated budgets, timelines and assigned employees), work descriptions (self-recordings of manager activities), print-outs of project reports from various points in time, interview transcripts and field notes of the researchers were collected in a case study diary (Yin 2003). The collection of the case study data was started in 2007 after the involved author left the management position. The idea to apply the VSM for the interpretation of the project was formed afterwards. We applied the VSM as a theory for matching our interpreted data in order to derive causes of the observed problems and successes. The development of the VSM was the responsibility of one of the authors who reflected on the obtained and interpreted information. The other author provided feedback and critique on the model. 3.2 Case Description
    
    The case study is based on an intensive implementation project that took place in 2006 and 2007 in a large Austrian bank. The trigger for this project was the supervisory requirements known as Basel II. These regulations demand specified risk calculation and risk treatment processes that have an impact on the whole structure of a bank. As these were developed by the Basel Committee on Banking Supervision until 2005 and have slightly adopted been released as an EU directives 2006/48/EC and 2006/49/EC in June 2006, they became law in Austria in 2007. Beside the Basel II project, another large project was established in the same bank. A new major operational system, intended for daily use for most of the bank s employees, was developed and switched productive during the second half of 2006. So nearly every department was involved in two large and important projects at the same time while doing the normal daily work as well. The whole value chain of the bank was touched and partly redesigned. From operational systems over the central group-wide data warehouse to the reporting and supervisory systems, nearly every IS was affected. One major task of the project was to extend the existing data warehouse by detailed data from foreign subsidiaries, to achieve a group-wide view on risk details according to Basel II regulations. Because some of the small foreign subsidiaries only had a few employees, the project staffing was a challenging task for the management. In the end of 2005, the bank decided to take a Basel-II-experienced consulting company as leader into the project and found zeb/ as partner. Within two years, the remaining tasks counting over 40,000 person-days of work had to be fulfilled. Higher management positions where staffed simultaneously by a bank employee and a consultancy manager, to assure that the whole project knowledge remains within the bank after the project has ended and to reach transparency throughout the whole implementation of Basel II. A changing environment partly disturbed the project. Inquiries of the supervising authority made demands on the employees time. Moreover, a further acquisition process stressed the bank s staff. The project organization needs a few clarifying words. Because the realization of Basel II is a large venture, the management of the bank talks about a program instead of a project. Projects are the smallest organizational units within the program. They are let by project bundles, while project bun-
    
    dles themselves are managed by project fields. These fields are subordinated to the overall project management, which itself is controlled by the program management team. By this organizational structure, about 500 single projects within the program for Basel II were supervised (cf. Table 2). While there were a couple of small projects, these little projects where combined by the responsible project manager of the bank if possible.
    Management Unit program management team overall project management project field management project bundle management single project management Subordinated Unit overall project management project field management project bundle management single project management project team members Subunits 1 8 from 4 to 5 from 2 to 95 from 2 to >25 Person-days 40,000 40,000 from 400 to 14,000 from 130 to 5,300 from 1 to 1,100
    
    Table 2.
    
    Hierarchical Order and Size of Management Units
    
    Project fields were managed by project field leaders (PFL). The main relevant project fields (PF) for the case were the PF Business Division, the PF IT Department and the PF Subsidiaries. The partitioning into these project fields matched the bank s organization in order to keep a familiar environment for the bank s employees known from their daily business and other projects. Project bundles were arranged regarding business topics, i. e. Rating and Scoring, Credit Risk, Group Management, Data Management and Roll Out Management. The data warehouse releases containing the efforts for the ETL process where positioned within a project bundle of the PF IT Department. To handle this large program, spending a peak of 550 person-days per week, the overall project management introduced standard project procedures for the lower management levels to be able to consolidate project progress information and keep the program controllable. An important task for every project manager in the beginning of a single project was to negotiate the tasks, timelines and budget with the project bundle management and the project team. Due to the size of the program, the weekly progress reporting was embedded in a reporting procedure based on the bank s mailing and groupware system. The different project levels (field, bundle etc.) discussed the reports, actual problems and taken actions in regular management meetings lasting about one hour. In addition, managers had to conduct operational work to handle emerging problems. This extra time needed for troubleshooting was planned explicitly. Accordingly, the management job was scheduled for two days a week for each manager, and the rest of the week was initially reserved for this operational work. 3.3 Case Analysis
    
    In the following, we employ the VSM to exemplarily sketch and interpret the main findings for ISDP management for the case study. Figure 1 sketches the resulting VSM. At the top right part the Program Management Unit is placed, which consists of the Overall Project Management and the Program Management Team. The managers of this unit were in charge of the whole program and came from the top management level of the involved parties. On the left side of Figure 1, the environment of the organization is shown, being in direct interaction with the organizational units. The main focus lies on the project fields mapped in the centre. Within a project field, the project bundles are plotted, building a recursive interface within the VSM. The sub-systems of the first recursion level are labelled in capitalization (e. g., System 3 as THREE , the overall project management), whereas the second level of recursion uses numbers (e. g., System 3 as 3 , the PFLs). Communication channels between the units are illustrated by directed arrows. The most important channels are transmitting via Systems 2 and 3* as well as the alarm channel. They allow communication between the different recursion levels. The main part of project activity comprised the time period from March 2006 to the middle of 2007. The introduced multi-project organization had to deal with a lot of projects running at the same time
    
    and having wide spread interdependencies. In the later stages of the project, the organizational structure shrunk with the tasks. The project bundle leaders had to control a couple of projects at a time. As project bundle leaders organizationally belong to a project field, there were different project bundle leaders responsible for different phases of the data warehouse development process. Requirements were gathered by the Business Division, while the responsible manager of the IT Department transferred the business requirements to release-specific technical requirements. To ensure a comprehensive information flow on management level between Business Division, IT Department and other involved units (e. g. Systems ONE), the same person was nominated for the role of the project bundle leader by the consultancy (acting as Management Unit on the second recursion level). In our interviews, project bundle leaders from both bank and consultancy mentioned problems with the planned information channels between Business Division and IT Department: Skilled business employees were busy. (22/03/2007, project bundle leader of the bank and team member in the data warehouse project) [In the beginning] there was no transparent communication between business division and IT. (24/10/2007, project bundle leader of the consultancy) Due to high work load in management tasks, sight was lost of the important information channel between business employees and IS developers. The high workload resulted from circumstances external to the project but influencing the project staffing, and requiring permanent replanning, tracking of resources and quality of work. Caused by non-project activities, a couple of times the staffing of bank employees had to be adopted by the managers, which added more tasks to the position than calculated upfront. As there was no formal specification of a permanent direct communication between Business Division and IT Department pertaining to requirements, the exchange of conceptual modelling ideas over time was not really taking place. In addition, business view feedback was given mostly in an individual style: Contents of a release were harmonized by a bunch of emails. (24/10/2007, project bundle leader of the consultancy) Each responsible employee worked slightly different. [...] The cleared release plan had to be changed due to late requirement changes. (22/03/2007, project bundle leader of the bank and team member in the data warehouse project) As a result, there were late requirement changes, which led from human resource shortage to loss of functionality and reduced time for documentation. There were only four employees having insight into the data warehouse from a business point of view. Their task was to design the new releases. After the first release, the PF management of the IT Department insisted on explicit deadlines for business requirements and direct involvement of the Business Division (realizing the need of an explicit System TWO on the first recursion level to coordinate Systems ONE). Having a look on the project organization visualized in Figure 1, it becomes clear that there was no direct formal information channel between PB1-n in Business Division and PB1-n in IT Department. As the final responsibility for arrangements between Business Division and IT Department lay in the hands of the PFLs using System TWO, but communication between the project bundle leaders was needed, there was an intensive use of the operational linkages between Business Division and IT Department. As all software products developed within the Basel II program had direct or indirect connections to the group data warehouse (gDWH), all data requirements showed up in one of four gDWH releases of the program. As there was no person in the Business Division who had a complete overview of the gDWH requirements, the project bundle leaders (Systems 3) were forced to spend much time on coordinative tasks that belong to System TWO, and which were not scheduled. As such, they played a major role in actual requirements engineering and indirectly secured user participation by being part of both Systems ONE. Although the major advantage of the project organization was a direct fit to the banks division structure, the observed communication and coordination problems were evident.
    
    FIVE
    
    Program Management Team
    
    Program Management Unit
    
    Environment Bank Group
    
    Outside and Future
    
    FOUR
    
    Overall Project Management
    
    Environment Business Division Audit (Parasympathicus )
    THREE*
    
    THREE
    
    Overall Project Management
    
    TWO
    
    Alarm Channel (algedonic )
    ON E
    
    5
    
    Project Fields
    4 3* 3
    
    PF L PF L
    
    A: B
    
    us i Div nes s i si on
    
    Network of information channels (Sympathicus )
    
    PF L
    Bu s Di v in es is i s on
    PB 1 PB 2 PB n
    
    Environment IT
    xP
    
    xP
    
    2 R po ertin g
    
    - no formal structure except reporting - informal: PBL discussions
    
    xP
    
    ON E
    
    5
    
    PF L
    4 3* 3
    
    B: IT
    
    De
    
    pa
    
    rtm
    
    en
    
    t
    
    PF L PF L
    
    IT D e
    xP
    
    pa rt m ent
    PB 1
    
    2 R po erti n g
    
    Environment Subsidiaries
    xP
    
    xP PB 2
    
    PB n
    
    ON ON E E
    
    5
    
    4 3* 3
    
    PF L PF L
    
    C:
    
    Su b
    
    s id
    
    i ari es
    
    Legend : PF PB xP P CZ MT
    
    Project Field Project Bundle Multiple Projects (Single) Project Czechia Malta Operational Unit
    
    PF L
    Sub dia s iries
    
    P
    
    2 R po erti ng
    
    Management Unit
    
    always stands for
    
    P
    
    CZ MT .. .
    
    SYSTEM IN FOCUS : project management team Systems on first level of recursion : ONE, TWO, THREE, THREE*, FOUR, FIVE Systems on second level of recursion : 1, 2, 3, 3*, 4, 5
    
    P
    
    Figure 1.
    
    VSM of the projects relevant parts (before March 2007)
    
    In order to give an example for the measurement of the resulting complexity for coordination and communication tasks, we refer back to the concept of variety. Variety is not an intrinsic property of the system, but rather depends on how the observer defines the system (Ashby 1964, p. 125). If different observers of a system distinguish the states or elements of the system differently, then they will come to different measures of variety of the system. But for a concrete case, the abstract concept of variety must be transformed into an applicable and useful measure (Rivett 1977, p. 37). For example, the amount of time of a manager can be considered. Assuming that a manager has a limited variety, this bound on communication capacity limits the coordination capacity of the units under the supervision of the manager (Bar-Yam 2004, p. 41). For instance, Table 3 shows planned and observed management activities of the consultancy project bundle leaders in an ordinary week, showing that the non-scheduled extra time was mostly due to coordination tasks. Consequently, using time as an activity-based measure, we can conclude that the variety for the project bundle leaders was proliferating.
    
    Activity Meetings Project bundle management Operational tasks and meetings Other tasks (ways etc.) Total
    
    Planned hours per week 20 18 2 40
    
    Observed hours per week 9.5 27 11 3.5 51 -7 +1,5 +11 +16,5
    
    Table 3.
    
    Actual Activities of an Exemplary Project Bundle Leader
    
    Therefore, a crucial point for project success was the decision to place the same consultancy managers in the leader role of all project bundles of the same business topic. In that they acted as boundary spanners and substituted direct user participation. As an informal System TWO, they fulfilled the important job of coordinating work in the separate Systems ONE, although this took more coordinative work than was originally expected (cf. Table 3). By this, the communication between the project bundles working on the same topics in different development steps was assured. In March 2007, the bank decided to create a single point of contact (SPOC) in the Business Division to collect requirements and be the central contact person for all subdivisions. Obviously, the subjective need for a central coordinative contact regarding gDWH requirements (System TWO) existed within the organizational structure. The interpretation of the organizational structure with the help of the VSM gave evidence for this missing information channel and the resulting suboptimal distribution of tasks. The formal gDWH project goals were specified by the project field management as 1) business requirement documents, 2) a software product and 3) a technical documentation. Project participants tried to at least fulfil all of these in pragmatic ways, because there was no time to discuss documentation contents deeply. The documents were read, interpreted and implemented by the IS developers having only little discussion with the business division. The following example clarifies this behaviour and resulting problems due to lack of communication. One requirement was to calculate the groupwide exposure of a customer within the ETL process. The business requirements did not cope with technical issues like inactive or closed deals which were needed for other analysis in gDWH. Having these additional deals within the calculation, the runtime of the gDWH had become unacceptable. Consequently, the responsible business employee and IT manager were directed to form a task force to solve the situation together. It took only a few hours to reduce the relevant amount of deals for the calculation to a half, which brought the runtime back in line. The business employee had no chance to consider this case upfront since technical knowledge was required: A transparent communication process has been implemented by pressure of project field management and project bundle management, which led to better results in the last releases. (24/10/2007, data warehouse project manager of the consultancy) In the middle of 2007, the project structure was changed to a more content-oriented structure. The project bundle leaders became PFLs with responsibility for Business Division, IT Department and Subsidiaries (System ONE). By this arrangement, they now officially became responsible for the coordinative communication tasks of System TWO as well.
    
    4
    
    DISCUSSION
    
    The main focus was on the ETL process which caused the largest expenses of about 60% within the data warehouse project. As the data warehouse in a first version already existed before the project had started, every change within the operational systems or in the data warehouse data model had impact on the ETL process. To develop a correct interface between an operational system as a data source and the data warehouse as a data consumer, the business departments and data warehouse developers have to agree about the business needs and the technical design of the ETL process. This agreement can
    
    only be reached by communication. This essentially is why the information channels of the surrounding organizational structure are that important. The main problems within the case can be put down to information channel defects and coordinative communication problems as shown in Table 4. There were a couple of problems having their roots in missing reconcilement between business requirements and technical design. The subjective business view judged the requirement documents as ready for implementation , while the subjective technical view often interpreted the requirements in a completely different direction. As a formal anti-oscillatory structure (System TWO) was missing, the project bundle leaders were forced to solve these issues with non-scheduled discussions. An intersubjective understanding had to be built with high costs between all stakeholders.
    Problem Destaffing of project members Part of VSM Systems 1 Actions taken Replanning of resources Project bundle leaders activities were shifted towards coordinative management tasks Overall program management installed the same consultant for a topic in each project field PFL IT defined clear processes for requirements analysis between Business Division and IT; installation of SPOC to tie communication
    
    Underestimated communication efforts for Systems ONE project bundle leaders No direct communication channel between System TWO Business Division and IT Department Late requirement changes and incomplete requirements discussion; no standards for communication System TWO
    
    Table 4.
    
    Summary of problems and actions linked to the VSM
    
    Requirement documents were needed to document the inter-subjective requirements, which became a contract between the business division as a principal and the IS implementation team as an agent. One finding of this case is that complex requirements cannot be written down without communication between business departments and IT departments. From a more radical point of view, requirements for complex IS always need to be discussed by all relevant stakeholders to enable a successful implementation. The observed ISDP s organizational structure failed in having a participative systems development approach: the users were involved in systems development, but did not take control of the process (Hirschheim et al. 1995, p. 36). Consequently, systems development was not viewed jointly as a social and technical process, which needs focusing on both the technical and the business issues. Up to a certain point, this could be substituted by an emerging System TWO: the project bundle leaders of the consultancy, acting in a dual role in both PFs of business and IT. Organizational structures in ISDPs need to explicitly take the mutual communication into account by providing official information channels and Systems TWO. A solution for the described problem is to implant a boundary spanner who has knowledge of both business and IT, as was the case with the PBL of the consultancy. Theoretically, this solves the problem, but the practical problem is that such high-skilled employees might be very expensive and do not automatically lead to a stable, reusable solution. When the specialist leaves the company, documentation is needed for the remaining employees or successors. Again a knowledge transfer is needed at that point in time, having to cope with the same problems as encountered during the implementation project. The underlying problem of requirements communication is that there is no common language in use that can handle all requirements in a formal way. On the other hand, the case shows that as of today it is not efficient to formalize, document and specify as much as you can ex ante by only one side of the requirements team. Requirements need to be based on broad inter-subjective understanding in order to be manageable with small expense. A problem exists with finding the right trade-off between how much more formalization is useful juxtaposed to direct speech-based communication and discussion. An ISDP s organizational structure explicitly has to take this into account.
    
    5
    
    CONCLUSIONS
    
    In this paper we introduced the VSM as an effective explanation model for communication-oriented organizational analysis on implementation projects in financial data warehousing. In a case study we showed how the organizational design of information channels can significantly affect project performance when building ETL processes. Every ISDP has to deal with implementing the business requirements correctly. For financial data warehousing projects the ETL process contains great complexity which leads to more complex requirements. To collect these requirements, direct communication is needed. The impact on project organization is a need for explicit provision of coordinative information channels and jointly developed requirements by both business and IT departments. In examining contributions of this research to ISDP management, we can conclude that from a practical perspective the VSM offers a suitable language for analyzing information and communication problems of complex ISDPs in detail. From a theoretical perspective, the VSM acts as a framework for identifying points of conflict and for actions to be taken to overcome those conflicts. This serves as a first building block for knowledge on assessing the quality of an ISDP s organizational structure. If sound ISDP management is among the desired goals, practitioners may benefit from our insights on what kind of activities strengthen the relationship between ISDP organizational structure and ISDP success. However, we like to point out that our study has several limitations. Our interpretation is not a validation of the relationship between the structure of the VSM and successful ISDP management. Since we examined only one single case for the single domain of financial data warehouses in detail, the findings need to be tested in cross-case analyses. Another suggestion is to apply the VSM in an action research approach. In the setup phase of an ISDP the organizational structure is determined by the roles and positions of the project. The know-how, skills and personality of team members filling these roles and positions influence the necessary intensity of information channel usage. We believe that team member allocation and the explicit design of information channels for communication are important prerequisites for successful financial data warehousing. But the process of working on business requirements and technical design still contains unexplained behaviors of involved actors. In further research, we want to develop a deeper understanding of how efficiency considerations make stakeholders believe that a sufficient level of knowledge transfer between team members is reached or not.
    
    References
    Adelman, S. and Moss, L. (2001) Data Warehouse Risks, Journal of Data Warehousing, 6 (1), pp. Aldrich, H. and Herker, D. (1977) Boundary Spanning Roles and Organization Structure, The Academy of Management Review, 2 (2), pp. 217-230. Ashby, W. R. (1964) An Introduction to Cybernetics, University Paperbacks, London, UK. Bar-Yam, Y. (2004) Multiscale variety in complex systems, Complexity, 9 (4), pp. 37-45. BCS (2004) The Challenges of Complex IT Projects, The British Computer Society (BCS) and The Royal Academy of Engineering, London, UK. Beer, S. (1979) The Heart of Enterprise, John Wiley & Sons, Chichester, UK et al. Beer, S. (1981) Brain of the Firm, John Wiley & Sons, Chichester, UK et al. Beer, S. (1985) Diagnosing the System for Organizations, John Wiley & Sons, Chichester, UK et al. Britton, G. A. and Parker, J. (1993) An explication of the viable system model for project management, Systemic Practice and Action Research, 6 (1), pp. 21-51. Conant, R. C. and Ashby, W. R. (1970) Every good regulator of a system must be a model of that system, International Journal of Systems Science, 1 (2), pp. 89-97. Espejo, R. and Harnden, R. (Eds.) (1989) The Viable System Model, Chichester, UK et al. Guo, Y., Tang, S., Tong, Y. and Yang, D. (2006) Triple-driven data modeling methodology in data warehousing: a case study, Proceedings of the 9th ACM international workshop on Data warehousing and OLAP, 59-66.
    
    Hirschheim, R., Klein, H. and Lyytinen, K. (1995) Information Systems Development and Data Modeling. Conceptual and Philosophical Foundations, Cambridge University Press, Cambridge, New York, USA. Hughes, J. and Wood-Harper, A. T. (1999) Systems development as a research act, Journal of Information Technology, 14 (1), pp. 83-94. Hwang, H. G., Ku, C. Y., Yen, D. C. and Cheng, C. C. (2004) Critical factors influencing the adoption of data warehouse technology: a study of the banking industry in Taiwan, Decision Support Systems, 37 (1), pp. 1-21. Jackson, M. C. (2000) Systems Approaches to Management, Kluwer Academic/Plenum Publishers, New York, NY, USA. Kawalek, P. and Wastell, D. G. (1999) A Case Study Evaluation of the Use of the Viable System Model in Information Systems Development, Journal of Database Management, 10 (4), pp. 24-32. Keil, M. (1995) Pulling the Plug: Software Project Management and the problem of Project Escalation, MIS Quarterly, 19 (4), pp. 421-447. Keil, M., Mann, J. and Rai, A. (2000) Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models, MIS Quarterly, 24 (4), pp. 631-664. Kimball, R. and Caserta, J. (2004) The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delivering Data, John Wiley & Sons. Kuntz, J. C., Christiansen, T. R., Cohen, G. P., Jin, Y. and Levitt, R. E. (1998) The Virtual Design Team, Communications of the ACM, 41 (11), pp. 84-91. Laudon, K. C. and Laudon, J. P. (2005) Essentials of Management Information Systems. Managing the Digital Firm, Pearson Prentice Hall, Upper Saddle River, NJ, USA. Levina, N. and Vaast, E. (2005) The Emergence of Boundary Spanning Competence in Practice: Implications for Implementation and Use of Information Systems, MIS Quarterly, 29 (2), pp. 335-363. Levitt, R. E. (2004) Computational Modeling of Organizations Comes of Age, Computational & Mathematical Organization Theory, 10 (2), pp. 127-145. Montealegre, R. and Keil, M. (2000) De-Escalating Information Technology Projects: Lessons from the Denver International Airport, MIS Quarterly, 24 (3), pp. 417-447. Pawlowski, S. D. and Robey, D. (2004) Bridging User Organizations: Knowledge Brokering and the Work of Information Technology Professionals, MIS Quarterly, 28 (4), pp. 645-672. Ribbers, P. M. A. and Schoo, K.-C. (2002) Program Management and Complexity of ERP Implementations, Engineering Management Journal, 14 (2), pp. 45-52. Rivett, P. (1977) The case for cybernetics. A critical appreciation, European Journal of Operational Research, 1 (1), pp. 33-37. Robillard, P. N. (1999) The role of knowledge in software development, Communications of the ACM, 42 (1), pp. 87-92. SGI (2001) (Standish Group International) Extreme CHAOS, Standish Group International, Inc. Vidgen, R. (1998) Cybernetics and Business Processes: Using the Viable System Model to Develop an Enterprise Process Architecture, Knowledge and Process Management, 5 (2), pp. 118-131. Walsham, G. (1995) Interpretive case studies in IS research: nature and method, European Journal of Information Systems, 4 (1), pp. 74-81. Wixom, B. H. and Watson, H. J. (2001) An Empirical Investigation of the Factors Affecting Data Warehousing Success, MIS Quarterly, 25 (1), pp. 17-41. Xia, W. and Lee, G. (2005) Complexity of Information Systems Development Projects: Conceptualization and Measurement Development, Journal of Management Information Systems, 22 (1), pp. 45-83. Yeo, K. T. (2002) Critical failure factors in information system projects, International Journal of Project Management, 20 (3), pp. 241-246. Yin, R. K. (2003) Case Study Research: Design and Methods, SAGE Publications, Thousand Oaks, CA, USA et al.

Add Comment

To add a comment, you need to login or signup (you can signup without leaving this page)