lean management of it organizations â•fi a perspective of ... · lean management of it...

Lean Management of IT organizations

Thirty Seventh International Conference on Information Systems, Dublin 2016 1

Lean Management of IT Organizations – A Perspective of IT Slack Theory

Research-in-Progress

Jörn Kobus TU Dresden

Dresden, Germany [email protected]

Markus Westner OTH Regensburg

Regensburg, Germany [email protected]

Susanne Strahringer

TU Dresden Dresden, Germany

[email protected]

Abstract

Lean Management has been successfully implemented in production organizations since several decades. The study at hand investigates the implementation of Lean Management to IT organizations (Lean IT). The study offers three contributions: First, it explains on a conceptual level how Lean Management can be transferred from production to IT organizations (philosophy, principles, tools). Second, it provides a theoretical perspective on why Lean IT can be beneficial for IT organizations (IT Slack theory). Third, it provides insights to the stated research questions (three benefits and three propositions) from an initial case study of an internal IT service provider for a large international insurance company (> US$25 Billion revenue; >20,000 employees; active in >120 countries) and lays out the research methodology and potential focus areas for further studies.

Keywords: Lean Management; Lean IT; IT Slack theory; Implementation; Application development and maintenance.



Introduction

Lean Management (LM) is considered the standard production mode in modern manufacturing (Rinehart

et al. 1997). While opponents of LM see it as just another management fad (Näslund 2013), proponents of LM see its applicability extending beyond only production organizations (Womack and Jones 1994). LM has been researched within the production literature for more than four decades (Stone 2012). However, not much research exists regarding the application of LM to IT organizations, so-called “Lean IT” 1 (Kobus and Westner 2015a). This situation is unfortunate as commonly mentioned objectives of LM implementations (e.g., the pursuit of best quality, lowest cost, shortest lead time, best safety, and highest

morale (Liker and Morgan 2006)) overlap with key issues IT executives are facing today: Luftman and Derksen (2012), for example, named their report on IT executives' key issues after a common proverb connected to LM: ‘Doing more with less’.

As leanness has a strong focus on simplicity and waste reduction, it can be used to lay a foundation throughout the whole IT organization to free up those resources needed for more demanding, yet compatible concepts such as agility (Conboy 2009, p. 340). These concepts can then be applied additionally and only where necessary. Using leanness as a pervasive concept throughout the IT organization - while preserving its simplicity claim - offers a more universal approach to improving efficiency and effectiveness than many of the other IT-related (mostly heavyweight and overly complex) management systems. Leanness' universality is due to its focus on philosophy and principles with only some of its tools being domain specific and thus needing adaptation. The universality of the approach also offers another opportunity by facilitating the identification of the underlying general mechanisms creating benefits to IT organizations. To this end we suggest to use the perspective of IT slack theory.

Considering the practitioner’s view, there seems to be broad interest in Lean IT, as reflected by activity on business-oriented social networks 2 or by publications of several management consultancies (Bain & Company 2016; McKinsey & Company 2016; The Boston Consulting Group 2012). In addition, several large organizations such as BBC Worldwide, Fujitsu Services, Tesco, TransUnion, or Wipro (CA 2009; Middleton and Joyce 2012; Staats et al. 2011) already deliver IT services internally or externally using Lean IT. However, since the majority of LM implementations fail to achieve their anticipated result (Liker and Rother 2011; Pay 2008), it is not only of interest how Lean IT can benefit IT organizations but also to understand its implementation process better. Therefore, the paper at hand tries to answer the following research questions:

(RQ 1) How can Lean IT benefit IT organizations?

(RQ 2) What are the factors influencing Lean IT implementation success?

The paper uses an empirical qualitative (case study) approach and is structured as follows: First, the term Lean IT is conceptualized and an overview of existing research is provided. Second, a theoretical frame for Lean IT is presented. Third, the research methodology is outlined. Fourth, initial results are discussed before fifth, an evaluation and an outlook on next steps is provided.

Background

Conceptualization

Building on previous research, we define Lean IT as “[…] a holistic management system based on philosophy, principles, and tools. Lean IT aims at systematic management of continuous improvement by reducing waste and variability as well as enhancing value and flexibility in all functions of an IT organization” (Kobus 2016, p. 1).

1 Kobus and Westner (2015a) conducted a database-driven literature review of more than 1,200 literature items. It showed that academic (peer-reviewed) literature penetration on Lean IT is currently low (only eleven items could be identified in total). 2 As of March 2016, the group Lean IT Service Management (LeanITSM) on www.linkedin.com counts more than 3.500 members, as of July 2016 3.700.



The term ‘IT organization’ is thereby understood as an organizational unit whose strategy has to align with the overarching business strategy. It is connected to suppliers from whom products and services are sourced as well as to customers to whom products and services are delivered. Products and services include especially applications management (e.g., enterprise architecture, application integration, and application development and maintenance) and ICT infrastructure management (e.g., networks, data centers, servers, client hardware). (Riempp et al. 2008)

As the origins of LM lie in production organizations, its transferability to service organizations is non-trivial and the subject of discussion (cf. Browning and Sanders 2012; Staats et al. 2011). We follow Arlbjørn et al.’s (2011) conceptualization of LM for production organizations regarding (1) Philosophy, (2) Principles, and (3) Tools to argue why LM is transferable to IT organizations on each of those levels. (1) Philosophy: The philosophy of LM is to reduce waste and develop customer value. Waste is “[…] any human activity which absorbs resources but creates no value” (Womack and Jones 1996b, p. 15) and value means “[…] capability provided to a customer at the right time at an appropriate price, as defined in each case by the customer” (Womack and Jones 1996b p. 311). Since this definition incorporates the concept of economic efficiency, it is generally transferable to IT organizations. However, especially waste might be of different nature in IT organizations as in production organizations (Hicks 2007). As an example, Al-Baik and Miller (2014) identified numerous sources of waste in IT organizations, e.g., over-provisioning of services (so-called gold plating), over-specification (analyses which do not support decision making), double handling (redundant work or data), waiting (for approval, information, or resources), or defects (unclear customer requirements). (2) Principles: In total, Arlbjørn et al. (2011, p. 282) mention five principles (following mainly Womack and Jones 1996a): “[(a)] Specify what does and does not create value from the customer’s perspective and not from the perspective of individual firms, functions and departments; [(b)] Identify all the steps necessary to design, order and produce the product across the whole value stream to highlight non value adding waste; [(c)] Make those actions that create value flow without interruption, detours, backflows, waiting or scrap; [(d)] Only make what is pulled by the customer; and [(e)] Strive for perfection by continually removing successive layers of waste as they are uncovered”. All five principles can be transferred to IT organizations. Principle (a) is about understanding the voice of the customer (in IT organizations often about understanding the business side of a company) and orientate own actions towards it. Principles (b) and (c) are about understanding key processes and their requirements as, e.g., inputs, dependencies, flows, and responsibilities. Value stream mapping (cf. Hines and Rich 1997) can be used to understand which steps in a process are value adding; non-value adding but necessary; and non-value adding (which means they are characterized as waste and can be removed). Principle (d) is ensuring the alignment of waste and value. Every service delivered that is not requested directly from the customer is characterized as waste – for example, software features that are rarely or never used (cf. Al-Baik and Miller 2014). The last principle (e) is describing what is known elsewhere as continuous improvement, which is also applicable to IT organizations. (3) Tools: Arlbjørn et al. (2011) enumerate a variety of tools used to achieve the previously described philosophy and principles including: Value Stream Mapping, 5S, Kanban, Pull Production, Information Boards, Overall Equipment Effectiveness and more. While we acknowledge that not all tools designed to support the production of physical goods are also suited to support production of virtual goods (as for example software (Staats et al. 2011)), Kumar Kundu and Bairi (2014) identified more than 50 Lean practices considered also important for IT organizations. Kobus (2016) states that a complete list of potential Lean IT tools does not exist as every tool helping to execute principles and philosophy of Lean IT can be considered as a Lean IT tool. Thus we argue, while not every single LM tool can be used in IT organizations, many (at least in their core idea) are transferable to IT organizations.

Related work

In order to determine the state of the art regarding Lean IT research, we conducted a database-driven literature review (Kobus and Westner 2015a) investigating more than 1,200 peer reviewed literature items (journals and conferences). While focusing on the identification of items on how LM can be applied to IT organizations (Lean IT), only eleven literature items could be identified.3 The results showed two main

3 More items (37) investigated IT as a function to support the implementation of LM in production organizations (for example by providing applications for performance management).



emerging themes. First, LM can be applied to IT organizations (Hicks 2007; Kumar Kundu and Bairi 2014) and second, LM has started to be applied to IT organizations mainly in application development and maintenance (Durrani et al. 2014; Lane et al. 2012; Pernstål et al. 2013; Vartiainen and Siponen 2012). The review resulted in the finding that research on Lean IT is still in a nascent state with low theory grounding of mostly formulative and interpretative research items. In addition, practitioner literature exists in several books (e.g. Bell and Orzen 2013; Müller et al. 2011; Orzen and Paider 2015) as well as on websites (e.g. Lean IT Association 2016; Lean Management Institute 2016).

With focus on RQ2 we conducted another database-driven literature review (Kobus and Westner 2015b) investigating in total more than 900 peer reviewed literature items (journals and conferences). Unfortunately, only four literature items could be identified focusing on Lean IT implementation success factors (Haley 2014; Holden and Hackbart 2012; Kundu and Manohar 2012; Manville et al. 2012). An analysis resulted in the identification of 13 implementation success factors which were classified into three categories: (1) Mindset and behavior including (a) Leadership involvement (What management needs to do in a transformation?); (b) Change culture & work ethic (Which employee’s attitude towards change helps most?); (c) Employee involvement (How to involve employees upfront and during the transformation?); (d) Clear vision/long term focus (How to create consistent perception of employees?); and (e) Customer focus (Is the voice of the customer the center of action?). (2) Organization and skills including (a) Training and education (How to teach employees and managers necessary skills?); (b) Existing skills (What type of skillset necessary/ desirable to start with?); (c) Organizational changes/standardization (Which roles, procedures, jobs or responsibilities need to be shifted/created?); and (d) Financial resources (Are necessary funds secured?). (3) Process facilitation and performance, including: (a) Performance management (How to set expectation/measure progress of LM implementation?); (b) Holistic approach (How to focus on overall improvement and not only optimization in sub-parts?); (c) Communication (When to communicate what?); and (d) Implementation facilitation (What is the change strategy and time planning?). (Kobus and Westner 2015b)

Theoretical framing

Organizational slack theory

The theory of organizational slack has been investigated in traditional strategy and organizational theory literature for a long time (e.g. Bourgeois 1981; Cyert and March 1963; Pfeffer and Salancik 1978). Bourgeois (1981, p. 30) defines organizational slack as “[…] that cushion of actual or potential resources which allows an organization to adapt successfully to internal pressures for adjustment or to external pressures for change in policy, as well as to initiate changes in strategy with respect to the external environment”. On the positive side, organizational slack strives for enhanced organizational effectiveness 4 by improving output quality, adaptability, and flexibility (Rahrovani and Pinsonneault 2012). On the negative side, organizational slack creation has been criticized because a primary part of organizational effectivity enhancement is achieved by sacrificing organizational efficiency5. However, the magnitude of efficiency decrease is determined by the level of redeployability6 of respective slack resources (Love and Nohria 2005).

IT slack theory

Rahrovani and Pinsonneault (2012) adapted the concept of organizational slack to IT organizations. They define (p. 170) IT slack as “[…] the cushion of actual or potential IT resources that allows IT or organizational adaptation to internal and external pressures and jolts”. IT slack thereby is seen as deliberately created by management in order to prepare for unanticipated and unintended events. IT slack aims to achieve two goals: (1) Creating options for the organization, e.g., to deliver appropriate service during demand spikes, to satisfy unplanned business requirements or regulatory changes; and (2)

4 Meaning the external standard of performance, i.e. to meet the demand of organizational stakeholders. Pfeffer and Salancik (1978) 5 Meaning the internal standard of performance, i.e. to maximize the output produced over the resources utilized. Rahrovani and Pinsonneault (2012) 6 Meaning the degree of (1) Alternative asset usage, and (2) Usage by alternative users without sacrificing the productive value. Williamson (1991)



Decreasing risk associated with IT investments and business value, e.g., to provide a fallback solution during hardware crashes or bugs in developed software. (ibid p. 170-171)

IT slack can be classified into six types as shown in Figure 1. The respective types are created by combining the slack types “IT artifacts” (e.g. buying extra software licenses or hardware servers as backup), “Human resources” (for example staffing of extra employees for a task), and “Time” (for example adding additional time buffer for an IS implementation) with IT asset types, i.e., “Infrastructure” assets and “Application” assets. For each type, the level of redeployability is indicated (the darker the background color of respective box, the less redeployable is the resource). For this, the concepts of absorbed IT slack vs. unabsorbed IT slack are distinguished. Absorbed IT slack refers to IT slack aiming to prevent a specific situation and hence can hardly be redeployed to other situations. For example, an overcapacity of highly trained windows developers does not help to overcome a too short number of Linux developers. In contrast, unabsorbed IT slack can be applied in various situations. For example desktop computers will be needed by most departments in a company and hence an overcapacity might count as unabsorbed IT slack. (ibid, p. 169-173)

Figure 1. Typology of IT slack (Rahrovani and Pinsonneault 2012, p. 184)

IT slack theory and Lean IT

IT Slack theory differentiates between desired resource buffers (useful) und undesired resource buffers (not useful). Undesired buffers can be considered waste and can and should be eliminated. Lean IT (philosophy, principles, tools) differentiates between value and waste, hence resources of all kinds can be seen as either value adding; non-value adding but necessary; or non-value adding (waste). Figure 2 visualizes the relation in between IT Slack and Lean IT from a resource buffer and value perspective. Both perspectives agree that the minimum of input resources needed to produce a pre-determined output is value adding. In addition, there is agreement that undesired buffers are non-value adding waste and should be removed. However, both perspectives seem to differ in their attitude towards ‘desired’ resource buffers. While Lean IT sees them as necessary but not desirable, IT Slack deliberately plans with buffer and focuses on its advantages. Depending on which side a critic stands, it is likely that s/he might either criticize Lean IT for too less focus on non-efficiency related matters or IT Slack for sacrificing organizational efficiency for organizational effectiveness. However, Lean IT can have a significant effect to maintain the equilibrium of efficiency and effectivity in an IT Slack context by (1) Creating transparency on the currently existing level of resource buffers; (2) Incorporating measures to reduce the level of necessary resource buffers (without decreasing the service level); and (3) Introducing redeployability measures in order to transform absorbed slack to unabsorbed slack (indicated as dashed line in Figure 2). With regard to a resource buffer perspective, redeployability means to transform undesired resource buffer to desired buffer, for example by increasing the workforce flexibility (‘multiskilling’). With regard to a value perspective redeployability means to transform a ‘wasteful’ resource to a non-value adding but necessary resource (for example to qualify employees to serve as temporary replacement) or to a valuable resource (for example to qualify an employee so he/she can work in a completely different field than previously).

La

st M

od

ified

04

.08

.20

16

17

:04

W. E

uro

pe

Sta

nd

ard

Tim

eP

rinte

d 1

3.1

2.2

01

5 1

7:0

5 W

. Eu

rop

e S

tan

da

rd T

ime

| 126QUELLE:



Figure 2. Understanding of resource buffers within IT slack theory and Lean IT

Methodology

To investigate RQ1 and RQ2, an empirical qualitative (explorative) multi-case-study approach is used. The methodology applied incorporates aspects from established case study research guidelines (Corbin and Strauss 1990; Eisenhardt 1989; Eisenhardt and Graebner 2007; Strauss and Corbin 1998; Yin 2003) and specifically follows the guideline by Pan and Tan (2011) who laid out a detailed eight step approach: (1) Access negotiation; (2) Conceptualizing the phenomenon; (3) Collecting and organizing the initial data; (4) Constructing and extending the theoretical lens; (5) Confirming and validating data; (6) Selective coding; (7) Ensuring theory-data-model alignment; and (8) Writing the case report.

(1) Access negotiation: We started by building up a network of possible case companies using the researcher’s personal as well as professional contacts. Several companies showed interest to participate. For the first case study, we decided for an internal IT service provider of a large international insurance company (details below) for the following reasons. First, within financial service institutions IT plays a preeminent role and receives high budgets. Second, recent acquisitions and a heterogeneous application landscape provide an interesting environment for a Lean IT implementation. Third, an internationally-renowned organization considered as an interesting case (Pan and Tan 2011). (2) Conceptualizing the phenomenon: Besides thorough literature reviews (Kobus and Westner 2015a, 2015b), we looked at Lean IT from two angles. First, we read non-technical literature to gather background information and second, we read broadly on different theories to be possibly applied in the context and also formulated first hypothesizes for the theoretical background (Kobus and Westner 2015b). (3) Collecting and organizing the initial data: Initial data was collected through a pre-scheduled interview with the Lean IT program manager. The program manager was seen as a gatekeeper to the organization. Together, the context of the Lean IT implementation was discussed, participants for the interviews were selected and the interview questionnaire was agreed upon. The interview questionnaire was refined in three pilot interviews with experienced researchers before the actual interviews took place. (4) Constructing and extending the theoretical lens: Our initial assumption that the group of resource-based-view theories (for example dynamic capabilities) could serve as a theoretical foundation for Lean IT proved insufficient as soon after the data collection had started. As it might be helpful to use it from a macro-economic perspective, it did not help to explain in more detail what benefits Lean IT provides regarding IT organizations. IT Slack theory offered this detail and proved helpful to explain why Lean IT can benefit IT organizations. (5) Confirming and validating data: Our findings were refined and tested continuously from interview to interview. Data triangulation with several on-field observations and documents of important meetings was performed. (6) Selective coding: All interviews were transcribed. Open and axial coding was used to determine common themes, building propositions and adapting the focus during the duration of the interview process. (7) Ensuring theory-data-model alignment: After each round of selective coding, it was checked if theoretical alignment in between the research context and the applied theory was still given or adaption was necessary. (8) Writing the case report: The case report is still to be written. As in a new area like Lean IT research, we consider the findings of one case study only as an intermediate step. Further case studies are necessary to deepen understanding and to validate the explorative findings more broadly. Therefore, steps (1-7) are to be repeated with further case companies, before the final case report can be authored.

129

Value

(Lean IT)

Resource buffer

(IT Slack theory)

Desired buffer

Non-value adding,

but necessary

Undesired buffer

Non-value adding

(waste)

Value adding

redeployability

redeployability



Preliminary findings

Context of case study

The case company is an internal IT service provider for a large international insurance company (> $25 Billion revenue; >20,000 employees; active in >120 countries). In the past, several acquisitions of the insurance company led to a heterogeneous environment of people, processes, and applications. The case company focuses on performance improvements as it expects a significant increase in demand in the near future due to upcoming challenges related to digitization. In addition, prices need to stay competitive as more and more external IT service providers aim to serve the insurance company. In order to increase efficiency (deliver more working software with the same number of employees) the case company decided to implement Lean IT in their application development and maintenance department.

The CIO was responsible for the implementation of Lean IT. A staggered implementation approach was used, i.e., in each ‘implementation wave’ three to six organizational groups (each group consisting of eight-18 employees) were involved. Each implementation wave consisted of four phases (analysis, design, execution, sustainability) and took around four months. A program manager steered the implementation operatively together with a project core team (four to six people). In each group, one or two group experts were selected by the group’s line manager to provide support during the implementation. A consulting company supported the setup of the transformation and took care of appropriate training for the core team.

The data collection process followed the methodology described above. In total, 14 interviews (eleven face-to-face and three via phone due to unavailability) were conducted with an average duration of 53 minutes. Data triangulation was ensured by four field visits and by review of archived documents of the most important meetings. The interviews took place seven month after implementation start, the implement-ation will continue for another 24 months. In order to get a comprehensive picture, we decided to categorize the most important employee roles into three employee categories and conduct interviews with members from each category: (1) Program manager and division heads (1+2 interviews); (2) Group leads and group experts (2+4 interviews); and (3) Core team and consultants (3+2 interviews). The interview questionnaire dealt mainly with the lessons learned during the implementation and if it was perceived successful (full interview questionnaire available from the authors upon request).

RQ 1: How can Lean IT benefit IT organizations?

Initial (qualitative) results of the analysis indicate three areas in which the IT organization mainly benefited from Lean IT: (1) Increased transparency; (2) Improved demand management; and (3) Increased skill management.

(1) Increased transparency: This was mainly achieved by the introduction of a whiteboard for operational daily work tasks, which was put in the team room (in case teams were locally spread, a software provided a virtual whiteboard) and included several information on, e.g., employee tasks, demand forecasts, performance tracking (KPIs were partly introduced as part of the implementation), unsolved problems, and the team morale. However, every group was free to design the whiteboard to fulfill its needs best. Every day, for around 15 minutes the group gathered (together with the group lead) and went through the respective categories. This meeting enabled a fixed and bidirectional (from group lead to group and vice versa) exchange of information and was greatly appreciated by both sides. Exemplary quote:

Especially important to me was to recognize who is working on what topic and that not only on a daily base but also for the forthcoming days and even further... Additionally, if we have a problematic situation, we can inform the team centrally using it [the whiteboard]. Alternatively, if we have escalations and so on and so on. I would say these are the main usages of our whiteboard. However, we also use it to ask how many hours a task takes… In this way we can check how accurate our estimations are. (Division head)

(2) Improved demand management: Before the Lean IT implementation took place, incoming work was predominantly received by acclamation, without clear rules for prioritization and feasible, agreed deadlines. During the implementation the number of entry channels for incoming work was reduced and clear prioritization rules with the customers were agreed upon. This and an additional analyses of incoming work (type, time, and amount of incoming work) helped to manage employee capacity more appropriate



according to the actual need of the customers and switch from a gut-based to a more fact-based management of resource buffers. Exemplary quote:

Generally it [demand management] worked per acclamation... There were three people [of three business departments] of whom each prioritized his/her own topics and not on overarching base... This lead to a constant reprioritization [for us]... And then we created a format that was also supported by the business division [deciding jointly with all business departments in one session on IT priorities]. (Core team member)

(3) Increased skill management: A central measure of Lean IT to increase the workforce flexibility was the so-called ‘multi-skilling’, which aimed to transfer and build skills of employees with regard to the group needs. For this, a to-be state of the group’s required capabilities was captured and compared to the current state. The gaps were then analysed, prioritized and transferred in a structured skill-development plan for the group. In this way, skill gaps in between employees and the number of head monopolies were reduced and the management of absences could be improved. Exemplary quote:

We also had a strategic look at head monopolies: Do they exist? Which do we need to eliminate? Where do we need to establish absence management? … And in which topics everybody belonging to a specific unit should have a certain level of minimal knowledge? (Group expert)

All benefits can be directly related to the theoretical framing of IT Slack theory. (1) Increased transparency helped to understand the level of current resource buffers (however, mainly focusing on ‘human’ and ‘time’ resource type (compare Figure 1), as the investigation focused on the application development and maintenance department), and in this way enabled a critical reflection of their adequacy compared to current priorities from a group perspectives. (2) Improved demand management helped to reduce the necessary level of resource buffers. By reducing the number of entry channels, introducing a clear allocation of work packages to employees with regard to group priorities and standardizing the entry channel for incoming work packages as far as possible, the level of resource buffers could decrease as planning was more fact based compared to the previous process to establish the level of resource buffers. (3) Increased skill management helped to enable redeployability of resources in order to transform absorbed slack to unabsorbed slack by increasing employee flexibility with regard to group needs in a systematic way.

Benefits (1) and (3) can be considered as in line compared to related literature because increased transparency and improved skill management can each be seen as a fundamental enabler of overarching benefits such as increased quality, lower cost, and higher efficiency which are mentioned in literature (for example Bell and Orzen 2013; Bhasin 2015; Liker and Morgan 2006). Regarding benefit (2), improved demand management can help to increase customer satisfaction (Bhasin 2015) by better fulfilling customer demand on time and in order (appropriate prioritization of requests).

RQ 2: What are the factors influencing Lean IT implementation success?

The interview analysis resulted in more than 70 lessons learned which were classified for each of the three employee categories. In order to achieve highest validity of results, we decided to focus only on the intersection of lessons learned which were mentioned by all three employee categories. We obtained three propositions for a successful Lean IT implementation, which we believe are of special interest to practitioners.

Proposition 1: Responsibility for the implementation needs to stay with employees (bottom-up). All employee categories emphasized that Lean IT is a bottom-up change program. During the implementation phase - together with the core team - group specific problems are analyzed, possible solutions discussed and then agreed upon. However, the responsibility for the execution of this solutions remains solely with the group itself. Therefore, it is not possible to simply transfer identified solutions in between groups. Each group has to undergo the same process in order to understand what their specific problems are and agree jointly to solutions. Hence it is important to include all group employees early upon in the analysis of the group’s work – this can either be done in an informative and transparent way (presenting to the group which analysis is done why and how) or in an inclusive way while actively involving the group itself. Exemplary quote:

‘Well, that is a superb result [of first wave]. You already defined many measurements which now can be rolled out to all groups [within the IT organization]’ (Board member). Then I replied ‘No! That would be the biggest



mistake one can make, as this again would be a top-down approach. This will not work […] as the employees will not accept it. […] Let the employees develop their improvement ideas by themselves!’ (Group lead)

Proposition 2: Group experts need to be selected carefully. The group expert holds direct relations to employees (a group expert is usually on the same organizational level as the other employees), the core team and the group lead. In an environment aiming to foster empowerment and bottom-up responsibility the group expert is an important role to directly influence its peers. The characteristic of an appropriate group expert include possessing a strong network, being well recognized within the team, action oriented and analytical. The group expert does not need to be the most knowledgeable person in the team. Depending on the group structure (different key topics, groups with clear leading structure) it might make sense to have two group expert instead of one. Exemplary quote:

The group lead needs to point out, that it [Lean IT] is important for the company, that it is also important for the division, and that it is in the end important for the employees. And it is always better if someone else [except the group lead] also argues that way… At this point, the group experts are even more important compared to the group lead…. It helps, if you have someone from the circle of colleagues. And that is exactly the group expert, who is an ambassador of the topic [Lean IT]. (Core team member)

Proposition 3: Implementation of Lean IT cannot be done ‘on-the-fly’. The implementation of Lean IT takes time and effort. This is especially true for the analysis phase as well as the design phase in which group leads and group experts can be required to work up to half of their working hours exclusively towards a Lean IT implementation. In addition, for the employees of the group to reorganize their work it takes time and effort before performance can increase. In order for a group (especially for the group lead) to plan accordingly, it is therefore important to communicate the expected additional workload transparently before a Lean IT implementation starts. If necessary, Lean IT activities need to be prioritized compared to daily work - especially during the first weeks of implementation. Exemplary quote:

A group lead needs to devote roughly 30% of his working hours to a Lean IT implementation. Below 30% it won't work. And especially in the first two phases [analysis phase, design phase] it is possibly even a bit more... Whereby I said to my colleagues: ‘Lean IT is actually an original task of leadership. That, what you are doing here is not on top on your daily work, but it is a different type of leadership you should use anyways’. (Group lead)

Compared to other relevant studies (Haley 2014; Holden and Hackbart 2012; Kundu and Manohar 2012; Manville et al. 2012), especially propositions 1 and 2 are surprising as they were not emphasized so far. Regarding proposition 1, all 14 interviewees mentioned, that the biggest difference between Lean IT and other change programs they experienced is, that they see Lean as a true bottom-up driven approach in which it is the responsibility of the group to implement it (however, with help during the implementation process). This finding is consistent with proposition 2, as – in contrary to other studies – there is a clear focus on the importance of well-performing group experts (bottom-up) in addition to existing management support (top-down) and not only the latter.

Contributions, limitations, and next steps

The paper offers several contributions to the existing body of IS knowledge. First, it explains on a conceptual level how LM can be transferred from production to IT organizations (philosophy, principles, tools). Second, it provides a theoretical perspective on why Lean IT can be beneficial for IT organizations (IT Slack theory). Third, it provides insights (three benefits and three propositions) from an initial case study and lays out the research methodology for further studies. While we provide a brief reflection of this study’s findings in the light of the results of two thorough literature reviews, a more detailed comparison of results with further literature items is left for future work. Future work also will need to understand IT Slack in more detail regarding each of Lean IT’s three levels: philosophy, principles and tools. In addition, future work will need to validate the benefits and propositions of the initial case study. For this, qualitative as well as quantitative research instruments could be applied. As the case company applied Lean IT only on their application development and maintenance department, further research should investigate especially the application of Lean IT to infrastructure services and possibly IT governance and reflect given results critically. Since this research focused only on possible benefits of Lean IT, a broader research effort also needs to investigate potential downsides.



References

Al-Baik, O., and Miller, J. 2014. “Waste identification and elimination in information technology organizations,” Empirical Software Engineering (19:6), pp. 2019-2061.

Arlbjørn, J. S., Freytag, P. V., and de Haas, H. 2011. “Service supply chain management: A survey of lean application in the municipal sector,” International Journal of Physical Distribution & Materials Management (41:3), pp. 277–295.

Bain & Company 2016. Lean Six Sigma / Lean Manufacturing / Six Sigma. http://www.bain.com/consulting-services/performance-improvement/lean-six-sigma.aspx#1. Accessed 7 March 2016.

Bell, S. C., and Orzen, M. A. 2013. Lean IT: Enabling and sustaining your lean transformation, Boca Raton, FL: CRC Press.

Bhasin, S. 2015. Lean management beyond manufacturing, Cham: Springer International Publishing. Bourgeois, L. J. 1981. “On the measurement of organizational slack,” The Academy of Management

Review (6:1), pp. 29–39. Browning, T. R., and Sanders, N. R. 2012. “Can innovation be lean?” California Management Review

(54:4), pp. 5–19. CA 2009. Masters of Lean IT.: How 3 visionary IT executives maximize value and minimize waste.

http://www.ca.com/us/~/media/files/brochures/masters-of-lean-it_204013.aspx. Accessed 27 October 2015.

Conboy, K. 2009. “Agility from first principles: Reconstructing the concept of agility in Information Systems development,” Information Systems Research (20:3), pp. 329–354.

Corbin, J. M., and Strauss, A. 1990. “Grounded theory research: Procedures, canons, and evaluative criteria,” Qualitative Sociology (13:1), pp. 3-21.

Cyert, R. M., and March, J. G. 1963. A behavioral theory of the firm, Englewood Cliffs, NJ: Prentice-Hall, Inc.

Durrani, U., Pita, Z., Richardson, J., and Lenarcic, J. 2014. “An empirical study of lean and agile influences in software configuration management. PACIS 2014 proceedings. Paper 320.,” .

Eisenhardt, K. M. 1989. “Building theories from case study research,” Academy of Management Review (14:4), pp. 532–550.

Eisenhardt, K. M., and Graebner, M. E. 2007. “Theory building from cases: Opportunities and challenges,” Academy of Management Journal (50:1), pp. 25–32.

Haley, M. 2014. “Information technology and the quality improvement in defense industries,” The TQM Journal (26:4), pp. 348–359.

Hicks, B. J. 2007. “Lean information management: understanding and eliminating waste,” International Journal of Information Management (27:4), pp. 233–249.

Hines, P., and Rich, N. 1997. “The seven value stream mapping tools,” International Journal of Operations & Production Management (17:1), pp. 46–64.

Holden, R. J., and Hackbart, G. 2012. “From group work to teamwork: A case study of “lean” rapid process improvement in the ThedaCare information technology department,” IIE Transactions on Healthcare Systems Engineering (2:3), pp. 190–201.

Kobus, J., and Westner, M. 2015a. “Lean management of IT organizations: A literature review". PACIS 2015 proceedings.

Kobus, J., and Westner, M. 2015b. “Lean management of IT organizations: Implementation success factors and theoretical foundation". AMCIS 2015 proceedings.

Kobus, J. 2016. “Demystifying Lean IT: Conceptualization and definition". MKWI 2016 proceedings. Kumar Kundu, G., and Bairi, J. 2014. “A scale for measuring the applicability of lean practices in IT

support services,” Journal of Enterprise Information Management (27:5), pp. 623–643. Kundu, G., and Manohar, M. B. 2012. “Critical success factors for implementing lean practices in IT

support services,” International Journal for Quality research (6:4), pp. 301–312. Lane, M., Fitzgerald, B., and Ågerfalk, P. 2012. “Identifying lean software development values". ECIS 2012

proceedings. Paper 15. Lean IT Association 2016. Lean IT Association. http://www.leanitassociation.com/. Accessed 21 March

2016. Lean Management Institute 2016. lean.org - Lean Enterprise Institute | Lean Production | Lean

Manufacturing | LEI | Lean Services. http://www.lean.org/. Accessed 21 March 2016.



Liker, J., and Rother, M. 2011. Why Lean Programs Fail. http://www.lean.org/Search/Documents/352.pdf. Accessed 5 October 2015.

Liker, J. K., and Morgan, J. M. 2006. “The Toyota way in services: The case of lean product development,” Academy of Management Perspectives (20:2), pp. 5–20.

Love, E. G., and Nohria, N. 2005. “Reducing slack: The performance consequences of downsizing by large industrial firms, 1977-93,” Strategic Management Journal (26:12), pp. 1087–1108.

Luftman, J., and Derksen, B. 2012. “Key issues for IT executives 2012: Doing more with less,” MIS Quarterly Executive (11:4), pp. 207–218.

Manville, G., Greatbanks, R., Krishnasamy, R., and Parker, D. W. 2012. “Critical success factors for lean six sigma programmes: A view from middle management,” International Journal of Quality & Reliability Management (29:1), pp. 7–20.

McKinsey & Company 2016. Lean IT | Business Technology. http://www.mckinsey.com/business-functions/business-technology/how-we-help-clients/lean-it. Accessed 7 March 2016.

Middleton, P., and Joyce, D. 2012. “Lean software management: BBC worldwide case study,” IEEE Transactions on Engineering Management (59:1), pp. 20–32.

Müller, A., Schröder, H., and Thienen, L. v. 2011. Lean IT-management: Was die IT aus produktionssystemen lernen kann, Wiesbaden: Gabler.

Näslund, D. 2013. “Lean and six sigma: Critical success factors revisited,” International Journal of Quality and Service Sciences (5:1), pp. 86–100.

Orzen, M. A., and Paider, T. A. 2015. The Lean IT field guide: A roadmap for your transformation, Boca Raton, FL: Taylor & Francis.

Pan, S. L., and Tan, B. 2011. “Demystifying case research: A structured–pragmatic–situational (SPS) approach to conducting case studies,” Information and Organization (21:3), pp. 161–176.

Pay, R. 2008. Everybody's jumping on the Lean bandwagon, but many are being taken for a ride. Access date: 20.07.2015. http://www.industryweek.com/articles/everybodys_jumping_on_the_lean_bandwagon_but_many_are_being_taken_for_a_ride_15881.aspx. Accessed 7 March 2016.

Pernstål, J., Feldt, R., and Gorschek, T. 2013. “The lean gap: A review of lean approaches to large-scale software systems development,” Journal of Systems and Software (86:11), pp. 2797–2821.

Pfeffer, J., and Salancik, G. R. 1978. The external control of organizations: A resource dependence perspective, Palo Alto, CA: Stanford University Press.

Rahrovani, Y., and Pinsonneault, A. 2012. “On the Business Value of Information Technology: A Theory of Slack Resources,” in Information Systems Theory: Explaining and Predicting Our Digital Society, Vol. 1, K. Y. Dwivedi, R. M. Wade and L. S. Schneberger (eds.), New York, NY: Springer New York, pp. 165–198.

Riempp, G., Mueller, B., and Ahlemann, F. 2008. “Towards a framework to structure and assess strategic IT/IS management". ECIS 2008 proceedings. Paper 53.

Rinehart, J. W., Huxley, C. V., and Robertson, D. 1997. Just another car factory?: Lean production and its discontents, Ithaca, NY: Cornell University Press.

Staats, B. R., Brunner, D. J., and Upton, D. M. 2011. “Lean principles, learning, and knowledge work: Evidence from a software services provider,” Journal of Operations Management (29:5), pp. 376–390.

Stone, K. B. 2012. “Four decades of lean: A systematic literature review,” International Journal of Lean Six Sigma (3:2), pp. 112–132.

Strauss, A. L., and Corbin, J. M. 1998. Basics of qualitative research: Techniques and procedures for developing grounded theory, Thousand Oaks, CA: Sage Publications.

The Boston Consulting Group 2012. Transforming IT with Lean. https://www.bcgperspectives.com/content/interviews/it_transformation_it_performance_transforming_it_with_lean/. Accessed 7 March 2016.

Vartiainen, T., and Siponen, M. 2012. “What makes information system developers produce defective information systems for their clients?". PACIS 2012 proceedings. Paper 107.

Williamson, O. E. 1991. “Comparative economic organization: The analysis of discrete structural alternatives,” Administrative Science Quarterly (36:2), pp. 269–296.

Womack, J. P., and Jones, D. T. 1994. “From lean production to the lean enterprise. (cover story),” Harvard Business Review (72:2), pp. 93–103.

Womack, J. P., and Jones, D. T. 1996a. “Beyond Toyota: How to root out waste and pursue perfection,” Harvard Business Review (74:5), pp. 140–158.



Womack, J. P., and Jones, D. T. 1996b. Lean thinking: Banish waste and create wealth in your corporation, New York, NY: Simon & Schuster.

Yin, R. K. 2003. Case study research: Design and methods, Thousand Oaks, CA: Sage Publications.