Koen Milis - Deel1 PDF

D O C T CJR A A T S P R 0 .
E F S C H R I F T
-.
2002
Faculteit
Toegepaste Economische Wetenschappen
Success factors for ICT projects

Empirical research, utilising gualitative and quantitative approaches
(incl. Bayesian networl<s, Probabilistic feature models)
.
Proefschrift voorgelegd tot het behalen van de graad van
Doctor in de Toegepaste Economische Wetenschappen,
te verdedigen door
Koen MILIS
Promotor : Prof. dr. R. Mercken
PARTNER IN DE UNIVERSITEIT LIMBURG

111~m11~1~111~1111u~r1
03 04 0071931 3
° 219 0 3
. 3 Ot.L LLIUL
68 1. 3
MILI
2002
l u c.lu c
.:.
··,
2002
Faculteit
Toegepaste Economische Wetenschappen

Empirical research, utilising gualitative and quantitative approaches
(incl. Bayesian networl<s, Probabilistic feature models)
Proefschrift voorgelegd tot het behalen van de graad van

Doctor in de Toegepaste Economische Wetenschappen,
te verdedigen door
021903
Koen MILIS
Promoter : Prof. dr. R. Mercken
PARTNER IN DE UNIVERSITEIT LIMBURG

Table of contents
CHAPTER I : PROBLEM STATEMENT ..................................................... 5
1.1 INTRODUCTION ...........................................................................................5

1.2 PURPOSE STATEMENT ................................................................................ 6
1.3 RESEARCH QUESTIONS ............................................................................... 6
1.4 DEFINITIONS IN TERMS .............................................................................. 6
1.5 LJMITATIONS & DELIMITATIONS .............................................................. 7
1.6 RESEARCH DESIGN ......................................................................................8
1.6.1 Research framework ................ ......................... ......................................................... 8
1.6.2 Success factors: Qualitative research ............... ....................................................... 10
1.6.3 Success factors: Quantitative research ..... .................................................. ............. 10
1.6.4 Success criteria: Quantitative research .................................................................... 11
CHAPTER II: LITERATURE REVIEW.................................................... 15
2.1 DEFINING A "SUCCESSFUL ICT PROJECT" ................................. 15

2.1. 1 lntroduction ............................................... ................ .............................................. 15
2.1.2 A project .................. .................................. .............................................................. 15
2.1 .3 An ICT project .................................................. ...................................................... 20
2.1.3 An lCT project ........ ............... ................................................................................. 20
2.1.4 A successful ICT project ........................... ..................................... ...... ................... 21
2.2 SUCCESS FACTORS FOR JCT PROJECTS: LITERATURE
REVIEW ....................................•...........................................•.•...•..................29
2.2.1 Introduction .......... ....................................................................... ............ ................ 29
2.2.2 Possible success factors for ICT projects, based on JCT literature ......................... 30
2.2 .3 Possible success factors for ICT projects, based on non-1CT literature .................. 57
2.2.4 Success factors for the implementation ofTCT projects: synopsis ......................... 79
CHAPTER III: QUALITATIVE RESEARCH FOR SUCCESS

FACTORS .......................................................................................................91
3.1 METHODOLOGICAL FRAMEWORK ............................................... 91

3.1.1 Introduction : a philosophical - theoretical perspective .................................. ......... 9 1
3.1.2 Purpose .......... ......... .................................... .................. ........................................... 93
3.1 .3 Research questions and sub-questions ......................... ........................................... 93
3 .1.4 Limitations and delimitations ...................................................... ............................ 93
3.1.5 Type of design used ................. ................................................................................ 94
3. 1.6 Context description ......... ...................... ................................ ...... ... ......................... 95
3.1 .7 Data collection ........ .............................................................................................. 111
3.1.8 Data analysis strategy ............................ ............................................ ... .......... ..... .. 11 6
3.1 .9 Validity and reliability ....................... ................................................................... 117
3.2 OUTCOME OF THE QUALITATIVE ANALYSIS ..........................122
3 .2. l Introduction ....................................................................... ........................ ............ 122
Table of contents
3.2.2 Category 1: Triggers and motives leading to the execution of the project ........... 122
3.2.3 Category 2: Selection and justification ............................................ ..................... 123
3.2.4 Category 3: Project definition ............................................................................... 126
3.2.5 Category 4: Additional specifications ...................... ............................................. 130
3.2.6 Category 5: Evaluation ex ante & ex post / control mechanisms .......................... 131
3.2.7 Category 6: Project plan & dealing with changing conditions .............................. 134
3.2.8 Category 7: Shift in goals or scope ....................................................................... 135
3.2.9 Category 8: Motivation project team / project manager .... ................................... 136
3.2.l OCategory 9: User training & support ................................................................... 137
3.2.1 l Category 10: Communication ............................................................................. 141
3.2.12 Category 11: Problems, conflicts and tension ..................................................... 144
3.2.13 Category 12: Resistance to change and change management.. ........................... 146
3.2.J 4 Category 13: The project organisation ......................................................... ....... 150
3.2.15 Category 14: Functioning & role of the project team / project manager .. .......... 152
3.2.16 Category 15: Functioning & role of the management.. ....................................... 155
3.2.17 Category 16: Functioning and role of the users .................................................. 157
3.2.18 Category 17: Judging the project .............................................................. .......... 159
3.2.19 Category 18: Problems, reported strengths & weaknesses ................................. 163
3.2.20 Overview ............................................................................................................. 166
3.2.21 Refining the categorisation .................................................................................. 167
3.3 COMPARING THE QUALITATIVE ANALYSIS AND THE
LITERATURE SURVEY ............................................................................ 170
3.3.1 Introduction ........................................................................ ............. ...................... 170
3.3.2 Good selection and justification ............................................................................ 170
3.3.3 The project definition ............................................................................................ 171
3.3.4 The project p.lan ..................................................................................................... 171
3.3.5 Management involvement & support .................................................................... 172
3.3.6 The project team ................................................................................................. ... 172
3.3.7 Change management ............................................... ...... ........................................ 173
3.3.8 Proper resources ...................................................... .............. .......................... ...... 173
3.3 .9 Managing relationships ......................................................................................... 174
3.4 CONCLUSIONS OF THE QUALITATIVE FIELD STUDY ........... 175
3.4.l Key factors that make the difference between failure and no failure .................... 175
3.4.2 Key factors that make the difference between mediocrity and success ................ 176
3.4.3 Remarks ................................ ................................................................................. 178
3.5 DISCUSSION..........................................................................................178
CHAPTER IV: QUANTITATIVE RESEARCH FOR SUCCESS

FACTORS ..................................................................................................... 183
4.1 METHODOLOGICAL FRAMEWORK............................................. 183

4.1.1 Justification quantitative research ......................................................................... 183
4.1 .2 Purpose ............................................................. ..................................................... 183
4.1.3 Research questions and sub-questions .................................................................. 184
4. l.4 Limitations and delimitations ................................................................................ 184
4.1.5 Type of design used ........................................................................ ....................... 184
4.1.6 Data collection .............. ......................................................................................... 185
4.1.7 Data analysis strategy ............................................................................................ 187
4.1 .8 Bayesian networks ................................................................................................. 188
rr
Table of contents
4.1.9 Validity and reliability .................................................................................. ........ 191

4.2 OUTCOME OF THE QUANTITATIVE ANALYSIS ....................... 193
4 .2.1 Introduction ............................ ............ ................................................................... 193
4.2.2 Good selection and justification ............................................................................ 193
4.2.3 The project definition ................................... ......................................................... 198
4.2.4 The project plan .............. ....................................................................................... 201
4.2.5 Management involvement and support .................... .............. ............................... 203
4.2.6 The project team ..... ..................................................... ................ .......................... 206
4.2.7 Change management ............................................................................................. 208
4.2.8 Sufficient resources ............................................................................................... 211
4.2.9 Managing relationships ........ ... ..................... ......................................................... 213
4.3 TRIANGULATION QUALITATIVE AND QUANTITATIVE
RESEARCH FOR SUCCESS FACTORS ................................................. 217
4.3.1 Introduction ............................................ ............................................................... 217
4.3.2 Good selection and justification ............................ ................................................ 217
4.3.3 The project definition ............................................................................................ 218
4.3.4 The project plan ..................................................................................................... 218
4.3 .5 Management support ............. .................. ...... ........................................................ 2 19
4.3.6 The project team ................................................................................................. ... 2 19
4.3.7 Change management ............................................................................................. 219
4.3.8 Sufficient resources ..................... ............... ........................................................... 220
4.3.9 Managing relationships ...................................................................................... ... 220
4.3.10 Conclusions ......................................................................................................... 221
CHAPTER V: DETERMINING SUCCESS CRITERIA FOR ICT

PROJECTS ...................................................................................................225
5.1 INTRODUCTION ..................................................................................225

5.2 LITERATURE REVIEW ......................................................................226
5.3 METHODOLOGICAL FRAMEWOR.K .............................................227
5.3.1 Purpose .............. .................................................................................................... 227
5.3.2 Research questions ............................... ................................................................. 228
5.3.3 Definition in terms ......... ..... ................................ .............. .................................... 228
5.3.4 Limitations & delimitations ........................................................ .......................... 229
5.3.5 Type of design used ..................................................................... .......................... 229
5.3.6 Data collection ........ ........... ........................................................................ ............ 230
5.3.7 Software used ............................ ............................................................................ 23 1
5.3.8 Data analysis strategy ............................................................................................ 231
5.3.9 Validity and reliability ........................................... ............................................... 232
5.4 OUTCOME OF THE QUANTITATIVE ANALYSIS .......................234
5.4. l Introduction ........................................................................................................... 234
5.4.2 Data inspection ... ..................................................................... .............................. 234
5.4.3 Comparing means ............ ............................................................................. ......... 236
5.4.4 Determining which criteria the parties use by employing linear models .............. 240
5.4.5 Data analysis using probabilistic feature models for frequency data ................... 267
5.5 TRIANGULATION PMD-MODEL VS. LINEAR MODELS ..........274
5.6 ANALYSIS OF THE ADDITIONAL QUESTIONS ..........................274
5.6.1 Additional criteria .............. ................... .......................... ...................................... 274
ill
Table of contents
5.6.2 Explicit ranking of the criteria .............................................................................. 274

5.7 COMPARING THE SEARCH FOR SUCCESS FACTORS AND
THE SEARCH FOR SUCCESS CRITERIA ............................................ 276
5.7.1 Introduction .......................... ......................................................................... .. ...... 276
5.7.2 Differences ............................................................................. ............................... 277
5.7.3 Impact of the differences on the criteria ........................................................ ..... ... 278
5.7.4 Conclusions ....................... ..... ............................................................................... 280
5.8 LINKING SUCCESS CRITERIA AND SUCCESS FACTORS .......281
5.8.1 Introduction ................................................................................................... ........ 28 1
5.8.2 Success factors vs. success criteria ....................................................................... 281
5.8.3 Success factors vs. parties involved ...................................................................... 284
5.9 CONCLUSIONS.....................................................................................285
5.10 DISCUSSION .......................................................................................286
CHAPTER VI: CONCLUSIONS, MANAGEMENT GUIDELINES AND

SUGGESTIONS FOR FURTHER RESEARCH ......................................289
6.1 CONCLUSIONS.....................................................................................289
6.1 .1 Literature review .............................................................. ... .................................. 289
6.1 .2 Research for success criteria ................................................................................ . 289
6.1.3 Research for success factors .................................................................................. 290
6.2 MANAGEMENT GUIDELINES .........................................................294
6.2.1 Guidelines, derived from the search for success criteria ............................... ........ 294
6.2 .2 Guidelines, derived from the research for success factors .................................... 294
6.3 SUGGESTIONS FOR FURTHER RESEARCH & CRITICAL
REMARK.S .................................................................................................... 298
6.3. 1 Search for success criteria ..................................................................................... 298
6.3.2 Search for success factors ............................ ............................................ ............. 298
6.3.3 Critical remarks .................................................................................................. ... 299
REFERENCES .................................................................................................. 303
APPENDIX I: GROUNDED THEORY ................................................................. 313

APPENDIX II: ANALYSING QUALITATIVE DATA, USING NUD*IST .............. 321
APPENDIX III: KBC-HOLDING ...................................................................... 329
APPENDIX IV: EXAMPLE OF A PROJECT DESCRLPTION ................................ 337
IV
List of tables
Chapter II
Table 1: Project lifecycles ..................... ................................................................................... 17

Table 2: Differences ICT vs. other projects ............................................................................. 21
Table 3: Comparing criteria for success ........................................................................ ........... 22
TabJe 4: Correlation between factors and success criteria ....................................................... 31
Table 5: Success criteria, formulated by Standish Group ....... .............................. ................... 33
Table 6: Scoring test. ................................................................................................................ 33
Table 7: Factors vs. criteria ................ ........................... .......... ..... ............................................ 37
Table 8: Overview of possible success factors ......................................................................... 87
Chapterm
Table 1: Validity and reliability of the research .............................. ...................... ................. 121
Table 2: Overview of the success factors derived from qualitative analysis ...................... ... 166
Table 3: Major categories that resulted from the qualitative analysis .................................... 169
Chapter IV
Table I: Example of a probabilistic relationship .................................................................. 189

Table 2: Selection &justification, mapping variables ............... .. .......................................... 194
Table 3: Project definition, mapping variables ................ .......... ............................................ 199
Table 4: Project plan, mapping the variables ........... .............................................................. 202
Table 5: Management involvement, mapping variables ......... ............................................... 204
Table 6: The project team, mapping variables ......... ............. ............................. .................... 206
Table 7: Change management, mapping the variables ..... ...................................................... 209
Table 8: Resources, mapping the variables ...................... ..... ................................... .............. 211
Table 9: Managing relationships, mapping variables .............. ............................................... 214
ChapterV
Table 1: Number of experts for each party .................................. .......................................... 23 1

Table 2: Reliability and validity of the research ........................................................ ............ 233
Table 3: Frequency data ......................................................................................................... 235
Table 4: Variance caused by project descriptions and individual differences ....................... 24 1
Table 5: Linear models, examining main effects .................................................. ................. 242
Table 6: High correlations between criteria and interaction terms ........................................ 243
Table 7: Basic linear model for all experts ........................................... ................................. 244
Table 8: Linear models, based on partial data, a ll experts included ...................................... 249
Table 9: F inal linear model for all experts ............................................................................. 250
Table 10: Calculation interaction tenns for the linear model, all experts .............................. 251
Table 11: Basic linear model for users ................................................................................... 252
Table 12: Final linear model for users .............................. ..................................................... 254
Table 13: Calculation interaction terms for the linear model, users ............................ ... ....... 255
Table 14: Basic linear model for project team members - no benefactors ............................ 256
V
List of tables and figures
Table 15: Final linear model, project team members - no benefactors .................................. 258
Table 16: Calculation interaction terms, project team members - no benefactors ................. 259
Table 17: Basic linear model for project team members - benefactors .................................. 260
Table 18: Final linear model for project team members - benefactors .................................. 262
Table 19: Calculation interaction terms for the linear model, project team members -
benefactors ... .... ... .............................................................................. ............................. 263
Table 20: Basic linear model for the management... .... .......................................................... 264
Table 21 : Final linear model for management ................................................... .................... 266
Table 22: Calculating interaction terms for the linear model, management .......................... 266
Table 23: Posterior median and 95% posterior intervals (Pl) for the disjunctive model ....... 272
Table 24: Explicit ranking by experts .................................................................................... 275
Table 25 : primary relationsh ips success factors vs. success criteria ................. ..................... 284
Table 26: Success factors vs. parties involved .... ................................................................... 285
List of figures
Chapter I
Figure 1: Research design ................................................... ....................................................... 9
Chapter II
Figure 1: Profile of an average project ...................................... ............................................... 19
Figure 2: Literature review on success factors ................................ ........... .............................. 29
Figure 3: Manager model ............................................ ............................................................ . 41
Figure 4 : User model ................................................................................................ ......... ... ... . 42
Figure 5: First partial test: manager model... ............................................................................ 46
Figure 6: First partial test: user model.. ............................... ..................................................... 47
Figure 7: Second partial test: user model ................................................... .............................. 48
Figure 8: Factor groups ....... ............................ ............................................................... ... ....... 63
Chapter III
Figure 1: Research design ................................................................................................. ....... 91
Figure 2: Grounded theory methodology ................................................ .......... ....................... 95
Figure 3: Interview schema .......................... ................................ ........... ............................... 11 5
Figure 4: Triggers and their impact .............................. ......................................................... . 125
Chapter IV
Figure I : Research design ...................................................................................................... 183
Figure 2: Schema interview & survey ..................................................................... ............... 187
Figure 3: Screen capture Bayesian network ................ .............................. ............................. 189
Figure 4: D iagnosis ........................ ..................... ................................................................... 190
F igure 5: Prediction ................................................................. ............................................... 19 1
Figure 6: Selection & justification network ............. .............................................................. 194
F igure 7: Bayesian network, selection & justification .................................................... ....... 196
Figure 8: Selection & justification, simulation 1 ................................................................... 197
VI
Ust of tables and figures
Figure 9: Selection & justification, simulation 2 ................................................................... I 97

Figure 10: Project definition network .................................................................................... 198
Figure 11: Bayesian network, project definition .................................................................... 199
Figure 12: Project definition, simulation 1............................................................................. 200
Figure 13: Project definition, simulation 2............................................................................. 200
Figure 14: Project definition, simulation 3 ............................................................................. 201
Figure 15: Project plan network ............................................................................................. 201
Figure ] 6: Bayesian network, project plan ............................................................................. 202
Figure 17: Project plan, simulation l ..................................................................................... 203
Figure 18: Management involvement network ...................................................................... 203
Figure 19: Bayesian network, management involvement ...................................................... 204
Figure 20: Management involvement, simulation 1............................................................... 205
Figure 21: Management involvement, Simulation 2 .............................................................. 205
Figure 22: Project team network ............................................................................................ 206
Figure 23: Bayesian network, the project team ...................................................................... 207
Figure 24: The project team, simulation 1 ............................................................................. 208
Figure 25: Change management network ............................................................................... 208
Figure 26: Bayesian network, change management.. ............................................................. 209
Figure 27: Change management, simulation 1....................................................................... 210
Figure 28: Change management, simular 2 ............................................................................ 210
Figure 29: Resources network ................................................................................................ 21.1
Figure 30: Bayesian network, resources ............ ..................... ............................................... 212
Figure 31: Resources, simulation I ........................................................................................ 213
Figure 32: Resources, simulation 2 ........................................................................................ 213
Figure 33 : Managing relationships network........................................................................... 214
Figure 34: Bayesian network, managing relationships ........... ........... .................................... 215
Figure 35: Managing relationships, simulation 1 ................................................................... 215
Figure 36: Managing relationships, simulation 2 ................................................................... 216
Figure 37: Research design .................... ................................................................................ 217
ChapterV
Figure 1: Research design ................................................................................................. ..... 225

Figure 2: One-way ANO VA to examine differences between parties ................................... 237
Figure 3: Post hoc tests to examine differences between the ratings of the parties ............... 238
Figure 4: Additional post hoc tests to examine differences in ratings between the parties ... 239
Figure 5: P-P plot for the regression model all experts .......................................................... 246
Figure 6: Partial regression plots for the linear model, all experts ........................................ 247
Figure 7: DFFIT outliers for the linear model, all experts ..................................................... 248
Figure 8: DFFIT outliers for linear model, users ................................................................... 253
Figure 9: DFFTT outliers for linear model, project team members - no benefactors .. ........... 255
Figure l 0: DFFIT outliers for linear model, project team members - benefactors ................ 26 1
Figure 11: DFFIT outliers for the linear model, management ............................................... 265
Figure 12: Concept of PMD models ...................................................................................... 269
VII
Chapter I: Problem statement
1.1 Introduction
"Information Technology (IT) budgets have grown faster than any other indicator of
corporate performance. Executive management expects that their information management
experts will deliver results that will surpass other available means for generating economic
su,p/uses" (Strassman, 1997). The importance ofIT is constantly increasing.
Nevertheless, research studies suggest that at least 20% of expenditure on TT is wasted and
between 30 and 40% of 1T projects realise no net benefit, however measured (Willcocks,
1995; Willcocks & Lester, 1994; Hochstrasser & Griffiths, 1991).
An important factor, pointed at by most authors as a cause of failure of IT projects, is the lack
of a theoretically founded and empirically tested evaluation and justification methodology.
Hochstrasser & Griffiths ()991) for example, found that only 16% of the corporations rely on
rigorous methods to calculate the benefits of investments in IT. Consequently, costs are often
significantly underestimated (G. Fitzgerald, 1998).
Literature provides an extensive list of other possible factors that may cause failure or
success, like there are: Jack of involvement of the executives, lack of experience with similar
IT, management style, alignment with the business strategy and so on. Unfortunately, these
statements are often based on a limited number of cases or even on testimonials of some
vendors.
Most research in this field focuses on IT at corporate level, that is, the ideal level of TT
spending is being researched. Ways of allocating IT budgets are described. Management rules
and attitudes are being examined (Strassman, 1997; Kaplan & Norton, 1992; Willcocks,
1996). Projects, as such, are seldom the unit of research.
Another branch of research studies the justification process for lT projects. Justification
techniques for IT are examined and compared with traditional justification techniques
(Willcocks, 1995; Dos Santos, 1991; Groneman & Meroney, 1991; Clemons & Weber, 1990).
Suggestions are made to improve the justification process.
Despite an increased interest in IT spending, it is surprising that so little empirical research

has actually been conducted on IT projects itself, especially from the perspective of project
management. Very few studies have focused on the success factors oflT projects. Those who
did, mainly focused on the impact of one or two specific factors, like the impact of
management style or the severity of the posed targets (Earl 1990, the Hawley committee
report, 1995). Therefore, a more holistic approach is needed that studies the combined impact
of the different variables on IT projects.
This study tries to fill this deficiency in the current research literature by using IT projects as
the unit ofresearch. More precisely, ICT projects will be examined.
5
1.2 Purpose statement

The purpose of this study is twofold.
First, discover how fCT projects are judged. More specifically, an attempt is made to identify
the criteria that are used to judge the success an JCT project. These criteria are referred to as
success criteria.
Second, discover the factors that influence the success of the implementation of ICT projects.
A distinction is made between those factors that make a difference between failure and no
failure and the factors that lead to more than average success. Moreover, the mechanisms
behind these factors are examined as well.
The insights gained on success criteria and factors should improve knowledge on ICT
projects, whfoh can be used by management to improve the management of their projects.
1.3 Research questions

In order to fulfil the purpose of the research, the goals are translated into concrete research
questions. An attempt is made to answer each of these questions, based on the conclusions
drawn from qualitative or quantitative research projects.
• Which are the success criteria upon which the success ofICT projects is judged?
o Does every group of stakeholders use the same set of criteria?
o If this is not the case, which criteria are used by which group?
o Does every criterion have the same impact on the judgement for success?
• Which are the factors that lift an ICT project to a more then average level?
• Which are the factors that make a difference between failure and no failure?
• Discover the mechanisms behind these factors.
1.4 Definitions in terms

Rockart's concept of Critical Success Factors (CSF; Reckart 1979) is often used to examine
the success and the management of a company (example: Mathyssens et al, 1998).
Unfortunately, using this concept to study JCT projects' success often leads to ambiguity.
Due to the fact that project success cannot be defined in a binary way (failed or successful) 1,
one can wonder if CSF are those factors that prevent failure or factors that lead to more than
average success. The germ of this ambiguity can already be found in the article in which
Rockart introduced the concept of CSF ( "Chief executives define their own data needs",
Harvard Business Review, 1979), where CSF are described as "the few key areas where
'things must go right ' for the business to flourish" and at the same time as "if the results in
these areas are not adequate, the organization's efforts for the period will be less than
desired''.
1
Too often, success and failure are seen as "black and white". However, projects may not always be
seen as completely successful or complete failures (Wateridge, 1996).
6
Tn this thesis, an attempt is made to distinct between factors. There are those factors that lead
to more than average success. These are called success factors (SF), following the definition
of D.R. Daniel, who introduced this tenn in 1961. (Rockart quotes the article ofDanieJ as one
of his major sources of inspiration for his CSF concept.) The other group of factors are
referred to as Factors that Prevent Failure (FPF). However, note that in this dissertation the
term "success factor" can have a double meaning. If not explicitly stated, the term success
factor refers to both SF and FPF factors.
The distinction between those types of factors is seldom made in lCT literature. Either authors
define project's success in a very rigid, binary way or the authors presume that the factors that
prevent failure are the same as those that lead to more than average success.
1.5 Limitations & delimitations

The scope of the study is narrowed down to ICT-projects in large firms situated in Belgium.
The choice for large firms has to do with their structure and working methods. Large
companies tend to work in a more formal way. Consequently, more written information will
be at hand. These documents are crucial sources of information for this study (project
proposals, internal memos, reports, time sheets, etc.).
The choice to limit the study to Belgian companies is based on the observation that there is a
substantial difference in management culture and company structure between the companies
located in different countries. By limiting the study geographically, the cultural differences
are reduced to a minimum. Furthermore, this decision has a pragmatic element as well.
Limiting the study to Belgian firms reduces the number of linguistic and logistic problems.
An initiative will be regarded as a project when the board or direction committee approves the
project proposal. Due to the research design, a project can only be studied if the project
proposal (or another official document) contains targets, a budget and a timeframe (triple
constraint\ The project are studied after the handover phase, e.g. at the time when the
resulting application was in use by an operational department.
2
The triple constraint (within time and budget, and to specifications) are the three criteria traditionally
used in project management (Groote, 1995).
7
1.6 Research design

1.6.1 Research framework
Before entering the field, a literature review was performed. The aim was double. First,
literature was used to construct a definition of a successful JCT project. Possible success
criteria were identified. Second, literature provided a list of possible success factors and the
mechanisms behind these factors. This information was used to prepare the qualitative
research for success factors.
The research for success factors was conducted using a two-phased research design. In the
first phase a qualitative research was executed. The choice to start with the qualitative
research is based on the conviction that ICT projects (unit of research) should, in first
instance, be approached in a holistic manner. It is important to create a global picture before
starting the examination of some elements in more detail.
The qualitative research resulted in a list of possible success factors and a description of the
way in which they influence project success. 1n the second phase a quantitative research
design (survey) was used to verify, deepen and consolidate the findings of the qualitative
research. Since both researches use the same set of data but a different approach, this can be
classified as method triangulation.
The search for success criteria is quantitative in nature. From the limited number of
researches that deal with success criteria for ICT projects, a vast majority applies a form of
survey or a Delphi-like method. Nevertheless, a quantitative approach may provide additional
insights in the criteria used to judge JCT projects. Th.is part of the research tries to fill in this
deficiency by selecting a typical quantitative approach. A quasi-experiment is condµcted,
where several experts are asked to rate project descriptions. Each description contains a set of
criteria, manipulated by the researcher. By comparing and analysing the results, the researcher
intends to discover which criteria are the most important in the evaluation process.
Note that the search for success factors and the search for success criteria are conducted in
parallel. Consequently, the set-up of the quest for success factors is based on a definition of
success that was derived from literature, not from the search for success criteria. The search
for success criteria was used to verify and consolidate this definition.
A schematic overview of the different stages in the research is presented in Figure 1.
8
Chag_ter I: Problem statement
IS
1 uccess en"tena
. I1
...
y
Quantitative research
,,
Literature Conclusions
review
Succes factors A~
...
y
Qua Iitative )A Quantitative
research T \research
Figure 1: Research design
& = Triangulation
9
1.6.2 Success factors: Qualitative research

The aim of the qualitative research was to discover success factors (both SF & FPF) for the
implementation oflCT projects and to explore the mechanisms behind them.
ln order to do so, twelve ICT projects were examined. These projects were executed within
companies belonging to the KBC holding or companies that were to become part of the
holding. The projects were situated within the bank or insurance branch. They were selected
in such a way that there was a mix of different levels of success present in the sample.
Data was extracted both from documents (project charter, progress reports, evaluation
documents ... ) and from interviews. In total 45 interviews were conducted. For every project,
at least an end user, a project team member and someone from the management was
interviewed.
The grounded theory approach was used to conduct this research. This approach is developed
by Glaser and Strauss (1967) as a method to guide the researcher through an inductive and
reciprocal process, consistent with the inductive model of thinking (see also appendix 1). It is
chosen because it is very useful in developing context-based, process-oriented description and
explanations of a phenomenon. This is also the reason why it is becoming increasingly
common in the IS literature (Myers, 1998).
This research resulted in two lists of factors:

• Factors that lift a project beyond average (SF, success factors)
• Factors that prevent failure (FPF)
and the description of the way in which these factors influence success (mechanisms).
Note that the research was conducted in two phases: first, a pilot study was performed. This
pilot study helped to refine the interview technique of the interviewer and validate the list of
questions used. Furthermore, it was an important step in gaining confidence of KBC and the
interviewees.
1.6.3 Success factors: Quantitative research

The aim of the quantitative research for success factors is to verify, deepen and consolidate
the findings of the qualitative research. Moreover, the quantitative research should provide an
additional aid to interpret the data of the qualitative research. It is used to perform a method
triangulation with the findings of the qualitative research.
Method triangulation implies that the same data source is used. Consequently, in this research,
the same projects are examined and the same persons are engaged as in the qualitative
research for success factors. However, a survey approach was selected, which can be
classified as a cross-sectional research. The survey was conducted using a questionnaire with
closed questions that were asked during actual interviews. More specifically, the participants
were asked to rate a large number of statements in relation to a specific project.
The survey was refined and validated after the pilot study.
10
The data was analysed using Bayesian networks (also referred to as "belief networks" or
"probabilistic causal networks"). This technique was selected because it provides a good
insight in the way the variables are connected (network) and in the impact of the different
variables on success. However, because the number of cases was limited (42 surveys on 12
projects), it was not possible to test all the factors derived from the qualitative analysis.
Hence, it was not possible to test a network that incorporated all factors. Therefore, a number
of smaller networks were constructed, each related to a specific issue that might have an
important impact on the success.
Consequently, this research resulted in a number of networks. These networks express the
relationships between factors and were used to examine the impact of individual factors on
other factors and on success. Of course, these networks were constructed in such a way that
they could be used to verify the conclusions of the qualitative research, i.e. the networks were
used to test the relationships suggested in the qualitative research.
1.6.4 Success criteria: Quantitative research

The search for success factors depends largely on the definition of success. The triple
constraints (within time, within budget and to specifications) are the three criteria traditionally
used in project management (Groote, 1995). Nevertheless, there is a consensus in ICT
literature that the evaluation of a project's success should not be based solely on the triple
constraints. However, there is much less consensus about the criteria that should be used
instead. fn other words, there is consensus over the assumption that the triple constraints are
poor criteria to judge success upon, but there is no consensus on the set of criteria that should
be used.
In this research, an attempt is made to determine the criteria used by the different parties
involved in ICT projects to judge whether or not a project is successful. In other words, this
research tries to uncover the set of criteria the different parties use to evaluate a project for
success.
The aim is double. On the one hand, it is used to verify if the definition that was derived from
the literature is valid. On the other hand, the differences in the sets of criteria the parties use
give an insight into the evaluation process and the sensitivities of the different parties
involved.
This research can be classified as a quasi-experiment. More precisely, the research was set up
as a form of gaming.
Twenty-six experts were selected. These were employees from Interelectra or WVEM, which
are Belgian companies that are active in the energy market (electricity, gas) or consultants
working for them. The experts were divided into four groups:
• Users
• Management
• Projectteam members whose involvement does not cease after handover of the
resulting application to an operational department
• Projectteam members whose involvement ceases after handover
11
Twenty-five project descriptions containing each of the criteria tested were developed by the
researcher. Every expert was asked to rate the projects, based solely on the project description
that was given to him/ her. This resulted in 630 datapoints3.
Again, method triangulation was applied. The data was analysed using both traditional linear
techniques and an innovative non-linear technique (probability decomposition matrix). The
outcome of both techniques was compared and differences examined.
The result of this research is a list of success criteria for every party involved in the
implementation of an ICT project. Furthermore, the impact of every criterion is examined.
This provides a better insight in the way ICT projects are judged. Moreover, these insights can
help refine the definition of a successful project.
Note that this research cannot be classified as an experiment due to the fact that there was no
calibration and that there was no test group.
3
One of the participants fell out due to sickness. Therefore, the total number of datapoints was 630
and not (25 • 26) 650 datapoints.
12
Chapter II: Literature review
2.1 Defining a "successful ICT project''

2.1.1 Introduction
In order to identify the factors of success for ICT projects, a number of criteria needs to be
defined by which a project's success can be measured and which can be used to make an
objective distinction between successful and less successful or failed projects.
In this chapter, an attempt is made to define the tenns "project", "ICT' and "successful".
These definitions are used throughout the study and clearly state the scope of the research
since this study is limited to ICT projects only. Defining the terms "project" and "ICT" is
quite straightforward, the definition of"successful" is not.
''There has been little mention in literature of the criteria used to measure project
success. Furthermore, there is only broad agreement on the critical success factors.
Consequently, there is the need to examine the criteria and the factors, in particular
relating to !CT projects. " Wateridge 1996
A vast number of difficulties are encountered when defining the tenn "successful", as w ill be
demonstrated in this chapter. An examination of possible pitfalls and ambiguities is necessary
in order to construct a definition of the tenn "successful" that takes into account the remarks
and suggestions of previous researchers.
Closely related to this topic is the selection of a set of appropriate measures to quantify the
successfulness of a project. Some of these measures can be derived directly from the
definition of a successful I.CT project, other measures are selected because they can be used as
proxy variables for concepts that are difficult or impossible to quantify. An example: being on
time and high user-satisfaction might be two criteria that mark a successful project. Time can
be measured quite easily, user-satisfaction cannot. Often, frequency of use of the new system
is used as a proxy variable to measure user-satisfaction.
2.1.2 A project
2.1.2.1 Defining the term "proiect"
A lot of different definitions of the term "project" exist (Turner, 1993; Wateridge, 1996;
Munns & Bjeirmi, 1996). However, when examining these definitions, one notices that the
same elements keep recurring, often in a slightly different form :
• Unique: a project is a non-routine endeavour with objectives that are outside normal
working conditions. The construction of a production plant can be considered a project,
the production of goods cannot.
• Objectives: every project has (a) specific aim(s). This justifies the resources, time and
effort that are invested in projects. The aim can be very diverse, ranging from problem
solving (redesigning a production process) to creating new market opportunities
15
(development of a new software package). The objective(s) are the ultimate reason why a
project exists.
• Begin & end: resources are brought together at a certain point in time to realise the
objective set out. Once the objective is reached (or when the project has been recognised as
a failure), the project will be tenninated and the resources will be relocated so that they can
be used for other purposes (example: once a plant is fully operational, the construction
engineers are relocated to an other project). Often, au end-date is put forward at the
beginning of the project as a constraint (see infra).
• Resources: people, material and financial means are brought together and used as input for
a project.
• Constraints: as with every economic activity, a project needs to deliver profit in one form
or another. To assure the profitability of a project the sponsor poses constraints upon the
project. Often, these constraints exist out of a time- and budget limit and specifications
concerning the approach or result of the project. This implies that the objectives need to be
realised within a reasonable time-span and with a reasonable amount of resources.
Using these recurring elements, a definition of a project can be formulated as follows:
A project is a non-routine endeavour to achieve a specific objective. The achievement of

the objective involves a series of activities and tasks that use human, material and
financial resources. A project has a clear beginning and end and has to be completed
within a set of constraints. Traditionally, this set of constraints exists out of three
elements - a time limit, a budget and specifications - which are called the triple
constraints.
2.1.2.2 Proiect properties

A project is the response to a real life problem or opportunity and is thus executed within a
specific context. It evolves through several stages (lifecycle). A lot of parties are involved
during one or more of these stages. In order to understand the concept of projects and project-
management better it seems sensible to examine the project lifecycle and the parties involved
more closely.
2.1.2.2.1 Project lifecycle
Since a project has a well-defined beginning and ending and develops through different
stages, the period of existence of a project is often described as the project's life. Although the
objectives, the scope, the constraints and the way in which projects are managed and executed
can differ considerable, most projects seem to evolve following a predefined scheme of
stages. This scheme of stages is called the project lifecycle.
A lot of research has been done on the subject. Nevertheless, there is little agreement on the
most appropriate lifecycle model (Wateridge, 1996). Table 1 presents several different types
of lifecycle models.
16
Chapter IT: Literature review
Project lifecycles
Wateridge Conceptualisation Requirement & Functional design Implementation Operation

Specification
Turner Proposal & Initiation Design & Appraisal Execution & Control Finalization & Close out
British Per- Ga- Define Generate Evaluate Select Com- Plan Imple- Monitor
Telecom ceive ther pro- solutions solutions solutions mum- execu- ment
pro- data blem cate tion
blem
Mann & Stability Preliminary Detailed preparation Installation & testing Conversion Stabili- New
Williams & equili- planning sation equili-
brium brium
before
change
Munns & Concep- Planning Produc- Handover Utilisation Close- Integra- Operations mode Retire-
Bjeirmi tion tion down tion ment
Waterfall Requirements Specifica- Planning Design Implemen Integra- Operations mode Retire-
model tions -tation tion ment
Proto- Rapid prototyping Specifica- Planning Design Implemen
typing tion -tation
Table 1: Project lifecycles
Based on Schach, 1996; Muns & Bjeirmi, 1996; Turner, 1993; Wateridge, 1996; Mann & Williams, 1960
17
Jn this dissertation, a four-stage lifecycle is used.

1. Conceptualisation phase: in this phase, a feasibility study is performed on which the
development of the project definition is based.
2. Analysis phase: the requirements and needs of the stakeholders are examined in detail.
3. Development/ Taylor phase: the application is developed or the software package is
adjusted to the needs of the company
4. Implementation: the application is implemented and goes into production
After phase four, the application is handed over to an operations department, which uses the
application (utilisation phase) until it is updated or put aside (retirement).
This project lifecycle is rather rudimentary. However, since it is only used to give an
indication of the timeframe in which certain phenomena happen, this classification is
sufficient.
2.1.2.2.2 Participants
A project involves interactions between people. These people can be grouped, based on their
tasks and positions. These groups are referred to as "parties".
When looking at an average project, five parties can be distinguished:
• The first party that is involved in a project is the management. They represent the parent
organisation, which is the owner and sponsor of the project. The organisation provides the
funds and is the main benefactor of the project.
• The second party involved is the projectteam. These are the people who are responsible
for planning, organising, implementing and controlling the work. The bead of the
projectteam is the project manager. He I she controls the team and is responsible for the
external communication.
• The third party involved are the users. They will operate the outcome of the project on
behalf of the owner to achieve benefits. They are represented by a champion. This is a
representative user who has been asked to participate in the project team. He / she
translates and communicates the user requirements towards the project team.
• The fourth party are the supporters. This is a very heterogeneous group of people that
supplies resources or services to the project in one form or another. A supporter is not
necessarily an employee of the organisation. It can be a subcontractor as well.
• The last party are the stakeholders. These are people or groups whose lives or
environment are affected by the project, but who receive no direct benefit, nor have direct
influence on it. People working in another department or competitors are examples of
possible stakeholders.
(Based on Turner, 1993)
Not every party participates in every stage. Putting together the lifecycle and the different
parties provides a profile of an average project.
18
2.1.2.2.3 The profile of an average project
Based on the combination of a project lifecycle and the description of the parties involved, an
average project profile can be constructed. This profile is presented in the following figure.
-- Time
-
~
Project lifecycle
• •
Conceptuali- Analysis Development Implementation Utilisation Closedown
sation
Owners Owners Owners Owners Owners Owners
Users Users Users Users Users
Supporters Supporters Supporters Supporters
Stakeholders Stakeholders Stakeholders
Figure I: Profile of an average project

Based on Murms & Bjeimti, 1996
The owners and users set out the goals, but need to consult the supporters because they are the
ones that provide resources and services.
Once the project is defined, the analysis phase starts. All parties involved are asked to
participate in the analysis, development and implementation of the project.
After the implementation, the resulting application is handed over to an operational

department. Users will apply the application under guidance of the management to generate
gains for the organisation, which is the main benefactor from the project.
The decision to close down the project is a decision primarily made by the owners of the
application.
19
Success factors for JCT projects
2.1.3 An ICT proiect

2.1.3.1 Definition JCT proiect
Information technology (IT) refers to hardware, software and communication technologies -
essentially equipment- and attendant techniques (Willcocks, 1994). It is the set of all
technological solutions to the problem of collecting, storing, manipulating and distributing
information (Hochstrasser & Griffiths, 1991). Information systems (IS) is a wider concept
referring to how designed information flows attempt to meet the information needs of the
organisation (Willcocks, 1994). IS may be more, or less, 1T based.
An ICT project is defined in this dissertation as a project where capital investments are
made in information technology (IT) to enhance an organisation's information needs
(IS).
Note that some authors prefer the term IST or [S/IT instead of the term ICT. Bacon (1994) for
example defined IST as any acquisition of hardware or software or any "in-house"
development project that is expected to add to or enhance an organisation's information
systems capabilities and produce benefits beyond the short term.
2.1.3.2 Properties of an JCT proiect

ICT projects are a subset of tbe set of projects. Consequently, they share many characteristics
with other type of projects. When comparing Iifecycles for example, there is a great
resemblance between the Iifecycle of an average project and lifecycles developed specifically
for ICT projects ( compare the waterfall and prototyping models with the other lifecycles
presented in table !). Yet, some characteristics differ significantly. These characteristics give
ICT projects their own identity and force project managers to adjust their management style
according.
Most of the research and literature addresses project management principles in general and
neglects the specific nature of ICT projects, hereby neglecting the subtle changes in project
management approach (Wateridge, 1996). Nevertheless, these differences between ICT and
other type of projects are more than substantial. This is illustrated in table 2. A comparison is
made between an ICT project and a project aimed at developing an additional production line
for cars.
20
Table 2: Differences ICT vs. other projects
JCT project Project to develop a additional

production line
Supportive in nature Contributing directly to the business
objectives
High risk and long lead times Low risk and/or short lead time
Large part of the costs & benefits are hidden Large part of the costs & benefits are
known
Benefits are seen m other areas of the Benefits can be attributed directly to the
business and over a longer period project
More difficult to assess Less difficult to assess
High degree of importance on subjective High degree of importance on objective
features features
Often changing requirements Seldom changing requirements
More iterative in nature More sequential in nature
Significant difference between user's I Less friction between user's I customer's
customer's wants & needs wants & needs
Management emphasis on allocation and use Management driven by task dependencies
of resources
Based on Hmton & Kaye, 1996; Clemonts & Weber, 1990; W1Jlcocks l 996, Turner, 1993; Wateridge. 1996
Looking at these differences, one can expect that the success criteria and the success factors
differ between TCT- and other types of projects. It is thus sensible to examine ICT projects
more in detail, without regarding it as just another subgroup of the set of projects and
transposing the properties of projects in general on ICT projects. These differences justify an
extensive study of lCT projects, as this one.
2.1.4 A successful ICT project

2.1.4.1 Ambiguity
As Fowler & Walsh (1999) state, the definition of the concept of ICT success is, in itself,
potentially problematic. There is no consensus on the criteria for success, except for three
standard criteria - meeting time, meeting budget and meeting requirements (Wateridge 1995
& 1996).
Too often, success and failure are seen as "black and white" . However, projects may not
always be seen as completely successful or completely failed (Wateridge, 1996). Moreover,
the parties involved may perceive the terms "successful" or " failure" differently (example: a
project which has exceeded time and budget might be perceived as a success by the users, but
not by the management) (Belassi & Tukel, 1996). The appreciation of the parties might even
evolve during the different stages of the project.
Determine whether an ICT project is successful or not is thus not trivial. A lot of ambiguity
exists. In this section, the different reasons for this ambiguity will be examined more c losely.
In a following section, an attempt is made to fonnulate criteria that can be used to evaluate the
level of success of a project.
21
2.1.4.1.1 Ambiguity due to differences between parties
As stated earlier, five different parties can be distinguished who are involved in ICT projects.
Every party has its own objectives and expectations and thus its own view on the success of a
project (Munns & Bjeirmi, 1996; Turner, 1993; Wateridge, 1996). Consequently, the criteria
by which they measure success differ as well.
Th_is is illustrated by the survey of J. Wateridge (1997) where different participants were
asked to list the criteria by which they judged the success of the project. In table 3, a partial
overview is presented of the results of this survey.
Table 3: Comparing criteria for success
Criteria for success % frequency of mention

All "Csers Project
respondents mana!.!.ers
Haoov team 26 31 27
Meets quality 49 3S 58
Happy sponsor 28 15 27
Meets time 67 SB 71
Achieves purpose 71 65 60
Happy users 49 69 35
Meets budget 64 62 71
Meets user requirements 87 96 81
Commercial success 48 3S 60
Others 7 12 8
Source: Wateridge, 1997
This table clearly demonstrate that the impact of the criteria used is not the same for every
party. The criterion "commercial success" for example is of importance for most project
managers, but is far less important for the users.
Based on literature, an attempt is made to indicate which criteria are of importance for every
of the parties involved in an ICT project. Moreover, the mechanisms behind these criteria are
examined.
l. Management (Owner I sponsor)
The management is primarily interested in the benefits the product brings (Turner, 1993).
Time, cost and specifications are constraints that effect the owner's judgement because they
influence the benefits of the project, but they are not the primary concern (Turner, J993).
Hence, the owner is interested in the triple constraints, but only to the extent in which they
contribute to the expected gains.
Often, a project manager is appointed because the sponsor has no expertise or time to manage
the project. Faced with a problem and by simply appointing a project manager the sponsor
often considers the problem as solved even before the project begins. The mere act of
appointing a project manager will mean a decision has been made and it is now someone
else's concern (Wright, 1997).
22
2. Users
Users feel that the system delivered should meet their requirements and that they should be
happy with the system (Wateridge 1997). Their objective is usually to obtain the best (not
optimum) product, at any price. They are only concerned about price if the owner is part of
the user group, or if they need to get priority for their projects before others (Turner, 1993).
They will not perceive a project as a failure if it is implemented a few weeks too late or over
budget.
When looking at the results of Wateridge's survey (Table 3), this is illustrated by the high
score on the topics "happy users" and "users requirements" and the low score on the time
constraint.
3. Projectteam / project manager
Projectteam members and project managers are focusing on the short-term criteria (the triple
constraints) which are set by the owner, for the way in which a project manager will be
judged by the sponsor is if the project is completed to specification, on time and within budget
(Fowler & Walsh 1999, Wateridge 1997). This behaviour is amplified by the fact that their
involvement normally ceases after the handover (Turner, 1993).
Project managers tend to take a subservient role to the person or organisation employing
them. This is illustrated by the fact that they refer to the sponsor as their "client", which
means that they will strive to satisfy the other party to the transaction: "their client" (Wright,
1997). This is done by delivering what is asked for, on time and with the means that were
allocated to the project.
Comparing the view of the project manager and the owner, one notices that the project-
manager is primarily concentrating on short-term, process related criteria (Will we finish on
time and within budget?), where the owner is concentrating on longer-term, product re lated
criteria (Will the end result deliver gains?).
4. Supporters
Since the distance to the project manager is smaller than the distance to the owner, the
supporters will usually be more concerned about satisfying the project manager than
satisfying the owner (Turner, 1993). They are thus more concerned about the short-term
objectives of the project.
5. Stakeholders
The stakeholders' group exists out of many different subgroups, all with their own goals and
objectives. It comes as no surprise that a typical project will have some stakeholders who will
support it and some who oppose it (Wright, 1997). Some stakeholders will benefit if the
project succeeds and, the other way around, some stakeholders have interests in the failure of
a project.
23
2.1.4.1.2 Ambiguity due to interpretation differences among people
Not only is there a substantial difference between the different parties (see supra), even
among individuals of the same group, opinions may vary a lot. Every individual has his/her
own set of objectives against which the project is measured and these may be very subjective
(Fowler & Walsh, 1999).
Besides the overt objectives (the objectives adapted by the group), individuals often have
hidden agendas (covert objectives) that influence their opinion. Typically they may be:
• A project manager aiming to enhance his/ her career.

• Operation managers wishing to maintain a status quo.
• Users wishing to protect their job.
• Stakeholders resisting to change .
•
Sometimes these covert objectives support the overt objectives, but often the two sets (covert
& overt) are in conflict. This will cloud individuals' judgement about the success of a project
(Turner, 1993) and make it difficult to judge a project exclusively by user or owner happiness.
2.1.4.1.3 Ambiguity due to the stage at which the evaluation takes place
The evaluation of an TCT project can be performed during different stages in the project
lifecycle. Some criteria can only be assessed at the end of the project, other are measured
throughout the project lifecycle (Wateridge, 1998). Some can only be measured long after the·
tem1ination of the project.
This implicates that the judgement on success of a particular project may vary over time
(Wateridge, 1998). The viewpoint of the participants can alter quite significantly depending
on the stage the project is in. A project that looked very promising at the handover stage will
be regarded as a failure at the utilisation phase if the users refuse to work with the application
or if it turns out to be a commercial disaster.
Since project managers primarily focus on short-term objectives and their involvement often
ceases at the handover (see supra), the gravitation point of their opinion on the success of the
project will be situated at the handover stage. The users' evaluation is primarily based on their
experiences during the utilisation phase while the owners, who are interested in the
commercial success or the benefits of the project, base their judgement on the return of the
project. It might even take some time after the retirement before the exact return can be
calculated.
The combination of the fact that the different parties do not necessarily use the same criteria
and the fact that the gravitation points of the parties involved differ, can partly explain the
variations of opinions one sometimes finds among the participant of an ICT project.
24
2.l.4.1.4 Ambiguity due to influence of trends and fashion
The criteria used to evaluate the success of ICT projects are not free of trends & fashion.
Often, these trends are dictated by "new" management paradigms or technical
"breakthroughs".
Ln the '70s for example, the amount of memory consumed by an application was a criterion in
some ICT projects due to the fact that memory was scarce and, consequently, expensive.
Nowadays, this is hardly an issue anymore. After the publications of Porter and Earl in the
'80s, business alignment became a criterion and later, due to the economic crisis, cost
reduction turned out to be quite important. Today it seems that gaining a competitive
advantage and using TT as a strategic weapon are important criteria to assess ICT projects.
This limited and short overview clearly points out that the way in which people evaluate ICT
projects varies over time. A project that was bri!Jiant in the '70s might be judged differently in
the '90s because a different set of criteria is used to evaluate it.
Obviously, since the success factors change over time, it is methodologically unsound to
evaluate lCT projects based on success factors formulated by scientist or practitioners several
years ago.
2.1.4.1.5 Ambiguity due to ICT proiect characteristics
As mentioned in section 2.1.3.2, ICT projects have some very specific characteristics that
distinct them from other types of projects. One of these characteristics is that the goals tend to
shift as the project progresses. Consequently, criteria stated at the beginning of the project
may lose part of their accuracy along the way and are sometimes replaced by other -often
subjective- criteria on which there is no (formal) consensus.
Obviously, this can lead to confusion and misunderstandings between the parties and the
people involved. Moreover, it can contribute to ambiguity concerning a project' s success.
2.1.4.2 How to measure success?

2.1.4.2.1 lntroduction
Due to the potential problems and ambiguities described in the previous section, the definition
of a successful !CT project, and thus the selection of appropriate success factors, is in itself
potentially problematic. Nevertheless, in order to examine ICT projects in a quantitative way,
criteria should be formulated to make the distinction between good, mediocre and failed
projects.
Obviously, because of the potential problems related with this issue, this set of success criteria
should be a well-balanced combination of criteria measured at different stages of the project,
reflecting the different viewpoints of the people involved. However, even when the set of
criteria reflects and anticipates most problems, they should be applied with care.
25
Therefore, the set of success criteria described in this paragraph will not be used to position
projects on an ordinal scale or even to rank the projects. It will be used as a rough tool to
classify projects into three groups: good, mediocre and failed projects.
In order to formulate a list of possible criteria, it is necessary to examine the traditional and
the current practise and the criticism formulated on them. This provides a more solid basis for
the formulation of the set of criteria that will be used in this study.
2.1.4.2.2 Traditional success factors
Since the 60s, many authors have accepted the triple constraints (time, cost, specification) as a
standard measure of success (Powers & Dickson, 1973; Munns & Bjeirmi, 1996; Wright,
1997) and this still appears to be extremely important in evaluating the success of lCT
projects (Wateridge 1998, Turner, 1993).
The primary reason why the triple constraint remains so popular is that they reflect the very
nature of projects itself (Wright, 1997). Looking at the definition of a project (see supra),
precisely these elements (time, cost, specifications) form the core of the definition.
Furthennore, time and cost are objective criteria while most of the other criteria formulated
(see infra) are subjective in nature (Turner, 1993) and thus difficult to measure.
The major criticism on this approach is that it attaches too much importance to the viewpoint
of the project manager or contractor (Munns & Bjeirmi, 1996; Wateridge, 1996; Turner,
1993). Delivering what was asked for, within time and budget are exactly the criteria that the
projectteam / project managers find the most important (see section 2.1.4.1). They are
measured at the handover stage, the gravitation point of the project manager. These criteria do
not take into account the gains (primary objective of the owner), or the user satisfaction
(primary objectives of the users), which are measured in a later stage in the project lifecycle.
Furthermore, basing the judgement of a project solely on the triple constraint can lead to
strange situations. Suppose, for example, that the project manager delivers a new computer
application on time, within budget and following the specification, but there are no benefits
because the users refuse to ~ork with it. If solely the triple constraint is used to judge the
project, it will be regarded as a successful project. However, it does not satisfy management
or users.
"In most ofthe early studies in the area, it was assumed that if a projects completion time
exceeded its due date or expenses overran the budget, or outcome did not satisfj., a
company's predetermined performance criteria, the project was assumed to be a failure. "
(Belassi & Tukel, 1996)
"The objectives of both 'the project management' and ' the project' are different. The
control of time, cost and progress, which is often the project manager's objectives, should
not be confused with measuring project success."
(Munns & Bjeirmi, 1996)
26
2.1.4.2.3 Overview of other possible success factors
Some authors started to enhance the list of criteria in order to eliminate the criticism. They
recognised that the triple constraint primarily represents the project manager's view and
expanded their list with criteria as
• Provide satisfactory benefits to the owner

• Satisfy the needs of the owner, users and stakeholders
• Satisfying the needs and specifications of users and other parties
• User satisfaction with the system or with the outcome of the system
(Turner, 1993; Wateridge, I 996)
At the same time, it was recognised that the perceived success is of paramount importance to
the eventual success of ICT projects (Baker et al, 1993). In other words, the subjective
interpretation of success criteria by the different people involved needed to be incorporated
into the criteria. If the owner is convinced that he/she has a good return, his or her
appreciation of the project will be positive, regardless the actual return. This resulted in an
extension of the set of criteria with criteria as:
• Happy users
• Happy sponsors
• Happy project team
Favourable attitudes towards the system on part of the users
(Baker at al, 1993; Wateridge, 1996 & 1998)
Furthermore, sometimes an extra criterion was added which reflected the trends / fashion at
that time.
For example:
• Realise the business benefits required in terms of efficiency, effectiveness or new
business
• Technical performance
• Meeting quality levels
• Within the scope of corporate culture and values
• Meeting post-audit analysis
• Appropriate performance standards
• Computer operations function
However, these criteria did not solve the criticisms formulated. They only reflected the
concerns of the managers or IT-people at the time the project was initiated.
27
2.1.4.3 Preposition of a set of criteria to evaluate the success of

JCT proiects
The definition of a successful ICT project should be constructed so that the success criteria
derived from it take into consideration the criticisms fonnulated in previous sections.
This means that these success factors should not only represent the viewpoint of the project-
manager, but reflect the viewpoints of the other parties as well. lt should contain criteria that
are measured at different stages in the lifecycle. Criteria based on trends or fashions are
excl uded as much as possible. Moreover, the set should be constructed in such a way that it
takes into account the subjective element in the evaluation by the different parties.
Based on these guidelines, the definition of a successful ICT project will be formulated as
follows:
A successful ICT project is a project that delivers on time and within budget an
application that is constructed following the ex ante stated specifications and
requirements. Furthermore, the users, projectteam and the management should be
happy with it.
In other words, six criteria are used:

1. On time
2. Within budget
3. To specifications 1
4. User happiness
5. Projectteam happiness
6. Manager happiness
A project that is capable of fulfilling all criteria is considered as very successful. A failed
project is defined as a project that failed in at least four of these six criteria.
In order to judge a project, the amount of time and budget used are compared with the date
and budget stated in the documents written during the conception phase. The outcome will be
examined to see if it fulfils the requirements. Furthermore, the different key players (users,
project managers and management) are asked if they are happy with the outcome of the
project.
Evaluating time and budget restraints and checking whether the requirements are fulfilled can
be done immediately after the handover. Asking the opinion of the different parties involved
should be done during the utilisation phase. In other words, the participants shoul d have
sufficient experience with the application to give a grounded judgement.
1
Note that the specifications can be derived both from operational- or strategic concerns (cfr. Strategic fit) .
28
2.2 Success factors for ICT projects: literature

.
review
2.2.1 Introduction
The literature review of this part of the dissertation serves three purposes. First, it provides a
general insight into the body of literature regarding the success factors of TCT projects.
Second, a list of possible success factors should emerge. This list will be compared with the
findings of the qualitative research. Third, this literature review will be used to develop the
questions that are used in the interview phase of the qualitative research.
The literature review consists of three sections. In the first section, ICT literature is screened
for success factors. Both articles and books that deal with certain aspects of ICT projects as
well as those that deal with projects in global are discussed. The latter are discussed in more
detail in order to demonstrate the difference in approach between these studies and the
research conducted and described in this dissertation. In the second section, possible success
factors are derived from general project management literature and other types of
management literature (e.g. agent theory, goals setting theory etc). The last section gives a
synopsis of the literature review. The different elements of all types of literature are combined
and structured. An attempt is made to construct a coherent unity that combines elements of
the different research findings discussed in this chapter.
An overview of the literature survey on success factors is presented in the next figure:
Literature review success factors
Figure 2: Literature review on success factors
29
2.2.2 Possible success factors for ICT projects, based on

ICT literature
2.2.2.1 Introduction
In this section, an attempt is made to construct a list of possible success factors, based on
MIS, IT, TS and ICT literature. The section is divided into two subsections.
In the first subsection, four studies that are selected out of the limited number of researches
that approach the success factors of ICT in a holistic way, are discussed. They are selected
based of the approach used and because that these studies are often referred to. They can thus
be regarded as important research. The factors are listed and discussed as well as the
methodology, the resemblance and the differences with the PhD-study presented here.
The second subsection discusses statements from different researches that studied one or a
limited number of aspects of ICT projects and aims at combining these findings into possible
factors. Research on top management support for JCT projects for example can provide ideas
on the impact of the top management on JCT projects and thus helps to identify and explain
related factors.
At the end of the section, an overview of the factors discussed is presented.
2.2.2.2 JCT literature "holistic approach"

2.2.2.2.1 Research study nr.1: Richard F. Powers & Gary W. Dickson
Powers and Dickson conducted their study in the early seventies and published the results in
an article entitled "MIS project management: myths, opinions and reality" (California
Management Review, spring 1973, vol. XV, no. 3). This research can be situated in the first
wave of research dealing with the discrepancy between computer expenditure and satisfaction
with results. The authors initiated the study with the purpose of finding answers to the
question: "What organisational and procedural factors are correlated with success in MIS
projects?"
The methodology used resembles the methodology of this study. They started with the
construction of a list of possible success factors based on a literature survey, which they
presented to a number of lT managers who ranked them. With this information in mind, they
conducted an in-depth survey in 10 different companies, examining two projects a company.
Based on the information gathered from these cases they tried to find correlations between the
potential success factors and the success criteria used in their definition of a success ICT
project (i.e. time, cost, user satisfaction, computer operations\
Table 4 gives an overview of the results of their statistical analysis. A plus sign indicates a
positive relationship; a negative sign represents a negative correlation. Note that only those
factors are listed that are correlated with at least one success criteria.
2
The impact of the project on the computer operations function.
30
Table 4: Correlation between factors and success criteria
Factor Success criteria

Time Cost User Computer
satisfaction operations
Participation by operating management in +
design, formal approval of specifications and
continual review of project.
Organisation level of top computer executive - +
Documentation standards used and enforced +
Low turnover of project personnel +
Source of origination of project (MIS staff or +
user)
Length of experience in the organisation of - +
project personnel
High level programming language used for +
project
High formal educational level of project - +
personnel
Separation of analysts and programmers for + -
large projects
Overall size of organisation systems staff - - +
The researchers found that the four success criteria posited in the study were statistically
independent. ln other words, every success criteria was measuring a different dimension of
the JCT project's success. Ten possible success factors were found to correlate with at least
one of the success criteria.
Surprisingly, no factor was positive ly correlated to the cost criterion. In other words, none of
1he criteria tested has a statistically relevant - positive or negative- impact on the completion
ofICT-projects within budget. Furthermore, note that the impact of the factors on the criterion
"user satisfaction" is very different from their impact on the more tangible criteria "cost" &
"time". In several cases, factors have an opposite influence on "user satisfaction" compared to
the "time" and "cost" criterion. Finally, no factor affects multiple criteria consistently.
Based on the examination of the rejected possible factors (i.e. factors posedin the initial list
with no statistically relevant impact on the success criteria), the authors note that there is a
large difference between what MIS professionals believe to be important factors for MTS
projects and what factors the study shows to actually be related to successful projects. This
leads them to suggest that what is generally accepted as givens or principles in the MIS field
should be subjected to rethinking and further examination.
31
The combination of the knowledge gained with the ranking and the in-depth field research
leads to the fonnulation of the following management guidelines, which functioned as part of
the conclusions:
• Different MIS environments exist. Project managers should recognize these differences
and apply appropriate selective techniques in managing projects in line with their
distinctive characteristics and requirements.
• With respect to MIS projects, an evolutionary approach to project development should be
adopted. This implies a rather fluid development period, which takes explicit account of
the user's learning process in his/here own information decision situation.
• Follow-through of the information systems staff is imperative to the successful
implementation of the MIS project. If the manager who receives the products cannot or
will not use these products, the entire effort has been wasted.
• Project management schemes must be geared to the specific characteristics of the MIS
project.
• Wherever possible, the combination analyst/programmers should be used in developing
MIS projects. This should facilitate user confidence and participation, as well as afford
greater support to the user in the period following initial cutover to the computer.
• Large omnibus projects covering many functional areas should be avoided.
• User participation is crucial to the success of the MIS project. However, user participation
must be taken literally: the actual manager who is to receive and use the products of the
project, not staff personnel, should be the participant.
Although this research dates from the seventies - the middle ages in IT-terms -, this is a very
interesting research because of the methodology used. Moreover, it will be interesting to
compare the findings of this study with more recent research. It provides us with an insight in
the change of views on ICT over time.
2.2.2.2.2 Research study nr.2: The Standish Group
In January 1995, the Standish Group published a study entitled "CHAOS". The study aimed
at estimating the scope of software project failures, discovering the major factors that cause
software projects to fail and finding remedies for these failures. 1n 1996, a fo llowing study
was published on the subject, called "Unfinished Voyages" , which explored and refined the
factors described in the CHAOS study. The abstracts of these studies, as well as an
application form for membership - which is needed for ordering the complete rapports-, can
be downloaded at the Standish Group website at www.standishgroup.com.
1. Chaos
In order to estimate the scope of software failure - the first aim of the CHAOS study -, a
survey was conducted, resulting in 365 responses of IT executive managers, representing
8.380 applications. The outcome is presented as a set of "failure statistics", painting a rather
disheartening picture of the success of software projects. The findings are in Line with other
studies, as the study of Hochstrasser & Griffiths (1991 ), which are described and referred to in
other parts of this dissertation.
32
ln a following step, projects were divided into three groups:

1. Project success: the project is completed on-time, on-budget, with all
features and functions as initially specified.
2. Project challenged: the project is completed and operational but over-
budget, over the time estimated, and offers fewer features and functions
than originally specified.
3. Project impaired: the project is cancelled at some point during the
development cycle.
Tn the next step, four focus groups were created, each with an average of ten JT executives of
major companies. The purpose of these groups was to soLicit opinions on why projects fail.
This led to a list often factors, each with a weight factor to indicate their importance.
Table 5: Success criteria, formulated by Standish Group
Success criteria Points

User .Involvement 19
Executive Management Support 16
Clear Statement of Requirements 15
Proper Planning 11
Realistic Expectations 10
Smaller Project Milestones 9
Competent Staff 8
Ownership 6
Clear Vision & Objectives 3
Hardworking, Focused Staff 3
TOTAL 100
2. Unfinished Voyage
The "Unfinished Voyage" study tried to explore the factors listed in the CHAOS-study into
more detail, which should make it possible to create models and solutions that can be used on
project level. In order to do so, the Standish Group brought together 60 IT professionals who,
in a Delphi-like way, were asked to work out the factors in more detail.
The result is a set of questions for every factor. The answers lead to a rating-score that should
indicate success. [fa question is answered positively, the question's score is added to the total
score. A high score indicates a high chance for success; a low score indicates a large chance
for failure.
Table 6: Scoring test
Success criteria Score Sum

User Involvement 19
Do I have the right user(s)? 3.8
Did I involve the user( s) early and often? 3.8
Do 1 have a quality user(s) relationship? 3.8
Do I make involvement easy? 3.8
Did I find out what the user(s) needs? 3.8
33
Executive Management support 16

Do I have the key executive(s)? 3.2
Does the key executive have a stake in the outcome? 3.2
Is failure acceptable? 3.2
Do 1 have a well-defined plan? 3.2
Does the project team have a stake? 3.2
Developing clear statements of requirements 15
Do I have a concise vision? 3
Do I have a functional analysis? 3
Do I have a risk assessment? 3
Do I have a business case? 3
Can I measure the project? 3
Proper planning II
Do I have a problem statement? 2.2
Do I have a solution statement? 2.2
Do I have the right people? 2.2
Do I have a firm specification? 2.2
Do 1 have attainable milestones? 2.2
Setting realistic expectations 10
Do I have clear specifications? 2
Do l have prioritisation of needs? 2
Do I have small milestones? 2
Can I manage change? 2
Can I prototype? 2
Small project milestones 9
Am I using the 80/20 rulej? 1.8
Am I using a top-down desi1m? 1.8
Am I setting t ime limits? 1.8
Am I using a prototype tool? 1.8
Can I measure progress? 1.8
Competent staff 8
Do I know skills required? 1.6
Do I have the right people? 1.6
Do I have a training program? 1.6
Do I have incentives? 1.6
Will the staff see it through? 1.6
Proiect ownership 6
Do I have defined roles? 1.2
Do I have a defined organization? 1.2
Does evervone know his or her role? 1.2
Are incentives attached to success? 1.2
ls everyone committed? 1.2
Clear vision and objectives 3
Is the vision shared? 0.6
Is the vision ali1med with company goals? 0.6
Are objectives achievable? 0.6
3
In the majority of cases, 20% ofa project's features will provide 80% of user benefits.
34
Chapter II : Literature review
Are the ol>jectives measurable? 0.6

Do I have honest sanity checks? 0.6
Hardworking, focused staff 3
Are there incentives? 0.6
Are we concentrating on quantifiable deliverables? 0.6
Does each member have part ownership? 0.6
Does everyone work together? 0.6
Are we building confidence? 0.6
TOTAL 100 LOO
Although the Standish group is highly respected for their research, some remarks can be
made. First, the search for success factors is based on the opinions of LT executives and fT
professionals. The definition of success used is primarily oriented towards IT-professionals
(see supra). The view of the user or the management is not taken into account. F urthermore, it
is based on opinions. This leads to the following sentence in the "CHAOS" study:
... This study is hardly in-depth enough to provide a real solution to such a daunting
problem as the current project failure rate
Another remark is the use of the term "success criteria" . Throughout both studies, a search is
made for factors that cause software projects to fail. Manipulating these factors may avoid
failure, but does not guarantee success. The factors that make a difference between a
mediocre and a successful project are not necessarily the same as those factors preventing
failure.
Yet, the results of these studies are cited numerous times in colloquia and speeches, often
even extrapolated by the speaker to JCT projects, other than software development. This is the
prime reason why these studies are discussed here. During the preparation of this thesis,
several colleagues mentioned the research of the Standish Group, pointing out that an
essential part of the research had been done already. Luckily, close examination of the studies
of the Standish Group led to shade these pronouncements.
2.2.2.2.3 Research study nr.3: Ph.D. thesis of John Wateridge

1. Introduction
In July 1996, John F. Wateridge submitted his Ph.D.-thesis at the Henley Management
College, Brunel University, UK, entitled "Delivering Successful IS/IT Projects; Eight key
elements from success criteria to review via appropriate management, methodologies and
teams." His Ph.D. research resulted in several articles as well, which are quoted regularly
throughout this thesis.
His research is based upon fo ur research questions:

1. What can be defined as success criteria for ICT projects and what factors are
appropriate to deliver the defined success?
2. What tools, techniques and methodologies are available for the development and the
management ofICT projects and how can they be used to deliver the success criteria?
3. What is the role of the project manager and what qualities/skills should a manager of
ICT projects possess?
35
4. How can a manager become a better manager to help towards the success of'JCT
projects?
In view of this dissertation, especially the first research question is of major importance.
Nevertheless, the answers fonnulated on the other questions contain several elements that are
of interest as well.
2. Methodology
The author starts with an extensive literature study, which forms the basis for interviews with
1T professionals. Both the survey and the interview lead to a questionnaire, sent to IT -
professionals, managers, project managers and IT - users. Based on the analysis of the data
gathered, models are constructed, which are tested during post implementation interviews.
Finally, the author develops a health check. This list with questions helps the manager to
evaluate and diagnose the situation of the JCT project and helps him / her to respond and to
take appropriate action.
3. Literature
Wateridge starts with an extensive screening of the prior research in the field of IS and IT,
leading him to conclude that very little has been done on success criteria and success factors
of JCT projects. Furthermore, when comparing the scarce number of researches dealing with
this subject, one notices that there is little agreement amongst authors. The author illustrates
this very clearly by comparing the success criteria used by different authors. Since different.
criteria lead to different appreciations of success, the related success factors are bound to be
different as well.
Another observation was that, in the past, too often only the viewpoint of the project manager
was taken into account, ignoring the wishes of the users or sponsors. This Jed to an over-
emphasis on tangible criteria like time and cost.
In the past, there has been little attempt to link the factors of success to the success criteria.
Some studies on success factors are even executed without defining the success criteria in an
explicit manner.
4. Success criteria
Since there is no agreement on the criteria to evaluate success, an extensive part of the thesis
is dedicated to the search for these criteria. Having a reliable set of criteria is a basic condition
for conducting research on success factors. This part of the research is primarily qualitative in
nature and uses interviews and questionnaires to collect data.
Wateridge suggests six possible success criteria:

• It is profitable for the sponsor/owner and contractors.
• It achieves its business purpose.
• It meets its defined objectives.
• It meets quality thresholds.
• It is produced to specification, within budget and on time.
36
Chapter II : Literature review
• All parties (users, sponsors, the project team) are happy during the project
and with the outcome of the project.
At the same time, he notes that the importance of these criteria varies depending upon the
party who judged the success of the project. The users for example stressed the fact that they
should be happy with the result rather than emphasising budget or time constraints, two
criteria that are more important for the IT-manager and the owner. Furthennore, the relative
importance of the different criteria may vary amongst different types of projects.
Consequently, all parties involved - and thus not only the 1T or project managers - should
agree on the criteria for success by which the project is to be measured before the project is
started.
5. Factors for success
Based on previous literature and the analysis of the responses on the questionnaires, the
author distinguished a list of possible success factors and identified their relationship with the
criteria listed. Table 7 presents an overview of the factors found and their impact on the
criteria. Note that P stand for primary impact, S stands for secondary impact.
Table 7: Factors vs. criteria
Criteria
(P = primary impact) Comm Meets Meets Happy Achieve Meets Happy Meets Happy
(S = secondary impact) success Budget Req s. users purpose time snoasor quality team
F
Leadership s s p
Motivation s p
A p s p s s p s s
Planning s
C Dev. Method p s p
T Monitoring p p p s
0 M ITT11t. Method s s p
R Delegation s p
p p p
s Communication p
C lear objectives s p p s
User involvement s p p p p p
Top mgmt. Support p p p p
The author divides the factors into four different groups, based upon the primary impact they
have on the criteria:
Group 1: Satisfying time and cost constraints, thereby creating a profitable project
The main factors to ensure profitability are planning, control, top management support
and development methods. The first two factors have an impact on time and costs, and
thus on the profitability of the project. The other two ensure the availability of the
resources needed.
37
Group 2: Satisfying quality constraints
At the outset of the project, quality constraints must be defined. The view on the quality of
the product may alter along the way. This implies intensive communication and user
involvement.
Group 3: Satisfying the needs and specification of users and other parties
JCT projects involve change and thus automatically resistance to change. To resolve or
overcome this resistance, intensive communication and user involvement are crucial. lt is
an effective way to know and fulfil the needs of the users and sponsors as well.
In order to fulfil the needs of the project team, a high level of leadership and direction is
needed. A good delegation of tasks among a well-chosen and highly motivated project
team will help to fulfil their needs.
Good communication, leadership and motivation are the key factors for this category of
criteria.
Group 4: Satisfying the objectives and purpose of the project
A project needs to be planned carefully at a sufficiently high level at the start of the
project. The objectives have to be defined along with the purpose, the benefits required,
deliverables etc. As the project moves along, planning becomes more detailed and at a
lower level.
User involvement and management support may help to keep the focus on the objectives
of the project.
6. Eight key-elements
In the general conclusions of the Ph.D. thesis, the author lists eight key-elements, which he
believes are crucial for the success of an JCT project. This list can be interpreted as guidelines
for the management ofICT projects, primarily based on the success factors found.
Define success criteria
Projects are more successful when the criteria for judging success are defined and agreed
upon at the o utset of the project by all participants.
Apply appropriate factors to deliver success criteria
The success criteria will vary from project to project and between different participants.
Therefore, the appropriate success factors need to be manipulated.
Keep projects small/ define milestones
Keep projects small and develop programmes of projects with clearly defined and
achievable milestones and objectives.
38
Apply appropriate tools, techniques and methodologies
Apply appropriate tools, techniques and methodologies for project management, system
development and configuration management. However, caution is necessary because too
rigid or too detailed planning at the start can have a negative effect on the outcome of the
project.
Apply appropriate project management education, training and development
On the job training and experience should not be ignored. However, project managers are
often judged on their ability to deliver systems on time within budget. Consequently, they
use techniques, learned through experience, to achieve those goals. Additional training
and education can be of considerable help for the project manager.
Promote ownership, commitment and communication
The review of several projects by the author clearly showed that commitment and
ownership are very important factors in having successful outcome. In order to get this
commitment, the project manager needs to engage the best possible people and set them
realistic objectives.
Staff the project carefully
Carefully staffing the project team is an important step in avoiding conflicts. The project
team needs to be competent. The team members need to be complementary so that the
number of conflicts can be reduced. A project manager should rather engage team players
than individuals. The project manager should possess enough social skiJls to master
conflicts or better to avoid them.
Review projects and measure benefits
Project managers must learn from their success as well as their mistakes.
7. Conclusions
Although the domains of the Ph.D. study of Wateridge and this dissertation are quite similar,
there are some signHicant differences.
One of the major differences is the viewpoint. Wateridge looks at lCT projects as part of a
larger and continuous entity, i.e. a company. This is reflected in his management guidelines
(see supra), where training and education are important items and where review and learning
from mistakes are recommended. Obviously, these are guidelines that are fruitful in the long
run. These types of factors are not considered in this disse11ation since the unit of research are
individual JCT projects.
Another difference is the methodology. Wateridge uses mainly a qualitative approach, where
the methodology of this dissertation is based on a mixture of qualitative and quantitative
research methodologies.
39
Furthermore, note that no difference is made between success factors and factors that prevent
failure. It is not entirely clear whether the term "success factors" refers to factors that make a
difference between failure and no failure or factors that lift a project out of mediocrity.
2.2.2.2.4 Research study nr.4: Lucas et al
1. Introduction
In 1990 H.C. Lucas, M.J. Ginzberg & R.L. Schultz published a book entitled "Information
systems implementation: testing a structural model" (Ablex Publishing Corporation, ISBN 0-
89391-665-X). This book is a synopsis of a series of research studies, performed by these
authors, which results in the structural model presented here.
This research can be categorized into the implementation-type research, which aims at
developing management guidelines for improving the implementation of IT projects. The
authors start with the development of a conceptual foundation through the exploration of
literature. Variables and relationships between them are defined and integrated into a
structural model. This model is tested with data from two empirical studies.
The authors use the variables "acceptance" and "use" as criteria to measure the success of the
implementation of the ICT project.
2. Literature exploration & information modelling
The literature review is divided into three parts:

• Theory: propositions and theories about implementation
• Factor research: seeks various factors associated with implementation
• Process studies: deals with relationships among designers and users and on how
they approach the design problem.
This - rather extensive - literature study is presented in the first chapter of the work. The
variables / factors and processes described form the basis upon which the causal model is
constructed. The authors use the path analysis approach, which focuses on determining the
level of correlation between variables in a system and then using these correlations to identify
the underlying causal processes. A mixture of attitudinal and non-attitudinal variables are
used in the model.
Due to the focusing of the authors on a specific type of projects - projects with one
inte.rmediate level between the developer and the user: the manager - two submodels are
constructed: one representing the users' view and the other representing the view of the
manager.
These submodels are represented in the following figures. The link between both submodels
is marked by the following symbol: ~
40
Manager model
Manager belief in Manager decision Manager job

system concept style characteristics
Top management Manager knowledge Manager acceptance Manager

support of system demographics
Manager- Manager assessment Organizational

researcher of system and support
invnlvP.mP.nt ~11nnnrt
Figure 3: Manager model

41
Success factors for ICT Q!Qjects
User model
User knowledge
of system
purpose/use
User perception of
management support
"'
~
0
User decision style Satisfaction
,,
Organizational User's personal •• ••
change caused -, stake
by system
Problem urgency •
User knowledge of
system
u
f-+
,,
User acceptance
~
Use
1, ,,
~
Performance
•• •• •• ••a
1, Organizational
User - researcher User assessment of support
involvement __. system and support
I
System User job User demographics
characteristics characteristics
Figure 4: User model

42
Variable definition - Manager model
• Manager acceptance (YS): this is the central variable in the manager model and the
link to the user model. It is the predisposition to use a system or its output.
• Manager knowledge of system (Y3): how well does the manager understand the
system
• Manager assessment of system and support (Y4): measures the manager's
evaluation of the quality of the system and its supporting mechanisms.
• Manager decision style (X2): refers to the predominant approach a person uses to
solve the kind of problems for which the system is intended.
• Manager job characteristics (X3): measures task responsibilities of the manager.
• Manager demographics (X4): age, time with the company, time in job, educational
background, and so forth.
• Organizational support (XS): the degree to which organizational arrangements
foster and facilitate access to and use of a system.
• Manager belief in system concept (YL): the extent to which a manager believes in
the underlying concept or approach behind the system to solve the organization's
information or decision problems.
• Manager - researcher involvement (Y2): measures the degree of interaction
between the manager and the system designer concerning system development.
• Top management support (XI): measures the level of support exhibited by the top
management.
Variable definition - User model
• User acceptance (Y 10): measures the potential user's predisposition to personaJly

use a specific system. It is a measure of behavioural intention that will be reflected
in actual use.
• User knowledge of system (Y8): how much does the user understand of the
functioning of a particular system.
• User assessment of system and support (Y9): measures the user's evaluation of the
system and its supporting mechanisms.
• User decision style {Xl O): reflects the user' s characteristic way of solving a
problem or making a decision.
• System characteristics (Xl 1): the features and capabilities of the system (user
friendliness etc).
• User job characteristics (X12): measures task responsibilities of the user.
• User demographics (X13): age, time with the company, time in job, educational
background, and so forth.
• User-researcher involvement (Y7): measures the degree of interaction between the
manager and the system designer.
• User's personal stake (Y6): measures the degree to which the user' s "future" (e.g.
rewards) is tied to the system and its use.
• User perception of management support (X6): measures the user's perception of
the acceptance of the system by the manager.
• User knowledge of system purpose and use (X7): can the user assess the
importance of the system?
43
• Organizational change caused by the system (X8): measure of the degree of

change in task environment, working relationships, communication patterns, and
organizational structure that users anticipate will result or that has resulted.
• Problem urgency (X9): reflects the perception of the urgency of the problem(s) to
which a particular system is addressed.
• Use (YI 1): the use of a system (a behaviour) should be closely related to
acceptance of the system (an attitude).
• Organizational support (Xl4): the degree to which organizational arrangements
foster and facilitate access to and use of a system.
• Performance (Yl2): represents the quality of decision-making (or whatever other
performance dimension is appropriate) in the area(s) supported by the system.
• Satisfaction (Y13): reflects the user's overall evaluation attitude towards the
system.
Because the authors focus on projects with one intermediate level (the manager stands
between the designer and the users), a two-stage implementation process is adopted. It starts
with management initiation and acceptance of a given information system and ends with user
satisfaction with the system.
Toe acceptance of an information system by the manager is influenced by different types of

factors, as there are decision style and demographics (personal factors); job characteristics
(task-related factors); knowledge, assessment of system (system-specific factors) and
organizational support.
Y5 = f(X2, X3, X4, X5, Y3, Y4)
Top management support leads to a higher believe and involvement which, in tum, influence
the knowledge of the manager of the system and thus indirectly management acceptance.
Yl = f(Xl)
Y2 = f(Xl, Yl)
Y3 = f(Yl, Y2)
Y4 = f(Y2)
Acceptance by the manager is necessary but not enough. The system needs to be accepted by
the users as well. The factors that lead to user acceptance are analogue with those related with
manager acceptance: decision style, demographics, job-characteristics, knowledge,
assessment and system characteristics. The relationship between acceptance and use is
recurrent. Acceptance leads to use and use leads to acceptance. The more familiar one gets
with the system the easier it will be to accept it.
Y10 = f(Y8, Y9, Yl 1, X lO, Xll, Xl2, X13)
Toe process of accepting the system starts with the personal stake and ends with user-
satisfaction. The personal stake is influenced by the perception of the management support,
knowledge of the system, change caused by the system and the problem urgency. This, in
tum, influences the user knowledge, the user - researcher involvement and the use of the
system. The user must be able to assess how important the system is to him / her, how much
the system will change his / her job, how urgent the improvement in performance is and to
what extent the manager's support goes.
44
Y6 = f(X6,X7, X8, X9)

Y7 = f(Y6)
Y8 = f(Y6, Y7, XlO)
Y9 = f(Y7)
Acceptance, use, performance and satisfaction fonn a causal chain with recurrent elements.
Higher performance leads to satisfaction, but satisfaction leads to more use ands thus to a
higher perfonnance.
Yl l = f(Y6, YlO, Yl2, Y l3, XI4)

Yl2 = f(Yll)
Y13 = f(Yl 1, Y12)
3. Model testing
A structural model represents an overall theory of the phenomenon under study. Testing the
model is thus testing a theory. The best way to test a model is to test it as a whole, in other
words, testing all relationships at once. Unfortunately, the conditions are seldom favourable
enough to do this type of testing. This is also the case with this model. Not all variables used
can be measured in a satisfying way. For this reason, the authors decided to do partial tests.
The aim of these tests is to examine some parts of the model. This does not provide us with
proof regard ing the theory behind the model, but it gives indications that can be used to adjust
or refine the model.
Two partial tests were conducted: one based on figures collected in a large multinational
manufacturing company that had adopted a decision support system (DSS), the other was
performed in the same firm several years later. During the second test, figures were collected,
not only for the DSS, but also for all types of planning systems. The focus was narrowed to
the user model.
The aim of this section is to make a list of potential factors. Therefore, it seems irrelevant to
discuss in detai l the actual testing method or the proxy variables used to perform these tests in
this part of the di ssertation. What is more relevant is the outcome of the tests. These outcomes
are represented in the following figures.
45
Success factors for ICT Ei9iects
First partial test of manager submode/: Decision Support System
Manager belief in Manager decision Manager job

system concept style characteristics
ii~ - - - - - - -~
·,
\ i
\ i
\ i
\
\
I
!
\
\ i
\ i
\ i
\ ;
\ i
i
Top management Manager knowledge Manager acceptance ! Manager
support of system ·----- -- demographics
·- ·-·· .. ·· Not tested
-·--- ·- Little or no support
Manager - - - - Some support

Manager assessment Organizational
researcher of system and support
involvement simnnrt - Strong support
Figure 5: First partial test: manager model

46
First partial test of the user submode/: Decision Support Model
User perception of
management support
User knowledge of
system purpose/use User decision style Satisfaction
\
'--------------- \ \
\
Organizational \ I User's personal
change caused by stake
system
Problem urgency User knowledge of User acceptance Use Performance

system
•
User - researcher User assessment of
Organizational
support
involvement system and support
·-·--···-····...... Not tested i

System User job User demographics
- -- ---- Little or no support
Some support
- Strong support
Figure 6: First partial test: user model 47

Success factors for ICT £.l:2jects
Second partial test of user submode/: all types ofplanning systems
User perception of ~------- ------------ - ~

User knowledge
of system management support
purpose/use User decision style Satisfaction
~
Organizational User's personal .a
change caused stake l
by system
. 1 ,
• ' . '
Problem urgency User knowledge of
system ---IJ,
User acceptance
f---+
Use
~- ~ MornM~ I
t . .
,. ~j~
~ ~
I
i i
i Organizational
i support
User - researcher User assessment of i
involvement ,... ... system and support i
i
i
i
i I
port System User job User demographics
- Strong support
Figure 7: Second partial test: user model

48
4. Conclusion
There appears to be a strong link between both sub-models through the user perception of
management support. The perception of this support influences, in tum, the personal stake, as
do the perception of management support and problem urgency.
Two paths can be distinguished in the models: a path from personal stake, through user
assessment to user acceptance and use, the other direct from the user's personal stake to use.
The user experience has a direct impact on the user satisfaction.
The results raise questions on some variables included in the theoretical model. There has
been little evidence on the impact of system purpose, decision style, user job characteristics,
user - researcher involvement and user knowledge of the system. This could be attributed to
problems related to measuring; selecting a test-population etc, but it can also indicate some
weaknesses in the hypotheses used to build the model.
The variable "perfonnance" was not tested at all.
This is one of the weaknesses of this study. The model was not tested as a whole, but
conclusions were drawn on partial tests. The authors are aware of this and point it out to the
reader in several occasions.
Although a theoretically sound model was developed, the empirical testing provided little
support. Strong support was only found for the relationships between manager acceptance,
user perception of this support and the personal stake of the users and a relationship between
user stake and actual use.
A lot of work still needs to be done. Nevertheless, this study can serve as a good basis for
further research. What's more, it provides an interesting methodology that should be
considered when performing this type of research.
49
2.2.2.3 ICT literature, dealing with one or a limited number of

aspects of ICT proiects
2.2.2.3.1 Introduction
In this subsection, an overview is presented of a number of researches, dealing with one or a

limited number of aspects of JCT projects. The aim is to get a better insight into the impact of
- and the relationship between some factors and the success oflCT projects.
In order to keep this paragraph well structured, an attempt is made to classify the outcomes of
the studies into different categories. The categorisation is done on an arbitrary basis. Some
aspects ofICT projects have an impact on more than one category.
2.2.2.3.2 Proiect characteristics
1. Selection
The selection of an appropriate JCT project is essential for its success. Many failures can be
attributed to the fact that the project selected does not succeed in capturing all of the users'
specified needs or that it is selected based on an inadequate analysis of the needs (Griffiths &
Hochstrasser, 1991). As Strassmann (1997) puts it:
Computers are like drugs: they can either kill or cure you, depending on i,iformed choices. It
is not the drugs that should get the exclusive credit for bringing anyone back to health. It is
the doctor who has prescribed the right drug with the appropriate dosage that matters more
than any other influence.
In other words: the appropriate solution has to be selected for the appropriate problem. This
seems quite trivial, but nevertheless, as Earl (1989) mentions in his book, using computers to
solve the wrong problem was one of the major causes of failure in the seventies.
There are several arguments why the selection of an lCT project tends to be so difficult. First
of all, the traditional ClAT techniques are not or hardly applicable for JCT projects and there
is no new generally accepted technique for the assessment of ICT projects (Milis & Mercken
2002; Ballantine & Stray, 1998; Whiting et al, 1996; Strassmannn, 1997; Day & Schoemaker,
2003). Second, the fact that the performance of an investment is very much dependent on the
way it is implemented renders the evaluation procedure even more difficult (Apostolopoulos
& Pramataris, 1997). Third, unlike most other type of projects, the goals of an ICT project
tend to shift as the development progresses (see infra).
A way to minimize this type of problem is to embed the projects into a general ICT strategy.
There is a broad consensus among researchers that (fonnal) JCT strategic planning and
business alignment have a positive effect on the success of the ICT projects (Fowler & Walsh,
1999, Willcocks 1995 & 1996, Hochstrasser & Griffiths, 1991 ).
2. Other
As mentioned in the studies discussed earlier, there is some evidence that the chance of failure
is higher with large projects. Caffaso (1994) even states that the company size has an impact
50
on the success of a project. She claims that large companies suffer from projects that are too
large and have too many requirements to fulfil on a timely basis.
Management have proven to be very intolerant of poor system - user interfaces. Ease of use
and favourable interfaces are both positively correlated with user satisfaction (Zmud, 1979).
2.2.2.3.3 Project management
1. Planning
Clear objectives, good planning and project definition is an adagio for good project
management. This is not different for lCT projects. As Ingram (2000) states it:
"How can the music be pure when the musician does not know the notes. "
The development of tem1s of reference (project definition, goals, measures of performance) is

vital to its success (Wright 1997, Robey, 1979; Willcocks, 1995; Strassmannn, 1997). This
does not only require a good knowledge of the user requirements (ev. gained trough user
participation: see infra), but also a good knowledge from the management of their exact
information needs and a realistic view on the possibilities and -maybe even more important -
the limitations of IT. This is not always the case. People tend to ask too little or too much
information because they do not sufficiently understand their own information requirements
(Zmud, 1979). Hochstrasser & Griffith (1991) for example, note that the majority of managers
are unable to give precise definitions of their exact information needs. Willcocks (1995)
found that 38% of the managers indicate that poor understanding of the potential of TT by
senior management is a main constraint to optimise their TT involvement. 35% considered
themselves constrained by poor understanding of business plans by IT professionals.
In most JCT projects, the appreciation of the principal stakeholder of the opportunities of the
technology and the business problem improves during the development (Remeny &
Sherwood-Smith, 1998). This can lead to refining or even changing goals "along the way".
These changes should be handled by the project manager with the outmost care. He/she can
integrate these changes into the current planning or start-up a new project, which integrates
the old project and the new set of goals.
2. Allocating time, funding & personnel
.lo any project, it is essential that sufficient resources be allocated to the project.
Allocating resources is mainly a prioritisation problem (Willcocks, 1996). Scarce resources

have to be pulled away from normal business activity or from other projects before they can
be allocated to the ICT project. 1n this, the (top) management plays a significant role. Lack of
interest and involvement can quickly let other activities take more priority (Fowler & Walsh,
1999). The momentum suffers. Moreover, when support from the top is made obvious, then
the doubters and reluctant providers of resources will become less doubtful and less reluctant
(Wright, 1997), which makes it easier for the project manager to rely on and make use of
resources.
The top management interest should not be limited to the purely technical or project
managerial side of the project. The vision of the top management needs to be broader. Too
51
often, there is a lack of willingness on part of the top management to allocate sufficient
resources to overcome internal problems associated with the introduction and management of
IT (Hochstrasser & Griffith, 1991 ). Guiding change cannot be done without proper resources
and support from the top management. The same applies to risk management and contingency
planning. Not only does the making of a good contingency plan consume resources, but the
management needs to be aware that the eventual execution of a contingency plan requires
resources as well. (Mostly, a lot of resources need to be freed on a very short basis to execute
"plan B" and this at the moment where the credibility of the (project) management might be
in question due to the failure of"plan A").
The strategic importance of IT has increased. Consequently, the decision of where and when
to allocate resources to IT projects has become more risky and more difficult (Clemons &
Weber, 1990). This makes the top management support the more essential for a project. Lack
of top management support is indicated as an important factor for failure (Earl, 1989).
2.2.2.3.4 Managing the project
The role of IT has evolved from a basic supporting technology to a major enabling function,
often with substantial strategic consequences. Consequently, responsibility for IT investments
should evolve similarly. It needs to be separated from responsibilities for other investments
and transferred to specially appointed executives. Responsibility for 1T cannot continue as the
grey area of management. It cannot be left as a part-time activity, linked exclusively to
financial planning and short-term crisis decision making (Hochstrasser & Griffiths, 1991;
Willcocks, 1995; Willcocks, 1996; Strassmannn, 1995).
Within successful companies, senior executives emphasis the importance of information as a

vital corporate resource with a status equal to finance, raw material, manpower and other
assets (Hochstrasser & Griffiths, 1991).
As IT becomes more than just a basic support technology, the emphasis shifts from the
technological to management issues (Hochstrasser & Griffiths 1991, Earl, 1989). Managing
the investment dynamically and beyond the actual implementation process and regular
attention to both technical & human issues are major elements for the successful introduction
ofICT investments (Hochstrasser & Griffiths, 1991; Ingram, 2000). In an environment with
accelerating rate of change, a company must learn to adapt to technological change and
increase its understanding of the forces that direct this change in order to manage it.
2.2.2.3.5 Behaviour and organisational issues
Bad processes don't kill projects, people do (Maglitta, 1994).
A lot of research focuses on the human aspect of JCT - projects. It range s from forms of
communication to formal structures (project organisation) wherein people function.
1. Communication
Every individual and every party involved brings its own set of needs when the
implementation of an ICT project is involved. This can lead to friction between the parties on
behaviour or organisational issues, which is a major cause of implementation failure (Fowler
& Walsh, 1999). A process of continuous and dynamic evaluation and debate between
52
knowledgeable stakeholders provides the best chance for information system optimisation
(Remeny & Sherwood-Smith, 1998). It can reduce friction and help to align the different
viewpoints of the parties involved. Furthermore, intensive communication can improve the
knowledge of the manager on IT-issues and the knowledge of IT-people on the specific
management issues as the development and the implementation progresses.
Unfortunately, good communication practice is not generally applied. Three out of four
managers still point to the problems of communication gaps between IT-people and users as
main constraint to optimise IT (Willcocks, 1995). These problems are not easily avoided.
Despite good management intentions at the outset of the project, time and resource pressures,
coupled with political tensions and unintended mixed signal from team members can hinder
communications, distort perceptions and allow expectations to go unrecognised and/or
unsatisfied (Fowler & Walsh, 1999; Wright, 1997).
It needs to be stressed that it is not the quantity but the quality of comm unication and
information exchange that is important. The inclusion of irrelevant information in a report
degrades performance. Moreover, the amount of information being received appears to be
negatively related to user satisfaction (Zmud, 1979). Providing everyone with all possible
information is not a good practise, although it is tempting to place an additional list of
addresses into the CC of your email.
2. User attitudes
lCT projects can and do fail where user's psychological reactions and organisational factors
are ignored by system designers. Therefore, designers are urged to create favourable user
attitudes, for example by involving users in system development work. As with good
communication, effective participation might reduce the gap between the user's expectations
and the ability of the company to satisfy them. Potential resistance may be resolved, and a
more favourable attitude towards the project can be created (Robey, 1979, Fowler & Walsh,
1999, Hochstrasser & Griffiths 1991, Earl, 1989). However, the process is likely to take
longer if participation is encouraged (Fowler & Walsh, 1999).
Other factors that correlate positi vely with user attitudes are:
• Goals: if the user knows what is expected from him or her, he or she can focus
better. This leads to a higher job performance and thus raise expectations for
extrinsic or intrinsic rewards.
• Perceived potential of the system;
• Support / resistance: perceived implementation support; adequate top management
-, technical- and organisational support?
• Client I researcher relationship: the people who are implementing the system
understand management problems and work well with their clients.
• Perceived quality of the ICT staff;
• Urgency: the perceived urgency can reflect the user' s concern over performance
problems, which the ICT project could recti fy.
(Robey, 1979, Zmud, 1979)
User attitudes, in tum, are positively correlated with system use and system use is related with
user satisfaction (Robey, 1979, Zmud, 1979).
53
3. Power politics
A lack of consonance between the distribution of power implied by an information system

and the distribution of power existing in the organization is a source of resistance to change
(Markus, 1981). The more friction the implementation causes, the more important change
management becomes.
When IT investments are made without clear definitions of authority and responsibility, the
authority and responsibility will be taken by whi.chever power base within the organisation is
the strongest. Usually this means it is assumed by one of two groups: either a user group or by
technologists themselves (Willcocks 1995).
• If the users take charge, it can only be found that the resulting systems are
inconsistent, incomplete, expensive and only used to a fraction of their full
potential (Hochstrasser & Griffiths, 1991 );
• If the technologists take charge of CT the resulting systems can be user-unfriendly,
over-engineered, unduly complex and isolated from securing the business aims
(Strassmann, 1990).
Consequently, it is necessary to define the authorities and responsibilities of the different

parties involved at the outset of the project. The project manager should have sufficient power
to withstand the pressure of the different parties involved.
54
Chapter JI: Literature review
2.2.2.4 Overview of possible success factors based on ICT literature

Powler & Dickson The Standish Group Wateridge Lucas et al Q!!!.ll
• Participation operational • User involvement • Leadership • Organizational support • Selection appropriate

management • Executive management • Motivation • Management acceptance project
• Organisational level support • Planning • Perceived problem urgency • Strategic !CT planning
computer executives
• Clear statement of • Dev. method • Expected organizational • Business alignment
• Turnover project personnel requirements • Monitoring change • Project size
• Source of origination • Proper planning • Mgmt. method • Management support • Training users
• Experience • Realistic expectations • Delegation • User personal stake • Attention for user interfaces
• Use of high level • Smaller project milestones • Conununication • User demographics • Clear objectives
programming language
• Competent staff • Clear objectives • Planning & project
• Education level project • definition
personnel
• Ownership User involvement
• Knowledge of possibilities
Separation analysts &
• Clear vision & objectives • Top mgmt. support
& limitations oflT
0
programmers • Hardworking, focused staff

• Knowledge business goals
• Overall size organisation bylT people
system staff • Top management support
• Flexibility (changing goals)
• Good communication
• User involvement
• Perceived support
(technical / organisational)
• Relationship
users/implementers
• Perceived urgency
• Quality oflCT staff
• Defined authorities &
responsibilities
• Ownership
55
2.2.3 Possible success factors for ICT proiects, based

on non-JCT literature
Only a few studies in the general project management literature concentrate on the
key factors that affect project success or failure (Belassi & Tukel, I 996). The belief is
that, if project managers and their teams carry out these factors well, the project will
be a success (Wateridge, 1996).
Projects are, per definition, unique (see supra: definition of a project); Consequently,
the set of key factors for each project is unique as well (Belassi & Tukel, 1996;
Wateridge, 1996). Nevertheless, in literature there is evidence to support the existence
of key success factors general applicable for projects (Clarke, 1999). A list of factors
that influence success can thus be constructed in a substantial way.
Due to the unique nature of projects, the interpretation of this list has to be done with
care. Some of the factors in the list might not be applicable for a particular project or a
factor that is a determinant for success within a given project might not be listed
(Belassi & Tukel, 1996). The relative importance of the Listed factors might change
from one project to another. None of the key factors listed are responsible, on their
own, for ensuring a project success. They are all inter-dependent (Clarke, 1999). It is
a combination of many factors at different stages of project life cycle that results in
project success or failure (Belassi & Tukel, 1996).
The content of the list depends highly on the success criteria used. In the early
research, for example, the triple constraints were used as criteria to measure success
(see supra). This represented primarily the project manager's view and thus criteria
relating to user or owner happiness were seldom regarded as key factors. As the
criteria used became more complex and the emphasis broadened to users and owners,
other factors, as user participation, were added.
The construction of a list of key factors for ICT projects is a major goal in this
research and starts with an exploration of literature. The aim of the exploration is to
discover possible factors or groups of factors, which will be used to give orientation to
the qualitative part of the research. Because little research has been done on the key
factors of ICT projects (Belassi & Tukel, 1996; Wateridge, 1996), the exploration had
to be broadened to other, related types of literature. The literature overview presented
in this section is based on, respectively, general project management, change
management, project evaluation & selection management, and specific JCT literature.
57
2.2.3.2 Possible success factors, based on general proiect

management literature
Since ICT projects are a subset of the set of projects, one can assume that most of the
factors of projects in general apply to the subset of ICT projects as well. By
examining other types of projects, knowledge can be gained on the factors dealing
with the project management side of an ICT project. Nevertheless, as stated in a
previous chapter, the ICT projects have some specific characteristics that distinct
them from other types of projects and which may influence the list of success factors.
Thus, transposing the factors from projects in general to JCT projects has to be done
with great care.
The key factors for general projects will be discussed based on two research studies
and a book. These three are selected because they give an overview of the different
types of research in this area. Literature provides us with several other research
studies, but the conclusions are very similar to the conclusions of the research studies
discussed in this subsection.
2.2.3.2.1 Research study nr. 1: Angela Clarke
The first research study was performed by A. Clarke, member of the Warwick
Manufacturing Group, University of Warwick, UK. The aim of the study was to point
out how the use of key success factors can improve the effectiveness of project
management. The research was based on a survey, conducted at a number of
"Teaching Companies", involved in change. This research has been chosen because it
highlights the change aspects of projects. As will be advocated later in this chapter,
change is an unavoidable characteristic ofICT projects.
This paragraph is limited to the findings of the study. Those who want to examine the
study in more detail can find additional information in the following articles:
• "A practical use of key success factors to improve the effectiveness of project
management", International Journal of Project Management, vol. 17, no.3,
1999
• "Key Success Factors in the Project management", Proceedings of a teaching
Company Seminar, London, December 1995.
Clarke identified four key success factors for projects, involving organisational
change:
1. Communication throughout the project
Communication influences the acceptance of anything new. Lack of communication

has been cited as the biggest reason for the failure of many change projects to meet
their expectations.
There are several reasons why communication is important. ft can help to increase
understanding, to reduce non-productive effort, avoid duplication, eliminate mistakes,
manage uncertainty and motive the participants. It will encourage teamwork, may lead
to problems being identified sooner or generate ideas that lead to better solutions.
58
Successful communication needs to be focused rather than broad-brush and timing is

of crucial importance.
The result of successful communication will be a project, which is more likely to meet
its objectives within the allocated time and resources.
2. Clear objectives and scope
By defining and agreeing on objectives, the project will become goal and result
oriented, rather than activity based. Having key objectives helps the team to focus on
a target. 1t creates commitment and agreement about the project goals. When
objectives are agreed upon at the outset of the project, a set of measures is created to
monitor and evaluate the progression and success of a project.
Defining the scope at the outset of a project prevents the project boundaries extending
beyond the intended limits. Without a well-defined scope, the project objectives can
become fuzzy and people may start to Jose sight of what they are trying to achieve.
3. Breaking the project into 'bite sized chunks'
Breaking down large projects into sub-projects or work packages is regarded as one of
the most important tasks in new projects. Sub-projects can be delegated better.
Responsibility and accountability can be spread across more people, which make it
easier to manage.
However, care must be taken not to have too many work packages because that could
work contra-productive.
4. Using project plans as working documents
Project requirements may change drastically throughout the life of a project,

especially so when 'people' issues are involved. Consequently, people need to be
involved in the change and aware of what is happening in the project, to be able to
accept it readily. The project plan can be used as a communication tool and an
effective monitoring device.
Project plans need to be kept simple, at the right level of detail, so that adjustments
can be made easily if necessary. They need to be updated regularly to ensure that a
project is completed successfully.
2.2.3.2.2 Project handbook: Turner
The second source of infonnation is "The handbook of project based management",

written by J. R. Turner (1993). This is a book referred to in many articles. lt is
considered one of the prime works o n project management. Turner is connected with
ICI, Coopers & Lybrand and Henley Management College and based his book on a
mixture of literature, own experience and teaching notes. In this paragraph, only the
issues relating to success factors are discussed.
59
1. Attitudes
Chances for success are influenced substantialJy by the attitude of the different parties
towards the project. These attitudes have to be supportive and positive. There has to
be a major commitment to making the project a success and everyone working on the
project needs to be highly motivated.
To create a positive attitude, several actions are proposed by Turner:

• Develop a clear mission
• Make sure the project receives support from the top
• Be open for criticism and ensure to receive frank reviews as it develops
2. Pro ject definition
A comprehensive definition should be developed at the outset, stating the purpose,

ownership, technology, cost, schedule, duration, financing, sales and marketing, and
resource requirements.
Through the project definition, the vision for the project is created, the purpose of the
project is defined and the project plans are aligned with the business plans and the
basis of co-operation agreed.
The development of the project's definition is vital to its success.
3. Internal organisation
This section combines three important issue, all related to the internal organisation of
a project.
Organisation
Time and effort must be put into the development of an appropriate management
structure. Many projects begin and end with a functional line structure, but change to
a matrix during implementation. Attention has to be paid to an appropriate
management structure.
The owner involvement is another organisational issue. A sufficient degree of owner

involvement is necessary because the owner has to obtain sufficient knowledge to be
able to make well-founded decisions if needed. On the other hand, too much owner
involvement can be counterproductive. A good balance needs to be found.
People issues
Projects normally put enormous demands on the personal qualities of the people
involved. They are asked to perform extraordinary efforts.
The people involved need to be coached. Good communication and conflict control
should lead to expectations that are more realistic, better relationships and teamwork
amongst the participators. The composition of the team should be looked at from a
60
social as well as a technical viewpoint: people play social roles on teams and these
will be required to vary as the project evolves.
Planning and control systems
Planning needs to be done in different stages. At the outset of the project, plans should
be on a broad, systems level. Details are only provided if they are crucial for the
project. The plans are refined and details are filled in as the project evolves. Mostly,
this happens in discrete steps on a rolling wave basis. Costs are treated in a similar
way.
All changes made on the initial plans, proposed as well as actual, should be monitored
with care.
4. Project's context
As in the previous section, this section is divided in three subsections as well.
External influences
Several external influences may be identified. Turner lists the influences that he
estimates as being of particular interest:
• Project's political context

• Its relationship with the local community
• The general environment
• The project's location
• The geophysical conditions in which it is set
Although the project manager usually has little direct impact on those external factors,
he/she must be ready to manage these factors. He/she should court the politicians and
influential managers if necessary .
.It is important that these factors are well considered at the outset of the project so that
they can be managed or avoided.
Fillancing the project
Financial requirements have their impact on projects, especially if a large part of the
project is financed with external funds.
Essential parameter here is the likelihood of slippage. A slippage of a few months

means not just increased financing charges but the Jost revenue of a sum.mer season
for example. Financial requirements need to be managed carefully.
Scheduling the project
Determining the overall timing of the endeavour is crucial to calculating the risks and
dynamics of implementation and management.
61
A degree of urgency should be built in. There needs to be some pressure. However,
too much pressure can make it unstable. The right amount of time and resources
should be allocated to every phase in the process.
Milestone scheduling of the project at the earliest stage is extremely important. It is

crucial that none of the development stages of the project be rushed or glossed over.
2.2.3.2.3 Research study 3: W. Belassi & 0.1. Tukel
W. Belassi and O.I. Tukel (respectively connected to the College of Business

Administration, Cairo University and Operation Management and Business Statistics
Dept, Cleveland University) pose that it is nearly impossible to list all success factors
for all types of projects. In their research, they try to identify a limited number of
groups to which the different factors can be allocated. These groups are easier to study
and can provide a better insight and a better understanding of the aspects that
influence the success of a project.
Their research is based on a survey, conducted in the United States. Part of this survey
was a questionnaire in which project managers were asked to identify critical factors
for the successful completion of their project and to rank a number of factors
proposed by the researchers. Details on the questionnaire and the statistical analysis
can be found in the working paper "Analysis of the characteristics of projects in
diverse industries", Tukel, O.l. & ROM, W.O., Cleveland State University, Ohio
1995. The outcome of the research described in this section is based on the article "A
new framework for determining critical success/failure factors in projects", Belassi,
W. & Tukel, 0.1., International Journal of Project Management, vol.14, no. 3, 1996.
This research is selected because the authors made a distinction between different
types of projects. They included a category MTS projects, a category of special interest
for this research. Consequently, this research does not only provide knowledge on
projects in general, but gives a limited amount of information on MIS projects as well.
Belassi and Tukel identified four groups of factors:

I. Factors related to the project
2. Factors related to the project manager and the team members
3. Factors related to the organisation
4. Factors related to the external environment
Figure 8 gives an overview of the factor groups and their relations.
Compared with the previous studies, the term success factor is interpreted differently
by Belassi and Tukel. Certain circumstances, which the project manager or the project
team cannot alter or manage, are regarded as critical success factors as well. The list
of Belassi and Tukel can therefore be interpreted more as a list of possible hazards,
risks and possibilities. The success factors can be derived directly from this list.
An example: the technological-, political- and social environment is listed, pointing

out that these influence the outcome of the project. The management of the
relationships with the stakeholders is a possible success factor that relates to these
items.
62
Chapter 11: Literature review
actor groups System response Factor group
·actors related to the project manager

Ability to delegate authority
• Ability to trade-off Client consultation & acceptance
• Ability to co-ordinate
• Perception of his role &
responsibilities
roject manager's performance on the job actors related to the external
• Competence Effective planning and scheduling nvironmeut
• Commitment Effective co-ordination & communication Political environment
Factors related to project team Economical environment
Effective use of managerial skills
embers
Effective control & monitoring Social environment
• Technical background
Effective use of technology Technological environment
Communication skills
Nature
Trouble shooting
Client
• Commitment Competitors
Project preliminary estimates
Sub-contractors
actors related to the project

• Size & value
• Uniqueness of project activities vailability of resources (human, financial, raw
• Density of a project ,aterials & facilities)
• Life cycle
• Urgency
'actors related to the organisation

• Top management support
Project organisational structure
Functional managers' support
I• Project champion
Figure 8: Factor groups
63
1n the following subsection, the factor groups of figure 8 are discussed, as well as the
intermediate effects and their impact on the MIS.
l. Factors related to project
Project characteristics have long been overlooked in the literature as being critical
success factors whereas they constitute one of the essential dimensions of project
performance.
Belassi & Tukel list six factors in this group.

• Size and value: large size projects tend to exceed duration deadlines. Thus, if the
lifespan is being used as a success criterion, one should be aware of the impact of
the project's size and the penalties attributed to exceeding the deadline.
• Uniqueness of the project activities: the familiarity of the organisation with similar
types of projects is critical.
• Density of a project: this is defined as the ratio of total number of precedence
relationships to the total number of activities. The density affects the allocation of
resources, especially man-hours.
• Life cycle: no additional information provided by the authors
• Urgency: This is defined as the need to implement the project as soon as possible.
Often, the criteria posed are not met because there is too much pressure, resulting
in inadequate planning and scheduling of the project.
2. Factors related to project manager and team members
Many factors related to the skills of the project manager and the project team
members are crucial for the success of the project (see figure 8). It emphasises the
importance of the competence and commitment of project managers and the project
team members.
Factors related to the project manager

• Ability to delegate authority
• Ability to trade-off
• Ability to co-ordinate
• Perception of his role & responsibilities
• Competence
• Commitment
Factors related to project team members
• Technical background
• Communication skills
• Trouble shooting
• Commitment
Note that these factors not only influence project performance but also have an impact
on client satisfaction and project acceptance.
64
3. Factors related to organisation
One of the most important factors is top management support. Top management
usually controls a project manager's access to resources. The level of support of the
top management usually determines the level of support from the functional manager
as well.
The project's organisational structure has a large impact on these relationships and
thus influences the power equilibrium in the organisation and the amount of
negotiation that needs to be done.
Clearly, full support from the organisation for the project facilitates the
implementation towards the successful completion of the project.
Factors related to organisation

• Top management support
• Project organisational structure
• Functional managers' support
• Project champion
Belassi & Tukel define the term "project champion" as a member of the (top)
management who helps the project manager to understand and achieve the project
objectives better. He/she is an inspiring and driving force behind the project.
4. Factors related to the external environment
This group consists of factors that are external to the project but still have an impact
on it. Most of these factors have their impact on the planning stage of the life cycle,
but some may have an impact throughout the entire life-cycle and may even cause the
termination of a project during the implementation phase.
Note that "client" is listed as an external factor. This is the case when the client is not
a part of the organisation.
Sub-contractors are listed here as well since they have an impact on the resource
available and thus may influence the project manager's performance on the job.
Factors related to the external environment

• Political environment
• Economical environment
• Social environment
• Technological environment
• Nature
• Client
• Competitors
• Sub-contractors
65
5. The intermediate effects of factor groups
The factors in each group can be considered to be input-related factors affecting the
project implementation. Several factors in the groups can come into play
simultaneously and cause new obstacles (see figure 8).
An example: a project manager's performance on the job is affected by the factors

related to the organisation, by the project manager's ability to implement a project, by
external factors and by factors related to size, value and urgency of the project.
The framework presented in figure 8 l1elps the project manager to analyse the cause-
effect relationships and helps him/her to identify and manage the factors that have an
impact on their performance.
As stated at the beginning of this subsection, Belassi and Tukel made a distinction
between different types of projects. Their conclusions on MIS projects are discussed
in this paragraph.
The most critical success factors for MIS projects are grouped under the label
"organisation".
When the project managers were asked to rank a number of factors suggested by the
researchers, the following ranking emerged:
1 & 2. Top management support & Client consultation (same frequency)
3. Availability ofresources
4. Preliminary estimates
5. Project manager performance
Frequency tests were performed to examine the relationship between project attributes
and success factors. Only "Client consultation" and "project manager performance"
show a significant P-value.
Based on the framework presented in figure 8, the following ranking emerged:

L & 2. Commitment & Top management support (same frequency)
3 - 7. Size & value, Co-ordinate, Communication & Technology
(same :frequency)
Not all the factors were listed nor did every factor listed have a rank number.
66
2.2.3.3 Possible success factors, derived from programme

management literature (including ERP implementations)
As the popularity of project management grows and the number of projects within a
company rises, supra-project structures are created. These structures are referred to as
programmes. A programme combines a set of projects that are related in one fonn or
another (Vereecke et al, 2002). It is a structure designed to coordinate different
projects. 1t should enable the company to profit more from the proj ects by exploiting
synergies between them.
Programme management is a relatively young discipl ine. It has known an exponential

growth due to the growing complexity and the magnitude of software
implementations, as for example ERP packages. The introduction of the different ERP
modules are regarded as projects, while the coordination of the implementation of
these projects can be regarded as a programme.
Similar to the search for success factors at the project level, a quest for success factors
on the programme level has started. Like the research on the project level, the
research on programme level can be categorised in two groups. There are studies that
approach programme management as a whole, while other studies examine a specific
factor.
Examining the success factors on the programme level can provide infonnation on the
success factors on project level as well. Therefore, a number of studies on programme
management are discussed.
2.2.3.3.1 Research on programme management: holistic approach
Research study: Ribbers & Schoo
This research was conducted in different stages. At first, Schoo conducted a research
on programmes for complex software implementations. This was done by examining
two programmes in depth and by verifying the results by surveying 15 programmes
(Schoo, 1999). In a following stage, some elements were further developed and
highlighted in some articles (for example Ribbers & Schoo, 2002).
Based on the qualitative analysis, no less than 64 success factors for programmes
were described. The combination of these success factors and the findings of the
survey enabled the researchers to construct a list of 20 suggestions for the
implementation of complex software programmes. These suggestions are described
here because they contain elements that can be of value for the management of
projects as well.
• Find the right programme manager: the programme manager should have
experience with similar complex programmes.
• Concurrent programmes: it is very likely that similar programmes are
running at the same time.
• Completeness of the programme organisation: a programme organisation
should include a programme manager; programme sponsor; steering
67
committee; user representatives, coordinator to external suppliers;

coordinator across projects; coordinator for an efficient implementation
process.
• The programme should use a methodology.
• The use of tools should include tools for programme control and for
modelling.
• Conference room pilots should be used irrespective of complexity.
• The maximum of rollout projects that can be run in parallel is 12.
• An appropriate implementation strategy should be applied.
• Communication with users should be complete and honest.
• The programme managers should be aware of the users' resilience.
• The programme should receive sponsorship from all stakeholders.
• High user involvement throughout the programme.
• User training should be localized, including material, trainers and examples.
• The adherence to (original) user requirements gets more difficult as the
variety increases. Tools for requirement tracing are currently being
developed.
• Organize alignment: review at end of design phase; steering committee;
review customers demands; regular new software releases from the central
programme team; review after each implementation project.
• Avoid incomplete learning.
• Apply single loop learning: re-use plans and documents; bring in others from
within the company; use external consultants.
• Learning through simulation; prototyping or piloting; adoption of best
practice.
• Double loop learning: find underlying reasons of problems; use a pilot to
review your approach
A large number of factors might be valid both on the project and the programme
level. However, some factors can be excluded. This is for example the case for
factors that are related to learning. Single and double loop learning are not applicable
within the individual project. There are significant differences between project- and
programme organisation as well. The programme organisation is extended with
several functions that have no meaning for individual projects, like the project
coordinator,. Furthermore, tools can be used for project- and programme
management, though these tools are not necessarily the same.
2.2.3.3.2 Research on programme management: dealing with one or a

limited number of aspects
There is a line of research that tries to discover the (optimal) way in which projects
can be grouped into programmes (for example: Vereecke et al, 2002). However, this
line of research was not further examined because no direct success factors for the
implementation of projects could be derived.
Another type of research focuses on alignment. Especially with the implementation of

ERP systems, questions are asked whether ERP solutions are suitable for all types of
organisations or all types of information. Are the underlying reference models that are
68
embedded in ERP systems suited for a company? (Davenport, 1998; Kumar & van
Hillegersberg, 2000).
In the same line, a balance between adjusting the software or adjusting tbe company
procedures in order to optimise ERP is looked for. Should ERP be implemented from
a provider' s or a customer's perspective? (Kremer & van Dissel, 2000). Moreover,
should business processes be re-engineered before ERP is applied (Scheer &
Habermann, 2000)?
Some of these questions can be relevant for ICT projects as well:

• Alignment: is the solution we want to implement suited for our organisation?
• Selection: is the solution we selected the right one?
• Justification: is it worthwhile to redesign our processes?
2.2.3.4 Possible success factors, based on investment

iustification and selection literature
In this subsection, an attempt is made to identify possible success factors based on
selection and justification methods and techniques for JCT projects. These methods
and techniques are developed to select the "best" project. Consequently, there most be
an implicit definition of a "good" project behind these techniques. By examining these
methods and techniques some success criteria should emerge.
2.2.3.4.1 The selection and iustification procedure: a possible success

factor
The selection and justification of an ICT project is of primordial importance.

Selecting a mediocre or bad project or badly justifying the project puts a serious
mortgage on the success of the project.
The reason for the failures of IT projects can be complex: technical, human
resource, environmental, organisational and management issues interrelate
where explanations are sought. However, major barriers, identified by a range
of studies, occur in how the lT investment is evaluated and controlled
(Willcocks & Lester, 1994).
The way in which the JCT projects are selected and justified is thus, as such, a critical
factor for t he success of the project.
2.2.3.4.2 Other possible success factors, based on selection and

iustification techniques
The aim of selection and justification methods and techniques is to make sure the
most appropriate ICT projects are selected and implemented. The words " most
appropriate" indicate that implicitly these methods and techniques use a definition of
a successful project and use criteria by which the appropriateness is measured
(success criteria).
69
The project that has the best chances of becoming successful should be implemented.
In other words, by looking at certain properties of the project the successfulness of the
project is being predicted. Certain of these properties can be manipulated during the
design and implementation phases and thus, can be regarded as success factors, e.g.
manipulating them could have a direct impact on the perceived success.
1. Traditional Capital Investment Appraisal Techniques (CIATI
Traditional CIA Ts are financially oriented. The projects that are selected, are expected
to deliver a high return.
Most of these CIATs make use of the discount techniques in one form or another.
This means that the return is calculated, based on ti.me, costs and revenues. Two of the
three criteria of the traditional triple constraints are thus taken in consideration.
Traditional CIATs tend to favour short-term projects since they present less risk.
Revenues gained in the near future are better predictable and more certain than those
gained over a longer period. CIATs favour conservative investments.
The project's life-span is thus a factor that influences the risks and the return of the
project, which in tum influences the owner's happiness and thus the perceived success
of the project. Cost control is another possible factor that can be derived from the
traditional CIA Ts.
2. Adjusted CJATs
There is a broad consensus in literature that CIA Ts are not appropriate for the
selection and justification of ICT projects (Bacon, 1994; Strassmann, 1997;
Apostolopoulos & Pramataris, 1997; Willcocks, 1994). There is less consensus about
the techniques that should be used. Several attempts to develop more appropriate
techniques are made, either by adjusting the traditional techniques or by developing
totally new techniques and methods (Milis & Mercken, 2002). Factors derived from
the adjusted CIATs are discussed in this section, the latter in the next section.
One of the major adjustments is the incorporation of different types of risks into the
model (Clemons & Weber, 1990; Dos Santos, 1991). This can be done by adjusting the
discount rate according to the level of risk. Obviously, this rate influences the return
and thus the perceived success by the owner/sponsor.
Risks, and thus the discount rate, are potential success factors. The higher the risks
taken, the higher the return needs to be before the owner/sponsor is happy. Risk
reduction during the design phase can alter the perceived success of the project.
3. New methods/ techniques
The strategic fit technique evaluates lCT projects in function of the effect on a firm's
competitive and/or industry structure (Shank & Govindarajan, 1992; Porter, 1995). In
order to provoke the expected benefits, investment should be aligned to the corporate
goals. Focussing on the corporate goals during the design- and implementation phase
could thus be regarded as a success factor.
70
Information Economics, as introduced by Parker & Benson (1988), provides a new

framework for the selection and justification of IT projects. A set of new tools and
concepts that can assess the impact on performance of the IT investment is provided.
This framework, along with the applications based on it (CB - 90, icis, ...), forms
another source of possible success factors.
For example: the following risks are listed in the CB - 90 method, developed by
Oracle:
• Slow response time

• Staff resistance
• Avoid splinter systems
• Poor systems integration
• Risk of losing best staff
• Incomplete implementation
The analysis of this list supports the use of change management techniques (see infra),
which is reflected in the concem regarding the human a~ects of the ICT project
(minimise resistance, avoid losing staff, good response time). Another aspect is more
technical in nature. The design and implementation should be so that a good
integration with the current IT situation is accomplished. Several of these risks listed
can be translated into possible success factors.
Of course, since these possible success factors are derived indirectly, the
interpretation needs to be done with care. Nevertheless, since the aim of this chapter is
primarily the identification of possible success factors, this paragraph can be a useful
contribution to the qualitative part of the research.
4
Good response times relate to user happiness.
71
2.2.3.5 Possible success factors, based on change

management
"It most be considered that there is nothing more difficult to carry out, nor more
doubtfal to success, nor more dangerous to handle, than to initiate a new order of
things" (Machiavelli, 1513).
Change is inevitable when dealing with ICT projects and thus change management is
a fundamental activity in any ICT project (Wateridge, 1996; Turner, 1993). It helps to
cope with changes within the project management process as well as with changes
provoked by the outcome of the project.
2.2.3.5.1 Changes within the process
As stated in a previous chapter, requirements and specifications of JCT projects tend

to change over time (Wateridge 1995). This can outdate the original objectives and
criteria and can lead to confusion, panic and resistance among the parties involved.
This type of changes needs to be dealt with primarily by the project manager. He / she
is responsible for the communication, which is crucial for the acceptance of anything
new (Clarke, 1999). It helps to manage uncertainty, encourages teamwork and
increases motivation (Clarke, 1999).
2.2.3.5.2 Changes provoked by the outcome of the project
Changes provoked by the outcome of the project are more difficult to manage.
Two types can be distinguished:

1. Technological change: change to the technology or physical environment
2. Cultural changes: changes in the culture of the organisation itself
Cultural changes are more difficult and more time-consuming than technical changes
(Turner, 1993) because culture influences every facet of the organisation, including
management styles, attitudes, goals, standards, adaptability to change and power
equilibrium. Changing culture in itself can create resistance by creating inertia to its
introduction (Turner, 1993).
Markus ( I 981) stated that resistance to change is caused by a lack of consonance

between the distribution of power implied by an information system and the
distribution of power existing in the organisation.
The impact of change on the power structure can happen in three distinct ways.
Firstly, since ICT projects, per definition, provide management information, it
interferes in the decision-making process. lnformation is power. Secondly, the project
might deliver information that influences the behaviour of individuals and the
performance of the organisation. For example, a new information system might
monitor the performance of individuals or divisions. Thirdly, controlling the new
information system has a symbolic impact. Lt is presented by the image of the ability
72
to influence outcomes, regardless of the actual intention or ability to do so (Markus,

1981 ).
2.2.3.5.3 Dealing with change
A project manager has to accept that panic and resistance accompany change. He/she
has to learn to deal with it rather than to ignore it (Farrell & Broude, 1987). This is
precisely what change management tries to do.
Resistance can be overcome or at least diminished when the following management

rules are used:
• Effective communication: communication helps to manage uncertainty,
encourages teamwork and increases motivation. It helps to avoid and/or solve
problems and ensures the participation of the key players.
• Participation: through participation, potential resistance may be resolved.
• Training and development
• Team development
• Leadership: it has long been identified that people management is an important
skill of a project manager and, therefore, an important factor in delivering
successful projects. A proj ect manager may need to employ different
leadership styles at different times during the project life cycle.
• Commitment from the top: if the project affects a large part of the
organisation, the involvement of senior management is extremely crucial.
• Visibility of the results
(Based on Turner, 1993, Farrell & Broude, 1987, Fowler & Walsh, 1999; Clarke,
1999; Baker et al, 1993; Markus, 1981; Faes et al, 2000)
Since JCT projects induce change, and thus confusion and resistance, the management
of change can be regarded as a factor for the success of an ICT project.
73
2.2.3.6 Possible success factors, based on other types of

management literature
In this paragraph, success factors are extracted from different management theories.
The theories quoted in this paragraph are not directly related to project management
and will thus be discussed only briefly. Nevertheless, these theories may offer some
indications towards success factors of ICT projects. Furthermore, they confirm part of
the factors found in previous paragraphs and enhance the knowledge on success
factors by placing them in a broader spectrum, not limited to project- or change
management alone.
The kernel of every theory will be discussed briefly, followed by the most important
properties and presumptions, which will be brought into relation with project
management. Possible factors are indicated and will be presented in an overview in
the following subsection.
2.2.3.6.1 Agency theory
The principal agency theory studies the relationship between the principal (example:
top management) and agents (example: middle management). The principal and the
agent(s) are engaged in co-operative behaviour: the agent(s) performs certain tasks for
the principal and is rewarded for this.
The principal agency theory is based on a number of basic assumptions. The first
assumption is that the agent and the principal have different and sometimes opposite
goals. Every party is driven by self-interest and tries to maximise its own profit. The
second assumption is that both parties have a different attitude towards risks. Agents
are more risk averse since they preserve risk as extra work, which is not or not
adequately rewarded. ft is posed upon them. The principal is more risk neutral. He /
she takes the risks but hopes to get fully rewarded. The third assumption states that
there is information asymmetry between the parties. The infonnation exchanged is
incomplete. Some information is held back out of opportunist considerations.
The solution to many of the problems related to this type ofrelations, according to the
agency theory, is the alignment between the goals of the principal and the agent(s), in
management terminology called "goal congruence".
This goal congruence can be obtained by investing in control mechanisms and audit,
which delivers information on the agent. Based on this information a contract (not
necessarily a formal or written contract) can be made with the agent, posing realistic
goals, pointing out that the agent will be evaluated based on the results produced and
offering him/her an adequate and adjusted reward if the results are realised.
Obviously, this type of relations can be found in a project management environment

as well. The relationship between the project manager and the sponsor / owner is still
perceived as being hierarchically structured and the relationship between the project
manager and the users can be labelled as a principal agency relationship as well. This
is illustrated by the fact that all of these parties have their own goals and their own
criteria for success (see previous chapter).
74
Consequently, for a project to be successful, it is necessary that the goals of the parties
involved be aligned (goal congruence). This can be obtained by pointing out the
benefits that every party has when the project succeeds, by installing control and audit
mechanisms and by offering adequate rewards.
Although the tenn ''goal congruence" is not mentioned in a previous paragraph, many
elements seem to point in that direction. Project management theory emphasises,
among others, good planning and good communication, setting goals and criteria at
the start of the project and user participation. Change management stresses the fact
that all parties have to be aware of the possible benefits from the project for them.
These are all factors that should lead, directly or indirectly, to goal congruence
(putting all noses in the same direction).
2.2.3.6.2 Goal setting theory
This theory describes the relation between explicit goals and task perfonnance. It
states that goal setting can influence the performance of an employee significantly.
Clearly defined goals lead to higher performance than vague or no goals. The level of
challenge is an important feature as well. Tasks that are too easy or too difficult tend
to demotivate.
A five-step process that should lead to a good practice of goal setting is described by
Szilagyi & Wallace (1995).
1. The management has to clearly state what they want to achieve. They point out
that they need the help from the employee, offer him / her incentives for
participating and/or a reward when their goals are achieved.
2. Goal setting participative process: a process is defined that should lead to
individual goals for the employee. These goals can be imposed by the
management (assigned goal setting) or can be constructed in dialogue with the
employee (participative goal setting).
3. The properties of the goals proposed are examined. They are evaluated on a
number of characteristics as "clarity", "feedback" (measurable?), "the level of
challenge", "the difficulty of the tasks", "peer competition". If needed the goals
are adjusted or refined.
4. Goal setting intention: a link is made between the properties of the goals and level
of acceptance and engagement of the employee.
5. The perfom1ance and the job-happiness of the employee are evaluated.
Clearly, the goals set at the outlet of the project may have a similar effect on the
motivation and the engagement of the people involved in the project. This is
especially so for the goals posed by the owner/sponsor upon the project manager and
the project team.
These goals need to be realistic, but still present some challenge for the project team.
They have to be well defined, clear and concrete. Preferably, there is agreement on the
way in which the project's outcome and/or the project manager's or -team's effort are
measured, evaluated and rewarded.
75
2.2.3.6.3 Management By Objectives
Odiorne G. (1965) defined the term "management by objectives" as a process

whereby the superior and subordinate managers of an organisation jointly identify its
common goals, define each individual's major areas of responsibility in terms of the
results expected of him, and use these measures as guides for operating the unit and
assessing the contribution of each of its members.
A lot of research has been done on MBO. Szilagyi and Wallace (1995) give an
overview of the most important characteristics and conclusions relating to MBO.
• The performance of individuals improves if they know what is expected of
them.
• The performance of individuals improves if they are aware of the contribution
they make to the larger objectives, set by the management. They want to know
where their effort is situated in the general picture.
• Employees want to participate in the process that leads to the construction of
their individual goals. They want their saying on the results that they have to
achieve.
• Employees want to know how well they are doing. This implies a system of
regular feedback.
• Employees want to be rewarded for their effort. The reward is not necessarily
financial in nature, progress in the career or acknowledgements are considered
rewards as well.
There are several similarities between project management and MBO. In both
theories, goals are posed at the start. The superior (owner/sponsor) sets goals
(possibly in interaction) for the subordinate (project manager / team). In both cases,
high levels of performance are important and can be attained by a policy of clarity,
incentives and evaluation.
Again, the importance of goal setting and evaluation criteria at the outset of a project
is emphasised. But, in contrast with the goal setting theory, MBO places emphasis on
motivating people by communicating, evaluating, feedback and rewarding during the
execution of the project as well.
2.2.3. 7 Overview of the possible success factors based on

non-ICT literature
In the following table, an overview is presented of the possible success factors that
were listed in the previous subsections. Note that, in order to construct this overview,
some interpretations needed to be made. Consequently, it is not free of a certain
degree of interpretation and thus subjectivity. However, since the list presented is only
to be used as an indication and orientation for further research, the impact of the
subjectivity is limited and therefore acceptable.
76
Overview of possible success factors based on non-ICT literature
Augeh1 Clarke Turner Belassi and Tukel
• Communication • Positive attitudes • Related to the project

• Clear objectives and scope • Clear mission • Size and value
• Bite sized chunks • Top management support • Familiarity with similar projects
• Project plans as working documents • Open for criticism & review Project density
• Project definition Urgency
• Purpose, ownership, technology, cost, • Related to project manager / team
schedule, duration, finance, resources Choice of project manager
• Results in more vision and business alignment Choice of team members
• Organisation • Related to organ isation
• Appropriate management structure Top management support
Project organisational structure
• Owner involvement
Assure functional manager's support
• People issues
Project champion
• Team composition
• Related to external environment
• Communication • Manage relationships with client /
• Conflict control sub-contractors
• Planning & control systems Manage environment
• Proper level of detail in planning & refmement
along the way
• Context
• Detect and manage external influences
• Scheduling
• Milestone scheduling
• Build in a appropriate level of urgency
77
Success factors for ICT .Q!Qiects
Programme literature Change management Other management theories
• Alignment
• Effective comm.unication
Agency theory
• Good selection & justification
• Complete project organisation • Participation (resolve resistance)
• Audit- & control mechanisms
0 Use of tools (planning tools etc.) • Training & development
• Motivate agent
• Communication / involvement users • Leadership style Set realistic goals
• Aware of users' resilience • Selection project manager Evaluation & reward mechanisms
• Sponsorship by all stakeholders • Top management support
• Goal congruence
Justification & evaluation literature Goal setting theory
CIATs o Goals
Present challenge
• Lifespan Clear / concrete / well defined
• Cost control • Outcome
Measured
Adjusted CIATs Evaluated
• Rewarded
• Risk control
Management by objectives (MBO)
New methods
• Goal setting
Clarity
• Alignment with corporate goals
Evaluation mechanisms
• Integration with current situation
Provide incentives
• Managing change
• Communication
• Feedback during the project
78
Chapter II: L~erature review
2.2.4 Success factors for the implementation of ICT

proiects: synopsis
In the previous sections, several possible success factors for the implementation of JCT
projects were derived from various types of literature. The aim of th.is section is to combine
the infonnation of the previous sections into a structured synopsis, which will be used to
construct the qualitative research.
To facilitate the reading of this section, these factors are grouped into eight categories, based
on eight areas ofconcem that were derived from the literature survey.
These categories are not exclusive. Factors may belong to more than one category. The aim of
the categorisation is to present the data in a structured and comprehensive manner.
In the last part of this section, a schematic overview of the success factors is given
2.2.4.2 Good selection and justification

The appropriate solution bas to be selected in function of a given opportunity or problem
(Strassmann, 1997). In the past, projects often failed because computers were used to solve
the wrong problem (Earl, 1989). In pharmaceutical tenns one could say that it is the
combination of a good diagnosis with the use of the right drugs that cure the patient. Using
drugs without a proper diagnosis is potentially lethal.
Consequently, the selection and justification of an JCT project needs to be done with care.
Selecting a mediocre or bad project or badly justifying a project are serious handicaps. lt
might affect the profitability and , consequently, the sponsor's happiness, the happiness of the
users or of the project team and the actual implementation time and cost.
A good selection and justification of ICT projects tends to be difficult for several reasons.
First of all, traditional capital. investment appraisal techniques (CIATs) as net present value
(NPV) or internal rate of return (IRR) are not appropriate for JCT projects (Ballantine &
Stray, 1998; Whiting et al, 1996; Strassmann, 1997). Large parts of the costs and benefits are
hidden (Hinton & Kaye, 1996). Lead times and pay-offs tend to be long-tenn (Clemons &
Weber, 1990; Bacon, 1994). Risks are difficult to assess, which makes it problematic to select
a proper rate of return (Dos Santos, l 991). Meanwhile, there are no other generally accepted
techniques avai lable (Clemons & Weber, 1990). Second, the performance of an ICT
investment depends very much on the way in which it is implemented (Apostopoulos &
Pramataris, 1997). This makes the outcome even more uncertain and thus more difficult to
assess. Third, unlike other types of investments, the goal of an ICT project has the tendency to
shift due to rapid technological changes or changing insights of the parties involved as the
project progresses (Wateridge, 1995; Wateridge, 1997). As a fourth element one can point to
the fact that some projects are important because of the knowledge gained for the
organisations, regardless of the fact that they realise a direct profit or not (option theory; Dos
Santos, 1991 ).
The Literature provides some guidelines on how to deal with these difficulties. These
guidelines help to identify pitfalls and improve the selection and justification:
• Companies that apply an IT strategy tend to be more successful. The selection of a
project should be based on a sound business case that insures alignment with the IT &
79
business strategy (Turner, 1993; Fowler & Walsh, 1999; Willcocks, 1994 & 1996;
Hochstrasser & Griffiths, 1991).
• Small projects with a limited time horizon are easier to assess and to control. The
estimation of resources needed and potential return are more accurate. The
expectations are more concrete and thus easier to meet. Large omnibus projects
covering many functional areas should be avoided (Cafasso, 1994; Belassi & Tukel,
1996)
• The familiarity of the organisation with similar types of projects should be an
argument in the selection procedure (Belassi & Tukel, 1996).
2.2.4.3 The project definition

A comprehensive definition should be developed at the outset of a project, stating the
purpose, ownership, cost, schedule, duration, financing, sales and marketing, resource
requirements, boundaries, scope, objectives and goals (Turner, 1993; C larke, 1999). Through
this project definition, a joint vision on the project is created (goal congruence), the purpose
of the project is defined, a basis for cooperation is agreed upon and terms of reference are
produced. Moreover, the project definition should be used as an instrument to ensure the
alignment with the business & lT strategy (Wright, 1997; Robey, 1979; Turner, 1993).
Furthermore, defining the scope at the outset prevents the boundaries from extending beyond
the intended limits. Without scope, objectives can become fuzzy and people might lose the
overview of what they try to achieve. Having key o bjectives helps the team to focus on a
target. rt creates commitment and agreement about the project goals (Clarke, 1999).
Wateridge (1996 & 1998) found that projects are more successful when the criteria for
judging success are defined and agreed upon at the outset by all participants.
Drawing up a project definition requires a lot of experience and knowledge.

• Knowledge on the user requirements
• Knowledge on the exact information needs of the management
• Knowledge from the IT experts on the business strategy
• A realistic view on the possibilities and - perhaps even more important - the
limitations of IT.
• Sufficient experience to make realistic estimates of the resources required.
Unfortunately, gathering sufficient knowledge can be a difficult task. People tend to ask too
little or too much information because they do not sufficiently understand their own
information requirements. Hochstrasser & Griffiths (1991) for example, note that the majority
of managers are unable to give precise definitions of their information needs. Willcocks
(1994) found that 35% of the managers consider themselves constrained by poor
understanding of business plans by IT professionals.
This lack of knowledge of each other's domain is one of the reasons why the goals of ICT
projects are inclined to shift. The appreciation by the principal stakeholders of the
opportunities of the technology and the business problem improves during the development
(Remeny & Sherwood-Smith, 1998) and can thus lead to refining or even changing the goals
"along the way".
80
The impact and the quality of the project definition can be improved if:
• The goals posed are clear and concrete (The Standish group, 1995 & 1996;
Wateridge, 1996). They have to be realistic, but still present some challenge for
the project team (goalsetting theory). By defining and agreeing on objectives and
goals, the project becomes goal- and result-oriented rather than activity based
(Clarke, 1999).
• There is goal congruence. All parties need to agree upon the project definition.
This can be stimulated by active participation in the development of the project
definition by all parties and by pointing out the benefits each party has when the
project succeeds (Clarke, 1999; Turner, 1993; Wateridge, 1995).
• Control and audit mechanisms are put into place as well as adequate reward
mechanisms (agency theory).
• Large projects are divided into "bite sized chunks" (Clarke, 1999). It is easier to
set concrete objectives and goals when the project is limited in size and time.
Moreover, the possibility that technological changes outdate the project is
relatively smaller. It is thus less likely that the goals and objectives set need to be
adjusted (Belassi & Tukel, 1996).
• The investment is aligned with corporate goals and strategy (Willcocks, 1994;
Wateridge, 1996; King & Raghunathan, 1987)
• Experienced people participated in the development of the project definition.
Newly appointed managers need to be given only small projects or ones with a
fairly low complexity (Wateridge, 1997; Powers & Dickson, 1973).
A joint vision among the major participants on the goals and the way to achieve them is
essential. Differences not solved during this stage of the project will reappear later, possibly at
a less convenient moment.
2.2.4.4 The proiect plan

One of the important tasks of the pr~ject manager / team is to make a functional
decomposition. Projects are broken down into work packages. This makes it easier to spread
responsibility and accountabili.ty across more people and thus to make the project easier to
manage and to control (Clarke, 1999). These work packages are ordered and scheduled and
form the core of the project planning.
Planning needs to be done in different stages. At the outset of the project, plans should be on a
general level. Details are only provided if they are crucial for the project. As the project
moves along, planning becomes more detailed and visible at a lower level. Adjusting and
refining the project planning mostly happens in discrete steps on a rolling waves basis
(Turner, 1993; Wateridge, 1996).
The planning made at the outset should not be regarded as fixed. lt is a work document. Tt can
be used as a communication tool and as an effective monitoring device. It can help to keep the
focus on the objectives and goals set (Clarke, 1999). This is a rather fluid approach, which
offers the flexibility to react to changed situations. Furthermore, since details are filled in as
the project evolves, there is the opportunity to take the learning process of the parties involved
into account.
A degree of urgency should be built in. Manipulating the milestone scheduling can create this
urgency. However, if the pressure becomes too much, the project may become unstable.
Consequently, the milestones have to be ambitious but achievable (Belassi & Tukel, 1996;
Turner, 1993, Robey, 1979; Wateridge, 1996; goalsetting theory).
81
Nevertheless, some buffering is needed. It is not possible, nor desirable, to identify and
anticipate all possible risks and problems. The project manager can, and probably will, be
confronted with unexpected events. Sufficient time and resource buffers can help to reduce
the negative consequences to a minimum (Wright, 1997). These buffers may be part of a more
elaborate contingency plan.
There are several types of software tools on the market that can help the project manager to
make a proper project plan. Nevertheless, as Wateridge and Turner point out, these are just
aids. Relying too much on a tool is likely to have a negative effect on the success of the
project. The decisions stiJl need to be taken by the project manager.
2.2.4.5 Management involvement & support

There is a broad consensus in the literature that top management support is a success factor
(Belassi & Tukel, 1996; Earl, 1989; Fowler & Walsh, 1999; Lucas et al, 1990; The Standish
group, 1995 & 1996; Turner, 1993; Wateridge, 1996). The impact of this support is noticeable
in different areas.
Firstly, a degree of involvement of top management is necessary because they have to obtain
sufficient knowledge to be able to make well-founded decisions if needed (Turner, 1993).
Moreover, it enables them to adopt an appropriate level of additional support. On the other
hand, too much interference can be counter-productive. A good equilibrium is needed
(Turner, 1993; Belassi & Tukel, 1996).
Secondly, the level of top management support influences the level of support provided by the
functional managers. rt helps the project team to gain support from the organisation. This
makes the task of the project team easier and reduces the amount of negotiation that needs to
be done (Lucas et al, 1990; Belassi & Tukel, 1996).
Thirdly, the perceived amount of management support has an impact on the behaviour of the
users as well. High management support together with perceived problem urgency raise the
personal stakes of the users and thus the user acceptance of the project. The users expect that
their - incentric or exocentric - reward for fulfilling their role in the success of the project
will be higher (Lucas et al, 1990).
Finally, top management support is an important element in managing the change brought
about by ICT projects (see infra).
2.2.4.6 The project team

Many factors related to the skills of the project manager and the members of the project team
are crucial for the success of the project (Turner, 1993; Belassi & Tukel, 1996; Wateridge,
1997). Therefore, the selection of a project manager and the staffing of the project team need
to be done with care (Wateridge, 1996; Wateridge, 1997).
The project manager should be competent. Preferably, he or she has experience with similar
projects. This enables the project manager to make realistic estimates, in order to make a
proper planning (see supra) and it helps him or her to identify potential risks and problems at
an early stage. He or she has to have the ability to coordinate a large number of different tasks
and delegate authority. He or she has to be able to make trade-offs, should be open for
criticism and review and should possess enough social skills to master conflicts or, better, to
avoid them (Belassi & Tuke\, 1996; Tomer, 1993; Wateridge, 1997).
The composition of the team should be so that the team members have complementary skills.
This broadens the competence of the team and helps to avoid conflicts (Belassi & Tukel,
1996; Wateridge, 1996). As JCT projects become more complex and have greater impact, the
82
social element becomes more important (see supra, lngram, 2000). Conseq uently, the
composition of the team should be looked at from a social as well as a technical viewpoint
(Turner, 1993). Team members should not be judged solely on their knowledge or technical
merits, but on their social skills as well. A project manager should engage team players rather
than individuals (Wateridge, 1996).
The project team needs to be cohesive and well motivated. The team members should be
committed to the project. Turnovers have to be kept low (Belassi & Tukel, 1996;
Wateridge,1996). Skill transfer, empowerment strategies and reward mechanisms can achieve
this. The role of the team members should be defined, as well as their responsibilities and
authority. An effecti ve communication strategy should be in place and the project structure
should be clear to them (agency theory). Furthermore, the management structure and the
leadership style of the project manager are important in motivating the team (Earl, 1989;
Turner, 1993).
2.2.4. 7 Change management

Change is inevitable when dealing with TCT projects and thus change management is a
fundamental activity in any JCT project (Wateridge, 1996). Different types of changes can be
distinguished when dealing with JCT projects.
2.2.4.7.1 Change within the proiect
The first type of change is provoked by changes in the scope of the project (= project scope
change management). The scope, and thus the requirements and/or specifications of ICT
projects tend to change over time (see supra). This can outdate the original objectives and
criteria and can lead to confusion, panic and resistance among the parties involved. These
types of changes need to be handled primarily by the project manager (Farrell & Broude,
1987; Clarke, 1999). He / she is responsible for the communication, which is crucial for the
acceptance of anything new.
The changed requirements and specifications have to be incorporated into the project plan. If
the changes are substantial and have an impact on the objectives, goals or scope, the project
defini tion needs to be revised as well as the planning and the allocation of the means. The
project manager should avoid that creeping changes undermine the goal congruence and make
the planning and allocation of resources useless.
Changes in requirements and / or specifications should be formalised and communicated to

the parties involved. The project manager should seek approval for substantial changes. This
did not happen in any of the projects examined.
2.2.4.7.2 Change provoked by the outcome of the project
The other types of changes are provoked by the expected/ perceived or actual outcome of the
JCT project (= project transition management). A distinction can be made between the
technological changes and, more important, the cultural changes.
ICT projects often lead to changes in the technological or physical environment. People have
to get acquainted with their changed working environment. They have to learn to work with
new or changed techno logies in an altered environment (Turner, 1993). The impact of these
types of changes varies substantially from project to project.
83
Cultural changes are changes in the customs of the organisation itself. These are more
difficult and more time-consuming than technical changes because culture influences every
facet of the organisation, including management styles, attitudes, standards, adaptability to
change and power equilibrium (Turner, 1993; Markus, 1981). Changing the culture can create
resistance by creating inertia (Turner, I 993).
As with changes of the scope, changes of technology or culture may cause confusion, panic
and resistance. It is the task of the project manager to deal with it rather than to ignore it
(Farrell & Broude, 1987).
The following list provides some guidelines which may help to overcome, or at least reduce,
resistance against transition provoked by the ICT project:
• User participation: it is an effective way to know and fulfil the needs of the users. lt may
create commitment to the project.
• Effective communication: good communication should lead to more realistic expectations.
It helps to manage the uncertainty, encourages teamwork and increases motivation. ft may
even lead to problems being identified sooner or generate ideas that lead to better
solutions. Successful communication needs to be focused rather than broad-brush and the
timing of the communication is very important.
• Training: knowledge demystifies the JCT project. By teaching people how to work with
the new application / technology, their knowledge on the project, the outcome and the
possible advantages for them grow. The amount of time spent on - and the quality of the
training provided for the users is positively associated with user satisfaction.
• Support: the project team needs to be focused, committed and highly motivated (see
supra). Their attitude needs to be supportive and positive. They have to pay attention to
the complaints of the users.
• Leadership: people management is an important skill of a project manager and, therefore,
an important factor in delivering successful projects. A project manager may need to use
different leadership styles at different times during the project life cycle in order to get
acceptance.
• Commitment from the top: if the project affects a large part of the organization, the
involvement of senior management is crucial in the acceptance of the project (see supra).
(Based on Farrell & Boude, 1987; Fowler & Walsh, 1999; Clarke, 1999; Baker et al, 1993;
Marcus, 1981; Turner, 1983; Clarke, 1999)
2.2.4.8 Proper proiect resources

In order to manage a project successfully, sufficient resources should be at the disposal of the
project manager / team. Top management should engage itself in (re-)allocating these
resources to the project. They have to ensure the availability of the resources needed (Belassi
& Tukel, 1996; Wateridge, 1996).
Allocating resources is mainly a prioritisation problem (Willcocks, 1996) . Scarce resources
have to be withdrawn from normal business activity or from other projects before they can be
allocated to the JCT project. Lack of interest and involvement from (top) management can
quickly lead to other activities getting a higher priority (Fowler & Walsh, 1999) and thus
more resources. The momentum suffers. Moreover, when support from the top is made
obvious, doubters and reluctant providers of resources will become less doubtful and less
reluctant (Wright, 1997), which makes it easier for the project manager to rely on and make
use of resources (see supra).
84
As the strategic importance of IT increases, the resource allocation decisions become more
risky and more difficult (Clemons & Weber, 1990) and should thus be made at an
appropriately high level.
Too often, there is a lack of willingness on the part of the top management to allocate
sufficient resources to overcome internal problems associated with the introduction and
management of IT (Hochstrasser & Griffiths, 1991 ). Guiding change cannot be done without
proper resources. The same applies to risk management and contingency planning. Not only
does the making of a good contingency plan consume resources, but the management needs to
be aware that the eventual execution of a contingency plan requires resources as well.
(Mostly, a Jot of resources need to be made avai lable quickly to execute "plan B" and this at
the moment where the credibility of the (project) management might be in doubt due to the
failure of"plan A").
Furthennore, as advocated earlier in this text, there needs to be a buffer of resources to give
the project manager some flexibility to react to unexpected situations.
2.2.4.9 Managing relationships

When an ICT project is started, a number of people are brought together to work on the
project. These people fonn an entity, mostly referred to as the project team. This team has
relationships with all the other parties involved. These parties may be groups of people who
are directly affected by - and/or have direct impact on the outcome of the project (users,
management, etc) or groups that are only affected indirectly, usually with no immediate
influence (sub-contractors, government, unions, etc). The former are referred to as internal
stakeholders, the latter as external stakeholders.
Since the project team groups different people, the relationships between the participants of
the team need to be managed as well as the relationships with the internal and external
stakeholders.
2.2.4.9.1 Relationship among the project team members
Usually, projects put extra demands on the personal qualities of the people involved. The
team members are asked to put in an extra effort. Consequently, the people involved need to
be coached. Good communication and conflict control should lead to expectations that are
more realistic, better relationships and teamwork amongst the participators.
Moreover, it is important to point out their personal stake. Evaluation and reward mechanisms
should be in place (agency theory; Strassmann, 1997). The management has to set ambitious,
but realistic goals (goalsetting theory: see supra). The team members should have clarity in
what is expected from them as well as their position within the team (see supra). They hav e to
be aware of the context in which the project is developed (full picture). This helps to create
commitment of the team members and it helps to motivate them.
2.2.4.9.2 Relationship with internal stakeholders
Every party involved in the implementation of an JCT project, brings its own set of needs.
This can lead to friction between the parties on behavioural or organisational issues, which, in
turn, could cause implementation failure (Fowler & Walsh, 1999).
A process of continuous and dynamic evaluation and debate between infonned stakeholders
provides the best chance for information system optimisation (Remeny & Sherwood-Smith,
I 998). It can reduce friction and help to align the different viewpoints of the parties involved.
Furthennore, intensive communication can improve the knowledge of management on IT-
85
issues and the knowledge ofIT-people on the specific management issues as the development
and the implementation progresses.
Unfortunately, good communication practice is not generally applied. Three out of four
managers still point to the problems of communication gaps between IT-people and users as a
main constraint on optimising IT (Willcocks, 1994). These problems are not easily avoided.
Despite good management intentions at the outset of the project, time and resource pressure,
coupled with political tensions and unintended mixed signals from team members can hinder
communications, distort perceptions and allow expectations to go unrecognised and/or remain
unsatisfied (Fowler & Walsh, 1999; Wright, 1997).
Besides communication, dynamic evaluation and debate, clear definitions of authority and
responsibility can help to manage the relationships amongst the parties as well. If authority
and responsibility are not well defined, the authority and responsibility will be taken by
whichever power base within the organisation is the strongest. Usually this means control is
taken by one of two groups: either a user group or by technologists (Will.cocks, 1994).
• lf the users take charge, chances are that the resulting systems are inconsistent,
incomplete, expensive and only used to a fraction of their full potential
(Hochstrasser & Griffiths, 1991);
• If the technologists take charge of IT the resulting systems can be user-unfriendly,
over-engineered, unduly complex and not relevant to securing the business aims
(Strassmann, 1990).
The project manager should have sufficient power to withstand the pressure from the different
parties involved.
2.2.4.9.3 Relationship with external stakeholders
The impact of a project is not limited to the organization. It may influence several external
stakeholders, such as unions, clients, subcontractors etc. The project may provoke resistance
to change in every of these groups. At the same time, a lot of external factors can limit the
objectives and goals of the project. In fact, an analysis of the causes of project overruns,
shows that external factors are the principle cause (Turner 1993).
A list of possible external factors:

• Project's political, economfo and social environment
• Its relationship with the local community
• Competitors
• Legislation
• Agreements with and / or the (received) power of the labour unions
• Nimbyts
•
(Based on Belassi & Tukel, 1996; Turner, 1993)
The direct impact of management on these factors is often very limited. Nevertheless, some
indirect influence can be exerted, if only to provide some protective action or contingency.
The project manager should not only manage internal - but external change as well. He / she
should inform and discuss changes with the external stakeholders and should even court
politicians and influential managers if necessary in order to gain acceptance (Turner 1993).
It is important that external factors are carefully considered at the outset of the project so that
they can be monitored and managed or avoided. There are a number of techniques to manage
86
external influence, as the Environment Impact Analysis (EIA), which helps to reduce
potential opposition through extensive dialogue. Nevertheless, as with the management of
internal change (see supra), it is likely that the social and communicative skills of the project
manager, combined with experience in similar cases are essential in managing these external
factors.
2.2.4.10 Overview
The following table provides an overview of the possible success factors described in this
section. It serves as a basis for further field studies. The table is divided into eight categories,
each representing a specific area of concern. Since some factors have an impact on different
domains, some factors are listed more than once in this table.
Table 8: Overview of possible success factors
Category S ub-categorv Factors

Good selection Good diagnosis
Good selection & justification practice
AJil!IlJllent with business strategy
Small / limited time horizon
Familiar with similar projects
Proiect definition Prooer oroiect definition
Agreed upon project definition by all parties (goal
congruence)
C hallenging but realistic goals
Criteria for judgin11, success: defined & agreed upon
D ivide projects into bite size chunks
A lignment with corporate strategy
Developed by experienced people
Proiect olao Functional decomposition
Proper level of detail
Working document: adjusted and filled in as project
progresses
Degree of urgency built in
Some buffering ofresources
Management Proper level of top management involvement
involvement &
suooort
Top management support
• E nsure functional management / user
support
• Allocate resources
Proiect team Competent & experienced project manager
Team with complementary skills
Team players
Committed & motivated team
• Skill transfer & empowerment
• Responsibilities / authority / rewards
defined
• Effective communication strategies
Change Change within tl1e project Communicate changes
mana2ement
[ncorporate change in project plan / definition
Pormalise change
87
Change provoked by User participation

outcome
Effective communication
Training
Committed project team
Leadership
Commitment from the top
Project resources Sufficient resources
Top management support
Resources for change management
Resources for contingencv plan
Resource buffer
Managing Relationships among project Good communication & conflict control
relationships team members
Evaluation & rewdrd mechanisms in place
Ambitious but realistic goals
Relationships with internal Continuous evaluation & debate
stakeholders
Clear definition of authority responsibility
Project manager has sufficient power
Project manager has sufficient social skills
Relationship with external Consider external factors
stakeholders
Manage relationships with external parties
Literature provided a list of possible success factors (table 8) and the mechanisms behind
these factors. This information was used to prepare the qualitative research for success factors
(chapter ill). More specifically, it was used to construct the questions that were applied during
the interviews (see infra) and it provided background information for the interviewer. Though,
note that the literature review was not used as a base to start the qualitative research, but
rather as a source of background information. This was a consequence of the selected
methodology, which required that a "theory" is build, grounded in information from the field
rather than based on information from previous research.
1n opposite, the other part of the literature review -where a successful ICT project was
defined- provided information that was used as a base for the research for success criteria (see
chapter V). I.e. literature provided a list of possible success criteria that were tested
quantitatively. Literature did not function as a source of background information, but as a
starting point that enabled the researcher to develop a quantitative research.
88
Chapter III: qualitative research for success
factors
"If god wanted to humiliate man, he would have denied humans the possibility
to gain knowledge"
[mam Ali Bin abi Tale b, 6° century
Chapter III: Qualitative research for success factors
3.1 Methodological framework
3.1.1 Introduction: a philosophical - theoretical perspective
3.1.1.1 Justification qualitative research
As stated in chapter I, a choice was made to start with the qualitative research (see figure 1).
"Qualitative research is an inquiry process of understanding based on distinct

methodological traditions of inquiry that explore a social or human problem. The
researcher builds a complex, holistic picture, analyses words, reports detailed views
of informants and conducts the study in a natural setting" (J. W Creswell, 1997)
Quantitative
research
Figure 1: Research design
This choice is based on the conviction that lCT projects (unit of research) should, in first
instance, be approached in a holistic manner. It is important to create a global picture before
starting the examination of some elements in more detail. Moreover, it is important to study
the combined impact of variables. Consequently, part of this qualitative research has an
exploring nature. Furthermore, there has been little research that takes the project as unit of
research, which makes it impossible to develop a theory ex ante, based on literature tbat can
be tested quantitatively. Moreover, the projects are examined in their natural setting, which
means that the researcher has no impact on the - numerous- variables. This makes quantitative
research more difficult.
This choice has consequences for a number of aspects:
3.1.1.2 Methodological
Contrary to quantitative research, qualitative research is characterised by inductive logic. This
implies that the research should evolve from collecting actual data on specific projects to a
more abstract level. Furtbennore, the projects are studied in their specific context. This
implies that this context needs to be described accurately and that the impact of the context
should be examined.
91
3.1.1.3 Ontological
The researcher must be aware that the qualitative research always starts from a certain
perspective. One has to acknowledge different realities. For example, one can look at an TCT
project from an economical perspective, a social perspective or a technical one. Moreover,
one can look at a project from a company's site of view or through the eyes of the users. The
choice of perspective largely determines the techniques used.
This research focuses mainly on the stakeholders (users, management and project team).
Through interviews, an attempt is made to discover which elements the stakeholders perceive
as important for the success of a project.
3.1.1.4 Epistemological
The distance between the researcher and the phenomenon under research is much smaller
when performing qualitative research, compared to the quantitative approach. The researcher
is involved more closely. This is the case in this study as well. The data is mainly collected
through personal interviews.
Close involvement can cause biases. For example, liking or disliking an interviewee can
influence the analysis. The researcher has to be aware of this and should avoid errors that
result from close involvement.
3.1.1.5 Sampling
ln quantitative research, the objective is to take a representative sample that is by no means
manipulated by the researcher. Samplings are made based on chances (probability sampling).
The less statistical interferences in the sample, the better the quality of the sample.
Contrary, in a qualitative research, researchers intervene in the sampling. The researcher does
his sampling in such a way that the sample is best suited to examine the phenomenon under
research. In other words, one creates a sample that delivers the largest possible amount of
information.
In this research, successful, less successful and failed projects were selected. The comparison
between these categories provides the best chance of discovering the factors that have an
impact on success. Note that this mix is not a lucky coincidence, but a result of an active
selection policy.
3.1.1.6 Classification
This part of the research can be classified as a founded theory approach. The goal is to
develop a theoretical insight by continuous examining and comparing phenomena.
(Verschuren & Doorewaard, 1998).
92
Chapter Ill: Qualitative research for success factors
3.1.2 Purpose
The goal of the qualitative research is to identify these elements that have an impact on the
successful implementation of [CT projects. Identifying these elements and examining the way
in which they influence success, leads to a better insight in [CT projects. These will be
translated into management guidelines in a later phase.
3.1.3 Research questions and sub-questions

• Which are the key success factors for the implementation ofICT projects?
o Which are the factors that make a difference between failure and no failure?
o Which are the factors that can lift a project out of mediocrity towards a very
successful project?
• How do the key success factors affect the successfulness of an implementation?
o How do the mechanisms behind the success factors work?
3.1.4 Limitations and delimitations

The scope of the study is narrowed to large ICT projects in Belgian bank and insurance
companies.
The choice for large projects has to do with their structure and the working methods applied.
Large projects are formally structured. Different organs and different stakeholders can be
distinguished (users I project team / management). Moreover, sufficient written information
1
will be at hand • These documents are crucial sources of information for this study (project
proposals, internal memos, reports, time sheets, etc.).
The choice to limit the study to Belgian companies is based on the observation that there is a
substantial difference in management culture and company structure between the companies
of the different countries. By limiting the study geographically, the cultural differences are
reduced to a minimum. Furthermore, it provides logistic advantages.
The choice to select the bank and insurance sector is a pragmatic one. Since the KBC-holding
was willing to cooperate, the selection of the bank and insurance sector was eminent.
Furthermore, all the projects in the research had to meet a list of criteria. This list was
developed before the negotiations with companies started:
• It had to be an [CT project

• It had to be mu lti-sited: implemented in logically or physically distinct places
(example: different offices or departments)
• Three parties should be involved: end-users / project team / management. There has to
be a clear distinction between these groups.
• The expected project lifecycle should exceed 6 months
• The expected budget, expressed in man-weeks (MW) should exceed 150 MW.
1
Installing a specific kind of spreadsheet for the CEO can be regarded as an IS/IT-project.
Nevertheless, this is a very small project. There will not be enough written material.
93
An initiative was regarded as a project if the board or direction committee had approved the
project proposal. Due to the research design, a project can only be studied if the project
proposal ~or another official document) contains targets, a budget and a timeframe (triple
constraint ). Furthermore, the projects need to be examined after the handover. Some aspects
(resistance, actual gains, ... ) can only be examined when the application is in production.
3.1.5 Type of design used

Within the group of qualitative research methodologies, grounded theory was selected. It was
chosen because it is perceived as very useful in developing context-based, process-oriented
description and explanations of a phenomenon. This is also the reason why it is becoming
increasingly common in the IS literature (Myers, I 998).
Furthermore, the methodology enables an holistic approach and stimulates exploration, two
properties that were obligatory for this research (see Chapter I & section 3.1.1.). Though, note
that this approach implies that the "theory" is primarily constructed based on field data.
Consequently, the literature review is, in first instant, used as a source of background
information. In a later phase of the research, the findings based on the field data are compared
to the findings of the literature review.
Grounded theory is developed by Glaser and Strauss (1967) as a method to guide the
researcher through an inductive and reciprocal process, consistent with the inductive model of
thinking. The aim of the methodology is to generate a theory - an abstract analytical scheme
of a phenomenon - that is related to a specific situation. It promotes a continuous interplay
between data-collection and analysis (Myers, 1998).
Grounded theory is a "construct-oriented" methodology. One starts with general, open

questions, that are further shaped as the researcher progresses in his / her exploration in the
field. The emerging theory is thus embedded in and supported by data from the field.
Consequently, the theory will be highly interwoven with the context in which the
phenomenon is studied. A detailed description of the context of the research is thus necessary.
Basically, the researcher breaks down all the information collected into very small basic
elements, and labels them. These elements are regrouped and clustered into different
categories. By comparing and linking these categories with each other, patterns emerge. These
patterns form a theory, which will be validated on new data. Adjustments are made until a
rigorous and reproducible theory is constructed (see figure 2).
2
The triple constraints (within time and budget, and to specifications) are the three criteria traditionally
used in project management (Groote, 1995).
94
The grounded theory approach is discussed in more detail in appendix [.
athering: researcher gathers information
Interviews: researcher asks questions
Categorization: researcher forms categories
Patterns: researcher looks for patterns
heory building: researcher develops a theory
Figure 2: Grounded theory methodology
3.1.6 Context description

3.1.6.1 The KBC holding and the merging operation in 1998
KBC bank and insurance group was founded in June 1998 as a result of a merging operation
between two Belgian banks (CERA & KB) and an insurance company (ABB). It resulted in
one of the largest financial groups in Belgium, offering a range of financial products and
services to its clients, whether private persons, institutions or corporations.
The holding exists out of 4 juridical entities:

• KBC Bank and Insurance Holding Company NV
• KBCBankNV
• KBC Insurance NV
• KBC Asset Management NV
Some of the selected projects were executed before the merging operations, some were part of
the merging operation and some were initiated after the merging. The projects examined were
executed within KBC bank, KBC insurance or within one of the companies that were to
merge into the new group (ABB, CERA, KB).
The bank and insurance sector can be regarded as dynamic and turbulent (Ribbers et al, 2002).
In a turbulent environment, the expectations of customers, suppliers, competitors, and
government change rapidly and unpredictably. In response, organisations revise their business
plans and then re-evaluated their existing IS plans and ongoing projects (Salmela et al, 2000).
This is the case for the KBC group as well. They are working on volatile markets. This means
that their business needs can change rapidly. This has several repercussions on their ICT
strategy and on ICT projects as well.
95
• Changing environments make it difficult to make projections in the future. For

example: the gains of supporting a product with an application is difficult to estimate,
since it is highly uncertain that the product will still exist within 4 or 5 years.
• The changing environment may impact projects during their lifecycle. The goals may
shift, resulting in an alteration of the project definition.
• On the other hand, l.ots of the lCT projects are triggered by the fact that the
environment changes. It is a continuous struggle to apply to the market needs.
The merging operation had a large impact on the 1T departments as well.
Before the merge, every firm (ABB, CERA, KB) had its own IT department. The IT
department of the insurance company was relatively small compared to the 1T departments of
the banks. It had a less austere structure. Another difference was that the insurance company
relied more on self-developed software. Due to the specific legislation, there were tittle
packages on the market that could fulfil their needs. However, this changed in the mid-
nineties. Due to a shortage in 1T resources (especially skilled IT people) and due to the fact
that the quality and the coverage of functionalities of the software packages increased, the
insurance company decided to start implementing software packages as well. The difference
between the IT departments of the banks was mainly the level of decentralization. For
example: the local bank offices of CERA could not register data directly into the IT platform.
This was done by the back office. KB had some applications that required direct input by their
local offices.
During the merging operation, the IT departments of the banks had to merge as well. All
applications dealing with domestic banking were centralized on the CERAex-CERA
platform, while the applications that supported foreign trade were based on ex-KB
applications. This was decided upon during the negotiations leading to the merge. One of the
elements that influenced the decision was a study, performed by a consultancy agency.
Among other things, they developed a high-level merge plan for IT.
1n a later phase, the JT department from the insurance company and the new IT department
from the bank were to become one juridical entity. The IT department is not connected to a
certain business, but is regarded as a separate entity. Consequently, the distance between the
business and IT will probably become a bit larger.
All projects examined were initiated before the creation of this new juridical entity. Some
projects date from before the merging operations, others were triggered by it and some date
from after the merging operation.
Note that the fusion led to an IT department that was considerably larger than the departments
the companies were used to deal with. Consequently, new structures and working methods
needed to be introduced. This led to a search, which resulted in new organisational schemes.
For example, one of the new approaches was called "the new governance structure". It
described a new company structure, the different organs, their responsibilities and
composition. The new governance structure had repercussions on some of the projects
initiated after the merging operation. For example, it dictated which organs could be
contacted by the project organisation if difficult and sensitive decisions needed to be made
(see infra). Note that this new structure is already outdated.
96
Further information on KBC and the merging operation can be found in appendix ill or on the
KBC website (www.kbc.be).
3.1.6.2 The proiects examined

In this subsection, a brief overview of the projects examined is presented. This overview is
kept limited. A detailed description of the projects would enable the reader to connect certain
statements to certain interviewees. This should be prevented at all cost. Furthermore, the aim
of this study is not to judge the individual projects.
Nevertheless, the descriptions should be sufficient to present a view on the goals and the
context in which the projects were executed. These project descriptions are developed by the
researcher, but have been reviewed by the project managers. They were given the opportunity
to add or change information if they considered it useful in understanding their project.
Note that the data for these project descriptions are derived from the project charter (or similar
documents). Consequently, it presents the project as described at the outset. The estimates in
the project charter do not necessarily match with the actual use of time and resources.
97
3.1.6.2.1 Project description: ABC
Name ABC
Start date 1/1/95
Expected end date 31/12/95
Expected Man weeks
Project leader(s) Bernard Janssens
Interviewees Bernard Janssens, Frans Revmenams, Jos Naessens, Luc Husson
OT!!:anisation ABB (now KBC-V)
Pro2ram -
1. Goals
There were two major goals.

1. Applying to the information requests of the CDV (Controle Dienst der Verzekeringen:
this is an organ that supervises insurance companies in Belgium).
2. lmproving the management infonnation, by improving both quality and speed of
internal rapports.
Introducing an ERP package attained these goals. SAP was selected. ft was used to automate
the centralisation of the sub-accounts and to generate the requested rapports.
2. Constraints / criteria
The Belgian legislator had adjusted the account system for the insurance companies. The
accounts had to be rearranged and operational into the new system at the time when the new
legislation came into force. This meant that the timeframe was rigid and could not be altered.
3. Trigger
There were two triggers:

1. The changing legislation forced the company to alter their accounting system.
2. Management was convinced that the management information needed to improve.
4. Remarks
• The selection of the ERP and ABC were two different projects for the insurance
company. In this research, the term ABC refers to both projects. The selection and
implementation are regarded as a whole.
• Until this project, the company used self-developed software. But since there were a
lack of IT resources (mainly people), self-development was rejected as an option. This
was the first time that an external software package of this size was introduced into the
organisation. There was no experience with software packages nor with ERP systems
at the time the project was introduced.
• SAP R/3 was selected. At that time, R/3 was only just released. Consequently, it was
one of the first implementations of SAP R/3 in Belgium.
98
3.1.6.2.2 Proiect description: Ad Hoc Workflow
Name Ad hoc Workflow

Start date Februarv 2000
Expected end date January 2001
Expected Man weeks
Proiect leader(s) Luc Schroe
Interviewees Luc Schroe, Luc Provoost, An Van Rompaey, Marc Gijs, Katelijne
Vuerstaeck
Organisation KBC-V
Program KBC-VA
1. Goals
The goals were double. First, this project was initiated to get acquainted with ad hoc
workflow technology, its possibilities and limitations. It was to provide knowledge that was
useful in future projects. Second, the new workflow application was to improve the process
of mortgage insurance. Up until then, paper application forms had been used. Office clerks at
different branches filled them in and sent them to the head office. At the head office, this data
was keyed in. This process was partly automated by the ad hoc workflow application. This
was to result in a more efficient process. Moreover, mortgage insurance is a high volume
product. Consequently, improvements in the process can result in important savings, both in
the front- and back office.
There were a number of technical constraints, caused by the fact that this application had to
function within the different branches. This means that the soft- and hardware settings of the
branches were to be considered.
3. Trigger
With this project, knowledge could be gained that was asked for by the management and, at
the same time, some remarks of the back-office could be resolved. The combination of both
triggered the project.
4. Remarks
This was the first transversal lCT project, e.g. it affected both the insurance (KBC· V) and the
bank (KBC_ B). Although this project is relatively small compared with similar transversal
projects, it was highly visible in the organisation.
Moreover, it was the first project to deal with th is type of ad hoc workflow.
The application was constructed in Lotus Notes. Lotus Notes was selected because this
software and the necessary infrastructure were already present in the company.
99
3.1.6.2.3 Project description: CIS O&R
Name CIS I O&R (Client Information System / Question and Report tool)
Start date 10/11/1998
Expected Man weeks 381
Project leader(s) Yo Vercammen
Interviewees Yo Vercammen, Walter Boogaerts, Sonja Vertommen, Marc
Casselman
Organisation KBC-Bank
Program KIT-Transversale delta's
1. Goals
Develop and implement a Client Information System (ClS) application (type of CRM
application) on the KBC platform and implement a reporting tool (Q&R) in order to query the
data stored in CIS. This should result in better commercial profiles of the clients and hence to
a better commercial policy in the local branches of the bank.
During the merging process that led to the foundation of the KBC-group, it was decided that
the ex-CERA platform would be used for this type of applications. The applications of the
different players were compared. This resulted in a list of differences, called deltas. It was
decided which deltas had to be solved. E.g. this new application should resolve a number of
predefined deltas.
• Centralised data storing

• Allow multi-channel commercial actions
• Migration of historical data from old KB and CERA applications
• Expand the information with operational and management infomrntion
• Expand the view on customer relations to family and/or group level
• Print this information locally
3. Trigger
This project resulted from the merge that led to the creation of the KBC group. KB-bank had
a well-developed client information system application, while CERA, the other major bank
that was involved in the merge, had a similar application but much less developed and with
much less functionalities.
4. Remarks
The ex-KB branches demanded that their historical data could be integrated into the new
application.
The new application had similar functionalities as the KB application, but on the ex-CERA
platform.
100
3.1.6.2.4 Project description: CNPL
Name CNPL
Start date April 1998
Expected end date October 1999
Expected Man weeks
Pro.iect leader(s) Stefaan Crijns
Interviewees Stefaan Crijns, Johan Lamotte, Annemieke Van Oystaeyen
Oreanisation KBC-V
Proeram
1. Goals
The main goal was to transfer the policies from the insurance companies that were involved in
the merge that led to the creation of KBC into the TT-system of ABB. The latter was by far the
largest insurance company involved.
An application was built to transfer the policies, some functionalities had to be adjusted or
added to the ABB platform in order to accept the policies from the other companies.
As long as the insurance policies were not transferred, it was not possible to transfer these
clients' the total of bank related data of. Consequently, time was a major constraint.
Furthermore, the transfer had to be completed before the introduction of the euro, because
making the old applications euro compliant had to be avoided at all cost.
3. T rigger
This project was triggered directly by the merge that led to the creation of KBC.
4. Remarks
There was no one who knew the system of both ABB (target) and the other companies
(source).
101
3.1.6.2.5 Proiect description: EL-Tool
Name EL-tool for PALO-offices

Exnected end date 30/6/2002
Exoected Mao weeks 587,5
Proiect Ieader(s) Pat Geysen
Interviewees Ivo Schrooten, Pat Gevsen, Tom Kees
Omaoisatioo KBC-Bank
Proe:ram QCR
1. Goals
Main goal: comply with the BASEL committee agreements in order to diminish internal
reserves.
Secondary goals:
• Develop an EDF-rating (Expected Default Frequency) for
o Corporations
o Small Businesses
o Micro businesses, agricultural finns, self-employed
This ratio calculates the risk for failure within a certain period of time.
• Develop a LGD-rating (Loss Given Default). This gives an idea of the amount of
money lost if a firm fails.
• The multiplication of the EDF-rating and the LGD-rating gives a new rating: EL
(Expected Loss).
The summation of the EL-rating over all credits gives the basis on which the internal reserves
are calculated.
• Since some data is already stocked in the databases, one should avoid redundant data
as much as possible.
• The application should run on the current hardware setting of the branch offices.
3. Trigger
• Main trigger were the BASEL committee agreements, which changed the legal
environment. The amount of money kept within the organisation to compensate credit
risks (internal reserves) could be diminished if the bank organised a risk management
system, following the Basel guidelines.
• The project was to contribute to the goals set by KBC to optimise the credit allocation
process, using quantifiable risk measures.
• There was a need to develop a more risk-oriented prize setting system and return
measures.
102
4. Remarks
• The project was started before the program. The aim was to comply as quickly as
possible. A more formal structure (program) was set up afterwards.
103
Success factors for JCT projects
3.1.6.2.6 Project description: Eximbills
Name Eximbills Client/server

Exoected end date 1/4/2001
Project leader(s) Eddy Cousin
Interviewees Eli De Mil; Eddy Cousin ; Bart Verbeek
Ore;anisation KBC-Bank
Proe;ram KIT-Transversale delta' s
1. Goals
The aim was to develop a new ICT platform to fully support the back office of foreign trade.
A new, uniform and cost efficient transaction system that covers all foreign trade products
had to be developed and implemented.
• Ex.imbills had to be integrated with the current IT within the Bank.

• The application had to support multibanking and multibranching
• The application had to comply with the IT-architectural demands posed by the COU
(division that manages lT applications)
• The application had to support insourcing
• Clients had to be able to communicate with the application through a form of
electronic banking.
• There was to be the possibility to link the appl ication with other applications like
Bolero)
3. Trigger
This proj ect was triggered by the merge between KB, CERA and ABB, resulting in the KBC
group. KBC was in need of an application that covered all foreign trade products offered to
the clients. The ex-CERA IT-platform was selected to implement the application.
4. Remarks
KBC selected Eximbills, a CSE product. This product was customised and implemented.
KBC chose this package because of experiences with a previous version of this package
(based on MS DOS).
Both KB and CERA had applications that supported foreign trade products. These
applications did not support all products, though, and they were neither uniform nor
integrated.
104
3.1.6.2.7 Proiect description: IT-framework
Name IT-framework
Expected end date 3 l/12/2000
Project leader(s) Serge Beersaerts
Interviewees Serge Beersaerts, Rene Lamproye, Patrick Antoons, Rudy Desmet,
Erwin Wellekes
Ori?anisation KBC-V
Proeram -
1. Goals
Develop and implement a framework for IT to support the implementation practice of ICT
projects. The aim was to deliver high-Level products in a stepwise and controlled manner. The
framework was to lead to a better-controlled and supported_development process.
Moreover, the framework was to offer and deliver support for fT-tools, techniques, processes,
and organisational models for all ICT departments that are in need for this type of support.
Develop training material / organise courses on the subject.
The framework had to be flexible. ft had to be applicable throughout a number of different

lCT departments and it had to be adjustable to changing conditions in the future.
The project had to integrate the practices and tools that were currently used.
lt had to be in line with the "KBC - IT guide" and the various other frameworks that were
developed within the organisation (example: at that time, an organ, called PMO, was created
to develop, implement and control project management techniques.)
3. Trigger
There had been several attempts to introduce a methodology for the management,
development and implementation of IT projects. These methodologies w ere developed in
cooperation with external consultancy firms. These previous attempts failed. After the failure
of the last attempt, management decided to start developing a framework internally. This was
the start of this project.
This project was management driven. They felt the need for a more uniform approach within
lCT.
4. Remarks
The aim of the project was to develop and implement a framework, a series of guidelines
(called steps) and supporting tools. This approach is less stringent than a methodology, but
105
should still provide a more coherent and transparent way of working throughout the
organisation.
The choice for an IT-framework instead of a complete methodology was caused by the
concern that the implementation of a full methodology was bound to fail (as was
demonstrated by the previous attempts).
106
Chapter Ill; Qualitative research for success factors
3.1.6.2.8 Proiect descriptions: KDL & KDL 2
Name KDL&KDL2
Start date KDL: April 99 II KDL2: 114/2001
Expected end date KDL: 2311112000 II KDL2: 30111/2001
Expected Man weeks KDL: 850 II KDL2: 53
Pro_ject leader(s) KDL: Bart Saverwijns II KDL2: Nelly Boom
Interviewees Patrick Tans, Nelly Boom, Johan Laeremans
Oreanisation KBC-Bank
Proeram KIT
1. Goals
The goals ofKDL were:

• Support for the entire lifecycle of the credit process
• Generate information for the client (how much can I redraw and by which credit line)
• Online provision control
The aim of KDL2 - the sequel project - was to refine the outcome of KDL. One of the major
targets was the automation of on line provision control for cash credit lines for customers who
posed multiple accounts. Th.is functionality was not developed in KDL.
2. Constraints I criteria
KDL(2) was part of the KlT program. This means that they had to apply to the criteria the
program posed, e.g. criteria on flexibility, integration, KBC standards regarding lay-out etc.
3. Trigger
KOL was a result of the merge that led to the foundation of KBC. It was decided that a
platform was needed to support the credit process.
KDL2 was a sequel. The project was decided upon during the negotiations leading to a 4 year
planning forecast for IT.
4. Remarks
The interview with the management focused both on KDL and KDL 2. The interview with the
project leader and the user focused mainly on KDL2.
107
3.1.6.2.9 Proiect description: LCK
Name LCK
Project leader(s) Anne Van Kerrebroeck
Interviewees Anne Van Kerrebroeck, Hedwig Demunter, Gus Aerts, Tom Kees
Or2anisation KBC-Bank
Pro2ram KIT-Transversale delta's
1. Goals
Develop an application to support traditional loan products (LCK).
During the merging process that led to the foundation of the KBC-group, it was decided that
the ex-CERA platform would be used for this type of applications. The appHcations of the
different players were compared. A new application was to be developed on the ex-CERA
platform that contained the most important features of both the ex-CERA and ex-KB
applications.
• The application was to support LCK in the head office, in the merged branch offices
and the ex-CERA offices.
• The application was to be able to manage the ex-KB and ex-CERA portfolio. It had to
be possible to take the old systems out of operation after the introduction of this
application.
• Developed following the KBC-standards.
• User-friendly
• Integrated with the KBC IT-architecture
3. Trigger
This project was a result of the merge between KB, CERA and ABB, resulting in the KBC
group. It was inefficient to keep supporting the different systems of the different players.
Consequently, management decided to develop one application to replace the functions of the
other applications.
Furthermore, timing for this project was triggered by the introduction of the euro. ff they were
able to get the application in the air on time, there was no need to make the old programs
euro-compliant.
4. Remarks
The project was split up in two parts: LCK and LCK 2. Some functionalities of the original
project were taken out of scope due to time and resource considerations. These functionalities
were picked up by LCK2, a sequel project.
108
3.1.6.2.10 Project description: ORKA
Name ORKA
Start date 1/1/1996
Expected Man weeks
Project leader(s) Lieven Verhaevert
Interviewees Frans Reymenams, Lieven Verhaevert, Wim Devos
Organisation ABB (now KBC-V)
Program -
1. Goals
The main goal of the ORKA project was cost reduction and cost control.
Therefore management decided to restructure the purchase policy. It had to be transformed

from a decentralized to a more centralized system. Furthermore, new purchase procedures
(including budgeting and controUing procedures) were developed. New forms of client and
supplier accounting were introduced.
SAP was used as the main supporting 1T system. Several modules were introduced, e.g.
"purchase and stock management", "client/supplier accounting", "controlling".
SAP had already been introduced during the previous project (ABC). This influenced the
choice of software considerably.
3. Trigger
The project was triggered by a study that was performed some time before the start of the
project. 1n this study, the cost structure of the company was compared with the cost structure
of other - mainly foreign- insurance companies. This benchmark was the trigger of the project.
4. Remarks
Centralizing authority went in against the company culture of that time.
This project modelled processes that were cross-departmental. It was one of the first projects
to use a process based, cross-departmental approach.
109
3.1.6.2.11 Proiect description: Tak 23
Name Tak23
Pro_ject Ieader(s) Lode Wouters I Johan Devriendt
Interviewees Lode Wouters, Paul Vanheuverzwiin, Annick Van Meerbeek
Oreanisation KBC-insurance
Proeram -
l. Goals
Develop and implement a modern group insurance, with fixed contributions, where the client
can choose whether the insurance company invests the money in share related funds "tak 23",
in the traditional saving formula "tak 21", or in a mixture of both.
fn order to enable this, an application had to be developed to support both front- and back
office.
• The agents had to be able to make an offer for the new product through the VOBIS
system (current system)
• The current IT platform (Polaris) had to be altered to be able to manage the new
product on line.
• Legal and commercial documents had to be developed in Dutch, French, German and
English and administrative documentation on the newly developed product should be
constructed.
• Accounting procedures and procedures were developed for order reporting towards
fund management.
• There had to be a reporting tool.
3. Trigger
A combination of low interest rates on traditional saving formulas and high returns on shares
created a demand for share-related insurance products (for example: share funds for
retirement savings).
Several competitors had developed similar products already.
4. Remarks
• At the time of the execution of the project, the IT platform was made euro conform.
• At the start there was some uncertainty on the legislative initiatives taken by the
Belgian Government (KB 69; Beleidsnota ministerraad 30 juni 2000).
• The project charter explicitly names two project leaders: Lode Wouters from the
business site and Johan Devriendt from IT.
110
3.1. 7 Data collection

3.1.7.1 Sites
The units of research are ICT projects within bank or insurance companies (see supra). The
projects examined were executed within the KBC-holding or in one of the companies that
were to become part of the holding (i.e. these projects were initiated before the large merging
operation that led to the creation of the group). The projects were past the handover stage
when examined. In other words, the application that resulted from the project was in
production.
Both within the bank and the insurance company, there was a contact person. Thjs was
somebody who was well acquainted with the ICT projects in his company. The selection of
the projects was done in mutual agreement between the contact persons and the researcher. A
list of projects was made up and approval asked from the management.
The application that resulted from the project had to be implemented in physically or logically
distinct locations (for example: used by different departments). Differences in the
implementation and acceptance could be examined and compared between the locations.
For every project, an end user, someone from the project team and a member of the
management were interviewed. This list of interviewees was extended with additional people
if this enhanced the knowledge on the project.
3.1.7.2 Access to data

This type of data collection depends entirely on the cooperation of the companies and the
interviewees. Getting cooperation appeared to be quite difficult because internal and sensitive
information was asked for. Furthermore, this could be interpreted by IT as external
interference in their affairs.
There had been a number of failed negotiations with other companies. The contact with these
companies was made through the IT department. lt was relatively simple to get data on
successful projects, but when data was asked on less successful project, the companies
refused to cooperate.
Luckily, the KBC holding was willing to cooperate in full. A conftdentiality agreement was
signed. The deal was that the researcher got full access to all data, but everything derived
from this data would be reviewed by the contact person to avoid that sensitive information
would be published.
KBC asked the researcher to perform a pilot study. A temporary report was to be presented to
the management and the interviewees after the examination of two projects. This enabled
them to get acquainted with the methods of the interviewer and to get a better insight in the
aims of the research. Based on this pilot study, approval was given to examine the rest of the
projects. Note that this pilot study was equally of use to the researcher. The list of questions
for the interview and the working method were refined and validated during this pilot study.
111
After approval, a kick-off meeting was organised, to which all the people involved were
invited. At the kick-off meeting, the aims of the research and the approach were proposed. It
was made clear what was expected from the participators. Procedures and a timeframe were
worked out.
After all arrangements had been made, every potential interviewee was sent a letter to ask for
his / her cooperation. In this letter, the procedures were described, together with what was
expected from that person. Furthermore, the Jetter explicitly stated that only aggregated data
would be reported to the management, that confidentiality was fully guaranteed and that the
researcher had the full support of the management. After that step, the contact person
telephoned the interviewee and promoted the research. If the interviewee accepted, a
telephone call was made between the researcher and the interviewee to set a date.
At the start of every interview, the researcher again pointed out that discretion was guaranteed
and that the researcher had signed a confidentiality agreement. The content of the
confidentiality agreement was clarified. This enhanced an open conversation. Furthermore, it
was made clear that different documents had already been studied by the researcher and that
interviews with other stakeholders of their project were planned or had already taken place.
Moreover, the interviewee was asked if he / she objected to the registration of the interview
on an audiocassette. Only one interviewee refused. These statements enlarged the accuracy of
the answers of the interviewees.
When the research was finished, a feedback session was organised: the conclusions of the
research were presented in a session at KBC to which all participants were invited.
3.1. 7.3 Sampling

The sampling was done following the guidelines of Miles and Huberman ("theory based
sampling", Miles & Huberman, 1994). Similar sampling techniques are proposed by Strauss
& Corbin (1990) as well (see also appendix I).
The mix of the selected projects was such that it gave a maximum opportunity to study the
phenomenon. By selecting projects with a different degree of success, chances were optimised
to discover success factors. Having both successful and less successful projects in the sample
created the ability to compare. This type of sampling is often referred to as polar sampling,
which is a typical qualitative oriented technique.
Furthermore, the interviewees were selected, based on their potential contribution in the
construction of the theory as well. In every project, a user, a member of the project team and a
manager were interviewed. The selection of these persons happened in dialogue with the
contact persons, following a basic set of rules:
• All interviewees have to be representative for the group they belong to.
• The user has to use the application frequently. He or she is an end user.
• If possible, the user should be able to compare the situation before and after
implementation. This requires that he / she worked at the same department before and
after.
• The project team member can be the project manager or another person, on
condition that he / she had a key role in the project. He I she should have sufficient
knowledge on the goals, the evolution of the project and the problems encountered.
11 2
• The project team member should be adequately acquainted with the project
organisation.
• The management is preferably represented by someone who participated in the
construction of the goals and had direct benefits from the project. This could for
example be the owner (he / she initiates and guides the project) or the sponsor (he /
she provides resources).
Additional interviews were performed in some of the projects. New interviewees were added
to the list because of their specific knowledge on certain issues. The goals of these additional
interviews were double. On the one hand, it provided additional information. The interviewee
might have another perspective on the project or could give information on specific problems.
On the other hand, the additional interviews were used to triangulate and verify the statements
of the other interviewees. Moreover, it created the possibility to confirm or reject parts of the
emerging theory.
The first type of sampling (one interviewee from every group) can be regarded as a form of
homogeneous sampling, while selecting interviewees to highlight certain problems or to
verify ideas can be regarded as heterogeneous sampling.
3.1.7.4 Data types

For this research, source triangulation was used. Each project was studied using:
• Documents (project charter, progress reports, evaluation reports)

• The results of minimum three interviews, all from a different perspective.
The content of every interview was compared with the results from other interviews and the
data retrieved from the documents (triangulation). Since both documents and interviews are
used, the data can be classified as multi-sourced.
3.1.7.4.1 Interviews
The interviews are semi-structured. They were held using a List of questions. This list was
constructed, based on the guidelines of the University of Groningen, Netherlands (Hulshof,
1997) and KU-Leuven, Belgium (Carton, 1991). Inspiration for this list of questions was
found in the paper "Success factors for the implementation of JS/IT projects: synopsis"
(Enschede, EIASM-conference 2000). This was the synopsis of the literature review.
This list of questions was tested, adjusted and validated during the pilot phase of the research
(see supra). During the pilot study, every interviewee was asked if he / she knew issues that
might influence success, but that were not discussed during the interview. This was done to
check the list of questions on completeness. Moreover, the interviews of the different parties
were compared to see if a same pattern emerged, e.g .. did the list of questions reveal the same
weaknesses in every interview. Finally, the inlerviewees received feedback after the pilot
study (presentation of the results in group) and were asked to formulate their remarks. This
enabled the researcher to check whether the information resulting from the interviews was
correctly interpreted.
113
The questions in the list were grouped in five themes:

• Selection and project definition
• Project team / project manager and the functioning of the team
• Acceptation of the project and the results
• Jmplementation
• Evaluation of the results
With.in every theme, a fixed interrogation pattern was used.
First, the interviewee was introduced to the theme. This was done by means of a small
introduction (the subject of the next questions will be ... ) and a list of short questions about
facts (example: how many people were part of the project team?). These questions were asked
to refresh the memory of the interviewee. The interviewee thus had the chance to recall the
complete situation before more in depth questions were asked. This was necessary because
some of the projects had been initiated several months or even years before.
After the reconstruction, the core questions were asked. These questions were relatively
indirect in nature to avoid suggestion. The aim was to let the interviewee state some
important issues about the theme: the validity enhances if the interviewee suggests issues him
/ herself, without being specifically asked for. The issues reported by the interviewee were
further explored using some highly focused, direct questions, referred to as in-depth questions
because these questions enabled the researcher to dig deeper into the subject under discussion.
Every question session was concluded with a short summary by the interviewer (example: so
ifl understand you correctly, you state that in this project. ..). This was a way to verify if the
interviewer had interpreted the answers correctly.
After every theme, interviewees were asked to rate a number of statements. These ratings
were used in the quantitative part of the research for success factors (see part II of the
dissertation).
The interview was conducted using a large number of (relatively small) questions. These were
fired at the interviewee at high speed. The aim was to avoid the interviewee to reconstruct the
story (enhance reliability). The answers needed to be spontaneous and off-hand. The
interviewer controlled the tempo. He interrupted the conversation to explore some answers
more in depth if this was judged necessary. During the pilot study, this approach generated
the best results.
Crucial questions were posed twice (in a slightly different form) during the interview. If the
answers differed, the interviewer intervened and posed additional questions to get a better
insight in what the interviewee was trying to say.
114
Introduction into the theme

• . of the situation
Reconstruct1on . .
col questions (indirect)
•
Answers
ln-tpth q,ostions (direct ond fuousod)
Answers J
S+my ,nd / o, conclusion
Answers
Vigure 3: Interview schema
3.1.7.4.2 Documents
Besides interviews, documents were an important source of information as well. These were
internal documents, provided by the different parties involved in the project. The project
charter, the progress reports and the evaluation reports were asked for as well as any other
document that might be judged as being important to understand the project and its results.
These documents were examined before the start of the interviews. They gave a first
indication of sensitive issues. This information was kept in mind during the interviews.
Furthennore, these documents provided data such as time and budget limits, which could be
used directly in the research.
Examining the documents appeared to be a good preparation for the interviews. The
interviewer developed knowledge on the project. This was recognised and appreciated by the
interviewee. The interviews delivered much more information since they were well prepared.
Furthermore, it enhanced the accuracy and the reliability of the answers.
3.1.7.5 Recording of the data

The interviews were recorded on audiocassettes and notes were made during interviews. This
information was keyed in using MS Word. In a next step, the word files were transferred to a
software package called NUD*IST (more information can be found in the next sections and in
appendix TI). The information in the documents was filtered and summarised per project. This
information was loaded into NUD*IST as well.
115
3.1.8 Data analysis strategy

3.1.8.1 Analysis strategy
There appears to be no consensus on how to analyse qualitative data. Therefore, a mix of
techniques was used in this research, primarily based on Strauss & Corbin (1990) and
Creswell (1997).
Step l: General review
After a large part of the interviews are perfom1ed, the researcher reads all the data collected to
get a general picture, a general feeling on things. This leads to a first initial summary.
Step 2: Arranging data
Based on the keyed in data, categories are defined. The text files are read several times to
refine and support the categorisation. All categories receive a label. These labels are used to
code all the text fragments (tentative coding: see appendix I). An attempt is made to visualise
the categories as much as possible. Both the labelling and the visualisation was done using the
NUD*IST software (see infra).
A rule of thumb, developed by Creswell, dictates that one should have approx imately 25 - 30
categories at the start of the analysis. During research this number is reduces to 5 or 6.
Note that in qualitative research, not all data is entered into the analysis (Wolcott, 1994).
Some data will be ignored. This is the case, for example, for those parts of the interviews that
are simply not relevant for the research.
Step 3: Theory building
An attempt is made to connect the different categories. Based on this, an analytic framework
is drawn and a theory is developed.
3.1.8.2 The use of computer to analyse data

Computer programs can be used to analyse qualitative data. They are especially useful when
analysing and ranking large text databases.
The most important advantages are:

• Easy data organisation
• Swift retrieval possibilities
• Coding on computer forces the user to analyse each paragraph.
There are some disadvantages as well:
• Leaming to use the software
• Resistance to change the coding, once entered in the computer
• The manuals are technical and offer no help for the actual analysis.
The user has to be aware that keying in data is no substitute for careful analysis. E.g. the
computer is merely an aid. It cannot replace the researcher.
116
3.1.8.3 NUD*IST
In this research, the computer application NUD*IST (non-numerical unstructured data
indexing, searching and theorising) was used as an aid for the qualitative data analysis. This
software is described by Richards & Richards (1994) as a "theory generation program,
designed for grounded theory".
The following actions can be executed with the help of the software:
• Store and organise text files (ASCil-TXT format)
• Store and organise category labels (called tags or nodes)
• Coding paragraphs with the use of nodes
• Query the text database with the use of nodes
• Registering relations between nodes (categories)
• Visualise the nodes and their relationships in a tree diagram.
• Development of templates
• Search for words / sentences/ quotes
The software version 5.0 was used. Further information and screen caps ofNUD*JST and an
example of a coded page can be found in appendix II.
3.1.9 Validity and reliability

An important issue in this type of research is the "evidentiary adequacy" (Erickson, 1986).
Freely translated, it means that the researcher should spend a sufficient amount of time on the
field and that the data that is used as proof should be sufficiently extensive. Creswell (1997)
proposes a rule of thumb:
The ,-esearcher typically conducts 20 - 30 interviews based on several visits to "the

field" to collect interview data to saturate the categories.
In this research, more then 40 interviews were conducted because the research deals with a
broad and complex subject. These interviews play a significant role in the data collection of
this grounded theory research.
A study has to be credible, accurate and correct. Tt is of the utmost importance that the
researcher reflects on the question "Did I do it properly?". The research has to apply to
standards and criteria that the researcher imposes on himself and that are imposed by others
(academic world, principal, ... )
The researcher has to reduce the chance on random errors to a minimum (reliability). The data
needs to be accurate and stable (internal reliability) and the research has to be reproducible by
other researchers (external reliability). The legitimacy of the results most be uncontested and
based on a research design that avoids systematic errors (validity). The results need to be
relevant in explaining the phenomenon (internal validity) and the results have to be
transferable to other areas / units of research (external validity) (Pauwels, 2000).
On the one hand, the validity and reliability are enhanced by the way the study is constructed
117
(use of indirect questions, multiple interviews for every project, .. .). An overview of the
measures taken to enhance reliability and validity is presented in Table I. On the other hand,
the researcher should evaluate the research on a regular basis, during the different phases of
the research. In this research, guidelines of Howe & Eisenhardt, 1990 and Creswell & Miller,
1997 were used to question the research on a regular basis.
3.1.9.1 Howe & Eisenhardt (1990)

• Evaluate if the research questions are the driver of the data collection and not the
other way around.
The qualitative research is conducted using the "grounded theory" approach. This
implies that a theory is constructed, based on observations. The major research
questions are defined at the outset, but are refined as the research progresses and
theory emerges. This is a property of the method selected.
• Check whether the data collection and analysis was done in a technically correct
manner.
The research is conducted, using generally accepted and well documented techniques.
Furthermore, a pilot study was performed, which was used to check and validate the
research approach. This pilot study was discussed with the interviewees, managers,
but also with academics on content and methodology as well.
The analysis of the qualitative data is done, using appropriate software.
• Are the assumptions and the subjectivity that is part of every researcher sufficiently
explicit?
This question is posed several times during the writing process. Tn other words,. it was
kept in mind during the development of the dissertation.
• ls the research robust? Does it use generally accepted methods?
The qualitative research is conducted, following the guidelines of Strauss and Corbin
(see supra). This is a well understood and accepted methodology.
Note that more interviews (44) were carried out than prescribed by the authors. This
should contribute to the robustness of the research. A high number of interviews were
planned because of the complexity of the phenomenon under research.
• The research has to create value, both by creating knowledge and serving practical
goals (i.e. does the research have any value for business).
This is the first scientific research in Belgium on success factors ofICT projects, with
"projects" as unit ofresearch.
Furthermore, management guidelines for the successful implementation of JCT

projects can be derived directly from the success factors found in the research.
118
• The confidentiality and privacy of the participants need to be guaranteed.
A confidentiality agreement was signed (see supra). The contact persons within KBC
read all publications derived from the research to prevent the publication of sensitive
information
Only aggregated information is reported. The content of individual interviews are not
exposed to guarantee the privacy of the participants. This has repercussions on the
dissertation. The quotes of statements of interviewees are not labelled. E.g. neither the
name, nor the project is mentioned. Furthermore, some quotes are simply not used
because the content could reveal the author.
3.1.9.2 Creswell & Miller (1997)
• Long term engagement, extended and persistent observation in the field are
necessary. This means the construction of a relationship built on mutual trust,
immersing in and getting the feel of the company culture.
The interviews were executed during a two-year period and were conducted on site.
There had been a pilot research. This enabled the researcher to get better acquainted
with the company and, the other way around, it enlightened the goals and approach of
the research. i.e. it created a better insight on the KBC site. It enhanced mutual trust.
Furthermore, there were frequent contacts between the researcher and the contact
persons, which resulted in trust. Moreover, the contact persons were very well
informed and promoted the research in their organisation.
The confidentiality agreement and the fact that the researcher only r<;:ported on
aggregated level contributed to an open conversation as well.
• Triangulation: the researcher has to make use of multiple and different sources,
methods, researches and theories to prove the constructed theoty.
There are triangulations at different levels:

o source triangulation (interviews / documents)
o method triangulation: quaJitative and quantitative approach
o comparison with literature
• Review ofthe research process by other researchers.
Several parts of the research were presented at international, scientific conferences.

The aim was to get sufficient feedback from fellow researchers.
Of course, the research process was often discussed with the promoter of the thesis.
• Rework and refine all hypotheses until all cases match
119
The reciprocal research methodology from Strauss and Corbin, and their sampling
guidelines are followed closely. This leads to a saturated theory, e.g. a theory that is
applicable to all cases examined (see appendix l).
• Describe the position of the researcher at the start of the dissertation so that the
reader is aware of the possible biases that can result from it.
An extensive description of the context is made to provide background infonnation for

the readers. This enables them to have a view on the framework in which the research
took place and to judge the impact of the context on the findings of the study.
• Discuss temporary conclusions with the interviewees.
After every interview, there was a little informal conversation with the interviewees.
Often, the researcher was asked if he could draw some conclusions already. This was
used to present some conclusions and to get some feedback. Thls was especially so for
the last interviews.
Furthermore, the conclusions from the pilot study were presented to the interviewees
in order to get feedback (see supra).
120
Table 1: Validity aod reliability oftbe research
Key questions Measures

Internal reliability Is the research accurate, consistent • Multiple projects examined
and reasonably stable over time and
across researchers?
• Multi-source data collection (interviews+ documents)
• Multiple interviewees per project
• Selection of interviewees in dialogue with contact person
• Confidentiality agreement and anonymity guaranteed to ensure open
conversation
• Registration on audio cassette
External reliability ls the study reproducible in the • Multiple projects examined
future? • Different viewpoints examined for every project (user / project team /
management)
• Pilot study performed to validate the methods used and the list of questions
• Fixed structure for interviews (combination of indirect core questions and
direct in depth questions)
• More than 40 interviews performed
Internal validity Is the research suited for examining • Pilot study
the phenomenon, i.e. do the findings • Feedback meeting organised after presenting results of p ilot
of the study make sense in • Use of proven interviewing and analysis methods
explaining the phenomena? • Different viewpoints looked at (users / project team I management)
External validity Can the results be transferred to • Projects examined that were initiated both before and after the merge that led
other populations or other units of to the creation of the KBC holding
analysis? • Description of context
• Iteration between research and relevant literature
• Method triangulation (qualitative and quantitative approach)
121
3.2 Outcome of the qualitative analysis
3.2.1 Introduction
All the data was keyed in and entered into NUD*IST. The data was broken down into small
units. Each of these units were labelled and regrouped into categories (see appendix l & II). In
total 18 categories emerged. Each of these categories is discussed in this chapter.
In a next step, the categorisation was refined, and connections and relationships were
examined. The number of categories was reduced from 18 to 4 major categories. These major
categories are discussed as well.
3.2.2 Category 1: Triggers and motives leading to the

execution of the proiect
The way in which the projects were triggered had a severe impact on the perception and the
acceptation by the protagonists. Consequently, an attempt was made to examine the triggers
of the projects in this study more closely. This led to the construction of four categories of
projects, based on the elements that triggered them.
• The first category contains projects that are initiated because of changing regulations
or changing infonnation demands from the government. Consequently, these projects
are triggered from outside the organisation. The company needs to comply with the
new regulations. All the stakeholders perceive these projects as "unavoidable".
• The second categories of projects are triggered directly by the merge that led to the
creation of the KBC-group. The 1T platforms of both banks had to be integrated into a
new platform. The decision to integrate both 1T systems was part of a larger merge
plan. The bases for these plans were studies that were developed before the actual
merge. The project's stakeholders regarded the missions, described in these plans, as
established facts, which could not be altered.
• A third category of projects was initiated in order to gain knowledge on some
particular - technical or managerial- issues. In other words gaining knowledge was the
prime criterion. The knowledge lack was identified and a decision was made to initiate
a project to fill this gap.
• A fourth group of projects were either triggered by questions from the management or
from the users. These projects had to take advantage of some opportunities or solve
problems.
In general, the basic principals of the first two types of projects were not questioned; there
was no discussion on whether or not the project should be executed. That these projects were
going to be executed was perceived as an unchangeable fact. In the third category, projects
were selected that had the support of both users and management. In the last category, a
distinction has to be made between projects that were triggered by users and projects triggered
by the management. Especially in the last case, some discussion could arise on the basic
principles of the project.
122
"The difference between project xxx and Y.W is that project xxx was initiated by
questions from the users. Project Y.W was triggered by a management problem. We
neglected to make it the problem ofthe users as well."
Note that in the first and the third category, direct profit is a secondary issue. Complying with
the regulations is the prime goal of the first category of projects; gaining knowledge is the
prime goal of the third category. Of course, this knowledge is of value to the firm, and should
be validated in later projects. In the second category, the aim was to reduce redundancy.
Working with two different applications on two different platforms for the same product was
perceived as not cost effective. The basic driver of projects in the fourth category were the
gains that could be realised by solving certain problems or realising opportunities.
"We were looking for a business problem that could be solved with the new
technology. The aim was to get acquainted with this technology. This resulted in
project xxx. Though we knew project xxx would probably not realise a positive cost I
benefit, it was certainly worthwhile, considering the whole of things we are engaged
in."
3.2.3 Category 2: Selection and iustification

The trigger causes / forces management to consider initiating a project. However, a problem
might have different solutions. In other words, different approaches and different projects
might be at hand. Several techniques can be used to select the most appropriate of the
alternatives. Moreover, a project consumes both time and resources. It has to be worthwhil e to
progress with the project.
3.2.3.1 Impact of the selection and iustification procedures

The projects examined in this study clearly show that both the selection and justification are
strongly influenced by the trigger of the project. In this section, an attempt is made to
demonstrate this causal relationship, i.e. a link will be made between the selection and
justification practices and the categories of projects, based on their triggers (see Category I).
In the first category, little effort was put in the justification of the project. The protagonists
felt that no justification was needed. The rules had changed and they had to oblige. This was
remarkable, since in most cases, the goals of the ICT projects were substantially more far-
reaching than just applying to government's demands. On the other hand, since several
approaches were possible, selection was an important issue. Moreover, a selection needed to
be made between in-house developed software or several software packages that were
available on the market.
''No estimate was made of the benefits. With the old application, we risked not being
able to apply to government ruling. The project had to happen. It was forced upon us
by the government. "
"Cost I benefit was not an appropriate question: having an application that was
EURO compliant was a must. "
123
lo the second category of projects, there was little or no justification at project level. This was
the result of the fact that the decision to initiate these projects was made at a very high level,
based on calculations that had been made before and during the creation of the KBC-group,
i.e. the justification was done on a higher level. Moreover, some of the issues concerning
these projects were part of the negotiations between the different protagonists in the fusion.
Similarly, in most cases, the fusion plans dictated which platforms were to be used for which
type of applications (e.g.: applications dealing with the local bank offices should all be
transferred to the ex-Cera platform). The selection had been done on a supra-project level as
well. Consequently, at the project level, neither the justification nor the selection was of
importance to the parties involved. This could be illustrated by the fact that several project
managers declared that they assumed that there had been some sort of justification.
"At the start of the merge, estimates were made of the costs ofmerging the different IT
platforms. This was very rudimentary. However, these figures were never checked
afterwards. The predictions ofthe gains were based on these estimations as well''
Note that although these calculations were high-level, they were not questioned or refined by
the (project) management. This had two reasons. First, they perceived the migration to one
system as necessary. The basic ideas behind the high-level fusion plans were not contested.
Second, they felt that they bad no impact on these plans, whether they agreed or not.
Nevertheless, several interviewees guessed that in their particular case other approaches
would have been selected if the justification and selection had been performed at the project
level.
1n the third category of projects, the emphasis was on justification, not on selection. The
management wanted to introduce new techniques and looked for an appropriate business
problem to solve. Consequently, the technique / software that was to be used was already
decided upon even before the business problem was identified. The question was which
problem or opportunity was the best suited to maximize learning and, preferably, would have
a positive return.
In the fourth category, both selection and justification were important. The selected
application had to deliver the highest return. This could only be guaranteed by proper
selection and justification. Note that in several cases the selection and justification was based
on qualitative approaches (e.g. listing and comparing properties etc.). Several project
managers stated that it was nearly impossible and not meaningful to use quantitative
techniques, because it was impossible to calculate benefits in a rigorous way since most of the
benefits were hidden.
124
These four categories are presented in the following scheme:
'"'
High Group ill: triggered Group JV: triggered
by lack of by questions from
knowledge end-users or
Importance management
of
justification Group II: triggered Group I: external
by the fusion triggers
Low ...
,
~
Low High
Importance of selection
Figure 4: Triggers and their impact
Generally, the impact of selection or justification procedures was dim inished in several cases.
Either because the projects were perceived as "unavoidable", due to external or internal
evolutions (groups I & II) or due to the fact that the other goals coincide with the business
goals of the project (group Ill).
3.2.3.2 Other elements that influence the selection and

justification of a project
Besides the common cost / benefit techniques, there are other, qualitative el.ements that can
influence the choice for a certain approach or software.
One of these elements is b us.iness alignment. ·1n the literature, alignment with the business-
and IT strategy is an important issue when selecting or justifying a project. In a few of the
projects exami ned however, alignment with business- or IT strategy was deliberately
abandoned. Moreover, these projects were diametrically opposed to the business or TT
strategy:
• The combination of scarce IT resources (e.g. Y2K. EURO, scarce labour market) and
the improvement of applications on the market, led to a shift in the 1T strategy of the
insurance company. Up until that time, applications were developed and maintained
in-house. One of the projects examined was the first project that led to the
implementation of a large software package. Clearly, this was against IT strategy.
125
''First, we examined if we could develop the application in-house, but due to the
merge, Y2K and the EURO conversion, there were simply not enough IT resources
available. We had to look/or solutions outside the company. "
• Another project was diametrically opposed to the business policy. An attempt was
made to centralise and formalise certain functions of heads of department. This was
against the business culture and strategy, which was oriented towards empowerment
and delegation of tasks.
The first project was perceived as successful. Deliberately going against IT strategy did not
turn out to be a disadvantage. This had several reasons. First of all, a lot of arguments and
discussions preceded this project. Consequently, the objectives were very clear at the outset of
the project. Moreover, the fact that this was a project with high visibility throughout the
organisation and the fact that the project team members gained knowledge that could be of
use in future projects had a positive impact on their motivation. The latter project was not as
successful. There was a high amount of resistance, causing the project to run late and
preventing it from deploying to full potential.
This seems to indicate that alignment with the business strategy is more important than
alignment with the lT strategy. Moreover, it indicates that implementing an lCT project
against the IT strategy is not necessarily negative.
Another element that influenced the selection of certain projects was the amount of resources
needed. Resources were scarce, especially IT people. Consequently, the amount of resources
needed to implement the application was an issue. It was an important issue in the discussion
whether to develop in-house or to buy a package.
The last element that had an impact on the selection of certain projects was "familiarity".
Familiarity was an argument to favour the selection of known technology. The management
used two arguments to validate this. The first argument was that the introduction of new
techniques / technologies would inevitably require getting through a substantial learning
curve. This would influence the time needed to finalise an ICT project. A second argument
was that the architectural integration was much faster if the technology was known to the
organisation. Nevertheless, fammarity is no substitute for profound feasibility studies. E.g. in
at least one project, a disputable selection was made, based on misplaced thrust in the
competences of the software provider. The latter had sold other software packages to the firm
in the past, which were of high quality.
3.2.4 Category 3: Proiect definition

3.2.4.1 Proiect Charter
Every project examined had some type of project charter (i.e. a document that contained the
project' s goals, scope, resources, timeframe etc).
The procedure that led to the creation of the project charter was more or less the same for
most projects. Management asked the project manager to create a project charter, based on
specific instructions by the management (referred to as the project mission). In a following
stage, the project manager developed a temporary project charter and presented it to the
126
steering committee or another form of management representation. There it was discussed

and/or adjusted and approved.
The instructions for the development of the pr~ject charter the management gave to the
project managers differed very much, both in form and content. Some project missions were
very informal, limited to one page and containing only the prime goals, while others were
more formal and contained, besides a detailed description of the goals, a timeframe and
budget constraints. In one project even the lay-out of the rapports the application had to
deliver was described (this was the outcome of a previous study).
In several projects, the content of the mission statement was derived from a feasibility study
preceding the project. In other cases, the mission statement was derived directly from the
plans that were constructed during the merge (see supra). Some projects were part of a
program as well. The impact of the program on the project charter could mainly be found in
architectural issues (e.g. integration with other applications etc) and on the timeframe and
resources available. The program management did not interfere in content issues (e.g.
functionalities etc.), unless they were asked to (see also Category 13). They monitored
business alignment as well.
ln the earlier projects examined, the (project) management had a high degree of freedom, both
in the content and the use of the project charter. But, as the organisation grew larger and more
complex, a process towards more formal procedures was eminent. Attempts in that direction
are now made, too. For example, templates are being developed to help the project manager in
writing project charters. It should help him/her through the process. It should enhance
comparability between projects and should aid the project manager. Consequently, there is an
evolution towards more uniform project charters. The project charter is regarded more and
more as a contract between the project manager and the management. Once the management
approves the charter, it engages itself to deliver the resources that were asked in the charter.
The project charter becomes binding for both parties.
3.2.4.2 Goal & scope

The goals of these projects that were a result of the fusion were straightforward. One IT
platform was selected. The functionalities of the applications were compared (differences
between the applications were called deltas), the necessary alterations on the source platform
were made and data was transferred. A choi ce was made not to perform BPR. Consequently,
the goals were clear to the parties involved. These projects hardly suffered from changes in
goals or scope during the project.
The same remark can be made for the projects where there was a lot of discussion before the
approval of the project charter. Due to discussion and argumentation, the stakeholders had a
good view on the project proposed. The goals were clear. Furthermore, the discussions and
arguments ensured that the parties involved had their input in the project charter.
"At the very start, there was no joint vision. Therefore, a feasibility study was
initiated After this study, decisions were made. After that, there were hardly any
problems anymore. "
This seems to indicate that, the better the project charter is developed and understood, the less
the goals or scope will shift during the lifecycle of the project.
127
In several projects, the goals were described as (very) ambitious. This seems to have a double
impact. On the one hand, project management focused more on implementing the core
functionalities (no whistles and bells). On the other hand, ambitious goals appear to have a
positive effect on the drive of the people involved (see infra).
3.2.4.3 Time frame and budget

Besides a description of the scope and goals, the project charter contains a timeframe and a
budget.
If the timeframe is too long (i.e. when there is too much time between the approval of the
charter and the final acceptance of the client), it has a negative impact on the outcome of the
project. The project charter becomes outdated, together with the allocation of resources that
was based on this "approved" project charter. Moreover, a long lifespan can lead to a type of
project fatigue (see Category 14). Several problems could be avoided if the project life span
was smaller. Or if, as was the case in some other projects, the project itself was split up in
smaller entities that were easier to control. If the time span becomes too large, the engagement
of the different parties seems to diminish. The momentum suffers.
"The goals qf the prqject were ambitious because it was a large project that was
spread out over the whole company. Nevertheless, it was achievable due to the fact
that it was split up in different parts that were staggered in time. "
In the earlier project charters, budget was seen as a sort of guideline, an indication. But, as the
project charter evaluates towards a contract between management and project manager, it
becomes a basis on which the allocation of resources is based. Consequently, it becomes more
important to have a correct estimation of the evolution of the project, the time and resources
needed. This will make it even more difficult to execute projects with a long lifespan.
"There was no joint vision at the outset of the project. It had to grow. ... At the time
when the initial budget was decided upon, we had no idea what we were doing or
where we were heading. "
3.2.4.4 Goal congruence

Nearly all interviewees mentioned a joint vision on the project by all stakeholders as a prime
success factor. Still, there was not joint vision in some of the projects examined. There were
several causes that could hinder a joint vision.
Language (terminology) seems to be such a cause. There were some differences in the
contents of the definitions used by ex-KB and ex-Cera employees. In several cases, this led to
misunderstandings and misinterpreted project charters. These differences were situated mostly
in the analysis phase and were easily solved, though it took some time.
A similar problem occurred in some projects between IT-people and people from the business
site. The business impact of certain projects was not always fully understood by the IT
specialists. This could present a problem when writing the project charter. The other way
round, not everyone on the business site fully understood the technical issues, described in the
project charter.
128
"A problem is that IT often talk another language than we do. For example, at the
start of the project they often talked about 'data warehouses'. But we did not have the
slightest idea what they were talking about. These things were rectified quickly. "
Another issue is that in at least one project, not all the important stakeholders were involved
in the process of developing or approving the project charter. One cannot speak of a joint
vision if one of the parties is not informed. This tends to be a problem if a project influences
large areas of the company, e.g. other departments etc.
Several interviewees pointed out that it is very important to clearly state the engagement
expected from all parties involved, i.e. all stakeholders should know very well what is
expected from them and what they can expect from the other parties. Consequently, there can
be no (or little) discussion on their engagement during the project lifecycle. On the other
hand, not only duties should be outlined; the advantages every party has when the project
succeeds should be pointed out to them as well.
Furthermore, the project charter should be clear and sufficiently profound. Getting consensus
on a project charter that is vague and that avoids possible discussion points is relatively easy,
though it does not hold in the long run.
"Strong point of the project definition: we digged it out so deep, it was done so
profound that it was very clear. Everyone knew where we were heading. "
3.2.4.5 Change and contingency management

At the outset of most projects, very little attention was paid to change or contingency
management. Either management did not expect resistance and organised change management
on an ad hoc basis (i.e. manage problems as they occurred) or change management was
organised at the program level, combining the introduction of several applications. 1n that
case, change management was not regarded as a task for the project team (see Category l3 &
14).
Even less attention was paid to contingency planning. Either projects had to succeed (failure
was no option) or one could return to the previous way of working, in which case the project
managers felt they did not need a contingency plan. However, most project managers
indicated they had thought about it, but did not put it in writing. Note that in the fast case,
extensive testing was planned in order to reduce the chance of fai lure to a minimum.
"J have thought about which actions to take if the project failed, but I refused to put it
on paper. Do you have any idea what message you give to the project team if you
did?"
3.2.4.6 Remarks
Most interviewees state that there is a clear dependency between clear project definitions, a
joint vision and a project's success.
A clear project definition influences the amount of change in goals or scope during the
project's lifecycle. The clearer the definition at the outset, the less chance of drastic changes
129
during the project's life. This, in turn, enhances the chance of finishing on time and within
budget.
"This was a stable project: the determination of the scope etc. was well done. There
were not many changes. The price we paid.for stability = lot of effort in the project
definition. "
Moreover, a joint vision on the project is influenced by a good project definition as well.
Discussions and arguments during the feasibility study have a positive impact on the goals
congruence. It means the knowledge of the different stakeholders on the project is enhanced,
the expectations are more realistic and the positions of the different parties are known.
"There was a joint vision. This was because we developed a clear management vision
during the feasibility stage. in order to construct this management vision, a large
consultation round was needed "
A project with a clear project definition that is approved by all stakeholders has a good chance
of being successful. Projects where the goals are vague at the outset or submitted to change,
but where the parties are willing to co-operate and work towards a common goal tend to be
late and over budget but deliver an application which is satisfactory. Projects where one of the
prime stakeholders is opposed to the project have little chance of delivering a successful
application, however clear the goals are defined.
Jn order to enlarge the chances for success, a project definition should

• Have goals that are clear to all parties
• Have ambitious goals
• Contain estimates (time & budget) that are based on a profound feasibility study and
that are based on the input of all the major stakeholders
• Be limited in time so that the momentum does not suffer
• Contain a description of all interfaces and their consequences on the project
There should be a joint vision at the outset of the project (i.e. before the analysis phase starts).
This can be done by
• Developing clear goals
• Discussions and arguments before the analysis phase
• Good communication between parties to ensure the contents of the definitions used is
the same.
• Pointing out the engagement expected and the return for the different stakeholders
3.2.5 Category 4: Additional specifications

Besides goals, timeframe and budget, several projects had to apply to additional demands, as
there are perfonnance demands, architectural demands etc ... Although the attention for these
demands in the project charters was limited, they did have an impact on the success of the
project.
Three large groups of demands can be distinguished.
130
First of all, there are demands posed by the company on every project. Every project has to
apply to a style guide (lay out etc) and some architectural guidelines (type of servers, response
times etc). In one project, the project manager remarked that he/ she was not able to apply all
style rules, due to the fact that these style guidelines were primarily developed for transaction-
like type of projects, which were not easily applicable on his/ her project.
" We had to follow strict rules regarding several issues: construction of GUl's,
capacity use of servers, architectural limitations etc. The advantage is that we have
developed an application that links up with the other core applications and has a
recognisable interface. The disadvantage is that these rules create a rather rigid
environment to work in. "
A second set of demands was demands for integration with other applications. The level of
integration was not the same for every project. The integration with other applications made
the projects more complex. Integration is time and resource consuming, but it does not seem
to influence the feel of the final application, i.e. it does not have impact on the goals or the
basic ideas of the project, but it makes it more difficult to realise them. Moreover, since
integration means more interdependencies, it is more likely that the time schedule of the
project is altered due to elements outside the control of the project manager. For example,
some projects were influenced by the timing of the upgrade of software in the local offices.
"An important issue was that our application had be integrated with the software that
was running in the local offices. But this causes a problem at this very moment: next
year they are going to upgrade the software ofthe local offices. "
The third type of demands was project specific. It was imposed upon the project manager by
the owner/sponsor or by the program manager. For example: one of the applications had to be
multi-sited, so that the possibility existed that the application could be used for insourcing
(i.e. provide services for other banks).
"The application had to be integrated with the KBC-platform. Consequently, this

implicated that there were architectural restrictions. Furthermore, a possible
integration with SWIFT needed to be foreseen. "
Overall, these additional demands had considerable impact on complexity, time and budget.
Although most of the demands were outlined in the project charter (interfaces etc), they were
often underestimated. This is especially true for the interdependencies. Many project
managers claim that their application wou ld have been on time if they would not have had to
wait for data or results from other projects/ applications.
3.2.6 Category 5: Evaluation ex ante & ex post / control

mechanisms
3.2.6.1 Proiect evaluation
There is a distinct difference in the project evaluation practices between those projects where
external firms played a significant role (to develop [part of] the software, for instance) and
those where the role of an external firm is limited or non-existing. The latter is referred to as
'internal prqjects'.
131

Koen Milis - Deel1 PDF

Uploaded by

Copyright:

Available Formats

You might also like

Koen Milis - Deel1 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Koen Milis - Deel1 PDF

Uploaded by

Copyright:

Available Formats

D O C T CJR A A T S P R 0 .

Success factors for ICT projects

Promotor : Prof. dr. R. Mercken

PARTNER IN DE UNIVERSITEIT LIMBURG

Success factors for ICT projects

Proefschrift voorgelegd tot het behalen van de graad van

Promoter : Prof. dr. R. Mercken

PARTNER IN DE UNIVERSITEIT LIMBURG

1.1 INTRODUCTION ...........................................................................................5

CHAPTER II: LITERATURE REVIEW.................................................... 15

2.1 DEFINING A "SUCCESSFUL ICT PROJECT" ................................. 15

CHAPTER III: QUALITATIVE RESEARCH FOR SUCCESS

3.1 METHODOLOGICAL FRAMEWORK ............................................... 91

CHAPTER IV: QUANTITATIVE RESEARCH FOR SUCCESS

4.1 METHODOLOGICAL FRAMEWORK............................................. 183

4.1.9 Validity and reliability .................................................................................. ........ 191

CHAPTER V: DETERMINING SUCCESS CRITERIA FOR ICT

5.1 INTRODUCTION ..................................................................................225

5.6.2 Explicit ranking of the criteria .............................................................................. 274

CHAPTER VI: CONCLUSIONS, MANAGEMENT GUIDELINES AND

REFERENCES .................................................................................................. 303

APPENDIX I: GROUNDED THEORY ................................................................. 313

Table 1: Project lifecycles ..................... ................................................................................... 17

Table I: Example of a probabilistic relationship .................................................................. 189

Table 1: Number of experts for each party .................................. .......................................... 23 1

Figure 9: Selection & justification, simulation 2 ................................................................... I 97

Figure 1: Research design ................................................................................................. ..... 225

Despite an increased interest in IT spending, it is surprising that so little empirical research

1.2 Purpose statement

1.3 Research questions

1.4 Definitions in terms

1.5 Limitations & delimitations

1.6 Research design

A schematic overview of the different stages in the research is presented in Figure 1.

1.6.2 Success factors: Qualitative research

This research resulted in two lists of factors:

1.6.3 Success factors: Quantitative research

1.6.4 Success criteria: Quantitative research

2.1 Defining a "successful ICT project''

Using these recurring elements, a definition of a project can be formulated as follows:

A project is a non-routine endeavour to achieve a specific objective. The achievement of

2.1.2.2 Proiect properties

2.1.2.2.1 Project lifecycle

Wateridge Conceptualisation Requirement & Functional design Implementation Operation

Jn this dissertation, a four-stage lifecycle is used.

When looking at an average project, five parties can be distinguished:

2.1.2.2.3 The profile of an average project

Figure I: Profile of an average project

After the implementation, the resulting application is handed over to an operational

2.1.3 An ICT proiect

2.1.3.2 Properties of an JCT proiect

Table 2: Differences ICT vs. other projects

JCT project Project to develop a additional

2.1.4 A successful ICT project

2.1.4.1.1 Ambiguity due to differences between parties

Table 3: Comparing criteria for success

Criteria for success % frequency of mention