Proposal for a holistic research

approach to studying the implementation

of IT

Camilla Kølsen de Wit

caw@hha.dk
Dept. of Information Science
The Aarhus School of Business, Denmark

Abstract
A focus on the implementation of IT in business process reengineering projects
implies attention on the humans whose job it is to realize the implementation plans,
and concern for the management processes involved. This paper is a proposal to
how we can study the work process of implementing IT in radical organizational
innovations projects through the use of the critical incident technique. The goal is
to formulate critical success factors for the implementation process of IT in
business process reengineering projects. These critical success factors can be used
to guide the behavior of people involved in the implementation process. It is a
holistic research approach.
Key words: implementation of IT, organizational innovation, business process
reengineering, the critical incident technique, job analysis and job description, critical
success factors, holistic research approach.

Introduction
It might be said that the implementation of IT does not have a very close connection to
the ISR field, since the nature of implementation demands a broad sample of disciplines
and skills. Implementation involves the organization and the decision processes and
thereby it gets heavily entangled in theories within management science and the social and
political sciences. Also, implementation has a more withdrawn existence within the
Scandinavian IS research, as this seems to be oriented towards the design, the
development, and the use of computers and their applications.1 In the American IS
literature there is a much stronger concern with the implementation of IT sided with an
equally strong concern for the various uses of IT in connection with the business, e.g.
regarding handling of the interdependence of interfunctional business processes (Hammer
1987; Rockart & Short 1989) competition (Cash jr. & Konsynski 1985; Ives & Learmonth
1984; McFarlan 1984; Porter & Millar 1985) and the likes.

1
See the foreword to the proceedings from the Third Decennial Conference:
Computers in Context: Joining Forces in Design, 1995 which very much can be taken as
a position of contemporary Scandinavian ISR.
 However, as Nord & Tucker (1987) writes:
‘ (…) implementation activities have much more to do with the innovation’s success than do
design activities, yet so little is known about them.’
Nord & Tucker are concerned with organizational innovation, and large scale IT projects
can be viewed as organizational innovation (See for instance Currie & Willcocks 1997;
Davenport 1993; Grover et al. 1993; Tidd et al.1997).
Sometimes the borderlines between development and implementation are not so
well defined as is the case when the approach is evolutionary prototyping, other times they
are quite defined. When large scale IT projects are involved, there will usually be a gap
between the analyses, the planning and design, and the actual implementation because the
sheer size of the project will demand careful planning and scheduling. In these cases we
are stuck with a very limited amount of knowledge of how to implement the plans for
innovative change enabled by IT. It is the custom simply to advise the practitioners to
customize the implementation to the specific context in question.
The concepts of success criteria and the corresponding critical success factors
(CSF) (Rockard 1979) are two interrelated management tools that can be used to sustain
the implementation process. The success criteria are formulated goals for the project
(Wateridge 1996; 1997) and the success factors are the activities supposed to lead to
fulfilment of the success criteria and thereby secure a successful project. Critical success
factors are based on the assumption that a limited amount of criteria, critical of the
outcome of a project or endavour, can be identified, and that these criteria can be
manipulated by the managers. Thereby they are a tool for forecasting and managing
projects. CSFs are strongly related to the concept of strategy. (Ghemawat 1991; Sørensen
& Grunert 1994)
But, alas, the success factors are often far too general and formulated on an
abstract level which means that they cannot be used as guidelines to the human behavior
that will result in a successful implementation. The following examples of CSFs
concerning successful innovation are taken from Rothwell (1992):
‘Implementing careful planning and project control procedures: committing resources to up-
front screening of new projects: regular appraisal of projects.’ Or ‘Efficiency in
development work and high quality production: implementing effective quality control
procedures; taking advantage of up-to-date production equipment.’
It may be good to know that a large scale IT project needs ‘efficiency in development
work and high quality production’, but exactly what does one have to do to achieve this ?
We don’t know. Ghemawat (1991) mentions this as a fundamental critique of the concept
of critical success factors. Also, the evidence supporting the sets of factors is often
anecdotal, single-case study, or theory derived rather than empirical (Pinto & Slevin
1987). In other words: we have this job of implementing IT projects, but we don’t have an
adequate job description for it.
In the contemporary concept of Business Process Reengineering (BPR), radical
organizational innovation, strategy, and IT come together and create the potential for
large scale change. BPR has ridden the corporate world for the last couple of years and
we are certainly not short of so-called ‘cookbooks’ for how to conduct reengineering
projects or general guidelines. Also, there are formulated critical success factors for BPR
projects (Ascari, Rock & Dutta 1994; Bashein, Markus & Riley 1994; Bartram 1992;
Harvey 1995; Hiatt & Hope 1997; Kaplan & Murdock 1991), but nowhere are they:
•concrete to what actions must take place
 •connected to the handling of IT

The scope of this paper is to interpret BPR as a radical organizational innovation project
combining technical and administrative innovation (See Damanpour 1991). These projects
are analogous to large scale IT projects. The problem is to master implementation. It is
assumed that the general idea of CSFs is sound if they could be specific about what
actions to take in order to implement large scale IT projects. A research approach to solve
this problem will be proposed.
Even though both Rockart (1979) and Bullen (1995; 1995a) have proposed a
‘CSF approach or method’, their procedures will not be taken into account within the
present study. The methods are in both cases an interview procedure heavily relying on
the managers’ views on critical factors for success. In relation to studying the
implementation of large scale IT projects with the intention of formulating CSFs, the
problems with the Rockart/Bullen framework are twofold:
First, the CSF approach as envisioned by Rockart and Bullen, respectively, is
related to formulating corporate strategy, goals and related information needs, and is not
related to the implementation of the strategies. In other words, the CSFs concern the
things that must go right to ensure organizational success according to strategy.
Secondly, and as mentioned by Grunert & Ellegaard (1993), the executives’
perceptions of critical success factors may be wrong, leading to catalogues of CSFs which
lack external validity. It is acknowledged that psychological mechanisms may cause
decision makers to misattribute causes of success (Weiner et al. 1972). Considering that
the purpose of the study is to create a job description for the implementation activities, the
two mentioned grounds disqualify the procedure proposed by Rockart (1979) and Bullen
(1995; 1995a). It is mandatory to focus on concrete formulations of the critical activities
during the implementation process. The executives alone cannot provide an exhausted
description of the process and their statements need not be correct.
Another possible point of departure might have been the existing pool of critical
success factors for large IT projects. Here the problem is that they are often the product
of consultancy practice. This means that the factors are not validated as research results in
a systematic way (Grønhaug & Falkenberg 1990). Success factors are too often an
aggregated set of experience which somebody has collected, being a result of his or her
particular practice and knowledge.
To sum up: a method is needed which in a systematic way yields results that can
be validated, and which relates to the implementation of IT enabled innovation projects
from the view point of the people involved in the critical activities and not only from the
executives’ point of view.

Theoretical definitions
This section accounts for the concepts used in this article. The following will be defined:
• Critical success factors
• Business process reengineering
• The critical incident technique
Critical Success Factors
In connection with the implementation, the critical success factors are to be differentiated
from the success criteria (Wateridge 1997; 1996). The success criteria are used for
judging project success; if the success criteria are satisfied then the project is a success.
Often, the used criteria are on time, within budget, and to specification. The success
factors, on the other hand, relates to the performances employed to deliver these criteria
(Wateridge 1997).
The original use of the concept of CSFs, however, was not related to performance
but to information management. First Daniel (1961) and later Rockart (1979) used the
critical success factors as a mean to provide top management with the information they
needed in order to make the company prosper. The definition of the critical issues for the
company would help the executives define their specific information needs, and this would
be the model for designing the MIS of the company (see for instance Shank, Boynton &
Zmud 1985). Thus critical success factors are defined (Grunert & Ellegaard after Bullen &
Rockart 1981):
(…) the limited number of areas in which satisfactory results will ensure successful
competitive performance for the individual, department or organization. Critical success
factors are the few key areas where 'things must go right' for the business to flourish and for
the manager’s goals to be attained.’
Alongside this use of CSFs, a similar concept has been used in the innovation literature.
These studies have been concerned with discovering factors associated with success and
failure in industrial innovation (Rothwell 1977; 1992)., e.g. factors influencing innovations
(Schewe 1991). The need for finding these factors associated with success relates to the
increasing dynamics of the environment and uncertainties in technology, budgets, and
development processes (Pinto & Slevin 1987). In the projects a CSF describes an activity
that must go right in order to achieve the success criteria of the project.
It is not possible to pin-point the exact interface between the business oriented
CSF of Rockart & Co. and the critical success factors in the innovation and
implementation literature. They draw on the same substance and the basic idea that there
are a few factors which are decisive for the success of the company, and that these factors
can be ascertained (Grunert & Ellegaard 1993). Also, both concepts emphasize an
organizations-wide perspective (Jenster 1987). The term ‘critical success factor’ is used
within both contexts without further explanation, and it is probably the case that
nowadays the term has a general definition like: managers must focus their attention on
the few key areas where ‘things must go right’ for the business/the project/the... to thrive.
Within the current setting, however, the critical success factors will be related to
the implementation of organizational innovation using IT on a large scale. In connection
with a similar broad CSF-definition, Jenster (1987) makes a reference to the creator of the
research method that will be proposed in this paper, J. C. Flanagan. Flanagan has worked
with critical requirements for job descriptions. His method, the Critical Incident
Technique is a result of a need to determine the successful handling of the critical
incidents in the work processes. The goal of the method is both to identify the critical
incidents and to describe the successful performance in relation to the incidents. In this
way the critical success factors of implementation can be systematically described in
concrete action oriented terms from the view of all personnel involved.
However, first we will turn our attention to the definition of the sort of IT enabled
radical organizational innovation that the CSFs will be about.
Business Process Reengineering
Business Process Reengineering is an IT enabled organizational-wide innovation of the
business processes. It is a very post modern conceptualization in that it is made up of bits
and pieces from many theories of management, in that it focuses on effectiveness and
performance as the narrative of the business, and in that it embraces the post modern
systemic theories of change which are low on humanistic consciousness2. This cocktail
creates paradoxes within the concept that opens for many alternative interpretations and
forms of implementations.

The Concept of Business Process Reengineering

It is the view of this author and others (Francis & Southern 1995; Taylor 1995) that BPR
is one answer to the changes in the life conditions of the corporate organizations.
Together with the search for exellence, JIT, strategic change and the learning
organization, BPR is employed to change the organization of the company in response to
the changed life conditions in the corporate environment. The point is that neither BPR
nor the others are isolated management fads, they are part of the same business process
analysis paradigm (Coombs & Hull, ?) which taken together creates the contemporary
way of organizing business innovation and change.
No one really knows where BPR originated from or who introduced it. It is the
custom to attribute BPR to either Hammer (1990), Hammer & Champy (1993) or
Davenport & Short (1990), Davenport (1993) depending on the likes of the reader.
Davenport (1996) writes:
‘Of course, the real creators of reengineering weren’t consultants or academics. They were
real people with real problems to fix. Inside companies like Ford, Hewlett Packard, and
Mutual Benefit Life, managers were experimenting with new uses of information technology
to link processes that cut across functional boundaries. But they didn’t call their work
reengineering; they didn’t have elaborate “change models”; they certainly didn’t see a
movement in the making. All that came later.’ (Davenport 1996, page 70).
BPR wasn’t ‘made up’, it evolved in practice as a result of the circumstances and this is
the reason why it popped up in so many different places and contexts at the same time3.
This is confirmed by the many different versions of the historic roots of BPR (see for
instance Coombs & Hull ?; Davenport 1993; Earl 1994; Grint 1994; Iden 1995). BPR has
no roots, it is not a theoretical construct.
By reviewing the four ‘original’ BPR texts by Hammer and Davenport and their
associates mentioned above, it is possible to propose a ‘classic’ definition of BPR. It is
also possible with the help of a cronological tabulation of 55 central articles of BPR from
1991-19984 to state that this ‘classic’ concept of BPR does not change during the years. It
receives a lot of very critical comments as BPR gets tried out in practice, but the
comments remain alternatives to the classic definition. In other words: the critique is not
integrated with the concept of BPR. Therefore it is reasonable to define BPR on the
background of the ‘original’ texts.

2
E.g. Autopoeisis, chaos theory and the likes.
3
If one tries to backtrack BPR it is evident that it was going on in various
academic surroundings, the consultants were busy working with it and the practitioners
were also trying it out. From approx. the mid 80’s till now.
4
Unpublished work by the author.
 It is striking how alike the articles of both Hammer (1990) and Davenport & Short
(1990) are compared to their respective books published in 1993. The books are
prolonged discussions of the articles. Hammer and later Hammer & Champy are
concerned with why you should do reengineering and what the result will be for your
company. Davenport & Short and later Davenport are concerned with how to do BPR,
with what means and within which context. In a very nice way they complement each
other’s work. The ‘classic’ definition of BPR goes like this:
• The goal of BPR is fundamental and radical innovation of the business processes
in order to improve the performance of the business in a dramatic way. This implies new
strategies for work, new process designs, and the implementation of the changes in the
complex context of human, technological, and organizational dimensions.
• The means of BPR is holistic, intrafunctional process thinking using IT as an
enabler and as the mediating structure between the business processes that will create a
competitive advantage and economic gain for the company. The process thinking must be
discontinuate.
• The rationale of BPR is the changed life conditions for the corporate companies
which have turned their business processes into aged and useless processes oriented
towards wrong product goals. It is no use to go on paving these processes in IT, they
have to be redesigned according to the new conditions of the environment.

The Implementation of IT in BPR projects

Following Craig & Yetton (1992 and 1994) BPR in general can be viewed as a problem of
implementation. According to the framework in Scott-Morton’s book from 1991, which
is a result of the Management in the 90’s program at MIT, the companies have to strive
for a strategic alignment of the business goals, the internal structure and IT in
correspondence to the surrounding environment. The same tread of thoughts can be found
in the works of Grover & Co. (see for instance Grover et al 1993; Teng et al. 1994;
Jeong, Grover, Kettinger & Teng 1995). This is often termed as the ‘strategic fit’.
The point is that the strategy, the plans, and the designs for the business processes
are made beforehand and then they have to be implemented in the organization, typically
with the help of adjustments in the reward systems and other cultural/organizational
controlling devices (see for instance Oliver 1993; Schnitt 1993; White 1993). The role for
IT in this set up is a reactive role. IT is a part of the implementation scheme and not part
of the planning scheme (Craig & Yetton 1992). In order to get the potential out of the IT,
it must be used proactively in the planning and redesigning sequences.
Implementation of IT in these kinds of projects, then, is not merely the actual
setting up of the machines, education of users, obtaining of their acceptance, and turning
on the computers, it is more so a matter of developing the plans and strategies along with
their realization in IT and structural/organizational changes. In other words: the
implementation of IT connects to the very first process designs and strategy and structure
(incl. IT) should evolve together.
When reviewing the critique that is applied to the ‘classic’ concept of BPR, it is
clear that it is tremendously complex and hard to implement the radical and fundamental
IT enabled BPR projects. One problem is that of the time horizon. It takes 3-5 years to
implement, however, no management will accept waiting more than a year at the most
before the (successful) results become apparent. Another problem is getting ‘ the turkeys
to vote for Christmas’, e.g. persuading the employees to show an enthusiastic attitude to
the project. Davenport (1996) writes that the implementation was never meant to be
‘mindless bloodshed’ with the metaphors of warfare.
These social, political, and human aspects of the BPR projects only adds to the
implementation problems. Our limited knowledge of how to handle the accumulated
activities of the implementation of large scale IT projects is seriously holding us down. If
we want to know more and proceed in a more scientific way than leaning on the
experience of consultants, this must be researched.

The Critical Incident Technique and its scientific roots

The Critical Incident Technique (CIT) originated within the field of Industrial Psychology5
(see for instance Campbell et al. 1970; Cronbach 1970; Dunnette 1983; Ghiselli 1951;
Gilmer & Deci 1977) as a job analysis technique. Industrial Psychology is concerned with
the human factors of the production system, for instance personnel selection, personnel
training, personnel evaluation etc. In order to execute these tasks it is necessary to make
analyses of the jobs. It is a branch of psychology that is founded in applied and behavioral
science as opposed to the more traditional branch of psychology founded in therapeutic
science and ideas.
Traditional job analysis described the tasks of the job, e.g. the routines, but hereby
the critical aspects of the job got overlooked. Getting a person qualified to handle the
routine work is not very complicated, but how can it be determined what are the necessary
knowledge, skill and abilities to handle a crisis/critical situation ? These situations are
often very expensive if not handled correctly and quickly. The classic example of the
worker at the bottle assembly line where the bottle caps are stuck to the bottles. The
critical aspect of his job is to ensure that the machine always has caps in its storage to
apply to the bottles, because the whole assembly line will have to be stopped if his
machine stops. However, the actual actions connected to ensuring this are few and
seldom, so they might very well not be noticed at all in a normal job analysis.
The argument is that a useful job description has to describe the critical aspects of
the job, because these are the aspects that will make demands on the person performing
the job. Performance during critical incidents separates the well performing employee
from the not so well/badly performing employee. The CIT is a method of identifying and
formulating the critical requirements of performing a job successfully.
On the home page (http:/www.air-dc.org/about/critical.html) of the American
Institute for Research (AIR), which was founded by the creator of the CIT, the CIT gets
defined as follows:
‘The critical incident technique (CIT), developed by John Flanagan, consists of a
set of procedures for systematically identifying behaviors that contribute to the success or
failure of individuals or organizations in specific situations.’
There are 5 steps in the technique:
1. Define the goal of the activity.
2. Develop plans and specifications for collecting data.
3. Collect the Data.
4. Make a thematic analysis of the data.
5. Interpret and report the findings.

5
Later Industrial Psychology evolved into Industrial and Organizational
Psychology. Interestingly this appendix to the original name, denotes the shift in attention
from the individual towards integrating the individual and the organization.
In a sense it is a rather strict method with considerations for the problems involved in
empirical research. It utilizes a brand of data collecting methods, depending on the activity
under study and the conditions of the particular working place. It should be perceived as a
‘tool box’ for doing job analysis with a critical perspective. The original article from
Flanagan (1954) describes the stages of the method and emphasizes the internal relation of
the 5 steps in order to achieve internal validity in the study.
The crucial part is collecting the incidents, using the standardized way of
questioning about them, and the inductive and thematic/content categorization of the
incidents. The categories will be an ordered representation of the critical dimensions of the
job under study. The real value of the categories are that each category is exemplified
with the collected critical incidents. For instance, (cited from Bitner et al. 1990) in the
category ‘response to unavailable service’ a critical incident for creating a satisfied
customer was: ‘They lost my room reservation but the manager gave me the V.P. suite for
the same price.’ These incidents are concrete directions for the action to take in order to
give service that makes the customer satisfied, e.g. successful handling of a critical
incident for customer service.

Why is it a good idea to use the critical incident

technique to formulate critical success factors for the
implementation of IT in BPR projects ?
This paper is about a very complex job, namely implementing IT in BPR projects, that is
implementing IT in radical organizational innovation projects combining technical and
administrative innovation. When there is high complexity, one has to focus carefully on
the few key areas where ‘things must go right’. This reduction of the complexity is
necessary in order to handle the situation and be able to decide what to do. The
contingency of the situation will be too high to select appropriate actions without a
meaningful reduction (Luhmann 1984). The resulting actions will either not fit the
situation or be incidentally selected, and neither choice is good for promoting a successful
implementation.
Rockart used critical success factors to reduce the amount of information that the
executives got on their desks in order to make them able to decide on the basis of the
relevant information. This was clearly a meaningful reduction of the information
overflow. In project management critical success factors are used in order to determine
and handle factors influencing innovations.6 The critical success factors can be used to
plan and predict the actions that will make the project result connect to the success criteria
and other specifications.
If critical success factors are to play this central role in the implementation
process, then they must be concrete, valid, and related to implementation. This demands a
method which in a systematic way yields results that can be validated and which relates to
innovation projects from the viewpoint of the involved people in the critical activities and

6
There might even be resemblance between the use of risk factors and success
factors. They describe complementary parts of the project, but the idea is the same:
guiding the attention of the people involved to areas that potentially can flounder the
project (risk factors) and to areas where things must go right. Both types of areas are
critical for the result (CSF).
not only the executives’ point of view of the critical areas. Also, the method has to yield
clear behavioral descriptions for actions.
The critical incident technique has been designed with this purpose in mind, all
except the innovation project aspect. The method can both identify the critical activities
and provide clusters of behavioral descriptions related to every critical activity. It is
systematic, and the stepwise prescription is made in order to ensure internal validity. The
CIT is general in the way that it can be used to describe all kinds of activity involving
human interaction where it is possible to define the goal of the activity.7 It is explicitly
formulated that all humans involved in the activity should have their say in what is a
critical area and how it should be handled.
The problem however is that it is not possible to determine the external validity of
the critical success factors. A critical success factor describes a causal relation from the
critical activity to the successful result (Sørensen & Grunert 1994). The CIT can map the
relations, but there are no tools for measuring the strength of the proposed causal
relations8. As a consequence it is not possible to make a list starting with the most
influential critical success factor, e.g. the factor with the strongest causality. Because of
this the method is also very explicit that external validity does not equal the number of
responses relating to the same critical success factor. Studies have shown that the internal
validity using the critical incident technique is good (see for instance Andersson & Nilsson
1964; Prien & Ronan 1971) and that the method actually captures the total of critical
areas within the activity.9
Another aspect that should be touched upon is that the critical incident technique
has always been used to make job descriptions for job positions, e.g. the manager (van
Fleet 1974) , the dentist, the salesman (Kirchner & Dunnette 1957), the service personnel
(Bitner et al. 1990) etc. It is novel to attempt to use the method to study a collaborative
effort where the different human positions interact all the way in making the result. The
problem is obviously a matter of differentiating between the various individual
performances involved.10
Under such circumstances it is imperative that the critical areas stay related to the
job position they originated from, e.g. the IT manager, the CEO, the sponsor, the
personnel in the organization and other involved personnel groups. It is also imperative
that all involved groups of personnel accept the general formulation of the goal of the
activity. Then, the result will not be one job description of the work process of
implementing IT - on the contrary the result will consists of a bundle of job descriptions
covering all the personnel groups involved in the project thereby connecting the

7
It is not possible to define what is a critical area if the goal of the activity is
unknown.
8
Another problem related to the causality is if the critical success factors are the
type of causal relation. Using the concepts of ‘necessary’ and ‘sufficient’ causes for a
result, one might describe the nature of the resulting causal relations. However, as Cook
& Campbell (1979) writes, the science of causality is in chaos and no one agrees on the
characteristics of causal relations. This problem, then, may be acknowledged but not
solved.
9
This, however, should be judged in relation to the complexity of the activity
under study.
10
One individual performance might be seen in the context of either other
individual performances or organizational performance in general depending on the degree
of detail in the analysis.
behavioral descriptions directly to the responsible personnel. A further analysis might
reorganize the implementation work and create new job descriptions on the basis of the
first attribution of critical areas to the various personnel groups, placing the responsibility
of the critical areas with the people best equipped to handle them. This would be a
different kind of critical success factors and maybe a new term is justifiable?
To sum up: the critical incident technique has clear advantages that makes it a
good choice for studying the implementation of IT in BPR projects. It is even possible to
enlarge the scope of the analyses and create CSFs that are not only are factual job
descriptions of the work in the critical areas, but which are also are proposals to how the
work of implementation could be improved. Within the context of business process
reengineering this seems to be the natural outcome of the present study.

Concluding Remark
The proposed research methodology has yet to be tried out in practice. This will happen
during the next 1 ½ years. The main point to be remembered is not so much this particular
research approach, it is rather the attempt to study the work processes of our practice as
IT professionals in various job categories in a holistic manner. The holistic approach is
important if we want to gain understanding of the complex work situation we are engaged
in as IT professionals with the intention of improvement.

References
Andersson B-E & Nilsson S-G (1964); Studies in the Reliability and Validity of the Critical
Incident Technique, J. of Appl. Psych., 1964, Vol.. 48, No.6, 398-403
Ascari A, Rock M & Dutta (1994); Reengineering and Organizational Change: Lessons from a
Comparative Analysis, INSEAD Working Papers: 94/71, McKinsey & Co & Anderson
Consulting, USA
Bartram P (1992); Business Re-engineering - The use of process redesign and IT to transform
corporate performance, Business Intelligence Limited, London, UK
Bashein B J, Markus M L & Riley P (1994); Preconditions for BPR Success - and how to prevent
Failures, J. of Information Systems Management, Spring 1994, No. 55, page 7-13
Bitner M J; Booms B H; Tetreault M S (1990) The Service Encounter: Diagnosing Favorable and
Unfavorable Incidents, J. of Marketing, Vol. 54, Jan. 1990, pp. 71-84
Bullen C V (1995); Productivity CSFs for Knowledge Workers, Information Strategy: The
Executive’s Journal, 1995, Vol.. 12, 14-20
Bullen C V (1995a); Reexamining Productivity CSFs, Information Systems Management,
Summer 1995, 13-18
Campbell J P, Dunnette M D, Lawler E E III & Weick K E jr. (1970); Managerial Behavior,
Performance, and Effectiveness, McGraw-Hill Books, New York… USA
Cash J I jr. & Konsynski B R (1985); IS redraws Competitive Boundaries, Harvard Business
Review, march-april 1985, Vol.. 63, page 134-142
Computers in Context: Joining Forces in Design, Proceedings from the Third Decennial
Conference, Aarhus, Denmark, Aug. 14-18, 1995
Cook T D & Campbell D T (1979) Quasi-experimentation, Design & Analysis, Issues for Field
Research, Rand McNally, Chicago, USA
Coombs R & Hull R (?) The Wider Context of Business Process Analysis (A Consultancy Report
for the Economic and Social Research Council), http://bprc.warwick.ac.uk/umist1.html
Craig J & Yetton P (1992); Business Process Redesign: A Critique of Process Innovation by
Thomas Davenport as a case study in the literature, Australian J. of Mgmt, Vol. 17, No. 2,
page 285-306
Craig J F & Yetton P W (1994); The Dual Strategic and Change role of IT: A Critique of
Business Process Reengineering, Working paper 94-002, Australian Graduate School of
Management, University of South Wales, Australien
Cronbach L J (1970); Essentials of Psychological Testing 3rd ed., Haper & Row Publishers, USA
Currie W & Willcocks L P (1997) Does Radical Reengineering Really Work ? Emerging Issues in
Strategic Projects, In Willcocks et al. (Eds.) Managing IT as a Strategic Resource, The
McGraw-Hill Companies, London …pp. 238-274
Damanpour F (1991); Organizational Innovation: A Meta-Analysis of Effects of Determinants and
Moderators, Academy of Management J., Vol.. 34, No. 3, 555-590
Daniel R (1961); Management Information Crisis, Harvard Bus. Rev., okt. 1961, page 111
Davenport T H (1993); Process Innovation: Reengineering Work Through Information
Technology, Harvard Business School Press, Mass. USA
Davenport T H & Short J E (1990); The New Industrial Engineering: IT and Business Redesign,
Sloan Management Review, Summer 1990, 11-27
Davenport T H (1996); The Fad that Forgot People, Fast Company, Jan. 1996, page 70-74.
Artiklen kan desuden down loades fra flg. adr.:
http://www.fastcompany.com/online/resources/backissues.html
Dunnette M D (1983) (ed) ; Handbook of Industrial and Organizational Psychology, John Wiley
& Sons, New York …
Earl M J (1994); The New and the Old of Business Process redesign, J. of Strategic IS, Vol. 3,
No.1, page 5-22
Flanagan J C (1954); The Critical Incident Technique, Psychological Bulletin, Vol.. 51, No. 4,
July 1954, pp. 327-358
Ghiselli E E (1951); New Ideas in Industrial Psychology; J. of Appl. Psych.,Vol.. 35, 229-235
Ghemawat P (1991): Commitment - The Dynamic of Strategy, The Free Press (Macmillian Inc.),
New York USA …
Gilmer B v.H & Deci E L (1977); Industrial and Organizational Psychology 4th ed., McGraw-
Hill Book Company, New York …
Grint K (1994), Reengineering History. Social Resonances and Business Process Reengineering,
Organization, Vol. 1, No. 1, page 179-201
Grover V, Teng J T C & Fiedler K D (1993); IT enabled Business Process Redesign: An
Integrated Planning Framework, OMEGA J. of Int. Mgmt. Sci., Vol. 21, No. 4, page 433-447
Grunert K G & Ellegaard C (1993); The Concept of Key Success Factors: Theory and Method in
Baker M J (ed.) Perspectives on Management, Vol.. 3, John Wiley & Sons Ldt., page 245-274
Grønhaug K & Falkenberg J (1990): Organizational Success and Success Criteria: Conceptual
Issues and an Empirical Illustration, Scand. J. of Mgmt, Vol.6, No.4, pp. 267-284
Hammer, M (1990); Reengineering Work: Don’t Automate, Obliterate, Harvard Business review,
July-Aug. 1990, page 104-112
Hammer M & Champy J (1993); Reengineering the Corporation, Nicholas Brealey Publishing,
London
Hammer M & Mangurian G E (1987); The Changing Value of Communications Technology,
Sloan Mgmt. Review, Winter 1987, page 65-72
Harvey H (1995); Re-engineering: the critical success factors, 2nd ed., Management Publications
Limited & Business Intelligence Limited, London, UK
Hiatt J & Hope L (eds.) (1997); Best Practices in Business Process Reengineering and Process
Design, ProSci, Colorado, USA
Iden J (1995); Six Essays on Business Process Reengineering, Doctoral dissertation from Dept. of
 Information Science, Bergens Universitet, Norge
Ives B & Learmonth G P (1984); The Information System as a Competitive Weapon, Comm. of
the ACM, Vol. 27, No. 12, page 1193-1201
Jeong S R; Kettinger W J & Teng J C (1995): The implementation of Business Process
Reengineering, J. of Management Information Systems, Vol.. 12, No. 1, page 109-
Jenster P V (1987); Firm Performance and Monitoring of Critical Success Factors in Different
Strategic Contexts, J. of MIS, Vol. III, No. 3, page 17-33
Kaplan R B & Murdock L (1991); Core Process Redesign, McKinsey Quarterly, Summer 1991,
page 27-43
Kirchner W K & Dunnette M D (1957) Identifying the Critical Factors in Successful
Salesmanship, Personnel, Vol. 34, No. 2, pp. 54-60
Luhmann N (1984) Sociale Systemer, 1st electronic edition, Munksgaard, København
McFarlan F W (1984); Information Technology Changes The Way You Compete, Harvard
Business Review, May-June 1984, page 98-103
Nord W R & Tucker S (1987); Implementing Routine and Radical Innovations, Lexington
Books, Mass. USA
Pinto J K & Slevin D P (1987): Critical Factors in Successful Project Implementation, IEEE
Transactions on Engineering Management, Vol.. EM-34, No. 1, feb. 1987, s. 22-27
Porter M & Millar V E (1985): How Information Gives You Competitive Advantage, Harvard
Business Review, July-Aug. 1985, page 149-160
Oliver, J (1993); Shocking, Management Today, aug. 1993, page 18-22
Prien E P & Ronan (1971) Job Analysis: A Review of Research Findings, Personnel Psychology,
Vol. 24., pp. 371-396
Rockart J F (1979); Chief Executives Define their own Data Needs, Harvard Bus. Rev., Vol. 57,
No. 2, page 81-93
Rockart J F & Short J E (1989); IT in the 199s: Managing Organizational Interdependence, Sloan
Mgmt. Review, Winter 1987, page 7-17
Rothwell R (1977); The Characteristics of Successful Innovators and Technically Progressive
Firms (with some comments on innovation research); R & D Management, Vol. 7, No. 3, page
191-206
Rothwell R (1992) Successful Industrial Innovation: Critical Factors for the 1990s, R&D
Management, Vol. 22, No. 3, pp. 221-239
Schewe G (1991); Key Factors of Successful Innovation Management, Working Paper No. 274
from Institute for Business Administration, University of Kiel, Germany.
Schnitt D L (1993); Reengineering The Organization Using Information Technology, J. of Systems
Mgmt, Vol. 14, No. 20, page 14-42
Shank M E; Boynton A C; Zmud R W (1985) Critical Success Factor Analysis as a Method for
MIS Planning, MIS Quarterly, Vol 9, June, pp. 121-129
Sørensen, E & Grunert, K G (1994) Identification of managers perceived key success factors. In:
C. Eden & B. Winterscheid (Eds.) Proceedings of the Second International Managerial and
Organisational Cognition Workshop, pp. 541-565, Brussels, EISAM
Taylor J A (1995); Don’t Obliterate, Informate!: BPR for the Information Age, New Technology,
Work and Employment, Vol. 10, No. 2, page 82-87
Teng J T C; Grover V & Fiedler K D(1994); Business Process Reengineering: Charting for a
Strategic Path in the Information Age, California Mgmt Review, Vol. 36, No. 3, page 9-31
The Critical Incident Technique (1997) http://www.air-dc.org/about/critical.html
Tidd J, Bessant J & Pavitt K (1997); Managing Innovation, Integrating Technological Market
and Organizational Change, John Wiley & Sons, Chichester …
van Fleet D D (1974); Toward Identifying Critical Elements in a Behavioral Description of
Leadership, Public Personnel Management, Jan-feb 1974, Vol.. 3, No. 1, 70-82
Wateridge J F (1996) Delivering Successful IS/IT Projects, unpublished Doctoral dissertation
from Henley Management College, Brunel University, England
Wateridge J F (1997); How can IS/IT projects be measured for success ?, Int. J. of Project Mgmt,
Vol.. 16, No. 1, page 59-63
Weiner et al. (1972); Perceiving the Causes of Success and Failure, in Jones et al. (eds.)
Attribution and Perceiving the Causes of Behavior, General Learning Press, New Jersey, USA
White W L (1993); Compensation Support for Reengineering, Compensation & Benefits Review,
Vol. 25, No. 5, page 41-46