Lean Management of IT organizations

Lean Management of IT Organizations –

A Perspective of IT Slack Theory
Research-in-Progress

Jörn Kobus Markus Westner

TU Dresden OTH Regensburg
Dresden, Germany Regensburg, Germany
[email protected] [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.

Thirty Seventh International Conference on Information Systems, Dublin 2016 1

 Lean Management of IT organizations

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.

Thirty Seventh International Conference on Information Systems, Dublin 2016 2

 Lean Management of IT organizations

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

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

Thirty Seventh International Conference on Information Systems, Dublin 2016 3

 Lean Management of IT organizations

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 efficiency 5. However, the magnitude of efficiency
decrease is determined by the level of redeployability 6 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)

Thirty Seventh International Conference on Information Systems, Dublin 2016 4

 Lean Management of IT organizations

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)

Last Modified 04.08.2016 17:04 W. Europe Standard Time

Printed 13.12.2015 17:05 W. Europe Standard Time
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
QUELLE: 126 (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).

Thirty Seventh International Conference on Information Systems, Dublin 2016 5

 Lean Management of IT organizations

redeployability

Resource buffer Desired buffer Undesired buffer

(IT Slack theory)
Value Value adding Non-value adding, Non-value adding
(Lean IT) but necessary (waste)

redeployability
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.

Thirty Seventh International Conference on Information Systems, Dublin 2016 6

 Lean Management of IT organizations

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

Thirty Seventh International Conference on Information Systems, Dublin 2016 7

 Lean Management of IT organizations

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

Thirty Seventh International Conference on Information Systems, Dublin 2016 8

 Lean Management of IT organizations

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.

Thirty Seventh International Conference on Information Systems, Dublin 2016 9

 Lean Management of IT organizations

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.

Thirty Seventh International Conference on Information Systems, Dublin 2016 10

 Lean Management of IT organizations

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_transform
ing_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.

Thirty Seventh International Conference on Information Systems, Dublin 2016 11

 Lean Management of IT organizations

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.

Thirty Seventh International Conference on Information Systems, Dublin 2016 12