‘IT and Business Alignment.' Information Systems

profileVicky-shema
Howtostructurebusinesstransformationprojects.pdf

JOURNAL OF INFORMATION TECHNOLOGY

THEORY AND APPLICATION

ISSN: 1532-3416

Volume 17 Issue 2 Paper 2 pp. 5 – 21 July 2016

How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Maximilian Röglinger

FIM Research Center, University of Bayreuth

[email protected]

Manuel Bolsinger

FIM Research Center, University of Augsburg, Germany

Björn Häckel

FIM Research Center, University of Augsburg, Germany

Matthias Walter

FIM Research Center, University of Augsburg, Germany

Abstract:

Although project management, benefits management, change management, and transformation management are everyday terms in many organizations, projects still experience high failure rates. Business transformation projects in particular are prone to fail because they affect multiple enterprise architecture layers, involve many stakeholders, last several years, and tie up considerable amounts of corporate capital. To handle their complexity, scholars recommend structuring business transformation projects into portfolios of interdependent, yet smaller and, thus, manageable projects. So far, little guidance on how to do so exists. To share first-hand experience and stimulate research, we present and reflect on a project conducted with Infineon Technologies in which we co-developed Infineon’s finance IT roadmap. The finance IT roadmap served as the foundation for transforming Infineon’s finance IT setup to tackle future challenges of financial management in the semiconductor industry from an integrated business, process, and IT perspective.

Keywords: Business Transformation Management, Enterprise Architecture, Finance IT Setup, Project

Decomposition, Project Portfolio Management, Semiconductor Industry.

Jan vom Brocke was the Senior Editor for this paper.

6 How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2

1 Introduction

Business transformation is about fundamental change (Rouse, 2005). Centering around the orchestrated redesign of an organization’s genetic architecture, business transformation projects involve many stakeholder groups, affect multiple layers of the enterprise architecture, last several years, and tie up considerable amounts of corporate capital (Abraham, Aier, & Winter, 2015; Morgan & Page, 2008; Safrudin, Rosemann, Recker, & Genrich, 2014). Moreover, despite their enormous potential impact on corporate success, business transformation projects are prone to fail (Dehning, Richardson, & Zmud, 2003; Nelson & Morris, 2014). For instance, The Standish Group (2013) classifies 38 percent of large- scale projects (i.e., projects with a labor content greater than US$10 million) as failures.

Against this backdrop, researchers have investigated business transformation from different angles for years. From a descriptive perspective, Safrudin et al. (2014) crafted a typology of business transformation projects based on 20 real-world cases. Abraham and Junglas (2011) investigated at a healthcare company how a coordinated information systems (IS) implementation process contributed to organizational transformation and found that the linkage between IS implementation and business strategies promoted coordination. Abraham et al. (2015) analyzed which properties enterprise architecture models should have to overcome knowledge boundaries in business transformation projects. From a prescriptive perspective, Uhl and Gollenia (2012) proposed the business transformation management methodology to serve as a comprehensible, adaptable, holistic, and integrative approach to business transformation, to balance rational and emotional aspects of transformation, and to provide execution guidance.

Because one particular reason for why business transformation projects fail is a lack of up-front preparation and planning, we focus on program and project management activities. In particular, we focus on program planning and integration and scoping management (Rosemann, Recker, Safrudin, & Marketsmueller, 2012). In the business transformation lifecycle model—which includes the “envision”, “engage”, “transform”, and “optimize” phases—the program and project management activities mainly relate to the “engage” phase. In this phase, scholars recommend structuring business transformation projects into portfolios of interdependent, yet smaller and, thus, manageable projects (Stiles, Uhl, & Stratil, 2012). In fact, only four percent of all projects with a labor content less than US$1 million have been reported to fail (The Standish Group, 2013). Though being extensive and multi-faceted, related work provides little guidance on how to structure business transformation projects—be it the literature on business transformation management itself or the literature on related disciplines such as project management, project portfolio management, and enterprise architecture management. The project management body of knowledge, for example, fits standalone projects well but hardly applies to business transformation projects (Project Management Institute, 2013). Methods from project portfolio management help select and schedule projects from predefined project portfolios but not to identify these portfolios (Bardhan, Bagchi, & Sougstaf, 2004). Finally, the aforementioned business transformation management methodology provides detailed guidance on many topics related to program and project management, but it does not discuss how to structure business transformation projects (Rosemann et al., 2012).

To address this gap and stimulate research, we share first-hand experience on how to structure business transformation projects gained in a project with Infineon Technologies in which we co-developed Infineon’s finance IT roadmap. In Section 2, we introduce the context of Infineon Technologies and focus particularly on the future challenges of financial management in the semiconductor industry. We also outline the problem statement of Infineon’s finance IT roadmap project. After that, in Section 3, we elaborate on the objectives, main tasks, and outcomes of all project phases. In Section 4, we reflect on related lessons learned. In Section 5, we conclude by discussing our study’s implications for future research.

Contribution:

To provide first-hand experience on how to structure business transformation projects, this paper reports on a project with Infineon Technologies in which we co-developed Infineon’s finance IT roadmap. The paper elaborates on the objectives and outcomes of all project phases and on related lessons learned. It also shares insights into the project’s main tasks (i.e., conceptualize and operationalize the target state, identify and prioritize gaps, compile a project portfolio, and derive transformation roadmaps) and tools (i.e., a modular project framework, fulfillment-importance matrix, project templates) that proved useful in the Infineon case. Finally, the paper showcases how researchers and practitioners can collaborate to solve complex real-world problems.

Journal of Information Technology Theory and Application 7

Volume 17 Issue 2 Paper 2

2 Case Context and Problem Statement

Infineon Technologies is a global market leader in the semiconductor industry. In the 2014 fiscal year, Infineon generated revenue of about €4.3 billion. As of September 2014, Infineon employed approximately 29,800 people at 21 research and development (R&D) and 12 manufacturing locations worldwide. With its semiconductor and system solutions for automotive and industrial electronics and for chip card and security applications, Infineon focuses on three central challenges facing contemporary society: energy efficiency, mobility, and security. As with other companies operating in the semiconductor industry, Infineon faces ever-stronger demand- and supply-side challenges, which makes a sophisticated IT-based financial management setup strategically important.

From the demand-side perspective, the semiconductor industry is highly volatile and short-term oriented because, for one, due to fast technological progress and the rapid pace of innovation, most semiconductors have an extraordinarily short lifecycle and high depreciation. Moreover, many customers of semi-conductor companies face high demand uncertainty themselves. For example, the automotive industry is highly dependent on business cycles. To cope with their own demand uncertainty, customers of semiconductor companies are likely to place and cancel orders of substantial volume on short notice. On the contrary, they expect an availability of several decades for some products. Both circumstances make managing the demand side in the semiconductor industry challenging.

From the supply-side perspective, the semiconductor industry is comparatively sluggish and requires a long-term orientation because, for one, establishing and maintaining production facilities requires huge investments and considerable ramp-up time. Production facilities often lead to initial investments exceeding €100 million and do not amortize in less than 10 to 15 years. When considering the demand- side dynamics, calculating business cases for such investments is challenging. Production facilities need continuous updating and streamlining to keep up with the innovation pace due to product variety and cost- reduction pressure. Semiconductor production also requires firms to coordinate globally distributed supply network. Finally, semiconductors rely on precious metals and rare earths, which have volatile prices by themselves and whose availability throughout upcoming decades is at risk.

To address the demand- and supply-side challenges governing the semiconductor industry, Infineon Technologies decided to transform its finance IT setup. Infineon’s finance IT setup included all processes operated and services offered by Infineon’s financial management department and the IT support of these processes and services. The transformation of Infineon’s finance IT setup was an architectural transformation since parts of Infineon’s enterprise architecture had to be overhauled; the core business concepts were not the subject of change (Safrudin et al., 2014; Wu, Rose, & Lyytinen, 2011). To prepare the transformation of Infineon’s finance IT setup, we supported Infineon to conduct the finance IT roadmap project. The project’s overarching objective was to determine the target state of Infineon’s finance IT setup and provide concrete guidance in terms of a project portfolio and possible roadmaps on how to transform the previous finance IT setup in three to five years.

We believe for several reasons that the transformation of Infineon’s finance IT setup is a suitable case for discussing the program and project management activities of the business transformation lifecycle model. First, Infineon’s business and IT departments were heavily involved in the business transformation project. Second, Infineon’s finance department offered services in different organizational contexts and with heterogeneous requirements on process and IT support, such that the project’s overall complexity was very high. Based on our experience, one can find similar transformation projects in many other companies worldwide. Therefore, in our perception, the transformation of Infineon’s finance IT setup was much more closely related to a typical than to a particular case.

3 The Solution

3.1 Project Setup and Overview

The head of Infineon’s financial management department, who directly reported to the chief financial officer, initiated and sponsored the finance IT roadmap project. A workshop involving Infineon’s financial management department identified the need to transform Infineon’s finance IT setup. Thus, both senior management and the entire department supported the project. The project’s core team comprised four corporate and four academic members. To account for the project’s interdisciplinary nature and to cover all relevant layers of Infineon’s enterprise architecture, two corporate team members stemmed from

8 How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2

Infineon’s finance department, whereas the other two worked for the IT department. Two corporate team members, who shared the role of the project manager from Infineon’s side, were department heads to ensure that the finance IT roadmap project was equipped with sufficient decision authority and sufficiently connected with the senior management. As for the academic team members, two members had a background primarily in financial management, whereas the other two had their background primarily in business process management, enterprise architecture management, and IT. The academic team encompassed two post-doctorate researchers and two PhD students. The academic team members’ role was to enrich Infineon’s experience with academic knowledge, to prepare and conduct interviews, and to help compile the project portfolio and transformation roadmaps. To help the team members exchange information among themselves, the academic team members worked three days per week on site. They spent the rest of the week at university to synchronize with colleagues doing research in similar areas.

The finance IT roadmap project took nine months and comprised three phases: 1) conceptualizing and operationalizing the target state, 2) identifying and prioritizing gaps, and 3) compiling a project portfolio and deriving transformation roadmaps. Because we conceptualized the target state top-down and compiled the project portfolio bottom-up, the finance IT roadmap project followed a mixed top- down/bottom-up approach. Before starting the project, the team reached consensus on strategic guidelines regarding the project’s phase plan and the project results. Figure 1 overviews all project phases including objectives, main tasks, and outcomes. We discuss each phase in turn from Section 3.3.1 to Section 3.3.3.

Figure 1. Structure of the Finance IT Roadmap Project

3.2 Project Guidelines

Before starting the finance IT roadmap project, the team agreed on strategic guidelines with respect to the project’s phase plan and results that we had to consider throughout the project. The academic team members derived initial versions of most guidelines from related academic knowledge, and they iteratively prioritized, selected, and configured the guidelines in close collaboration with the corporate team members. Infineon proposed other guidelines (e.g., guideline 4). We chose project portfolio management and enterprise architecture management as primary reference disciplines for two reasons. First, the finance IT roadmap project aimed to structure the transformation of Infineon’s finance IT setup and provide guidance via transformation roadmaps. Thus, knowledge about project portfolios and project interactions was highly important. Second, with the transformation of Infineon’s finance IT setup being an architectural transformation, we needed to think across multiple enterprise architecture layers and to consider interactions among these layers. Overall, the project team agreed on five guidelines. Below, we present the final set of guidelines together with selected justificatory references where applicable.

Journal of Information Technology Theory and Application 9

Volume 17 Issue 2 Paper 2

1. Involve multiple stakeholder groups and management layers: the finance IT roadmap

project needed to involve multiple stakeholder groups and management layers. Involving multiple stakeholder groups (e.g., departments such as finance, operations, and IT) fosters operational business IT alignment, which is a success factor for transforming strategic plans into operations (Wagner & Weitzel, 2012). Involving multiple stakeholder groups also helps create a shared understanding of the transformation project’s target and, therefore, drives transformation success (Abraham et al., 2015). As for Infineon, this guideline was particularly important because Infineon is a global company whose departments are predominantly located in multiple countries and each country has its own peculiarities regarding financial management. Due to the variety of processes operated and services offered by Infineon’s finance IT setup, the project also had to consider multiple management layers. Indeed, top- down initiatives often fail due to a lack of coordination among organizational levels (Fonstad & Robertson, 2006).

2. Involve multiple enterprise architecture layers: the transformation’s scope dictated that the transformation not focus solely on IT. Rather, we committed to consider multiple enterprise architectures layers (e.g., business model, processes, application systems, and IT infrastructure) and interactions between neighboring layers (Abraham et al., 2015; Winter & Schelp, 2008) because research has shown that treating business transformation projects as purely IT driven is a critical failure factor and that a holistic approach considering multiple architecture layers is a success factor of organizational design and transformation (Braun & Winter, 2007).

3. Consider project interactions: due to the high number of projects we expected to be necessary to transform Infineon’s finance IT setup, we had to consider interactions among projects throughout the entire transformation, which included specifying individual projects and compiling the resulting project portfolio. Considering project interactions ensures that one can flexibly adapt transformation roadmaps in response to changes in the business environment, management priorities, and available resources (Ghasemzadeh & Archer, 2000; Martinsuo, 2013; Morris & Jamieson, 2005). Because the transformation had a timeframe of several years, intertemporal and scheduling interactions were particularly important (Bardhan et al., 2004).

4. Parsimoniously document the resulting project portfolio: due to the high number of

projects necessary to transform Infineon’s finance IT setup, we had to document the project portfolio resulting from the finance IT roadmap in a parsimonious manner. This documentation had to go far beyond a mere project list. Rather, the documentation had to comprehensively overview and visualize projects, interactions among projects, and management priorities such that Infineon could use it both as a foundation for deriving transformation roadmaps and as a tool for adjusting transformation roadmaps.

5. Align the project portfolio with the transformation target: we had to align the resulting project portfolio with the target state envisioned for the transformation (Patanakul & Shenhar, 2012). For each project, one had to be able to clearly argue how and to what extent it contributed to the overall transformation (Rosemann et al., 2012).

3.3 Project Phases

3.3.1 Phase 1: Conceptualize and Operationalize the Target State

In the first phase, we conceptualized and operationalized the target state of Infineon’s finance IT setup. To do so, we first conceived an initial set of high-level requirements based on a structured literature review. We deliberately refrained from extensively analyzing and documenting Infineon’s existing finance IT setup for several reasons: first, in a global company such as Infineon Technologies, such an endeavor would have taken months. Second, starting with the finance IT target setup helped develop a bolder vision of the future and avoid getting stuck in the existing setup’s problems. Third, we analyzed the existing finance IT setup throughout the second phase. To ensure that the high-level requirements complied not only with the academic state-of-the-art knowledge but also with the peculiarities of Infineon, we refined the initial set of high-level requirements throughout multiple review rounds with the corporate project team members. Figure 2 shows the final set of high-level requirements that we used in the finance IT roadmap project. With the transformation of Infineon’s finance IT setup being an architectural one, we structured the high-

10 How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2

level requirements along three layers derived from enterprise architecture management (i.e., business requirements, process-related and organizational requirements, and IT-related requirements).

As a theoretical lens, we relied on value-based management and related disciplines such as business process management, business intelligence, and corporate performance management to cover all involved enterprise architecture layers. We chose value-based management as our guiding paradigm as it emphasizes cash flow, future, and risk orientation (e.g., Rappaport, 1986). Value-based management directly affects corporate activities such as risk management, cash flow management, investment and project valuation, planning and forecasting; it also affects the interfaces of these activities that one uses to operational finance services (e.g., Aretz & Bartram, 2010; Hahn & Kuhn, 2012; Malmi & Ikäheimo, 2003). All these activities were important for Infineon’s financial management activities and, thus, for the finance IT setup. Our choosing value-based management was in line with the aspirations of Infineon’s financial management department. In the workshop in which the financial management department identified the need for transforming Infineon’s finance IT setup, it also decided to strengthen its cash flow, future, and risk orientation. Thus, in line with the objectives of Infineon’s financial management department, we chose value-based management as a perspective to promote organizational transformation.

Figure 2. High-level Requirements of the Finance IT Target Setup

As a foundation for the gap analysis we performed in the second phase, we operationalized the high-level requirements via low-level requirements. Low-level requirements had to be on such a low level of abstraction that we could discuss the target state of Infineon’s finance IT setup (and, more importantly, gaps between the target state and the existing finance IT setup) with corporate experts in relation to their daily processes. The process we used to deriving low-level requirements was similar to that for deriving high-level requirements. The project team derived an initial set of low-level requirements (as far as possible in accordance with academic state-of-the-art knowledge) and continuously refined until the set sufficiently covered all fields of action. In the end, at least one low-level requirement had to cover each high-level requirement. The final catalog of low-level requirements that captured Infineon’s finance IT target setup included 169 low-level requirements. Some examples include: “Outlier analysis (anomaly detection) is performed (e.g., to identify sales outliers/anomalies in a data set of a region, product, sales representative, or season)” and “Data for analytical purposes (e.g., planning, forecasting, and reporting) is retrieved from a core data warehouse and multiple dependent data marts”.

Due to the high number of low-level requirements, we relied not only on the three layers derived from enterprise architecture management but also on Infineon’s finance service catalog to structure the low- level requirements. Infineon’s finance department had conceived the finance service catalog just before the finance IT roadmap project started. It included all services offered by Infineon’s financial management

Journal of Information Technology Theory and Application 11

Volume 17 Issue 2 Paper 2

department, including operational services (e.g., accounting, operational tax services, and working capital management) and analytical services (e.g., planning, targeting, analytics, and reporting). One could easily communicate this second dimension in Infineon. It also helped ensure completeness when deriving low- level requirements and selecting low-level requirements for interviews in the second phase. To fine-tune the low-level requirements’ understandability, we conducted pretests with selected corporate experts. As a result, we enriched the low-level requirements with Infineon-specific examples and with open-ended follow-up questions to obtain richer insights as input for the second and third phases.

3.3.2 Phase 2: Identify and Prioritize Gaps

In the second phase, we identified and prioritized gaps between the status quo and the target state of Infineon’s finance IT setup. We first conducted semi-structured interviews based on the low-level requirements derived in the first phase with corporate experts from different stakeholder groups. We also interviewed selected senior managers to obtain insights from both an operational and a management perspective. The corporate project team members proposed all interviewees in accordance with Infineon’s finance service catalog.

The questionnaire used for the interviews included selected low-level requirements and the corresponding follow-up questions that matched with interviewees’ area of expertise. We included these questions in the questionnaire because they helped the interviewees prepare the interview and the interviewers discuss the requirements in a comparable manner across all interviews. At the end of the questionnaire, we included overarching questions to elicit the interviewees’ expectations concerning the transformation of Infineon’s finance IT setup, perceived complexity drivers, and principal pain and opportunity points regarding the finance IT setup. To identify gaps, the interviewees also had to quantitatively rate to what extent Infineon was already fulfilling the low-level requirements (from “poor” to “excellent”) and how important it was that they were excellently fulfilled in the future (from “not at all” to “business critical”) on six-point Likert scales. Overall, we conducted 33 semi-structured inter-views with finance and IT experts in charge of different finance services (e.g., head of tax management, head of IT, and heads of finance in different geographical regions). We also interviewed six senior managers from Infineon’s finance and IT community. Because most interviews involved more than one interviewee, including several members from the interviewees’ teams, we interviewed 86 experts in total. Each interview lasted about two hours and covered approximately 30 low-level requirements.

After we conducted all interviews, we aggregated the quantitative results for each low-level requirement and assigned them to quadrants (which imply a specific option for action in line with the associated fulfillment and importance values) of a fulfillment-importance matrix. The fulfillment-importance matrix slightly resembles a mirrored version of Gartner’s Magic Quadrant except the latter’s “ability to execute” dimension corresponds to the former‘s “current extent of fulfillment” and the former’s “importance of excellent fulfillment” dimension replaces the latter’s “completeness-of-vision” dimension (Gartner, 2015). Figure 3 shows the results for all 169 low-level requirements. The “Invest!” quadrant encompasses all low- level requirements with a low fulfillment and high importance of excellent fulfillment. We treated all low- level requirements located in this quadrant as gaps. The idea is that, by transforming Infineon’s finance IT setup, Infineon successively closes all gaps and moves the associated requirements to the “Manage Excellence!” quadrant. The “Manage Excellence!” quadrant includes requirements with a high fulfillment and high importance of excellent fulfillment. There were small or no gaps regarding the requirements in this quadrant. Therefore, we excluded these requirements from further analyses. The main challenge of this quadrant was to maintain the high level of fulfillment and management attention over time, particularly during the transformation of Infineon’s finance IT setup. The “Reprioritize! or Disinvest!” quadrant encompasses all requirements with high fulfillment and low importance of excellent fulfillment. Considering the effort required for maintaining high levels of fulfillment, the low-level requirements located in this quadrant may have been underestimated or cause unnecessarily high effort, which kept valuable resources away from the transformation project. Thus, there are two options: reprioritize requirements (i.e., increase their perceived importance of excellent fulfillment), or disinvest them (i.e., reduce service levels, staff, or IT support). The first option leads to a migration toward the “Manage Excellence!” quadrant, and the second option leads to a migration toward the “Ignore!” quadrant. Finally, the “Ignore!” quadrant encompasses all requirements featuring a low fulfillment and low importance of excellent fulfillment. Management should not emphasize these requirements. Therefore, we excluded these requirements from further analyses as well. The requirements located in the “Invest!” quadrant were not the only source of gaps: there were also gaps related to requirements located in the other quadrants, which we identified by contrasting their quantitative rating against the interviewers’ impressions from the

12 How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2

interviews. We further enlarged the catalog of gaps by analyzing the qualitative insights from the follow- up, the overarching questions, and the interviews with senior managers.

For our analysis, we defined the quadrants of the fulfillment-importance matrix by interpreting fulfillment values less than or equal to 4 and importance values less than 3 as low. Choosing these borders, we accounted for the circumstance that interviewees tended to be uncertain about whether to choose 3 (i.e., the requirement tended not to be well fulfilled / not so important) or 4 (i.e., the requirement tended to be well fulfilled / important).

In sum, almost no low-level requirements were located in the “Ignore!” and the “Reprioritize! or Disinvest!” quadrants. On the one hand, this finding corroborated the validity of our low-level requirements. On the other, it showed that Infineon did not overinvest in particular topics of the finance IT setup. We located many requirements in the “Manage Excellence!” quadrant, a finding that indicates the fact that Infineon did a good job regarding some central topics of the finance IT setup. Most interestingly, low-level requirements located in the “Invest!” quadrant (i.e., the gaps) were almost equally distributed across the layers of the enterprise architecture. That is, treating the finance IT roadmap project as a purely IT-driven transformation endeavor would have neglected about two thirds of the relevant gaps.

Figure 3. Fulfillment-importance Matrix Derived from 33 Semi-structured Interviews

3.3.3 Phase 3: Compile a Project Portfolio and Derive Transformation Roadmaps

In the third phase, we compiled a portfolio of interdepending projects that we expected to close the gaps between the status quo and the target state of Infineon’s finance IT setup. Thus, we clustered the identified gaps into groups, each of which the project team members were convinced they could tackle in a single project. This procedure ensured that each project aligned with the target state of Infineon’s finance IT setup. While defining projects, we catered for interactions such as successor/predecessor relationships.

To document the resulting project portfolio in a parsimonious manner, we conceived a modular project framework. The framework’s dimensions referred to the processes operated by Infineon’s financial management department and to cross-process topics discovered during the grouping of gaps. We chose this matrix-like structure because, according to the experience gained throughout the finance IT roadmap project, we could unambiguously assign some gaps to distinct finance processes and others to distinct topics that spanned multiple processes (e.g., advanced analytics). We grouped projects according to the processes operated by Infineon’s finance department and not in line with the services that the finance service catalog covered because there also were gaps regarding some internal finance processes that influenced several services. Moreover, the people from Infineon’s financial management were familiar with

Journal of Information Technology Theory and Application 13

Volume 17 Issue 2 Paper 2

process thinking. The final project framework included only those finance processes for which we identified gaps. We marked cells of the project framework as “not applicable” if we could derive no respective project. We referred to projects that referred neither to a distinct process nor to a cross-process topic as standalone projects and collected them separately. Figure 4 shows the project framework’s overall structure.

Figure 4. Overall Structure of the Modular Project Framework

The modular project framework distinguishes process-specific projects and cross-process topics. Process- specific projects close gaps that relate to a distinct process but not to a cross-process topic. One may need multiple process-specific projects to close all gaps identified for a particular process. The framework assumes that one can address processes independently, which leaves considerable degrees of freedom when deciding on the sequence one should implement projects. We specified process-specific projects using a brief project description, benefits, and opportunities, drawbacks and risks, an arbitrary number of work packages, direct interactions with other projects, and further comments. Cross-process topics address all gaps that refer to a distinct topic (e.g., advanced analytics). The specification of a cross- process topic briefly describes the related topic, benefits and opportunities, drawbacks and risks, work packages, direct relationships with other projects, and further comments. In contrast to process-specific projects, work packages of a cross-process topic split into preparatory, general, and process-specific work packages. This structure enables configuring projects for concrete process/topic combinations. One must execute general work packages for each process intended to be improved according to the cross-process topic. One must execute process-specific work packages only for a distinct process. Table 1 shows a partly anonymized specification of the cross-process topic “advanced reporting”. A concrete process/topic- specific project may also require preparatory work packages to be carried out beforehand if it is the first project referring to this topic. We considered successor/predecessor relationships among cross-process topics that restrict the sequence in which one can implement process/topic-specific projects.

14 How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2

Table 1. Specification of the Cross-process Topic “Advanced Reporting” (Partly Anonymized)

Cross-process topic: advanced reporting

Brief description

This cross-process topic aims to improve the reports with respect to their coverage of information needs and their creation processes. In particular, this topic includes the development of ….

Addressed high-level requirement

 Orientation toward information needs and decision relevance

 …

Main benefits and opportunities Main drawbacks and risks

1 Consistent report design in line with the state-of-the- art.

1 Flexibility to adapt reports to specific needs of management may be reduced.

2 … 2 …

I—Preparatory work packages Scope Goals

1 Evaluate in detail the existing reporting application landscape within IFX regarding their ability to cover information needs and the manual effort required for creating reports.

IT -

2 … Functional …

II—General work packages Scope Goals

1 Adapt and implement company-wide reporting guidelines in existing reporting applications which according to preparatory work package 1 will still be in use in the future. Thereby consider information needs of the report recipients.

Functional …

2 Establish regularly feedback process between report recipients and report creators regarding the fulfillment of the report recipient’s information needs as well as the decisions that resulted from the reports.

Process -

3 […] IT …

III—Process-specific work packages Process Scope Goals

1 Improve automated reporting on R&D projects (and their risks) under consideration of company-wide reporting guidelines.

… IT …

2

Improve (ex ante) reporting on main risks of investments (especially demand risks and sales risks) under consideration of interdependencies between different product lines and the company-wide reporting guidelines.

Functional …

3 … … IT …

Direct relationships to other projects / topics Type

1 Flexible data management in a single data source Predecessor

2 … Predecessor

Further comments

Because the project framework so far only structured projects and did not contain information about priorities or interactions, we extended the project framework to indicate priorities via colors and to arrange all projects referring to a distinct process in a pseudo-sequential order using numbers and letters (Figure 4). Colors indicate the priority of distinct processes as a foundation for deriving transformation roadmaps. In line with the quantitative rating of the gaps conducted in the second phase, colors indicate whether the implementation of a distinct project is of very high importance (“red”), high importance (“orange”), or medium importance (“yellow”). The more important the projects related to a distinct process, the higher the process’s priority. In Figure 5, it would be more important to implement projects related to risk management than projects related to tax management. Because business transformation projects are not restricted to a single process at a time, the number of processes that one may address in parallel depends on the resources available, the results of business case analyses, and other ongoing projects. Numbers help cluster projects into rollout waves. Using the numbers 1 to 3, we suggest implementing projects marked with “1” before “2,” and “2” before “3.” If appropriate, one can also have more than three

Journal of Information Technology Theory and Application 15

Volume 17 Issue 2 Paper 2

implementation waves. In a rollout wave, one may further prioritize projects using small letters because some projects may be important (i.e., the associated cell in the project framework is red) but need to implement other potentially less-important projects beforehand (e.g., to comply with successor/predecessor relationships). One can implement a project that has only a number assigned at any point in the associated rollout wave. In this case, the colors may help determine in what order to implement the projects. Consequently, the project framework does not only contain a single project sequence. Rather, it allows one to derive multiple transformation roadmaps that one can adjust to new information and to changing market environments and management priorities.

Based on our assessment in the second phase, we identified gaps with respect to finance processes such as consolidation, internal charging, inventory valuation, risk management, and tax management. Furthermore, we identified cross-process topics such as data management, advanced analytics, and advanced reporting. This resulted in a project framework similar to that shown in Figure 5. For confidentiality, we cannot show the complete project framework developed during the finance IT roadmap project at Infineon. Due to the cross-process nature of the identified topics, numerous admissible project sequences comply with the successor/predecessor relationships that one can compile into concrete transformation roadmaps. Each transformation roadmap candidate reflects different management priorities regarding cross-process topics and finance processes.

Figure 5. Project Framework used for Infineon’s Finance IT Roadmap Project (Partly Anonymized)

4 Lessons Learned from the Case

Based on the experience gained throughout the finance IT roadmap project, we identified four major lessons learned in project post-completion reviews both in the academic project team and with the entire core team. Therefore, the lessons learned include the entire core team’s assessment (i.e., four academic team members and four corporate team members). Because the corporate team members worked for Infineon’s financial management and IT department (even in different areas of these departments), the lessons learned reflect all relevant stakeholder groups’ assessments.

1. Well prepared is half-transformed: one of the most challenging tasks in the finance IT roadmap project was to derive the high-level requirements that characterize the finance IT target setup on different layers of the enterprise architecture and, in particular, to operationalize these high-level requirements in terms of low-level requirements. At first, we

16 How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2

planned to derive requirements in a few weeks. However, we realized quickly that this task was more complex than anticipated and, in line with the critical importance of the requirements for validating our project outcomes, we decided to take much more time to specify the requirements. As such, we could incorporate the latest research results regarding IT-supported value-based management into the high- and low-level requirements. Moreover, we ensured that the low-level requirements covered all services from Infineon’s finance service catalog, had an appropriate level of abstraction, and were written to be easily understandable by the intended interviewees. To ensure the validity and appropriateness of our requirements, we conducted multiple review rounds with the corporate project team members. We also took the time to map low-level requirements to not only different layers of the enterprise architecture but also Infineon’s finance service catalog. Thus, we ensured that the interviewees were confronted with requirements only from their area of expertise. Our experience throughout the interviews and, even more importantly, from identifying projects based on the interview results and presenting how we derived the project framework showed that this additional investment was worthwhile. In the end, it took about two months to define and validate the low-level requirements. If we had stuck with the initial project plan (a few weeks for the same task), the project outcome would have been much less sophisticated.

2. Let corporate and academic project team members conduct the interviews: the interviews we conducted were challenging. On the one hand, interviewees had deep knowledge regarding tasks in their area of expertise and extensive implicit knowledge about how Infineon as a company behaved, which occasionally complicated how we interpreted what the interviewees said. On the other hand, we had to make the purpose of the finance IT roadmap project clear and acquire as much information as possible from the interviewees in quite a short timeframe. Against this backdrop, both corporate and academic project team members conducted the interviews. The academic team members were more familiar with interview techniques and could take on the neutral perspective of outside observers. Due to the personal relationship between the corporate project team members (who were themselves department heads) and the interviewees, we could quickly establish a trusting atmosphere and received constructive and reliable information. The corporate project team members also served as “translators” among the interviewees and the academic team members when we needed additional knowledge to correctly grasp the meaning of some statements made throughout the interviews. If only academic team members had conducted the interviews, the corporate team members (particularly the department heads) would have saved a significant amount of time. However, we would have missed relevant hints, particularly with respect to the open-ended follow-up questions, which pointed to gaps of the finance IT setup. If only corporate core team members had conducted the interviews, the interviews would have been biased towards those problems and ideas the corporate team members already had in mind, which would have significantly impacted the project’s credibility because Infineon considered the neutral academic perspective an important factor for its finance IT roadmap project.

3. Establish a central transformation governance entity: successfully implementing a business transformation project requires a central governance entity for multiple reasons. First, business transformation projects require team members from different business and IT departments and internal and external project team members to be coordinated. Second, the interactions in the project portfolio must be managed centrally to be able to react to changes in management priorities and the business environment. Third, only a central governance entity can further develop the project framework and transformation roadmap, monitor the implementation progress, and decide how to proceed in case of multiple alternatives. Fourth, such a central entity can serve as a single point of contact for business and IT departments. In this capacity, it must collect and prioritize change requests that originate from the operational business and affect the transformation endeavor. In the finance IT roadmap project, we established such a central project governance entity, the finance IT office, which included experienced finance and IT experts from all involved organizational entities such as central services, divisions, operations, and regions. Establishing the finance IT roadmap was essential for anchoring the finance IT roadmap in Infineon’s organization. Otherwise, it would have been unclear which organizational entity should take on responsibility for the finance IT roadmap, a circumstance that would have impeded the transformation of Infineon’s finance IT setup.

4. Provide more than one transformation roadmap: the main outcome of the finance IT

roadmap project was a project framework that helped Infineon document project portfolios in a

Journal of Information Technology Theory and Application 17

Volume 17 Issue 2 Paper 2

parsimonious manner and derive concrete transformation roadmaps. When developing the project framework, we refrained from proposing a single roadmap for transforming the existing finance IT setup into the finance IT target setup. We knew that a single roadmap would simply not have been enough, particularly in a dynamic environment such as the semiconductor industry whose business environment may change quickly and whose business cycles heavily impact companies’ priorities and project budgets. To prevent the transformation roadmap from ending up as a “paper tiger” in the drawer of some senior managers, we needed to make the transformation roadmaps easily adaptable, which is why we not only specified projects but also considered interactions among projects and management priorities. Of course, a single transformation roadmap would have been much easier to derive and communicate, but a single roadmap for Infineon would have been had much less utility, particularly if one considers the long planning horizon of the transformation of Infineon’s finance IT setup and the demand- and supply-side challenges on financial management in the semiconductor industry.

5 Conclusion

Despite their importance for organizational change and the high failure rates, little guidance on how to structure business transformation projects exists. To share first-hand experience and to stimulate related research, we report on a project with Infineon Technologies in which we co-developed Infineon’s finance IT roadmap. The finance IT roadmap served as foundation for transforming Infineon’s finance IT setup to tackle future challenges of financial management in the semiconductor industry from a business, process, and IT perspective. We outline the objectives, main tasks, and outcomes of all project phases and reflect on lessons learned from the Infineon case. The case of the finance IT roadmap project also showcased that project teams comprising corporate and academic members can tackle challenges that neither corporate nor academic teams would be able to tackle alone. We confirmed this assessment for the finance IT roadmap project in the post-completion reviews we conducted.

As inherent to case descriptions, our insights are limited to the Infineon case. From a research perspective, it would be interesting to advance the ideas developed in the finance IT roadmap project towards a full-fledged method for structuring business transformation projects using, for example, situational method engineering as research method. To do so, researchers should discover which parts and to which extent one needs to abstract a project’s main tasks and the tools used to document intermediate or final results (e.g., the catalog of high- and low-level requirements, the fulfillment- importance matrix, or the modular project) such that they apply to other project contexts. Researchers should also investigate which parts of the resulting method should be customizable with respect to different contexts and which factors drive customization. Experience from similar projects would be extremely helpful as well.

Despite the single-case character of this study, we hope that the presented experience from the finance IT roadmap project, the ideas on how to structure business transformation projects, and the lessons learned help corporate transformation managers and researches until we see further development from a research perspective.

18 How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2

References

Abraham, C., & Junglas, I. (2011). From cacophony to harmony: A case study about the IS implementation process as an opportunity for organizational transformation at Sentara healthcare. The Journal of Strategic Information Systems, 20(2), 177-197.

Abraham, R., Aier, S., & Winter, R. (2015). Crossing the line: Overcoming knowledge boundaries in enterprise transformation. Business & Information Systems Engineering, 57(1), 3-13.

Aretz, K., & Bartram, S. M. (2010). Corporate hedging and shareholder value. Journal of Financial Research, 33(4), 317-371.

Bardhan, I., Bagchi, S., & Sougstad, R. (2004). Prioritizing a portfolio of information technology investment projects. Journal of Management Information Systems, 21(2), 33-60.

Braun, C., & Winter, R. (2007). Integration of IT service management into enterprise architecture. In Proceedings of the 2007 ACM Symposium on Applied Computing (pp. 1215-1219).

Dehning, B., Richardson, V. J., & Zmud, R. W. (2003). The value relevance of announcements of transformational information technology investments. MIS Quarterly, 27(4), 637-656.

Fonstad, N. O., & Robertson, D. (2006). Transforming a company, project by project: The IT engagement model. MIS Quarterly Executive, 5(1), 1-14.

Gartner. (2015). Gartner magic quadrant. Retrieved from http://www.gartner.com/technology/ research/methodologies/research_mq.jsp

Ghasemzadeh, F., & Archer, N. P. (2000). Project portfolio selection through decision support. Decision Support Systems, 29(1), 73-88.

Hahn, G. J., & Kuhn, H. (2012). Designing decision support systems for value-based management: A survey and an architecture. Decision Support Systems, 53(3), 591-598.

Malmi, T., & Ikäheimo, S. (2003). Value based management practices—some evidence from the field. Management Accounting Research, 14(3), 235-254.

Martinsuo, M. (2013). Project portfolio management in practice and in context. International Journal of Project Management, 31(6), 794-803.

Morgan, R. E., & Page, K. (2008). Managing business transformation to deliver strategic agility. Strategic Change, 17(5-6), 155-168.

Morris, P. W. G., & Jamieson, A. (2005). Moving from corporate strategy to project strategy. Project Management Journal, 36(4). 5-18.

Nelson, R. R., & Morris, M. G. (2014). IT project estimation: Contemporary practices and management guidelines. MIS Quarterly Executive, 13(1), 15-30.

Patanakul, P., & Shenhar, A. J. (2012). What project strategy really is: The fundamental building block in strategic project management. Project Management Journal, 43(1), 4-20.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide). Newton Square.

Rappaport, A. (1986). Creating shareholder value: The new standard for business performance. New York, NY: Free Press.

Rosemann, M., Recker, J., Safrudin, N., & Marketsmueller, R. (2012). Program and project management. In A. Uhl, & L. A. Gollenia (Eds.), A handbook of business transformation management methodology. Farnham, UK: Gower Publishing.

Rouse, B. W. (2005). A theory of enterprise transformation. Systems Engineering, 8(4), 279-295.

Safrudin, N., Rosemann, M., Recker, J., & Genrich, M. (2014). A typology of business transformations. 360°—the Business Transformation Journal, 10, 25-41.

Stiles, P., Uhl, A., & Stratil, P. (2012). Meta management. In A. Uhl, & L. A. Gollenia (Eds.), A handbook of business transformation management methodology. Farnham, UK: Gower Publishing.

Journal of Information Technology Theory and Application 19

Volume 17 Issue 2 Paper 2

The Standish Group. (2013). Chaos manifesto 2013—think big, act small. Retrieved from https://larlet.fr/static/david/stream/ChaosManifesto2013.pdf

Uhl, A., & Gollenia, L. A. (2012). A handbook of business transformation management methodology. Farnham, UK: Gower Publishing.

Wagner, H.-T., & Weitzel, T. (2012). How to achieve operational business-IT alignment: Insights from a global aerospace firm. MIS Quarterly Executive, 11(1), 25-36.

Winter, R., & Schelp, J. (2008). Enterprise architecture governance: The need for a business-to-IT method. In Proceedings of the 2008 ACM Symposium on Applied Computing (pp. 548-552).

Wu, W. W., Rose, G, M., & Lyytinen K. (2011). Recognizing and managing innovation points in large IT projects. MIS Quarterly Executive, 10(3), 121-132.

20 How to Structure Business Transformation Projects: The Case of Infineon’s Finance IT Roadmap

Volume 17 Issue 2 Paper 2

About the Authors

Maximilian Röglinger is an Associate Professor of Information Systems at the University of Bayreuth. Maximilian serves as Deputy Academic Director of the Research Center Finance & Information Management (FIM), where he co-heads the research group on customer relationship and business process management. Maximilian also works with the Project Group Business & Information Systems Engineering of the Fraunhofer FIT. Most of his work centers around business process management, customer relationship management, and digital transformation. He publishes in journals such as Business & Information Systems Engineering, Business Process Management Journal, Decision Support Systems, Journal of the Association for Information Systems, and Journal of Strategic Information Systems. Maximilian is highly engaged in projects with companies such as Deutsche Bank, Infineon Technologies, Radeberger Group, and Siemens. He earned his PhD at the University of Augsburg, and holds a Diploma in Business & Information Systems Engineering from the University of Bamberg.

Manuel Bolsinger studied Business Mathematics (BSc) and Finance & Information Management (MSc)

at the University of Augsburg and at the TU München, respectively. From 2010 to 2015, Manuel worked as a research associate at the Research Center Finance & Information Management (FIM), where he finished his doctoral thesis on value-based business process management in 2014. During his doctoral studies, he collaborated with various industry partners such as Infineon Technologies, Hilti, and GEWOFAG Holding.

Björn Häckel is an Interim Professor of Business Engineering with a major in Finance, Operations, and

Information Management at the University of Augsburg. Björn serves as Deputy Academic Director of the Research Center Finance & Information Management (FIM), where he heads the research group "IT- based Financial Management". He also works with the Project Group Business & Information Systems Engineering of the Fraunhofer FIT. His research topics include the application of financial methods to the evaluation and management of IT investments and IT portfolios. Moreover, he is working on the IT- enabled identification, quantification, and management of systemic risk in value networks. He publishes in journals like Business & Information Systems Engineering, Decision Support Systems, Electronic Markets, Journal of Decision Systems, Journal of Innovation and Technology Management, and The Data Base for Advances in Information Systems. He is highly engaged in projects with companies such as BMW Financial Services, Carl Zeiss, Deutsche Bank, and Infineon Technologies. He earned his PhD at the University of Augsburg, and holds a Diploma in Business Administration from the University of Augsburg.

Matthias Walter studied Business Administration at the University of Augsburg with major in Finance &

Information Management. Since 2010, he has worked as a research associate at the Research Center Finance & Information Management (FIM), where he finished his doctoral thesis on risk management in late 2015. During his doctoral studies, he further collaborated with industry partners such as GEWOFAG, Infineon Technologies, and Radeberger Group.

Copyright © 2016 by the Association for Information Systems. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than the Association for Information Systems must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or fee. Request permission to publish from: AIS Administrative Office, P.O. Box 2712 Atlanta, GA, 30301-2712 Attn: Reprints or via e- mail from [email protected].

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.