Mba Project

CRITICAL INVESTIGATIONS ON CONTRIBUTION OF PROCESS
AUTOMATION TO SOFTWARE PROJECT SUCCESS

A THESIS
submitted by
ANNE MARTIN
In partial of fulfillment for the award

of
DOCTOR OF PHILOSOPHY
Faculty of Management Studies

[INTER-DISCIPLINARY
Management Studies/Computer Applications]
Dr. M.G.R.
EDUCATIONAL AND RESEARCH INSTITUTE
UNIVERSITY
(u/s 3 of the UGC Act 1956)
CHENNAI - 600 095
OCTOBER 2012
1
BONAFIDE CERTIFICATE
Certified that this thesis titled Critical Investigations On Contribution Of

Process Automation To Software Project Success is the bonafide work of
Ms. Anne Martin who carried out the research under my supervision. Certified further,
that to the best of my knowledge the work reported herein does not form part of any
other thesis or dissertation on the basis of which a degree or award was conferred on an
earlier occasion on this or any other candidate.
DECLARATION
Declare
that
the
entitled
CRITICAL
INVESTIGATIONS
ON
CONTRIBUTION OF PROCESS AUTOMATION TO SOFTWARE PROJECT

SUCCESS submitted by me for the degree of Doctor of Philosophy is the record of
bonafide work carried out by me during the period from July 2004 to November 2008
under the guidance of Dr. S. Ramalingam and has not formed the basis for the award of
any Degree, Diploma, Associateship, Fellowship, Title in this or any other Institution of
Higher Learning.
ii
ABSTRACT
Information technology (IT) as an industry covers a variety of services that range from
hardware procurement, installation and management, software design, development,
deployment and maintenance, data management, networking and administration. Information
Technology has become an integral part of any business and hence becomes very critical to
the safety and security of any business information. Thus Information Technology services are
to be provided with very high level of quality. To achieve such quality levels, underlying
processes need to be well defined, applied, standardized, measured and improved
continuously.
Software Process Automation provides a set of process guidelines and related tools in
an integrated workflow based environment within a software services organization to enable
the end users to follow certain process standards uniformly thereby deriving desired and
expected outputs. Software Process Automation has great potential to impact software project
execution positively. Software Project Success refers to the factors that contribute to customer
satisfaction on delivery of a project. Though there are many factors that customers measure for
a successful delivery, the most important explicit factors are Time, Cost and Quality.
However, there has not been much work done on investigating the impacts of Software
Process Automation on the software projects being delivered to customers.
The research is aimed at understanding how Software Process Automation initiative

was adopted in software organizations and how they have impacted the success of Project
deliveries. The primary hypothesis There is no significant contribution by Process
Automation on Software Project Success is stated to provide a focus on the objective of the
research study.
Data for the study was collected through a survey on a sample of 83 software
professionals from two Indian and two foreign software companies. The responses were
studied through distribution analysis to understand the characteristics of organizations, process
iii
characteristics, focus on the initiative, development, deployment and training methodologies

adopted. Correlation analysis attempts to understand the relation between various groups of
information gathered to finally derive a conclusion on the objective of the research.
The research has clearly brought out the facts that software process automation
adoption has positively impacted software services organizations. The various benefits are
seen in terms of quality improvement through error reduction, productivity improvement,
process compliance, reduction in mundane activities and enhanced communication. When
quality is maintained at a high level and clerical and administrative work are taken away from
the project teams, productivity is positively influenced thereby ensuring a successful delivery
of a project.
Overall, the responses confirm that adoption of Software Process Automation has been
successful in their organizations. Further the study revealed that Software Process Automation
has positively impacted Project successes in ways such as time to market, reduced cost
through improved quality and increased productivity.
iv
ACKNOWLEDGEMENT
As I look back in the journey of life, I remember with gratitude all my teachers who
have molded me in schools and colleges. What I am today is because of their teachings of
knowledge and values.
Critical Investigations on Contribution of Process Automation to Software Project
Success was a choice I made due to the immense knowledge on Quality and Process that I
acquired during my IT career. I am grateful to my employers who have given me the exposure
to Information Technology and Quality.
I owe my immense gratitude to Dr. S. Ramalingam who was kind enough to take me
under his wing and guided me till the end using his encouraging smiles and short and humor
filled advises. I also thank Dr. Sawitha Harikrishnan who helped me in my initial days of
research.
My heartfelt gratitude to Dr. J. Sekkizhar for providing me the statistical analysis with
great understanding of my research work. I thank Dr. Kennedy Thomas and Mr. Chandrasekar
for all the help. I thank my friends who backed me up during this difficult period.
Princes tireless nudging to keep me going with work and research at the same time has
made me realize what I am capable of achieving. My hectic life style would have drained me
out if not for my daughters, Andrea and Althea. Their refreshing smiles and bubbling energy
has rejuvenated my energy many a time. My love and a big thank you to my family.
My Pappa has been my dearest friend who always advised me to do what I liked best.
Gods representative in the form of Mommy has been the source of divine strength throughout
my life that sustained me through earthly challenges. She has devoted her entire life for my
well-being. Today, both are not here to share this moment of pride with me, may they have
eternal peace beside God Almighty. To them I dedicate this thesis.
Anne Martin
TABLE OF CONTENTS
LIST OF TABLES .................................................................................................................... vii
LIST OF FIGIURES ................................................................................................................. xv
LIST OF ABBREVIATIONS .................................................................................................. xix
LIST OF CORRECTIONS ....................................................................................................... xx
CHAPTER I: INTRODUCTION................................................................................................ 1
CHAPTER II: REVIEW OF LITERATURE ........................................................................... 16
CHAPTER III: RESEARCH METHODOLOGY .................................................................... 78
CHAPTER IV: ANALYSIS ..................................................................................................... 98
CHAPTER V: CONCLUSION .............................................................................................. 385
BIBLIOGRAPHY ................................................................................................................... 394
APPENDIX I - SURVEY QUESTIONNAIRE ...................................................................... 402
APPENDIX II - CURRICULAM VITAE .............................................................................. 407
vi
LIST OF TABLES
Cha
pter
III
IV
IV
IV
IV
IV
IV
IV
IV
IV
Table ID
Description
RM-01
ST-HYP-01-01
ST-HYP-01-02
ST-HYP-01-03
ST-HYP-01-04
ST-HYP-01-05
ST-HYP-01-06
ST-HYP-01-07
ST-HYP-01-08
ST-HYP-01-09
IV
ST-HYP-01-10
IV
IV
IV
ST-HYP-01-11
ST-HYP-02-01
ST-HYP-02-02
IV
ST-HYP-02-03
IV
ST-HYP-02-04-01
IV
ST-HYP-02-04-02
IV
ST-HYP-02-04-03
IV
ST-HYP-02-04-04
IV
ST-HYP-02-04-05
IV
IV
IV
IV
IV
IV
IV
ST-HYP-02-05-01
ST-HYP-02-05-02
ST-HYP-02-05-03
ST-HYP-02-05-04
ST-HYP-02-05-05
ST-HYP-02-06
ST-HYP-02-07
IV
ST-HYP-03-01
IV
ST-HYP-03-02-01
Particulars of Organizations participated in this study

Organization culture Vs Team Size
Organization culture Vs Team Leaders Experience
Organization culture Vs Respondents Experience
Organization culture Vs Team Experience
Organization culture Vs End-User Representation
Organization culture Vs External Consultants Expertise
Organization culture Vs Subcontractor Expertise
Organizational Change Vs Team Size
Organizational Change Vs End-User Representation
Organizational Change Vs External Consultants
Expertise
Organizational Change Vs Subcontractor Expertise
Organizational Change Vs Areas of Automation
Organizational Change Vs Motivating Elements
Organizational Change Vs Elapsed of Process
Automation
Organization Culture Vs Areas of Automation I
Organization Culture Vs Automation Addressed
Process Areas II
Organization Culture Vs Automation Address Process
Areas III
Process Areas IV
Process Areas V
Organization Culture Vs Motivating Elements I
Organization Culture Vs Motivating Elements II
Organization Culture Vs Motivating Elements III
Organization Culture Vs Motivating Elements IV
Organization Culture Vs Motivating Elements V
Organization Culture Vs Adequate Funding
Organization Culture Vs Process Users Involvement
Organization culture Vs Documented Process
Improvement in place
Organization culture Vs Projects routinely collect
metrics on project management data
Page
No.
86
185
186
187
188
189
190
191
191
192
193
193
195
196
197
198
199
199
200
200
204
204
205
205
205
208
209
211
212
vii
IV
ST-HYP-03-02-02
IV
ST-HYP-03-02-03
IV
ST-HYP-03-02-04
IV
ST-HYP-03-02-05
IV
ST-HYP-03-02-06
IV
ST-HYP-03-03
IV
ST-HYP-03-04
IV
ST-HYP-03-05
IV
ST-HYP-03-06
IV
ST-HYP-03-07
IV
ST-HYP-03-08
IV
IV
ST-HYP-04-01
ST-HYP-04-02
IV
ST-HYP-04-03
IV
ST-HYP-04-04
IV
ST-HYP-04-05
IV
ST-HYP-04-06
IV
ST-HYP-04-07
IV
ST-HYP-04-08
IV
ST-HYP-05-01-01
IV
ST-HYP-05-01-02
IV
ST-HYP-05-01-03
IV
ST-HYP-05-02
IV
IV
ST-HYP-05-03
ST-HYP-05-04
Organization culture Vs Projects routinely use metrics

to support process improvement
Organization culture Vs Projects routinely use
documented processes to perform their tasks
Organization culture Vs Projects routinely meet external
schedules
Organization culture Vs Projects routinely meet cost
estimates
Organization culture Vs Projects routinely provide
appropriate training on tools and methods
Organization culture Vs Organizations have any
documented processes in manual operations
Organization culture Vs Organizations used a
recognized process definition notation to define process
Organization culture Vs The process design is clearly
and completely documented
Organization culture Vs Functional requirements were
used to define tools embedded in the process
Organization culture Vs Metrics requirements are
specified for the process
Organization culture Vs Process definition was more
challenging than first thought
Development Team Size Vs Areas of Automation
Development Team Size Vs Process Users Involvement
Development Team Size Vs Elapsed days from
Initiation to Completion
Development Team Size Vs Processes currently being
automated
Development Team Size Vs Automated processes in
operation
Development Team Size Vs Automated processes
in day-to-day use
Development Team Size Vs Frequency of Tool
execution
Development Team Size Vs Stages of Deployment
Areas of Automation Vs Project Teams
Routine Activities I
Routine Activities II
Routine Activities III
Areas of Automation Vs Documented Processes in
manual operation
Areas of Automation Vs Target Process
Areas of Automation Vs Process definition was more
212
213
214
214
215
216
217
218
219
220
221
223
224
225
225
226
227
227
228
230
231
232
235
237
239
viii
IV
ST-HYP-05-05-01
IV
ST-HYP-05-05-02
IV
ST-HYP-05-05-03
IV
ST-HYP-05-06-01
IV
ST-HYP-05-06-02
IV
ST-HYP-05-06-03
IV
ST-HYP-05-06-04
IV
ST-HYP-05-06-05
IV
ST-HYP-05-06-06
IV
ST-HYP-05-06-07
IV
ST-HYP-05-06-08
IV
ST-HYP-05-06-09
IV
ST-HYP-05-06-10
IV
ST-HYP-05-07
IV
ST-HYP-05-08
IV
IV
ST-HYP-05-09
ST-HYP-05-10
IV
ST-HYP-05-11
IV
ST-HYP-05-12
IV
ST-HYP-05-13
IV
ST-HYP-05-14
IV
ST-HYP-06-01
IV
ST-HYP-06-02
IV
ST-HYP-06-03
challenging
Motivating Elements Vs Project Teams Routine
Activities I
Motivating Elements Vs Project Teams
Routine Activities II
Motivating Elements Vs Project Teams
Routine Activities III
Motivating Elements Vs Process areas addressed by
Process Automation I
Process Automation II
Process Automation III
Process Automation IV
Process Automation V
Process Automation VI
Process Automation VII
Process Automation VIII
Process Automation IX
Process Automation X
Motivating Elements Vs Target Process
Motivating Elements Vs Process definition was
challenging
Adequate funding Vs Process areas automated
Elapsed days of Automation Vs Target Process
Elapsed days of Automation Vs Process definition was
challenging
Process Automation used on day-to-day basis Vs
Automated Processes
Stages of progress in Automation Vs The target process
Stages of progress in Automation Vs Process definition
was challenging
Adequate funding for technical development Vs
Strengths of Process Automation Tool
Adequate funding for technical development Vs Other
qualities of Process Automation Tool
Automated process used on day-to-day basis Vs
241
241
242
243
244
244
245
245
246
246
247
247
248
251
252
254
255
256
257
258
260
262
263
265
ix
IV
ST-HYP-06-04
IV
ST-HYP-07-01
IV
ST-HYP-07-02
IV
ST-HYP-07-03
IV
ST-HYP-07-04
IV
ST-HYP-07-05
IV
ST-HYP-07-06
IV
ST-HYP-07-07
IV
ST-HYP-07-08
IV
ST-HYP-08-01-01
IV
ST-HYP-08-01-02
IV
ST-HYP-08-01-03
IV
ST-HYP-08-02
IV
ST-HYP-08-03
IV
ST-HYP-08-04
IV
ST-HYP-08-05
IV
ST-HYP-08-06
IV
ST-HYP-08-07
IV
ST-HYP-08-08
IV
ST-HYP-08-09
IV
ST-HYP-08-10
Automated process used on day-to-day basis Vs Other

Training provided to support Process Automation Tool
Automated Process design/development approach
Resistance to Process Automation
Management Support to Process Automation
Training provided to support Process Automation Tool
Projects routinely use documented processes to perform
their tasks Vs Strengths of Process Automation Tool
Projects routinely track and meet cost estimates Vs
Projects routinely provide appropriate training on tools
and methods Vs Strengths of Process Automation Tool
Projects routine activities Vs Defects in the automation
tool affected development
Projects routine activities Vs System crashes affected
development effort
Projects routine activities Vs Difficult to recover from
system crashes
Projects routine activities Vs The automation tool
supports a good range of hardware platforms
The process design is clearly and completely
documented Vs Strengths of Process Automation Tool
documented Vs Other qualities of Process Automation
Tool
Functional requirements were used to define tools
embedded in the process Vs Strengths of Process
Automation Tool
embedded in the process Vs Other qualities of Process
Automation Tool
Metrics requirements are specified for the process Vs
266
268
269
270
271
272
274
275
276
278
279
280
281
282
283
284
286
287
289
290
292
IV
ST-HYP-08-11
IV
ST-HYP-08-12
IV
ST-HYP-08-13
IV
ST-HYP-08-14
IV
ST-HYP-08-15
IV
ST-HYP-09-01-01
IV
ST-HYP-09-01-02
IV
ST-HYP-09-01-03
IV
ST-HYP-09-02-01
IV
ST-HYP-09-02-02
IV
ST-HYP-09-02-03
IV
ST-HYP-09-03-01
IV
ST-HYP-09-03-02
IV
ST-HYP-09-03-03
IV
ST-HYP-09-04-01
IV
ST-HYP-09-04-02
IV
ST-HYP-09-04-03
IV
ST-HYP-09-05
IV
ST-HYP-09-06
IV
ST-HYP-09-07

Other qualities of Process Automation Tool
The target process was not a prior manual process Vs
The target process was not a prior manual process Vs
Other qualities of Process Automation Tool
Process definition was more challenging than first
thought Vs Strengths of Process Automation Tool
thought Vs Other qualities of Process Automation Tool
their tasks Vs Training provided
Training provided
and methods Vs Training provided
their tasks Vs Automated Process design/development
approach
and methods Vs Automated Process
design/development approach
their tasks Vs Resistance to Process Automation
and methods Vs Resistance to Process Automation
their tasks Vs Management Support to Process
Automation
and methods Vs Management Support to Process
Automation
documented Vs Training provided
documented Vs Automated Process design/development
approach
documented Vs Resistance to Process Automation
293
295
296
298
299
301
301
302
303
304
305
306
307
307
309
309
310
311
312
313
xi
IV
ST-HYP-09-08
IV
ST-HYP-09-09
IV
ST-HYP-09-10
IV
ST-HYP-09-11
IV
ST-HYP-09-12
IV
ST-HYP-09-13
IV
ST-HYP-09-14
IV
ST-HYP-09-15
IV
ST-HYP-09-16
IV
ST-HYP-09-17
IV
ST-HYP-09-18
IV
ST-HYP-09-19
IV
ST-HYP-09-20
IV
ST-HYP-09-21
IV
ST-HYP-09-22
IV
ST-HYP-09-23
IV
ST-HYP-09-24
IV
ST-HYP-10-01-01
IV
ST-HYP-10-01-02
IV
ST-HYP-10-01-03

documented Vs Management Support to Process
Automation
embedded in the process Vs Training provided
embedded in the process Vs Automated Process
embedded in the process Vs Resistance to Process
Automation
embedded in the process Vs Management Support to
Process Automation
Training provided
The target process was no prior manual process Vs
Training provided
thought Vs Training provided
thought Vs Automated Process design/development
approach
thought Vs Resistance to Process Automation
thought Vs Management Support to Process Automation
their tasks Vs Process Automation project is a success
Process Automation project is a success
and methods Vs Process Automation project is a success
314
315
316
317
319
319
321
322
323
324
325
326
327
328
329
330
331
333
333
334
xii
IV
ST-HYP-10-02-01
IV
ST-HYP-10-02-02
IV
ST-HYP-10-02-03
IV
ST-HYP-10-03-01
IV
ST-HYP-10-03-02
IV
ST-HYP-10-03-03
IV
ST-HYP-10-04
IV
ST-HYP-10-05
IV
ST-HYP-10-06
IV
ST-HYP-10-07
IV
ST-HYP-10-08
IV
ST-HYP-10-09
IV
ST-HYP-10-10
IV
ST-HYP-10-11
IV
ST-HYP-10-12
IV
ST-HYP-10-13
IV
ST-HYP-10-14
IV
ST-HYP-10-15
IV
ST-HYP-10-16
IV
ST-HYP-10-17

their tasks Vs Process Automation outcomes
Process Automation outcomes
and methods Vs Process Automation outcomes
their tasks Vs The technical implementation was
challenging
Projects routinely track and meet cost estimates Vs The
technical implementation was challenging
and methods Vs Resistance to Process Automation
documented Vs Process Automation project is a success
documented Vs Process Automation outcomes
documented Vs The technical implementation was
challenging
embedded in the process Vs Process Automation project
is a success
embedded in the process Vs Process Automation
outcomes
embedded in the process Vs The technical
implementation was challenging
The technical implementation was challenging
The target process was no prior manual process Vs The
thought Vs Process Automation project is a success
thought Vs Process Automation outcomes
335
336
338
339
339
339
340
342
343
344
345
346
347
348
349
350
351
352
353
354
xiii
IV
ST-HYP-10-18
IV
ST-HYP-11-01
IV
ST-HYP-11-02
IV
ST-HYP-11-03
IV
ST-HYP-11-04
IV
ST-HYP-11-05
IV
ST-HYP-11-06
IV
ST-HYP-12-01
IV
ST-HYP-12-02
IV
ST-HYP-12-03
IV
ST-HYP-12-04

thought Vs The technical implementation was
challenging
Automation tool used for implementing process
automation Vs Time taken to transition the process to
the production environment
automation Vs The automation initiative came from
automation Vs Process Automation Strategy
automation Vs The process model is being implemented
Strengths of Automation tool Vs The automated process
improves the effectiveness of end-users in performing
their tasks
Defects in the automation tool affected the development
effort Vs Process Automation Development Process
Transition and adoption methods Vs To date, I consider
the process automation project to be a success
Reasons for resistance to Process Automation Vs
Time taken to transition the process to the production
environment Vs Outcomes of Process Automation
Duration the automated process has been operational Vs
Impacts of Process Automation Vs Outcomes of Process
Automation
355
356
357
358
359
360
361
364
367
370
372
xiv
LIST OF FIGIURES
Cha
pter
I
Page
No.
12
Figure ID
Description
INTRO-01
Process of Research
Software Project Success Rate CHAOS Report by The
28
Standish Group
Software Process Automation Coverage
57
Relation between Groups of information
80
Number of Respondents and their Organization Role
87
Number of respondents from each organization
99
Number of respondents from each organization
99
Number of respondents Vs Organization Strength
100
Number of respondents and their Organization Role
101
Industries supported by organizations
102
Organization type
103
Focus on Products and Services
103
IT Services provided by the organizations
104
Frequency of Organization Changes
104
Risk takers Vs Conservative Organizations
105
Formal Vs Informal Organizations
106
Organization Structure
106
Controlling Vs Hands-off Organizations
107
Static Vs Dynamic Environment
107
Complacent Vs Energetic
108
Closed minded Vs Open minded
109
Political Vs Non-political
109
Jobs are routine Vs Jobs are exciting
110
Stable staff Vs High turnover
111
Process automation development team size
111
Process automation team leader experience
112
Respondents experience
113
Process Automation Development Teams Experience
113
Representation from End-users
115
Utilization of Expertise of External Consultants
115
Utilization of Expertise of Sub-contractors
116
Areas of Process Automated
117
Motivating Elements
118
Motivating Elements
119
Adequate Funding
120
II
ROL-01
II
III
III
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
ROL-02
RM-01
RM-02
GEN-01
GEN-02
GEN-03
GEN-04
GRP-A-01
GRP-A-02
GRP-A-03
GRP-A-04
GRP-A-05
GRP-A-06-01
GRP-A-06-02
GRP-A-06-03
GRP-A-06-04
GRP-A-06-05
GRP-A-06-06
GRP-A-06-07
GRP-A-06-08
GRP-A-06-09
GRP-A-06-10
GRP-B-01
GRP-B-02
GRP-B-03
GRP-B-04
GRP-B-05
GRP-B-06
GRP-B-07
GRP-C-01
GRP-C-02-01
GRP-C-02-02
GRP-C-03
xv
IV
GRP-C-04
IV
GRP-C-05
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
GRP-C-06
GRP-C-07
GRP-C-08
GRP-C-09
GRP-C-10-01
GRP-C-10-02
GRP-C-10-03
GRP-C-10-04
GRP-C-10-05
GRP-D-01
GRP-D-02-01
GRP-D-02-02
GRP-D-02-03
GRP-D-02-04
GRP-D-02-05
GRP-D-02-06
GRP-D-03
GRP-D-04-01
GRP-D-04-02
GRP-D-04-03
GRP-D-04-04
GRP-D-04-05
GRP-D-04-06
GRP-D-04-07
GRP-D-04-08
GRP-D-04-09
GRP-D-04-10
GRP-D-04-11
GRP-D-04-12
GRP-D-04-13
GRP-D-04-14
GRP-D-04-15
GRP-D-04-16
GRP-D-04-17
GRP-D-04-18
GRP-D-04-19
GRP-D-04-20
GRP-D-04-21
GRP-D-05
GRP-D-06
GRP-D-07
Process User Involvement

Elapsed Days from Initiation to Completion of Process
Automation
Number of Process Automated
Number of Process in Operation
Day-to-Day use of Processes
Frequency of Process Execution
Automation Activities Included
Planned Additional Process Automation
Additional Processes under Development
Additional Processes being Implemented
Additional Processes Successfully Deployed
Documented Process Improvement Plan
Collection of Metrics
Use of Metrics
Use Processes to Perform Project Tasks
Use Processes to Meet External Schedules
Use Processes to Meet Cost Estimates
Provision of Training in Process Tools and Methods
Documented Automated Process in Manual Operation
Automated Process Project Initiation/Startup
Automated Process Project Planning
Automated Process Project Tracking and Oversight
Automated Process Project Closure
Automated Process Requirements Management
Automated Process Software Design
Automated Process Software Development
Automated Process Verification/Reviews
Automated Process Validation/Testing
Automated Process Defect/Anomaly Tracking
Automated Process Release Management
Automated Process Deployment
Automated Process Software Maintenance
Automated Process Hardware/Software Servicing
Automated Process Change Management
Automated Process Configuration Management
Automated Process Document Management
Automated Process Document Review
Automated Process Subcontractor Management
Automated Process Supplier Management
Automated Process Other Process Areas
Process Definition Notation
Process Definition Notations Followed
Documented Process Design
120
121
122
122
123
124
124
125
126
126
127
128
129
129
130
130
130
131
132
132
133
133
133
134
134
134
135
135
135
136
136
136
137
137
137
138
138
138
139
139
140
140
141
xvi
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
GRP-D-08
GRP-D-09
GRP-D-10-01
GRP-D-10-02
GRP-D-10-03
GRP-D-11
GRP-E-01
GRP-E-02-01
GRP-E-02-02
GRP-E-02-03
GRP-E-02-04
GRP-E-02-05
GRP-E-02-06
GRP-E-02-07
GRP-E-02-08
GRP-E-02-09
GRP-E-02-10
GRP-E-02-11
GRP-E-02-12
GRP-E-03
GRP-E-04
GRP-E-05
GRP-E-06
GRP-F-01
GRP-F-02
GRP-F-03-01
GRP-F-03-02
GRP-F-04
GRP-F-05
GRP-F-06
GRP-F-07
GRP-F-08
GRP-F-09
GRP-F-10
GRP-F-11
GRP-F-12
GRP-F-13-01
GRP-F-13-02
GRP-F-13-03
GRP-F-13-04
GRP-F-13-05
GRP-F-13-06
GRP-F-14
GRP-F-15
Use of Functional Requirements

Defined Metrics Requirements
Target Process
Target Process Documented Manual Process
Target Process Manual Process in Operation
Process Definition a Challenge
Process Automation Adoption Method
Process Development Environment
Debugging Capabilities
Integrating Application Tools
Effective End-User Interfaces
Collect Metrics
Performance
Cross-Platform Compatibilities
Customer Support
Training
Documentation
Ease of Use
Cost Effectiveness
Defects Affected Software Development
System Crashes Affected Software Development
System Crashes Affected Software Development
Process Automation Supports Hardware Platforms
Time taken for Transition to Process Automation Tool
How long is Process Automation Tool is Operational
Training the Implementers on Process Automation Tool
Training the End-Users on Process Automation Tool
Process Design developed in conjunction with End-users
Process design reviewed with End-users
End-user screens evaluated by End-users
Process simulations performed with End-users
Automated Process improves effectiveness of End-users
End-users had difficulty in accepting new process
End-users feel ownership towards the automated process
End-users make suggestions to improve automated process
Metrics used to improve automated process
Automation was externally imposed
Fear of Job Loss
Fear of Change
Process Automation is Controlling
End-users not consulted sufficiently
Metrics used in Job Evaluations
Senior Management is Supportive
First-line Management is Supportive
141
142
142
143
143
144
144
145
145
146
146
147
147
148
148
149
149
150
150
151
151
152
153
154
154
155
156
156
157
157
158
159
159
160
161
161
162
163
163
164
164
165
166
166
xvii
IV
IV
IV
IV
IV
IV
IV
IV
IV
IV
GRP-F-16
GRP-F-17
GRP-F-18
GRP-F-19
GRP-F-20
GRP-F-21
GRP-F-22
GRP-F-23
GRP-F-24
GRP-G-01
IV
GRP-G-02-01
IV
GRP-G-02-02
IV
GRP-G-02-03
IV
GRP-G-02-04
IV
GRP-G-02-05
IV
GRP-G-02-06
IV
IV
IV
IV
IV
IV
IV
IV
GRP-G-03-01
GRP-G-03-02
GRP-G-03-03
GRP-G-03-04
GRP-G-03-05
GRP-G-03-06
GRP-G-03-07
GRP-G-04
IV
GRP-G-05
IV
IV
GRP-G-06
GRP-G-07
Automation Business Plan written

Management agreed to Development Plan
Management reviewed Design
Adequate funding for Transitioning
Process Automation initiative has a Champion
Process Automation Initiative came from
Documented Transition Strategy
Prototyping Strategy used for Implementation
Implementation of Process Automation Tool
Process Automation initiative is a success
Process Automation tool helps to improve end-user
productivity
Process Automation tool helps to improve product quality
Process Automation tool helps to manage projects more
effectively
Process Automation tool helps to improve communication
between end-users
Process Automation tool helps to improve end-user job
satisfaction
Process Automation tool helps to improve end-user team
building
Process Automation tool helps reduce tedium
Process Automation tool helps prevent errors
Process Automation tool supports administrative efforts
Process Automation tool provides useful process guidance
Process Automation tool provides timely status information
Process Automation tool provides useful metrics data
Process Automation reduce costs
Automation helped to enforce defined process
Implementation of Process Automation tool was
challenging
The Process Automation met planned schedule
Plans on automating additional processes in future
167
168
168
169
170
170
171
171
172
173
174
174
175
176
176
177
178
178
179
180
180
181
181
182
183
183
184
xviii
LIST OF ABBREVIATIONS
3D
Three Dimensional
ANOVA
ANalysis Of VAriance
CMMi
Capability Maturity Model integrated
DMAIC
Define, Measure, Analyze, Improve and Control
DMADV
Define, Measure, Analyze, Design and Verify
IEEE
Institute of Electrical and Electronics Engineers
ISO
International Organization for Standardization
IT
Information Technology
MAS
Multi-Agent Systems
MNC
Multi-National Company
PMP
Project Management Professional
PMI
Project Management Institute
PMBOK
Project Management Book Of Knowledge
PRINCE2
PRojects IN Controlled Environments 2
HR
Human Resource
ROI
Return On Investment
SEI
Software Engineering Institute
SEPG
Software Engineering Process Group
TQM
Total Quality Management
CSDP
Certified Software Development Professionals
US
United States
xix
LIST OF CORRECTIONS
S.No.
1
Page
60
71
75
Corrections Suggested
i. The references in Section
2.5 may be chronologically
rearranged and
ii. their styles (author name
conventions) may be made
consistent
However, the starting
paragraph of Section 2.6.1
may be made less dramatic,
befitting for a thesis, and not
sound like a magazine feature
article
(a) The research methodology
elaborated in Chapter 3, needs
to put forth a copy of the
questionnaire.
(b) It needs to be shown how
the i. independent variables,
ii. Dependent variables and
iii. Background variables,
have been addressed in the
questionnaire.
(c) A breakdown of the
respondents in the hierarchy
of the corresponding
organizations also needs to be
included (c.f. Section 3.3.3
and 4.2.1)
83, 174 The thesis needs to establish

correlation between the items
presented in Section 4.2.2 and
the variables as mentioned in
Chapter 3. Otherwise, one
might get the idea that the
discussion in this section
appears only as page fillers
Page
64
Corrections carried out

i. Section 2.5 is chronologically
arranged
ii. Author name conventions
made consistent
75
The first paragraph in Section

2.6.1 is rewritten
89
a) Section 3.3.5 added to include

the questionnaire
89
b) The first paragraph of Section

3.3.5 maps the Questionnaire to
the variables
87,99
c) Figure RM-02: Number of

Respondents and Organization
Role in Section 3.3.3 and
Figure GEN-04: Number of
respondents and their
Organization Role in Section
4.2.1. included to provide the
hierarchical breakdown of
respondents
94,184 The reason for having Section
4.2.2 (Distribution Analysis of
Responses) is mentioned in
Section 3.3.6 (Statistical
Analysis of Data). Also in
Section 4.3 (Correlation
Analysis) the Distribution
analysis tables are cross
xx
referenced in each of the

analysis.
xxi
CHAPTER I: INTRODUCTION
1.1
BACKGROUND OF THE RESEARCH................................................................. 2
1.2
RESEARCH PROBLEM AND HYPOTHESIS ...................................................... 6
1.3
JUSTIFICATION FOR THE RESEARCH ............................................................. 9
1.4
METHODOLOGY ................................................................................................ 12
1.5
OUTLINE OF THE THESIS ................................................................................. 13
1.6
DEFINITIONS ....................................................................................................... 14
1.7
DELIMITATIONS OF THE SCOPE .................................................................... 15
Software Industry, the largest segment of the IT industry has grown to be a major
contributor to the worlds technological boom. Many software organizations that had just
data store capabilities are now offering business solutions through software. With high
expectations from the world of customers, software organizations looked for various
means to deliver quality and cost-effective solutions. One of the methodologies they
adopted was Process Automation though the impact it had on their business was never
studied. Moreover, there are very few research papers, books and articles published on
this subject area. Hence, the researcher felt the imperative need to investigate in detail the
relation between software process automation and software project success. There have
been many limitations such as the openness to share information, location constraints,
etc. but the researcher has made best efforts to collect information and correlate between
the two areas of Process Automation and Project Success.
CHAPTER I
INTRODUCTION
1.1 BACKGROUND OF THE RESEARCH
Information technology (IT) is a broad subject which deals with technology and
other aspects of managing and processing information, especially in large organizations.
Particularly, IT deals with the use of electronic computers, computer software,
internet/intranet and telecommunication systems to collect, convert, store, protect,
process, transmit, and retrieve information in text, audio or video forms. Over the past 20
years, its prevalence has dramatically increased so that it is now a part of nearly every
aspect of daily life and brought in some fundamental changes to how we live, how we
work, how we communicate, how we travel and even how we relax.
Technology is a word originated from Greek words tecne and logica, where
tecne means skill and logica means study of science. Technology is the human
innovation that involves generation of knowledge and processes gathered for the
development of new systems to help in solving practical problems and extending human
capabilities. Technology is becoming popular due to its multi-faceted advantages. Firstly,
technology makes work easier. For example, washing machines has made the activity of
washing clothes simple and easy. Secondly, technology has help in conducting certain
activities faster and obtaining quick results. For example, mixers and grinders have
helped in getting part of cooking faster with desired results. Also, technology has
provided quick results in photography and communication transmission. Technology has
also been greatly used in channeling creativity into reality. For example, animation and
3D has brought in a new dimension to film making.
Information is the collection of facts through various means of communication

and plays a vital role in drawing a logical conclusion. Information can also be considered
as a critical tool for human development. Information also helps in determining how to
use technology to learn the research process and enhance problem solving skills.
2
Information can be categorized into deterministic, probabilistic and quantum information.

Sources of information could be people, news papers, television, etc. Any useful
information should be accurate, timely, complete, precise and relevant. Information
broadly is required for decision making, communication, accumulating knowledge,
improving efficiency and productivity.
Today, the term information technology has ballooned to encompass many

aspects of computing and technology, and the term is more recognizable than ever before.
The information technology umbrella can be quite large, covering many fields. IT
professionals perform a variety of duties that range from installing applications to
designing complex computer networks and information databases. A few of the duties
that IT professionals perform may include data management, networking, engineering
computer hardware, database and software design, as well as the management and
administration of entire systems. When computer and communications technologies are
combined, the result is information technology. Information Technology is a general term
that describes any technology that helps to produce, manipulate, store, communicate or
disseminate information.
Information Technology plays a vital role in various fields. In business

environment, IT has greatly influenced competitiveness through E-business, security
through safe and secure storage of vast confidential information, cost through automating
routine tasks thereby reducing manpower in administration and supply chain management
and marketing through internet advertising, faster product launches and faster service. In
the field of manufacturing, simulation systems are used for virtually design plants,
measure material usage and assess ergonomic factors before decision making and also
robotics to conduct mundane and repeatable activities in the shop floor such as simple
welding. Mobile computing is a field that has leveraged highly on IT and has spread its
own use in many other fields such as emergency services, stock information control,
credit card verification and e-mail. In the world of media, IT has impacted in two
powerful areas, entertainment and social awareness. Multi-media applications are widely
used in the area of entertainment. Information Technology has become a powerful tool
for communication, problem solving and as a means of research for learning in education
area. It has helped learners to develop problem solving, analytical and research skills.
E-learning has helped a wide range of students to go through relevant course material that
is collected, collated and made available through subscription. E-mail has helped in
sending and receiving valuable information between two or more cohesive people. News
groups is a forum created electronically where information can be shared among people
with common interest. Web-casts are used to broadcast seminars and classes over a
electronic communication media so like-minded people view, learn and benefit from it.
Internet and intranet are used to store a set of information that can be accessible to a
group of people or to entire public based on the kind of information.. Above all,
technology has greatly benefited the field of medicine where use of high end machines
and software are used for diagnosis, treatments and complicated surgeries.
Information Technology comprises hardware that consists of physical components

that form a computer system or any other electronic gadget, software that is a set of
instructions in the form of a program which when executed control the sequence of a set
of tasks, data or raw information which is the unprocessed collection of facts for the
purpose of communication, interpretation and processing by human or automatic means
and people who perform various functions by utilizing the processed information
collected by a combination of hardware and software.
Software development and sustenance is an activity that involves high stakes.

While a successful outcome brings good revenue and more business to stakeholders, a
failed attempt could cause them heavy losses. However, there are many factors that
influence and challenge every single step of a project. Hence, Companies in software
business adopt various measures to make sure the software projects are delivered
successfully. Significant few are Onsite-Offshore models, billing methods, project
management processes, quality assurance practices and automation. Also, companies
have adopted such measures in variations such as the levels of implementation, timelines,
depths and breadths of coverage and so on.
One very important initiative taken by Software companies is Software Process

Automation. Higher Management has believed that this initiative will ensure costeffective software to be delivered to customers on time. However, not all companies have
gone about implementing this initiative in a uniform manner. The reasons are again due
to variations in the client profile, business types, quality processes, etc.
Software Process Automation in the present study refers to automating the various
Software Engineering Processes that projects are expected to comply with to ensure
successful delivery of the project to end customers. The processes and policies are
defined by an organization by either adopting one or more industry standard process
models such as ISO-9001, SEI-CMMI, etc. Some of processes that are commonly set are
Requirements Management, Project Planning, Monitoring and Control, Configuration
Management, Test Management, Release Management and Change Management. These
processes over the years have become quite elaborate and expect heavy manual paper
work to prove compliance and for further analysis and improvement. So, to overcome
these mundane lifeless activities and at the same time to be able to comply with process
policies as prescribed by the organization, automating the same processes were initiated
in most organizations.
Software Project Success in the present study refers to the factors that contribute
to customer satisfaction on delivery of a project. Though there are many factors that
customers measure for a successful delivery, the most important explicit factors are Time,
Cost and Quality. Time factor refers to two types one in terms of the on-time delivery
of the project by the software organization to its customer and other in terms of time-tomarket which refers to how the software will provide quick services to customers end
customers. Cost factor is measured again in terms of the cost spent on this project by the
customer and also cost saved or revenue earned by the customer in implementing the
delivered software project. Quality factor refers to the quality of service given by the
software organization to its customer which may be quality of software, quality of
communication, quality of documents, quality of presentations, etc. In this research, the
factors considered are all those that not only impact customers but also has a major
impact on the software organization such as Time of project delivery, Cost of the project
spent by customer and Quality of the project deliverables.
In this particular research work, the author attempts to gain insights into various
process automation factors that define a project and factors that influence project
successes. Also, the research focuses on the factors that influence the software process
automation adoption methods and finally culminate the two to exhibit a picture of how
Process Automation has contributed to Project success. In the following sections below,
various aspects of Software Project Success and Software Process Automation are
discussed to understand how they are interlinked.
1.2 RESEARCH PROBLEM AND HYPOTHESIS
1.2.1
Research Problem
When Computers were first invented, it was primarily used as a number

crunching machine. Technological advancements led to using computers to do large
mathematical computations on data and storing them for further multiple use. Further,
with the invention of client-server technology, multi-site data capture and centralized data
store and computations became possible. With the Internet boom, the concept of data
entry was shelved and online data capture and online processing became the latest
technological trend. Introduced thereafter were the concepts Business Process
Automation and Knowledge Process Automation. These two areas have captured almost
all industries worldwide since these adoptions reached out to the customers at their
homes and work places and even in coffee shops.
From the time computers were invented, there was always an underlying process
defined for every activity that was performed on the computer. With upgrades in the use
of computers, the processes also become more stringent and complex. While Software
industry is too busy selling Business Process Automation and Knowledge Process
Automation solutions, a few software companies started proactively developing software
to automate software processes. However, this activity was only to enhance internal
quality and productivity and hence was not given much importance. Then came along
Capability Maturity Model that set the rules of Quality and Process to a much higher
level. The 5th stage of Process maturity evaluates the organizations ability to rapidly
respond to changes and opportunities and enhanced by finding ways to accelerate and
share learning. Improvement of processes became part of every employees role,
resulting in cyclic, continual improvement. Process Change Management, one of the key
process areas accentuated the need for Process automation.
Eventually, Software organizations adopted various methodologies to implement

Process Automation but did not look back to think how positively or otherwise the impact
of it in their business. Thus, there is not much research done on this subject. There are
also not much discussed on this subject.
1.2.2
Hypothesis
PRIMARY HYPOTHESIS:
The primary NULL Hypothesis is:
There
is
no
significant
contribution by Process Automation on Software Project Success.
SECONDARY HYPOTHESIS:
The secondary hypotheses are defined relative to the primary hypothesis and
the various factors that influence Software Process Automation and Software
Project Success. These will be statistically defined based on seven groups of
information listed below that are gathered during research, analyzed for relationship
and influence amongst them and may be proved or disproved by the statistical
analysis conducted.
A.
B.
C.
D.
E.
F.
G.
Business/Product Characteristics of the Organization

Implementation Team Characteristics
Application Focus
Process Characteristics
The Development Technology
Transition and Adoption
Impacts and Insights
HYPOTHESIS I: A. Business/Product Characteristics has no significant influence on

B. Implementation team characteristics
HYPOTHESIS II: A. Business/Product Characteristics has no significant influence on
C. Application focus
HYPOTHESIS III: A. Business/Product Characteristics has no significant influence on
D. Process characteristics
HYPOTHESIS IV: B. Implementation team characteristics has no significant influence
on C. Application focus
HYPOTHESIS V: C. Application focus has no significant influence on D. Process
characteristics
HYPOTHESIS VI: C. Application focus has no significant influence on E. The
development technology
HYPOTHESIS VII: C. Application focus has no significant influence on F. Transition
and adoption
HYPOTHESIS VIII: D. Process characteristics has no significant influence on E. The

HYPOTHESIS IX: D. Process characteristics has no significant influence on F.
Transition and adoption
HYPOTHESIS X: D. Process characteristics has no significant influence on G. Impacts
and Insights
HYPOTHESIS XI: E. The development technology has no significant influence on F.
HYPOTHESIS XII: F. Transition and adoption has no significant influence on G.
1.3 JUSTIFICATION FOR THE RESEARCH
1.3.1
Need for the Study

The IT revolution has led to various practices all over the world. The growth has
been phenomenal and fast. Innovation and Creativity in using the appropriate process
automation adoption strategy is crucial for the success of an organization. The presence
of many consultant firms and web sites has confused the software organizations in
selecting the appropriate process automation strategies. Hence, an exclusive model
needed to be developed to select or develop an appropriate process automation practice to
suit their specific needs and also meet the challenges faced by software organizations in
the global market.
The researcher has been involved in the exercise of Process Automation for a very
large Software Organization and has spent close to 3 years in designing, developing and
implementing Process Automation. During this period, the researcher has understood that
there are many factors that play an important role in making decisions with respect to the
adoption of Process Automation Methodology. Moreover, the researcher also observed
that there is mixed feelings about implementing Process Automation. While there were
some who welcomed this initiative and believed that it improves business, there were also
some who felt that it is an overhead and does not positively contribute to success of
project delivery.
Thus the researcher felt an imperative need to investigate how process automation
has contributed to success of software projects in the global industry of Information
Technology. In accordance with the base objective, the researcher attempts to study the
various factors that are interlinked with Software Process Automation and also how they
ultimately influence the Project Success.
The purpose of this research is to investigate in detail the relation between
software process automation and software project success. It is also the intention of the
researcher to find out whether there are differences if any in the way Indian and nonIndian software organizations adopt various software process automation methodologies.
In addition, the researcher strives to find out whether there are relationships if any
between different modes of automation namely Commercially Off The Shelf and Inhouse developed and different approaches taken by organization in adopting the
software process automation methodologies. Similarly, the study also attempts to find
out how software process automation impacts various dimensions of Software project
success namely Time, Cost and Quality.
1.3.2
Objectives of the Study
To study and analyze Process Automation in Software Industry in light of emerging

globalized competitive environment
To identify the key objectives for the selected Process Automation Practices
To identify the factors for Project Success
To categorize the identified Process Automation practices according to software
project types
To draw the relationship between Process Automation practices and the factors of
Project Success
To Assess the influence of Process automation Strategies in Execution Excellence
On the basis of the defined objectives, descriptive information on different issues
in implementing software process automation and its impact on success of projects that
are being delivered in various companies in India and abroad were studied. While
presenting such datasheet to achieve the objective knowledge gaining in several quality
practices that were changing over the last 35 years and the data for companies abroad
based on the experience over the last 20 years have influenced the structure for this
thesis.
Software Process and Process Automation in
Software Services Organizations
A
10
Success rates of Software Projects delivered

by Software Services Organizations
Literature
Review
(books,
journals,
internet,
publications
Need for Investigation on the impact of

Software Process Automation on Success of
Software Delivery
Researchers
background
and
experience
Evolution of Research Concept
Identification of Software Process

Automation Adoption practices
Data analysis
from 17
Organizations
Validation of Research Concept
Arriving at practices, objectives, types and

disciplines
Development of Pilot questionnaire for

development of Comprehensive questionnaire
Administration of Pilot questionnaire
Finalizing Objectives
Design and development of Comprehensive

questionnaire
B
11
Administration of Comprehensive
questionnaire to 7 Organizations
Analysis and Investigation of 83 responses

from 4 Organizations
Derivation of Inferences from Analysis and

Investigation Results
Formation of Summary and Conclusion

Figure INTRO-01: Process of Research
Software Process Automation technology helps to manage software projects by
driving the sequence of phases and activities that comprises the project, managing the
work products or outputs that are being developed or managed, integrating with tools that
developers require to do their tasks, collecting and collating metric data automatically,
flashing warnings when project progress is deviating, triggering automatic actions that do
not need human intervention, providing a workflow based approach to allow
communication between the persons who are building the product, reducing human
errors, and providing project management with timely, accurate status information to
project teams and management. Software Process Automation is adopted by
organizations that clearly understand that such initiatives are needed to improve
productivity and quality.
1.4 METHODOLOGY
Four Software organizations were approached and data was collected through
interviewing technique. 83 employees from these organizations responded to the
questionnaire. Based on the primary hypothesis, the independent variable was defined as
12
Software Process Automation and the dependent variable as Software Project Success.
Different types of statistical techniques such as Quantitative analysis, Correlation
analysis, Chi-square analysis, etc. were appropriately used to derive statistical outcomes
that support the hypothesis.
1.5 OUTLINE OF THE THESIS
Chapter I
Background of the Research This first chapter provides an
introduction to the present study. It details the Background of the study, Research
Problem and Hypotheses, Justification of the Research, Methodology, Outline of Thesis,
Definitions, Scope of the study and Limitations of the study.
Chapter II
Review of Literature This chapter details the various literature
that the researcher drew information from to form the basis of this research work. This
chapter deals with the review of literature available in the field of process automation
software project success. Being a new area in the IT field, there are very few literature
available that provide practical and real time information. However, there are few papers
and articles published that portray the growth of this concept during the last decade.
These will be very useful to understand the above research topic.
Chapter III
Research Methodology This chapter describes the approach and
the conceptual framework used for this research and various methodologies used for
collection, analysis and representation of information. The sampling, designing
questionnaire and analysis methodology are discussed here.
Chapter IV
Analysis of Data The outcomes of the analysis conducted on the
data collected for the purpose of this research are detailed in this chapter.
Chapter V
Conclusions The inferences based on the analysis results,
summary of the research study, the final conclusion, suggestions and recommendations
for further research and are explained in this chapter.
13
1.6 DEFINITIONS
Software - software is a general term that describes computer programs. Related

terms such as software programs, applications, scripts, and instruction sets all fall
under the category of software. Software consists of lines of code written by
computer programmers that have been compiled into a computer program. Software
programs are stored as binary data that is copied to a computer's hard drive, when it is
installed. Since software is virtual and does not take up any physical space, it is much
easier to upgrade than computer hardware.
Process It is a sequence of interdependent and linked procedures which, at every

stage, consume one or more resources (employee time, energy, machines, money) to
convert inputs (data, material, parts, etc.) into outputs. These outputs then serve as
inputs for the next stage until a known goal or end result is reached.
Automation It is the technique, method, or system of operating or controlling a

process by highly automatic means, as by electronic devices, reducing human
intervention to a minimum.
Quality A measure of excellence or a state of being free from defects, deficiencies,

and significant variations, brought about by the strict and consistent adherence to
measurable and verifiable standards to achieve uniformity of output that satisfies
specific customer or user requirements. ISO standard defines quality as "the totality
of features and characteristics of a product or service that bears its ability to satisfy
stated or implied needs."
Onsite A place where an organization is registered or located and where the activity
concerned is conducted accomplished or operated.
Offshore A place where an activity is conducted accomplished or operated in a

foreign country.
14
1.7 DELIMITATIONS OF THE SCOPE
1.7.1
Scope of the Study
This particular research is done to find out what kind of software services
organizations have embraced this concept of Software Process Automation and to what
extent have they adopted its principles and the impact such adoption had in delivering
software projects. For this purpose, software services organizations were approached to
gather data. Two Indian and two foreign based software services organizations were
specifically considered and a survey on a sample of 83 software professionals spread over
these four organizations were conducted. The scope has a clear boundary in terms of
automation only in relation to software development and the target audience was selected
based on the practices adopted to implement process automation.
1.7.2
Period of the Study
This research was conducted over a period of 3 years starting in 2005. Initially a
small scale preliminary study was conducted to test the design of research and improve
the same to ensure feasibility of the full scale research and making it a success.
1.7.3
Limitations of the Study
Data collection was a challenging task. Software services organizations normally do

not have large groups working on this area. Moreover, this function is a specialized
function in any organization that maintains high level of confidentiality. Hence,
though many questionnaires were distributed, not all were returned.
Information Technology is one industry that is fast changing. In such scenarios, data
collected 2-3 years before could have undergone changes too. This research could not
review and incorporate all changes.
15
Though the questionnaire was administered to process groups of two Indian and two
foreign organizations, the respondents were all residents of India.
CHAPTER II: REVIEW OF LITERATURE
2.1
INTRODUCTION ................................................................................................. 18
2.2
SOFTWARE PROJECT SUCCESS ...................................................................... 18
2.3
LITERATURE ON SOFTWARE PROJECT SUCCESS ..................................... 48
2.4
SOFTWARE PROCESS AUTOMATION ........................................................... 54
2.5
LITERATURE ON SOFTWARE PROCESS AUTOMATION ........................... 64
2.6
RESEARCH GAP IN AVAILABLE LITERATURE ........................................... 75
2.7
CONCLUSION ...................................................................................................... 76
Various research and studies conducted in the field of Information

Technology which is relevant to this particular research work has been organized around
three areas namely, (i). Software Project Success factors, (ii). Experiences and Success
stories of Software Process Automation and issues faced by Software Services
Organizations and (iii). Association of Software Process Automation Adoption directly
on the success of software services delivered to customers. Experience tells that there is a
close association between Process Automation and Project Success. It is also known that
there are many external and internal factors that influence both Process Automation and
Project Success. It is noted during the preliminary study, that very limited literature is
available on the areas of Software Process Automation, Software Project Success and
various internal and external factors influencing them. Therefore, the researcher
identified this specific topic of identifying the extent of association and supporting and
inhibiting factors of each area namely Software Process Automation and Software Project
Success.
16
17
CHAPTER II
REVIEW OF LITERATURE
2.1 INTRODUCTION
For the purpose of the present study, the following key concepts have been
extracted from the focus area of research and the review of relevant literature is organized
around them. (i). Software Project Success factors, (ii). Experiences and Success stories
of Software Process Automation and issues faced by Software Services Organizations
and (iii). Association of Software Process Automation Adoption directly on the success
of software services delivered to customers (Alan M. Christie, et.al., 1997). The scope
and trends of research on Software Process Automation is handled in a general way
examining the extent of research done in this area in the past few years in India and
abroad. It is also the intention of the researcher to investigate various processes that have
been automated with focus on process improvement and project success. In such a pursuit
the relationship between Software Process Automation and Software Project Success
with which it has been explored have also been considered.
2.2 SOFTWARE PROJECT SUCCESS
2.2.1
Software
Software is a generic term for organized collection of computer data and
instructions. It is responsible for controlling, integrating and managing the hardware

components of a computer and to accomplish specific tasks. In other words, software tells
the computer what to do and how to do it. For example, software instructs the hardware
what to display on the users screen, what kinds of input to take from user, and what
kinds of output to generate. Thus, software communicates with the hardware by
organizing the control sequences, and the hardware carries out instructions defined by the
software. A computer needs to be instructed to perform any task. These instructions are
given in the form of computer programs, which are written in computer programming
languages. A program controls activity of the processor. The moment the hardware acts
18
as per the instructions of a program, the program is said to be in running or executing

state.
A set of programs which are specifically written to provide the user a precise
functionality like solving a specific problem is termed as a software package (Ashok M.
Kamthane, 2007). For example, word processing software package functionality to the
computer so that it can be used to create documents like letters and mailing lists.
Similarly, an image processing software assists a user in drawing and manipulating
graphics.
Software can be categorized as system software and application software.
System software is a generic form for referring to any computer program whose purpose
is to help the user to run the computer system, whereas application software employs the
capabilities of a computer directly to a task that the user wishes to perform.
2.2.2
Software Projects
In general, a project may be termed as a temporary process which has a
clearly defined start and end time, a set of tasks and a budget that is developed to solve a
well defined goal or objective. Project Management Institute's widely disseminated A
Guide to the Project Management Body of Knowledge defines Project as A project is a
temporary endeavor undertaken to create a unique product or service. James P. Lewis, a
writer and Project Manager, whose excellent book The Project Manager's Desk Reference
we will also rely on heavily throughout this course:
A project is a one-time, multitask job that has clearly defined starting and
ending dates, a specific scope of work to be performed, a budget, and a specified level of
performance to be achieved. Following are the main characteristics of a project.
Objectives A project has a fixed set of objectives. Once the objectives have
been achieved, the project is deemed finished.
Life span A project cannot continue endlessly. It has to come to an end.
19
Single entity A project is one entity and is normally entrusted to one

responsibility center while the participants in the project may be many.
Team work A project calls for work the team again is constituted of
members belonging to different disciplines, organizations and even countries.
Life cycle A project has a life cycle reflected by growth, maturity and decay.
It has naturally, a learning component.
Uniqueness No two projects are exactly similar even if the plants are exactly
identical or are merely duplicated. The location, the infrastructure, the
agencies and the people make each project different from the other.
Change A project sees many changes throughout its life. While some of
these changes may not have any major impact, there can be some changes
which will change the entire character of the project.
Successive principle What is going to happen during the life cycle of a

project is not fully known at any stage. The details get finalized successively
with the passage of time. More is known about a project when it enters the
construction phase than what was known, say, during the detailed engineering
phase.
Made to order A project is always made to the order of its customer. The
customer stipulates various requirements and puts constraints within which
the project must be executed.
Unit in diversity A project is a complex set of varieties. The varieties are in

terms of technology, equipment and materials, machinery and people work
culture and ethics. But they remain interrelated and unless this is so, they
either do not belong to the project or will never allow the project to be
completed.
High level of sub-contracting A high percentage of the work in a project is

done through contractors. The more the complexity of the project, the more
will be the extent of contracting. Normally, around eighty percent of the work
in a project is done through sub-contractors.
Element of risk and uncertainty Every project is associated with risk and
uncertainty. The degree of risk and uncertainty will depend on how a project
20
has passed through its various life cycle phases. An ill defined project will
have high degree of risk and uncertainty.
A project usually is driven by factors such as type, billing, schedule, location,
technology, size, scope and speed. Based on these factors, projects are categorized into
various types. Recognition of this distinction is important for management of any project.
2.2.2.1 Type of Service
Software projects are planned and executed based on the type of service that
these are aimed at delivering.
Development
Conversion/Migration
Integration
Product Implementation
Testing
Maintenance
Service
Hybrid
Development - Development projects are those that produce a software

directly for a business. Such projects provide custom software that customers access,
automation of procedures that take place within the company, or software to handle
monetary transactions securely. These development projects have many phases that may
include Requirements engineering, Architecting, Designing, Coding, Testing and
Deploying.
Conversion/Migration - Software migration is the process of moving from
the use of one operating environment to another operating environment to comply with
the changing business needs and technological advancements. Migration can involve
moving to new hardware, new software, or both. One can migrate data from one kind of
database to another kind of database. Since the new database may be organized
21
differently, it may be necessary to write a program that can process the migrating files.
The new software being developed to help migrate environments is usually termed
software conversion. The conversion or migration project can be small-scale, such as
migrating/converting a single system, or large-scale, involving many systems, new
applications, or a redesigned network.
Integration - This type of project generates software called Interfaces that
truly interface with a variety of applications be it third party or in-house developed to
import, export or synchronize data.
Product Implementation - It can refer to a service group that works on
configuring existing software that it produces to a companys needs and specifications. In
such cases, the standard software is made to be highly configurable, and working with the
client to understand particular needs and make all necessary adjustments are part of the
service package. There are many software products today which can be bought off-theshelf and customized to suit the companys business requirements. Some well known
products are SAP, Siebel and Peoplesoft.
Testing - A project exclusively executed to check whether the actual results
match the expected results and to ensure that the software system is defect free is a
Testing project. It includes a set of activities conducted with the intent of finding errors in
software so that it could be corrected before the product is released to the end users.
Because software bugs could be expensive or even dangerous, many clients conduct
independent testing projects, maybe even outsource to another software service provider,
to make sure that the software is of absolute quality.
Maintenance - After a software product has been deployed in the real life
environment, this Maintenance project keeps it up to date with environment changes and
changing user requirements. There are four difference types of activities involved in a
maintenance project. Corrective maintenance deals with fixing bugs in the code.
Adaptive maintenance deals with adapting the software to new environments. Perfective
maintenance deals with updating the software according to changes in user requirements.
22
Preventive maintenance deals with updating the documentation and making the software
better maintainable.
Service - Once software is developed and deployed, the software is
maintained by either the customer or the software service provider. In addition, there are
other maintenance activities such as data fixing, job scheduling, job cycle monitoring,
backups and archives, etc. which are quite regular in nature and some are even periodic
activities. These kinds of requests are called service requests and are contracted as
separate project under the category Service.
Hybrid - Hybrid projects are a combination of two or more of the above
mentioned projects. These projects are extremely difficult to execute and manage.
Usually, software organizations split these into smaller units of projects and execute
them. However, for want of a larger contract, some organizations do take it as one whole
project but execute them into small sub-projects and integrate them.
2.2.2.2 Type of Billing
Projects are categorized into mainly three types based on the billing models.
Fixed Price
Time and Material
Hybrid
Fixed Price - Fixed Price projects are those projects that are awarded to a
software organization on a fixed rate which is based on the estimate provided by both
customer and software organization and mutually agreed upon by them. In such an
agreement, the customer is only involved in providing the requirements and in final
testing to ensure that the software meets the requirements. The software organization has
complete control of the project starting from deciding where to execute to usage of
various resources for the project execution. Thus, it is the responsibility of this software
organization to ensure that the cost of this project does not exceed the price fixed by
utilizing the optimum resources and increasing the profitability without compromising on
23
the quality and time. If it fails to do so, usually the software organization bears the loss
incurred. However, in most cases, when initially the requirements of the projects are not
well defined, there is high likelihood of more requirements being added or removed or
modified which is called scope creep. In such cases, the fixed price of the project is
reevaluated and amended accordingly by both the customer and the software
organization. Sometimes, not so often, software organizations do not conduct a
requirements gathering activity that results in a bad estimate. Also, in some cases, the
software organization consumes all cost due to various reasons such as inappropriate use
hardware/software resources, wrong choice of project execution location, not employing
the right skilled people of may be even overloading the team with more or high skilled
people. In both these cases, the software organization has to bear the losses and may even
be charged a penalty. If a project under this model is executed within the stipulated cost
budget, then it is a win-win situation for both customer and the software service
organization. Projects of type development, conversion/migration, Integration, Product
Implementation and Testing are usually executed in this model.
Time and Material - Time and Material is another model of pricing in which
first a rough estimate of work that is expected to flow in is evaluated and the team size is
estimated. The customer continues to pay this cost and is responsible to create demands
so that the entire team is fully utilized. The reason is that the customer has no definite
requirements that a Software service organization can execute as one big project. Projects
of maintenance, service, hybrid nature follow this pricing model where maintenance
requests, service requests are created by customer and the project teams deliver them.
Hybrid - Hybrid is a combination of fixed price model and the time and
material model and is also called a flex model. Herein, a part of the team is fixed to cater
to ongoing request flows and is paid on time and material model. In addition, whenever
the customer has a larger requirement, the software organization immediately ramps up a
sizable team to cater to this requirement and is charges a fixed price. This team is
retained if there is any other large requirement in pipeline, otherwise it is ramped down.
The advantage in this model is that the customer does not have to pay for a large team
when there is consistent flow of requirements and still gets a team at short notice when
24
the need arises. On the other hand, the software organization also need not block a large
highly skilled technical team with no work. Projects mostly of hybrid nature and very
large maintenance and services projects follow this pricing model.
2.2.2.3 Types of Schedule
Software service projects vary in size and nature and hence cannot be
executed in one single standard manner. What constitutes to how a project execution
model is the kind of involvement that the client has throughout the project life cycle.
Thus, there are two distinct types of project execution model as follows:
Milestone driven projects
Fixed period projects
Milestone driven projects - A point in time representing a key or important

intermediate event in the life of a project is a milestone. A milestone should be capable of
validation by meeting all of the items prescribed in a defining checklist as agreed with the
stakeholders. For example, a requirements gathering phase requires a validation by the
clients and end-users (if necessary) for its completeness and hence it is a major milestone.
Similarly, design, coding and unit testing, system testing are important phases where we
need the sign-off from client team before proceeding to the next level.
Fixed period projects - These projects are drawn as contract for a specific
period of time such as one year or two years. These contracts renewed periodically and
may also change in nature, team size etc. marginally. Usually maintenance and service
projects are executed under this type.
2.2.2.4 Types of Location
With various stakeholders involved such as Project team, Clients, End-users,
Sub-contractors, Top management, etc., a project was executed with different options of
locations as follows and hence, projects were executed later development happened at
offshore, while client involving activities such as requirements gathering, system testing
25
were happening at onsite. Today, projects are executed at multiple sites with control of
various activities are also handled at these sites.
Onsite
Offshore
Multi-site/Co-located
Onsite - Projects were traditionally executed at one site and most often at the
customer site. This meant the entire project team travels to the customer site and work in
their environment. The advantages of this model are 1) The client is close and hence the
client is involved more closely and is able to give feedback much earlier to avoid rework.
2) Testing is done at clients environment and hence it is easier to find any compatibility
issues and resolve them at the earliest. The disadvantage is that cost of travel and living
expenses to be born by client is quite high and this is in addition to the project cost.
Offshore - Offshore projects are those where the entire project development
and test activities happen at offshore or offsite. Except for a couple of senior project team
members and an onsite coordinator, everyone else works from offshore. Here the cost is
reduced but the challenge are two fold 1) there are usually delays in client reviews and
feedback 2) the live environment may not be same as development environment and
hence there might some problems of software compatibility towards user acceptance
testing which is costlier to resolve at that stage.
Multi-site/Co-located - Teams from different locations work closely
throughout all the life cycle phases as peers. With the use of sophisticated communication
tools and maturity of the teams on the system, all the remote site teams work in
disciplined and structured way for the successful implementation of the project.
2.2.3
Software Project Success

In todays world, software projects are becoming more and more complex
in size, sophistication and technologies used. Now most software products cater to
26
multiple clients, millions of users, support different national languages and come in
different sizes and shapes desktop, standard, professional, enterprise and so on.
Success of a Software Project is measured by the famous triple constraints.
These constraints are measured from the customer perspective since customer is the one
who should sign-off stating the project closure as successful or otherwise (Baccarini D,
1999). These triple constraints are:
Time
Cost
Quality
Time - From the customer perspective, the word time has many meanings:
(1) Time span of a project life cycle: the date that the software service organization
delivered a project that is completely tested and certified to be used by the customer end
users. This time frame is clearly a measurement for the software company. (2) Time to
market: Time span of software from its concept inception to the stage where the customer
reaps returns out of implementing this software. This particular aspect is very critical for
a Customer who has a larger business goal in mind and software to support this goal is
only a portion that enables quicker results. Hence, customers while drawing up an
engagement with a software company to develop, implement or maintain software, they
particularly emphasize on the time to delivery. Some customers even draw up clauses for
penalty in case of late delivery of projects. Thus, this time frame is a measurement for the
Customer.
Cost - Cost is another major factor that influences the status of a project
namely success or failure. Cost also can be defined in two ways: 1) From the software
companys perspective, cost of Human effort, Resources (Facility, Hardware, Software,
Tools), Miscellaneous (Travel, Accommodation), etc. would comprise the various costs
involved. (2) From the customers perspective, cost is much bigger. It involves their
effort in reviewing software development progress, Resources for implementation
27
(Facility, Hardware, Software, Tools), Training personnel to use the software,

implementation costs, etc.
Quality - Quality, unlike Time and Cost, is just one definition for both the
software company and its customer. A Complete (all requirements met), Bug-free, High
Performance, Reliable, Stable, Scalable Product is Quality. Quality sometimes is
misconstrued as just a bug-free product but rising competition has encouraged customers
to demand for more than just a bug-free software. Customers today expect software
companies to understand the business need, draw out a software plan, develop,
implement and sustain till the customer obtains return-on-investment. There is also a
another dimension to cost cost of poor quality means if the software is impaired, then
cost of repairing it and bringing it back to usable shape. This cost is very critical and
never budgeted for. Hence, it is imperative that both the Customer and the Software
company consciously strives to reduce this cost.
Even though, a project is always measured for success through these three
factors, it is clearly noticed that Time and Quality are also finally measured as costs.
Thus, Cost Reigns Supreme. The world is now aware that cost is primary and needs to be
controlled. Customers together with their Software service partners strive to manage
project costs to minimum. They shrink project budgets thus forcing teams to become
highly efficient. Increased accountability and transparency are demanded by customers,
management, and governments. Leveraging the best resource, with the right skills, at the
right time, is a must though challenging.
Overall, a project is said to be succeeding if delivered on time, on budget,
with required features and functions" says Jim Johnson, chairman of The Standish Group.
In 2009, a study conducted by The Standish Group says only 32% of software projects
have succeeded. Out of the remaining, 44% were challenged which are late, over budget,
or with less than the required features and functions and 24% failed which are cancelled
prior to completion or delivered and never used. In the year 2004, 29% of software
projects succeeded, 53% were challenged 18% have failed.
28
Figure ROL-01: Software Project Success Rate CHAOS Report by

Standish Group
The reasons for increase in success percentage is found to be higher customer
involvement, management support and requirements clarity. These are achieved through
effective application of following methodologies.
Project Management is a methodology which is not only adopted by software
industry but almost all large industries in the world. Project Management methodology
adoptions help the organizations to plan, execute, monitor each and every step of a
project. It provides visibility to all levels of personnel in the organization thus enabling
rapid review and quick reactions to outcomes during the entire life cycle of the project.
PMP and Prince2 are two well known methodologies widely used by Software
organizations. Project Management thereby covers the entire project life cycle through
Planning, Executing, Controlling and Closing stages to ensure quality delivery on time
with less expense.
PMP - The Project Management Institute (PMI) offers a guideline to plan,
execute, monitor and measure a project from its inception to its delivery. PMP is more a
set of raw building blocks from which practitioners can develop their own methodology.
PMI has developed a Project Management Body of Knowledge (PMBOK), a guide which
presents a set of standard terminology and guidelines for project management (Rita
Mulcahy, 2000). It acts as a reference manual for project management, and includes a
description of many concepts and terms used in the field. The PMBOK is organized on
five process groups and nine knowledge areas. The process groups are:
29
Initiating Processes authoring the project or phase
Planning Processes: defining/refining objectives.
Executing Processes: carrying out project activities.
Controlling Processes: ensuring the project is on track.
Closing Processes: formally ending the project or a phase.
The nine knowledge areas are:
Integration Management: the processes used to effectively coordinate

the various aspects and layers of the project.
Scope Management: the processes that focus on the work that needs
to be done to achieve the project goal(s).
Time Management: the processes that ensure the project is completed

on schedule.
Cost Management: the processes that ensure the project does not
deviate and exceed from its budget.
Quality Management: the processes that ensure the project satisfies

the need that it is based upon, as well as satisfies customer
requirements and fitness for use.
HR Management: the processes that make effective use of the people

involved in the project.
Communications Management: the processes that create the relevant

creation, organizing, sharing, storing, and disposition of project
information.
Risk Management: the processes that identify, analyze, and manage

project risk.
Procurement Management: the processes that enable the acquisition

of goods and services from outside the project staff in order to
support the project goals.
30
It can be seen that these nine management processes are neither linear nor
logical; one does not finish up with integration management, and then move on to scope
management.
Prince2 PRojects IN Controlled Environments 2 (PRINCE2) is a structured
project management method endorsed by the UK government as the project management
standard for public projects (Colin Bentley, et. Al, OGC, 2002). The methodology
encompasses the management, control and organization of a project. PRINCE2 is based
on seven principles namely continued business justification, learn from experience,
defined roles and responsibilities, manage by stages, manage by exception, focus on
products and tailored to suit the project environment and seven themes namely business
case, organization, quality, plans, risk, change and progress. These principles and themes
come into play in the seven processes:
Starting up a project
Initiating a project
Directing a project
Controlling a stage
Managing stage boundaries
Managing product delivery and
Closing a project
Prince2 method works with most project management techniques but

specifically describes the Product based planning, Change Control Technique and Quality
Review Technique.
Agile Software development methodology is a recent innovative adaptive
approach to project management. It is people oriented rather than process oriented and
some of its characteristics are collaborative approach, frequent testing, frequent delivery
and provides good return-on-investment for client. Scrum is an iterative and incremental
agile software development method for managing software projects and product or
application development.
31
There are many more methodologies such as PRiSM, ITIL and IPMA but
they are not widely used.
Quality Management is a very important approach understanding precisely
what the customer needs and consistently delivering accurate software solutions on time
with less cost. Quality Management thus goes in parallel to Project management and is
considered to have four main components namely quality planning, quality control,
quality assurance and quality process improvement. Therefore Quality management uses
quality assurance and control of processes to achieve more consistent quality. Thus
Quality Management and Project Management methodologies run parallel to each
through the life cycle of a project to ensure success of a project and product delivery.
ISO International Organization for Standardization, particularly ISO 9000
is an international quality management system standard a standard used to assess an
organizations management approach regarding quality. Its focus is directed internally at
an organizations processes and methods and externally at managing the quality of
products and services delivered. It is a generic international standard, adopted on a
country-to-country basis, and written for use by the widest possible audience. As a result,
the standards define what needs to be done but does not specify how to do it. Hence, ISO
does not offer details about its application but provides a series of guidelines to assist in
the application of standards specific to domains. ISO 9000-3 is an international guideline
for software development, supply and maintenance environments. These set down certain
policies that are governed by various procedures, guidelines, methods and tools designed
and developed by software organizations. The various policies covered under major
threads are:
Management Responsibility
Quality Policy that describes the organizations attitude towards quality
Organization Structure that is required to manage the quality system
Management Review Procedure for senior management to review the

effectiveness of the quality system
Quality System
32
Quality System developed in general and a manual that describes and guides
the user to adopt it.
Quality System Procedures that are consistent with the Quality Policy
Quality Planning to show how the organization intends to fulfill the quality
system requirements.
Contract Review
Procedures to coordinate the review of sales orders and customer contracts
Review Procedures to ensure that all contractual requirements are acceptable
Procedures to specify how contracts are amended and these amendments are
communicated to relevant groups in the organization
Record Keeping System to record the review of customer orders and contracts
Software Development and Design
Procedures to control the product design and development process. These

procedures must ensure that all requirements are met
Design and Development Planning Procedures to ensure the design and

development plan is prepared, documented clearly, reviewed and approved
before it is implemented
Organizational and Technical Interfaces to be identified and ensure that their

design inputs are properly documented, circulated and reviewed
Design Procedures to ensure that all design input requirements are identified,
documented and reviewed and all design flaws, ambiguities, contradictions
and deficiencies are resolved.
Procedures to control design outputs thereby ensuring correctness and

completeness.
Procedures to ensure design reviews are properly planned and performed
Procedures to ensure verification of design outputs at every stage of product

design and development process. Design outputs are accepted for use in
subsequence phases only if proper review is conducted and remedial actions
have been conducted
Procedures to validate the developed products to ensure that they meet the
customer needs
33
Procedures to ensure all design changes are documented, reviewed and

formally authorized and then circulated for implementation
Document and Data Control
Procedures to control all the documents and data related to the defined quality
system
Procedures to review, approve and manage all the documents and data related
to the defined quality system
Procedures to control changes to all the documents and data related to the
defined quality system
Purchasing Requirements
Procedures to ensure that the purchased products meet all the requirements
Procedures to select, evaluate, monitor and control the sub-contractors
Procedures to ensure that the Purchase Orders clearly describe what exactly
needs to be bought
Procedures to allow verification for acceptability of the products that were

bought
Customer Supplied Products
Procedures to control and protect the products supplied by Customers
Product Identification and Tracing
Procedures to identify and track products from start to finish through

Configuration management processes
Process Control Requirements
Procedures to plan, monitor and control production, control and servicing

processes
Product Inspection and Testing
Procedures to inspect, test and verify that the developed product meets all
specified requirements
Procedures to ensure that incoming products are not used until they are
verified to meet all specified requirements
Procedures to ensure that work in progress meets all specified requirements

before work is allowed to continue
34
Procedures to ensure that the finished product meets all specified requirements
before it is made available for sale
Control of Inspection Equipment
Procedures to control, calibrate and maintain inspection, measuring and test

equipment used to test the finished product for conformance to requirements
Procedures to ensure that the Inspection Equipment is appropriate, accurate

and secure
Inspection and Test Status of Products
Procedures to control the inspection status of products by documenting and

circulating to relevant groups in the organization
Control of Nonconforming Products
Procedures to ensure that the nonconforming products are identified,

evaluated and segregated to make sure that they are not inappropriate used.
Procedures to control how the nonconforming products are reviewed,

reworked, re-graded, retested, recorded, and discussed with the customers.
Corrective and Preventive Action
Procedures to correct and prevent nonconformities and use Configuration

Management Procedures to document and control corrective and preventive
actions that affect the development life cycle process
Procedures to ensure that nonconformities are identified, investigated,

recorded and corrective actions implemented without delay
Procedures to ensure that routine inspections are conducted to identify

potential nonconformities and preventive actions are implemented
Handling, Storage and Delivery
Procedures to handle, store, package, preserve, and deliver finished products
Procedures to identify handling methods to prevent product damage or

deterioration
Procedures to identify secure storage areas, storage, removal and protect the
products
Procedures to pack, package and mark the finished products to protect and
control the quality of finished product
35
Procedures to protect and preserve the product quality prior to delivery
Procedures to ensure that the finished product is verified before delivery,

protect quality of product and presever during delivery
Control of Quality Records
Procedures to develop and control a Quality Record System
Internal Quality Audit Requirements
Procedures of audit for determining whether quality activities and results

comply with quality plans, procedures and programs. Procedures to also
evaluate performance of the quality system and effectiveness of corrective and
preventive actions
Training Requirements
Procedures for Quality training to ensure that the training needs are identified,
trainings planned and conducted and training records are maintained
Servicing Requirements
Procedures to ensure product service processes are documented, service

activities are reported and quality of product service is verified
Statistical Techniques
Procedures to select appropriate statistical techniques to establish, control and

verify process capabilities and product characteristics
Procedures to explain these techniques should be used, monitor and records

are maintained
CMMi Capability Maturity Model Integration is a process approach to that
provides software companies with essential elements of effective processes which will
measure its maturity and improve their performance. CMMi is the result of 20 years of
ongoing effort put in by the SEI (Software Engineering Institute) which also includes
members from the industry and the government. Therefore CMMi is a model comprising
best practices of various organizations that help the entire industry to improve
effectiveness, efficiency and quality. CMMi for development is a model that is used by
software companies to develop and deliver successful software projects. CMMi focuses
36
strongly on process maturity of an organization. Mature processes are considered to be

well defined, repeatable, measured, analyzed and improved.
This CMMi model is a staged representation with five maturity levels. Each
maturity level consists of a predefined set of process areas. Each level is measured by the
achievement of generic and specific goals that apply to each predefined set of process
areas.
Maturity Level 1 - Initial: Organizations in maturity level 1 have processes
that are usually ad-hoc and chaotic. These organizations do not provide a stable
environment and hence success of projects depends on competence of people and not on
the use of proven processes. In effect, there are no predefined key process areas in
Maturity level 1.
Maturity Level 2 Managed: Maturity level 2 covers basic project
management where projects are planned, performed, measured and controlled.
Organizations have achieved all the generic and specific goals of level 2 process areas.
The various key process areas well managed in this level are Requirements Management,
Project Planning, Project Monitoring and Control, Supplier Agreement Management,
Measurement Analysis, Process and Product Quality Assurance and Configuration
Management. At this stage, the status of development or delivery of services are visible
to management at defined points. The stakeholders establish and commits to their role in
successful delivery. Various steps of the projects are periodically reviewed with
stakeholders and controlled.
Maturity Level 3 Defined: Maturity level 3 namely Defined covers
process standardization. At this stage, the organizations in addition to achieving the goals
of Maturity level 2, strive to achieve goals generic and specific to Maturity level 3. Here,
processes are understood, characterized and formulated into standards, procedures, tools
and methods. The various key process areas that define the goals of Maturity level 3 are
Requirements Development, Technical Solution, Product Integration, Verification,
Validation,
Organization
Process
Focus,
Organizational
Process
Definition,
37
Organizational Training, Integrated Project Management, Risk Management, Decision

Analysis and Resolution, Integrated Teaming, Organizational Environment for
Integration and Integrated Supplier Management. In Maturity Level 3, the processes are
described in detail, managed more proactively and followed rigorously.
Maturity Level 4 Quantitatively Managed: At this stage, organizations
define sub-processes that significantly contribute to overall process performance. These
selected sub-processes are controlled using statistical and other quantitative techniques.
Quantitative goals for quality and process performance are established and used as
criteria in managing processes. They are based on the needs of the customer, end users,
software organization and process implementers. For the key processes defined in this
level, detailed measures of process performance are collected and statistically analyzed.
These statistical measures are incorporated into the organizations performance
measurement repository to support fact-based decision making in future. The two key
processes areas are Organizational Process Performance and Quantitative Project
Management. While Maturity Level 3 is qualitatively predictable, Maturity Level 4 is
quantitatively predictable and thus any anomalies are caught earlier and corrected to
prevent further occurrences.
Maturity Level 5 Optimizing: In this final stage, the organization focuses
on continually improving process performance through both incremental and innovative
technological improvements. Optimizing processes that are agile and innovative depends
on the participation of an empowered workforce aligned with the business values and
objectives of the organization. The organizations ability to rapidly respond to changes
and opportunities is enhanced by finding ways to accelerate and share learning.
Improvement of processes is inherently part of every employees role, resulting in cyclic,
continual improvement (Rajesh Sharma, 2001). The key process areas Defect Prevention,
Technology Change Management and Process Change Management.
To summarize, CMMi based process improvement benefits include improved
schedule and budget predictability, improved cycle time, improved productivity,
improved quality, increased customer satisfaction, improved employee morale, increased
38
return on investment and decreased cost of quality (CMMI, 1991). Reuters in their study
have published assertion statements on the impact of CMM process improvement
initiatives on project success factors:
Time - Schedule variance improved from approximately 25 percent to 15

percent as the organization moved from CMM maturity level 3 to CMMI
maturity level 5
Cost (Return on Investment) -
Over 3:1 ROI due to post release defect
reduction as the organization moved from CMM maturity level 3 to CMMI

maturity level 5. Over 2.5:1 ROI from process automation estimated at CMMI
maturity level 5
Quality - Over 110 percent improvement in effectiveness of phase

containment as the organization moved from CMM maturity level 3 to CMMI
maturity level 5
Total Quality Management (TQM) is a management philosophy that seeks to
integrate all organizational functions (marketing, finance, design, engineering,

production, customer service, etc.) to focus on meeting customer needs and
organizational objectives.
TQM is a blend of technologies focused on four concepts: defect prevention,
continuous improvement, focusing on the customer and a philosophy that quality is not
just the responsibility of an organizations Quality Assurance department, but, rather, it is
a responsibility shared by all. TQM reverses our fixation on inspecting to detect defects,
and focuses on practices that identify potential defects to prevent them from occurring.
TQM instills a philosophy emphasizing a continuous search for improvement and
implementing actions to convert improvement opportunities to reality. TQM emphasizes
knowing your customers, both internal and external, and focusing on satisfying their
needs and expectations. And finally, TQM helps us all recognize we are responsible for
our work, not someone else who will check it after we are done (Joseph, Susan Brek,
1995).
39
TQM is a management approach that originated in the 1950s and has

steadily become more popular since the early 1980s. It is a description of the culture,
attitude and organization of a company that strives to provide customers with products
and services that satisfy their needs. The culture requires quality in all aspects of the
companys operations, with processes being done right the first time and defects and
waste eradicated from operations.
TQM is a method by which management and employees can become
involved in the continuous improvement of the production of goods and services. It is a
combination of quality and management tools aimed at increasing business and reducing
losses due to wasteful practices.
TQM is considered as Quality Foundation for activities that include meeting
customer requirements, reducing developing cycle times, just-in-time, demand flow
manufacturing, improvement teams, reducing product and service costs and improving
administrative systems training. There are ten distinct steps involved in TQM as follows:
Pursue new strategic thinking
Know your customers
Set true customer requirements
Concentrate on prevention, not correction
Reduce waste
Pursue a continuous improvement strategy
Use structured methodology for process improvement
Reduce variation
Use a balanced approach
Apply to all function

TQM works on the following principles that encompass the quality
perspective of the entire business:
Quality can and must be managed
40
Everyone has a customer is a supplier
Processes, not people are the problem
Every employee is responsible for quality
Problems must be prevented, not just fixed
Quality must be measured
Quality improvements must be continuous
Quality standard is defect free
Goals are based on requirements, not negotiated
Life cycle costs, not front end costs
Management must be involved and lead
Plan and organize for quality improvement
TQM process improvement and problem solving sequence is a simple

methodology that is designed in just four steps namely Plan, Do, Check and
Act. These four steps are detailed as below:
Plan
Define the problem
Recognize that what you are doing is a process
Identify the commodity being processed
Define some measurable characteristics of value to the commodity
Describe the process
Identify the big problem
Identify possible causes
Brainstorm what is causing the problem
Determine what past data shows
Evaluate possible causes
Determine the relationship between cause and effect
Determine what the process is doing now
Do (Conduct)
Make change
Determine what change would help
41
Check
Test the change
Determine what change worked
Act
Take permanent action
Ensure the fix is embedded in the process and that the resulting process is
used
Continue to monitor the process to ensure the problem is fixed for good and
the process is good enough
This sequence of acts is cyclic in nature and this process is used for
continuous improvement.
A buzzword phrase of the 1980s, TQM has been killed and resurrected on a
number of occasions. The concept and principles, though simple seem to be creeping
back into existence in bits and pieces through the evolution of ISO, Six Sigma, Lean, etc.
Six Sigma at many organizations simply means a measure of quality that
strives for near perfection. Six Sigma is a disciplined, data-driven approach for
eliminating defects in any process from manufacturing to transactional and from
product to service. Six sigma points out the total number of defects that has come across
in an organizational performance. Any type of defects, apart from the customer
specification, is considered as the defect, according to Six Sigma. With the help of
statistical representation, it is easy to find out how a process is performing quantitatively.
A defect according to Six Sigma is nonconformity of the product or service of an
organization.
Since the fundamental aim of the Six Sigma is the application of the
improvement on the specified process, through a measurement based strategy, Six Sigma
is considered as the registered service mark. Six Sigma has its own rules and
methodologies to be applied. In order to achieve this mark, the process should not
produce more than 3.4 defects per million opportunities. In order to attain the
42
fundamental objectives of Six Sigma, there are Six Sigma methodologies to be

implemented. Two major methodologies are the Six Sigma DMAIC and the Six Sigma
DMADV. The Six Sigma DMAIC process Define, Measure, Analyze, Improve and
Control is an improvement system for existing processes falling below specification
and looking for incremental improvement. The Six Sigma DMADV Define, Measure,
Analyze, Design and Verify is an improvement system used to develop new processes
or products at Six Sigma Quality levels.
The Six Sigma ensures the quality control, total quality and zero defects.
Through the implementation of the Six Sigma it is made sure that the goals are set on the
improvement of all processes to reach the level of better quality. Six Sigma shows the
organizations highly capable processing ability in producing the outputs within the
limited specifications. Therefore, it can be said that the processes that operates with the
Six Sigma quality, is able to produce a quality product at a low rate of defects. When a
process attains the certification of Six Sigma quality, it is clear that the organization has
attained the standard deviations from the means of the production till the specific
limitations, and so can make sure that there is no room for the items to fail to meet the
specifications.
LEAN operating principles began in manufacturing environments and are
known by a variety of synonyms; Lean manufacturing, Lean production, Toyota
production system, etc. It is commonly believed that Lean started by Toyota in Japan, but
Henry Ford has been using parts of Lean as early as the 1920s. Lean is defined as a
systematic approach to identifying and eliminating waste through continuous
improvement, flowing the product at the pull of the customer in pursuit of perfection.
The waste mentioned about is commonly referred to as non-value-added activities and
are segregated into eight types. They are:
Overproduction
Waiting
Transportation
Non-value-added processing
43
Excess inventory
Defects
Excess motion
Underutilized resources
Lean Manufacturing comprises fourteen principles defined and implemented
in Toyota (Jeffrey K. Liker, 2004):
Base your management decisions on a long term philosophy, even at the

expense of short-term financial goals.
Create continuous process flow to bring problems to the surface.
Use pull systems to avoid overproduction.
Level out the workload (heijunka).
Build a culture of stopping to fix the problems, to get the quality right the fist
time.
Standardized tasks are the foundation for continuous improvement and

employee empowerment.
Use visual control so no problem is hidden.
Use only reliable, thoroughly tested technology that serves your people and
processes.
Grow leaders who thoroughly understand the work, live the philosophy and
teach it to others.
Develop exceptional people and teams who follow your companys

philosophy.
Respect your extended network of partners and suppliers, by challenging them

and helping them improve.
Go and see for yourself to thoroughly understand the situation (genchi

genbutsu).
Make decisions slowly by consensus, thoroughly considering all options;

implement decisions rapidly.
44
Become a learning organization through relentless reflection (hansei) and

continuous improvement (kaizen).
Lean Software Development is a translation of lean manufacturing and lean
IT principles and practices to the software development domain. The term Lean
Software Development originated in a book by the same name written by Mary
Poppendieck and Tom Poppendieck. Lean development can be summarized by seven
principles namely:
Eliminate Waste Everything not adding value to the customer is considered

to be waste (muda). This is explained earlier.
Amplify learning The best approach for improving a software development

environment is to amplify learning. The learning process is sped by usage of
short iteration cycles, each one coupled with refactoring and integration
testing. Increasing feedback via short feedback sessions with customers helps
when determining the current phase of development and adjusting efforts for
future improvements. During these sessions, customer and the development
team learn more about the domain problem and figure out possible solutions
for further development.
Decide as late as possible As software development is always associated

with some uncertainty, better results should be achieved with an option-based
approach, delaying decisions as much as possible until they can be made
based on facts and not on uncertain assumptions and predictions. The iterative
approach promotes this principle, the ability to adapt to changes and correct
mistakes, which might be costly if discovered after the release of the software.
Deliver as fast as possible In the age of rapid technology evolution, it is not

the biggest that survives but the fastest. The sooner the software is delivered
without defects, the sooner feedback can be obtained and incorporated into the
next iteration. The shorter the iterations, better the learning and
communication within the team. Quick delivery assures fulfilling customers
present needs and this gives them the opportunity to delay making up their
45
minds about what they really require until they gain better knowledge.
Customers today value rapid delivery of a quality product.
Empower the team People might be resources from the point of view of
team head count, but in software development, people do need something
more than just the list of tasks and the assurance that they will not be
disturbed during the completion of the tasks. People need motivation and a
higher purpose to work for, purpose within the reachable reality, with the
assurance the team might choose its own commitments. The developers
should be given access to customers, more importantly the end users to
understand the true needs. The organization should provide the freedom to the
team to voice their ideas, opinions and concerns and even solutions. After all,
the team is formed by a set of very highly skilled dynamic professionals!
Build integrity in The customer should have an overall visibility of the

software project. This is so called perceived integrity how it is being
advertised, delivered, deployed, accessed, how intuitive its use is, price and
how well it solves problems. The information flow should be constant in both
directions, from customer to developers and back, thereby avoiding the large
stressful wait for information after long development time in isolation.
See the whole Best is result if the software development projects are seen as
part of the larger business initiative. It helps to understand the greater the
importance of the puzzle piece that is being developed as software, in order to
produce a business solution with smoothly interacting components.
Lean software development uses a few practices or tools such as Value
Stream Mapping, Pull Systems, Queuing Theory, Scrum, Kanban, 5S, Visual Controls
and Concurrent Engineering.
Lean software development has benefited in three ways namely operational,
administrative and strategic improvements. Lean is becoming the next quality or
eBusiness practice area. Lean organizations are able to be more responsive to market
trends, deliver products and services faster and provide products and services less
expensively than their non-linear counterparts. Lean crosses all industry boundaries,
46
addresses all organizational functions and impacts the entire system supply chain to
customer base.
Process Automation can be thought of as supplementing manual procedures
with automatically controlled alternatives. This happens through the orchestration and
integration of technology and human assets to form streamlined processes. These
processes enable one to choreograph the activities between people, applications and
external services. This choreography of processes and tasks through process automation
gives one the power to see all of these items as common elements in the overall process
flow. With that, the process itself will be significantly improved, typically in terms of
decreasing overall process cycle time while significantly improving process quality in
various aspects, be it reducing costs or better resource assignments, management
visibility or other quality aspects varying from organization to organization.
A software organization takes up Process Automation initiative on a broad
scale to cover their business processes or their software development processes. In
software development, the scope of process automation comprises Project Management
processes and Quality Management processes as discussed above. The various processes
that are automated are:
Automation of Project Activities
Initiating
Planning
Executing
Controlling
Closing
Automation of Quality Activities
Requirements
Design
Development
Verification
Validation
47
Testing
Releasing
Deploying
Maintaining
Servicing
Change management
Configuration management
Tracking and Measuring Performance
Metrics
Causal analysis\
Corrective/preventive actions
Follow-up
Feedback for Continuous performance
Other Methodologies
TQM methods
Six Sigma methods
Lean Principles
2.3 LITERATURE ON SOFTWARE PROJECT SUCCESS

Belassi, W. and Tukel , O. (1996) have published a paper that provides us
with a new framework to determine critical success/failure factors in software projects.
Only a few studies in the project management literature concentrate on the critical factors
that affect project success or failure. Whereas many of these studies generate lists of
critical success factors, each list varies in its scope and purpose. The success factors are
usually listed as either very general factors or very specific factors affecting only a
particular project. However, lacking a comprehensive list makes it difficult not only for
project managers but also for researchers to evaluate projects based on these factors. In
this study, we suggest a new scheme that classifies the critical factors, and describes the
impacts of these factors on project performance. Emphasis is given to the grouping of
success factors and explaining the interaction between them, rather than the identification
48
of individual factors. An empirical study is conducted to test the practicality of using

such a scheme. The statistical analyses of the results demonstrate the differences between
the critical success factors identified in a previous study from literature and the factors
identified with the use of our scheme. Many critical factors, such as factors related to
project managers' performance, factors related to team members and environmental
factors, became apparent with this study. The results are encouraging, in that practitioners
support the use of this scheme for determining and analysing critical success factors and
how systems respond to these factors.
Westhuizen, D. and Fitzgerald, E. P. (1997) in their paper Defining and
measuring project success, have analyzed the related concepts of software project
success, software project management success and software project product success and
proposes a set of dimensions for defining and measuring software project success. An
extension of the DeLone and Mclean (1992, p. 87) model is proposed as a base model for
software project success. Even though this investigation is only a first step in defining
project success, it is expected to be of interest to both Information System and Project
Management researchers and practitioners.
Baccarini, D. (1999) has extensively studied and has derived a logical
framework for defining process success. He considers the definition of project success as
it relates to project management. Importance of clear objectives for the team assigned to a
particular project. Project success is a core concept of project management but its
definition remains elusive. The project team must have a clear understanding of their
project success objectives. This paper uses the logical framework method (LFM) as a
foundation for defining project success. Using LFM, four levels of project objectives are
identified: goal, purpose, output, and input. It is proposed that project success consists of
two components-product success and project management success. Product success deals
with goal and purpose; project management success deals with outputs and inputs.
Gupta, U. G. and Raval, V. (1999), have studied what critical factors
contribute to executing software projects successfully at Offshore. Outsourcing,
according to them is more of an art than a science. Their paper acknowledges complex
49
consideration in choosing offshore outsourcing option. Effectively, they have found nine
roadblocks to outsource a project which means that a project can be executed at offsite
with direct supervision. They are unclear requirements, poor definition of test
environment, lack of effective communication, poor understanding of development
methodologies or tools (suggest client train the vendor and enforce its use), lack of
consensus on evaluation tools and methodologies (what does success mean?), confusion
about cost estimates (negotiate based on offshore programming costs), lack of sensitivity
to country and corporate culture (make or break), short term focus (argues for partnership
rather than market view), unrealistic expectations of offshore personnel . While these
may seem quite alarming, are also a good number of key success factors that help. They
are excellent communication, partnerships not just contracts, cost is not everything,
independence and accountability (avoid micro-management), recognize the human
element (HR issues, culture), management (project management), continuous learning soft skills key more so than hard skills (they say culture makes or breaks).
Reel, J. S. (1999) has published an excellent paper on Critical success
factors in software projects in the IEEE Software Journal. Over the years, much effort
has been directed on how to ensure the success of software projects. Despite this, the
ability to successfully, consistently move from idea to product has not improved a bit.
This report details the five essential factors to managing a successful software project:
start on the right foot; maintain momentum; track progress; make smart decisions; and
institutionalize post-mortem analyses.
Procaccino, J. D., Verner, J. M., Overmyer, S. P. and Darter, M. E.
(2002), have prepared an exclusive case study on factors for early prediction of software
development success. Project managers can make more effective and efficient project
adjustments if they detect project high-risk elements early. We analyzed 42 software
development projects in order to investigate some early risk factors and their effect on
software project success. Developers in our organization found the most important factors
for project success to be: (1) the presence of a committed sponsor and (2) the level of
confidence that the customers and users have in the project manager and development
50
team. However, several other software project factors, which are generally recognized as
important, were not considered important by our respondents.
Kendra, K. and Taplin, L. J. (2004) have taken up many case studies to
basically understand the dynamics of international project groups by grasping the
strategies project leaders set up to cope with cultural diversity. Three kinds of crosscultural practices emerged from the comparative study of European project groups: (1) to
draw upon individual tolerance and self-control, (2) to enter into a trial-and-error process
coupled with relationship development and (3) to capitalize on transnational corporate or
professional cultures. An alternative method to enhance the functioning of cross-cultural
projects is also suggested. It consists in the construction of cross-cultural patterns based
upon a structured examination of the cultural sense-making processes of project
members. Their paper concludes on the necessarily culture bound approaches of crosscultural management in transnational project groups.
Amberg, M and Wiener, M. (2005), as part of a research-in-progress
project, published a paper on Towards a Model for Critical Success Factors in Offshore
Development Projects A Grounded Theory Approach. This paper describes a researchin-progress project that aims to provide an understanding of the critical success factors of
offshore software development projects. This reveals new knowledge around influencing
factors for the successful implementation of offshore development projects, hereby
addressing the viewpoint of German clients.
Gottschalk, P. and Solli-Sther, H. (2005). Their research paper , Critical
success factors from IT outsourcing theories: an empirical study, aims to identify and
rank critical issues in IT outsourcing relationships. Design/methodology/approach - A
total of 11 management theories were applied in this research theory of core
competencies, resource-based theory, neo-classical economic theory, transaction cost
theory, contractual theory, agency theory, partnership and alliance theory, relational
exchange theory, stakeholder theory, social exchange theory and theory of firm
boundaries. The main method used is case studies and survey. Case studies were
conducted in three IT outsourcing relationships. Findings - Core competence
51
management and stakeholder management were found to be the most critical success
factors. Future research should focus on one or two theories, explicitly laying out
expectations with respect to the theories, and organizing rich data to test expectations.
Originality/value - This paper demonstrates that a holistic approach to IT outsourcing is
needed that recognizes and emphasizes the combination of several critical success
factors. The theory-based factors have both divergent and convergent implications for
management.
Karlsen, J.T., Andersen, J., Birkely, L. S. and Odegard, E. (2006), in
their empirical research, aim at studying the most critical success factors in Information
Technology (IT) projects. Several studies show that many IT projects have difficulties
meeting their performance goals. This paper reviews the literature and presents
significant contributions to the discussion of what factors play an important role in
achieving successful IT projects. Results from a survey in Norway on IT projects show
that the five most important success factors are: 1 top management support 2 end-user
involvement 3 a clear project goal 4 good communication and feedback from involved
parties 5 clear responsibilities. Copyright 2006 Inderscience Enterprises Ltd.
Chow, T. and Cao, D. (2008) have taken up an exclusive study on agile
software projects and analyzed what are the critical success factors that lead to executing
them successfully. While software is so important for all facets of the modern world,
software development itself is not a perfect process. Agile software engineering methods
have recently emerged as a new and different way of developing software as compared to
the traditional methodologies. However, their success has mostly been anecdotal, and
research in this subject is still scant in the academic circles. This research study was a
survey study on the critical success factors of Agile software development projects using
quantitative approach. Based on existing literature, a preliminary list of potential critical
success factors of Agile projects were identified and compiled. Subsequently, reliability
analysis and factor analysis were conducted to consolidate this preliminary list into a
final set of 12 possible critical success factors for each of the four project success
categories Quality, Scope, Time, and Cost. A survey was conducted among Agile
professionals, gathering survey data from 109 Agile projects from 25 countries across the
52
world. Multiple regression techniques were used, both at the full regression model and at
the optimized regression model via the stepwise screening procedure. The results
revealed that only 10 out of 48 hypotheses were supported, identifying three critical
success factors for Agile software development projects: (a) Delivery Strategy, (b) Agile
Software Engineering Techniques, and (c) Team Capability. Limitations of the study are
discussed together with interpretations for practitioners. To ensure success of their
projects, managers are urged to focus on choosing a high-caliber team, practicing Agile
engineering techniques and following Agile-style delivery strategy.
Standish Group, (2009), in its CHAOS Summary 2009" reports a
downward trend in project success rates with more project failures compared to previous
years. The Standish Group is a Massachusetts-based consultancy responsible for
publishing the CHAOS reports since 1994. The reports are based on studies of IT projects
and track the success, challenged and failure outcomes of each project by looking at:
project budgets, project costs, expected functionality delivered and other CHAOS IT
Project Factors.
Nasir, M. H. N. and Sahibuddin, S. (2011), in their published paper, bring
out a comparative study of the various factors that influence a software project to its
success or failure. Although there have been studies completed on the critical success
factors of software projects, these studies all have been specific to one particular country.
There has been no comprehensive study reporting on different project sizes in various
domains and in multiple countries. In this article, they have presented an extensive
literature survey of critical success factors that impact software projects. Forty-three
articles from the years 1990 to 2010 were found to be significant contributions that could
be analyzed in order to develop a list of critical factors that specifically affect the success
of software projects. The method of content analysis and frequency analysis was adopted.
Twenty-six critical success factors were found to be related to software project success.
They now suggest that organization or project manager is attentive to control the top five
critical factors to drive towards project success since the percentage of frequency of
occurrences for each is more than 50%. Also, it appears that non-technical factors (94%)
dominated over technical factors (6%). In a result unique to their study compared with
53
previous one, it was found that the factors of clear and frozen requirements, realistic
estimation of the schedule and budget, along with a competent project manager are the
five most critical success factors of software projects.
2.4 SOFTWARE PROCESS AUTOMATION
2.4.1
Quality
The quality of software is highly influenced by the quality of a process used
to acquire, develop and maintain it. Quality counts even more during tough times, though
ironically, it is usually the first victim. Consumers are more vigilant about what they buy
during the downturn and demand their moneys worth. But by cutting corners, vendors
could compromise on quality. During these times, one has to be cautious about quality
controls. Customers are more concerned about quality now.
A defect can result from design errors, logic errors and coding errors. Design
errors occur when, for example, changes made to the software are incorrect, incomplete,
wrongly communicated or the change request is misunderstood. Logic errors result from
invalid tests and conclusions, incorrect implementation of design specifications, faulty
logic flow or incomplete test of data. Coding errors are caused by incorrect
implementation of detailed logic design and incorrect use of the source code logic.
Defects are also caused by data processing errors and system performance errors. All
these errors, sometimes called residual errors or bugs, prevent the software from
conforming to its agreed specification.
2.4.2
Quality Process
Process is defined as the means by which people, procedures, methods,
equipment, and tools are integrated to produce a desired end result. Since most software
is maintained and enhanced throughout its life, this definition is intended to encompass
new development, enhancement and repair (Watts S. Humphrey, 1990).
54
Everyone realizes the importance of having a highly motivated, skilled

workforce and the latest technology but even the finest people cannot perform at their
best when the process is not understood or operating at its best.
2.4.3
Process Automation
Over the last 200 years, the traditional manufacturing process has seen two
major revolutions:
From craft production to mass production
From mass production to what has been termed "lean" production. Lean, as
exemplified by many, has led to major improvements both in productivity and
quality.
The history of software manufacturing or development is much shorter,
spanning decades rather than centuries, and software development still uses techniques
that have much in common with craft industries. In craft industries, products of high
quality and sophistication can be produced, but such products rely heavily on skilled
experts. Given the phenomenal growth of the software industry, relying on the limited
supply of these experts has been a major contributor to what has been called the software
crisis. Thus, there is a need for techniques that can leverage the skills of software
engineers, simultaneously improving productivity and quality. While not a magical
solution, process automation may contribute to this critical need.
Software Process Management provides a framework for progressively
improving the orderliness of software development work. By using a structured, managed
and planned process, the professionals will better understand their roles and their
interrelationships. Once such orderly performance is achieved, improvements will
continue but will be incremental. At some pint the professionals will be using the process
about as effectively as they know how to, and yet there will be a need for further quality
and productivity improvements. Progressively automating more and more of the process
tasks that are now done manually, will not only increase productivity and quality but will
also enrich the roles of the professionals, free them from much of their current drudgery
55
and make more of them available for more creative work. While automated tools are not
expected to replace creative programmers and managers, it can certainly develop far
more capable support systems. There are many opportunities for such intelligent
assistance that are well beyond the level of mere task support. Some such promising
positives are:
Defining the conditions that must be satisfied before some action is taken
Forward or backward chaining to maintain implementation consistency
Checking and exposing the side effects of potential actions
Building logs and data records of process transactions
Providing symptomatic assessments of software process data

In attempting to move software development away from the craft approach to
a more rational means of production, two significant approaches have been pursued:
Using technology to support, automate, and to some extent reduce the skill
level required for development.
Improving the process through which the software is developed

Process Automation is used to
Automate the menial tasks
Maintain consistency among the requirements, design and the code
Provide a full range of interactive tool capabilities for the team
Provide environment support for project management, version control and

incremental programming
Process Automation in any organization is initiated and deployed with the
following characteristics:
Workflow based
Preemptive
Facilitate process adherence
56
Project status visibility
Knowledge management
Figure ROL-02: Software Process Automation Coverage

Figure ROL-02 above represents the various areas covered under 4 major
heads typically as part of process automation in a software organization.
Instant Process Software companies are organized into industry wise
customers to easily service them with similar kind of solutions by making use of cross
skills. Also, for different types of projects, there are many different process models.
Therefore, the processes used for some software projects in the same industry and
technology might be similar too. Hence, it is ideal to streamline them and automate them
so the teams find it easy to follow:
57
Software Process Models Software process models used for different types
of projects may be as follows:
Development Waterfall, Spiral, Iterative, Rational Unified Process, etc.
Conversion/Migration Waterfall, Spiral, Iterative
Integration - Iterative
Product Implementation - Waterfall
Testing Iterative, customized Testing Service Models
Maintenance Maintenance model
Service Service model
Hybrid Iterative and Maintenance

Re-use Templates Templates are usually designed at organization level,
customized for project types and tailored for a particular project. These templates are
made available in the automated tool which after customization and tailoring is made
available for the entire project team to use. Any change in it is communicated through the
automated tool itself. Always, the latest versions of the templates are made available for
the entire organization.
Readymade Checklists Just as above, the checklists are made available to
the entire organization along with recent changes and hence no separate communication
to the entire organization required for every change that is being made.
Best Practices Project teams innovate new ways to deliver projects
successfully and this success stories are either published or incorporated as new processes
or process changes within the automated tool. Thus, teams do not have to reinvent the
wheel every time.
Process Conformance As part of continuous improvement, there are always
process changes happening. Large software organizations will find it difficult to
communicate this to all the teams and ensure process is complied. The automated tool
58
helps with this and saves effort and time while also organization wide process
conformance.
Customized Approach Software organizations, in addition to standard
process systems such as CMMi, ISO or PMP use tools and principles suggested by other
performance and quality improvement methodologies such as Six Sigma, Lean, etc.
These tools and principles are also integrated with process automation to enable use of
them at appropriate phases in the project.
Role based Access - Processes define who, what, when and how an activity
has to be conducted. Certain activities have to be performed only by some people in the
team. For example, developers have access to check-in developed source code while
testers have access to check-out the same only for testing. Project Managers have access
to create and amend project plans and create work plans. The team members have access
to only view the plans and update the work progress. So, an automated tool helps with
providing the right access to right people to conduct their activities appropriately.
Multi-role Support If a person is working on multiple projects or playing
different roles, for example he is the team leader as well as the tester, the project
managers and test managers find it easy to allocate work plans to him based on his
availability since all this schedule is planned, updated and made visible in the automated
tool.
Customizable Workflow As an example, a typical workflow for code is
Program specification, source code development, code review, fix bugs, repeat code
review and fix bugs till passed, unit test, fix bugs, repeat unit test and fix bugs until
passed. When the project manger suddenly feels that an additional performance test to be
done exclusively for this code since it has got a very complex high data handling code,
this activity can be introduced only for this piece of code within this only project and
progress completely tracked only through an automated tool.
External Reviews If at any time, a project requires an external reviewer to
conduct a review, there is a whole lot of procedural changes required. In an automated
59
tool, this is quite easy. The skill sets of employees are available to choose from, their
availability and location is known and hence it is quite easy to plan and organize an
external review without much hassle.
Document Sharing It is quite easy and fast to share any important
documents and guidelines among teams through automation. It helps to upload these
documents and send out a single communication that reaches all relevant people.
Integrated Framework There are many process systems that recommend
processes, models, methodologies and guidelines for different kinds of projects. But
nothing prepares the organization from conducting complex multi-variant projects.
Business Applications Automation helps to merge and collaborate different
application processes according to present need.
Hybrid Models Process models such as Maintenance and Service models
can be merged to address customer needs. Similarly, Conversion, Integration and Testing
models can be combined into a single framework through automation since the base
models are already available in the tool.
Module Integration Especially when different teams work out of different
location, modules and their information such as interface points, test paths, etc. can be
shared through an automated tool.
Visibility Across Projects Most importantly, there is absolute visibility on
the progress of work within the project for the team, across teams. Best practices and
cross utilization of skills is possible through automation.
Client/Management Visibility An automated tool provides regular reports
and any warnings of urgent attention to the management up to the top level. There is no
time delay in identifying concerns and challenges that require management intervention.
Clients are also provided visibility through reports and status dashboards which makes
them comfortable on knowing the progress frequently.
60
Real-time
Management
Managing
project
management,
account
management and business unit management at real time is quite easy with automation.
Project Planning Project plan frameworks are readily available which can
be adopted and adapted for a particular type of customer, project, location and
technology.
Risk/Issue Management The complete process of possible risks and
subsequent issues in a project are identified, appropriate action plans to eliminate/solve
them and complete tracking of the same to closure can be done in an automated tool.
Resource Management Hardware, software and human resources can be
effectively utilized and managed well through process automation.
Performance Monitoring Monitoring the resource performance and tracking
the project progress is very easily done through process automation.
Data Collection and Reporting Last but not the least, a process automation
tool holds information that is phenomenal. This data can be well used by collecting,
collating and reporting to the right people at the right time to take quick decisions. The
same can also be collated at various levels and presented in a simple dashboard to the top
management. These reports, since prepared on a click of a button, can be generated and
presented as frequently as even daily.
Adopting any new initiative is likely to meet with significant resistance.
Because of its pervasiveness and potentially impersonal nature, this is particularly true
with process automation. As with any new initiative, some of this resistance will simply
result from the fact that people often do not like to change from their comfortable routine
to new and uncertain ways. However, some resistance will also come from reasons
unique to process automation. Such reasons are related to the controlling nature of the
adoption and the automated collection of personal productivity metrics. Process
automation imposes behavioral changes that are unique in its own way. Process
automation is different in the sense that it can request actions of the human. While the
61
roles of the computer and human are not entirely reversed, this puts the computer at the
same status level as the human. This question of roles may be difficult for many to take,
and is a major reason why adoption issues for process automation are so critical. If
management wishes to succeed, then it has to create an environment of trust that can only
be achieved through closely involving the people who will have to live within the system
(Alan M. Christie, 1994). The following points provide some experience-based
guidelines which may be useful to address when considering the application of process
automation technology.
Resistance to change: Resistance should be expected. Overt resistance is to
be encouraged otherwise it can easily become covert and undermining.
Process ownership: The philosophy of pushing down responsibility to as low
an organizational level as possible should be adopted. Thus the group responsible for
performing a process which is to be automated should help define, and should feel that it
has ownership of, that automated process. This may be done by encouraging close
collaboration between the user group and a software engineering process group (SEPG).
The SEPG should know how to elicit information on the current processes and identify
the user-groups requirements on its automated equivalent, by:
Knowing how to define process models,
Knowing how to implement and validate enactable models,
Understanding metrics collection and analysis issues, and
Having the necessary skills to address adoption/transition issues.
Training: Training and setting expectations are significant contributors to the
success of this adoption task.
Process improvement: In the same way that a group operating a process
should feel ownership if it, the group should also have the responsibility for improving it.
Thus the group should be responsible for collecting and analyzing its own process
62
metrics, encouraging suggestions for enhancing the process and for implementing
changes. These changes should, of course conform to the organizational standards.
Process metrics: Process metrics should be managed by the group and should
be non-attributable to individuals. With the automated metric collection, access to
confidential metric data should be controllable, thus assuring those involved that such
data will not be used in employee evaluations. Only non-attributable data is passed up the
management chain. Person-specific metrics are used by the group only to improve the
groups process; group-averages may then be used to support the improvement of higherlevel processes.
Organizational context: Project processes should be defined within the
broader context of the organization. Thus the organization has the responsibility to
develop process definition standards, process interface standards, and data format
standards. However, broad organizational standards should only be imposed after
sufficient exploratory experience is gained with process automation at the project level.
Process interfaces: Broad higher-level process models may be used to guide
the organization of the lower-level processes and information flows. However, these
higher-level processes should not specify the details of the individual processes. Detailed
process definition should be a bottom-up task. The top-down model may be periodically
revised as a result of bottom-up integration of tasks. In this way the model is organic,
being neither completely top-down nor bottom-up.
Transitioning strategies: To institute automated processes in an existing
project, real-time validation may be required before commitment to the new process is
made. One approach to this is to run the old (perhaps manual) process in parallel, sideby-side with the new automated process, making sure that the inputs to both are identical.
Outputs are then compared for some time to assure that they are identical. In cases where
the old and new processes are not the same, the two processes can still be run side-byside until sufficient confidence is gained that the new process is providing correct output
(parallel strategy). Another strategy is to incrementally insert small components of the
63
automated process into the old process in such a way that the change-over to the new
process occurs gradually (incremental strategy).
Process reuse: Processes that have been successfully run by one project can
be captured in a organization process repository for use or modification by others. This
not only reduces the effort in implementing processes in subsequent projects, but will
support the drive to organizational consistency of process and encourage communication
between projects.
Granularity of process control: The manner in which a process is be modeled
should depend on the application area. In general, processes closer to technical
development should provide increasing degrees of support or guidance and decreasing
degrees of imposed control. For example, developers are unlikely to accept a level of
overt, external control in which every act in the code/compile/test cycle is regulated.
However, they may wish to support their activities by developing their own personal
process scripts. On the other hand, persons managing change requests or document
review activities may be very happy to have the support of an externally defined process
in order to lift some of the administrative burdens from their shoulders.
2.5 LITERATURE ON SOFTWARE PROCESS AUTOMATION
Humphrey, W. S. (1989), Managing the Software Process, AddisonWesley Professional. The author, drawing on years of experience at IBM and the SEI,
provides here practical guidance for improving the software development and
maintenance process. He focuses on understanding and managing the software process
because this is where he feels organizations now encounter the most serious problems,
and where he feels there is the best opportunity for significant improvement. Both
program managers and practicing programmers, whether working on small programs or
large-scale projects, will learn how good their own software process is, how they can
make their process better, and where they need to begin. "This book will help you move
beyond the turning point, or crisis, of feeling over-whelmed by the task of managing the
64
software process to understanding what is essential in software management and what

you can do about it."
Paulk, M. C., et al. (1993), The Capability Maturity Model for Software,
Version 1.1 (CMU/SEI-93-TR-24, ADA 263403). Pittsburgh, PA: Software Engineering,
Institute, Carnegie Mellon University. This paper provides a technical overview of the
Capability Maturity Model for Software and reflects Version 1.1. Specifically, this paper
describes the process maturity framework of five maturity levels, the structural
components that comprise the CMM, how the CMM is used in practice, and future
directions of the CMM. This paper serves as one of the best sources for understanding the
CMM, and it should clear up some of the misconceptions associated with software
process maturity as advocated by the SEI. The SEI has worked with industry and
government to refine and expand the model, and software organizations are encouraged
to focus on the CMM rather than on the maturity questionnaire. The SEI has developed,
and is developing, a suite of process products to encourage this focus. This paper
[Paulk93a], in combination with the "Key Practices of the Capability Maturity Model,
Version 1.1" [Paulk93b], comprises CMM v1.1. The "Key Practices of the Capability
Maturity Model, Version 1.1" describes the key practices for each level of the CMM.
This paper describes the principles underlying software process maturity and is intended
to help software organizations use CMM v1.1 as a guide to improve the maturity of their
software processes.
Christie, A. M. (1994), A Practical Guide to the Technology and Adoption
of Software Process Automation, Carnegie-Mellon University, Pittsburgh. Process
automation provides a means to integrate people in a software development organization
with the development process and the tools supporting that development. For many
reasons, this new technology has the potential to significantly improve software quality
and software development productivity. As yet, however, there is little practical
experience in its day-to-day use. The main goal of this report is thus to provide
information for organizations that are considering its adoption. For these reasons, the
report aims to identify how process automation relates to both process improvement and
CASE tools, to review in some detail two of the major commercial process automation
65
products, and to address relevant organizational adoption issues. It is hoped that the
report will help bridge the gap between those whose focus is software process
improvement and those whose focus is software technology. Software process
automation, CASE Tools, Software process improvement.
Christie, A. M. (1994), Software Process Automation - A Technology
Whose Time has Come? CrossTalk - Journal of Defense Software Engineering.
Software process automation, as described in this article, is still in its infancy.
Commercial products supporting this technology are only now becoming available, and
there is, as yet, little real-world experience with its day-today use. The experience with
CASE technology indicates that adoption issues are critical to success, and if these issues
are not adequately addressed, expectations may not match reality. This conclusion will be
just as true with process-centered environments. However, for organizations that
understand the technology and adoption issues, process automation may offer the many
advantages cited in this article and result in significant improvement in both process
effectiveness and product quality.
Cherinka, R., Overstreet, C.M., Cadwell, A. and Ricci, J. (1994), Issues
in software process automation-from a practical perspective, Software Maintenance,
Proceedings, International Conference, Canada. This paper describes a process-oriented
approach currently employed by a Department Of Defense software maintenance
organization to use an integrated software engineering environment, largely based on
commercially-available tools, for enhancing quality and productivity during software
maintenance. Before automated support could be provided to the organization, a
complete review of existing procedures was required. The first step was an extensive
modeling effort to identify the procedures and document them in detail. It was then
possible to identify, and in some cases modify, those procedures that could benefit from
automated support. The result of this organization-wide process analysis was then
mapped into an existing commercial process enactment tool and used to automate,
control, measure, and improve the software maintenance process.
66
Christie, A. M. (1995), Software process automation: the technology and

its adoption, Springer-Verlag, London, UK. Process automation provides a means to
integrate people in a software development organization with the development process
and the tools supporting that development. This monograph is for those who wish to
explore the technology and are considering its adoption. The monograph discusses the
underlying concepts, reviews in some detail two of the major process automation
products, relates process automation to process improvement and provides adoption
guidelines.
Macdonald, F., Miller, J., Brooks, A., Roper, M. and Wood M. (1995),
Automating the Software Inspection Process, Automated Software Engineering: An
International Journal. Inspection is widely believed to be the most cost-effective method
for detecting defects in documents produced during the software development lifecycle.
However, it is by its very nature a labor intensive process. This has led to work on
computer support for the process which should increase the efficiency and effectiveness
beyond what is currently possible with a solely manual process. In this paper, we first of
all describe current approaches to automation of the inspection process. There are four
main areas of inspection which have been the target for computer support: document
handling, individual preparation, meeting support and metrics collection. We then
describe five tools which have been developed to support the inspection process and
compare the capabilities of these tools.
Berk, J. and Berk, S. (1995), in their book Total Quality Management;
Implementing Continuous Improvement, describes in detail how TQM is redefining the
way companies do business. The TQM philosophy is based on several management
systems designed to continuously improve customer satisfaction. Some of the systems
used for successful improvement include: Continuous improvement an approach
emphasizing sustained improvements in the quality of goods and services; Quality
Measurement identifying areas in which customer expectations are not satisfied and
prioritizing continuous improvement; Employee Involvement placing the responsibility
for delivering quality products and services in the minds of all employees; Business
Process Management defining how processes operate and implementing improvements
67
that reduce cost while increasing customer satisfaction; Value Improvement eliminating
unnecessary cost while meeting or exceeding customer expectations. With is proven
philosophy and these quality gains, it will increase the market share and reduce the cost
of doing business!
Christie, A. M., Levine, L., Morris, E. J. and Zubrow, D. (1996),
Software Process Automation: Experiences from the Trenches, Technical Report,
CMU/SEI-96-TR-013, ESC-TR-96-013, July 1, 1996, Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, Pennsylvania 15213. Software process
automation is a new technology with significant promise. However, practical experience
in the field is still limited and there appears to be a variety of potential barriers to its use.
The objective of this empirical study is thus to document practical experience that does
exist and to identify what works and what does not. Lessons learned from the study will
be disseminated to help others who wish to implement the technology. This report
documents the first phase of the study in which 15 in-depth interviews were conducted.
Personnel interviewed were involved in projects where process-centered environments
were developed and transitioned into use.
Sheth, A., Georgakopoulos, D., Joosten, S. M. M., Ruskinkiewicz, M.,
Scacchi, W., Wileden, J. and Wolf A. (1996), Report on NSF Workshop on Workflow
and Process Automation in Information Systems, Athens, GA. An interdisciplinary
research community needs to address challenging issues raised by applying workflow
management technology in Information Systems. This conclusion results from the NSF
workshop on Workflow and Process Automation in Information Systems which was held
at the State Botanical Garden of Georgia during May 8-10, 1996. The workshop brought
together active researchers and practitioners from several communities, with significant
representation from database and distributed systems, software process and software
engineering computer supported cooperative work. This report is the joint work of
selected representatives from the workshop and it documents the results of significant
group discussions and exchange of ideas.
68
Perry, D. E., Porter, A., Votta, L. G. and Wade, M. W. (1996),

Evaluating Workflow and Process Automation in Wide-Area Software Development,
Proceedings of the Fifth European Workshop on Software Process Technology. Process
Automation Tools can significantly reduce cycle-time. We share this belief, but have
some reservations since our previous research suggests that building quality software
products rapidly will require much more than just new technology; it will also require
careful analysis of the software processes in which the technology is used. To study this
issue we've developed a workflow tool that allows distributed groups to execute a wide
variety of software inspection processes. More importantly, we are using this technology,
in a live software development project? This work is supported in part by a National
Science Foundation Faculty Early Career Development Award, CCR-9501354. To
support controlled experiments exploring how process structure affects cycle time.
Tekinerdogan, B., Saeki, M., Sunye, G., Broek, P. V. D. and Hruby, P.
(1999), Automating the Object- Oriented Software Development Process. Current
software projects have generally to deal with producing and managing large and complex
software products. It is generally believed that applying software development methods
are useful in coping with this complexity and for supporting quality. As such numerous
object-oriented software development methods have been defined. Nevertheless, methods
often provide a complexity by their own due to their large number of artifacts, method
rules and their complicated processes. We think that automation of software development
methods is a valuable support for the software engineer in coping with this complexity
and for improving quality. This paper presents a summary and a discussion of the ideas
that were raised during the workshop on automating object-oriented software
development methods.
Christie, A. M. (2000), Software Process Automation provides a means to
integrate people in a software development organization with the development process
and the tools supporting that development. This new technology may significantly
improve software quality and development productivity. However, as yet there is little
practical experience in its day-to-day use. This book is for those who wish to explore the
technology or are considering its adoption. The monograph discusses the underlying
69
concepts, reviews in some detail two of the major process automation products, relates
process automation to process improvement, and provides adoption guidelines. Special
emphasis is on the process modeling language ProNet which is commercially available.
The book is enriched by numerous examples, tables, and technical appendices.
Narzt, W. (2000), Design Patterns for Process Automation Systems. By
now, European companies are the market leaders in the development of process
automation software. Current numbers indicate, however, that this market position is
going to change in favor of US and Far East companies. This thesis can be regarded as a
contribution to keep the leading market position because it presents an innovative
software architecture for process automation systems which promises a high reuse factor
up to 70% and therefore helps to save time and costs for the development of future
process automation software.
Reis, R. Q., Reis, C. A. L., Aless, C., Reis, R. L. and Nunes, D. J. (2001),
Automated Support for Software Process Reuse: Requirements and Early Experiences
with the APSEE model, Proceedings of the 7th International Workshop on Groupware
(CRIGW-01) Darmstadt (Germany). This paper discusses the need to provide better
support for software processes reuse in PSEEs (process-centered software engineering
environments). This discussion is influenced by the recent work on process reuse field
presented by the literature and the experience of authors in the definition of a meta-model
for process modeling, enaction and simulation in an integrated environment (APSEE).
This model proposes templates and policies as basic constructs to store generic and
reusable knowledge about process models, which are integrated with a search engine
based on similarity measurement. The basic set of data types used in the definition of the
meta-model is presented. The paper concludes by presenting the proposed functionality
for retrieve and adaptation of reusable process descriptions to a specific context.
Sharma, R. (2001), Software Process Improvement and Automation, Over
the years, the software development has evolved from just being science to a combination
of art and science. Todays software development environments follow lifecycles
with phases that are either sequential or parallel in execution. This has highlighted the
70
significance of establishment and institutionalization of the lifecycle supportive

processes. This paper discusses the need for automated assistance for these process
management activities. It will also highlight the considerations for an automated system
for processes and the benefits that can be realized.
Behforooz, A. and Hudson F. J. (2003), have explained in details the
essence of Software Engineering Fundamentals. Their book provides a comprehensive
overview of software engineering and its process, builds on experience drawn from actual
practice, and guides software engineering students toward a better understanding of the
various disciplines, tasks, and specialties that contribute to the development of a software
product. Intended for both students and professionals, the text follows the full software
development life cycle,, including a thorough coverage of methods, tools, principles and
guidelines. Software engineering fundamentals is unique in its coverage of such topics as
software metrics, real-time software design, quality assurance, reliability, risk
management, cost and schedule estimating, sizing, planning, test and integration process,
technical management and human factors. It establishes the concept of software
development as an engineering process and software as an engineered product, and
describes software development as a team-oriented activity usually conducted in a system
development setting. The notion of using software metrics to measure properties of the
software product as a means to evaluate and control the development process is
introduced, software metrics are presented as a management tool, and the software
development process is described using an accepted review and documentation structure
as an outline. Many interim products of the software engineering process are described in
enough detail to permit the reader to produce a credible draft of these products. While
encouraging the use of modeling techniques for sizing, cost and schedule estimation,
reliability, risk assessment, and real-time design, the authors emphasize the need to
calibrate models with actual data. Explicit guidance is provided for virtually every task
that a software engineer may be assigned and realistic case studies and examples are used
extensively to reinforce the topics presented. Software Engineering Fundamentals
presents a unique blend of practical and theoretical treatment of software engineering
topics for students and professionals alike.
71
Grubb, P. and Takang, A. A. (2003), Software Maintenance: Concepts

and Practice, Software systems now invade every area of daily living. Yet, we still
struggle to build systems we can really rely on. If we want to work with software systems
at any level, we need to get to grips with the way software evolves. This book should
equip the reader with a sound understanding of maintenance and how it affects all levels
of the software evolution process.
Liker J. K. (2004), in his book The Toyota Way has brought a concise set
of points that help ones business to learn from Toyota. The key points are 1) double or
triple the speed of any business process; 2) build quality into workplace systems; 3)
eliminate the huge costs of hidden waste and 4) turn every employee into a quality
control inspector. With a market capitalization greater than the value of General Motors,
Ford and Chrysler combines, Toyota is also the worlds most profitable automaker.
Toyotas well known secret weapon is Lean production - revolutionary approach to
business processes that it invented in the 1950s and has spent decades perfecting. Less
well known are the management principles that underline Lean production. Today
businesses around the world are attempting to implement Toyotas radical system for
speeding up processes, reducing waste, and improving quality. But are they getting
beneath the surface of Lean tools and techniques to the real foundation of Toyotas
success? This book explains Toyotas unique approach to Lean Management the 14
principles that drive Toyotas quality and efficiency-obsessed culture. One gains valuable
insights that can be applied to any organization and any business process, whether in
services or manufacturing. Youll discover how the right combination of long-term
philosophy, processes, people and problem solving can transform your organization into
a Lean, learning enterprise The Toyota Way.
Beasley J. D. (2004), The Impact of Technology on Plagiarism Prevention
and Detection: Research Process Automation, A New Approach For Prevention
Plagiarism: Prevention, Practice and Policies 2004 Conference. Plagiarism: Prevention,
Practice and Policies 2004 Conference For the past several years, technology approaches
to plagiarism prevention have focused on detection, meaning the ability for a lecturer to
utilize software to analyze student papers and detect whether or not content was
72
plagiarized from another source. This paper proposes adding another approach, Research
Process Automation, which focuses on automating elements of the research and writing
process and more specifically on the development of research work products. This
approach provides plagiarism prevention through just-in-time guidance, research project
management, productivity tools, and tracking features. The topics included are the scope
of the plagiarism problem, current approaches, some of the strengths and limitations of
detection technology, the advantages of using Research Process Automation in
plagiarism prevention, the causes of plagiarism, and how Research Process Automation
and Research Development Environment software can address various causes of
plagiarism.
Thayer, R.H. and Christensen, M. J. (2005), in their book Software
Engineering, The Development Process, describe in detail the key processes that support
development, and address the key issues and tasks facing the software engineer today. It
provides a self-teaching guide and tutorial for software engineers who desire to qualify
themselves as Certified Software Development Professionals (CSDP) as described at the
IEEE Computer Society Web site (www.computer.org/certification), while also gaining a
fuller understanding of standards-based software development.
activities of software and systems engineering are
Key concepts and
Societal and legal contexts in which
software development takes place, Key IEEE software engineering standards, Software
requirements and methods for developing them, Essential concepts and methods of
software design, Guidelines for the selection and use of tools and methods, Major issues
and activities of software construction, Software development testing and Preparation and
execution of software maintenance programs.
Thayer, R. H. and Dorfman, M. (2005), in their book Software
Engineering, The Supporting Processes, detail the supporting life cycle processes that
developers need to employ and execute in the engineering of software products. The
various underlying processes detailed with supporting papers, and standards are Software
Engineering Supporting Processes,
Software Configuration Management, Software
Verification and Validation Processes, Software Quality Assurance Process, Software
73
Reviews and Audits Processes, Software Documentation Process, Management Process,

Infrastructure Process and Improvement and Training Processes.
Seilonen, I. (2006), as part of his research thesis describes studies on
application of multi-agent systems (acronym: MAS) to enhance process automation
systems. A specification of an extended process automation system is presented.
According to this specification, MAS can be used to extend the functionality of ordinary
process automation systems at higher levels of control. Anticipated benefits of the
specification include enhanced re-configurability, responsiveness and flexibility
properties of process automation. Here, a specification of an agent platform for process
automation is presented as a basis for applying MAS in this application domain. The
specification extends a FIPA-compliant agent platform with process automation specific
functionality. It utilizes a hierarchical agent organization, a BDI-agent model and
qualitative reasoning. It also presents a model for programming MAS applications for
process automation with techniques of distributed planning and search. Two applications
are specified using the platform. One of these shows how the techniques of distributed
planning can be applied in sequential control. The other provides a design model for
supervisory continuous control applications using the techniques of distributed search.
Experiments
performed
with
a laboratory test
environment
using prototype
implementations of the applications are presented. The experiments are able to

demonstrate the feasibility of the approach in limited test scenarios. They also provide
information about in which ways MAS techniques are able enhance the properties of
process automation.
Persse, J. (2007), Project Management Success with CMMI@", Prentice
Hall, Prentice Education, New Jersey. The CMMI Level 2 offers powerful, end-to-end
tools for improvement an organization. In this book, James demonstrates exactly how to
apply CMMI Level 2 to virtually any project, program or process. The author takes a
practical approach to the business and operational needs of project management, carefully
linking the realities of business and technical projects with CMMI recommendations.
Persse introduces the substance and intention of all seven CMMI Level 2 process areas.
74
He also explains how CMMI can integrated with the tools and skills of the PMIs
PMBoK improving the effectiveness of both.
Derniame, J. C., Kaba, A. B. and Wastell, D. (2008), Software Process
Principles, Methodology and Technology, Springer. The software process defines the
way software development is organized, managed, measured, supported and improved,
independently of the support techniques used in the development. Software houses and
businesses in general have come to realize that the key to successful delivery (on time, on
budget, with the expected quality) lies in the effective management of their software
process. This book is devoted to quality management for software. The focus is on
supporting the development process by constructing explicit models and deploying
automated support environments. The authors do not attempt to compare, analyze or
propose improvements to existing processes or process design methodologies. Their main
concern is with the core technologies and basic concepts underpinning software process
modeling and software process automation, with a special emphasis on the mechanisms
that support software process evolution.
2.6 RESEARCH GAP IN AVAILABLE LITERATURE
2.6.1
Relation between Software Process Automation and Software Project

Success
When a project is in progress, the status reports and the GUI (Graphic User
Interface) is very good and suddenly something goes wrong. To identify and rectify this
problem, the project team is now is repairing and modifying code that has been in the
configuration store for months. This change can add more problems lead to quality
issues. Sometimes, by the time one finds out a quality problem, it is probably too late to
fix it. This unsettlement hinders the regular project progress. So, the lesson is one cannot
go back and add quality. Project success depends on a more controlled environment with
established procedures to build a quality product at the very beginning.
75
Software Process Automation is a technology that may be viewed as a two-edged

sword. On the one hand it can be viewed as a productivity and quality enhancer, while on
the other hand, it can be viewed as a mechanism to control, routinize, and de-skill work.
These views both have elements of truth, but with appropriate design and adoption
considerations, we believe that it is possible to enhance the positive elements while
reducing the negative ones.
Therefore, there is a close association between Process Automation and Project
Success. However, it is also known that there are many external and internal factors that
influence both Process Automation and Project Success.
2.6.2
Gaps in Literature
The literature that is available today on various studies and research work
conducted on Project Success is very detailed and exhaustive. There are some studies
conducted on Process Automation and limited literature available on the same. Literature
on studies or research conducted on the association between Process Automation and
Project Success is very limited and whatever is available has not done in-depth study to
understand how one affects the other.
2.7 CONCLUSION
It is noted during the preliminary study, that very limited literature is
available on the areas of Software Process Automation, Software Project Success and
various internal and external factors influencing them. Also, no study or research has
been done on the actual width and depth of the relation between these two areas. There
are literature on what are various means that can be adopted to successful project
delivery. There are also few literature on the process automation initiatives undertaken by
various software service organizations. But, no study has pointed out the association
between these two areas and how deeply they are associated. Hence, the researcher
identified this specific area for identifying the extent of association and supporting and
inhibiting factors of each area namely Software Process Automation and Software Project
Success.
76
77
CHAPTER III: RESEARCH METHODOLOGY
3.1
INTRODUCTION ................................................................................................. 79
3.2
JUSTIFICATION FOR METHODOLOGY.......................................................... 79
3.3
DETAILS OF RESEARCH PROCEDURES ........................................................ 80
3.4
ETHICAL CONSIDERATIONS ........................................................................... 97
3.5
CONCLUSION ...................................................................................................... 97
This particular research is supported by information gathered through

interviewing method and the information was collated from four different Software
Services Organizations. The primary hypothesis is supported by 12 different secondary
hypotheses which are proven with the analysis conducted on the 7 distinct groups of data
collected. A questionnaire containing 70 questions under the above said 7 groups was
distributed and 83 responses were collected. Statistical tools were used appropriately to
derive analytical results and arrive at conclusions.
78
CHAPTER III
RESEARCH METHODOLOGY
3.1 INTRODUCTION
In this chapter, the research methodology is presented. The aim of this chapter is
to introduce and explains the design of the research methodology, the various steps taken
to apply this methodology to obtain relevant, concrete and absolute information to
substantiate the research theory and conduct quantitative and qualitative research
techniques. Then, the research proceeds to conduct appropriate and reliable statistical
tools to derive statistical results and thereby bring out concluding inferences. This chapter
also points out the challenges faced in applying the research methodology.
3.2 JUSTIFICATION FOR METHODOLOGY
This research was conducted over a period of 3 years starting in 2005. Initially a
small scale preliminary study was conducted to test the design of research and improve
the same to ensure feasibility of the full scale research and making it a success. For this
purpose, software services organizations were approached to gather data. Later, two
Indian and two global based software services organizations were specifically considered
and a survey on a sample of 83 software professionals spread over these four
organizations were conducted. The scope has a clear boundary in terms of automation
only in relation to software development and the target audience was selected based on
the practices adopted to implement process automation.
The questionnaire was designed, tested and then rolled out to gather data for the
purpose of this research. Data collection was a challenging task. Software services
organizations normally do not have large groups working on this area. Hence, though
many questionnaires were distributed, not all were returned. Further, the questionnaire
was administered to process groups of two Indian and two foreign organizations, the
respondents were all residents of India. Also, this is one industry that is fast changing. In
79
such scenarios, data collected 2-3 years before could have undergone changes too. This
research could not review and include any changes occurred thereafter.
3.3 DETAILS OF RESEARCH PROCEDURES
3.3.1
RESEARCH HYPOTHESES
The primary hypothesis is stated based on the main focal topic and scope of
the research and is defined as:
PRIMARY HYPOTHESIS: There is no significant contribution by Process

Automation on Software Project Success.
The secondary hypotheses are defined relative to the primary hypothesis and
the various factors that influence Software Process Automation and Software Project
Success. For this purpose, the seven groups of information gathered during research
are analyzed for relationship and influence.
A. Business/Product Characteristics of the Organization

B. Implementation Team Characteristics
C. Application Focus
D. Process Characteristics
E. The Development Technology
F. Transition and Adoption
G. Impacts and Insights
80
B
Implementation
Team
Characteristics
H4
H1
C
Application
Focus
H2
A
Business/
Product
Characteristics
H5
H6
H3
H8
H7
E
Development
Technology
H11
D
Process
Characteristics
F
Transition and
Adoption
H9
H12
G
Impacts and
Insights
H10
Figure RM-01: Relation between Groups of information
The secondary hypotheses are defined with reference from Fig. 3 and detailed
below:
HYPOTHESIS I: A. Business/Product Characteristics has no significant influence
on B. Implementation team characteristics
HYPOTHESIS II: A. Business/Product Characteristics has no significant influence
HYPOTHESIS III: A. Business/Product Characteristics has no significant influence
on D. Process characteristics
HYPOTHESIS IV: B. Implementation team characteristics has no significant
influence on C. Application focus
characteristics
81

HYPOTHESIS VII: C. Application focus has no significant influence on F.
HYPOTHESIS VIII: D. Process characteristics has no significant influence on E.
The development technology
HYPOTHESIS X: D. Process characteristics has no significant influence on G.
HYPOTHESIS XI: E. The development technology has no significant influence on
F. Transition and adoption
3.3.2
Variables of the Study
PRIMARY HYPOTHESIS: There is no significant contribution by Process

Automation on Software Project Success.
Independent variable: Software Process Automation
Dependent variable: Software Project Success
HYPOTHESIS I: A. Business/Product Characteristics has no significant influence

on B. Implementation Team Characteristics.
Independent variable: Business/Product Characteristics
Dependent variable: Implementation Team Characteristics
Background variables: Frequency of Organizational Changes, Organizations

culture, Process Automation Team Size, Team Leaders experience, Teams
Skills/Experience, End-User Participation, External Consultants Participation
and Sub-contractors Involvement.
HYPOTHESIS II: A. Business/Product Characteristics has no significant influence

on C. Application Focus.
82
Dependent variable: Application Focus
Background variables: Frequency of Organizational Changes, Organizations

culture, Process Areas addressed by Automation, Organizations motivators
for Process Automation, Funding by Organization, Number of Process Users
involved during Process Automation, Elapsed Period for Automating any
Process and Various activities of Process Automation.
HYPOTHESIS III: A. Business/Product Characteristics has no significant influence

on D. Process Characteristics.
Dependent variable: Process Characteristics
Background
variables:
Organizations
culture,
Presence
of
Process
Improvement Document, Projects Routine Process Activities, Use of Process

Definition Notation, Presence of Process Design, Use of Functional
Requirements, Specification of Metrics Requirements and Challenges in
Process Definition.
HYPOTHESIS IV: B. Implementation Team Characteristics has no significant

influence on C. Application Focus.
Independent variable: Implementation Team Characteristics
Dependent variable: Application Focus
Background variables: Process Automation Team Size, Process Areas

addressed by Automation, Number of Process Users involved during Process
Automation, Elapsed Period for Automating any Process and Various
activities of Process Automation, Number of Processes Currently Automated,
Number of Processes Automated that are in Operation, Automation Activities,
Planned Process Automation, Process Automation In-progress, Additional
Process Automation being Implemented with End-users and Automated
Processes Successfully Deployed.
HYPOTHESIS V: C. Application Focus has no significant influence on D. Process

Characteristics
Independent variable: Application Focus
83
Dependent variable: Process Characteristics
Background variables: Process Areas addressed by Automation, Number of

Process Users involved during Process Automation, Elapsed Period for
Automating any Process and Various activities of Process Automation,
Number of Processes Currently Automated, Number of Processes Automated
that are in Operation, Automation Activities, Planned Process Automation,
Process Automation In-progress, Additional Process Automation being
Implemented with End-users, Automated Processes Successfully Deployed,
Presence of Process Improvement Document, Projects Routine Process
Activities, Use of Process Definition Notation, Presence of Process Design,
Use of Functional Requirements, Specification of Metrics Requirements and
Challenges in Process Definition.
HYPOTHESIS VI: C. Application Focus has no significant influence on E. The

Development Technology
Dependent variable: The Development Technology

Process Automation Methodology, Strengths of Process Automation, Factors
influencing Process Automation Adoption and Hardware supported by
Process Automation Adoption.
HYPOTHESIS VII: C. Application focus has no significant influence on F.

Transition and Adoption.
Dependent variable: Transition and Adoption

84

Time taken for Transition to Process Automation, Period Process Automation
has been in Production Environment, Training to support Process Automation
Adoption, End-user support, Metrics to measure and improve Process
Automation, Performance improvement for End-users through Process
Automation, Management Sponsorship, Initiation of Process Automation
Adoption, Implementation Strategy and Time frame for implementation.
HYPOTHESIS VIII: D. Process Characteristics has no significant influence on E.

The Development Technology.
Independent variable: Process Characteristics
Dependent variable: The Development Technology
Background variables: Presence of Process Improvement Document, Projects

Routine Process Activities, Use of Process Definition Notation, Presence of
Process Design, Use of Functional Requirements, Specification of Metrics
Requirements, Challenges in Process Definition, Process Automation
Methodology, Strengths of Process Automation, Factors influencing Process
Automation Adoption and Hardware supported by Process Automation
Adoption.
HYPOTHESIS IX: D. Process Characteristics has no significant influence on F.


Requirements, Challenges in Process Definition, Time taken for Transition to
Process Automation, Period Process Automation has been in Production
Environment, Training to support Process Automation Adoption, End-user
85
support, Metrics to measure and improve Process Automation, Performance

improvement for End-users through Process Automation, Management
Sponsorship, Initiation of Process Automation Adoption, Implementation
Strategy and Time frame for implementation.
HYPOTHESIS X: D. Process Characteristics has no significant influence on G.

Impacts and Insights.
Dependent variable: Impacts and Insights

Requirements, Challenges in Process Definition, Success of Process
Automation Adoption Initiative, Areas where Process Automation has helped,
Was Process Automation deployed within stated schedule and Scope for
Automation of Further Processes.
HYPOTHESIS XI: E. The Development Technology has no significant influence on

F. Transition and Adoption.
Independent variable: The Development Technology
Background variables: Process Automation Methodology, Strengths of

Process
Automation,
Factors
influencing
Process
Automation
Adoption, Hardware supported by Process Automation Adoption,

Time taken for Transition to Process Automation, Period Process
Automation has been in Production Environment, Training to support
Process Automation Adoption, End-user support, Metrics to measure
and improve Process Automation, Performance improvement for Endusers through Process Automation, Management Sponsorship,
Initiation of Process Automation Adoption and Implementation
Strategy and Time frame for implementation.
86
HYPOTHESIS XII: F. Transition and Adoption has no significant influence on G.

Independent variable: Transition and Adoption
Dependent variable: Impacts and Insights
Background variables: Time taken for Transition to Process Automation,

Period Process Automation has been in Production Environment, Training to
support Process Automation Adoption, End-user support, Metrics to measure
and improve Process Automation, Performance improvement for End-users
through Process Automation, Management Sponsorship, Initiation of Process
Automation Adoption, Implementation Strategy and Time frame for
implementation, Success of Process Automation Adoption Initiative, Areas
where Process Automation has helped, Was Process Automation deployed
within stated schedule and Scope for Automation of Further Processes.
3.3.3
Population of the Study
The target population of the study is Indian and US based organizations

representing the Software Industry, and the survey sample is from organizations that
would provide a good mix of both the geographies. Four organizations that were
selected for this study are NASDAQ listed. Particulars of these organizations are
furnished below:
Sl.
Professionals
No.
Population
Global Presence
Headquarters
(rounded to
000)
Indian Organization 1
103
26 countries
Bangalore, India
Indian Organization 2
98
35 countries
Bangalore, India
Foreign Organization 1
400
30 countries
New York, USA
Foreign Organization 2
150
170 countries
California, USA
Table RM-01: Particulars of Organizations participated in this study
From the above said organizations, 83 respondents have provided information.

They are at different levels in the hierarchy of the organization but are closely
87
associated with the Process Automation Initiatives. People who participated in this
survey and their roles are shown below:
No. of Respondents
3, 4%
Role
Senior Manager
First Line Manager
Anaysts/Architects
Programmers
SEPG/QA
External Consultants
Total
No. of Respondents
7
27
21
18
7
3
83
7, 8%
7, 8%
Senior Manager
First Line Manager
18, 22%
27, 33%
Anaysts/Architects
Programmers
21, 25%
SEPG/QA
Figure RM-02: Number of Respondents and Organization Role

It can be observed that the management and consultants form about 45% and the
technical people form 55% of the sample size. The balanced spread gives a good
coverage of the organization that was involved in Process Automation Initiatives.
3.3.4
Sample Design and Technique
The sampling technique employed in the study was volunteer sampling.

Volunteer sampling refers to the willingness of software professionals to cooperate to
respond. Volunteers from two India based software organizations and two US based
organizations were approached for this study. 83 respondents have provided
information which is highly confidential and hence the Organization names have been
masked while preparing this report.
The data collection method is a written survey instrument comprising a

self-administered questionnaire with instructions. Participants were assured complete
confidentiality of their responses. The central research design of this study applies a
non-experimental method and is ex post facto in nature. The questionnaire consisted
of 70 questions spread over seven broad categories that formulate the variables of the
study which are stated above and their relationship depicted in Fig RM-01. The
respondents perception of success factors relating to Process Automation
3.3.5
Questionnaire
88
The Survey Instrument or the Questionnaire is designed in such a way that the
seven groups of information as mentioned above are addressed by the seven set of
questions. For example, In Hypothesis I, the independent variable namely
Business/Product Characteristics is the first set of information collected and the
dependent variable namely Implementation Team Characteristics is the second set
of information collected through the questionnaire. The background variables
Frequency of Organizational Changes and Organizations culture are questions 4
and 5 in the group Business Product Characteristics and Process Automation
Team Size, Team Leaders experience, Teams Skills/Experience, End-User
Participation, External Consultants Participation and Sub-contractors Involvement
are questions 1 to 7 in the group Implementation Team Characteristics.
The Questionnaire is given below for reference:
89
Critical investigations on Contribution of Process Automation

to Software Project Success
This questionnaire is being administered as part of the research titled "Critical investigations on Contribution of Process
Automation to Software Project Success". It consists of questions that would help gauge the extent of process automation
implemented in software companies and its influence on the success of the projects delivered by these companies.
A. Business/Product Characteristics
This section deals with the basic characteristics of the business you are in, the products you produce, and your
organization's culture.
1 What industries do you support?
Electronics
Health
Communications
Aerospace
Scientific
Transportation
Software
Finance/Banking/Insurance
Other (specify)
2 In which type of organization do you work?

Commercial
Government
Academic
Other (specify)
3 What is the focus of your products?

One-of-a kind (conceptually new, may require R&D)
Mass-produced (COTS, assembly line)
Maintenance (corrective, perfective)
Customized (tailoring existing product)

Application Development (unique service to customer)
Other (specify)
4 How often do you undergo organizational change which affects the work you do?
Every few months
Yearly
Every few years
Never in my experience
DK/NA
5 How would you characterize your organization's culture (in your experience)?
Neutral
Conservative
5.01
Risk takers
Informal
5.02
Formal
5.03
Many layers
Flat organization
5.04
Controlling
Hands-off
Static environment
Dynamic environment
5.05
Complacent
Energetic
5.06
5.07
Closed minded
Open minded
5.08
Political
Non-political
Jobs are exciting
5.09
Jobs are routine
High turnover
5.10
Stable staff

This section deals with the people who were involved in developing the process-centered environment and transi-tioning the
environment into use
1 How many people are involved in developing the automated process?
<6
7-10
11-20
Over 20
DK/NA
2 How many years of software development experience does the process automation team leader have?
0-2
3-5
6-10
11-15
Over 15
DK/NA
3 How many years of software development experience do you have?
0-2
3-5
6-10
11-15
Over 15
4 People with experience in the following categories are part of the development team:
4.01 Process definition
Yes
No
4.02 Process-centered environment development
Yes
No
4.03 Tool integration
Yes
No
4.04 Computer networking
Yes
No
4.05 Transition and adoption
Yes
No
4.06 Training
Yes
No
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
90
5 There are representatives from each end-user project on the development team
Yes
No
DK/NA
6 Some of the expertise is being provided by external consultants
Yes
No
DK/NA
7 Some of the expertise is being provided by subcontractors
Yes
No
DK/NA
This section covers the process that was automated. If you have been involved in more than one automation project answer
the questions with respect to that project with which you have greatest familiarity.
1 What general areas does the automated processes address?
Project Initiation/Startup
Project Planning
Project Closure
Requirements management
Software Development
Verification/Reviews
Defect/Anomaly Tracking
Release Management
Software Maintenance
Hardware/Software Servicing
Configuration Management
Document Management
Subcontractor Management
Supplier Management
Project tracking & oversight

Design
Validation/Testing
Deployment
Change Management
Document Review
Other (Specify)
2 What elements motivated the management to consider the use of a process automation?
Time to market
Management oversight
Quality
Metrics
Productivity Improvement
Process Improvement
DK/NA
Other (Specify)
3 Adequate funding for technical development was supplied.
Yes
No
4 How many process-users are (or will be) involved in the automated process?
1-5
6-10
11-20
Over 20
DK/NA
DK/NA
5 Approximately how many elapsed days does (or will) the automated process take from initiation to completion?
Less than 1
1-10
11-100
Over 100
DK/NA
6 How many processes are currently being automated?
0
1
2
3
More than 3
DK/NA
7 How many automated processes are in operation?

0
1
2
3
More than 3
DK/NA
8 Is the automated process currently being used on a day-to-day basis?
Yes
No
9 Approximately how many times per month is (or will) the automated process be executed?
Less than 1
1-10
11-100
Over 100
10 To the best of my knowledge, our current automation activities include:

10.01
Technology-no product purchases made
10.02
Organization is evaluating a specific commercial process automation tool
10.03
Defining first process to be automated
10.04
Developing first implementation
10.05
One implementation running - field trials being performed
10.06
One implementation successfully deployed
If the response to question 10.6 is "yes" then
10.06.01 Is automation of any additional process(es) planned
10.06.02 Is development of any additional automated process(es) underway
10.06.03 Are additional automated processes being implemented with end-users
10.06.04 Are additional automated processes successfully deployed?
DK/NA
DK/NA
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
Yes
Yes
Yes
Yes
No
No
No
No
DK/NA
DK/NA
DK/NA
DK/NA
This section covers issues associated with manually defined process in your organization.
1 A documented process improvement plan is in place.
Yes
No
DK/NA
91
2 Projects routinely:
2.01 Collect metrics on project management data
2.02 Use metrics to support process improvement,
2.03 Use documented processes to perform their tasks
2.04 Meet external schedules
2.05 Meet cost estimates
2.06 Provide appropriate training on tools and methods.
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
3 Do you have any documented processes in manual operation?
Yes
No
DK/NA
4 If 3 is 'Yes', in what areas are these processes automated?

Project Planning
Quality Assurance
Document Review
Other (Specify)

Document Management
5 Was a recognized process definition notation used to define the process

6 If 5 is "Yes" please indicate which notation was used:
IDEFO/SADT
Role Interaction Nets
StateMate
Process Breakdown Structure
Flow Chart
ETVX
Yes
No
Role Activity Diagrams

ProNet
DK/NA
DK/NA
Rummler-Brache
Petri-Net
Other (Specify)
7 The process design is clearly and completely documented
Yes
No
DK/NA
8 Functional requirements were used to define tools embedded in the process
Yes
No
DK/NA
9 Metrics requirements are specified for the process
Yes
No
DK/NA
10 The target process was either (check one):

A new process (no prior manual operation)
Operated manually prior to the automation initiative
If you checked 'operated manually' then:

10.01
Was the manual process documented?
10.02
Was the manual process operated in a stable manner?
11 Process definition (for automation) was more challenging than first thought?
DK/NA
Yes
Yes
No
No
DK/NA
DK/NA
Yes
No
DK/NA
E. The development technology

This section deals with the capabilities of the tool that was used to build the process-centered environments. The section
should be completed only by those who have knowledge of the implementation technology.
1 With which automation tool(s) are you implementing process automation?
Procured from market (COTS)
Procured from market and customized
In-house developed
DK/NA
Strongly
Disagree
Disagree
Agree
2 The major strengths of the process automation tool I used are:

2.01 The process development environment
2.02 Debugging capabilities
2.03 Ability to integrate application tools
2.04 Ability to design effective end-user interfaces
2.05 Ability to collect metrics
2.06 Performance (speed of response to end-users),
2.07 Cross-platform compatibilities
2.08 Customer support
2.09 Availability of training in the tool
2.10 Documentation
2.11 Ease of use of the development environment,
2.12 Cost-effectiveness
Strongly
Agree
For questions 2 through 6, please check the category that you feel is most appropriate:
92
3
4
5
6
Defects in the automation tool affected the development effort.

System crashes affected the development effort.
It is difficult to recover from system crashes.
The automation tool supports a good range of hardware platforms.

This section deals with how the automated process was transitioned into use.
1 How long (in months) has it taken to transition the process to the production environment?
0-2
3-6
7-12
13-24
Over 24
Transition not completed
DK/NA
Strongly
Disagree
Disagree
3 Training was provided to support:
Agree
How long (in months) has the automated process been operating in a production environment (excluding tran-sitioning
time)?
Not yet in production
0-2
3-6
7-12
13-24
Over 24
DK/NA
Strongly
Agree
DK/NA
3.01 Implementers of the process-centered environment

3.02 End-users of the automated process
Statements 4 through 6 deal with end-users' involvement in the development process.
4
5
6
7
The process design was developed in conjunction with end-users

The process design was reviewed with the end-users
The end-user screens have been evaluated by the end-users
Process simulations have been performed with the end-users
Statements 8 through 13 deal with your impressions of end-users' operational experience

8 The automated process improves the effectiveness of end-users in performing
their task(s).
9 The end-users had difficulty in accepting the new process.
10 The end-users feel ownership towards the automated process
11 End-users make suggestions to improve the automated process
12 Metrics have been used to improve the automated process
13 There was resistance to process automation for the following reasons
13.01
Automation was viewed as externally imposed
13.02
Fear of job loss
13.03
Fear of change
13.04
The perception that process automation is too controlling
13.05
End-users feel that they were not consulted sufficiently
in process definition
13.06
Fear that metrics would be used in job evaluations
Statements 14 through 20 deal with management sponsorship.
14
15
16
17
18
19
20
Senior management is supportive of the process automation project

First-line management is supportive of the automation project
An automation business plan was written
A development plan was agreed to by management
The design was reviewed with management
The project has received adequate funding for transitioning
The automation project has a champion with designated authority
21 The automation initiative came from:

Technical staff
Management
A bit of both
Statements 22 through 23 deal with implementation strategy

22 A documented transition strategy was developed
23 A prototyping strategy is being used for implementation
24 The process model is being implemented:
All at once
In multiple incremental phases
Other (Specify)
DK/NA
93
DK/NA
Strongly
Disagree
Disagree
Agree
Strongly
Agree
Those automation projects that have progressed far enough will likely have practical insights of considerable value. We wish
to capture some of these insights in this section. Respondents who have additional insights, not covered in this section, are
encouraged to describe them textually.
1 To date, I consider the process automation project to be a success

2 Based on my experience, process automation has helped:
2.01 Improve end-user productivity
2.02 Improve product quality
2.03 Manage projects more effectively
2.04 Improve communication between end-users
2.05 Improve end-user job satisfaction
2.06 Improve end-user team-building
3 In the context of my application(s) I feel process automation:
3.01 Helps reduce tedium
3.02 Helps prevent errors
3.03 Supports administrative efforts
3.04 Provides useful process guidance,
3.05 Provides timely status information
3.06 Provides useful metric data
3.07 Reduces costs
4 Automation has helped to enforce defined process.
5 The technical implementation was more challenging than first thought
6 How well has the actual schedule for automation met the planned schedule?
Significant delays
Some delays
On time
Ahead of schedule
DK/NA
7 Based on our experience to date, we will automate additional processes
No
What is your job title?

Programmer
Senior Manager
Analyst
First-line Manager
SEPG/Quaity Assurance
Yes
DK/NA
External Consultant
Other (Specify)
IMPORTANT: The information below is optional. If you would like to remain anonymous, leave the spaces blank.
Name:
Organization:
Address:
Business Phone:
e-mail address:
Thank you very much for taking the time to complete the questionnaire
94
3.3.6
Statistical Analysis of Data
The following statistical techniques were used for analyzing the data as per
the objectives of the study stated earlier.
a. Nature of distributions by qualitative analysis using Histograms

This analysis is conducted to bring two important aspects of our research.
i.
There are 70 questions in the administered Questionnaire. Out of these, 11

questions have further sub-sections. The core topic of research Process
Automation is one area that was addressed by organizations of the Software
Industry at various points in time in various ways. It is important to know how
the people have approached and reacted to this initiative. This research has
taken data from four different organizations to bring out the similarities and
differences. By means of Histograms, the distribution analysis portrays the
numbers in a concise and clear view to help understand the pulse of the
respondents.
ii.
To support the research hypotheses, various types of analysis have been

conducted as mentioned below. These analyses involve cross referencing data
collected through multiple questions in the questionnaire. While Studying the
results of the below mentioned types of analysis along with the distribution
analytical results enables clear understanding of the outcome.
b. Correlation analysis using

i.
Chi-Square test of association of attributes - When Both Independent variable

and Dependent variable are Categorical: The chi-square test provides a
method for testing the association between the row and column variables in a
two-way table. The null hypothesis H0 assumes that there is no association
between the variables (in other words, one variable does not vary according to
the other variable), while the alternative hypothesis Ha claims that some
association does exist. The alternative hypothesis does not specify the type of
95
association, so close attention to the data (percentage comparison) is required

to interpret the information provided by the test.
ii.
Kruskal-Wallis of variation by rank - When Independent variable is

categorical and Dependent variable is Numeric: KruskalWallis test (named
after William Kruskal and W. Allen Wallis) is a non-parametric method for
testing whether samples originate from the same distribution. It is used for
comparing more than two samples that are independent. The factual null
hypothesis is that the populations from which the samples originate have the
same median. When the Kruskal-Wallis test leads to significant results, then at
least one of the samples is different from the other samples. The parametric
equivalence of the Kruskal-Wallis test is the one-way analysis of variance
(ANOVA). Since it is a non-parametric method, the KruskalWallis test does
not assume a normal distribution, unlike the analogous ANOVA.
iii.
Spearmans Correlation rho - When both Independent variable and Dependent

variable are Numeric: Correlation is a bivariate measure of association or the
relationship between two variables. It varies from 0 (random relationship) to 1
(perfect linear relationship) or -1 (perfect negative linear relationship). It is
sometimes reported in terms of its square (r2), interpreted as percent of
variance explained. For instance, if r2 is .25, then the independent variable is
said to explain 25% of the variance in the dependent variable. Beside
Pearsonian correlation (r), by far the most common type, there are other
special types of correlation to handle the special characteristics of such types
of variables as dichotomies, and there are other measures of association for
nominal and ordinal variables. Spearman's rank correlation coefficient ( )
named after Charles Spearman is a non-parametric measure of statistical
dependence between two variables.
A statistical significance coefficient is the chance that a relationship as strong

or stronger than the one observed was due to the chance of random sampling. Thus if
a correlation coefficient is significant at exactly the .05 level, this means there is 5%
chance that a correlation as strong or stronger than the observed one would result
96
from an unusual random sampling of data when in fact the correlation was zero.
3.4 ETHICAL CONSIDERATIONS
The Information Technology industry, more particularly the Software Service

Sector is a very competitive business. Software Service Organizations invent new
methods, new tools and new approaches to provide, cost effective, time to market and
quality services. Hence any initiative taken by them and the steps taken to implement
them are not publicly announced. Hence, most of the information is considered highly
confidential.
The respondents were initially reluctant to part with information pertaining to this
research. The researcher stated a clear repudiation to not disclose the organization names
of the respondents and also not give any indication as to identify the same. The
respondents were given only guidelines to fill the questionnaire and then given full
freedom to provide information that is known to them as authentic facts.
With the above constraints, although employees from four Software Service
Organizations have participated in this research survey, and their responses were
considered for analysis, their organization names are not disclosed in any of this report.
3.5 CONCLUSION
The research methodology was designed to with multiple aspects considered and
evaluated. The Information Technology industry has its own means of adopting new
initiatives and some impact the whole organization and some only impact a particular
group or department. Similarly, there are employees of these organizations spread all
over the globe in various hierarchical positions and may or may not be in a position to
respond. The analysis of information required applications of highly tailored statistical
tools. Ultimately, a framework of research methodology was designed to help this
research bring out a concrete outcome.
97
CHAPTER IV: ANALYSIS
4. 1
INTRODUCTION ................................................................................................. 99
4. 2
DISTRIBUTION ANALYSIS ............................................................................... 99
4. 3
CORRELATION ANALYSIS............................................................................. 187
4. 4
CONCLUSION .................................................................................................... 378
This chapter presents extensive analysis of the data collected through

interviewing method and collated from four different Software Services Organizations.
Firstly, the nature of the participating organizations were analyzed and found that the four
organizations are homogenous in nature. Next the responses were studied through
distribution analysis to understand the characteristics of organizations, process
characteristics, focus on the initiative, development, deployment and training
methodologies adopted. It also analyses the impacts of the introducing the Process
Automation tool across the organizations and the learnings from the same. Correlation
analysis attempts to understand the relation between various groups of information
gathered to finally derive a conclusion on the objective of the research.
98
CHAPTER IV
ANALYLSIS
4. 1 INTRODUCTION
In the present study, employees from four different Information Technology
Organizations have participated and responded to the questionnaire distributed. They are
all CMMI 5 certified organizations and hence very strong in their process definitions and
implementations. 2 Indian organizations and 2 MNC organizations having offices in India
were covered. 83 fully completed questionnaires were taken up for analysis. Information
related to these organizations, Software Process Automation methodologies adopted by
them and their outcomes are collected and collated under seven broad categories as
mentioned below:
B. Process Automation Implementation Team Characteristics
C. Application Focus (Processes that were automated)
E. Development Technology (Automation)
4. 2 DISTRIBUTION ANALYSIS
In this research work, information has been gathered to support the context of the
thesis subject. This study spans the width and depth of the Software Process Automation
and hence very rich in information. Therefore, a distribution analysis is applied to derive
a qualitative and quantitative inferences from this information.
99
4.2.1.
Respondents Analysis
This subsection of Distribution Analysis presents the nature of organizations

whose employees have participated in the study before we dwell deep into the subject
matter.
Organization
INT-1
INT-2
NAT-1
NAT-2
Total
Respondents
27
16
19
21
83
Respondents %
32.53%
19.28%
22.89%
25.30%
100.00%
Figure GEN-01: Number of respondents from each organization

The result of the above table and graph represents the distribution of study
subjects according to their organizations that they are employed in. The two Indian
organizations are titled NAT-1 and NAT-2 respectively instead of their original names to
maintain confidentiality. Similarly, the two Indian organizations are titled INT-1 and
INT-2 respectively. Out of 83 subjects, 27 subjects from INT-1 responded which is
25.30% contribution to the study information, 16 subjects from INT-2 responded which is
19.28% contribution to the study information, 19 subjects from NAT-1 responded which
is 22.89% contribution to the total study information and 21 subjects from NAT-2
responded which is 32.53% contribution to the study information,.
Organization Type
INT
NAT
Total
Respondents
43
40
83
Respondents %
51.81%
48.19%
100.00%
Figure GEN-02: Number of respondents from each organization

100
Figure GEN-02 shows that the distribution of subjects across various roles in the
hierarchy of the organization. It can be noticed that 45% of the subjects are in the
management and consultants category and remaining 55% belong to the technical group.
In this manner, the breadth is covered to ensure all round feedback.
Viewing the distribution of subjects between Indian and International
organizations, it is noted that that there is an equal participation by both categories.
Respondents from Indian organizations count to 40 which is 48.19% of the total sample
population and respondents from Multinational organizations count to 43 which is
51.81% of the total sample population. Hence it is believed that this representation would
provide information that would enable a balanced data for this particular research.
Organization
INT-1
INT-2
NAT-1
NAT-2
Respondents
27
16
19
21
Organization
Strength ('000)
400
150
103
98
Figure GEN-03: Number of respondents Vs Organization Strength
The result of the above table represents the sample size verses the total
population. It is important to note that the total population here denotes only the
organization strength of the only four participating organizations and not all the IT
organizations present in the world. Moreover, not all employees are aware of process
automation initiatives. Further, all employees who are aware of these initiatives may not
be directly involved in the process automation implementation activities. Hence, it is
important to understand the sample size in conjunction with the process automation
implementation team size.
101
27
30
21
25
Role
Senior Manager
First Line Manager
Anaysts/Architects
Programmers
SEPG/QA
No. of Respondents
7
27
21
18
7
3
18
20
15
10
7
3
Figure GEN-04: Number of respondents and their Organization Role
4.2.2.
Response Analysis
This subsection of Distribution Analysis presents the analysis of the responses

provided by the representatives of the participating organizations. This analysis is once
again collated in the seven broad categories as explained in the Introduction subsection.
These groups of questions are aimed at understanding the business that these
organizations conduct or the products that they deal with and also their clientele. Here,
the focus is also to find out the cultural aspects of these organizations.
102
1. Industries supported
Industries Supported
Aerospace and Defense
Agriculture
Airlines
Automotive
Banking and Capital Markets
Cloud services
Communication Media and Entertainment
Consumer Packaged Goods
Cybersecurity
Discrete Manufacturing
Education
Energy
Government
Healthcare
High Technology
Hospitality and Gaming
Insurance
Life Sciences
Logistics and Transportation
Manufacturing
Public safety, justice, welfare
Publishing
Revenue and Tax
Resources
Retail
Studios and Networks
Utilities
Other (specify)
Respondents
83
43
67
62
83
83
83
83
83
67
62
83
64
83
62
67
83
83
83
83
43
46
43
46
83
46
83
4
Figure GRP-A-01: Industries supported by organizations

It is observed through the above table and graph that the organizations of the
respondents cater to all kinds of industries in the world by providing software services
and solutions to them. All the respondents have said that their organization provides
services to Aerospace and Defense, Banking and Capital Markets, Cloud services,
Communication, media and entertainment, Cyber security, Energy, Healthcare,
Insurance, Logistics and Transportation, Manufacturing, Retail and Utilities industries.
67 respondents have said that Airlines, Discrete manufacturing and Hospitality industries
are the customers of their organization. Government is an industry which is chosen by 64
respondents as being their customer while 62 respondents have identified Automotive,
Education, High technology are serviced by their organizations. About 46 respondents
have said that Publishing, Resources and Studios and networks industries are their
customers. Agriculture, Public safety, justice and welfare and Revenue and tax are the
103
industries indicated by 43 respondents as being serviced by their organization. Only four

respondents have said that there are industries other than listed which are serviced by
their organization.
2. Organization type
Organization Type
Government
Commercial
Academic
Total
Respondents
0
83
0
83
Respondents %
0.00%
100.00%
0.00%
100.00%
Figure GRP-A-02: Organization type
The above table and graph shows clearly that all respondents (100%) are from
organizations that are commercial in nature.
3. Organizations products/services
Products and Services

One-of-a kind
Customized
Mass-produced
Application Development
Maintenance
Other
Respondents
8
22
9
37
32
5
Respondents %
9.64%
26.51%
10.84%
44.58%
38.55%
6.02%
Figure GRP-A-03: Focus on Products and Services
The above table and graph indicates that maximum respondents (37,44.58%) have
said that Application development is the major service for their organization. Next, 32
respondents (38.55%) have said Maintenance is one equally common service provided.
About 22 respondents (26.51%) have said their organizations provided customized
solutions. Then, 9 and 8 respondents (9.64%,10.84%) have said that Mass production,
One-of-a-kind software are developed by their organizations respectively. 5 respondents
104
(6.02%) have said there are services other than indicated being provided by their
organizations.
4. The IT services provided
IT Services
Application Services
Architecture Services
Business Consultation
Enterprise Quality Services
Independent Validation Services
Information Management Services
Infrastructure Services
Knowledge Services
Packaged Application Services
SOA Services
Systems Integration Services
Respondents
83
83
62
83
56
56
56
83
83
83
83
Respondents %
100.00%
100.00%
74.70%
100.00%
67.47%
67.47%
67.47%
100.00%
100.00%
100.00%
100.00%
Systems Integration Services
100%
SOA Services
100%
Packaged Application Services
100%
100%
Knowledge Services
Infrastructure Services
67%
Information Management Services
67%
Independent Validation Services
67%
100%
Enterprise Quality Services

75%
Business Consultation
100%
Architecture Services
100%
Application Services
0% 20% 40% 60% 80% 100%
Figure GRP-A-04: IT Services provided by the organizations
The above table and graph indicates that all respondents (100%) have said
Application software, Architecture services, Enterprise quality services, Knowledge
services, Packaged application services, SOA services and System integration services
are their primary business. While 62 respondents (74.7%) have said that Business
consultation is part of their business, about 56 respondents (67.47%) have said that
Independent validation services, Information management services and Infrastructure
services are their business too.
5. Frequency of organizational change that affects normal work
Organizational Changes
Every few months
Yearly
Every few years
Dont know/Not applicable
Total
Respondents
10
31
23
16
3
83
Respondents %
12.05%
37.35%
27.71%
19.28%
3.61%
100.00%
Figure GRP-A-05: Frequency of Organization Changes
105
In the above table and graph, it is observed that 31 respondents (37.35%) said that
their organizations undergo changes one every year. This is typically the case where the
organization takes stock of performance for one whole year and make changes to
improve their performance for the coming years. 23 respondents (27.71%) have said that
their organizations undergo changes once every few years which indicates that either
their organizations are too stable or that they are afraid of taking risks and avoid changes
as much as possible. About 10 respondents have denoted that their organizations undergo
changes every few months which is a sign of the organizations volatility and that they
take big risks. 16 respondents (19.28%) have said that they have never seen a change
implementation in their organization. This could imply that either their organization does
not undergo any changes or that their working conditions and business situations do not
have necessity to change.
6. Organization's culture Here the business culture of the organization is studied.

a.
Risk takers / Neutral / Conservative
Organization Culture
Risk Takers
Neutral
Conservative
Total
Respondents
37
17
8
62
Respondents %
59.68%
27.42%
12.90%
100.00%
Figure GRP-A-06-01: Risk takers Vs Conservative Organizations
In the above table and graph, out of 62 respondents who answered, it is observed
that 37 respondents (59.68%) agree that their organizations are risk takers while only 8
respondents (12.9%) feel that theirs is a conservative organization. However, 17
respondents (27.42%) have said that their organizations are neither total risk takers nor
totally conservative in their approach.
106
b.
Formal / Neutral / Informal
Formal
Neutral
Informal
Total
Respondents
34
13
14
61
Respondents %
55.74%
21.31%
22.95%
100.00%
Figure GRP-A-06-02: Formal Vs Informal Organizations
that 34 respondents (55.74%) agree that their organizations are formal while only 14
respondents (22.95%) feel that their organizations follow a informal approach. However,
13 respondents (21.31%) have said that their organizations are neither totally formal nor
completely follow informal.
c.
Many layers / Mixed / Flat organization structure
Many Layers
Neutral
Flat Organization
Total
Respondents
44
8
9
61
Respondents %
72.13%
13.11%
14.75%
100.00%
Figure GRP-A-06-03: Organization Structure
In the above table and graph, out of 61 respondents who answered, it is quite
apparent that many layered organizations is prevalent since 44 respondents (72.13%)
agree to this type while only 9 respondents (14.75%) feel that their organizations are flat
structure. There are about 8 respondents (13.11%) who said that their organizations are
107
neither layered nor flat which means theirs is a structure that is designed with both modes
according to convenience.
d.
Controlling / Neutral / Hand-off management
Controlling
Neutral
Hands-off
Total
Respondents
39
18
10
67
Respondents %
58.21%
26.87%
14.93%
100.00%
Figure GRP-A-06-04: Controlling Vs Hands-off Organizations
that 38 respondents (58.21%) agree that their organizations operate in controlled
environment while only 10 respondents (14.93%) feel that their organizations operate in a
hands-off environment. But, 18 respondents (26.87%) have said that their organizations
are neither totally controlled nor completely hands-off which is a good combination that
not only retains certain amount of discipline but also provides opportunities for
employees to experiment and innovate new solutions.
e.
Static environment / Neutral / Dynamic environment
Static environment
Neutral
Dynamic environment
Total
Respondents
7
11
45
63
Respondents %
11.11%
17.46%
71.43%
100.00%
Figure GRP-A-06-05: Static Vs Dynamic Environment
108
that 45 respondents (71.43%) agree that their organizations work under a dynamic
environment which is easily adaptable to change and adopts to new initiatives easily.
Only 7 respondents (11.11%) have said that their organizations are working under a static
environment which may be the case their business needs are not so varied and volatile.
However, 11 respondents (17.46%) have said that their organizations worked in a mixed
environment which is neither static nor dynamic.
f.
Complacent / Neutral / Energetic
Complacent
Neutral
Energetic
Total
Respondents
4
13
44
61
Respondents %
6.56%
21.31%
72.13%
100.00%
Figure GRP-A-06-06: Complacent Vs Energetic
In the above table and graph, out of 61 respondents who answered, it is clearly
seen that 44 respondents (72.13%) consider that the employee behavior is energetic
which gives an enjoyable ambience to work in such places. Only 4 respondents (6.56%)
have said that the employees are complacent that may give a stable and contented place
to work in but not be a fast growing environment. About 13 respondents (21.31%) have
said that some employees are energetic while some are complacent.
109
g.
Closed minded / Neutral / Open minded
Closed minded
Neutral
Open minded
Total
Respondents
5
13
48
66
Respondents %
7.58%
19.70%
72.73%
100.00%
Figure GRP-A-06-07: Closed minded Vs Open minded
In the above table and graph, out of 66 respondents who answered, it is apparent
that the industry itself has an open minded culture. About 48 respondents (72.73%) say
that employees are encouraged to be open minded which means that they are motivated to
voice their opinions, concerns and even new ideas. Some organizations adopt 360
feedback which helps to understand the expectations and capabilities and match them to
derive desired outcomes. Only 5 respondents (7.58%) have said that employees are
closed minded which means that there is no transparency in the work allocation or
feedback among superiors, subordinates and peers. However, 13 respondents (19.7%)
have said that there is a both open minded and closed minded employees working in their
organizations.
h.
Political / Neutral / Non-political
Political
Neutral
Non-political
Total
Respondents
9
23
27
59
Respondents %
15.25%
38.98%
45.76%
100.00%
Figure GRP-A-06-08: Political Vs Non-political
110
that 23 respondents (38.98%) say that that their organizations conduct business with a
neutral approach. About 27 respondents (45.76%) have said that their organizations are
completely non-political in their business while 9 respondents (15.25%) have said that
their organizations conduct business with a political approach.
i.
Jobs are routine / Neutral / Jobs are exciting
Jobs are routine
Neutral
Jobs are exciting
Total
Respondents
17
17
29
63
Respondents %
26.98%
26.98%
46.03%
100.00%
Figure GRP-A-06-09: Jobs are routine Vs Jobs are exciting
that 29 respondents (46.03%) agree that their jobs are exciting which means it provides
challenging environments to work in and provide great opportunities for innovations. The
employees get to work in new technologies, build complex solutions under tight schedule
and budget. Only 17 respondents (26.98%) have said that their jobs are routine which
means that their jobs are day-to-day mundane activities that is boring and uninteresting.
Typically service projects that include activities such job cycle monitoring, server
maintenance, data fixes, etc. are not brain teasers and create boredom and lethargy. 17
respondents (26.98%) have said that their organizations do have both exciting and routine
jobs as well. However, organizations such as this make sure the employees are rotated
between these two types to increase employee satisfaction and encourage them to deliver
better outputs.
111
j.
Stable staff / Neutral / High turnover (attrition
Stable staff
Neutral
High turnover
Total
Respondents
16
22
23
61
Respondents %
26.23%
36.07%
37.70%
100.00%
Figure GRP-A-06-10: Stable staff Vs High turnover
that 23 respondents (37.7%) agree that their organizations have a high turnover where as
16 respondents (26.23%) have stable staff in their organizations. However, 22
respondents (36.07%) have said that their organizations have stable staff but may also
face high turnover at some points in time.
B. Process Automation Implementation Team Characteristics
Every organization that has adopted process automation has its own
implementation team. The characteristics of these teams will give an idea of how much
importance and focus is given to this process automation.
1. Process automation development team
Development Team Size

<6
7-10
11-20
Over 20
Total
Respondents
0
0
45
31
76
Respondents %
0.00%
0.00%
59.21%
40.79%
100.00%
112
Figure GRP-B-01: Process automation development team size
that 31 respondents (40.79%) say that their process automation development team size is
greater than 20. About 45 respondents (59.21%) say that process automation
development team size is between 11 and 20. Overall it is observed that 76 respondents
which is a good 92% of total respondents say their process automation development team
size is greater than 10. This implies that software organizations are giving adequate
importance and focus to process automation initiatives.
2. Process automation team leaders experience
Team Leader Experience

0-2
3-5
6-10
11-15
Over 15
Total
Respondents
0
1
7
39
31
78
Respondents %
0.00%
1.28%
8.97%
50.00%
39.74%
100.00%
Figure GRP-B-02: Process automation team leader experience
that 31 respondents (39.74%) say that their process automation team leader has more than
15 years of experience. About 39 respondents (50%) say that process automation team
leader has 11 to 15 years of experience. About 7 respondents (8.97%) say that process
automation team leader has 6 to 10 years of experience and only 1 respondent (1.28%)
said that process automation team leader has 3 to 5 years of experience. It is evident that
a total of 70 respondents which is a good 84% of respondents say their process
automation team leader has more than 10 years of experience. This again indicates that
the organizations ensure the initiative is led by a highly experienced person so as to make
it a success.
113
3. The respondents experience
Respondent Experience
0-2
3-5
6-10
11-15
Over 15
Total
Respondents
13
23
24
21
2
83
Respondents %
15.66%
27.71%
28.92%
25.30%
2.41%
100.00%
Figure GRP-B-03: Respondents experience
In the above table and graph, it is observed that 2 respondents (2.41%) with more
than 15 years of experience have responded. About 21 respondents (25.3%) with 11 to 15
years of experience have responded. About 24 respondents (28.92%) with 6 to 10 years
of experience and about 23 respondents (27.71%) with 3 to 5 years of experience and 13
respondents (15.66%) with less than 3 years of experience have responded. The responses
seem to be widely spread and hence it can only be observed that as 47 respondents which
is a good 56% of respondents with more than 5 years of experience have responded by
which it can be said that the data provided by them is with personal experience with the
Process automation initiative.
4. The teams experience
Respondent Experience
Process definition
Process-centered
environment development
Tool integration
Computer networking
Training
Yes
83
Yes%
100.00%
No
0
No%
0.00%
83
81
59
77
76
100.00%
97.59%
89.39%
97.47%
91.57%
0
2
7
2
7
0.00%
2.41%
10.61%
2.53%
8.43%
Figure GRP-B-04: Process Automation Development Teams Experience
114
In the above table and graph, it is observed that all 83 respondents (100%) say
that their process automation development team has personnel experienced in the areas of
process definition and process centered environment development. 81 respondents
(97.59%) say that process automation development team has personnel experienced in
tool integration. About 77 respondents (97.47%) say that process automation
development team has personnel experienced in transition and adoption. 76 respondents
(91.57%) say that process automation development team has personnel experienced in
training the end-users of process automation tool while 59 respondents (89.39%) say that
process automation development team has personnel experienced in computer
networking. 52 respondents (62.65%) say that their process automation development
team has personnel experienced in all the six areas. 81 respondents (97.59%) say that
their process automation development team has personnel experienced in process
definition, process centered environment and tool integration. Of this 81, 57 respondents
say that their process automation development team has personnel experienced also in
computer networking. Of the same 81, 75 respondents (70.37%) say that their process
automation development team has personnel experienced also in transition and adoption.
Again of the same 81, 76 respondents (93.83%) say that their process automation
development team has personnel experienced also in training. Of the 57 respondents who
said that their say that their process automation development team has personnel
experienced process definition, process centered environment, tool integration and
computer networking, 56 respondents (98.25%) say that their process automation
development team has personnel experienced also in transition and adoption. Of the same
57, 52 respondents (91.23%) say that their process automation development team has
personnel experienced also in training. Of the 75 respondents who said that their say that
their process automation development team has personnel experienced process definition,
process centered environment, tool integration and transition and adoption, 71
respondents (94.67%) say that their process automation development team has personnel
experienced also in training.
115
5. Representation from End-user
End-User Represenation
Yes
No
Total
Respondents Respnodents%
68
87.18%
10
12.82%
78
100.00%
Figure GRP-B-05: Representation from End-users
that all 68 respondents (87.18%) say that their process automation development team has
representation from the end-users also. This indicates that the organizations are particular
that the process automation tool being developed and implemented is user friendly and
caters to the end users needs to be able to follow the defined processes without much
hassle.
6. Expertise of External Consultants utilized
Expertise
Yes
No
Total
Respondents Respnodents%
38
31
69
55.07%
44.93%
100.00%
Figure GRP-B-06: Utilization of Expertise of External Consultants
that 38 respondents (55.07%) say that their organizations employ external consultants to
116
help implement the process automation initiative. This indicates that some organizations
utilize the expertise of external consultants. The reasons for this could be that the
processes defined for each organization are unique in nature and may not be known by
external people. Also, these organizations themselves are software development experts
and hence develop their own process automation tools to suit their specific needs.
7. Expertise of Sub-contractors utilized
Subcontractors
Expertise
Yes
No
Total
Respondents
10
52
62
Respnodents%
16.13%
83.87%
100.00%
Figure GRP-B-07: Utilization of Expertise of Sub-contractors
that all only 10 respondents (16.13%) say that their organizations employ external
consultants to help implement the process automation initiative. This indicates that not
many organizations sub-contract such initiatives. The reasons for this could be that the
processes defined for each organization are unique in nature and may not be known by
external people. Also, these organizations themselves are software development experts
and hence develop their own process automation tools to suit their specific needs.
C. Process Automation Application Focus
Every organization has its own modes of adopting Process Automation Initiative.
It may vary in the number of process being automated, adequate funding, involvement of
process users, all processes automated at once or in phases, etc. These characteristics of
process automation application focus will give an idea of how organizations have
embarked on the journey of Software Process Automation Adoption.
117
1. Areas of Process that Automation addresses
Process Areas
Project Planning
Project closure
Design
Valiation/Testing
Release Management
Deployment
Hardware/Software
Servicing
Change Management
Document Management
Document Review
Supplier Management
TQM Tools
Six Sigma Tools
Lean Principles
Respondents Respondents %
83
100.00%
83
100.00%
83
83
100.00%
100.00%
60
61
33
83
83
83
61
24
83
72.29%
73.49%
39.76%
100.00%
100.00%
100.00%
73.49%
28.92%
100.00%
83
83
100.00%
100.00%
83
24
61
100.00%
28.92%
73.49%
10
10
0
0
0
12.05%
12.05%
0.00%
0.00%
0.00%
Lean Principles
0.00%
Six Sigma Tools
0.00%
TQM Tools
0.00%
Supplier Management
12.05%
12.05%
73.49%
Document Review
Document Management
28.92%
100.00%
Change Management
100.00%
100.00%
100.00%
Deployment
28.92%
73.49%
Release Management
100.00%
Valiation/Testing
100.00%
100.00%
39.76%
Design
73.49%
72.29%
Project closure
100.00%
100.00%
Project Planning
100.00%
100.00%
0% 20% 40% 60% 80% 100%
Figure GRP-C-01: Areas of Process Automated
In the above table and graph, it is observed that, out of 83 respondents all 83
respondents (100%) say that Process Automation solution addresses process areas such as
Project Initiation/Startup, Project Planning, Project Tracking and Oversight, Project
Closure, Verification/Reviews, Validation/Testing, Defect/Anomaly Tracking, Software
Maintenance, Hardware/Software Servicing, Change Management and Configuration
Management are all automated. Then 61 respondents (73.5%) say that Design, Release
and Document Review processes are addressed by their Process Automation Solution. 60
respondents (72.29%) say that Release Management process is part of the Process
Automation solution. Deployment and Document Management are the processes are
included in Process Automation, say 24 respondents (28.92%). Just 10 respondents
118
(12.05%) say that Subcontractor Management and Supplier Management processes are
added in Process Automation. Processes and Tools defined by TQM, Six Sigma and Lean
Methodology are not addressed by Process Automation. It is understood from these
results, that main processes related to Project Management and Software Development
Process are normally addressed Process Automation. Other processes that are not critical
but only enhancing performance may be included in Process Automation. Processes that
refine existing processes to bring in better performance and quality are either not
included. This may be because, Process Automation solutions that are available in the
market usually only address critical process areas that are defined by standard Process
Systems such as ISO and CMMi. Organizations will then have to purchase these products
and customize it to suit their requirements and also enhance it to include other process
areas specifically defined for themselves.
2. Motivating Elements
2.41%
DN/NA
12.05%
Others
86.75%
Process Improvement
37.35%
Motivating Elements
Time to market
Quality
Metrics
Process Improvement
Others
DN/NA
29
34.94%
71
85.54%
64
77.11%
68
81.93%
31
37.35%
72
86.75%
10
12.05%
2
2.41%
81.93%
Metrics
77.11%
Quality
85.54%
34.94%
Time to market
0%
20%
40%
60%
80% 100%
Figure GRP-C-02-01: Motivating Elements
In the above table and graph, it is observed that, out of 83 respondents, 72 respondents
(86.75%) say that Process Improvement is the key reason for their organizations to go for
Process Automation. About 71 respondents (85.54%) say that Management Oversight is
the key for Management to take up Process Automation. About 68 respondents (81.93%)
say that Metrics collection and collation is the motive for their organizations to adopt
119
Process Automation. 64 respondents (77.11%) say that Quality is the one of the reasons
which motivates organizations to go for Process Automation. 31 respondents (37.35%)
say that Productivity Improvement is the reason for Organizations initiating Process
Automation. 29 respondents (%) say that Time to Market is one such reason for Process
Automation being initiated in organizations. Only 10 respondents (%) say that there are
some other reasons. There are multiple reasons which may motivate initiation of Process
Automation in organizations.
No. Motivating Elements

6
5
4
3
2
1
0
13
15.66%
24
28.92%
27
32.53%
4
4.82%
4
4.82%
9
10.84%
2
2.41%
Figure GRP-C-02-02: Motivating Elements
As discussed above, there are six major reasons for any organization to have
pointed as key reasons for proceeding to implement Process Automation. In the above
table and graph, it is observed that, out of 83 respondents, 13 respondents (15.66%) say
that all the six reasons motivated their organizations to go for Process Automation. About
24 respondents (28.92%) say that 5 out 6 elements are key reasons for Management to
take up Process Automation. About 27 respondents (32.53%) say that 4 out of 6 elements
are motives for their organizations to adopt Process Automation. 4 respondents (4.82%)
say that 3 out of 6 and 2 out of 6 reasons which motivates organizations to go for Process
Automation respectively. Around 9 respondents (37.35%) say that Productivity
Improvement is the reason for Organizations initiating Process Automation. 29
respondents (%) say that Time to Market is one such reason for Process Automation
being initiated in organizations. Only 10 respondents (10.84%) say that there is just one
reason that led to Process Automation initiative in their organizations. However, 2
120
respondents (2.41%) feel that none of the listed elements are reason enough for their
organizations to implement Process Automation.
It is important to notice from the responses organizations do conduct elaborate

study to check out if the process automation initiative is worth it. They evaluated many
factors to ensure that there are enough reasons to embark upon this automation journey.
3. Adequate Funding
Adequate
Funding
Yes
No
DN/NA
Respondents
Respondents %
58
19
6
69.88%
22.89%
7.23%
Figure GRP-C-03: Adequate Funding
In the above table and graph, it is observed that, out of 83 respondents, a good
number of 58 respondents (69.89%) felt that management of their organizations provided
adequate funding for implementing Process Automation initiative. However, 19
respondents (22.89%) felt that adequate funding was not provided by their organizations
to ensure successful implementation of Process Automation. 6 respondents (7.23%) did
not have knowledge of whether their organizations provided adequate funding or not.
4. Process User Involvement
121
Process User
Involvement
Respondents
Respondents %
15
25
20
17
6
18.07%
30.12%
24.10%
20.48%
7.23%
1-5
6-10
11-20
Over 20
DN/NA
Figure GRP-C-04: Process User Involvement
In the above table and graph, it is observed that, out of 83 respondents, about 17
respondents (20.48%) say that over 20 process users were involved in implementing
Process Automation in their organizations. Another 20 respondents (24.1%) say that over
11-20 process users were involved in implementing Process Automation in their
organizations. A good 25 respondents (30.12%) say that over 20 process users were
involved in implementing Process Automation in their organizations.
And 15
respondents (18.07%) say that over 20 process users were involved in implementing
Process Automation in their organizations. Just 6 respondents (7.23%) were not aware
how many process users were involved in implementing Process Automation in their
organizations. It is good to observe that about 62 respondents (74.7%) say that Process
User involvement in Process Automation implementation is greater 5 members.
5. Elapsed days
Elapsed Days
Less than 1
1-10
11-100
Over 100
DN/NA
Respondents
0
9
60
10
4
Respondents %
0.00%
10.84%
72.29%
12.05%
4.82%
122
Figure GRP-C-05: Elapsed Days from Initiation to Completion of Process

Automation
In the above table and graph, it is observed that, out of 83 respondents, 60

respondents (72.29%) say that every process that is automated takes an average of 11-100
elapsed days from initiation to completion. Just 10 respondents (12.05%) say that every
process that is automated takes more than 100 elapsed days from initiation to completion.
Only 9 respondents (10.84%) say that every process that is automated takes an average of
1-10 elapsed days from initiation to completion. 4 respondents (4.82%) do not know how
long it takes for a single process automation to roll out into production.
6. Number of Processes Automated
Processes currently
automated
Respondents
Respondents %
5
6
7
8
9
10
11
8
12
23
25
8
6
1
9.64%
14.46%
27.71%
30.12%
9.64%
7.23%
1.20%
Figure GRP-C-06: Number of Process Automated
In the above table and graph, it is noticed that, maximum of 11 processes have
been automated so far and only 1 respondent (1.2%) said this. 6 respondents (7.23%) say
that 10 processes were automated, 8 respondents (9.64%) say that 9 processes were
automated and 25 respondents (30.12%) say that 8 processes were automated. It is found
that 23 respondents (27.71%) say that 7 processes were automated, 12 respondents
(14.46%) say that 6 processes were automated and 8 respondents (9.64%) say that only 5
processes were automated. It is clear that all organizations have automated 5 or more
processes.
7. Number of Processes in Operation

123
Automated Processes in
Respondents
Operation
4
16
30
5
14
6
16
7
8
1
9
6
Respondents %
19.28%
36.14%
16.87%
19.28%
1.20%
7.23%
Figure GRP-C-07: Number of Process in Operation
In the above table and graph, it is noticed that, maximum of 9 processes have
been deployed in production so far and 6 respondents (7.23%) said this. Just 1 respondent
(1.2%) says that 8 processes have been deployed in production, 16 respondents (19.28%)
say that 7 processes have been deployed in production and 14 respondents (16.87%) say
that 6 processes have been deployed in production. It is found that 30 respondents
(36.14%) say that 5 processes were implemented and in operation and 16 respondents
(19.28%) say that 4 processes were implemented and in operation. It is seen that there are
some processes automated by these organizations but not moved into production
environment for use by the end-users.
8. Day-to-Day use of Processes
Processes in Day-to-Day
Use
Respondents
Yes
77
No
2
4
DN/NA
Respondents %
92.77%
2.41%
4.82%
Figure GRP-C-08: Day-to-Day use of Processes
In the above table and graph, it is clearly noticed that a huge 77 respondents
(92.77%) have said that the processes that are deployed into production environment are
124
being used on a day-to-day basis. Only 2 respondents (2.41%) have stated that the
processes that are deployed into production environment are being used on a day-to-day
basis. However, 4 respondents (4.82%) are exceptions who are unaware if all processes
that are automated and deployed into production environment are being used on a day-today basis or not. It is very clear that Process Automation initiative is being taken quite
seriously starting from Management to End-users and they give due importance and make
sure that for the effort that is put, this initiative is put to good use.
9. Frequency of Process Execution
Frequency Processes
Executed
Respondents
Respondents %
0
0
83
0
0
0.00%
0.00%
100.00%
0.00%
0.00%
Less than 1
1-10
11-100
Over 100
DN/NA
Figure GRP-C-09: Frequency of Process Execution
In the above table and graph, it is perceived all 83 respondents (100%) have said
that around 11-100 times the process automation tool is used in a month. It just goes to
show that the process automation tool is completely intertwined with project execution
and becomes an excellent method to plan, execute and track a project through defined
processes with ease.
10. Automation Activities Included
125
Automation Activities
Include
Respondents
Respondents %
No Product Purchased
0.00%
0.00%
0.00%
0.00%
0.00%
83
100.00%
Commercial Tool
Under Evaluation
Defining First Process
Developing First
Implementation
One Implementation
on Trial
One Implementation
Deployed
Figure GRP-C-10-01: Automation Activities Included
In the above table and graph, without any argument, it is good to know that all
organizations have gone a long way in the area of Software Process Automation. All 83
respondents (100%) have said that their organization has already successfully deployed
one process automation implementation. This goes to show that these organizations are
not only mature in defining and following stringent processes, they also ensure ease of
use of the same processes by automating them and making it available for the end-users
in a more structured manner.
With this result, following analysis helps to understand what further activities are
planned by these organizations with respect to this Software Process Automation
initiative.
Planned Additional
Process Automation
Yes
No
DN/NA
Respondents
59
14
10
Respondents %
71.08%
16.87%
12.05%
Figure GRP-C-10-02: Planned Additional Process Automation
126
In the above table and graph, it is observed that 59 respondents (71.08%) say that
there is continuous work going on with respect to this initiative. Automation of more
processes are planned which means that the earlier process automation activities have
been successful; there is still scope for more processes to be automated. About 14
respondents (16.87%) have said that there are no plans for automating additional
processes. This could either mean that all processes in the entire organization has been
completely automated and hence no further action required or the previous process
automation activities that were taken up have not given the desired results and hence no
further enhancement has been taken up. Only 10 respondents (12.05%) have said that
they were not aware if any plans were made to add more processes to the automated tool.
Additional Processes
Under Development
Yes
No
DN/NA
Respondents
60
17
6
Respondents %
72.29%
20.48%
7.23%
Figure GRP-C-10-03: Additional Processes under Development
In the above table and graph, it is observed that 60 respondents (72.29%) again
say that there is continuous work going on with respect to this initiative. Not only
automation of more processes is planned but also there are process automation
constructions that are currently in progress. About 17 respondents (20.48%) have said
that there are no process automation construction activities going on. This could mean
that processes to be automated are being planned and construction work would start soon.
Also, this could either mean that all processes in the entire organization has been
completely automated and hence no further action required or the previous process
automation activities that were taken up have not given the desired results and hence no
further enhancement has been taken up. Only 6 respondents (7.23%) have said that they
were not aware if any process automation construction activities are happening in their
organizations.
127
Being Implemented
Yes
No
DN/NA
Respondents
65
7
11
Respondents %
78.31%
8.43%
13.25%
Figure GRP-C-10-04: Additional Processes being Implemented
In the above table and graph, it is observed that 65 respondents (78.31%) have
indicated that there is continuous work going on with respect to this initiative by
answering this particular question. It shows that in most organizations, additional
processes are being automated and implemented even at the time of this research study.
Just about 7 respondents (8.43%) have said that there are no additional processes that
were automated and are under implementation now. This could either mean that all
processes in the entire organization has been completely automated and hence no further
action required or the previous process automation activities that were taken up have not
given the desired results and hence all further activities have been abandoned. Only 11
respondents (13.25%) have said that they were not aware if any additional processes were
automated and are under implementation.
Successfully Deployeed Respondents
66
Yes
5
No
12
DN/NA
Respondents %
79.52%
6.02%
14.46%
Figure GRP-C-10-05: Additional Processes Successfully Deployed
In the above table and graph, it is observed that 66 respondents (79.52%) have
indicated Process Automation initiative has taken a successful journey by answering this
128
particular question. It shows that in most organizations, additional processes are already
deployed successfully. Just about 5 respondents (6.02%) have said that no additional
processes are deployed. This could probably mean their organizations did not proceed
further in deploying additional processes but this number could be ignored since it is
small in comparison. Only 12 respondents (14.46%) have said that they were not aware if
any additional processes were automated and are under implementation.
Overall, it is perceived all organizations that have been covered in this particular
research work have gone through a line of thorough evaluation, defined processes for
implementation, implemented and deployed which in itself are success stories that speak
for Software Process Automation.
The software services industry plays an important role in the business of every
other industry in the world today. Hence, software services industry holds a high
responsibility in delivery cost effective services to their customers on time with high
quality. As part of this endeavor, software services organizations use highly matured
Process System to maintain quality. At times, Process Systems maintain quality but
reduce productivity thereby reducing cost. That is why, organizations adopt automation
of these Process Systems. However, if the Process Systems themselves are not defined
properly and then taken up for Process Automation, then the whole initiative could fail.
Hence, it is highly critical that first Process Systems are set up properly and then a
methodical way is used to translate the same into an automated solution. This section
attempts to understand how organizations have taken this journey from defining
processes to automating them.
1. Documented Process Improvement Plan
129
Documented Process
Improvement plan
83
0
0
Yes
No
DN/NA
100.00%
0.00%
0.00%
Figure GRP-D-01: Documented Process Improvement Plan
In the above table and graph, it is observed that, out of 83 respondents, all 83
respondents (100%) say that in their organizations, they have a well defined and
documented Process Improvement Plan in place. It goes to show that their organizations
are mature in processes and are methodical in implementing any initiative.
2. Project Teams Routine Activities
Collect Metrics
Yes
No
DN/NA
83
100.00%
0
0.00%
0
0.00%
Figure GRP-D-02-01: Collection of Metrics
respondents (100%) say that in their organizations, the project teams regularly collect
metrics on project management data. This not only helps the project to improve their
performance, it also helps the management to view progress more often and take
appropriate actions when needed. In addition, these metrics provide the Process Users to
improve processes to ensure there is a performance improvement too.
130
Use Metrics
Yes
No
DN/NA
83
100.00%
0
0.00%
0
0.00%
Figure GRP-D-02-02: Use of Metrics
respondents (100%) say that in their organizations, the project teams not only regularly
collect metrics on project management data but also use them for improving their
performance. Thus, metrics collection and further analysis of the same is a good common
practice adopted by these organizations.
Use Processes to
Perform Tasks
66
5
12
Yes
No
DN/NA
79.52%
6.02%
14.46%
Figure GRP-D-02-03: Use Processes to Perform Project Tasks
respondents (79.52%) say that in their organizations, the project teams use defined
processes to perform their project tasks appropriately and regularly. Thus, it is understood
that automating these processes would definitely provide a better means of using these
processes thereby increasing efficiency and productivity.
Meet External
Schedules
Yes
No
DN/NA
83
0
0
100.00%
0.00%
0.00%
131
Figure GRP-D-02-04: Use Processes to Meet External Schedules
respondents (100%) say that in their organizations, the project teams use processes to
ensure that they deliver their services on time. An automated solution would enhance the
project teams performance and enable them to deliver with higher schedule under-run.
Meet Cost Estimates

Yes
No
DN/NA
54
65.06%
14
16.87%
15
18.07%
Figure GRP-D-02-05: Use Processes to Meet Cost Estimates

respondents (65.06%) say that in their organizations, the project teams use processes to
meet Cost Estimates. 14 respondents (16.87%) say that in their organizations, the project
teams do not use processes to meet Cost Estimates. Yes, it is clear that Process do not
improve productivity directly. Processes helps in making sure that tasks are done right the
first time. Therefore, rework effort reduced and thus the cost of quality is decreased
thereby increasing overall productivity. The same concept applies to use of automated
processes too. So, it is quite apparent that using processes, manual or automated, will not
directly help in meeting cost estimates but help in other ways to improve performance
and productivity to improve cost estimates.
Provide Training
Yes
No
DN/NA
52
62.65%
15
18.07%
16
19.28%
Figure GRP-D-02-06: Provision of Training in Process Tools and Methods
132

respondents (62.65%) say that in their organizations, the project teams are trained in
usage of Process Tools and Methods. 15 respondents (18.07%) say that in their
organizations, the project teams are trained in usage of Process Tools and Methods. It is
understood that extensive training or clear guidelines are provided by most organizations
to their project teams for using appropriate process tools and methods. This helps the
project team to apply the right process, tool or method as required by the project scenario.
133
3. Documented Process in Operation
Documented
Automated Processes
in Manual Operation
66
9
8
Yes
No
DN/NA
79.52%
10.84%
9.64%
Figure GRP-D-03: Documented Automated Process in Manual Operation

respondents (79.52%) say that in their organizations, all documented and automated
processes are in operation which means that all processes required to execute a project
are automated and in use by the project teams on a regular basis which a good sign. 9
respondents (10.84%) say that there are probably some documented and automated
processes not in manual operation in their organizations This implies that Process
Automation initiative is a successful endeavor in most of the organizations.
4. Process that are Automated
Project
Initiation/Startup
Yes
No
DN/NA
83
0
0
100.00%
0.00%
0.00%
Figure GRP-D-04-01: Automated Process Project Initiation/Startup
respondents (100%) say that in their organizations, a critical process area Project
Initiation/Startup is automated as part of the Process Automation initiation.
134
Project Planning
Yes
No
DN/NA
83
100.00%
0
0.00%
0
0.00%
Figure GRP-D-04-02: Automated Process Project Planning
Planning is automated as part of the Process Automation initiation.
Project tracking &

oversight
83
0
0
Yes
No
DN/NA
100.00%
0.00%
0.00%
Figure GRP-D-04-03: Automated Process Project Tracking and Oversight
Tracking and Oversight is automated as part of the Process Automation initiation.
Project closure
Yes
No
DN/NA
83
100.00%
0
0.00%
0
0.00%
Figure GRP-D-04-04: Automated Process Project Closure
Closure is automated as part of the Process Automation initiation.
135
Requirements
management
23
0
0
Yes
No
DN/NA
27.71%
0.00%
0.00%
Figure GRP-D-04-05: Automated Process Requirements Management
In the above table and graph, it is observed that, out of 83 respondents, only 23
respondents (27.71%) say that in their organizations, the process area Requirements
Management is automated as part of the Process Automation initiation.
Design
Yes
No
DN/NA
61
73.49%
0
0.00%
0
0.00%
Figure GRP-D-04-06: Automated Process Software Design

respondents (73.49%) say that in their organizations, the process area Software Design
is automated as part of the Process Automation initiation.
Software Development Respondents Respondents %

Yes
No
DN/NA
33
0
0
39.76%
0.00%
0.00%
Figure GRP-D-04-07: Automated Process Software Development

respondents (39.76%) say that in their organizations, the process area Software
Development is automated as part of the Process Automation initiation.
136
83
0
0
Yes
No
DN/NA
100.00%
0.00%
0.00%
Figure GRP-D-04-08: Automated Process Verification/Reviews
respondents
(100%)
say
that
in
their
organizations,
the
process
area
Verification/Reviews is automated as part of the Process Automation initiation.
Valiation/Testing
Yes
No
DN/NA
83
100.00%
0
0.00%
0
0.00%
Figure GRP-D-04-09: Automated Process Validation/Testing
respondents (100%) say that in their organizations, the process area Validation/Testing
is automated as part of the Process Automation initiation.
Defect/Anomaly
Tracking
Yes
No
DN/NA
83
0
0
100.00%
0.00%
0.00%
Figure GRP-D-04-10: Automated Process Defect/Anomaly Tracking

respondents (100%) say that in their organizations, a critical process area
Verification/Reviews is automated as part of the Process Automation initiation.
137
Release Management
61
0
0
Yes
No
DN/NA
73.49%
0.00%
0.00%
Figure GRP-D-04-11: Automated Process Release Management

respondents (73.49%) say that in their organizations, the process area Release
Deployment
Yes
No
DN/NA
24
28.92%
0
0.00%
0
0.00%
Figure GRP-D-04-12: Automated Process Deployment
respondents (28.92%) say that in their organizations, the process area Deployment is
automated as part of the Process Automation initiation.
Software Maintenance Respondents Respondents %

Yes
No
DN/NA
83
0
0
100.00%
0.00%
0.00%
Figure GRP-D-04-13: Automated Process Software Maintenance

respondents (100%) say that in their organizations, the process area Software
Maintenance is automated as part of the Process Automation initiation.
138
Hardware/Software
Servicing
83
0
0
Yes
No
DN/NA
100.00%
0.00%
0.00%
Figure GRP-D-04-14: Automated Process Hardware/Software Servicing
respondents (100%) say that in their organizations, the process area Hardware/Software
Servicing is automated as part of the Process Automation initiation.
Change Management
83
0
0
Yes
No
DN/NA
100.00%
0.00%
0.00%
Figure GRP-D-04-15: Automated Process Change Management
respondents (100%) say that in their organizations, the
process
area
Change
Configuration
Management
Yes
No
DN/NA
83
0
0
100.00%
0.00%
0.00%
Figure GRP-D-04-16: Automated Process Configuration Management

respondents (100%) say that in their organizations, the process area Configuration
139
Document
Management
59
0
0
Yes
No
DN/NA
71.08%
0.00%
0.00%
Figure GRP-D-04-17: Automated Process Document Management

respondents (71.08%) that in their organizations, the process area Document
Document Review
Yes
No
DN/NA
22
26.51%
0
0.00%
0
0.00%
Figure GRP-D-04-18: Automated Process Document Review
respondents (26.51%) say that in their organizations, the process area Document
Review is automated as part of the Process Automation initiation.
Subcontractor
Management
Yes
No
DN/NA
10
0
0
12.05%
0.00%
0.00%
Figure GRP-D-04-19: Automated Process Subcontractor Management
140
respondents (12.05%) say that in their organizations, the process area Subcontractor
Supplier Management Respondents Respondents %

10
0
0
Yes
No
DN/NA
12.05%
0.00%
0.00%
Figure GRP-D-04-20: Automated Process Supplier Management
In the above table and graph, it is observed that, out of 83, respondents 10
respondents (12.05%) say that in their organizations, the process area Supplier
Other
Yes
No
DN/NA
13
15.66%
0
0.00%
0
0.00%
Figure GRP-D-04-21: Automated Process Other Process Areas
respondents (15.66%) say that in their organizations, other process areas are automated as
part of the Process Automation initiation.
141
5. Process Definition Notation
Process Definition
Notation
83
0
0
Yes
No
DN/NA
100.00%
0.00%
0.00%
Figure GRP-D-05: Process Definition Notation
respondents (100%) say that in their organizations, Process Definition Notation was
followed.
6. Process Definition Notation Followed
Figure GRP-D-06: Process Definition Notations Followed
142
In the above table and graph, it is observed that, ETVX is the most popularly
followed notation, say 42 respondents (50.6%). Flow Charts is a notation commonly
followed say 23 respondents (27.71). 14 respondents (16.87%) say that Role Interaction
Nets and Role Activity Diagrams are notations followed in their organizations and other
notations are sparingly used.
7. Documented Process Design
Documented Process
Design
83
0
0
Yes
No
DN/NA
100.00%
0.00%
0.00%
Figure GRP-D-07: Documented Process Design
respondents (100%) say that in their organizations, Process Design is clearly documented
and maintained.
8. Use of Functional Requirements
Functional
Requirements Used
Yes
No
DN/NA
55
11
7
66.27%
13.25%
8.43%
Figure GRP-D-08: Use of Functional Requirements

respondents (66.27%) say that Functional Requirements are defined and used during
Process Automation in their organizations, while 11 respondents (13.25%) say that
143
Functional Requirements are not defined and used during Process Automation in their
organizations.
144
9. Defined Metrics Requirements
Metrics Requirements
Specified
65
9
9
Yes
No
DN/NA
78.31%
10.84%
10.84%
Figure GRP-D-09: Defined Metrics Requirements

respondents (78.31%) say that Metrics Requirements were specified before adopting the
Process Automation initiative and 9 respondents (10.84%) say that Metrics Requirements
were not specified before adopting the Process Automation initiative.
10. Target Process
Target Process
A New Process
Operated Manually
DN/NA
33
39.76%
38
45.78%
12
14.46%
Figure GRP-D-10-01: Target Process

respondents (39.76%) say that a new process was defined before adopting the Process
Automation initiative and 38 respondents (45.78%) say that the existing process that was
manually being operated was used for adopting the Process Automation initiative.
145
Documented Manual
Process
27
11
0
Yes
No
DN/NA
32.53%
13.25%
0.00%
Figure GRP-D-10-02: Target Process Documented Manual Process
In the above table and graph, it is observed that, out of 38 (45.78%) that said that
existing process was retained for adopting Process Automation, 27 respondents (32.53%)
say that the existing process was documented manually by the organization and 11
respondents (13.25%) say that the existing process that was not documented manually
before adopting the Process Automation initiative.
Stable Process
Operation
Yes
No
DN/NA
24
11
3
28.92%
13.25%
3.61%
Figure GRP-D-10-03: Target Process Manual Process in Stable Operation
In the above table and graph, it is observed that, out of 38 (45.78%) that said that
existing process was retained for adopting Process Automation, 24 respondents (28.92%)
say that the existing process was in operation and was stable and 11 respondents
(13.25%) say that the existing process that was not stable in operation before adopting the
Process Automation initiative.
146
11. Process Definition a Challenge
Process Definition
Challenging
54
15
14
Yes
No
DN/NA
65.06%
18.07%
16.87%
Figure GRP-D-11: Process Definition a Challenge

respondents (65.06%) say that Process Definition was challenging before adopting the
Process Automation initiative and 15 respondents (18.07%) say that Process Definition
was not so challenging before adopting the Process Automation initiative.
E. Process Automation Development Technology
In this section, the technological approach taken by organizations to adopt Process

Automation initiative is analyzed and discussed.
1. Process Automation Adoption Method
Process Automation
Adoption Method
In-house Developed
Procured
83
0
100.00%
0.00%
Figure GRP-E-01: Process Automation Adoption Method
respondents (100%) say their organizations have developed Process Automation tool
147
themselves. It goes to show that their organizations are capable of not only defining
mature processes but also developing a tool to align with the processes.
2. Major Strengths of Software Process Automation
Process Development
Environment
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
57
24
0
0
2
68.67%
28.92%
0.00%
0.00%
2.41%
Figure GRP-E-02-01: Process Development Environment

respondents (68.67%) strongly agree that Process Development Environment is a major
strength of a Process Automation tool and 24 respondents (28.92%) agree that Process
Development Environment is a major strength of Process Automation tool. It goes to
show that all respondents are quite agreeable that Process Development Environment is a
major strength.
Debugging Capabilities
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
20
31
3
0
15
24.10%
37.35%
3.61%
0.00%
18.07%
Figure GRP-E-02-02: Debugging Capabilities

respondents (24.1%) strongly agree that Debugging Capabilities is a major strength of a
Process Automation tool and 31 respondents (37.35%) agree that Debugging Capabilities
is a major strength of Process Automation tool. There are just about 3 respondents
148
(3.61%) who disagree on this. It goes to show that many respondents are quite agreeable
that Process Debugging Capabilities a major strength.
Integrating Application
Tools
Strongly agree
25
30.12%
Agree
43
51.81%
Disagree
3
3.61%
Stongly Disagree
0
0.00%
DK/NA
12
14.46%
Figure GRP-E-02-03: Integrating Application Tools

respondents (30.12%) strongly agree that Integrating Application Tools is a major
strength of a Process Automation tool and 43 respondents (51.81%) agree that Integrating
Application Tools is a major strength of Process Automation tool. There are just about 3
respondents (3.61%) who disagree on this. It goes to show that many respondents are
agreeable that Integrating Application Tools is a major strength.
Effective End-User
Interfaces
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
33
33
2
0
15
39.76%
39.76%
2.41%
0.00%
18.07%
Figure GRP-E-02-04: Effective End-User Interfaces

respondents (39.76%) strongly agree that Effective End-User Interfaces is a major
strength of a Process Automation tool and 33 respondents (39.76%) agree that Effective
End-User Interfaces is a major strength of Process Automation tool. There are just about
2 respondents (2.41%) who disagree on this. It goes to show that many respondents are
quite agreeable that Effective End-User Interfaces is a major strength.
149
Collect Metrics
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
51
61.45%
25
30.12%
3
3.61%
0
0.00%
4
4.82%
Figure GRP-E-02-05: Collect Metrics

respondents (61.45%) strongly agree that Metrics Collection is a major strength of a
Process Automation tool and 25 respondents (30.12%) agree that Metrics Collection is a
major strength of Process Automation tool. There are just about 3 respondents (3.61%)
who disagree on this. It goes to show that many respondents are quite agreeable that
Metrics Collection is a major strength.
Performance
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
25
30.12%
34
40.96%
12
14.46%
0
0.00%
12
14.46%
Figure GRP-E-02-06: Performance

respondents (30.12%) strongly agree that Performance is a major strength of a Process
Automation tool and 34 respondents (40.96%) agree that Performance is a major strength
of Process Automation tool. There are 12 respondents (14.46%) who disagree on this. It
goes to show that many respondents are quite agreeable that Performance is a major
strength.
150
Cross-Platform
Compatibilities
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
20
27
2
2
32
24.10%
32.53%
2.41%
2.41%
38.55%
Figure GRP-E-02-07: Cross-Platform Compatibilities

respondents (24.1%) strongly agree that Cross-Platform Compatibilities is a major
strength of a Process Automation tool and 27 respondents (32.53%) agree that CrossPlatform Compatibilities is a major strength of Process Automation tool. There are just
about 2 respondents (2.41%) who disagree on this. There are also 2 respondents (2.41%)
who strongly disagree on this. It still goes to show that all respondents are quite agreeable
that Process Development Environment is a major strength.
Customer support
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
27
32.53%
40
48.19%
3
3.61%
0
0.00%
13
15.66%
Figure GRP-E-02-08: Customer Support

respondents (32.53%) strongly agree that Customer Support is a major strength of a
Process Automation tool and 40 respondents (48.19%) agree that Customer Support is a
major strength of Process Automation tool. There are just about 3 respondents (3.61%)
who disagree on this. It goes to show that all respondents are quite agreeable that
Customer Support is a major strength.
151
Training
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
19
22.89%
33
39.76%
17
20.48%
4
4.82%
10
12.05%
Figure GRP-E-02-09: Training

respondents (22.89%) strongly agree that Training is a major strength of a Process
Automation tool and 33 respondents (39.76%) agree that Training is a major strength of
Process Automation tool. There are about 17 respondents (20.48%) who disagree on this.
There are also 4 respondents (4.82%) who strongly disagree on this. It still goes to show
that while there are many respondents quite agreeable that Training is a major strength,
there are also few respondents who are not agreeable that Training is a major strength.
Documentation
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
22
26.51%
36
43.37%
9
10.84%
6
7.23%
10
12.05%
Figure GRP-E-02-10: Documentation

respondents (26.51%) strongly agree that Documentation is a major strength of a Process
Automation tool and 36 respondents (43.37%) agree that Documentation is a major
strength of Process Automation tool. There are just about 9 respondents (10.94%) who
disagree on this. There are also 6 respondents (7.23%) who strongly disagree on this. It
still goes to show that while there are many respondents quite agreeable that
Documentation is a major strength, there are also few respondents who are not agreeable
that Documentation is a major strength.
152
Ease of use
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
17
20.48%
23
27.71%
10
12.05%
0
0.00%
33
39.76%
Figure GRP-E-02-11: Ease of Use

respondents (20.48%) strongly agree that Ease of Use is a major strength of a Process
Automation tool and 23 respondents (27.71%) agree that Ease of Use is a major strength
of Process Automation tool. There are about 10 respondents (12.05%) who disagree on
this. It goes to show that all respondents are quite agreeable that Ease of Use is a major
strength.
Cost Effectiveness
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
17
20.48%
25
30.12%
9
10.84%
6
7.23%
26
31.33%
Figure GRP-E-02-12: Cost Effectiveness

respondents (20.48%) strongly agree that Cost Effectiveness is a major strength of a
Process Automation tool and 25 respondents (30.12%) agree that Cost Effectiveness is a
major strength of Process Automation tool. There are about 9 respondents (10.84%) who
disagree on this. There are also 6 respondents (7.23%) who strongly disagree on this. It
still goes to show that while there are many respondents quite agreeable that Cost
Effectiveness is a major strength, there are also few respondents who are not agreeable
that Cost Effectiveness is a major strength.
153
3. Defects Affected Development
Defects Affected
Development
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
10
25
27
4
17
12.05%
30.12%
32.53%
4.82%
20.48%
Figure GRP-E-03: Defects Affected Software Development

respondents (12.05%) strongly agree that their Process Automation tool had defects
which affected their own work, 25 respondents (30.12%) agree that their Process
Automation tool had defects which affected their own work, 27 respondents (32.53%)
disagree that their Process Automation tool had defects which affected their own work
and just 4 respondents (4.82%) strongly disagree that their Process Automation tool had
defects which affected their work. It goes to show that there are many respondents who
say their tool did not have defects that affected their work but there are many more who
agree that their Process Automation tool had defects which affected their regular work.
4. System Crashes Affected Development
System Crashes Affected

Development
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
15
34
9
7
18
18.07%
40.96%
10.84%
8.43%
21.69%
Figure GRP-E-04: System Crashes Affected Software Development

respondents (18.07%) strongly agree that their Process Automation tool had crashed their
systems which affected their own work, 34 respondents (40.96%) agree that their Process
154
Automation tool crashed their systems which affected their own work, 9 respondents
(10.84%) disagree that their Process Automation tool crashed their systems which
affected their work and 7 respondents (8.43%) strongly disagree that their Process
Automation tool resulted in system crashes which affected their own work. It goes to
show that there are many respondents who say their tool crashed their systems thereby
affecting their regular work but there are few of them who agree that their Process
Automation tool did not crash their systems.
5. Difficult to recover from System
Difficult to recover from

Crashes.
Strongly agree
6
7.23%
Agree
29
34.94%
Disagree
29
34.94%
Stongly Disagree
3
3.61%
DK/NA
16
19.28%
Figure GRP-E-05: Difficult to recover from System Crashes

respondents (7.23%) strongly agree that it was difficult to recover from system crashes
occurred due to execution of Process Automation tool, 29 respondents (34.94%) agree
that it was difficult to recover from system crashes occurred due to execution of Process
Automation tool, 29 respondents (34.94%) disagree that it was difficult to recover from
system crashes occurred due to execution of Process Automation tool and only 3
respondents (3.61%) strongly disagree that it was difficult to recover from system crashes
occurred due to execution of Process Automation tool. It goes to show that there is an
equal number of responses for and against the issue the teams having difficulty in
recovering from system crashes occurred due to execution of Process Automation tool.
155
6. Tool supports Hardware platforms
Supports Range of
Hardware Platforms
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
16
23
3
4
35
19.28%
27.71%
3.61%
4.82%
42.17%
Figure GRP-E-06: Process Automation Supports Hardware Platforms

respondents (19.28%) strongly agree that their Process Automation tool supports multiple
hardware platforms, 23 respondents (27.71%) agree that their Process Automation tool
supports multiple hardware platforms, 3 respondents (3.61%) disagree that their Process
Automation tool supports multiple hardware platforms and 4 respondents (4.82%)
strongly disagree that their Process Automation tool supports multiple hardware
platforms. It goes to show that there is larger number of respondents say their tool
supports multiple hardware platforms.
Once the Process Automation tool is developed, the next major step is to
implement it across the organization. The required deployment platforms will be readied,
required training provided to the end-users and then the tool will be rolled out for use. In
this section, the various aspects of transition and adoption of Process Automation tools
are analyzed and discussed.
156
1. Transition Period
Transition Time
0-2
3-6
7-12
13-24
Over 24
Transition not
completed
DK/NA
Respondents
8
18
12
23
12
Respondents %
9.88%
22.22%
14.81%
28.40%
14.81%
2.47%
7.41%
Figure GRP-F-01: Time taken for Transition to Process Automation Tool

respondents (14.81%) said that their organizations took more than 2 years to transition
from manual process to Process Automation tool, 23 respondents (28.4%) said that they
took close to 2 years, 12 respondents (14.81%) said that they took between 7 months to a
year, 18 respondents (22.22%) said that they took 3-6 months, 8 respondents (9.88%)
said that they took just less than 3 months to transition from manual process to Process
Automation tool and 2 respondents (7.41%) said that in their organizations, transition is
still in progress. It is understood that the transition period varies from 2 months to 2
years. The reason could be that some organizations would have implemented few
processes and some might have implemented processes all at once.
2. Period Process Automation tool is Operational

Tool Operational
Not yet in
Production
0-2
3-6
7-12
13-24
Over 24
DK/NA
Respondents
Respondents %
15
18.75%
13
17
11
10
6
8
16.25%
21.25%
13.75%
12.50%
7.50%
10.00%
Figure GRP-F-02: How long is Process Automation Tool is Operational
157

respondents (7.5%) said that the Process Automation tool deployed and transitioned to
end-users in this organization has been operational for more than 2 years, 10 respondents
(12.50%) said that the Process Automation tool deployed and transitioned to end-users in
this organization has been operational for close to 2 years, 11 respondents (13.75%) said
that the Process Automation tool deployed and transitioned to end-users in this
organization has been operational for between 7 months to a year, 17 respondents
(21.25%) said that the Process Automation tool has been operational for 3-6 months tool,
13 respondents (9.88%) said that the Process Automation tool has been operational for
just less than 3 months and 15 respondents (18.75%) said that the Process Automation
tool has not yet gone into production. It is understood quite a number of respondents have
said that the Process Automation tool is not yet in production which may mean that either
there is no such initiative in their organizations or that their tool has not yet addressed all
the processes. However, a larger number of respondents have said that their Process
Automation tool is in production.
3. Training provided for implementing the Process Automation tool
Training for
Implementers
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
41
23
6
5
8
49.40%
27.71%
7.23%
6.02%
9.64%
Figure GRP-F-03-01: Training the Implementers on Process Automation Tool

respondents (49.4%) strongly agree that the Implementers were trained on the Process
Automation tool, 23 respondents (27.71%) agree that the Implementers were trained on
the Process Automation tool, 6 respondents (7.23%) disagree that the Implementers were
trained on the Process Automation tool and 5 respondents (6.02%) strongly disagree that
the Implementers were trained on the Process Automation tool. It is understood that
158
majority of the respondents have agreed that Implementers of the Process Automation
tool in their organizations have been extensively trained on the tool.
Training for
End-Users
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
20
38
9
0
16
24.10%
45.78%
10.84%
0.00%
19.28%
Figure GRP-F-03-02: Training the End-Users on Process Automation Tool

respondents (24.1%) strongly agree that the End-users were trained on the Process
Automation tool, 38 respondents (45.78%) agree that the End-users were trained on the
Process Automation tool, 9 respondents (10.84%) disagree that the End-users were
trained on the Process Automation tool and none of the respondents strongly disagreed
that the Implementers were trained on the Process Automation tool. It is understood that
majority of the respondents have agreed that End-users have been trained on the Process
Automation tool in their organizations.
4. Process Design developed in conjunction with End-users

Process Designed
along with
End-Users
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
40
35
2
0
2
50.63%
44.30%
2.53%
0.00%
2.53%
Figure GRP-F-04: Process Design developed in conjunction with End-users

respondents (50.63%) strongly agree that the Process Design was developed in
conjunction with End-users, 35 respondents (44.3%) agree that the Process Design was
159
developed in conjunction with End-users, 2 respondents (2.53%) disagree that and none
strongly disagreed that the Process Design was developed in conjunction with End-users.
It is understood that majority of the respondents have agreed that the Process Design was
developed in conjunction with End-users.
5. Process design reviewed with End-users
Process Design
Reviewed with
End-Users
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
44
35
0
0
2
54.32%
43.21%
0.00%
0.00%
2.47%
Figure GRP-F-05: Process design reviewed with End-users

respondents (54.32%) strongly agree that Process Design was reviewed by the End-users,
35 respondents (43.21%) agree that Process Design was reviewed by the End-users, and
none of the respondents disagreed that Process Design was reviewed by the End-users. It
is understood that all the knowledgeable respondents have agreed that Process Design
was reviewed by the End-users.
6. The end-user screens evaluated by End-users
Screens Evaluated
by
End-Users
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
23
29
13
2
10
29.87%
37.66%
16.88%
2.60%
12.99%
Figure GRP-F-06: End-user screens evaluated by End-users
160

respondents (29.87%) strongly agree that the front-end screens of the Process Automation
tool were evaluated by End-users, 29 respondents (37.66%) agree that the front-end
screens of the Process Automation tool were evaluated by End-users, 13 respondents
(16.88%) disagree that the front-end screens of the Process Automation tool were
evaluated by End-users and just 2 respondents (2.6%) strongly disagree that the front-end
screens of the Process Automation tool were evaluated by End-users. It is understood that
though many of the respondents have agreed that the front-end screens of the Process
Automation tool were evaluated by End-users, close to 20% of the respondents have
disagreed to this which is a point to be noted. This might be an inhibitor for successful
implementation of the Process Automation tool.
7. Process simulations performed with End-users
Process
Simulations by End- Respondents
Users
Strongly agree
24
Agree
40
Disagree
11
Stongly Disagree
0
DK/NA
4
Respondents %
30.38%
50.63%
13.92%
0.00%
5.06%
Figure GRP-F-07: Process simulations performed with End-users

respondents (30.38%) strongly agree that Process simulations were performed with the
End-users, 40 respondents (50.63%) agree that Process simulations were performed with
the End-users, 11 respondents (13.92%) disagree that Process simulations were
performed with the End-users and none of the respondents strongly disagreed that
Process simulations were performed with the End-users. It is understood that though
many of the respondents have agreed that Process simulations were performed with the
End-users, close to 14% of the respondents have disagreed to this which is a point to be
161
noted. This might be an inhibitor for successful implementation of the Process

Automation tool.
8. Automated Process improves effectiveness of End-users
Improves
End-Users
Performance
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
28
42
5
0
8
33.73%
50.60%
6.02%
0.00%
9.64%
Figure GRP-F-08: Automated Process improves effectiveness of End-users

respondents (33.73%) strongly agree that Automated Process improves effectiveness of
End-users, 42 respondents (50.6%) agree that Automated Process improves effectiveness
of End-users, 5 respondents (6.02%) disagree that Automated Process improves
effectiveness of End-users and none of the respondents strongly disagree that Automated
Process improves effectiveness of End-users. It is understood that majority of the
respondents have agreed that Automated Process improves effectiveness of End-users.
This result shows that improving effectiveness of End-users is a motivator for the success
of Process Automation.
9. End-users had difficulty in accepting new process
Difficulty in
Accepting Tool
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
17
37
15
4
10
20.48%
44.58%
18.07%
4.82%
12.05%
Figure GRP-F-09: End-users had difficulty in accepting new process
162

respondents (30.48%) strongly agree that End-users had difficulty in accepting new
process, 27 respondents (44.58%) agree that End-users had difficulty in accepting new
process, 15 respondents (18.07%) disagree that End-users had difficulty in accepting new
process and 4 respondents (4.82%) strongly disagree that End-users had difficulty in
accepting new process. It is understood that though many of the respondents have agreed
that End-users had difficulty in accepting new process, almost 23% of the respondents
have disagreed to this which is a point to be noted. This might be an inhibitor for
successful implementation of the Process Automation tool.
10. End-users feel ownership towards the automated process
Ownership by EndRespondents
Users
Strongly agree
27
Agree
40
Disagree
6
Stongly Disagree
0
DK/NA
10
Respondents %
32.53%
48.19%
7.23%
0.00%
12.05%
Figure GRP-F-10: End-users feel ownership towards the automated process

respondents (32.53%) strongly agree that End-users feel ownership towards the
automated process, 40 respondents (48.19%) agree that End-users feel ownership towards
the automated process, 6 respondents (7.23%) disagree that End-users feel ownership
towards the automated process and none of the respondents strongly disagree that Endusers feel ownership towards the automated process. It is understood that majority of the
respondents have agreed that End-users feel ownership towards the automated process
which is a great motivating factor towards success of the whole initiative.
163
11. End-users make suggestions to improve automated process
End-User Suggests
Improvement
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
33
35
2
0
13
39.76%
42.17%
2.41%
0.00%
15.66%
Figure GRP-F-11: End-users make suggestions to improve automated process

respondents (39.76%) strongly agree that the End-users make suggestions to improve the
automated process, 35 respondents (42.17%) agree that the End-users make suggestions
to improve the automated process, 2 respondents (2.41%) disagree that the End-users
make suggestions to improve the automated process and none of the respondents strongly
disagreed that the End-users make suggestions to improve the automated process. It is
understood that majority of the respondents have agreed that the End-users make
suggestions to improve the automated process.
12. Metrics used to improve automated process
Metrics used for

Improvement
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
31
37
3
0
12
37.35%
44.58%
3.61%
0.00%
14.46%
Figure GRP-F-12: Metrics used to improve automated process

respondents (37.35%) strongly agree that Metrics were used to improve automated
164
process, 37 respondents (44.58%) agree that Metrics were used to improve automated
process, 3 respondents (3.61%) disagree that Metrics were used to improve automated
process and none of the respondents strongly disagreed that Metrics were used to
improve automated process. It is understood that majority of the respondents have agreed
that Metrics were used to improve automated process.
13. Resistance to process automation Any new initiative in an organization receives

resistance since it is misconstrued that it jolts the smooth operation of the existing
systems and disturbs the harmony of working environment. Process Automation
initiative is no exception and since it is an initiative which affects the entire
organization population, it is even more critical to make sure the reasons for
resistance and addresses in advance to avoid any unnecessary delays during
implementation.
Automation was
Respondents
Externally Imposed
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
18
32
17
4
12
Respondents %
21.69%
38.55%
20.48%
4.82%
14.46%
Figure GRP-F-13-01: Automation was externally imposed

respondents (21.69%) strongly agree that the Process Automation initiative was
externally imposed on the employees, 32 respondents (38.55%) agree that the Process
Automation initiative was externally imposed on the employees, 17 respondents
(20.48%) disagree that the Process Automation initiative was externally imposed on the
employees and 4 respondents (4.82%) strongly disagree that the Process Automation
initiative was externally imposed on the employees. It is understood that majority of the
respondents have agreed that the Process Automation initiative was externally imposed
on the employees although there is also a good number of respondents (almost 25%) who
says that yes, the tool was not imposed on them.
165
Fear of Job Loss

Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
16
25
20
10
12
Respondents %
19.28%
30.12%
24.10%
12.05%
14.46%
Figure GRP-F-13-02: Fear of Job Loss

respondents (19.28%) strongly agree that there is a fear of job loss among employees due
to implementation of Process Automation tool, 25 respondents (30.12%) agree that there
is a fear of job loss among employees due to implementation of Process Automation tool,
20 respondents (24.1%) disagree that there is a fear of job loss among employees due to
implementation of Process Automation tool and 10 respondents (12.05%) strongly
disagree that there is a fear of job loss among employees due to implementation of
Process Automation tool. It is understood that almost half the respondents have agreed
that there is a fear of job loss among employees due to implementation of Process
Automation tool even though as much as 36% of the employees have disagreed on this
which is a good sign. However, this is a point that needs to be noted and focused upon by
the management.
Fear of Change
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
4
35
22
12
10
Respondents %
4.82%
42.17%
26.51%
14.46%
12.05%
Figure GRP-F-13-03: Fear of Change

respondents (4.82%) strongly agree that there is discomfort and fear of change loss
among employees due to implementation of Process Automation tool, 35 respondents
(42.17%) agree that there is discomfort and fear of change loss among employees due to
166
implementation of Process Automation tool, 22 respondents (26.51%) disagree that there

is discomfort and fear of change loss among employees due to implementation of Process
Automation tool and 12 respondents (14.46%) strongly disagree that there is discomfort
and fear of change loss among employees due to implementation of Process Automation
tool. It is understood that about 47% of the respondents have agreed that there is
discomfort and fear of change loss among employees due to implementation of Process
Automation tool while a big 41% of respondents disagree on this which is a positive
perception. Still, it is a critical issue that the management needs to tackle if it is to make
sure that the whole Process Automation initiative should be a success.
Automation too
Controlling
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
4
35
25
10
9
4.82%
42.17%
30.12%
12.05%
10.84%
Figure GRP-F-13-04: Process Automation is Controlling

respondents (4.82%) strongly agree that Process Automation is controlling, 35
respondents (42.17%) agree that Process Automation is controlling, 25 respondents
(30.12%) disagree that Process Automation is controlling and 10 respondents (12.05%)
strongly disagree that Process Automation is controlling. It is understood that about 42%
of the respondents have agreed that Process Automation is not controlling. However,
there is a big number of nearly 47% respondents who perceive that Process Automation is
controlling and this perception needs to be cleared by the management.
End-Users not
Consulted
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
9
27
30
4
13
10.84%
32.53%
36.14%
4.82%
15.66%
Figure GRP-F-13-05: End-users not consulted sufficiently
167

respondents (10.84%) strongly agree that the end-users were not consulted in the
beginning and during implementation of Process Automation, 27 respondents (32.53%)
agree that the end-users were not consulted in the beginning and during implementation
of Process Automation, 30 respondents (36.14%) disagree that the end-users were not
consulted in the beginning and during implementation of Process Automation and 4
respondents (4.82%) strongly disagree that the end-users were not consulted in the
beginning and during implementation of Process Automation. It is understood that
majority of the respondents (about 41%) have agreed that the end-users were consulted in
the beginning and during implementation of Process Automation but it is also critical to
note that about 43% agree otherwise. This is an issue which cannot be overlooked by the
management because ultimately, the end-users are the ones who are going to use the tool
and the success of the whole initiative depends heavily on their satisfaction.
Metrics used for

Job Evaluation
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
16
36
22
2
7
19.28%
43.37%
26.51%
2.41%
8.43%
Figure GRP-F-13-06: Metrics used in Job Evaluations

respondents (19.28%) strongly agree that Metrics reports generated by the Process
Automation tool is used in job evaluations, 36 respondents (43.37%) agree that Metrics
reports generated by the Process Automation tool is used in job evaluations, 22
respondents (26.51%) disagree that Metrics reports generated by the Process Automation
tool is used in job evaluations and 2 respondents (2.41%) strongly disagree that Metrics
reports generated by the Process Automation tool is used in job evaluations. It is
understood that majority of the respondents have agreed that Metrics reports generated by
the Process Automation tool is used in job evaluations. It is very critical to note that
majority of the respondents (almost 63%) of the employees agree that Metrics reports
168
generated by the Process Automation tool is used in job evaluations which means this
issues needs immediate attention of the management.
14. Senior Management is Supportive
Senior
Management
Support
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
36
45
2
0
0
43.37%
54.22%
2.41%
0.00%
0.00%
Figure GRP-F-14: Senior Management is Supportive

respondents (43.37%) strongly agree that senior management supports the Process
Automation initiative, 45 respondents (54.22%) agree that senior management supports
the Process Automation initiative, 2 respondents (2.41%) disagree that senior
management supports the Process Automation initiative and none of the respondents
strongly disagreed that senior management supports the Process Automation initiative. It
is understood that majority of the respondents have agreed that senior management
supports the Process Automation initiative.
15. First-line Management is Supportive.
First-line
Management
Support
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
28
49
4
0
0
34.57%
60.49%
4.94%
0.00%
0.00%
Figure GRP-F-15: First-line Management is Supportive
169

respondents (34.57%) strongly agree that first-line management supports the Process
Automation initiative, 49 respondents (60.49%) agree that first-line management supports
the Process Automation initiative, 4 respondents (4.94%) disagree that first-line
management supports the Process Automation initiative and none of the respondents
strongly disagree that first-line management supports the Process Automation initiative.
It is understood that almost all of the respondents have agreed that first-line management
supports the Process Automation initiative.
16. Automation Business Plan written
Written
Automation
Business Plan
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
19
52
6
0
4
23.46%
64.20%
7.41%
0.00%
4.94%
Figure GRP-F-16: Automation Business Plan written

respondents (23.46%) strongly agree that a business plan to automate processes is clearly
documented, 52 respondents (64.2%) agree that a business plan to automate processes is
clearly documented, 6 respondents (7.41%) disagree that a business plan to automate
processes is clearly documented and none of the respondents strongly disagree that a
business plan to automate processes is clearly documented. It is understood that majority
of the respondents have agreed that a business plan to automate processes is clearly
documented.
170
17. Management agreed to Development Plan
Management
agreed to
Respondents
Development Plan
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents %
24
45
8
0
4
29.63%
55.56%
9.88%
0.00%
4.94%
Figure GRP-F-17: Management agreed to Development Plan

respondents (29.63%) strongly agree that management agreed to the development plan
defined by the Process Automation team, 45 respondents (55.56%) agree that
management agreed to the development plan defined by the Process Automation team, 8
respondents (9.88%) disagree that management agreed to the development plan defined
by the Process Automation team and none of the respondents strongly disagree that
management agreed to the development plan defined by the Process Automation team. It
is understood that majority of the respondents have agreed that management agreed to the
development plan defined by the Process Automation team.
18. Management reviewed Design
Design reviewed
by Management
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
28
39
12
0
2
34.57%
48.15%
14.81%
0.00%
2.47%
Figure GRP-F-18: Management reviewed Design
171

respondents (34.57%) strongly agree that the design of the Process Automation tool is
reviewed and approved by the management, 39 respondents (48.15%) agree that the
design of the Process Automation tool is reviewed and approved by the management, 12
respondents (14.81%) disagree that the design of the Process Automation tool is reviewed
and approved by the management and none of the respondents strongly disagree that the
design of the Process Automation tool is reviewed and approved by the management. It is
understood that majority of the respondents have agreed that the design of the Process
Automation tool is reviewed and approved by the management.
19. Adequate funding for Transitioning
Adequate Funding
for Transition
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
47
0
22
0
14
56.63%
0.00%
26.51%
0.00%
16.87%
Figure GRP-F-19: Adequate funding for Transitioning

respondents (56.63%) strongly agree that adequate funding was provided by the
management for transitioning, 22 respondents (26.51%) disagree that adequate funding
was provided by the management for transitioning and none of the respondents agreed or
strongly disagreed that adequate funding was provided by the management for
transitioning. It is understood that majority of the respondents have agreed that adequate
funding was provided by the management for transitioning although a good 26.5% of the
time, the respondents have disagreed.
172
20. Process Automation initiative has a Champion
Champion with
Authority
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
44
23
10
0
4
54.32%
28.40%
12.35%
0.00%
4.94%
Figure GRP-F-20: Process Automation initiative has a Champion

respondents (54.32%) strongly agree that the Process Automation initiative has a
champion, 23 respondents (28.4%) agree that the Process Automation initiative has a
champion, 10 respondents (12.35%) disagree that the Process Automation initiative has a
champion and none of the respondents strongly disagree that the Process Automation
initiative has a champion. It is understood that majority of the respondents have agreed
that the Process Automation initiative has a champion.
21. Process Automation Initiative came from
Automation
Initiative Came
From
Technical Staff
Management
A bit of Both
Respondents
Respondents %
54
10
19
65.06%
12.05%
22.89%
Figure GRP-F-21: Process Automation Initiative came from

respondents (65.06%) say that the Process Automation initiative came from technical
staff, 10 respondents (12.05%) say that the Process Automation initiative came from the
173
management and 19 respondents (22.89%) say that the Process Automation initiative
came from both management and technical staff.
22. Documented Transition Strategy
Documented
Respondents
Transition Strategy
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
20
49
4
2
8
Respondents %
24.10%
59.04%
4.82%
2.41%
9.64%
Figure GRP-F-22: Documented Transition Strategy

respondents (24.1%) strongly agree that a strategic plan was document for transitioning
the Process Automation tool, 49 respondents (59.04%) agree that a strategic plan was
document for transitioning the Process Automation tool, 4 respondents (4.82%) disagree
that a strategic plan was document for transitioning the Process Automation tool and 2
respondents (2.41%) strongly disagree that a strategic plan was document for
transitioning the Process Automation tool. It is understood that majority of the
respondents have agreed that.
23. Prototyping Strategy used for Implementation

Prototyping
Strategy
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
19
44
5
2
13
22.89%
53.01%
6.02%
2.41%
15.66%
Figure GRP-F-23: Prototyping Strategy used for Implementation
174

respondents (22.89%) strongly agree that a prototyping strategy used for Process
Automation implementation, 44 respondents (53.1%) agree that a prototyping strategy
used for Process Automation implementation, 5 respondents (6.02%) disagree that a
prototyping strategy used for Process Automation implementation and 2 respondents
(2.41%) strongly disagree that a prototyping strategy used for Process Automation
implementation. It is understood that majority of the respondents have agreed that a
prototyping strategy used for Process Automation implementation.
24. Implementation of Process Automation Tool
Process Model
Implemented
All at once
In multiple
incremental
phases
Other
DK/NA
Respondents
Respondents %
30
36.14%
42
50.60%
3
8
3.61%
9.64%
Figure GRP-F-24: Implementation of Process Automation Tool

respondents (36.14%) say that as part of the Process Automation the process model was
implemented all at once, 42 respondents (50.6%) say that as part of the Process
Automation the process model was implemented in multiple incremental phases and just
about 3 respondents (3.61%) say that they followed a different approach to implement the
process model as part of Process Automation. It is understood that there is an equal mix
of implementation strategies; some organizations have automated and implemented the
processes all at once while some organizations have implemented the process automation
initiative in a phased manner.
175
Now that the Process Automation tool is deployed, the next step is to understand
if such a huge initiative has served its purpose, and has been a successful endeavor on the
management part that has also found a good number of happy end-users. There might
have been many motivators but there might also have been few inhibitors but ultimately,
the Process Automation tool is deployed and its important to measure its performance to
ensure that the money and effort spent on this initiative has not gone waste.
1. Process Automation initiative is a success
Process
Automation is
Successful
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
32
49
2
0
0
38.55%
59.04%
2.41%
0.00%
0.00%
Figure GRP-G-01: Process Automation initiative is a success

respondents (38.55%) strongly agree that the Process Automation initiative was a
success, 49 respondents (59.04%) agree that the Process Automation initiative was a
success, just 2 respondents (2.41%) disagree that the Process Automation initiative was a
success and none strongly disagreed that the Process Automation initiative was a success.
It is understood that almost all of the respondents have agreed that the Process
Automation initiative was a success.
2. Process Automation has helped in many ways It is a known fact that a huge
initiative such as Process Automation will be taken up by organizations only when
they are sure that it will help them. Here the list of various possible areas where
Process Automation could help is considered.
176
2.1.Process Automation tool helps to improve end-user productivity
Improve end-user
productivity
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
30
51
2
0
0
36.14%
61.45%
2.41%
0.00%
0.00%
Figure GRP-G-02-01: Process Automation tool helps to improve end-user

productivity

respondents (36.14%) strongly agree that Process Automation tool helps to improve
end-user productivity, 51 respondents (61.45%) agree that Process Automation tool
helps to improve end-user productivity, 2 respondents (2.41%) disagree that Process
Automation tool helps to improve end-user productivity and none strongly disagreed
that the Process Design was developed in conjunction with End-users. It is
understood that majority of the respondents have agreed that Process Automation tool
helps to improve end-user productivity.
2.2.Process Automation tool helps to improve product quality
Improve product
quality
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
41
38
4
0
0
49.40%
45.78%
4.82%
0.00%
0.00%
Figure GRP-G-02-02: Process Automation tool helps to improve product quality
177

product quality, 38 respondents (45.78%) agree that Process Automation tool helps to
improve product quality, 4 respondents (4.82%) disagree that Process Automation
tool helps to improve product quality and none strongly disagreed that Process
Automation tool helps to improve product quality. It is understood that majority of
the respondents have agreed that Process Automation tool helps to improve product
quality.
2.3.Process Automation tool helps to manage projects more effectively
Manage projects
more effectively
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
35
37
9
2
0
42.17%
44.58%
10.84%
2.41%
0.00%
Figure GRP-G-02-03: Process Automation tool helps to manage projects more

effectively

respondents (41.17%) strongly agree that Process Automation tool helps to manage
projects more effectively, 37 respondents (44.58%) agree that Process Automation
tool helps to manage projects more effectively, 9 respondents (10.84%) disagree that
Process Automation tool helps to manage projects more effectively and 2 respondents
(2.41%) strongly disagreed that Process Automation tool helps to manage projects
more effectively. It is understood that majority of the respondents have agreed that
Process Automation tool helps to manage projects more effectively.
178
2.4.Process Automation tool helps to improve communication between end-users

Improve
communication
between
end-users
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
37
38
6
0
2
44.58%
45.78%
7.23%
0.00%
2.41%
Figure GRP-G-02-04: Process Automation tool helps to improve communication

between end-users

communication between end-users, 38 respondents (45.78%) agree that Process
Automation tool helps to improve communication between end-users, 6 respondents
(7.23%) disagree that Process Automation tool helps to improve communication
between end-users and none strongly disagreed that Process Automation tool helps to
improve communication between end-users. It is understood that majority of the
respondents have agreed that Process Automation tool helps to improve
communication between end-users.
2.5.Process Automation tool helps to improve end-user job satisfaction
Improve end-user
job satisfaction
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
29
38
13
0
3
34.94%
45.78%
15.66%
0.00%
3.61%
Figure GRP-G-02-05: Process Automation tool helps to improve end-user job

satisfaction
179

end-user job satisfaction, 38 respondents (45.78%) agree that Process Automation
tool helps to improve end-user job satisfaction, 13 respondents (15.65%) disagree that
Process Automation tool helps to improve end-user job satisfaction and none strongly
disagreed that Process Automation tool helps to improve end-user job satisfaction. It
is understood that although majority of the respondents have agreed that Process
Automation tool helps to improve end-user job satisfaction, there is a considerable
number of respondents (15.66%) that disagree on this.
2.6.Process Automation tool helps to improve end-user team building
Improve end-user
team-building
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
31
29
14
4
5
37.35%
34.94%
16.87%
4.82%
6.02%
Figure GRP-G-02-06: Process Automation tool helps to improve end-user team

building

end-user team building, 29 respondents (34.94%) agree that Process Automation tool
helps to improve end-user team building, 14 respondents (16.67%) disagree that
Process Automation tool helps to improve end-user team building and 4 respondents
(4.82%) strongly disagreed that Process Automation tool helps to improve end-user
team building. It is understood that although majority of the respondents have agreed
that Process Automation tool helps to improve end-user team building, there is quite a
few (11%) who disagree on this.
180
3. Process Automation is beneficial in many ways Although standard benefits of

productivity and process adherence are stated for Process automation, there are many
more benefits that can be derived by implementing Process automation.
3.1.Process Automation tool helps reduce tedium
Helps reduce
tedium
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
31
49
3
0
0
37.35%
59.04%
3.61%
0.00%
0.00%
Figure GRP-G-03-01: Process Automation tool helps reduce tedium

respondents (37.35%) strongly agree that Process Automation tool helps reduce
tedium, 490 respondents (59.04%) agree that Process Automation tool helps reduce
tedium, 3 respondents (3.61%) disagree that Process Automation tool helps reduce
tedium and none strongly disagreed that Process Automation tool helps reduce
tedium. It is understood that majority of the respondents have agreed that Process
Automation tool helps reduce tedium.
3.2.Process Automation tool helps prevent errors
Helps prevent
errors
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
35
44
4
0
0
42.17%
53.01%
4.82%
0.00%
0.00%
Figure GRP-G-03-02: Process Automation tool helps prevent errors
181

respondents (42.17%) strongly agree that Process Automation tool helps prevent
errors, 44 respondents (53.01%) agree that Process Automation tool helps prevent
errors, 4 respondents (4.82%) disagree that Process Automation tool helps prevent
errors and none strongly disagreed that Process Automation tool helps prevent errors.
It is understood that majority of the respondents have agreed that Process Automation
tool helps prevent errors.
3.3.Process Automation tool supports administrative efforts
Supports
administrative
efforts
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
38
45
0
0
0
45.78%
54.22%
0.00%
0.00%
0.00%
Figure GRP-G-03-03: Process Automation tool supports administrative efforts

respondents (45.78%) strongly agree that Process Automation tool supports
administrative efforts, 45 respondents (54.22%) agree that Process Automation tool
supports administrative efforts and none of the respondents neither disagreed not
strongly disagreed that Process Automation tool supports administrative efforts. It is
understood that majority of the respondents have agreed that Process Automation tool
supports administrative efforts.
182
3.4.Process Automation tool provides useful process guidance
Provides useful
process guidance
Respondents
Respondents %
30
51
2
0
0
36.14%
61.45%
2.41%
0.00%
0.00%
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Figure GRP-G-03-04: Process Automation tool provides useful process guidance

respondents (36.14%) strongly agree that Process Automation tool provides useful
process guidance, 51 respondents (61.45%) agree that Process Automation tool
provides useful process guidance, 2 respondents (2.41%) disagree that Process
Automation tool provides useful process guidance and none strongly disagreed that
Process Automation tool provides useful process guidance. It is understood that
majority of the respondents have agreed that Process Automation tool provides useful
process guidance.
3.5.Process Automation tool provides timely status information
Provides timely
Respondents
status information
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
47
36
0
0
0
Respondents %
56.63%
43.37%
0.00%
0.00%
0.00%
Figure GRP-G-03-05: Process Automation tool provides timely status information

respondents (56.63%) strongly agree that Process Automation tool provides timely
183
status information, 36 respondents (43.37%) agree that Process Automation tool

provides timely status information and none of the respondents neither disagreed not
strongly disagreed that Process Automation tool provides timely status information. It
is understood that majority of the respondents have agreed that Process Automation
tool provides timely status information.
3.6.Process Automation tool provides useful metrics data
Provides useful
metric data
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
41
40
2
0
0
49.40%
48.19%
2.41%
0.00%
0.00%
Figure GRP-G-03-06: Process Automation tool provides useful metrics data

respondents (49.4%) strongly agree that Process Automation tool provides useful
metrics data, 40 respondents (48.19%) agree that Process Automation tool provides
useful metrics data, 2 respondents (2.41%) disagree that Process Automation tool
provides useful metrics data and none strongly disagreed that Process Automation
tool provides useful metrics data. It is understood that majority of the respondents
have agreed that Process Automation tool provides useful metrics data.
3.7.Process Automation reduce costs
Reduces costs
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
37
39
2
0
5
Respondents %
44.58%
46.99%
2.41%
0.00%
6.02%
184
Figure GRP-G-03-07: Process Automation reduce costs

respondents (44.58%) strongly agree that Process Automation reduce costs, 39
respondents (46.99%) agree that Process Automation reduce costs, 2 respondents
(2.41%) disagree that Process Automation reduce costs and none strongly disagreed
that Process Automation reduce costs. It is understood that majority of the
respondents have agreed that Process Automation reduce costs.
4. Automation helped to enforce defined process
Automation
enforces Process
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
44
38
1
0
0
53.01%
45.78%
1.20%
0.00%
0.00%
Figure GRP-G-04: Automation helped to enforce defined process

respondents (53.01%) strongly agree that Process Automation helped to enforce defined
process, 38 respondents (45.78%) agree that Process Automation helped to enforce
defined process, 1 respondent (1.2%) disagree that Process Automation helped to enforce
defined process and none strongly disagreed that Process Automation helped to enforce
defined process. It is understood that majority of the respondents have agreed that
Process Automation helped to enforce defined process.
185
5. Implementation of Process Automation tool was challenging
Implementation
was Challenging
Strongly agree
Agree
Disagree
Stongly Disagree
DK/NA
Respondents
Respondents %
26
47
8
0
2
31.33%
56.63%
9.64%
0.00%
2.41%
Figure GRP-G-05: Implementation of Process Automation tool was challenging

respondents (31.33%) strongly agree that Implementation of Process Automation tool
was challenging, 47 respondents (56.63%) agree that Implementation of Process
Automation tool was challenging, 8 respondents (9.64%) disagree that Implementation of
Process Automation tool was challenging and none strongly disagreed that
Implementation of Process Automation tool was challenging. It is understood that
majority of the respondents have agreed that Implementation of Process Automation tool
was challenging.
6. The Process Automation met planned schedule
Automation met
Planned Schedule
Respondents
Respondents %
Significant delays
4.82%
Some delays
On time
26
35
31.33%
42.17%
Ahead of schedule
4.82%
DK/NA
14
16.87%
Figure GRP-G-06: The Process Automation met planned schedule

respondents (4.82%) say that there were significant delays in implementing the Process
186
Automation tool, 26 respondents (31.33%) say that there were some delays in
implementing the Process Automation tool, 35 respondents (42.17%) say that the Process
Automation tool met the planned schedule and 4 respondents (4.82) say that Process
Automation tool was implemented ahead of planned schedule. While delays are expected
while implementing such a large initiative across the organization, the responses indicate
that to a great extent the implementation took place either on time or without much delay.
7. Organizations plans to automate additional processes in future
Automate
Additional
Respondents
Processes in Future
55
18
10
Yes
No
DK/NA
Respondents %
66.27%
21.69%
12.05%
Figure GRP-G-07: Plans on automating additional processes in future

respondents (66.27%) say that their organizations will automate additional processes in
future and 18 respondents (21.69%) say that their organizations will not automate
additional processes in future. It is understood that majority of the respondents have
agreed that their organizations will automate additional processes in future.
4. 3 CORRELATION ANALYSIS
This section lays out the statistical hypotheses and details the statistical analysis
conducted on the data collected through questionnaire to prove or disprove these
hypotheses. These results eventually help in deciding whether the primary hypothesis is
accepted or not.
Hypothesis I: Business Product Characteristics has no significant influence on

Implementation Team Characteristics.
187
To substantiate this hypothesis with data, 5 questions from Group A (Business

Product Characteristics) and 7 questions from Group B (Implementation Team
Characteristics) are analyzed. However, since all results did not yield any correlation,
only relevant results are presented here.
Analysis H1.1:
Questions considered
1. Independent Variable - Group A Question 5: Organization culture with
10 different cultural aspects studied here.
2. Dependent Variable - Group B Question 1: How many people are
involved in developing the automated process?
Test applied: Chi-Square Test
Test Results: The below table is the result of Chi-Square Test conducted on data
depicted in figures GRP-A-06-01 to GRP-A-06-10 and GRP-B-01.
Organization Culture Vs Team size
Left
Organization
Culture
Team size
Count
Risk takers Vs
Conservative
% within
Formal Vs Informal
Count
% within
Many layers Vs
Flat organization
Count
Controlling Vs
Hands-off
Count
% within
% within
Count
Static environment
Vs Dynamic
% within
environment
Complacent Vs
Energetic
Count
Closed minded Vs
Open minded
Count
Political Vs Nonpolitical
Count
% within
% within
% within
Neutral
Right
Total
11-20
Over 20
Total
11-20
Over 20
Total
11-20
Over 20
Total
11-20
Over 20
Total
17
17
34
10
13
32
25
57
50.00%
50.00%
100.00%
60.00%
40.00%
100.00%
69.20%
30.80%
43.90%
100.00%
23
16
39
23
55
59.00%
41.00%
100.00%
50.00%
50.00%
100.00%
62.50%
37.50%
41.80%
100.00%
22
12
34
10
17
24
61
64.70%
35.30%
100.00%
41.20%
58.80%
100.00%
80.00%
20.00%
39.30%
100.00%
22
13
35
10
17
23
58
62.90%
37.10%
100.00%
41.20%
58.80%
100.00%
100.00%
0.00%
39.70%
100.00%
10
26
16
23
59
85.70%
14.30%
100.00%
40.00%
60.00%
100.00%
61.90%
38.10%
39.00%
100.00%
13
21
17
50.00%
50.00%
100.00%
69.20%
30.80%
100.00%
55.30%
44.70%
13
25
16
80.00%
20.00%
100.00%
53.80%
46.20%
100.00%
61.00%
39.00%
13
21
16
66.70%
33.30%
100.00%
38.10%
61.90%
100.00%
69.60%
30.40%
Count
Jobs are routine Vs
Jobs are exciting
% within
11
11
17
22
36.40%
63.60%
100.00%
35.30%
64.70%
100.00%
75.90%
24.10%
Stable staff Vs High Count

turnover
% within
14
12
21
14
64.30%
35.70%
100.00%
42.90%
57.10%
100.00%
70.00%
30.00%
100.00% 56.10%
8
32
100.00% 58.20%
10
37
100.00% 60.70%
6
35
100.00% 60.30%
42
36
100.00% 61.00%
38
32
100.00% 58.20%
41
36
100.00% 61.00%
23
30
100.00% 56.60%
29
32
100.00% 56.10%
20
32
100.00% 58.20%
23
55
41.80%
100.00%
23
59
39.00%
100.00%
23
53
43.40%
100.00%
25
57
43.90%
100.00%
23
55
41.80%
100.00%
Chisquare
DF
P-value
Result
1.486
0.476
NS
0.291
0.864
NS
4.505
0.105
NS
6.645
0.036
Significant
3.666
0.16
NS
0.895
0.639
NS
1.039
0.595
NS
4.873
0.087
NS
9.328
0.009
Significant
3.389
0.184
NS
Table ST-HYP-01-01: Organization culture Vs Team Size
From the above table, it is observed that only two out of ten cultural aspects of an
organization namely Controlling Vs Hands-off and Jobs are routine Vs Jobs are
exciting have significant influence on the size of the team involved in developing the
automated process. Hence, it can be concluded that the Cultural aspects of an
188
organization has little influence on the size of the team involved in developing the
automated process.
Analysis H1.2:
2. Dependent Variable - Group B Question 2: How many years of software
development experience does the process automation team leader have?
Organization Culture Vs Team Leader Experience
Team
Leader
Exp.
Organization
Culture
Count
Risk takers Vs
Conservative
% within
Formal Vs Informal
Count
% within
Many layers Vs
Flat organization
Count
Controlling Vs
Hands-off
Count
% within
% within
Static environment Count

Vs Dynamic
% within
environment
Complacent Vs
Energetic
Count
Closed minded Vs
Open minded
Count
Count
% within
% within
% within
Jobs are routine Vs Count

Jobs are exciting
% within
turnover
% within
Left
6-10
11-15
Neutral
over 15
Total
6-10
11-15
Right
over 15
Total
6-10
11-15
Total
over 15
Total
6-10
11-15
over 15
Total
20
12
35
15
34
21
58
8.60%
57.10%
34.30%
100.00%
0.00%
53.30%
46.70%
100.00%
0.00%
75.00%
25.00%
100.00%
5.20%
58.60%
36.20%
100.00%
18
11
31
13
13
30
24
57
6.50%
58.10%
35.50%
100.00%
0.00%
46.20%
53.80%
100.00%
7.70%
46.20%
46.20%
100.00%
5.30%
52.60%
42.10%
100.00%
20
17
40
30
23
56
7.50%
50.00%
42.50%
100.00%
0.00%
71.40%
28.60%
100.00%
0.00%
55.60%
44.40%
100.00%
5.40%
53.60%
41.10%
100.00%
17
13
34
18
10
33
24
62
11.80%
50.00%
38.20%
100.00%
0.00%
50.00%
50.00%
100.00%
10.00%
70.00%
20.00%
100.00%
8.10%
53.20%
38.70%
100.00%
11
19
17
42
30
22
59
0.00%
100.00%
0.00%
100.00%
9.10%
45.50%
45.50%
100.00%
14.30%
45.20%
40.50%
100.00%
11.90%
50.80%
37.30%
100.00%
11
21
19
42
30
23
56
0.00%
66.70%
33.30%
100.00%
9.10%
63.60%
27.30%
100.00%
4.80%
50.00%
45.20%
100.00%
5.40%
53.60%
41.10%
100.00%
10
21
20
47
30
24
61
0.00%
100.00%
0.00%
100.00%
10.00%
50.00%
40.00%
100.00%
12.80%
44.70%
42.60%
100.00%
11.50%
49.20%
39.30%
100.00%
13
21
16
25
29
23
54
0.00%
75.00%
25.00%
100.00%
4.80%
33.30%
61.90%
100.00%
4.00%
64.00%
32.00%
100.00%
3.70%
53.70%
42.60%
100.00%
14
15
18
29
30
24
58
0.00%
42.90%
57.10%
100.00%
6.70%
40.00%
53.30%
100.00%
10.30%
62.10%
27.60%
100.00%
6.90%
51.70%
41.40%
100.00%
14
10
20
13
22
30
23
56
7.10%
57.10%
35.70%
100.00%
5.00%
45.00%
50.00%
100.00%
4.50%
59.10%
36.40%
100.00%
5.40%
53.60%
41.10%
100.00%
Chisquare
DF
3.189
0.527
NS
2.093
0.719
NS
2.03
0.73
NS
4.205
0.379
NS
6.713
0.152
NS
1.61
0.807
NS
4.539
0.338
NS
6.236
0.182
NS
5.37
0.251
NS
1.153
0.886
NS
Table ST-HYP-01-02: Organization culture Vs Team Leaders Experience
From the above table, it is observed that none of the ten cultural aspects of an
organization have significant influence on the size of the team involved in developing the
organization has no influence on the experience of the person leading the team that
is involved in developing the automated process.
189
PResult
value
Analysis H1.3:

2. Dependent Variable - Group B Question 3: How many years of software
development experience do you have?
Organization Culture Vs Respondent's Experience
Organization
Culture
Respondent
Exp.
Risk takers Vs
Conservative
Count
Formal Vs Informal
% within
Count
% within
Many layers Vs
Flat organization
Count
Controlling Vs
Hands-off
Count
Left
Right
Total
3-5
6-10
11-15
over 15
Total
0-2
3-5
6-10
11-15
over 15
Total
0-2
3-5
6-10
11-15
over 15
Total
0-2
3-5
6-10
11-15
over 15
Total
13
10
37
17
17
17
17
62
13.50%
24.30%
35.10%
27.00%
0.00%
100.00%
23.50%
29.40%
17.60%
23.50%
5.90%
100.00%
0.00%
37.50%
12.50%
37.50%
12.50%
100.00%
14.50%
27.40%
27.40%
27.40%
3.20%
100.00%
11
34
13
14
12
15
17
15
61
20.60%
26.50%
32.40%
17.60%
2.90%
100.00%
38.50%
30.80%
23.10%
7.70%
0.00%
100.00%
0.00%
14.30%
21.40%
57.10%
7.10%
100.00%
19.70%
24.60%
27.90%
24.60%
3.30%
100.00%
% within
Neutral
0-2
18.20%
13
10
29.50%
22.70%
11
25.00%
2
4.50%
44
100.00%
2
25.00%
0
0.00%
2
25.00%
4
50.00%
0
0.00%
8
100.00%
0
0.00%
4
44.40%
3
33.30%
2
22.20%
0
0.00%
9
100.00%
10
16.40%
17
27.90%
15
24.60%
17
27.90%
2
3.30%
61
16
11
39
18
10
11
21
16
17
67
15.40%
41.00%
28.20%
15.40%
0.00%
100.00%
27.80%
11.10%
16.70%
33.30%
11.10%
100.00%
0.00%
30.00%
20.00%
50.00%
0.00%
100.00%
16.40%
31.30%
23.90%
25.40%
3.00%
100.00%

Vs Dynamic
% within
environment
11
17
45
10
19
17
15
63
0.00%
14.30%
28.60%
57.10%
0.00%
100.00%
9.10%
9.10%
54.50%
18.20%
9.10%
100.00%
20.00%
37.80%
20.00%
20.00%
2.20%
100.00%
15.90%
30.20%
27.00%
23.80%
3.20%
100.00%
13
11
13
44
10
16
16
17
61
75.00%
25.00%
7.70%
15.40%
Count
Closed minded Vs
Open minded
Count
Count
% within
% within
% within
0.00%
0.00%
0.00%
100.00%
15.40%
61.50%
0.00%
100.00%
20.50%
25.00%
29.50%
20.50%
4.50%
100.00%
16.40%
26.20%
26.20%
27.90%
3.30%
13
16
12
10
48
10
20
17
17
66
60.00%
0.00%
40.00%
0.00%
100.00%
7.70%
7.70%
38.50%
38.50%
7.70%
100.00%
18.80%
33.30%
25.00%
20.80%
2.10%
100.00%
15.20%
30.30%
25.80%
25.80%
3.00%
100.00%
23
11
27
10
15
15
17
59
0.00%
44.40%
33.30%
11.10%
11.10%
100.00%
26.10%
21.70%
26.10%
21.70%
4.30%
100.00%
14.80%
22.20%
22.20%
40.70%
0.00%
100.00%
16.90%
25.40%
25.40%
28.80%
3.40%
100.00%
17
17
10
10
29
10
17
17
17
63

Jobs are exciting
% within
17.60%

turnover
% within
16
22
10
23
10
16
16
17
61
18.80%
25.00%
6.30%
50.00%
0.00%
100.00%
22.70%
31.80%
22.70%
18.20%
4.50%
100.00%
8.70%
21.70%
43.50%
21.70%
4.30%
100.00%
16.40%
26.20%
26.20%
27.90%
3.30%
100.00%
35.30%
23.50%
0.00%
100.00%
29.40%
17.60%
23.50%
17.60%
11.80%
100.00%
6.90%
34.50%
24.10%
34.50%
0.00%
100.00%
15.90%
27.00%
27.00%
27.00%
3.20%
Pvalue
Result
0.366
NS
15.802
0.045
SignifIcant
7.838
0.449
NS
17.183
0.028
SignifIcant
14.15
0.078
NS
14.748
0.064
NS
10.438
0.236
NS
9.85
0.276
NS
11.935
0.154
NS
11.594
0.17
NS
100.00%
0
0.00%
23.50%
DF
8.724
100.00%
% within
Complacent Vs
Energetic
Chisquare
100.00%
Table ST-HYP-01-03: Organization culture Vs Respondents Experience
organization namely Formal Vs Informal and Controlling Vs Hands-off have
significant influence on the Respondents experience who have responded to the
questionnaire. Hence, it can be concluded that the Cultural aspects of an organization
has little influence on the Experience of the Respondents who have responded to the
questionnaire concerned with this particular research.
Analysis H1.4:
2. Dependent Variable - Group B Question 4: People with experience are
part of the development team with 6 different categories studied here.
Test applied: Non - parametric ANOVA (Kruskal-Wallis Test)
190
Test Results: The below table is the result of Kruskal-Wallis Test conducted on
data depicted in figures GRP-A-06-01 to GRP-A-06-10 and GRP-B-04.
Organization Culture Vs Team Experience
Organization
Culture
Team
Experience
Left
Neutral
Right
ChiSquare
Risk takers Vs
Conservative
Count
Mean Rank
37
29.23
17
30.32
8
44.5
6.289
Formal Vs Informal
Count
Mean Rank
34
27.15
13
35
14
36.64
4.681
Many layers Vs Flat

organization
Count
Mean Rank
44
32.64
8
24
9
29.22
2.175
Controlling Vs
Hands-off
Count
Mean Rank
39
34.73
18
30
10
38.35
1.736
Static environment
Vs Dynamic
environment
Complacent Vs
Energetic
Count
Mean Rank
7
40.43
11
33
45
30.44
2.441
Count
Mean Rank
4
27.38
13
36.04
44
29.84
1.785
Closed minded Vs
Open minded
Count
Mean Rank
5
41
13
33.38
48
32.75
1.1
Count
Mean Rank
9
29.33
23
24.74
27
34.7
5.419
Jobs are routine Vs

Jobs are exciting
Count
Mean Rank
17
29.35
17
31
29
34.14
1.02
Stable staff Vs High

turnover
Count
Mean Rank
16
29.06
22
30.77
23
32.57
0.475
DF
P-Value
Result
0.043
Significant
0.096
NS
0.337
NS
0.42
NS
0.295
NS
0.41
NS
0.577
NS
0.067
NS
0.601
NS
0.789
NS
Table ST-HYP-01-04: Organization culture Vs Team Experience
From the above table, it is observed that only one of the ten cultural aspects of an
organization namely Risk takers Vs Conservative have significant influence on the
Process Teams experience levels. Hence, it can be concluded that the Cultural aspects
of an organization has little influence on the Experience of the Team who developed
the Software Process Automation.
Analysis H1.5:
2. Dependent Variable - Group B Question 5: There are representatives
from each end-user project on the development team
191
Organization Culture Vs End-user Representation
Organization
Culture
End-user
Representation
Risk takers Vs
Conservative
Count
% within
Formal Vs Informal
Count
% within
Many layers Vs
Flat organization
Count
Controlling Vs
Hands-off
Count
% within
% within
Count
Static environment
Vs Dynamic
% within
environment
Complacent Vs
Energetic
Count
Closed minded Vs
Open minded
Count
Count
% within
% within
% within
Left
Neutral
Right
Total
Yes
No
Total
Yes
No
Total
Yes
No
Total
Yes
No
Total
29
33
15
17
52
58
87.90%
12.10%
100.00%
88.20%
11.80%
0.00%
100.00%
89.70%
10.30%
100.00%
26
30
13
13
12
14
51
57
86.70%
13.30%
100.00%
100.00%
0.00%
100.00%
85.70%
14.30%
100.00%
89.50%
10.50%
100.00%
40
40
51
57
100.00%
0.00%
100.00%
75.00%
25.00%
100.00%
55.60%
44.40%
100.00%
89.50%
10.50%
100.00%
29
35
16
18
10
10
55
63
82.90%
17.10%
100.00%
88.90%
11.10%
0.00%
100.00%
87.30%
12.70%
100.00%
43
45
55
61
71.40%
28.60%
100.00%
77.80%
22.20%
100.00%
95.60%
4.40%
100.00%
90.20%
9.80%
100.00%
100.00% 100.00%
100.00% 100.00%
11
38
42
51
57
100.00%
0.00%
100.00%
81.80%
18.20%
100.00%
90.50%
9.50%
100.00%
89.50%
10.50%
100.00%
11
11
41
45
55
61
60.00%
40.00%
100.00%
100.00%
0.00%
100.00%
91.10%
8.90%
100.00%
90.20%
9.80%
100.00%
17
21
23
25
49
55
100.00%
0.00%
100.00%
81.00%
19.00%
100.00%
92.00%
8.00%
100.00%
89.10%
10.90%
100.00%
Count
Jobs are routine Vs
Jobs are exciting
% within
13
17
15
15
25
27
53
59
76.50%
23.50%
100.00%
100.00%
0.00%
100.00%
92.60%
7.40%
100.00%
89.80%
10.20%
100.00%

turnover
% within
12
16
20
20
19
21
51
57
75.00%
25.00%
100.00%
100.00%
0.00%
100.00%
90.50%
9.50%
100.00%
89.50%
10.50%
100.00%
Chisquare
DF
P-value Result
1.072
0.585
NS
1.99
0.37
NS
17.479
Signifcant
2.119
0.347
NS
5.802
0.055
NS
1.2
0.549
NS
6.375
0.041
Signifcant
2.751
0.253
NS
5.245
0.073
NS
5.934
0.051
NS
Table ST-HYP-01-05: Organization culture Vs End-User Representation
organization namely Many layers Vs Flat Organization and Closed minded Vs Open
minded Organization have significant influence on the End-User Representation in
developing the automated process. Hence, it can be concluded that the Cultural aspects
of an organization has little influence on the End-User Representation in developing
the automated process.
Analysis H1.6:
2. Dependent Variable - Group B Question 6: Some of the expertise is
being provided by external consultants
192
Organization Culture Vs External Consultants Expertise

External
Consultants
Expertise
Organization
Culture
Count
Risk takers Vs
Conservative
% within
Formal Vs Informal
Count
% within
Many layers Vs
Flat organization
Count
Controlling Vs
Hands-off
Count
% within
% within
Count
Static environment
Vs Dynamic
% within
environment
Complacent Vs
Energetic
Count
Closed minded Vs
Open minded
Count
Count
Left
Yes
No
Neutral
Total
Yes
No
Right
Total
Yes
No
Total
Total
Yes
No
Total
12
11
23
17
24
24
48
52.20%
47.80%
100.00%
47.10%
52.90%
100.00%
50.00%
50.00%
100.00%
50.00%
50.00%
100.00%
12
12
24
13
10
22
25
47
50.00%
50.00%
100.00%
30.80%
69.20%
100.00%
60.00%
40.00%
100.00%
46.80%
53.20%
100.00%
12
23
35
20
27
47
34.30%
65.70%
100.00%
66.70%
33.30%
100.00%
66.70%
33.30%
100.00%
42.60%
57.40%
100.00%
15
20
35
11
27
27
54
42.90%
57.10%
100.00%
54.50%
45.50%
100.00%
75.00%
25.00%
100.00%
50.00%
50.00%
100.00%
20
18
38
26
25
51
80.00%
20.00%
100.00%
25.00%
75.00%
100.00%
52.60%
47.40%
100.00%
51.00%
49.00%
100.00%
10
16
17
33
20
27
47
0.00%
100.00%
100.00%
40.00%
60.00%
100.00%
48.50%
51.50%
100.00%
42.60%
57.40%
100.00%
12
19
16
35
25
27
52
40.00%
60.00%
100.00%
33.30%
66.70%
100.00%
54.30%
45.70%
100.00%
48.10%
51.90%
100.00%
14
18
10
19
18
27
45
50.00%
50.00%
100.00%
22.20%
77.80%
100.00%
52.60%
47.40%
100.00%
40.00%
60.00%
100.00%
Jobs are routine Vs

Jobs are exciting
% within
11
15
11
13
16
21
22
27
49
26.70%
73.30%
100.00%
15.40%
84.60%
100.00%
76.20%
23.80%
100.00%
44.90%
55.10%
100.00%

turnover
% within
12
14
18
10
17
20
27
47
50.00%
50.00%
100.00%
22.20%
77.80%
100.00%
58.80%
41.20%
100.00%
42.60%
57.40%
100.00%
% within
% within
% within
Count
Chisquare
DF
P-value Result
0.102
0.95
NS
2.14
0.343
NS
3.833
0.147
NS
NS
2.805
0.246
3.887
0.143
NS
3.465
0.177
NS
1.716
0.424
NS
3.967
0.138
NS
14.904
0.001
Signifcant
5.157
0.076
NS
Table ST-HYP-01-06: Organization culture Vs External Consultants Expertise
From the above table, it is observed that only one out of ten cultural aspects of an
organization namely Jobs are Routine Vs Jobs are Exciting has significant influence on
employing External Consultants to provide their expert consultation in developing the
organization has very little influence on employing External Consultants to provide
their expert consultation in developing the automated process.
Analysis H1.7:
being provided by subcontractors
193
Organization Culture Vs Subcontractor Expertise

Organization
Culture
Subcontractor
Expertise
Risk takers Vs
Conservative
Count
Left
% within
Count
Controlling Vs
Hands-off
Count
% within
% within
Yes
No
Total
Yes
No
Total
Yes
No
Total
22
24
13
15
43
47
8.30%
91.70%
100.00%
13.30%
86.70%
100.00%
0.00%
100.00%
100.00%
8.50%
91.50%
100.00%
18
22
11
11
11
11
40
44
18.20%
81.80%
100.00%
0.00%
100.00%
100.00%
0.00%
100.00%
100.00%
9.10%
90.90%
100.00%
30
34
42
46
11.80%
88.20%
100.00%
0.00%
100.00%
100.00%
0.00%
100.00%
100.00%
8.70%
91.30%
100.00%
24
29
11
13
42
49
17.20%
82.80%
100.00%
15.40%
84.60%
100.00%
0.00%
100.00%
100.00%
14.30%
85.70%
100.00%
27
31
40
44
0.00%
100.00%
100.00%
0.00%
100.00%
100.00%
12.90%
87.10%
100.00%
9.10%
90.90%
100.00%
10
10
26
30
40
44
0.00%
100.00%
100.00%
0.00%
100.00%
100.00%
13.30%
86.70%
100.00%
9.10%
90.90%
100.00%
10
10
25
30
40
45
0.00%
100.00%
100.00%
0.00%
100.00%
100.00%
16.70%
83.30%
100.00%
11.10%
88.90%
100.00%
14
16
20
20
40
42
0.00%
100.00%
100.00%
12.50%
87.50%
100.00%
0.00%
100.00%
100.00%
4.80%
95.20%
100.00%
13
13
11
11
16
20
40
44
0.00%
100.00%
100.00%
0.00%
100.00%
100.00%
20.00%
80.00%
100.00%
9.10%
90.90%
100.00%
12
14
14
14
14
16
40
44
14.30%
85.70%
100.00%
0.00%
100.00%
100.00%
12.50%
87.50%
100.00%
9.10%
90.90%
100.00%

Vs Dynamic
% within
environment
Count
Complacent Vs
Energetic
% within
Closed minded Vs
Open minded
Count
Count
% within
% within

Jobs are exciting
% within
turnover
% within
Total
Total
Count
Many layers Vs
Flat organization
Right
No
% within
Formal Vs Informal
Neutral
Yes
Chisquare
DF
P-value Result
1.193
0.551
NS
4.4
0.111
NS
1.546
0.462
NS
1.386
0.5
NS
1.845
0.397
NS
2.053
0.358
NS
2.813
0.245
NS
3.412
0.182
NS
5.28
0.071
NS
2.082
0.353
NS
Table ST-HYP-01-07: Organization culture Vs Subcontractor Expertise
organization have significant influence on employing Subcontractors Expertise and
involving them in developing the automated process. Hence, it can be concluded that the
Cultural aspects of an organization has no influence on employing Subcontractors
Expertise and involving them in developing the automated process.
Analysis H1.8:
1. Independent Variable - Group A Question 4: How often do you undergo
organizational change which affects the work you do?
2. Dependent Variable - Group B Question 1: How many people are
depicted in figures GRP-A-05 and GRP-B-01.
Frequency of Organizational Change Vs Team Size
Every few months
Team Size
Organization
Change
Count
% within
Yearly
Every few years
Total
11-20
Over 20
Total
11-20
Over 20
Total
11-20
Over 20
Total
11-20
Over 20
Total
11-20
Over 20
Total
19
11
30
18
14
16
45
28
73
33.33%
66.67%
100.00%
63.33%
36.67%
100.00%
50.00%
50.00%
100.00%
87.50%
12.50%
100.00%
61.64%
38.36%
100.00%
Chisquare
8.643
DF
P-value
0.034
Result
Signifcant
Table ST-HYP-01-08: Organizational Change Vs Team Size
194
From the above table, it is observed that the Frequency of Organizational

Changes has a significant influence on Process Automation Development Team Size.
Analysis H1.9:
2. Dependent Variable - Group B Question 5: There are representatives
from each end-user project on the development team.
Table ST-HYP-01-09: Organizational Change Vs End-User Representation

Changes has no significant influence on End-User Representation.
Analysis H1.10:
being provided by external consultants.
195
Table ST-HYP-01-10: Organizational Change Vs External Consultants Expertise

Changes has no significant influence on External Consultants Expertise.
Analysis H1.11:
being provided by subcontractors.
Table ST-HYP-01-11: Organizational Change Vs Subcontractor Expertise

Changes has no significant influence on Subcontractors Expertise.
Hypothesis I: Summary and Conclusion
From the above statistical analysis, it is understood there are few factors of the
independent variable Business Product Characteristics that significantly influence few
factors of the dependent variable Implementation Team Characteristics. Therefore, the
hypothesis is neither accepted nor rejected. Hence, it can be concluded that while
Business
Product
Characteristics
has
a relation
to
Implementation
Team
196
Characteristics, it does not have a significant influence on Implementation Team

Characteristics.
Hypothesis II: Business Product Characteristics has no significant influence on

Application Focus.

Product Characteristics) and 10 questions from Group C (Application Focus) are
analyzed. However, since all results did not yield any correlation, only relevant results
are presented here.
Analysis H2.1:
2. Dependent Variable - Group C Question 1: What general areas does the
automated processes address?
Test applied: Chi-Square
depicted in figures GRP-A-05 and GRP-C-01.
197
Frequency of Organizational Change Vs Areas Addressed by Automation

Areas Addressed
by Automation
Project
Initiation/Startup
Organizational Every few

Change
months
Count
10
% within $c1
12.5%
Count
10
Project Planning
% within $c1
12.5%
Project tracking &
Count
10
oversight
% within $c1
12.5%
Count
10
Project closure
12.5%
% within $c1
Requirements
Count
6
management
10.2%
% within $c1
Count
5
Design
8.6%
% within $c1
Software
Count
6
Development
% within $c1
18.2%
Count
10
% within $c1
12.5%
Count
10
Valiation/Testing
% within $c1
12.5%
Defect/Anomaly
10
Count
Tracking
% within $c1
12.5%
Release
5
Count
Management
% within $c1
8.6%
2
Count
Deployment
% within $c1
8.3%
Software
Count
10
Maintenance
% within $c1
12.5%
Hardware/Software Count
10
Servicing
% within $c1
12.5%
Change
Count
10
Management
% within $c1
12.5%
Configuration
Count
10
Management
12.5%
% within $c1
Document
Count
2
Management
8.3%
% within $c1
Count
5
Document Review
8.6%
% within $c1
Subcontractor
Count
2
Management
% within $c1
22.2%
Supplier
Count
2
Management
% within $c1
22.2%
Count
9
TQM Tools
% within $c1
13.0%
4
Count
Six Sigma Tools
% within $c1
8.3%
4
Count
Lean Principles
% within $c1
7.8%
2
Count
Other (Specify)
% within $c1
15.4%
Yearly
31
38.8%
31
38.8%
31
38.8%
31
38.8%
24
40.7%
25
43.1%
11
33.3%
31
38.8%
31
38.8%
31
38.8%
25
43.1%
8
33.3%
31
38.8%
31
38.8%
31
38.8%
31
38.8%
8
33.3%
25
43.1%
3
33.3%
3
33.3%
31
44.9%
21
43.8%
19
37.3%
7
53.8%
Every
few
years
23
Never
in my
experie
16
28.8%
23
28.8%
23
28.8%
23
28.8%
18
30.5%
15
25.9%
8
24.2%
23
28.8%
23
28.8%
23
28.8%
15
25.9%
8
33.3%
23
28.8%
23
28.8%
23
28.8%
23
28.8%
8
33.3%
15
25.9%
2
22.2%
2
22.2%
13
18.8%
10
20.8%
14
27.5%
2
15.4%
20.0%
16
20.0%
16
20.0%
16
20.0%
11
18.6%
13
22.4%
8
24.2%
16
20.0%
16
20.0%
16
20.0%
13
22.4%
6
25.0%
16
20.0%
16
20.0%
16
20.0%
16
20.0%
6
25.0%
13
22.4%
2
22.2%
2
22.2%
16
23.2%
13
27.1%
14
27.5%
2
15.4%
Total
Chi-square
DF
80
Nil
80
Nil
80
58
33
Nil
7.294
0.063
NS
4.581
0.205
NS
3.43
0.33
NS
80
Nil
80
Nil
80
58
24
Nil
4.581
0.205
NS
2.867
0.413
NS
80
Nil
80
Nil
80
Nil
80
24
58
9
9
69
48
51
13
Result
Nil
80
59
P-value
Nil
2.867
0.413
NS
4.581
0.205
NS
2.488
0.477
NS
2.488
0.477
NS
6.349
0.096
NS
39.279
Signifcant
44.009
Signifcant
2.389
0.496
NS
Table ST-HYP-02-01: Organizational Change Vs Areas of Automation
From the above table, it is observed that Frequency of Organizational Change has
no relation with 11 Process areas that may be addressed by Process Automation. Also,
Frequency of Organizational Change has no significant influence on 11 other Process
areas that may be addressed by Process Automation. However, Frequency of
Organizational Change has a significant influence on 2 Process areas that may be
addressed by Process Automation namely Six Sigma Tool and Lean Principles. Hence, it
can be concluded that the Frequency of Organizational Change has no major
198
influence on most of Process Areas that may be addressed by Process Automation as

perceived by the respondents.
Analysis H2.2:
2. Dependent Variable - Group C Question 2: What elements motivated the
management to consider the use of a process automation?
depicted in figures GRP-A-05 and GRP-C-02-01.
Frequency of Organizational Change Vs Motivating Elements
Motivating
Elements
Time to market
Management
oversight
Quality
Metrics
Productivity
Improvement
Process
Improvement
Other (Specify)
Organizational Every few

Change
months
Count
3
% within $c2
10.3%
Count
8
% within $c2
11.4%
Count
8
% within $c2
13.1%
Count
8
% within $c2
11.9%
Count
6
% within $c2
19.4%
Count
8
% within $c2
11.3%
Count
2
% within $c2
22.2%
Yearly
8
27.6%
27
38.6%
21
34.4%
27
40.3%
8
25.8%
27
38.0%
1
11.1%
Every
few
12
41.4%
21
30.0%
20
32.8%
20
29.9%
13
41.9%
22
31.0%
0
.0%
Never
in my
6
20.7%
14
20.0%
12
19.7%
12
17.9%
4
12.9%
14
19.7%
6
66.7%
Total
29
70
61
67
31
71
9
Chi-square
DF
P-value
Result
7.066
0.07
NS
0.548
0.908
NS
11.188
0.011
Signifcant
0.92
0.821
NS
0.52
0.915
NS
2.269
0.518
NS
2.488
0.477
NS
Table ST-HYP-02-02: Organizational Change Vs Motivating Elements
From the above table, it is observed that Frequency of Organizational Change has
no significant influence on 6 Motivating Elements and significant influence only on 1
Motivating Element namely Quality. Hence, it can be concluded that the Frequency of
Organizational Change has no major influence on most of Motivating Elements as
199
Analysis H2.3:
2. Dependent Variable - Group C Question 5: Approximately how many
elapsed days does (or will) the automated process take from initiation to
completion?
depicted in figures GRP-A-05 and GRP-C-05.
Frequency of Organizational Change Vs Elapsed Days from Initiation to Completion of Process Automation
Elapsed
Days
Organization Count
Change
% within
Every few months

1-10
11-100
30.00% 60.00%
Yearly
Over
100
Total
1-10
10
10.00% 100.00% 10.00%
Every few years
11-100
Over
100
Total
1-10
23
30
76.70% 13.30% 100.00% 9.50%
11-100
Over
100
Total
1-10
17
21
81.00%
9.50%
100.00%
0.00%
Total
11-100
Over
100
Total
1-10
11-100
Over
100
13
15
59
86.70% 13.30% 100.00% 10.50% 77.60% 11.80%
Total
76
ChiSquare
DF
6.01
P-value Result
0.422
NS
100.00%
Table ST-HYP-02-03: Organizational Change Vs Elapsed days of Process Automation

Changes has no significant influence on Elapsed Days from Initiation to Completion
of Process Automation.
Analysis H2.4:
1. Independent Variable - Group A Question 5: How would you
characterize your organization's culture?
Test Results: The two variables namely Organization Culture and Process Areas
addressed by Process Automation have multiple factors and hence a twodimensional analysis is conducted. Below tables are the result of Chi-Square Test
conducted on data depicted in figures GRP-A-06-01 to GRP-A-06-10 and GRPC-01.
200
Organizational Culture Vs Areas of Automation - Part I

Areas of
Automation
OrganizationC
ulture
Count
% within $c1
Count
Project Planning
% within $c1
Project tracking &
Count
oversight
% within $c1
Count
Project closure
% within $c1
Requirements
Count
management
% within $c1
Count
Design
% within $c1
Software
Count
Development
% within $c1
Count
% within $c1
Count
Valiation/Testing
% within $c1
Defect/Anomaly
Count
Tracking
% within $c1
Release
Count
Management
% within $c1
Count
Deployment
% within $c1
Software
Count
Maintenance
% within $c1
Hardware/Software Count
Servicing
% within $c1
Change
Count
Management
% within $c1
Configuration
Count
Management
% within $c1
Document
Count
Management
% within $c1
Count
Document Review
% within $c1
Subcontractor
Count
Management
% within $c1
Supplier
Count
Management
% within $c1
Count
TQM Tools
% within $c1
Count
Six Sigma Tools
% within $c1
Count
Lean Principles
% within $c1
Count
Other (Specify)
% within $c1
Project
Initiation/Startup
Risk takers Vs Conservative

Left
Neutral
Right
Total
37
59.7%
37
59.7%
37
59.7%
37
59.7%
26
59.1%
29
65.9%
15
68.2%
37
59.7%
37
59.7%
37
59.7%
29
65.9%
16
80.0%
37
59.7%
37
59.7%
37
59.7%
37
59.7%
16
80.0%
29
65.9%
8
100.0%
8
100.0%
28
52.8%
25
64.1%
24
63.2%
7
53.8%
17
27.4%
17
27.4%
17
27.4%
17
27.4%
12
27.3%
9
20.5%
7
31.8%
17
27.4%
17
27.4%
17
27.4%
9
20.5%
4
20.0%
17
27.4%
17
27.4%
17
27.4%
17
27.4%
4
20.0%
9
20.5%
0
.0%
0
.0%
17
32.1%
8
20.5%
8
21.1%
4
30.8%
8
12.9%
8
12.9%
8
12.9%
8
12.9%
6
13.6%
6
13.6%
0
.0%
8
12.9%
8
12.9%
8
12.9%
6
13.6%
0
.0%
8
12.9%
8
12.9%
8
12.9%
8
12.9%
0
.0%
6
13.6%
0
.0%
0
.0%
8
15.1%
6
15.4%
6
15.8%
2
15.4%
62
62
Nil
Nil
62
44
22
Nil
2.019
0.364
3.523
0.172
1.286
0.526
62
Nil
Nil
62
8
53
39
38
13
NS
Nil
62
NS
Nil
62
44
NS
3.523
0.172
0.537
0.765
62
20
NS
Nil
62
20
NS
Nil
62
44
Result
Nil
62
44
Formal Vs Informal
Chi-Square /
P-Value
Nil
0.537
0.765
3.523
0.172
0.407
0.816
0.407
0.816
0.948
0.622
1.102
0.576
2.843
0.241
1.625
0.444
NS
NS
NS
NS
NS
NS
NS
NS
Left
Neutral
Right
Total
34
55.7%
34
55.7%
34
55.7%
34
55.7%
24
55.8%
23
54.8%
13
52.0%
34
55.7%
34
55.7%
34
55.7%
23
54.8%
12
60.0%
34
55.7%
34
55.7%
34
55.7%
34
55.7%
12
60.0%
23
54.8%
5
62.5%
5
62.5%
26
53.1%
20
57.1%
21
56.8%
6
54.5%
13
21.3%
13
21.3%
13
21.3%
13
21.3%
7
16.3%
9
21.4%
6
24.0%
13
21.3%
13
21.3%
13
21.3%
9
21.4%
5
25.0%
13
21.3%
13
21.3%
13
21.3%
13
21.3%
5
25.0%
9
21.4%
0
.0%
0
.0%
10
20.4%
5
14.3%
7
18.9%
0
.0%
14
23.0%
14
23.0%
14
23.0%
14
23.0%
12
27.9%
10
23.8%
6
24.0%
14
23.0%
14
23.0%
14
23.0%
10
23.8%
3
15.0%
14
23.0%
14
23.0%
14
23.0%
14
23.0%
3
15.0%
10
23.8%
3
37.5%
3
37.5%
13
26.5%
10
28.6%
9
24.3%
5
45.5%
61
Chi-Square /
P-Value
61
Nil
61
Nil
61
43
42
25
Nil
0.508
0.776
1.338
0.512
0.896
0.639
61
Nil
Nil
61
8
49
35
37
11
NS
Nil
61
NS
Nil
61
42
NS
1.338
0.512
5.304
0.071
61
20
NS
Nil
61
20
NS
Nil
61
42
Result
Nil
Nil
5.304
0.071
1.338
0.512
4.137
0.126
4.137
0.126
0.094
0.954
2.649
0.266
8.782
0.012
2.304
0.316
NS
NS
NS
NS
NS
NS
Signifcant
NS
Table ST-HYP-02-04-01: Organization Culture Vs Areas of Automation - I
201
Organizational Culture Vs Areas of Automation - Part II

Many layers Vs Flat Orgn.
Areas of
Automation
Project
Initiation/Startup
Project Planning
Project tracking &
oversight
Project closure
Requirements
management
Design
Software
Development
Valiation/Testing
Defect/Anomaly
Tracking
Release
Management
Deployment
Software
Maintenance
Hardware/Software
Servicing
Change
Management
Configuration
Management
Document
Management
Document Review
Subcontractor
Management
Supplier
Management
TQM Tools
Six Sigma Tools
Lean Principles
Other (Specify)
OrganizationC
ulture
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
Left
Neutral
Right
Total
44
72.1%
44
72.1%
44
72.1%
44
72.1%
32
74.4%
31
73.8%
14
56.0%
44
72.1%
44
72.1%
44
72.1%
31
73.8%
14
70.0%
44
72.1%
44
72.1%
44
72.1%
44
72.1%
14
70.0%
31
73.8%
2
33.3%
2
33.3%
38
74.5%
24
66.7%
24
66.7%
9
69.2%
8
13.1%
8
13.1%
8
13.1%
8
13.1%
4
9.3%
6
14.3%
6
24.0%
8
13.1%
8
13.1%
8
13.1%
6
14.3%
2
10.0%
8
13.1%
8
13.1%
8
13.1%
8
13.1%
2
10.0%
6
14.3%
2
33.3%
2
33.3%
6
11.8%
6
16.7%
6
16.7%
2
15.4%
9
14.8%
9
14.8%
9
14.8%
9
14.8%
7
16.3%
5
11.9%
5
20.0%
9
14.8%
9
14.8%
9
14.8%
5
11.9%
4
20.0%
9
14.8%
9
14.8%
9
14.8%
9
14.8%
4
20.0%
5
11.9%
2
33.3%
2
33.3%
7
13.7%
6
16.7%
6
16.7%
2
15.4%
61
Nil
61
Nil
61
42
25
Nil
0.997
0.607
1.201
0.549
0.977
0.613
61
61
20
1.201
0.549
0.421
0.81
51
36
36
13
NS
Nil
Nil
61
NS
Nil
61
NS
Nil
61
42
NS
Nil
61
20
NS
Nil
61
42
Result
Nil
61
43
Controlling Vs Hands-off
Chi-Square /
P-Value
Nil
0.421
0.81
1.201
0.549
2.104
0.349
2.104
0.349
0.273
0.872
0.104
0.949
3.23
0.199
0.776
0.678
NS
NS
NS
NS
NS
NS
NS
NS
Left
Neutral
Right
Total
39
58.2%
39
58.2%
39
58.2%
39
58.2%
26
55.3%
23
50.0%
13
50.0%
39
58.2%
39
58.2%
39
58.2%
23
50.0%
14
66.7%
39
58.2%
39
58.2%
39
58.2%
39
58.2%
14
66.7%
23
50.0%
4
57.1%
4
57.1%
34
59.6%
22
53.7%
25
59.5%
8
66.7%
18
26.9%
18
26.9%
18
26.9%
18
26.9%
11
23.4%
13
28.3%
7
26.9%
18
26.9%
18
26.9%
18
26.9%
13
28.3%
5
23.8%
18
26.9%
18
26.9%
18
26.9%
18
26.9%
5
23.8%
13
28.3%
1
14.3%
1
14.3%
14
24.6%
11
26.8%
10
23.8%
2
16.7%
10
14.9%
10
14.9%
10
14.9%
10
14.9%
10
21.3%
10
21.7%
6
23.1%
10
14.9%
10
14.9%
10
14.9%
10
21.7%
2
9.5%
10
14.9%
10
14.9%
10
14.9%
10
14.9%
2
9.5%
10
21.7%
2
28.6%
2
28.6%
9
15.8%
8
19.5%
7
16.7%
2
16.7%
67
Chi-Square /
P-Value
Nil
67
Nil
67
Nil
67
47
46
26
Nil
1.717
0.424
3.491
0.175
1.865
0.394
67
67
21
Nil
57
41
42
12
NS
Nil
Nil
67
NS
Nil
67
NS
3.491
0.175
3.763
0.152
67
46
NS
Nil
67
21
NS
Nil
67
46
Result
Nil
3.763
0.152
3.491
0.175
3.118
0.21
3.118
0.21
0.53
0.767
1.902
0.386
5.335
0.069
3.783
0.151
NS
NS
NS
NS
NS
NS
NS
NS
Table ST-HYP-02-04-02: Organization Culture Vs Areas of Automation - II
Organizational Culture Vs Areas of Automation - Part III

Areas of
Automation
Project
Initiation/Startup
Project Planning
Project tracking &
oversight
Project closure
Requirements
management
Design
Software
Development
Valiation/Testing
Defect/Anomaly
Tracking
Release
Management
Deployment
Software
Maintenance
Hardware/Software
Servicing
Change
Management
Configuration
Management
Document
Management
Document Review
Subcontractor
Management
Supplier
Management
TQM Tools
Six Sigma Tools
Lean Principles
Other (Specify)
OrganizationC
ulture
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
Left
Neutral
Right
Total
7
11.1%
7
11.1%
7
11.1%
7
11.1%
5
10.6%
5
11.4%
2
8.0%
7
11.1%
7
11.1%
7
11.1%
5
11.4%
4
22.2%
7
11.1%
7
11.1%
7
11.1%
7
11.1%
4
22.2%
5
11.4%
2
20.0%
2
20.0%
7
13.2%
6
15.8%
6
15.8%
2
15.4%
11
17.5%
11
17.5%
11
17.5%
11
17.5%
7
14.9%
6
13.6%
6
24.0%
11
17.5%
11
17.5%
11
17.5%
6
13.6%
3
16.7%
11
17.5%
11
17.5%
11
17.5%
11
17.5%
3
16.7%
6
13.6%
2
20.0%
2
20.0%
10
18.9%
8
21.1%
6
15.8%
5
38.5%
45
71.4%
45
71.4%
45
71.4%
45
71.4%
35
74.5%
33
75.0%
17
68.0%
45
71.4%
45
71.4%
45
71.4%
33
75.0%
11
61.1%
45
71.4%
45
71.4%
45
71.4%
45
71.4%
11
61.1%
33
75.0%
6
60.0%
6
60.0%
36
67.9%
24
63.2%
26
68.4%
6
46.2%
63
Nil
63
Nil
63
44
25
Nil
3.47
0.176
3.688
0.158
0.083
0.959
63
3.688
0.158
0.524
0.769
Nil
63
10
53
38
38
13
NS
Nil
63
10
NS
Nil
63
44
NS
Nil
63
18
NS
Nil
63
18
NS
Nil
63
44
Result
Nil
63
47
Chi-Square /
P-Value
Nil
0.524
0.769
3.688
0.158
4.126
0.127
4.126
0.127
1.107
0.575
2.967
0.227
5.991
0.05
0.897
0.639
NS
NS
NS
NS
NS
NS
Signifcant
NS
Left
Neutral
Right
Total
4
6.6%
4
6.6%
4
6.6%
4
6.6%
4
9.3%
3
7.1%
1
4.0%
4
6.6%
4
6.6%
4
6.6%
3
7.1%
0
.0%
4
6.6%
4
6.6%
4
6.6%
4
6.6%
0
.0%
3
7.1%
0
.0%
0
.0%
4
7.8%
2
5.6%
2
5.6%
2
15.4%
13
21.3%
13
21.3%
13
21.3%
13
21.3%
9
20.9%
7
16.7%
5
20.0%
13
21.3%
13
21.3%
13
21.3%
7
16.7%
2
10.0%
13
21.3%
13
21.3%
13
21.3%
13
21.3%
2
10.0%
7
16.7%
1
12.5%
1
12.5%
11
21.6%
10
27.8%
10
27.8%
4
30.8%
44
72.1%
44
72.1%
44
72.1%
44
72.1%
30
69.8%
32
76.2%
19
76.0%
44
72.1%
44
72.1%
44
72.1%
32
76.2%
18
90.0%
44
72.1%
44
72.1%
44
72.1%
44
72.1%
18
90.0%
32
76.2%
7
87.5%
7
87.5%
36
70.6%
24
66.7%
24
66.7%
7
53.8%
61
61
61
61
43
42
25
61
61
61
42
20
61
61
61
61
20
42
8
8
51
36
36
13
Chi-Square /
P-Value
Result
Nil
Nil
Nil
Nil
0.253
0.881
2.763
0.251
1.347
0.51
NS
NS
NS
Nil
Nil
Nil
2.763
0.251
1.066
0.587
NS
NS
Nil
Nil
Nil
Nil
1.066
0.587
2.763
0.251
2.571
0.277
2.571
0.277
5.8
0.055
3.009
0.222
1.255
0.534
0.743
0.69
NS
NS
NS
NS
NS
NS
NS
NS
Table ST-HYP-02-04-03: Organization Culture Vs Areas of Automation - III
202
Organizational Culture Vs Areas of Automation - Part IV

Areas of
Automation
Project
Initiation/Startup
Project Planning
Project tracking &
oversight
Project closure
Requirements
management
Design
Software
Development
Valiation/Testing
Defect/Anomaly
Tracking
Release
Management
Deployment
Software
Maintenance
Hardware/Software
Servicing
Change
Management
Configuration
Management
Document
Management
Document Review
Subcontractor
Management
Supplier
Management
TQM Tools
Six Sigma Tools
Lean Principles
Other (Specify)
OrganizationC
ulture
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
Left
Neutral
Right
Total
5
7.6%
5
7.6%
5
7.6%
5
7.6%
3
6.4%
3
6.5%
2
7.4%
5
7.6%
5
7.6%
5
7.6%
3
6.5%
0
.0%
5
7.6%
5
7.6%
5
7.6%
5
7.6%
0
.0%
3
6.5%
0
.0%
0
.0%
5
8.9%
4
10.3%
4
10.3%
4
30.8%
13
19.7%
13
19.7%
13
19.7%
13
19.7%
11
23.4%
9
19.6%
5
18.5%
13
19.7%
13
19.7%
13
19.7%
9
19.6%
3
15.0%
13
19.7%
13
19.7%
13
19.7%
13
19.7%
3
15.0%
9
19.6%
4
50.0%
4
50.0%
12
21.4%
10
25.6%
8
20.5%
3
23.1%
48
72.7%
48
72.7%
48
72.7%
48
72.7%
33
70.2%
34
73.9%
20
74.1%
48
72.7%
48
72.7%
48
72.7%
34
73.9%
17
85.0%
48
72.7%
48
72.7%
48
72.7%
48
72.7%
17
85.0%
34
73.9%
4
50.0%
4
50.0%
39
69.6%
25
64.1%
27
69.2%
6
46.2%
66
Nil
66
Nil
66
46
27
Nil
0.554
0.758
2.649
0.266
4.48
0.106
66
66
20
2.649
0.266
3.627
0.163
56
39
39
13
NS
Nil
Nil
66
NS
Nil
66
NS
Nil
66
46
NS
Nil
66
20
NS
Nil
66
46
Result
Nil
66
47
Chi-Square /
P-Value
Nil
3.627
0.163
2.649
0.266
2.122
0.346
2.122
0.346
0.944
0.624
4.149
0.126
2.226
0.329
3.622
0.164
NS
NS
NS
NS
NS
NS
NS
NS
Left
Neutral
Right
Total
9
15.3%
9
15.3%
9
15.3%
9
15.3%
9
22.0%
8
20.0%
2
8.0%
9
15.3%
9
15.3%
9
15.3%
8
20.0%
1
5.0%
9
15.3%
9
15.3%
9
15.3%
9
15.3%
1
5.0%
8
20.0%
1
12.5%
1
12.5%
9
18.4%
7
20.0%
6
17.6%
3
23.1%
23
39.0%
23
39.0%
23
39.0%
23
39.0%
11
26.8%
9
22.5%
11
44.0%
23
39.0%
23
39.0%
23
39.0%
9
22.5%
7
35.0%
23
39.0%
23
39.0%
23
39.0%
23
39.0%
7
35.0%
9
22.5%
3
37.5%
3
37.5%
18
36.7%
11
31.4%
11
32.4%
6
46.2%
27
45.8%
27
45.8%
27
45.8%
27
45.8%
21
51.2%
23
57.5%
12
48.0%
27
45.8%
27
45.8%
27
45.8%
23
57.5%
12
60.0%
27
45.8%
27
45.8%
27
45.8%
27
45.8%
12
60.0%
23
57.5%
4
50.0%
4
50.0%
22
44.9%
17
48.6%
17
50.0%
4
30.8%
59
Chi-Square /
P-Value
Nil
59
Nil
59
Nil
59
41
40
25
Nil
1.849
0.397
7.427
0.024
0.276
0.871
59
59
20
Nil
7.427
0.024
6.424
0.04
59
8
49
35
34
13
Signifcant
Nil
Nil
59
Signifcant
Nil
59
40
NS
Nil
59
20
NS
Signifcant
Nil
59
40
Result
Nil
6.424
0.04
7.427
0.024
1.711
0.425
1.711
0.425
0.1
0.951
2.589
0.274
2.514
0.284
3.468
0.177
Signifcant
Signifcant
NS
NS
NS
NS
NS
NS
Table ST-HYP-02-04-04: Organization Culture Vs Areas of Automation - IV
Organizational Culture Vs Areas of Automation - Part V

Areas of
Automation
Project
Initiation/Startup
Project Planning
Project tracking &
oversight
Project closure
Requirements
management
Design
Software
Development
Valiation/Testing
Defect/Anomaly
Tracking
Release
Management
Deployment
Software
Maintenance
Hardware/Software
Servicing
Change
Management
Configuration
Management
Document
Management
Document Review
Subcontractor
Management
Supplier
Management
TQM Tools
Six Sigma Tools
Lean Principles
Other (Specify)
OrganizationC
ulture
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
Count
% within
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
$c1
Left
Neutral
Right
Total
17
27.0%
17
27.0%
17
27.0%
17
27.0%
8
17.8%
10
22.7%
8
29.6%
17
27.0%
17
27.0%
17
27.0%
10
22.7%
6
30.0%
17
27.0%
17
27.0%
17
27.0%
17
27.0%
6
30.0%
10
22.7%
3
37.5%
3
37.5%
16
30.2%
8
21.1%
7
18.9%
4
30.8%
17
27.0%
17
27.0%
17
27.0%
17
27.0%
13
28.9%
11
25.0%
6
22.2%
17
27.0%
17
27.0%
17
27.0%
11
25.0%
3
15.0%
17
27.0%
17
27.0%
17
27.0%
17
27.0%
3
15.0%
11
25.0%
1
12.5%
1
12.5%
13
24.5%
8
21.1%
9
24.3%
5
38.5%
29
46.0%
29
46.0%
29
46.0%
29
46.0%
24
53.3%
23
52.3%
13
48.1%
29
46.0%
29
46.0%
29
46.0%
23
52.3%
11
55.0%
29
46.0%
29
46.0%
29
46.0%
29
46.0%
11
55.0%
23
52.3%
4
50.0%
4
50.0%
24
45.3%
22
57.9%
21
56.8%
4
30.8%
63
Chi-Square /
P-Value
Nil
63
Nil
63
Nil
63
45
44
27
Nil
0.986
0.611
1.084
0.581
1.507
0.471
63
1.084
0.581
2.331
0.312
Nil
63
8
53
38
37
13
NS
Nil
63
NS
Nil
63
44
NS
Nil
63
20
NS
Nil
63
20
NS
Nil
63
44

Result
Nil
2.331
0.312
1.084
0.581
1.796
0.407
1.796
0.407
2.338
0.311
1.013
0.603
3.057
0.217
4.227
0.121
NS
NS
NS
NS
NS
NS
NS
NS
Left
Neutral
Right
Total
16
26.2%
16
26.2%
16
26.2%
16
26.2%
12
27.9%
12
28.6%
6
24.0%
16
26.2%
16
26.2%
16
26.2%
12
28.6%
6
30.0%
16
26.2%
16
26.2%
16
26.2%
16
26.2%
6
30.0%
12
28.6%
1
12.5%
1
12.5%
11
21.6%
10
27.8%
11
30.6%
2
15.4%
22
36.1%
22
36.1%
22
36.1%
22
36.1%
17
39.5%
13
31.0%
8
32.0%
22
36.1%
22
36.1%
22
36.1%
13
31.0%
5
25.0%
22
36.1%
22
36.1%
22
36.1%
22
36.1%
5
25.0%
13
31.0%
1
12.5%
1
12.5%
17
33.3%
9
25.0%
10
27.8%
7
53.8%
23
37.7%
23
37.7%
23
37.7%
23
37.7%
14
32.6%
17
40.5%
11
44.0%
23
37.7%
23
37.7%
23
37.7%
17
40.5%
9
45.0%
23
37.7%
23
37.7%
23
37.7%
23
37.7%
9
45.0%
17
40.5%
6
75.0%
6
75.0%
23
45.1%
17
47.2%
15
41.7%
4
30.8%
61
Chi-Square /
P-Value
61
Nil
61
Nil
61
43
42
25
Nil
1.185
0.553
0.461
0.794
1.778
0.411
61
Nil
Nil
61
8
51
36
36
13
NS
Nil
61
NS
Nil
61
42
NS
0.461
0.794
1.254
0.534
61
20
NS
Nil
61
20
NS
Nil
61
42
Result
Nil
Nil
1.254
0.534
0.461
0.794
0.624
0.732
0.624
0.732
0.545
0.761
8.507
0.014
3.881
0.144
1.253
0.535
NS
NS
NS
NS
NS
Signifcant
NS
NS
Table ST-HYP-02-04-05: Organization Culture Vs Areas of Automation - V
203
1. From table ST-HYP-02-04-01, it is observed that the first cultural aspect namely
Risk takers Vs Conservative organization has no relation with 11 Process areas
that may be addressed by Process Automation. Also, the cultural aspect Risk
takers Vs Conservative organization has no significant influence on 13 other
Process areas that may be addressed by Process Automation. Hence, it can be
concluded that, the Cultural aspect Risk takers Vs Conservative organization
has no significant influence on all the Process Areas addressed by Process
Automation as perceived by the respondents.
2. From table ST-HYP-02-04-01, it is also observed that the second Cultural aspect
namely Formal Vs Informal has no relation with 11 Process areas that may be
addressed by Process Automation. Also, the Cultural aspect Formal Vs
Informal has no significant influence on 12 other Process areas that may be
addressed by Process Automation. However, the Cultural aspect Formal Vs
Informal has a significant influence on just one Process area that may be
addressed by Process Automation namely Lean Principles. Hence, it can be
concluded that the Cultural aspect Formal Vs Informal has no major influence
on the Process Areas addressed by Process Automation as perceived by the
respondents.
3. From table ST-HYP-02-04-02, it is observed that the third cultural aspect namely
Many Layers Vs Flat Organization has no relation with 11 Process areas that
may be addressed by Process Automation. Also, the cultural aspect Many Layers
Vs Flat Organization has no significant influence on 13 other Process areas that
may be addressed by Process Automation. Hence, it can be concluded that the
Cultural aspect Many Layers Vs Flat Organization has no significant influence
on all the Process Areas addressed by Process Automation as perceived by the
respondents.
4. From table ST-HYP-02-04-02, it is also observed that the fourth cultural aspect
namely Controlling Vs Hands-Off Organization has no relation with 11 Process
areas that may be addressed by Process Automation. Also, the cultural aspect
Controlling Vs Hands-Off Organization has no significant influence on 13 other
Process areas that may be addressed by Process Automation. Hence, it can be
204
concluded that the Cultural aspect Controlling Vs Hands-Off Organization has

no significant influence on all the Process Areas addressed by Process
5. From table ST-HYP-02-04-03, it is observed that the fifth cultural aspect namely
Static Vs Dynamic Environment has no relation with 11 Process areas that may
be addressed by Process Automation. Also, the cultural aspect Static Vs
Dynamic Environment has no significant influence on 13 other Process areas
that may be addressed by Process Automation. However, Frequency of
Organizational Change has a significant influence on just one Process area that
may be addressed by Process Automation namely Lean Principles. Hence, it can
be concluded that the Cultural aspect Static Vs Dynamic Environment has no
significant influence on all the Process Areas addressed by Process Automation as
6. From table ST-HYP-02-04-03, it is also observed that the sixth cultural aspect
namely Complacent Vs Energetic has no relation with 11 Process areas that
may be addressed by Process Automation. Also, the cultural aspect Complacent
Vs Energetic has no significant influence on 13 other Process areas that may be
addressed by Process Automation. Hence, it can be concluded that the Cultural
aspect Complacent Vs Energetic has no significant influence on all the Process
Areas addressed by Process Automation as perceived by the respondents.
7. From table ST-HYP-02-04-04, it is observed that the seventh cultural aspect
namely Closed Minded Vs Open Minded has no relation with 11 Process areas
that may be addressed by Process Automation. Also, the cultural aspect Closed
Minded Vs Open Minded has no significant influence on 13 other Process areas
that may be addressed by Process Automation. Hence, it can be concluded that the
Cultural aspect Closed Minded Vs Open Minded has no significant influence on
all the Process Areas addressed by Process Automation as perceived by the
respondents.
8. From table ST-HYP-02-04-04, it is also observed that the eighth cultural aspect
namely Political Vs Non-Political has no relation with 11 Process areas that
may be addressed by Process Automation. Also, the cultural aspect Political Vs
205
Non-Political has no significant influence on 8 other Process areas that may be

addressed by Process Automation. However, the cultural aspect Political Vs
Non-Political has a significant influence on five Process areas that may be
addressed by Process Automation namely Software Design, Release Management,
Deployment, Document Management and Document Review. Hence, it can be
concluded that the Cultural aspect Political Vs Non-Political has a slight
influence on the Process Areas addressed by Process Automation as perceived by
the respondents.
9. From table ST-HYP-02-04-05, it is observed that the ninth cultural aspect namely
Jobs are Routine Vs Jobs are Exciting has no relation with 11 Process areas that
may be addressed by Process Automation. Also, the cultural aspect Jobs are
Routine Vs Jobs are Exciting has no significant influence on 13 other Process
areas that may be addressed by Process Automation. Hence, it can be concluded
that the Cultural aspect Jobs are Routine Vs Jobs are Exciting has no significant
influence on all the Process Areas addressed by Process Automation as perceived
by the respondents.
10. From table ST-HYP-02-04-05, it is also observed that the tenth cultural aspect
namely Stable Staff Vs High Turnover has no relation with 11 Process areas
that may be addressed by Process Automation. Also, the cultural aspect Stable
Staff Vs High Turnover has no significant influence on 12 other Process areas
that may be addressed by Process Automation. However, the cultural aspect
Stable Staff Vs High Turnover has a significant influence on just one Process
area that may be addressed by Process Automation namely Six sigma tools.
Hence, it can be concluded that the Cultural aspect Stable Staff Vs High
Turnover has no major influence on the Process Areas addressed by Process
Therefore, it can be concluded that the Cultural aspects of an organization has no

major influence on Process areas addressed by Process Automation.
206
Analysis H2.5:
2. Dependent Variable - Group C Question 2: What elements motivated the
management to consider the use of a process automation?
Test Results: The two variables namely Organization Culture and Motivating
Elements have multiple factors and hence a two-dimensional analysis is
conducted. Below tables are the result of Chi-Square Test conducted on data
depicted in figures GRP-A-06-01 to GRP-A-06-10 and GRP-C-02-01.
Organizational Culture Vs Motivating Elements - Part I
Risk takers Vs Conservative
Motivating
Elements
Organization
Culture
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Time to market
Management
oversight
Quality
Metrics
Productivity
Improvement
Process
Improvement
Other (Specify)
Left
Neutral
Right
15
68.2%
29
53.7%
27
58.7%
29
55.8%
19
86.4%
33
58.9%
6
75.0%
5
22.7%
17
31.5%
15
32.6%
15
28.8%
3
13.6%
15
26.8%
2
25.0%
2
9.1%
8
14.8%
4
8.7%
8
15.4%
0
.0%
8
14.3%
0
.0%
Total
22
54
46
52
22
56
8
Chi-Square /
P-Value
1.468
0.48
3.24
0.198
1.307
0.52
3.652
0.161
2.019
0.364
1.78
0.411
1.205
0.547
Formal Vs Informal
Result
NS
NS
NS
NS
NS
NS
NS
Left
Neutral
Right
12
54.5%
28
52.8%
24
51.1%
26
51.0%
10
43.5%
30
54.5%
5
62.5%
2
9.1%
13
24.5%
13
27.7%
13
25.5%
5
21.7%
13
23.6%
2
25.0%
8
36.4%
12
22.6%
10
21.3%
12
23.5%
8
34.8%
12
21.8%
1
12.5%
Total
22
53
47
51
23
55
8
Chi-Square /
P-Value
1.203
0.548
1.806
0.405
0.846
0.655
0.364
0.834
3.244
0.197
0.174
0.917
1.239
0.538
Result
NS
NS
NS
NS
NS
NS
NS
Table ST-HYP-02-05-01: Organization Culture Vs Motivating Elements - I
Organizational Culture Vs Motivating Elements - Part II

Many layers Vs Flat Organization
Motivating
Elements
Time to market
Management
oversight
Quality
Metrics
Productivity
Improvement
Process
Improvement
Other (Specify)
Organization
Culture
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Left
Neutral
Right
15
68.2%
40
75.5%
34
75.6%
40
78.4%
14
60.9%
42
76.4%
6
75.0%
4
18.2%
8
15.1%
6
13.3%
6
11.8%
2
8.7%
6
10.9%
2
25.0%
3
13.6%
5
9.4%
5
11.1%
5
9.8%
7
30.4%
7
12.7%
0
.0%
Total
22
53
45
51
23
55
8
Chi-Square /
P-Value
2.078
0.354
6.398
0.041
0.174
0.917
3.879
0.144
2.822
0.244
3.636
0.162
0.045
0.978
Controlling Vs Hands-off
Result
NS
Signifcant
NS
NS
NS
NS
NS
Left
Neutral
Right
8
33.3%
31
54.4%
29
56.9%
29
52.7%
11
45.8%
33
55.9%
8
88.9%
8
33.3%
16
28.1%
12
23.5%
16
29.1%
5
20.8%
16
27.1%
1
11.1%
8
33.3%
10
17.5%
10
19.6%
10
18.2%
8
33.3%
10
16.9%
0
.0%
Total
24
57
51
55
24
59
9
Chi-Square /
P-Value
0.047
0.977
1.909
0.385
2.335
0.311
2.944
0.229
3.433
0.18
6.601
0.037
0.678
0.712
Result
NS
NS
NS
NS
NS
Signifcant
NS
Table ST-HYP-02-05-02: Organization Culture Vs Motivating Elements II
207
Organizational Culture Vs Motivating Elements - Part III

Motivating
Elements
Organization
Culture
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Time to market
Management
oversight
Quality
Metrics
Productivity
Improvement
Process
Improvement
Other (Specify)
Left
Neutral
Right
Total
0
.0%
7
12.3%
3
6.4%
5
9.1%
2
8.7%
5
8.8%
0
.0%
5
19.2%
7
12.3%
7
14.9%
7
12.7%
4
17.4%
7
12.3%
2
25.0%
21
80.8%
43
75.4%
37
78.7%
43
78.2%
17
73.9%
45
78.9%
6
75.0%
26
57
47
55
23
57
8
Chi-Square /
P-Value
1.522
0.467
2.156
0.34
1.066
0.587
3.273
0.195
1.018
0.601
2.395
0.302
0.161
0.922
Result
NS
NS
NS
NS
NS
NS
NS
Left
Neutral
Right
Total
0
.0%
4
7.5%
2
4.4%
4
7.8%
1
4.0%
4
7.3%
0
.0%
3
13.6%
11
20.8%
7
15.6%
9
17.6%
0
.0%
9
16.4%
1
16.7%
19
86.4%
38
71.7%
36
80.0%
38
74.5%
24
96.0%
42
76.4%
5
83.3%
22
53
45
51
25
55
6
Chi-Square /
P-Value
0.081
0.961
1.092
0.579
0.176
0.916
1.296
0.523
0.168
0.919
0.897
0.639
4.51
0.105
Result
NS
NS
NS
NS
NS
NS
NS
Table ST-HYP-02-05-03: Organization Culture Vs Motivating Elements - III
Organizational Culture Vs Motivating Elements - Part IV

Motivating
Elements
Organization
Culture
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Time to market
Management
oversight
Quality
Metrics
Productivity
Improvement
Process
Improvement
Other (Specify)
Left
Neutral
Right
Total
0
.0%
5
8.6%
1
2.1%
3
5.5%
0
.0%
3
5.1%
0
.0%
6
23.1%
11
19.0%
9
19.1%
11
20.0%
1
4.0%
11
18.6%
4
50.0%
20
76.9%
42
72.4%
37
78.7%
41
74.5%
24
96.0%
45
76.3%
4
50.0%
26
58
47
55
25
59
8
Chi-Square /
P-Value
2.626
0.269
2.57
0.277
3.523
0.172
3.835
0.147
4.451
0.108
1.54
0.463
5.081
0.079
Result
NS
NS
NS
NS
NS
NS
NS
Left
Neutral
Right
Total
5
25.0%
9
17.6%
5
11.6%
9
18.4%
4
16.0%
9
17.0%
1
25.0%
4
20.0%
19
37.3%
17
39.5%
17
34.7%
5
20.0%
17
32.1%
3
75.0%
11
55.0%
23
45.1%
21
48.8%
23
46.9%
16
64.0%
27
50.9%
0
.0%
20
51
43
49
25
53
4
Chi-Square /
P-Value
0.733
0.693
1.117
0.572
0.208
0.901
1.041
0.594
6.28
0.043
7.956
0.019
7.305
0.026
Result
NS
NS
NS
NS
Signifcant
Signifcant
Signifcant
Table ST-HYP-02-05-04: Organization Culture Vs Motivating Elements - IV
Organizational Culture Vs Motivating Elements - Part V

Motivating
Elements
Time to market
Management
oversight
Quality
Metrics
Productivity
Improvement
Process
Improvement
Other (Specify)
Organization
Culture
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2
Count
% within $c2

Left
Neutral
Right
Total
2
9.1%
15
27.3%
13
27.7%
13
24.5%
8
29.6%
13
22.8%
3
50.0%
8
36.4%
15
27.3%
13
27.7%
15
28.3%
5
18.5%
15
26.3%
1
16.7%
12
54.5%
25
45.5%
21
44.7%
25
47.2%
14
51.9%
29
50.9%
2
33.3%
22
55
47
53
27
57
6
Chi-Square /
P-Value
1.084
0.581
0.094
0.954
2.299
0.317
0.284
0.868
0.487
0.784
1.815
0.404
1.642
0.44

Result
NS
NS
NS
NS
NS
NS
NS
Left
Neutral
Right
Total
4
18.2%
14
26.4%
10
22.2%
12
23.5%
6
24.0%
14
25.5%
3
50.0%
10
45.5%
20
37.7%
20
44.4%
20
39.2%
9
36.0%
20
36.4%
1
16.7%
8
36.4%
19
35.8%
15
33.3%
19
37.3%
10
40.0%
21
38.2%
2
33.3%
22
53
45
51
25
55
6
Chi-Square /
P-Value
0.428
0.807
2.553
0.279
0.685
0.71
1.349
0.51
7.431
0.024
0.245
0.885
3.83
0.147
Result
NS
NS
NS
NS
Signifcant
NS
NS
Table ST-HYP-02-05-05: Organization Culture Vs Motivating Elements - V
1. From table ST-HYP-02-05-01, it is observed that the first cultural aspect namely
Risk takers Vs Conservative organization has no significant influence on all the
seven Motivating elements as perceived by the respondents. Hence, it can be
concluded that the Cultural aspect Risk takers Vs Conservative organization has
208
no significant influence on all the Motivating Elements as perceived by the

respondents.
2. From table ST-HYP-02-05-01, it is also observed that the second cultural aspect
namely Formal Vs Informal has no significant influence on all the seven
Motivating elements as perceived by the respondents. Hence, it can be concluded
that the Cultural aspect Formal Vs Informal has no significant influence on all
the Motivating Elements as perceived by the respondents.
3. From table ST-HYP-02-05-02, it is observed that the third cultural aspect namely
Many Layers Vs Flat Organization has no significant influence on six of the
seven Motivating elements as perceived by the respondents. However, the cultural
aspect Many Layers Vs Flat Organization has a significant influence only on
the Motivating Element, Management Oversight. Hence, it can be concluded that
the Cultural aspect Many Layers Vs Flat Organization has no major influence
on the Motivating Elements as perceived by the respondents.
4. From table ST-HYP-02-05-02, it is also observed that the fourth cultural aspect
namely Controlling Vs Hands-Off Organization has no significant influence on
six of the seven Motivating elements as perceived by the respondents. However,
the cultural aspect Controlling Vs Hands-Off Organization has a significant
influence only on the Motivating Element, Process Improvement. Hence, it can be
concluded that the Cultural aspect Controlling Vs Hands-Off Organization has
no major influence on the Motivating Elements as perceived by the respondents.
5. From table ST-HYP-02-05-03, it is observed that the fifth cultural aspect namely
Static Vs Dynamic Organization has no significant influence on all the seven
that the Cultural aspect Static Vs Dynamic Organization has no significant
influence on all the Motivating Elements as perceived by the respondents.
6. From table ST-HYP-02-05-03, it is also observed that the sixth cultural aspect
namely Complacent Vs Energetic Organization has no significant influence on
all the seven Motivating elements as perceived by the respondents. Hence, it can
be concluded that the Cultural aspect Complacent Vs Energetic Organization
209
has no significant influence on all the Motivating Elements as perceived by the

respondents.
7. From table ST-HYP-02-05-04, it is observed that the seventh cultural aspect
namely Closed Minded Vs Open Minded Organization has no significant
influence on all the seven Motivating elements as perceived by the respondents.
Hence, it can be concluded that the Cultural aspect Closed Minded Vs Open
Minded Organization has no significant influence on all the Motivating Elements
as perceived by the respondents.
8. From table ST-HYP-02-05-04, it is also observed that the eighth cultural aspect
namely Political Vs Non-Political Organization has no significant influence on
four of the seven Motivating elements as perceived by the respondents. However,
the cultural aspect Political Vs Non-Political Organization has a significant
influence three of seven Motivating Elements namely Productivity Improvement,
Process Improvement and Others. Hence, it can be concluded that the Cultural
aspect Political Vs Non-Political Organization has some influence on the
Motivating Elements as perceived by the respondents.
9. From table ST-HYP-02-05-05, it is observed that the ninth cultural aspect namely
Jobs are Routine Vs Jobs are Exciting has no significant influence on all seven
that the Cultural aspect Jobs are Routine Vs Jobs are Exciting has no significant
influence on all the Motivating Elements as perceived by the respondents.
10. From table ST-HYP-02-05-05, it is also observed that the tenth cultural aspect
namely Stable Staff Vs High Turnover Organization has no significant
influence on six of the seven Motivating elements as perceived by the
respondents. However, the cultural aspect Stable Staff Vs High Turnover
Organization has a significant influence only on the Motivating Element,
Productivity Improvement. Hence, it can be concluded that the Cultural aspect
Stable Staff Vs High Turnover Organization has no major influence on the
Motivating Elements as perceived by the respondents.
210
Therefore, it can be concluded that the Cultural aspects of an organization has

no major influence on Motivating elements as perceived by the respondents.
Analysis H2.6:
2. Dependent Variable - Group C Question 3: Adequate funding for
technical development was supplied.
depicted in figures GRP-A-06-01 to GRP-A-06-10 and GRP-C-03.
Table ST-HYP-02-06: Organization Culture Vs Adequate Funding
From the above table, it is observed that seven out of the ten cultural aspects of an
organization have no significant influence on adequate funding provided by management
for Process Automation. However, three of cultural aspects namely Risk Takers Vs
Conservative, Many Layered Vs Flat Organization and Closed Minded Vs Open
Minded have significant influence on the adequate funding provided by management for
211
Process Automation. Hence, it can be concluded that the Cultural aspects of an

organization has little influence on the Adequate Funding provided by management
for Process Automation initiative.
Analysis H2.7:
2. Dependent Variable - Group C Question 4: How many process-users are
(or will be) involved in the automated process?
depicted in figures GRP-A-06-01 and GRP-A-06-10 and GRP-C-04.
Table ST-HYP-02-07: Organization Culture Vs Process Users Involvement
From the above table, it is observed that five out of the ten cultural aspects of an
organization have no significant influence on Process Users Involvement in Process
Automation. However, five of cultural aspects namely Risk Takers Vs Conservative,
Many Layered Vs Flat Organization, Political Vs Non-political Organization, Jobs
are routine Vs Jobs are exciting and Stable staff Vs High turnover Organization have
significant influence on Process Users Involvement in Process Automation. Hence, it can
212
be concluded that the Cultural aspects of an organization has some influence on

Process Users Involvement in Process Automation initiative.
Hypothesis II: Summary and Conclusion
independent variable Business Product Characteristics that significantly influence few
factors of the dependent variable Application Focus. Therefore, the hypothesis is
neither accepted nor rejected. Hence, it can be concluded that while Business Product
Characteristics has a relation to Application Focus, it does not have a significant
influence on Application Focus.
Hypothesis III: Business/Product Characteristics has no significant influence on

Process characteristics
Product Characteristics) and 11 questions from Group B (Process Characteristics) are
analyzed. However, since all results did not yield any correlation, only relevant results
are presented here.
Analysis H3.1:
2. Dependent Variable - Group D Question 1: A documented process
improvement plan is in place.
depicted in figures GRP-A-06-01 to GRP-A-06-10 and GRP-D-01.
213
Table ST-HYP-03-01: Organization culture Vs Documented Process Improvement in place
From the above table, it is observed that all of the ten cultural aspects of an
organization have relation to the organization having a documented process improvement
in place. Hence, it can be concluded that the Cultural aspects of an organization have
no relation whatsoever to the organization having a documented process
improvement in place.
Analysis H3.2:
2. Dependent Variable - Group D Question 2: Projects routine activities
Test Results: The two variables namely Organization Culture and Projects
Routine Activities have multiple factors and hence a two-dimensional analysis is
conducted. Below tables are the result of Chi-Square Test conducted on data
depicted in figures GRP-A-06-01 to GRP-A-06-10 and GRP-D-02-01 to GRP-D02-06.
214
Table ST-HYP-03-02-01: Organization culture Vs Projects routinely collect metrics on

project management data
organization have no relation to Projects routinely collect metrics on project management
data. Hence, it can be concluded that the Cultural aspects of an organization have no
relation whatsoever to Projects routinely collect metrics on project management
data.
Table ST-HYP-03-02-02: Organization culture Vs Projects routinely use metrics to support

process improvement
215
organization have no relation to Projects routinely use metrics to support process
improvement. Hence, it can be concluded that the Cultural aspects of an organization
have no relation whatsoever to Projects routinely use metrics to support process
improvement.
Table ST-HYP-03-02-03: Organization culture Vs Projects routinely use documented

processes to perform their tasks
From the above table, it is observed that six out of ten cultural aspects of an
organization have no significant influence on whether Projects routinely use documented
processes to perform their tasks. However, four out of ten cultural aspects of an
organization namely Many layers Vs Flat organization, Static environment Vs
Dynamic environment, Complacent Vs Energetic and Closed minded V Open
minded have significant influence on whether Projects routinely use documented
processes to perform their tasks. Hence, it can be concluded that the Cultural aspects of
an organization has some amount of influence on whether Projects routinely use
documented processes to perform their tasks.
216
Table ST-HYP-03-02-04: Organization culture Vs Projects routinely meet external

schedules
organization have no relation to Projects routinely meet external schedules. Hence, it can
be concluded that the Cultural aspects of an organization no relation whatsoever to
Projects routinely meet external schedules.
Table ST-HYP-03-02-05: Organization culture Vs Projects routinely meet cost estimates
217
From the above table, it is observed seven out of ten cultural aspects of an
organization have no significant influence on whether Projects routinely meet cost
estimates. However, three out of ten cultural aspects of an organization namely Risk
taker Vs Conservative, Many layered Vs Flat organization and Stable staff Vs High
turnover have significant influence on whether Projects routinely meet cost estimates.
Hence, it can be concluded that the Cultural aspects of an organization has some
influence on whether Projects routinely meet cost estimates.
Table ST-HYP-03-02-06: Organization culture Vs Projects routinely provide appropriate

training on tools and methods
From the above table, it is observed six out of ten cultural aspects of an
organization have no significant influence on whether Projects routinely provide
appropriate training on tools and methods. However, four out of ten cultural aspects of an
organization namely Risk takers Vs Conservative, Many layered Vs Conservative
organization, Complacent Vs Energetic and Closed minded Vs Open minded have
significant influence on whether Projects routinely provide appropriate training on tools
and methods. Hence, it can be concluded that the Cultural aspects of an organization
has some influence on whether Projects routinely provide appropriate training on
tools and methods.
218
Analysis H3.3:
2. Dependent Variable - Group D Question 3: Do you have any
documented processes in manual operation?
Table ST-HYP-03-03: Organization culture Vs Organizations have any documented

processes in manual operations
From the above table, it is observed nine out of ten cultural aspects of an
organization has no significant influence on whether Organizations have any documented
processes in manual operations. However, only one of ten cultural aspects of an
organization namely Controlling Vs Hands-off has a significant influence on whether
Organizations have any documented processes in manual operations. Hence, it can be
concluded that the Cultural aspects of an organization has no major influence on
whether Organizations have any documented processes in manual operations.
219
220
Analysis H3.4:
2. Dependent Variable - Group D Question 5: Was a recognized process
definition notation used to define the process
Table ST-HYP-03-04: Organization culture Vs Organizations used a recognized process

definition notation to define process
organization have no relation to Organizations used a recognized process definition
notation to define process. Hence, it can be concluded that the Cultural aspects of an
organization have no relation whatsoever to Organizations used a recognized
process definition notation to define process.
221
Analysis H3.5:
2. Dependent Variable - Group D Question 7: The process design is clearly
and completely documented
Table ST-HYP-03-05: Organization culture Vs The process design is clearly and completely
documented
organization have no relation to The process design is clearly and completely
documented. Hence, it can be concluded that the Cultural aspects of an organization
have no relation whatsoever to The process design is clearly and completely
documented.
222
Analysis H3.6:
2. Dependent Variable - Group D Question 8: Functional requirements
were used to define tools embedded in the process
Table ST-HYP-03-06: Organization culture Vs Functional requirements were used to define

tools embedded in the process
From the above table, it is observed that seven out of ten cultural aspects of an
organization have no significant influence on whether Functional requirements were used
to define tools embedded in the process. However, three out of ten cultural aspects of an
organization namely Complacent Vs Energetic, Closed minded Vs Open minded and
Political Vs Non-political have significant influence on whether Functional
requirements were used to define tools embedded in the process. Hence, it can be
223
concluded that the Cultural aspects of an organization has some influence on whether
Functional requirements were used to define tools embedded in the process.
Analysis H3.7:
2. Dependent Variable - Group D Question 9: Metrics requirements are
Table ST-HYP-03-07: Organization culture Vs Metrics requirements are specified for the
process
From the above table, it is observed that four out of ten cultural aspects of an
organization have no significant influence on whether Metrics requirements are specified
for the process. However, six out of ten cultural aspects of an organization namely
Formal Vs Informal, Many layered Vs Flat organization, Static environment Vs
Dynamic environment, Complacent Vs Energetic, Closed minded Vs Open minded
and Jobs are routine Vs Jobs are exciting have significant influence on whether Metrics
224
requirements are specified for the process. Hence, it can be concluded that the Cultural
aspects of an organization has good influence on whether Metrics requirements are
specified for the process.
Analysis H3.8:
2. Dependent Variable - Group D Question 11: Process definition (for
automation) was more challenging than first thought.
Table ST-HYP-03-08: Organization culture Vs Process definition was more challenging

than first thought
From the above table, it is observed that three out of ten cultural aspects of an
organization have no significant influence on whether Process definition was more
challenging than first thought. However, three out of ten cultural aspects of an
organization namely Controlling Vs Hands-off, Static environment Vs Dynamic
environment and Stable staff Vs High turnover have significant influence on whether
225
Process definition was more challenging than first thought. Hence, it can be concluded
that the Cultural aspects of an organization has little influence on whether Process
definition was more challenging than first thought.
Hypothesis III: Summary and Conclusion
independent variable Business/Product Characteristics that significantly influence few
factors of the dependent variable Process Characteristics. Therefore, the hypothesis is
neither accepted nor rejected. Hence, it can be concluded that while Business/Product
Characteristics has a relation to Process Characteristics, it does not have a significant
influence on Process Characteristics.
Hypothesis IV: Implementation team characteristics has no significant influence on

Application focus
To substantiate this hypothesis with data, 7 questions from Group B

(Implementation Team Characteristics) and 10 questions from Group C (Application
Focus) are analyzed. However, since all results did not yield any correlation, only
relevant results are presented here.
Analysis H4.1:
1. Independent Variable - Group B Question 1: How many people are
depicted in figures GRP-B-01 and GRP-C-01.
226
Table ST-HYP-04-01: Development Team Size Vs Areas of Automation
From the above table, it is observed that Process Automation development team
size has no relation with 11 Process areas that may be addressed by Process Automation.
Also, Process Automation development team size has no significant influence on 13 other
Process areas that may be addressed by Process Automation. Hence, it can be concluded
that the Process Automation development team size has no influence on most of
227
Process Areas that may be addressed by Process Automation as perceived by the

respondents.
Analysis H4.2:
2. Dependent Variable - Group C Question 4: How many process-users are
(or will be) involved in the automated process?
Table ST-HYP-04-02: Development Team Size Vs Process Users Involvement
From the above table, it can be concluded that the Process Automation
development team size has no significant influence on Process users involvement.
Analysis H4.3:
completion?
228
Table ST-HYP-04-03: Development Team Size Vs Elapsed days from Initiation to

Completion
development team size has a significant influence on Elapsed days from Initiation to
Completion of Process Automation.
Analysis H4.4:
2. Dependent Variable - Group C Question 6: How many processes are
currently being automated?
Table ST-HYP-04-04: Development Team Size Vs Processes currently being automated
development team size has a significant influence on the number of processes being
automated
currently.
229
Analysis H4.5:
2. Dependent Variable - Group C Question 7: How many automated
processes are in operation?
Table ST-HYP-04-05: Development Team Size Vs Automated processes in operation
development team size has no significant influence on Number of automated
processes in operation.
Analysis H4.6:
2. Dependent Variable - Group C Question 8: Is the automated process
currently being used on a day-to-day basis?
230
Table ST-HYP-04-06: Development Team Size Vs Automated processes in daily use
development team size has no significant influence on automated processes in dayto-day use.
Analysis H4.7:
times per month is (or will) the automated process be executed?
Table ST-HYP-04-07: Development Team Size Vs Frequency of Tool execution
development team size has no relation to Frequency of automated tool execution.
231
Analysis H4.8:
2. Dependent Variable - Group C Question 10: To the best of my
knowledge, our current automation activities include:
With respondents answering Yes to One implementation successfully
deployed, the subsequent queries answered are considered.
depicted in figures GRP-B-05 and GRP-C-10-01 to GRP-C-10-05.
Table ST-HYP-04-08: Development Team Size Vs Stages of Deployment
From the above table, it is observed that Process Automation development team
size have no significant influence on three out of four stages of deployment. However,
Process Automation development team size have significant influence on only one out of
the four stages of deployment namely Planning additional processes. Hence, it can be
concluded that Process Automation development team size has no major influence on
various stages of deployment.
Hypothesis IV: Summary and Conclusion
independent variable Implementation team characteristics that significantly influence
232
few factors of the dependent variable Application focus. Therefore, the hypothesis is
neither accepted nor rejected. Hence, it can be concluded that while Implementation
team characteristics has a relation to Application focus, it does not have a significant
influence on Application focus.
Hypothesis V: Application focus has no significant influence on Process

characteristics
To substantiate this hypothesis with data, 10 questions from Group C (Application

Focus) and 11 questions from Group D (Process Characteristics) are analyzed. However,
since all results did not yield any correlation, only relevant results are presented here.
Analysis H5.1:
1. Independent Variable - Group C Question 1: What general areas does
the automated processes address?
2. Dependent Variable - Group D Question 2: Project Teams routinely
conduct certain activities such as:

Collect metrics on project management data

Use metrics to support process improvement,
Use documented processes to perform their tasks
Meet external schedules
Meet cost estimates
Provide appropriate training on tools and methods.
depicted in figures GRP-C-01 and GRP-D-02-01 to GRP-D-02-06.
233
Table ST-HYP-05-01-01: Areas of Automation Vs Routine Activities I
234
Table ST-HYP-05-01-02: Areas of Automation Vs Routine Activities II
235
Table ST-HYP-05-01-03: Areas of Automation Vs Routine Activities III
1. From table ST-HYP-05-01-01, it is observed that all of the twenty four Process
areas addressed by process automation has no relation to Projects routinely collect
236
metrics on project management data. Hence, it can be concluded that Process

Areas addressed Process Automation has no relation with Projects routine
activity namely Collect metrics on project management data as perceived by the
respondents.
areas addressed by process automation has no relation to Projects routinely collect
metrics on project management data. Hence, it can be concluded that Process
Areas addressed by Process Automation has no relation with Projects routine
activity namely Use metrics to support process improvement as perceived by
the respondents.
3. From table ST-HYP-05-01-02, it is observed that 11 out of twenty four Process
areas addressed by Process Automation have no relation with Projects routine
activity namely Use documented processes to perform their tasks. Also, 13 out
of the twenty four Process areas addressed by Process Automation have no
significant influence on Projects routine activity namely Use documented
processes to perform their tasks. Hence, it can be concluded that most of the
Process areas addressed by Process Automation has no major influence on
Projects routine activity namely Use documented processes to perform their
tasks.
areas addressed by process automation have no relation to Projects routine
activity namely Meets external schedules as perceived by the respondents.
Hence, it can be concluded that Process Areas addressed by Process Automation
has no relation with Projects routine activity namely Meets external schedules
5. From table ST-HYP-05-01-03, it is observed that 11 out of twenty four Process
areas addressed by Process Automation have no relation with Projects routine
activity namely Meet cost estimates. Also, 12 out of the twenty four Process
areas addressed by Process Automation have no significant influence on Projects
routine activity namely Meet cost estimates. However, one process area namely
Software Development addressed by Process Automation has a significant
237
influence on Projects routine activity Meet cost estimates. Hence, it can be

concluded that most of the Process areas addressed by Process Automation has no
major influence on Projects routine activity namely Meet cost estimates.
6. From table ST-HYP-05-01-03, it is observed that 11 out of twenty Process areas
addressed by Process Automation have no relation with Projects routine activity
namely Provide appropriate training on tools and methods. Also, 13 Process
areas addressed by Process Automation have no significant influence on Projects
routine activity namely Provide appropriate training on tools and methods.
Hence, it can be concluded that most of the Process areas addressed by Process
Automation has no influence on Projects routine activity namely Provide
appropriate training on tools and methods.
Therefore, it can be concluded that all the Process areas addressed by Process
Automation has no major influence on Project teams routine activities.
Analysis H5.2:
2. Dependent Variable - Group D Question 3: Do you have any
documented processes in manual operation?
depicted in figures GRP-C-01 and GRP-D-03.
238
Table ST-HYP-05-02: Areas of Automation Vs Documented Processes in manual operation
239
From the above table, it is observed that 11 out of twenty four Process areas
addressed by Process Automation have no relation with Documented Processes in
manual operation. Also, 12 Process areas addressed by Process Automation have no
significant influence on Documented Processes in manual operation. However, one
process area addressed by Process automation namely Six Sigma Tools addressed by
Process Automation has a significant influence on Documented Processes in manual
operation. Hence, it can be concluded that most of the Process areas addressed by
Process Automation has no major influence on Documented Processes in manual
operation.
Analysis H5.3:
2. Dependent Variable - Group D Question 10: The target process was

No prior manual process

Manual process not documented
Manual process operated in not a stable manner
240
Table ST-HYP-05-03: Areas of Automation Vs Target Process
241
1. From the above table, it is observed that 11 out of twenty four Process areas
addressed by Process Automation have no relation to the target process choice No
prior manual process. Also, 13 Process areas addressed by Process Automation have
no significant influence on the target process choice No prior manual process.
Hence, it can be concluded that the Process areas addressed by Process Automation
has no major influence on the target process choice No prior manual process.
2. From the above table, it is also observed that all 24 Process areas addressed by
Process Automation have no relation with the target process Manual process not
documented. Hence, it can be concluded that the Process areas addressed by Process
Automation has no relation whatsoever to the target process choice Manual process
not documented.
3. Moreover, from the above table, it is observed that 11 Process areas addressed by
Process Automation have no relation with the target process Manual process
operated in not a stable manner and 13 Process areas addressed by Process
Automation have no significant influence on the target process Manual process
operated in not a stable manner. Hence, it can be concluded that the Process areas
addressed by Process Automation has no relation whatsoever to the target process
choice Manual process operated in not a stable manner.
Therefore, it can be concluded that all the Process areas addressed by Process
Automation has no major influence on the target process in practice.
Analysis H5.4:
automation) was more challenging than first thought?
242
Table ST-HYP-05-04: Areas of Automation Vs Process definition was more challenging
243
From the above table, it is observed that 11 out of twenty four Process areas
addressed by Process Automation have no relation with Process definition was more
challenging. Also, 13 Process areas addressed by Process Automation have no
significant influence on Process definition was more challenging. Hence, it can be
concluded that all the Process areas addressed by Process Automation has no
influence on Process definition was more challenging.
Analysis H5.5:
1. Independent Variable - Group C Question 2: What elements motivated
the management to consider the use of a process automation?
2. Dependent Variable - Group D Question 2: Project Teams routinely
conduct certain activities such as:

Collect metrics on project management data

Use metrics to support process improvement,
Use documented processes to perform their tasks
Meet external schedules
Meet cost estimates
Provide appropriate training on tools and methods.
depicted in figures GRP-C-02-01 and GRP-D-02-01 to GRP-D-02-06.
244
Table ST-HYP-05-05-01: Motivating Elements Vs Project Teams Routine Activities I
Table ST-HYP-05-05-02: Motivating Elements Vs Project Teams Routine Activities II
245
Table ST-HYP-05-05-03: Motivating Elements Vs Project Teams Routine Activities III
1. From table ST-HYP-05-05-01, it is be observed that Motivating elements has no

relation to Projects routine activity namely Collect metrics on project
management data as perceived by the respondents.
2. From table ST-HYP-05-05-01, it is also be observed that Motivating elements has
no relation to Projects routine activity namely Use metrics to support process
improvement as perceived by the respondents.
3. From table ST-HYP-05-05-02, it is be observed that Motivating elements has no
significant influence on Projects routine activity namely Use documented
processes to perform their tasks as perceived by the respondents.
4. From table ST-HYP-05-05-02, it is also be observed that Motivating elements has
no relation to Projects routine activity namely Meet external schedules as
5. From table ST-HYP-05-05-03, it is observed that Motivating elements has no
significant influence on Projects routine activity namely Meet cost estimates as
6. From table ST-HYP-05-05-03, it is also observed that Motivating elements has no
significant influence on Projects routine activity namely Provide appropriate
training on tools and methods as perceived by the respondents.
246
To conclude, Motivating elements either has no relation or no significant

influence on Projects routine activities as perceived by the respondents.
Analysis H5.6:
2. Dependent Variable - Group D Question 4: Process areas addressed by
Process Automation
Table ST-HYP-05-06-01: Motivating Elements Vs Areas of Automation I
247
Table ST-HYP-05-06-02: Motivating Elements Vs Areas of Automation II
Table ST-HYP-05-06-03: Motivating Elements Vs Areas of Automation III
248
Table ST-HYP-05-06-04: Motivating Elements Vs Areas of Automation IV
Table ST-HYP-05-06-05: Motivating Elements Vs Areas of Automation V
249
Table ST-HYP-05-06-06: Motivating Elements Vs Areas of Automation VI
Table ST-HYP-05-06-07: Motivating Elements Vs Areas of Automation VII
250
Table ST-HYP-05-06-08: Motivating Elements Vs Areas of Automation VIII
Table ST-HYP-05-06-09: Motivating Elements Vs Areas of Automation IX
251
Table ST-HYP-05-06-10: Motivating Elements Vs Areas of Automation X

relation to Process area Project initiation/startup addressed by Process
relation with Process area Project planning addressed by Process Automation as
relation with Process area Project tracking and oversight addressed by Process
relation with Process area Project closure addressed by Process Automation as
significant influence on Process area Requirements management addressed by
Process Automation as perceived by the respondents.
6. From table ST-HYP-05-06-03, it is also observed that six out of seven motivating
elements have no significant influence on Process area Software Design
addressed by Process Automation. However, only one motivating element namely
252
Metrics, has a significant influence on Process area Software Design

addressed by Process Automation as perceived by the respondents.
7. From table ST-HYP-05-06-04, it is observed that six out of seven motivating
elements have no significant influence on Process area Software Development
Metrics has a significant influence on Process area Software Development
relation with Process area Verification/Reviews addressed by Process
relation with Process area Validation/Testing addressed by Process Automation
relation with Process area Defect/Anomaly tracking addressed by Process
relation with Process area Release management addressed by Process
relation with Process area Deployment addressed by Process Automation as
13. From table ST-HYP-05-06-07, it is observed that six out of seven motivation
elements have no significant influence on Process area Software maintenance
Metrics has a significant influence on Process area Software maintenance
14. From table ST-HYP-05-06-07, it is also observed that six out of seven Motivating
elements has no significant influence on Process area Hardware/Software
servicing addressed by Process Automation. However, only one motivating
element namely Metrics has a significant influence on Process area
253
Hardware/Software servicing addressed by Process Automation as perceived by

the respondents.
relation with Process area Change Management addressed by Process
relation with Process area Configuration Management addressed by Process
relation with Process area Document Management addressed by Process
18. From table ST-HYP-05-06-09, it is also observed that six out of seven Motivating
elements has no significant influence on Process area Document review
Process improvement has a significant influence on Process area Document
review addressed by Process Automation as perceived by the respondents.
relation with Process area Subcontractor Management addressed by Process
relation with Process area Supplier Management addressed by Process
To conclude, Motivating elements either has no relation or no significant

influence on Process areas as addressed by Process Automation as perceived by the
respondents.
Analysis H5.7:
254


Table ST-HYP-05-07: Motivating Elements Vs Target Process
1. From the above table, it is observed that all the seven motivating elements have no
significant influence on the target process choice No prior manual process. Hence,
it can be concluded that the Motivating elements has no influence on the target
process choice No prior manual process.
2. From the above table, it is also observed that all seven motivating elements have no
relation to the target process Manual process not documented. Hence, it can be
concluded that the Motivating elements has no relation whatsoever to the target
process choice Manual process not documented.
3. Moreover, from the above table, it is observed that all the seven motivating elements
have no significant influence on the target process Manual process operated in not a
255
stable manner. Hence, it can be concluded that the Motivating elements has
influence on the target process choice Manual process operated in not a stable
manner.
Therefore, it can be concluded that all the Motivating elements has no major
influence on the target process in practice.
Analysis H5.8:
depicted in figures GRP-C-02-01 and GRP-D-11.
Table ST-HYP-05-08: Motivating Elements Vs Process definition was challenging
256
From the above table, it is observed and concluded that Motivating Elements has
no significant influence on Process definition was more challenging.
Analysis H5.9:
1. Independent Variable - Group C Question 3: Adequate funding for
technical development was supplied?
2. Dependent Variable - Group D Question 4: Process areas automated by
Process Automation tool
257
Table ST-HYP-05-09: Adequate funding Vs Process areas automated
From the above table, it is observed that adequate funding has no relation to seven
out of twenty processes automated through Process Automation tool. Also, it is observed
that adequate funding has no significant influence on thirteen processes automated
through Process Automation tool. Hence, it can be concluded that Adequate funding has
258
no significant influence on the processes automated through Process Automation

tool.
Analysis H5.10:
1. Independent Variable - Group C Question 5: Approximately how many
completion?


Table ST-HYP-05-10: Elapsed days of Automation Vs Target Process
From the above table, it is observed and can be concluded that the elapsed days
for automation from initiation to completion phase have no major influence on all
the three the target processes in practice.
259
Analysis H5.11:
1. Independent Variable - Group C Question 5: Approximately how many
completion?
Table ST-HYP-05-11: Elapsed days of Automation Vs Process definition was challenging
From the above table, it is observed and can be concluded that the elapsed days
for automation from initiation to completion phase have no major influence on
Process definition was more challenging.
Analysis H5.12:
1. Independent Variable - Group C Question 8: Is the automated process
2. Dependent Variable - Group D Question 4: In what areas are these
processes automated?
260
Table ST-HYP-05-12: Process Automation used on daily basis Vs Automated Processes
From the above table, it is observed Process Automation used on day-to-day

basis has no relation to nine out of twenty process areas automated by the Process
Automation tool. Also, it is observed that Process Automation used on day-to-day basis
has no significant influence on eight out of twenty process areas automated by the
261
Process Automation tool. However, Process Automation used on day-to-day basis has
significant influence on three process areas automated by the Process Automation tool
namely Requirements Management, Release Management and Deployment.
Hence, it can be concluded that Process Automation used on day-to-day basis little
influence on the Process areas automated by the Process Automation tool.
Analysis H5.13:
1. Independent Variable - Group C Question 10.06: One implementation
successfully deployed and various stages of deployment are:

Is automation of any additional processes planned

Is development of any additional automated processes underway
Are additional automated processes being implemented with endusers
Are additional automated processes successfully deployed?


Table ST-HYP-05-13: Stages of progress in Automation Vs The Target Process
262
1. From the above table, it is observed that all the four stages of progress in process
automation have no significant influence on the target process choice No prior
manual process. Hence, it can be concluded that the stages of progress in process
automation have no influence on the target process choice No prior manual process.
2. From the above table, it is also observed that all four motivating elements have no
relation to the target process Manual process not documented. Hence, it can be
concluded that the stages of progress in process automation have no relation
whatsoever to the target process choice Manual process not documented.
3. Moreover, from the above table, it is observed that all the four stages of progress in
process automation have no significant influence on the target process Manual
process operated in not a stable manner. Hence, it can be concluded that the stages
of progress in process automation have influence on the target process choice
Manual process operated in not a stable manner.
Therefore, it can be concluded that all the Stages of progress in process

automation have no influence on the target process in practice.
Analysis H5.14:
1. Independent Variable - Group C Question 10.06: One implementation
successfully deployed and various stages of deployment are:

Is automation of any additional processes planned

Is development of any additional automated processes underway
Are additional automated processes being implemented with endusers
Are additional automated processes successfully deployed?

263
depicted in figures GRP-C-10-06 and GRP-D-11.
Table ST-HYP-05-14: Stages of progress in Automation Vs Process definition was

challenging
From the above table, it is observed that two out of four stages of progress in
Process Automation have no significant influence on Process definition was
challenging. However, two stages of progress in Process Automation namely
Automation of additional processes planned and Additional automated processes
being implemented with end-users have a significant influence on Process definition
was challenging. Hence, it can be concluded that Stages of Progress in Process
Automation has partial significant influence on Process definition was
challenging.
Hypothesis V: Summary and Conclusion
independent variable Application focus that significantly influence few factors of the
dependent variable Process Characteristics. Therefore, the hypothesis is neither
accepted nor rejected. Hence, it can be concluded that while Application focus has a
relation to Process Characteristics, it does not have a significant influence on Process
Characteristics.
264
Hypothesis VI: Application focus has no significant influence on Development

technology

Focus) and 6 questions from Group E (Development Technology) are analyzed.
However, since all results did not yield any correlation, only relevant results are
presented here.
Analysis H6.01:
2. Independent Variable - Group E Question 2: The major strengths of the
process automation tool I used are:

The process development environment

Debugging capabilities
Ability to integrate application tools
Ability to design effective end-user interfaces
Ability to collect metrics
Performance (speed of response to end-users),
Cross-platform compatibilities
Customer support
Availability of training in the tool
Documentation
Ease of use of the development environment,
Cost-effectiveness
Test applied: Kruskal-Wallis
data depicted in figures GRP-C-03 and GRP-E-02-01 to GRP-E-02-12.
265
Adequate funding for technical development Vs Strengths of Process Automation Tool

Strengths of
Process
Automation
The process
development
environment
Debugging
capabilities
Ability to integrate
application tools
Ability to design
effective end-user
interfaces
Ability to collect
metrics
Performance
(speed of
response to endusers),
Cross-platform
compatibilities
Customer support
Availability of
training in the tool
Documentation
Ease of use of the
development
environment,
Cost-effectiveness
Adequate
funding for
development
Yes
No
Total
Count
58
19
77
Mean Rank
41.97
29.95
Count
51
13
Mean Rank
32.19
33.73
Count
58
19
Mean Rank
40.94
33.08
Count
58
19
Mean Rank
38.79
39.63
Count
58
19
Mean Rank
42.79
27.42
Count
58
19
Mean Rank
36.47
46.71
Count
58
19
Mean Rank
36.86
45.53
Count
58
19
Mean Rank
38.72
39.84
Count
58
19
Mean Rank
36.22
47.47
Count
58
19
Mean Rank
35.23
50.50
Count
58
19
Mean Rank
34.91
51.50
Count
58
19
Mean Rank
37.30
44.18
Chi-Square
DF
P-Value
Result
6.080
0.014
Significant
0.084
0.772
NS
2.223
0.136
NS
0.024
0.878
NS
8.820
0.003
Significant
3.420
0.064
NS
2.383
0.123
NS
0.043
0.835
NS
4.042
0.044
Significant
7.639
0.006
Significant
8.583
0.003
Significant
1.448
0.229
NS
64
77
77
77
77
77
77
77
77
77
77
Table ST-HYP-06-01: Adequate funding for technical development Vs Strengths of Process

Automation Tool
From the above table, it is observed that Adequate funding provided for
technical development of Process Automation tool has no significant influence on
significant influence on seven out of the twelve strengths of Process Automation.
However, Adequate funding provided for technical development of Process Automation
tool has significant influence on five strengths of Process Automation tool namely The
process development environment, Ability to collect metrics, Availability of training
in the tool, Documentation and Ease of use of the development environment.
Hence, it can be concluded that Adequate funding provided for technical development
266
of Process Automation tool has some influence on the Strengths of Process

Automation tool.
Analysis H6.02:
2. Independent Variable - Group E Question 3-6: Other qualities of Process
Automation tool:

Defects in the automation tool affected development

Difficult to recover from system crashes
Tool supports a good range of hardware platforms
data depicted in figures GRP-C-03 and GRP-E-03 to GRP-E-06.
Adequate funding for technical development Vs Other qualities of Process Automation
Other qualities of Adequate

Process
funding for
Automation
development
Defects in the
Count
automation tool
affected
Mean Rank
development
System crashes
affected the
development
effort.
Difficult to
recover from
system crashes
Tool supports a
good range of
hardware
platforms
Yes
No
Total
58
19
77
38.95
39.16
Count
58
19
Mean Rank
40.03
35.84
Count
58
19
Mean Rank
39.80
36.55
Count
56
19
Mean Rank
36.43
42.63
Chi-Square
DF
P-Value
Result
0.001
0.971
NS
0.553
0.457
NS
0.337
0.561
NS
1.272
0.259
NS
77
77
75
Table ST-HYP-06-02: Adequate funding for technical development Vs Other qualities of

Process Automation Tool
technical development of Process Automation tool has no significant influence on any of
the four qualities of Process Automation tool and hence, it can be concluded that
267
Adequate funding provided for technical development of Process Automation tool

has no significant influence on other qualities of Process Automation tool.
Analysis H6.03:


Customer support
Documentation
Cost-effectiveness
data depicted in figures GRP-C-08 and GRP-E-02-01 to GRP-E-02-12.
268
Automated process used on day-to-day basis Vs Strengths of Process Automation Tool

Strengths of
Process
Automation
The process
development
environment
Debugging
capabilities
application tools
Ability to design
effective end-user
interfaces
Ability to collect
metrics
Performance
(speed of
response to endusers),
Cross-platform
compatibilities
Customer support
Availability of
Documentation
Ease of use of the
development
environment,
Cost-effectiveness
Day-to-Day use
of Automated
process
Yes
No
Count
77
Mean Rank
39.34
65.50
Count
64
Mean Rank
33.42
36.00
Count
77
Mean Rank
39.84
46.00
Count
77
Mean Rank
39.77
49.00
Count
77
Mean Rank
39.48
60.00
Count
77
Mean Rank
39.94
42.50
Count
77
Mean Rank
40.16
34.00
Count
77
Mean Rank
39.82
47.00
Count
77
Mean Rank
40.10
36.00
Count
77
Mean Rank
39.99
40.50
Count
77
Mean Rank
40.29
29.00
Count
77
Mean Rank
40.26
30.00
Total
Chi-Square
DF
P-Value
Result
79
3.781
0.052
NS
66
0.041
0.840
NS
79
0.173
0.677
NS
79
0.368
0.544
NS
79
2.057
0.152
NS
79
0.028
0.868
NS
79
0.156
0.693
NS
79
0.228
0.633
NS
79
0.069
0.793
NS
79
0.001
0.973
NS
79
0.516
0.473
NS
79
0.417
0.519
NS
Table ST-HYP-06-03: Automated process used on daily basis Vs Strengths of Process

Automation
From the above table, it is observed that Automated process used on day-to-day
basis has no significant influence on any of the twelve strengths of Process Automation
tool and hence, it can be concluded that Automated process used on day-to-day basis
has no significant influence on the Strengths of Process Automation tool.
269
Analysis H6.04:
Automation tool:


data depicted in figures GRP-C-08 and GRP-E-03 to GRP-E-06.
Automated process used on day-to-day basis Vs Other qualities of Process Automation
Day-to-Day use
of Automated
process
Defects in the
automation tool
affected
development
System crashes
affected the
development
effort
Difficult to
recover from
system crashes
Automation tool
supports good
range of
hardware
platforms
Yes
No
Count
77
Mean Rank
40.90
5.50
Count
77
Mean Rank
40.83
8.00
Count
77
Mean Rank
40.49
21.00
Count
75
Mean Rank
39.29
28.00
Total
Chi-Square
DF
P-Value
Result
79
5.002
0.025
Significant
79
4.366
0.037
Significant
79
1.561
0.212
NS
77
0.552
0.457
NS
Table ST-HYP-06-04: Automated process used on daily day basis Vs Other qualities of
Overall, it is observed that Automated process used on day-to-day basis has no

significant influence on two of the four qualities of Process Automation tool. However,
Automated process used on day-to-day basis has significant influence on two qualities
of Process Automation tool namely Defects in the automation tool affected
development and System crashes affected the development effort. Hence, it can be
270
concluded that Automated process used on day-to-day basis partial significant

influence on other qualities of Process Automation tool.
Hypothesis VI: Summary and Conclusion
independent variable Application focus that significantly influence few factors of the
dependent variable Development Technology. Therefore, the hypothesis is neither
relation to Development Technology, it does not have a significant influence on
Development Technology.
Hypothesis VII: Application focus has no significant influence on Transition and

adoption

Focus) and 24 questions from Group F (Transition and Adoption) are analyzed. However,
since all results did not yield any correlation, only relevant results are presented here.
Analysis H7.01:
2. Independent Variable - Group F Question 3: Training was provided to
support:
Implementers of the process-centered environment
End-users of the automated process
data depicted in figures GRP-C-03 and GRP-F-03-01 to GRP-F-03-02.
271
Adequate funding for technical development Vs Training provided

Adequate
funding for
development
Training was provided

to support
Implementers of the
process-centered
environment
End-users of the
automated process
Yes
No
Count
58
19
Mean Rank
41.27
32.08
Count
58
19
Mean Rank
35.65
49.24
Total
Chi-Square
DF
P-Value
Result
77
2.775
0.096
NS
77
6.036
0.014
Significant
Table ST-HYP-07-01: Adequate funding for technical development Vs Training provided to

support Process Automation Tool
technical development of Process Automation tool has no significant influence on one
out of the two kinds of training provided to support the Process Automation tool.
However, Adequate funding provided for technical development of Process Automation
tool has significant influence on one kind of training provided to support the Process
Automation tool namely End-users of the automated process. Hence, it can be
concluded that Adequate funding provided for technical development of Process
Automation tool has some significant influence on the kinds of training provided to
support the Process Automation tool.
Analysis H7.02:
2. Independent Variable - Group F Question 4-12: Automated Process
design/development approach:

Process design developed in conjunction with end-users

Process design reviewed with end-users
End-user screens evaluated by the end-users
Process simulations performed with the end-users
Tool improves end-user effectiveness
End-users had difficulty in accepting
End-users feel ownership
End-users make suggestions to improve
272
data depicted in figures GRP-C-03 and GRP-F-04 to GRP-F-12.
Adequate funding for technical development Vs Automated Process design/development approach
Adequate
funding for
development
Process design
developed in conjunction
with end-users
Process design reviewed
with end-users
Yes
No
Count
55
19
Mean Rank
38.33
35.11
Count
57
19
Mean Rank
36.83
43.50
End-user screens
evaluated by the endusers
Count
53
19
Mean Rank
33.86
43.87
Process simulations
performed with the endusers
Count
55
19
Mean Rank
36.58
40.16
Tool improves end-user

effectiveness
Count
58
19
Mean Rank
37.96
42.18
End-users had difficulty

in accepting
Count
58
19
Mean Rank
39.72
36.82
Count
58
19
Mean Rank
40.64
34.00
Count
58
19
Mean Rank
39.22
38.32
Count
58
19
Mean Rank
38.54
40.39
End-users make
suggestions to improve
Metrics used to improve
automated process
Total
Chi-Square
DF
P-Value
Result
74
0.414
0.520
NS
76
1.751
0.186
NS
72
3.521
0.061
NS
74
0.472
0.492
NS
77
0.626
0.429
NS
77
0.269
0.604
NS
77
1.507
0.220
NS
77
0.028
0.867
NS
77
0.116
0.734
NS
Table ST-HYP-07-02: Adequate funding for technical development Vs Automated Process

the nine Automated Process design/development approaches and hence it can be
concluded that Adequate funding provided for technical development of Process
Automation
tool
has
no
significant
influence
on
Automated
Process
design/development approach.
273
Analysis H7.03:
2. Independent Variable - Group F Question 13: There was resistance to
process automation for the following reasons:


Fear of job loss
Fear of change
End-users feel that they were not consulted sufficiently in process
definition
Adequate funding for technical development Vs Resistance to process automation
Resistance to process
automation
Automation was viewed
as externally imposed
Fear of job loss
Fear of change
The perception that
process automation is too
controlling
End-users feel that they
were not consulted
sufficiently in process
definition
Fear that metrics would
be used in job
evaluations
Adequate
funding for
development
Yes
No
Count
58
19
Mean Rank
40.43
34.63
Count
58
19
Mean Rank
39.42
37.71
Count
58
19
Mean Rank
36.98
45.16
Count
58
19
Mean Rank
37.06
44.92
Count
58
19
Mean Rank
38.95
39.16
Count
58
19
Mean Rank
37.93
42.26
Total
Chi-Square
DF
P-Value
Result
77
1.044
0.307
NS
77
0.089
0.766
NS
77
2.132
0.144
NS
77
1.989
0.158
NS
77
0.001
0.970
NS
77
0.599
0.439
NS
Table ST-HYP-07-03: Adequate funding for technical development Vs Resistance to

Process Automation
the six reasons for resistance to Process Automation and hence it can be concluded that
274

has no significant influence on the reasons for resistance to Process Automation.
Analysis H7.04:
2. Independent Variable - Group F Question 14-20: Management Support
activities:

Senior management is supportive

First-line management is supportive
Development plan agreed to by management
Design reviewed with management
Received adequate funding for transitioning
Initiative has champion with designated authority
Adequate funding for technical development Vs Management Support
Management Support
activities
Adequate
funding for
development
Yes
No
Senior management is
supportive
Count
58
19
Mean Rank
35.31
50.26
First-line management is
supportive
Count
57
18
Mean Rank
35.88
44.72
An automation business
plan was written
Count
57
18
Mean Rank
33.67
51.72
Development plan agreed

to by management
Count
57
18
Mean Rank
36.47
42.83
Design reviewed with

management
Count
57
18
Mean Rank
35.82
44.89
Received adequate
funding for transitioning
Count
58
19
Mean Rank
32.61
58.50
Initiative has champion

with designated authority
Count
57
18
Mean Rank
35.28
46.61
Total
Chi-Square
DF
P-Value
Result
77
8.325
0.004
Significant
75
2.967
0.085
NS
75
12.477
0.000
Significant
75
1.472
0.225
NS
75
2.831
0.092
NS
77
25.611
0.000
Significant
75
4.687
0.030
Significant
Table ST-HYP-07-04: Adequate funding for technical development Vs Management

Support to Process Automation
275
technical development of Process Automation tool has no significant influence on three
out of seven activities of Management support. However, Adequate funding provided
for technical development of Process Automation tool has significant influence on four
activities of Management support namely Senior management is supportive, An
automation business plan was written, Received adequate funding for transitioning
and Initiative has champion with designated authority. Hence it can be concluded that
has a significant influence on the Management support to Process Automation
initiative.
Analysis H7.05:
support:
Automated process currently used on day-to-day basis Vs Training provided
Training was provided

to support
Implementers of the
process-centered
environment
End-users of the
automated process
Automated
process used on
day-to-day basis
Yes
No
Count
77
Mean Rank
39.74
50.00
Count
77
Mean Rank
40.77
10.50
Total
Chi-Square
DF
P-Value
Result
79
0.452
0.502
NS
79
3.908
0.048
Significant
Table ST-HYP-07-05: Automated process used on daily basis Vs Training provided to

support Process Automation Tool
276
basis has no significant influence on one out of the two kinds of training provided to
support the Process Automation tool. However, Automated process used on day-to-day
basis has significant influence on one kind of training provided to support the Process
Automation tool namely End-users of the automated process. Hence it can be
concluded that Automated process used on day-to-day basis has some significant
influence on the kinds of training provided to support the Process Automation tool.
Analysis H7.06:


277
Automated process currently used on day-to-day basis Vs Aumated Process design/development approach
Process design
developed in conjunction
with end-users
with end-users
End-user screens
Automated
process used on
day-to-day basis
Yes
No
Count
74
Mean Rank
38.00
57.00
Count
76
Mean Rank
39.95
22.50
Count
72
Mean Rank
37.49
38.00
Process simulations
Count
74
Mean Rank
38.34
44.50

effectiveness
Count
77
Mean Rank
39.78
48.50
End-users had difficulty

in accepting
Count
77
Mean Rank
40.12
35.50

End-users make
automated process
Count
77
Mean Rank
39.81
47.50
Count
77
Mean Rank
40.60
17.00
Count
77
Mean Rank
40.62
16.00
Total
Chi-Square
DF
P-Value
Result
76
1.879
0.170
NS
78
1.566
0.211
NS
74
0.001
0.972
NS
76
0.185
0.667
NS
79
0.348
0.555
NS
79
0.089
0.766
NS
79
0.264
0.607
NS
79
2.438
0.118
NS
79
2.660
0.103
NS
Table ST-HYP-07-06: Automated process used on daily basis Vs Automated Process

basis has no significant influence on any of the nine Automated Process
design/development approaches and hence it can be concluded that Automated process
used on day-to-day basis has no significant influence on Automated Process
Analysis H7.07:
Fear of job loss
278
Fear of change
definition
Automated process currently used on day-to-day basis Vs Resistance to Process Automation
Resistence to process
automation
Automation was viewed

as externally imposed
Fear of job loss
Fear of change
The perception that
controlling
were not consulted
definition
Fear that metrics would
be used in job
evaluations
Automated
process used on
day-to-day basis
Yes
No
Count
77
Mean Rank
39.53
58.00
Count
77
Mean Rank
39.73
50.50
Count
77
Mean Rank
40.47
22.00
Count
77
Mean Rank
40.47
22.00
Count
77
Mean Rank
39.73
50.50
Count
77
Mean Rank
39.47
60.50
Total
Chi-Square
DF
P-Value
Result
79
1.378
0.241
NS
79
0.455
0.500
NS
79
1.418
0.234
NS
79
1.430
0.232
NS
79
0.476
0.490
NS
79
1.841
0.175
NS
Table ST-HYP-07-07: Automated process used on daily basis Vs Resistance to Process

Automation
basis has no significant influence on any of the six reasons for resistance to Process
Automation and hence it can be concluded that Automated process used on day-to-day
basis has no significant influence on the reasons for resistance to Process
Automation.
Analysis H7.08:
279

activities:


Automated process currently used on day-to-day basis Vs Management support
Automated
process used on
day-to-day basis
supportive
Yes
No
Count
77
Mean Rank
39.56
57.00
Received adequate
funding for transitioning
Count
77
Mean Rank
39.52
58.50
Automation has helped to

enforce defined process.
Count
58
19
Mean Rank
36.38
47.00
Total
Chi-Square
DF
P-Value
Result
79
1.471
0.225
NS
79
1.741
0.187
NS
77
4.271
0.039
Significant
Table ST-HYP-07-08: Automated process used on daily basis Vs Management Support to

Process Automation
basis has no significant influence on two out of three activities of Management support.
However, Automated process used on day-to-day basis has significant influence on
only one activity of Management support namely Automation has helped to enforce
defined process. Hence it can be concluded that Automated process used on day-today basis has little significant influence on the Management support to Process
Automation initiative.
280
Hypothesis VII: Summary and Conclusion
From the above statistical analysis, it is understood there are very few factors of
the independent variable Application focus significantly influence few factors of the
dependent variable Transition and Adoption. Therefore, the hypothesis is neither
relation to Transition and Adoption, it does not have a significant influence on
Hypothesis VIII: Process characteristics has no significant influence on

Development technology
To substantiate this hypothesis with data, 11 questions from Group D (Process

Characteristics) and 6 questions from Group E (Development Technology) are analyzed.
presented here.
Analysis H8.01:
1. Independent Variable - Group D Question 2: Projects routine activities:
Projects routinely use documented processes to perform their tasks
Projects routinely track and meet cost estimates
Projects routinely provide appropriate training on tools and
methods


281

Customer support
Documentation
Cost-effectiveness
Test Results: The two variables namely Projects Routine Activities and Process
Areas addressed by Process Automation have multiple factors and hence a twodimensional analysis is conducted. Below tables are the result of Kruskal-Wallis
Test conducted on data depicted in figures GRP-D-02-03, GRP-02-05 & GRP-0206 and GRP-E-02-01 to GRP-E-02-12.
Projects routinely use documented processes to perform their tasks Vs Strengths of Process
Automation Tool
Strengths of
Process
Automation Tool
Use
documented
process
Yes
No
The process
development
environment
Count
66
Mean Rank
35.30
45.20
Debugging
capabilities
Count
55
Mean Rank
31.10
23.90
Count
66
Mean Rank
34.90
50.50
Count
66
Mean Rank
36.27
32.50
Count
66
Mean Rank
36.61
27.90
application tools
Ability to design
effective end-user
interfaces
Ability to collect
metrics
Performance
Cross-platform
compatibilities
Customer support
Availability of
Documentation
Ease of use of the
development
environment
Cost-effectiveness
Count
66
Mean Rank
36.57
28.50
Count
66
Mean Rank
36.54
28.90
Count
66
Mean Rank
35.74
39.40
Count
66
Mean Rank
36.18
33.60
Count
66
Mean Rank
36.05
35.30
Count
66
Mean Rank
35.75
39.30
Count
66
Mean Rank
35.52
42.30
Total
Chi-Square
DF
P-Value
Result
71
1.606
0.205
NS
60
0.922
0.337
NS
71
3.447
0.063
NS
71
0.183
0.669
NS
71
1.086
0.297
NS
71
0.815
0.367
NS
71
0.703
0.402
NS
71
0.176
0.675
NS
71
0.081
0.776
NS
71
0.007
0.933
NS
71
0.150
0.699
NS
71
0.536
0.464
NS
Table ST-HYP-08-01-01: Projects routinely use documented processes to perform their

tasks Vs Strengths of Process Automation Tool
282
From the above table, it is observed that Projects routinely use documented
processes to perform their tasks has no significant influence on any of the twelve
strengths of Process Automation tool and hence it can be concluded that Projects
routinely use documented processes to perform their tasks has no significant
influence on the Strengths of Process Automation tool.
Projects routinely track and meet cost estimates Vs Strengths of Process Automation Tool
Strengths of
Process
Automation
The process
development
environment
Meet cost
estimates
Yes
No
Count
54
14
Mean Rank
34.78
33.43
Debugging
capabilities
Count
48
Mean Rank
27.92
32.00
application tools
Count
54
14
Mean Rank
36.22
27.86
Ability to design
effective end-user
interfaces
Count
54
14
Mean Rank
35.52
30.57
Ability to collect
metrics
Count
54
14
Mean Rank
35.07
32.29
Count
54
14
Mean Rank
33.11
39.86
Performance
Cross-platform
compatibilities
Customer support
Availability of
Documentation
Ease of use of the
development
environment
Cost-effectiveness
Count
54
14
Mean Rank
32.61
41.79
Count
54
14
Mean Rank
32.83
40.93
Count
54
14
Mean Rank
33.06
40.07
Count
54
14
Mean Rank
33.17
39.64
Count
54
14
Mean Rank
33.33
39.00
Count
54
14
Mean Rank
34.00
36.43
Total
Chi-Square
DF
P-Value
Result
68
0.080
0.777
NS
56
0.505
0.478
NS
68
2.501
0.114
NS
68
0.827
0.363
NS
68
0.323
0.570
NS
68
1.448
0.229
NS
68
2.663
0.103
NS
68
2.259
0.133
NS
68
1.541
0.214
NS
68
1.370
0.242
NS
68
1.011
0.315
NS
68
0.179
0.672
NS
Table ST-HYP-08-01-02: Projects routinely track and meet cost estimates Vs Strengths of
From the above table, it is observed that Projects routinely track and meet cost
estimates has no significant influence on any of the twelve strengths of Process
Automation tool and hence it can be concluded that Projects routinely track and meet
cost estimates has no significant influence on the Strengths of Process Automation
tool.
283
Projects routinely provide appropriate training on tools and methods Vs Strengths of Process
Automation Tool
Strengths of
Process
Automation
Provide
training on
tools and
methods
Yes
No
The process
development
environment
Count
52
15
Mean Rank
37.03
23.50
Debugging
capabilities
Count
52
Mean Rank
30.12
24.17
Count
52
15
Mean Rank
37.30
22.57
application tools
Ability to design
effective end-user
interfaces
Count
52
15
Mean Rank
36.57
25.10
Ability to collect
metrics
Count
52
15
Mean Rank
37.61
21.50
Count
52
15
Mean Rank
30.20
47.17
Performance
Cross-platform
compatibilities
Customer support
Availability of
Documentation
Ease of use of the
development
environment
Cost-effectiveness
Count
52
15
Mean Rank
30.61
45.77
Count
52
15
Mean Rank
32.39
39.57
Count
52
15
Mean Rank
30.92
44.67
Count
52
15
Mean Rank
30.91
44.70
Count
52
15
Mean Rank
31.10
44.07
Count
52
15
Mean Rank
31.88
41.33
Total
Chi-Square
DF
P-Value
Result
67
8.586
0.003
Significant
58
0.764
0.382
NS
67
8.354
0.004
Significant
67
4.689
0.030
Significant
67
10.941
0.001
Significant
67
9.767
0.002
Significant
67
7.789
0.005
Significant
67
1.872
0.171
NS
67
6.390
0.011
Significant
67
6.701
0.010
Significant
67
5.640
0.018
Significant
67
2.925
0.087
NS
Table ST-HYP-08-01-03: Projects routinely provide appropriate training on tools and

methods Vs Strengths of Process Automation Tool
From the above table, it is observed that Projects routinely provide appropriate
training on tools and methods has no significant influence on three out of the twelve
strengths of Process Automation tool. However, Projects routinely provide appropriate
training on tools and methods has significant influence on nine out of the twelve
strengths of Process Automation tool namely The process development environment,
Ability to integrate application tools, Ability to collect metrics, Performance,
Cross platform compatibilities, Availability of training in the tool, Documentation
and Ease of use of the development environment. Hence, it can be concluded that
284
Projects routinely provide appropriate training on tools and methods has significant
Analysis H8.02:

methods
2. Independent Variable - Group E Question 3: Defects in the automation
tool affected development
data depicted in figures GRP-D-02-03, GRP-02-05 & GRP-02-06 and GRP-E-03.
Projects' routine activities Vs Defects in the automation tool affected the development effort
Defects in tool
affected
development
Use documented
processes to
perform tasks
Yes
No
Count
66
Mean Rank
37.54
15.70
Meet cost
estimates
Count
54
14
Mean Rank
34.33
35.14
Provide training on
tools and methods
Count
52
15
Mean Rank
32.76
38.30
Total
Chi-Square
DF
P-Value
Result
71
5.662
0.017
Significant
68
0.020
0.887
NS
67
1.010
0.315
NS
Table ST-HYP-08-02: Projects routine activities Vs Defects in the automation tool affected
development
From the above table, it is observed that two of three Projects routine activities
have no significant influence on the weakness of Process Automation tool namely
Defects in the automation tool affected development. However, only one of the three
Projects routine activities namely Use documented processes to perform tasks has
significant influence on the weakness of Process Automation tool namely Defects in the
automation tool affected development. Hence, it can be concluded that Projects
285
routine activities has little significant influence on the weakness of Process

Automation tool namely Defects in the automation tool affected development.
Analysis H8.03:
methods
2. Independent Variable - Group E Question 4: System crashes affected
development effort
Projects' routine activities Vs System crashes affected the development effort
System crashes
affected
development
Yes
No
Use documented
processes to
perform tasks
Count
66
Mean Rank
36.49
29.50
Meet cost
estimates
Count
54
14
Mean Rank
37.31
23.68
Provide training on
tools and methods
Count
52
15
Mean Rank
35.93
27.30
Total
Chi-Square
DF
P-Value
Result
71
0.585
0.444
NS
68
5.851
0.016
Significant
67
2.541
0.111
NS
Table ST-HYP-08-03: Projects routine activities Vs System crashes affected development

effort
From the above table, it is observed that two of the three Projects routine
activities have no significant influence on the weakness of Process Automation tool.
However, only one of the three Projects routine activities namely Meet cost estimates
has significant influence on the weakness of Process Automation tool namely System
crashes affected development effort. Hence, it can be concluded that Projects routine
activities has little significant influence on the weakness of Process Automation tool
namely System crashes affected development effort.
286
Analysis H8.04:
methods
2. Independent Variable - Group E Question 5: Difficult to recover from
system crashes
Projects' routine activites Vs Difficult to recover from system crashes
Difficult to recover
from system crashes
Use documented
processes to
perform tasks
Yes
No
Count
66
Mean Rank
36.39
30.90
Meet cost
estimates
Count
54
14
Mean Rank
37.13
24.36
Provide training on
tools and methods
Count
52
15
Mean Rank
35.66
28.23
Total
Chi-Square
DF
P-Value
Result
71
0.366
0.545
NS
68
5.172
0.023
Significant
67
1.856
0.173
NS
Table ST-HYP-08-04: Projects routine activities Vs Difficult to recover from system crashes
activities have no significant influence on the weakness of Process Automation tool.
However, only one of the three Projects routine activities namely Meet cost estimates
has significant influence on the weakness of Process Automation tool namely Difficult
to recover from system crashes. Hence, it can be concluded that Projects routine
activities has little significant influence on the weakness of Process Automation tool
namely Difficult to recover from system crashes.
287
Analysis H8.05:
methods
2. Independent Variable - Group E Question 6: The automation tool
supports a good range of hardware platforms
Projects' routine activities Vs Tool supports a good range of hardware platforms
Tool supports a good
range of hardware
platforms
Use documented
processes to
perform tasks
Yes
No
Count
64
Mean Rank
34.61
40.00
Meet cost
estimates
Count
52
14
Mean Rank
31.68
40.25
Provide training on
tools and methods
Count
50
15
Mean Rank
29.60
44.33
Total
Chi-Square
DF
P-Value
Result
69
0.367
0.545
NS
66
2.405
0.121
NS
65
7.636
0.006
Significant
Table ST-HYP-08-05: Projects routine activities Vs The automation tool supports a good
range of hardware platforms
activities have no significant influence on the strength of Process Automation tool.
However, only one of the three Projects routine activities namely Provide training on
tools and methods has significant influence on the strength of Process Automation tool
namely The automation tool supports a good range of hardware platforms. Hence, it
can be concluded that Projects routine activities has little significant influence on the
strength of Process Automation tool namely The automation tool supports a good
range of hardware platforms.
288
Analysis H8.06:
1. Independent Variable - Group D Question 7: The process design is
clearly and completely documented.


Customer support
Documentation
Cost-effectiveness
data depicted in figures GRP-D-07 and GRP-E-02-01 to GRP-E-02-12.
289
The process design is clearly and completely documented Vs Strengths of Process Automation Tool
Strengths of
Process
Automation
Process design is
clearly and
completely
documented
Yes
No
The process
development
environment
Count
55
11
Mean Rank
33.19
35.05
Debugging
capabilities
Count
54
Mean Rank
33.31
24.11
application tools
Count
55
11
Mean Rank
35.20
25.00
Ability to design
effective end-user
interfaces
Count
55
11
Mean Rank
34.34
29.32
Ability to collect
metrics
Count
55
11
Mean Rank
32.81
36.95
Performance
Cross-platform
compatibilities
Customer support
Availability of
Documentation
Ease of use of the
development
environment
Cost-effectiveness
Count
55
11
Mean Rank
33.69
32.55
Count
55
11
Mean Rank
32.86
36.68
Count
55
11
Mean Rank
34.46
28.68
Count
55
11
Mean Rank
33.89
31.55
Count
55
11
Mean Rank
34.00
31.00
Count
55
11
Mean Rank
31.31
44.45
Count
55
11
Mean Rank
32.22
39.91
Total
Chi-Square
DF
P-Value
Result
66
0.117
0.732
NS
63
2.248
0.134
NS
66
3.455
0.063
NS
66
0.743
0.389
NS
66
0.538
0.463
NS
66
0.037
0.847
NS
66
0.407
0.524
NS
66
0.982
0.322
NS
66
0.156
0.693
NS
66
0.255
0.613
NS
66
4.657
0.031
Significant
66
1.610
0.205
NS
Table ST-HYP-08-06: The process design is clearly and completely documented Vs

From the above table, it is observed that The process design is clearly and
completely documented has no significant influence on eleven out of the twelve
strengths of Process Automation tool. However, The process design is clearly and
completely documented has significant influence on only one out of the twelve strengths
of Process Automation tool namely Ease of use of the development environment.
Hence, it can be concluded that the process design is clearly and completely
documented has very little significant influence on the Strengths of Process
Automation tool.
290
Analysis H8.07:
clearly and completely documented
Automation tool:


data depicted in figures GRP-D-07 and GRP-E-03 to GRP-E-06.
Process design is clearly and completely documented Vs Other qualities of Automation tool
Process design is
Other qualities of clearly and
Automation tool completely
documented
Defects in tool
Count
affected
Mean Rank
development
System crashes
affected
development
from system
crashes
Tool supports a
good range of
hardware platforms
Yes
No
55
11
31.48
43.59
Count
55
11
Mean Rank
33.52
33.41
Count
55
11
Mean Rank
32.79
37.05
Count
55
Mean Rank
31.30
39.83
Total
Chi-Square
DF
P-Value
Result
66
3.931
0.047
Significant
66
0.000
0.986
NS
66
0.498
0.480
NS
64
1.774
0.183
NS
Table ST-HYP-08-07: The process design is clearly and completely documented Vs Other
completely documented has no significant influence on three out of the four qualities of
Process Automation tool. However, The process design is clearly and completely
documented has a significant influence on only one of the four qualities of Process
Automation tool namely Defects in the automation tool affected development. Hence,
it can be concluded that The process design is clearly and completely documented has
little significant influence on other qualities of Process Automation tool.
291
Analysis H8.08:
1. Independent Variable - Group D Question 8: Functional requirements


Customer support
Documentation
Cost-effectiveness
292
Functional requirements used to define tools embedded in process Vs Strengths of Process Automation
Tool
Strengths of
Process
Automation Tool
Functional
requirements used to
define tools
embedded in
process
Yes
No
The process
development
environment
Count
65
Mean Rank
36.53
44.50
Debugging
capabilities
Count
56
Mean Rank
34.43
24.11
Count
65
Mean Rank
37.02
41.00
application tools
Ability to design
effective end-user
interfaces
Count
65
Mean Rank
37.96
34.17
Ability to collect
metrics
Count
65
Mean Rank
37.22
39.50
Performance
Cross-platform
compatibilities
Customer support
Availability of
Documentation
Ease of use of the
development
environment,
Cost-effectiveness
Count
65
Mean Rank
37.49
37.56
Count
65
Mean Rank
38.62
29.39
Count
65
Mean Rank
37.76
35.61
Count
65
Mean Rank
38.26
32.00
Count
65
Mean Rank
38.15
32.78
Count
65
Mean Rank
38.34
31.44
Count
65
Mean Rank
38.55
29.89
Total
Chi-Square
DF
P-Value
Result
74
1.566
0.211
NS
65
2.641
0.104
NS
74
0.336
0.562
NS
74
0.284
0.594
NS
74
0.114
0.736
NS
74
0.000
0.993
NS
74
1.632
0.201
NS
74
0.097
0.755
NS
74
0.748
0.387
NS
74
0.570
0.450
NS
74
0.889
0.346
NS
74
1.391
0.238
NS
Table ST-HYP-08-08: Functional requirements were used to define tools embedded in the
process Vs Strengths of Process Automation Tool
From the above table, it is observed that Functional requirements were used to
define tools embedded in the process has no significant influence on any of the twelve
strengths of Process Automation tool and hence, it can be concluded that Functional
requirements were used to define tools embedded in the process has no significant
Analysis H8.09:
293

Automation tool:


Functional requirements used to define tools embedded in process Vs Other qualities of Automation tool
Functional
requirements used to
Other qualities of
define tools
Automation tool
embedded in
process
Defects in tool
affected
development
System crashes
affected
development
from system
crashes
Tool supports a
good range of
hardware platforms
Yes
No
Count
65
Mean Rank
37.92
34.50
Count
65
Mean Rank
38.48
30.39
Count
65
Mean Rank
39.70
21.61
Count
63
Mean Rank
37.36
30.50
Total
Chi-Square
DF
P-Value
Result
74
0.213
0.644
NS
74
1.235
0.267
NS
74
6.171
0.013
Significant
72
0.934
0.334
NS
process Vs Other qualities of Process Automation Tool
define tools embedded in the process has no significant influence on three out of four
qualities of Process Automation tool. However, Functional requirements were used to
define tools embedded in the process has a significant influence on only one of the four
qualities of Process Automation tool namely Difficult to recover from system crashes.
Hence, it can be concluded that Functional requirements were used to define tools
embedded in the process has little significant influence on other qualities of Process
Automation tool.
294
Analysis H8.10:
1. Independent Variable - Group D Question 9: Metrics requirements are
specified for the process.


Customer support
Documentation
Cost-effectiveness
295
Metrics requirements are specified for the process Vs Strengths of Process Automation Tool
Strengths of
Process
Automation Tool
Metrics requirements
are specified for the
process
Yes
No
The process
development
environment
Count
33
38
Mean Rank
44.52
41.79
Debugging
capabilities
Count
26
35
Mean Rank
35.38
31.49
Count
33
38
Mean Rank
37.52
43.08
application tools
Ability to design
effective end-user
interfaces
Count
33
38
Mean Rank
37.21
43.00
Ability to collect
metrics
Count
33
38
Mean Rank
48.64
41.29
Performance
Cross-platform
compatibilities
Customer support
Availability of
Documentation
Ease of use of the
development
environment,
Cost-effectiveness
Count
33
38
Mean Rank
39.86
39.72
Count
33
38
Mean Rank
39.47
39.14
Count
33
38
Mean Rank
42.18
38.97
Count
33
38
Mean Rank
38.97
36.63
Count
33
38
Mean Rank
37.59
37.54
Count
33
38
Mean Rank
43.64
34.68
Count
33
38
Mean Rank
41.03
36.82
Total
Chi-Square
DF
P-Value
Result
71
1.793
0.408
NS
61
5.772
0.056
NS
71
3.444
0.179
NS
71
3.953
0.139
NS
71
10.561
0.005
Significant
71
4.603
0.100
NS
71
6.915
0.032
Significant
71
2.712
0.258
NS
71
17.120
0.000
Significant
71
18.558
0.000
Significant
71
11.980
0.003
Significant
71
10.016
0.007
Significant
Table ST-HYP-08-10: Metrics requirements are specified for the process Vs Strengths of
From the above table, it is observed that Metrics requirements are specified for
the process has no significant influence on six out of the twelve strengths of Process
Automation tool. However, Metrics requirements are specified for the process has
significant influence on six out of the twelve strengths of Process Automation tool
namely Ability to collect metrics, Cross platform compatibilities, Availability of
training in the tool, Documentation, Ease of use of the development environment
and Cost effectiveness. Hence, it can be concluded that Metrics requirements are
specified for the process has partial significant influence on the Strengths of Process
Automation tool.
296
Analysis H8.11:
Automation tool:


Metrics requirements are specified for the process Vs Other qualities of Automation tool
are specified for the
process
Defects in tool
affected
development
System crashes
affected
development
from system
crashes
Tool supports a
good range of
hardware platforms
Yes
No
Count
33
38
Mean Rank
41.92
38.20
Count
33
38
Mean Rank
38.79
43.89
Count
33
38
Mean Rank
37.65
43.80
Count
31
38
Mean Rank
38.60
38.62
Total
Chi-Square
DF
P-Value
Result
71
4.347
0.114
NS
71
1.077
0.584
NS
71
2.307
0.315
NS
69
5.414
0.067
NS
Table ST-HYP-08-11: Metrics requirements are specified for the process Vs Other qualities
of Process Automation Tool
the process has no significant influence on any of the four qualities of Process
Automation tool and hence, it can be concluded that Metrics requirements are specified
for the process has no significant influence on other qualities of Process Automation
tool.
297
Analysis H8.12:
1. Independent Variable - Group D Question 10: The target process was
not a prior manual process.


Customer support
Documentation
Cost-effectiveness
data depicted in figures GRP-D-10-01and GRP-E-02-01 to GRP-E-02-12.
298
The target process was not a prior manual process Vs Strengths of Process Automation Tool
Strengths of
Process
Automation Tool
The target process

was not a prior
manual process
Yes
No
The process
development
environment
Count
36
13
Mean Rank
25.67
23.15
Debugging
capabilities
Count
35
11
Mean Rank
25.50
17.14
Count
36
13
Mean Rank
26.43
21.04
application tools
Ability to design
effective end-user
interfaces
Count
36
13
Mean Rank
24.79
25.58
Ability to collect
metrics
Count
36
13
Mean Rank
25.60
23.35
Performance
Cross-platform
compatibilities
Customer support
Availability of
Documentation
Ease of use of the
development
environment,
Cost-effectiveness
Count
36
13
Mean Rank
23.26
29.81
Count
36
13
Mean Rank
21.82
33.81
Count
36
13
Mean Rank
24.75
25.69
Count
36
13
Mean Rank
22.17
32.85
Count
36
13
Mean Rank
22.68
31.42
Count
36
13
Mean Rank
22.15
32.88
Count
36
13
Mean Rank
22.04
33.19
Total
Chi-Square
DF
P-Value
Result
49
0.463
0.496
NS
46
3.844
0.050
Significant
49
1.801
0.180
NS
49
0.035
0.851
NS
49
0.310
0.578
NS
49
2.314
0.128
NS
49
7.608
0.006
Significant
49
0.049
0.825
NS
49
6.155
0.013
Significant
49
4.175
0.041
Significant
49
5.853
0.016
Significant
49
6.305
0.012
Significant
Table ST-HYP-08-12: The target process was not a prior manual process Vs Strengths of
From the above table, it is observed that The target process was not a prior
manual process has no significant influence on six out of the twelve strengths of Process
Automation tool. However, The target process was not a prior manual process has
significant influence on six out of the twelve strengths of Process Automation tool
namely Debugging capabilities, Cross platform compatibilities, Availability of
training in the tool, Documentation, Ease of use of the development environment
and Cost effectiveness. Hence, it can be concluded that The target process was not a
prior manual process has good significant influence on the Strengths of Process
Automation tool.
299
Analysis H8.13:
1. Independent Variable - Group D Question 10: The target process was
not a prior manual process
Automation tool:


data depicted in figures GRP-D-10-01 and GRP-E-03 to GRP-E-06.
The target process was not a prior manual process Vs Other qualities of Automation tool
The target process

Other qualities of
was not a prior
Automation tool
manual process
Defects in tool
affected
development
System crashes
affected
development
from system
crashes
Tool supports a
good range of
hardware platforms
Yes
No
Count
36
13
Mean Rank
23.25
29.85
Count
36
13
Mean Rank
24.63
26.04
Count
36
13
Mean Rank
25.74
22.96
Count
36
11
Mean Rank
23.33
26.18
Total
Chi-Square
DF
P-Value
Result
49
2.210
0.137
NS
49
0.102
0.750
NS
49
0.398
0.528
NS
47
0.408
0.523
NS
Table ST-HYP-08-13: The target process was not a prior manual process Vs Other qualities
of Process Automation Tool
From the above table, it is observed that The target process was not a prior
manual process has no significant influence on any of the four qualities of Process
Automation tool and hence, it can be concluded that The target process was not a prior
manual process has no significant influence on other qualities of Process
Automation tool.
300
Analysis H8.14:
1. Independent Variable - Group D Question 11 Process definition was
more challenging than first thought.


Customer support
Documentation
Cost-effectiveness
data depicted in figures GRP-D-11and GRP-E-02-01 to GRP-E-02-12.
301
Process definition was challenging Vs Strengths of Process Automation Tool

Strengths of
Process definition
Process Automation
was challenging
Tool
The process
Count
development
Mean Rank
environment
Debugging
capabilities
application tools
Yes
No
54
15
33.72
39.60
Count
45
15
Mean Rank
27.89
38.33
Count
54
15
Mean Rank
32.23
44.97
Ability to design
effective end-user
interfaces
Count
54
15
Mean Rank
31.19
48.70
Ability to collect
metrics
Count
54
15
Mean Rank
35.47
33.30
Performance
Cross-platform
compatibilities
Customer support
Availability of training
in the tool
Documentation
Ease of use of the
development
environment,
Cost-effectiveness
Count
54
15
Mean Rank
30.19
52.30
Count
54
15
Mean Rank
33.14
41.70
Count
54
15
Mean Rank
33.14
41.70
Count
54
15
Mean Rank
32.52
43.93
Count
54
15
Mean Rank
31.99
45.83
Count
54
15
Mean Rank
33.32
41.03
Count
54
15
Mean Rank
32.16
45.23
Total
Chi-Square
DF
P-Value
Result
69
1.511
0.219
NS
60
4.882
0.027
Significant
69
6.307
0.012
Significant
69
10.856
0.001
Significant
69
0.180
0.671
NS
69
16.189
0.000
Significant
69
2.380
0.123
NS
69
2.767
0.096
NS
69
4.327
0.038
Significant
69
6.599
0.010
Significant
69
1.873
0.171
NS
69
5.368
0.021
Significant
Table ST-HYP-08-14: Process definition was more challenging than first thought Vs
From the above table, it is observed that Process definition was more challenging
than first thought has no significant influence on five out of the twelve strengths of
Process Automation tool. However, Process definition was more challenging than first
thought has significant influence on seven out of the twelve strengths of Process
Automation tool namely Debugging capabilities, Ability to integrate application
tools, Ability to design effective end-user interfaces, Performance, Availability of
training in the tool, Documentation and Cost effectiveness. Hence, it can be
concluded that Process definition was more challenging than first thought has good
significant influence on the Strengths of Process Automation tool.
302
Analysis H8.15:
1. Independent Variable - Group D Question 11: Process definition was
more challenging than first thought
Automation tool:


data depicted in figures GRP-D-11and GRP-E-03 to GRP-E-06.
Process definition was challenging Vs Other qualities of Automation tool
Other qualities of
Automation tool
Process definition
was challenging
Yes
No
Defects in tool
affected development
Count
54
15
Mean Rank
32.36
44.50
System crashes
affected development
Count
54
15
Mean Rank
32.38
44.43
from system crashes
Count
54
15
Mean Rank
35.68
32.57
Tool supports a good

range of hardware
platforms
Count
54
13
Mean Rank
34.06
33.73
Total
Chi-Square
DF
P-Value
Result
69
4.695
0.030
Significant
69
4.862
0.027
Significant
69
0.320
0.571
NS
67
0.003
0.954
NS
Table ST-HYP-08-15: Process definition was more challenging than first thought Vs Other
than first thought has no significant influence on two of the four qualities of Process
Automation tool. However, Process definition was more challenging than first thought
has a significant influence on two of the four qualities of Process Automation tool namely
Defects in the automation tool affected development and System crashes affected
development and hence, it can be concluded that Process definition was more
303
challenging than first thought some significant influence on other qualities of

Process Automation tool.
Hypothesis VIII: Summary and Conclusion
independent variable Process Characteristics that significantly influence few factors
of the dependent variable Development Technology. Therefore, the hypothesis is
neither accepted nor rejected.
Hence, it can be concluded that while Process
Characteristics has a relation to Development Technology, it does not have a

significant influence on Development Technology.
Hypothesis IX: Process characteristics has no significant influence on Transition

and adoption

Characteristics) and 24 questions from Group F (Transition and Adoption) are analyzed.
presented here.
Analysis H9.01:
methods
support:

304
Test Results: The two variables namely Projects Routine Activities and Training
Provided for Support have multiple factors and hence a two-dimensional analysis
is conducted. Below tables are the result of Kruskal-Wallis Test conducted on
data depicted in figures GRP-D-02-03, GRP-02-05 & GRP-02-06 and GRP-F-0301 to GRP-F-03-02.
Projects routinely use documented processes to perform their tasks Vs Training Provided
Training Provided to
Projects routinely use

documented processes
Yes
No
Implementers of the
process-centered
environment
Count
66
Mean Rank
36.73
26.40
End-users of the
automated process
Count
66
Mean Rank
36.76
26.00
Total
Chi-Square
DF
P-Value
Result
71
1.369
0.242
NS
71
1.504
0.220
NS

tasks Vs Training provided
processes to perform their tasks has no significant influence on any of the two kinds of
training provided to support the Process Automation tool and hence it can be concluded
that Projects routinely use documented processes to perform their tasks has no
significant influence on the kinds of training provided to support the Process
Automation tool.
Projects routinely track and meet cost estimates Vs Training Provided

Projects routinely meet cost

estimates
Yes
No
Implementers of the
process-centered
environment
Count
54
14
Mean Rank
33.91
36.79
End-users of the
automated process
Count
54
14
Mean Rank
32.48
42.29
Total
Chi-Square
DF
P-Value
Result
68
0.268
0.605
NS
68
3.155
0.076
NS
Table ST-HYP-09-01-02: Projects routinely track and meet cost estimates Vs Training
provided
estimates has no significant influence on any of the two kinds of training provided to
support the Process Automation tool and hence it can be concluded that Projects
305
routinely track and meet cost estimates has no significant influence on the kinds of
training provided to support the Process Automation tool.
306
Projects routinely provide appropriate training on tools and methods Vs Training Provided
Training provided to
Projects routinely provide

training on tools and
methods
Yes
No
Implementers of the
process-centered
environment
Count
52
15
Mean Rank
37.88
20.53
End-users of the
automated process
Count
52
15
Mean Rank
30.31
46.80
Total
Chi-Square
DF
P-Value
Result
67
10.824
0.001
Significant
67
9.952
0.002
Significant

methods Vs Training provided
training on tools and methods has significant influence on both the kinds of training
provided to support the Process Automation tool namely Implementers of the processcentered environment and End-users of the automated process and hence it can be
concluded that Projects routinely provide appropriate training on tools and methods
has some significant influence on the kinds of training provided to support the
Therefore, it can be concluded that Projects routine activities have some

significant influence on the kinds of training provided to support the Process
Automation tool.
Analysis H9.02:
methods
307


Test Results: The two variables namely Projects Routine Activities and
Automated Process Design/Development Approach have multiple factors and
hence a two-dimensional analysis is conducted. Below tables are the result of
Kruskal-Wallis Test conducted on data depicted in figures GRP-D-02-03, GRP02-05 & GRP-02-06 and GRP-F-04 to GRP-F-12.
Projects routinely use documented processes to perform their tasks Vs Automated Process design/development
approach
Automated process
approach

Yes
No
Process design developed

in conjunction with endusers
Count
64
Mean Rank
34.72
38.60

with end-users
Count
66
Mean Rank
35.52
42.30
End-user screens
Count
64
Mean Rank
34.63
20.50
Process simulations
Count
64
Mean Rank
36.28
18.60

effectiveness
Count
66
Mean Rank
35.24
46.00
End-users had difficulty in

accepting
Count
66
Mean Rank
36.15
34.00
Count
66
Mean Rank
36.21
33.20
End-users make
Count
66
Mean Rank
36.07
35.10

automated process
Count
66
Mean Rank
36.11
34.60
Total
Chi-Square
DF
P-Value
Result
69
0.226
0.634
NS
71
0.684
0.408
NS
67
1.705
0.192
NS
69
4.490
0.034
Significant
71
1.608
0.205
NS
71
0.057
0.811
NS
71
0.123
0.726
NS
71
0.012
0.912
NS
71
0.030
0.863
NS

tasks Vs Automated Process design/development approach
processes to perform their tasks has no significant influence on eight out of the nine
Automated Process design/development approaches. However, Projects routinely use
documented processes to perform their tasks has a significant influence on only one of
the nine Automated Process design/development approaches namely Process
308
simulations performed with the end-users. Hence it can be concluded that Projects
routinely use documented processes to perform their tasks has very little significant
influence on Automated Process design/development approach.
Projects routinely track and meet cost estimates Vs Automated Process design/development approach
Automated process
approach
with end-users

estimates
Yes
No
Count
52
14
Mean Rank
33.85
32.21
Count
52
14
Mean Rank
34.00
31.64
End-user screens
Count
50
14
Mean Rank
30.78
38.64
Process simulations
Count
52
14
Mean Rank
32.58
36.93

effectiveness
Count
54
14
Mean Rank
32.91
40.64

accepting
Count
54
14
Mean Rank
37.19
24.14
Count
54
14
Mean Rank
33.98
36.50
End-users make
Count
54
14
Mean Rank
34.59
34.14

automated process
Count
54
14
Mean Rank
33.91
36.79
Total
Chi-Square
DF
P-Value
Result
66
0.105
0.746
NS
66
0.222
0.638
NS
64
2.227
0.136
NS
66
0.687
0.407
NS
68
2.077
0.150
NS
68
5.684
0.017
Significant
68
0.216
0.642
NS
68
0.007
0.933
NS
68
0.288
0.592
NS
Table ST-HYP-09-02-02: Projects routinely track and meet cost estimates Vs Automated
Process design/development approach
estimates has no significant influence on eight out of the nine Automated Process
design/development approaches. However, Projects routinely track and meet cost
estimates has a significant influence on only one of the nine Automated Process
design/development approaches namely End-users had difficulty in accepting. Hence,
it can be concluded that Projects routinely track and meet cost estimates has very
little significant influence on Automated Process design/development approach.
309
Projects routinely provide appropriate training on tools and methods Vs Automated Process design/development
approach
methods
Automated process
approach
Yes
No

Count
52
13
Mean Rank
33.25
32.00

with end-users
Count
52
13
Mean Rank
32.63
34.50
End-user screens
Count
50
13
Mean Rank
30.27
38.65
Process simulations
Count
52
13
Mean Rank
32.40
35.38

effectiveness
Count
52
15
Mean Rank
33.38
36.13

accepting
Count
52
15
Mean Rank
35.54
28.67
Count
52
15
Mean Rank
34.90
30.87
End-users make
Count
52
15
Mean Rank
33.95
34.17

automated process
Count
52
15
Mean Rank
34.15
33.47
Total
Chi-Square
DF
P-Value
Result
65
0.059
0.808
NS
65
0.136
0.712
NS
63
2.478
0.115
NS
65
0.316
0.574
NS
67
0.282
0.595
NS
67
1.635
0.201
NS
67
0.589
0.443
NS
67
0.002
0.967
NS
67
0.017
0.895
NS
Table ST-HYP-09-02-03: Projects routinely provide appropriate training on tools

and methods Vs Automated Process design/development approach
training on tools and methods has no significant influence on any of the nine Automated
Process design/development approaches and hence it can be concluded that Projects
routinely provide appropriate training on tools and methods has no significant
Analysis H9.03:
methods
310

Fear of job loss

Fear of change
definition
Test Results: The two variables namely Projects Routine Activities and Reasons
for Resistance to Process Automation have multiple factors and hence a twodimensional analysis is conducted. Below tables are the result of Kruskal-Wallis
Test conducted on data depicted in figures GRP-D-02-03, GRP-02-05 & GRP-0206 and GRP-F-13-01 to GRP-F-13-06.
Projects routinely use documented processes to perform their tasks Vs Resistance to process automation
automation
Automation was viewed as
externally imposed
Fear of job loss
Fear of change
The perception that
controlling
were not consulted
definition
Fear that metrics would be
used in job evaluations

Yes
No
Count
66
Mean Rank
36.38
31.00
Count
66
Mean Rank
35.58
41.60
Count
66
Mean Rank
35.67
40.40
Count
66
Mean Rank
35.54
42.10
Count
66
Mean Rank
35.61
41.10
Count
66
Mean Rank
35.68
40.20
Total
Chi-Square
DF
P-Value
Result
71
0.344
0.557
NS
71
0.420
0.517
NS
71
0.275
0.600
NS
71
0.536
0.464
NS
71
0.370
0.543
NS
71
0.254
0.614
NS

tasks Vs Resistance to Process Automation
processes to perform their tasks has no significant influence on any of the six reasons for
resistance to Process Automation and hence it can be concluded that Projects routinely
use documented processes to perform their tasks has no significant influence on the
reasons for resistance to Process Automation.
311
Projects routinely track and meet cost estimates Vs Resistance to process automation
automation
externally imposed
Fear of job loss
Fear of change
The perception that
controlling
were not consulted
definition

estimates
Yes
No
Count
54
14
Mean Rank
35.41
31.00
Count
54
14
Mean Rank
37.28
23.79
Count
54
14
Mean Rank
34.33
35.14
Count
54
14
Mean Rank
31.98
44.21
Count
54
14
Mean Rank
36.81
25.57
Count
54
14
Mean Rank
36.76
25.79
Total
Chi-Square
DF
P-Value
Result
68
0.604
0.437
NS
68
5.523
0.019
Significant
68
0.021
0.885
NS
68
4.825
0.028
Significant
68
3.983
0.046
Significant
68
3.928
0.047
Significant
Table ST-HYP-09-03-02: Projects routinely track and meet cost estimates Vs Resistance to
Process Automation
estimates has no significant influence on two out of six reasons for resistance to Process
Automation. However, Projects routinely track and meet cost estimates has a
significant influence on four out of six reasons for resistance to Process Automation
namely Fear of job loss, The perception that process automation is too controlling,
End-users feel that they were not consulted sufficiently in process definition and Fear
that metrics would be used in job evaluations. Hence it can be concluded that Projects
routinely track and meet cost estimates has a significant influence on the reasons for
resistance to Process Automation.
Projects routinely provide appropriate training on tools and methods Vs Resistance to process automation
automation
externally imposed
Fear of job loss
Fear of change
The perception that
controlling
were not consulted
definition

methods
Yes
No
Count
52
15
Mean Rank
36.23
26.27
Count
52
15
Mean Rank
37.65
21.33
Count
52
15
Mean Rank
35.13
30.07
Count
52
15
Mean Rank
32.70
38.50
Count
52
15
Mean Rank
37.99
20.17
Count
52
15
Mean Rank
37.19
22.93
Total
Chi-Square
DF
P-Value
Result
67
3.299
0.069
NS
67
8.666
0.003
Significant
67
0.861
0.354
NS
67
1.150
0.284
NS
67
10.788
0.001
Significant
67
7.099
0.008
Significant

methods Vs Resistance to Process Automation
312
training on tools and methods has no significant influence on three out of six reasons for
resistance to Process Automation. However, Projects routinely provide appropriate
training on tools and methods has a significant influence on three out of six reasons for
resistance to Process Automation namely Fear of job loss, End-users feel that they
were not consulted sufficiently in process definition and Fear that metrics would be
used in job evaluations. Hence it can be concluded that Projects routinely provide
appropriate training on tools and methods has significant influence on the reasons
for resistance to Process Automation.
Analysis H9.04:
methods
activities:


Test Results: The two variables namely Projects Routine Activities and
Management Support Activities have multiple factors and hence a twodimensional analysis is conducted. Below tables are the result of Kruskal-Wallis
Test conducted on data depicted in figures GRP-D-02-03, GRP-02-05 & GRP-0206 and GRP-F-14 to GRP-F-20.
313
Projects routinely use documented processes to perform their tasks Vs Management Support
Management support
activiti es
Projects routi nely use

docum ented processes
Yes
No
supportive
Count
66
Mean Rank
35.76
39.20
Firs t-line management is

supportive
Count
64
Mean Rank
35.12
33.50
plan was writt en
Count
64
Mean Rank
35.57
27.70

to by management
Count
64
Mean Rank
34.66
39.30

management
Count
64
Mean Rank
34.56
40.60
Total
Chi-Squar e
DF
P-Value
Resul t
71
0. 168
0. 682
NS
69
0. 039
0. 843
NS
69
0. 911
0. 340
NS
69
0. 322
0. 570
NS
69
0. 510
0. 475
NS

tasks Vs Management Support to Process Automation
processes to perform their tasks no significant influence on any the five activities of
Management support and hence it can be concluded that Projects routinely use
documented processes to perform their tasks has no significant influence on the
Management support to Process Automation initiative.
Projects routinely track and meet cost estimates Vs Management Support

Management Support
activities

estimates
Yes
No
supportive
Count
54
14
Mean Rank
34.54
34.36
supportive
Count
52
14
Mean Rank
32.00
39.07
plan was written
Count
52
14
Mean Rank
33.38
33.93

to by management
Count
52
14
Mean Rank
31.46
41.07

management
Count
52
14
Mean Rank
32.54
37.07
Total
Chi-Square
DF
P-Value
Result
68
0.001
0.972
NS
66
1.967
0.161
NS
66
0.012
0.915
NS
66
3.501
0.061
NS
66
0.747
0.387
NS
Table ST-HYP-09-04-02: Projects routinely track and meet cost estimates Vs Management
estimates has no significant influence on any of the five activities of Management
support and hence it can be concluded that Projects routinely track and meet cost
estimates has no significant influence on the Management support to Process
314
Projects routinely provide appropriate training on tools and methods Vs Management Support
Management Support
activities

methods
Yes
No
supportive
Count
52
15
Mean Rank
34.00
34.00
supportive
Count
50
15
Mean Rank
33.51
31.30
plan was written
Count
50
15
Mean Rank
31.87
36.77

to by management
Count
50
15
Mean Rank
33.19
32.37

management
Count
50
15
Mean Rank
32.16
35.80
Total
Chi-Square
DF
P-Value
Result
67
0.000
1.000
NS
65
0.204
0.652
NS
65
0.999
0.318
NS
65
0.028
0.867
NS
65
0.518
0.472
NS

methods Vs Management Support to Process Automation
training on tools and methods has no significant influence on any of the five activities of
Management support and hence it can be concluded that Projects routinely provide
appropriate training on tools and methods has no significant influence on the
Management support to Process Automation initiative.
Analysis H9.05:
support:
data depicted in figures GRP-D-02-03, GRP-02-05 & GRP-02-06 and GRP-F-0301 to GRP-F-03-02.
315
The process design is clearly and completely documented Vs Training Provided

The process design is

documented
Yes
No
Implementers of the
process-centered
environment
Count
55
11
Mean Rank
33.11
35.45
End-users of the
automated process
Count
55
11
Mean Rank
32.68
37.59
Total
Chi-Square
DF
P-Value
Result
66
0.159
0.690
NS
66
0.743
0.389
NS

Training provided
completely documented has no significant influence on any of the two kinds of training
provided to support the Process Automation tool and hence it can be concluded that The
process design is clearly and completely documented has no significant influence on
the kinds of training provided to support the Process Automation tool.
Analysis H9.06:


data depicted in figures GRP-D-07 and GRP-F-04 to GRP-F-12.
316
The process design is clearly and completely documented Vs Automated Process design/development approach
Automated process
approach
documented
Count
in conjunction with endMean Rank
users
Yes
No
55
11
34.57
28.14

with end-users
Count
55
11
Mean Rank
32.60
38.00
End-user screens
Count
53
11
Mean Rank
30.19
43.64
Process simulations
Count
55
11
Mean Rank
33.88
31.59

effectiveness
Count
55
11
Mean Rank
34.28
29.59

accepting
Count
55
11
Mean Rank
35.51
23.45
Count
55
11
Mean Rank
35.65
22.73
End-users make
Count
55
11
Mean Rank
36.50
18.50

automated process
Count
55
11
Mean Rank
34.80
27.00
Total
Chi-Square
DF
P-Value
Result
66
1.335
0.248
NS
66
0.967
0.325
NS
64
5.418
0.020
Significant
66
0.156
0.692
NS
66
0.730
0.393
NS
66
4.001
0.045
Significant
66
5.230
0.022
Significant
66
9.463
0.002
Significant
66
1.780
0.182
NS

completely documented has no significant influence on five out of the nine Automated
Process design/development approaches. However, The process design is clearly and
completely documented has a significant influence on four out of the nine Automated
Process design/development approaches namely End-user screens evaluated by the endusers, End-users had difficulty in accepting, End-users feel ownership and Endusers make suggestions to improve. Hence it can be concluded that the process design
is clearly and completely documented has a significant influence on Automated
Process design/development approach.
Analysis H9.07:
317



Fear of job loss
Fear of change
definition
data depicted in figures GRP-D-07 and GRP-F-13-01 to GRP-F-13-06.
The process design is clearly and completely documented Vs Resistance to process automation
automation
externally imposed

documented
Yes
No
Count
55
11
Mean Rank
33.89
31.55
Count
55
11
Mean Rank
35.03
25.86
Fear of job loss

Count
55
11
Mean Rank
32.63
37.86
Fear of change
The perception that
controlling
were not consulted
definition
Count
55
11
Mean Rank
33.95
31.27
Count
55
11
Mean Rank
36.11
20.45
Count
55
11
Mean Rank
33.99
31.05
Total
Chi-Square
DF
P-Value
Result
66
0.151
0.697
NS
66
2.214
0.137
NS
66
0.767
0.381
NS
66
0.213
0.645
NS
66
6.821
0.009
Significant
66
0.245
0.621
NS

completely documented has no significant influence on five out of the six reasons for
resistance to Process Automation. However, The process design is clearly and
completely documented has a significant influence on one of the six reasons for
resistance to Process Automation namely End-users feel that they were not consulted
sufficiently in process definition. Hence it can be concluded that the process design is
clearly and completely documented has little significant influence on the reasons for
resistance to Process Automation.
318
Analysis H9.08:
activities:


The process design is clearly and completely documented Vs Management Support
Management support
activities

documented
Yes
No
supportive
Count
55
11
Mean Rank
34.97
26.14
supportive
Count
53
11
Mean Rank
32.79
31.09
plan was written
Count
53
11
Mean Rank
31.91
35.36

to by management
Count
53
11
Mean Rank
31.85
35.64

management
Count
53
11
Mean Rank
31.33
38.14
Total
Chi-Square
DF
P-Value
Result
66
2.551
0.110
NS
64
0.100
0.752
NS
64
0.416
0.519
NS
64
0.471
0.493
NS
64
1.462
0.227
NS

completely documented has no significant influence on any of the five activities of
Management support and hence it can be concluded that The process design is clearly
and completely documented has no significant influence on the Management
support to Process Automation initiative.
319
Analysis H9.09:
support:
Functional requirements were used to define tools embedded in the process Vs Training Provided
Functional requirements
used to define tools
Implementers of the
process-centered
environment
End-users of the
automated process
Yes
No
Count
65
Mean Rank
37.32
38.78
Count
65
Mean Rank
37.50
37.50
Total
Chi-Square
DF
P-Value
Result
74
0.042
0.838
NS
74
0.000
1.000
NS
process Vs Training provided
define tools embedded in the process has no significant influence on any of the two
kinds of training provided to support the Process Automation tool and hence it can be
concluded that Functional requirements were used to define tools embedded in the
process has no significant influence on the kinds of training provided to support the
Analysis H9.10:
320



Functional requirements were used to define tools embedded in the process Vs Automated Process
Automated process
approach
Yes
No

Count
63
Mean Rank
34.06
53.61

with end-users
Count
63
Mean Rank
34.86
48.00
End-user screens
Count
61
Mean Rank
34.52
42.11
Process simulations
Count
63
Mean Rank
35.50
43.50

effectiveness
Count
65
Mean Rank
35.75
50.17

accepting
Count
65
Mean Rank
38.29
31.78
Count
65
Mean Rank
38.88
27.56
End-users make
Count
65
Mean Rank
37.22
39.50

automated process
Count
65
Mean Rank
36.12
47.44
Total
Chi-Square
DF
P-Value
Result
72
8.932
0.003
Significant
72
4.169
0.041
Significant
70
1.216
0.270
NS
72
1.400
0.237
NS
74
4.331
0.037
Significant
74
0.796
0.372
NS
74
2.568
0.109
NS
74
0.103
0.748
NS
74
2.558
0.110
NS
process Vs Automated Process design/development approach
define tools embedded in the process has no significant influence on six out of the nine
Automated Process design/development approaches. However, Functional requirements
321
were used to define tools embedded in the process has a significant influence on three of
the nine Automated Process design/development approaches namely Process design
developed in conjunction with end-users, Process design reviewed with end-users and
Tool improves end-user effectiveness. Hence it can be concluded that Functional
requirements were used to define tools embedded in the process has some significant
Analysis H9.11:


Fear of job loss
Fear of change
definition
Functional requirements were used to define tools embedded in the process Vs Resistance to process automation
automation
externally imposed
Yes
No
Count
65
Mean Rank
38.95
27.00
Count
65
Mean Rank
38.41
30.94
Fear of job loss

Count
65
Mean Rank
38.48
30.39
Count
65
Mean Rank
39.65
22.00
Fear of change
The perception that
controlling
were not consulted
definition
Count
65
Mean Rank
39.11
25.89
Count
65
Mean Rank
38.19
32.50
Total
Chi-Square
DF
P-Value
Result
74
2.705
0.100
NS
74
1.010
0.315
NS
74
1.234
0.267
NS
74
6.072
0.014
Significant
74
3.303
0.069
NS
74
0.639
0.424
NS
322
process Vs Resistance to Process Automation
define tools embedded in the process has no significant influence on five out of the six
reasons for resistance to Process Automation. However, Functional requirements were
used to define tools embedded in the process has a significant influence on one of the six
reasons for resistance to Process Automation namely The perception that process
automation is too controlling. Hence it can be concluded that Functional requirements
were used to define tools embedded in the process has little significant influence on
the reasons for resistance to Process Automation.
Analysis H9.12:
activities:


323
Functional requirements were used to define tools embedded in the process Vs Management Support
Management support
activities
Yes
No
supportive
Count
65
Mean Rank
35.22
53.94
supportive
Count
63
Mean Rank
36.08
39.44
plan was written
Count
63
Mean Rank
33.37
58.44

to by management
Count
63
Mean Rank
36.11
39.22

management
Count
63
Mean Rank
33.80
55.39
Total
Chi-Square
DF
P-Value
Result
74
7.803
0.005
Significant
72
0.273
0.601
NS
72
14.725
0.000
Significant
72
0.222
0.637
NS
72
10.135
0.001
Significant
process Vs Management Support to Process Automation
define tools embedded in the process has no significant influence on two out of five
activities of Management support. However, Functional requirements were used to
define tools embedded in the process has a significant influence on three out of five
activities of Management support namely Senior management is supportive, An
automation business plan was written, Design reviewed with management. Hence it
can be concluded that Functional requirements were used to define tools embedded in
the process has some significant influence on the Management support to Process
Analysis H9.13:
support:
324
Metrics requirements are specified for the process Vs Training Provided

specified
Yes
No
Implementers of the
process-centered
environment
Count
33
38
Mean Rank
35.56
42.54
End-users of the
automated process
Count
33
38
Mean Rank
39.06
35.29
Total
Chi-Square
DF
P-Value
Result
83
8.942
0.011
Significant
83
24.052
0.000
Significant
Table ST-HYP-09-13: Metrics requirements are specified for the process Vs Training
provided
the process has significant influence on both of the two kinds of training provided to
support the Process Automation tool namely Implementers of the process-centered
environment and End-users of the automated process and hence it can be concluded
that Metrics requirements are specified for the process has a significant influence on
the kinds of training provided to support the Process Automation tool.
Analysis H9.14:


325
Metrics requirements are specified for the process Vs Automated Process design/development approach
Automated process
approach
specified
Count
users
Yes
No
31
38
37.44
44.17

with end-users
Count
31
38
Mean Rank
30.15
46.41
End-user screens
Count
31
36
Mean Rank
37.58
35.78
Process simulations
Count
31
38
Mean Rank
39.32
37.58

effectiveness
Count
33
38
Mean Rank
39.67
40.61

accepting
Count
33
38
Mean Rank
29.45
46.71
Count
33
38
Mean Rank
39.67
37.39
End-users make
Count
33
38
Mean Rank
38.15
38.82

automated process
Count
33
38
Mean Rank
42.00
38.71
Total
Chi-Square
DF
P-Value
Result
79
3.609
0.165
NS
81
14.741
0.001
Significant
77
6.556
0.038
Significant
79
3.424
0.180
NS
83
3.442
0.179
NS
83
20.456
0.000
Significant
83
12.687
0.002
Significant
83
12.029
0.002
Significant
83
3.443
0.179
NS
Table ST-HYP-09-14: Metrics requirements are specified for the process Vs Automated
the process has no significant influence on four out of nine Automated Process
design/development approaches. However, Metrics requirements are specified for the
process has a significant influence on five out of nine Automated Process
design/development approaches namely Process design reviewed with end-users, Enduser screens evaluated by the end-users, End-users had difficulty in accepting, Endusers feel ownership and End-users make suggestions to improve. Hence it can be
concluded that Metrics requirements are specified for the process has a significant
Analysis H9.15:
326



Fear of job loss
Fear of change
definition
Metrics requirements are specified for the process Vs Resistance to process automation
automation
externally imposed
specified
Yes
No
Count
33
38
Mean Rank
37.62
41.75
Count
33
38
Mean Rank
33.62
45.33
Fear of job loss

Count
33
38
Mean Rank
41.74
39.62
Fear of change
The perception that
controlling
were not consulted
definition
Count
33
38
Mean Rank
38.68
39.04
Count
33
38
Mean Rank
34.39
42.68
Count
33
38
Mean Rank
36.23
46.67
Total
Chi-Square
DF
P-Value
Result
83
4.881
0.087
NS
83
8.385
0.015
Significant
83
1.975
0.373
NS
83
9.241
0.010
Significant
83
11.582
0.003
Significant
83
3.748
0.153
NS
Table ST-HYP-09-15: Metrics requirements are specified for the process Vs Resistance to
Process Automation
the process has no significant influence on three out of six reasons for resistance to
Process Automation. However, Metrics requirements are specified for the process has a
significant influence on three out of six reasons for resistance to Process Automation
namely Fear of job loss, The perception that process automation is too controlling
and End-users feel that they were not consulted sufficiently in process definition.
Hence it can be concluded that Metrics requirements are specified for the process has
partial significant influence on the reasons for resistance to Process Automation.
327
Analysis H9.16:
activities:


Metrics requirements are specified for the process Vs Management Support
Management support
activities
specified
Yes
No
supportive
Count
33
38
Mean Rank
39.36
43.18
supportive
Count
33
36
Mean Rank
45.71
36.96
plan was written
Count
33
36
Mean Rank
39.64
40.75

to by management
Count
33
36
Mean Rank
38.52
36.86

management
Count
33
36
Mean Rank
36.77
42.01
Total
Chi-Square
DF
P-Value
Result
83
0.974
0.614
NS
81
3.257
0.196
NS
81
0.767
0.681
NS
81
11.872
0.003
Significant
81
3.234
0.198
NS
Table ST-HYP-09-16: Metrics requirements are specified for the process Vs Management
the process has no significant influence on four out of five activities of Management
support. However, Metrics requirements are specified for the process has significant
influence on one of the five activities of Management support namely Development plan
agreed to by Management. Hence it can be concluded that Metrics requirements are
specified for the process has little significant influence on the Management support
to Process Automation initiative.
328
Analysis H9.17:
1. Independent Variable - Group D Question 10: The target process was no
prior manual process
support:
data depicted in figures GRP-D-10-01 and GRP-F-03-01 to GRP-F-03-02.
The target process was no prior manual process Vs Training Provided
Target process was no prior

manual process
Yes
No
Implementers of the
process-centered
environment
Count
36
13
Mean Rank
26.40
21.12
End-users of the
automated process
Count
36
13
Mean Rank
24.72
25.77
Total
Chi-Square
DF
P-Value
Result
49
1.588
0.208
NS
49
0.071
0.790
NS
Table ST-HYP-09-17: The target process was no prior manual process Vs Training
provided
From the above table, it is observed that The target process was no prior manual
process has no significant influence on any of the two kinds of training provided to
support the Process Automation tool and hence it can be concluded that The target
process was no prior manual process has no significant influence on the kinds of
training provided to support the Process Automation tool.
Analysis H9.18:
329


data depicted in figures GRP-D-10-01 and GRP-F-04 to GRP-F-12.
The target process was no prior manual process Vs Automated Process design/development approach
Automated process
approach
manual process
Count
users
Yes
No
36
13
25.71
23.04

with end-users
Count
36
13
Mean Rank
21.85
33.73
End-user screens
Count
34
13
Mean Rank
22.74
27.31
Process simulations
Count
36
13
Mean Rank
24.82
25.50

effectiveness
Count
36
13
Mean Rank
24.32
26.88

accepting
Count
36
13
Mean Rank
24.65
25.96
Count
36
13
Mean Rank
25.76
22.88
End-users make
Count
36
13
Mean Rank
26.00
22.23

automated process
Count
36
13
Mean Rank
25.60
23.35
Total
Chi-Square
DF
P-Value
Result
49
0.428
0.513
NS
49
8.808
0.003
Significant
47
1.292
0.256
NS
49
0.027
0.870
NS
49
0.444
0.505
NS
49
0.092
0.761
NS
49
0.495
0.482
NS
49
0.813
0.367
NS
49
0.289
0.591
NS
Table ST-HYP-09-18: The target process was no prior manual process Vs Automated
Overall, it is observed that The target process was no prior manual process has
no significant influence on eight out of the nine Automated Process design/development
approaches. However, The target process was no prior manual process has a significant
influence on one of the nine Automated Process design/development approaches namely
Process design reviewed with end-users. Hence it can be concluded that the target
process was no prior manual process has no major influence on Automated Process
330
Analysis H9.19:


Fear of job loss
Fear of change
definition
data depicted in figures GRP-D-10-01 and GRP-F-13-01 to GRP-F-13-06.
The target process was no prior manual process Vs Resistance to process automation
automation
externally imposed

manual process
Yes
No
Count
36
13
Mean Rank
23.90
28.04
Count
36
13
Mean Rank
24.65
25.96
Fear of job loss

Count
36
13
Mean Rank
24.63
26.04
Count
36
13
Mean Rank
24.67
25.92
Fear of change
The perception that
controlling
were not consulted
definition
Count
36
13
Mean Rank
25.92
22.46
Count
36
13
Mean Rank
24.63
26.04
Total
Chi-Square
DF
P-Value
Result
49
0.913
0.339
NS
49
0.088
0.767
NS
49
0.108
0.742
NS
49
0.096
0.757
NS
49
0.656
0.418
NS
49
0.108
0.742
NS
Table ST-HYP-09-19: The target process was no prior manual process Vs Resistance to
Process Automation
process has no significant influence on any of the reasons for resistance to Process
Automation and hence it can be concluded that The target process was no prior
331
manual process has no significant influence on the reasons for resistance to Process
Automation.
Analysis H9.20:
activities:


data depicted in figures GRP-D-10-01 and GRP-F-14 to GRP-F-20.
The target process was no prior manual process Vs Management Support
Management support
activities

manual process
supportive
Count
36
13
Mean Rank
24.56
26.23
supportive
Count
34
13
Mean Rank
24.51
22.65
plan was written
Count
34
13
Mean Rank
23.06
26.46

to by management
Count
34
13
Mean Rank
23.38
25.62

management
Count
34
13
Mean Rank
21.60
30.27
Yes
No
Total
Chi-Square
DF
P-Value
Result
49
0.169
0.681
NS
47
0.240
0.624
NS
47
0.739
0.390
NS
47
0.323
0.570
NS
47
4.717
0.030
Significant
Table ST-HYP-09-20: The target process was no prior manual process Vs Management
process has no significant influence on four out of the five activities of Management
support. However, The target process was no prior manual process has a significant
influence on one out of five activities of Management support namely Design reviewed
with management. Hence it can be concluded that the target process was no prior
332
manual process has little significant influence on the Management support to

Process Automation initiative.
Analysis H9.21:
support:
Process definition was more challenging than first thought Vs Training Provided
Process definition was

challenging
Implementers of the
process-centered
environment
End-users of the
automated process
Yes
No
Count
54
15
Mean Rank
34.19
37.90
Count
54
15
Mean Rank
35.46
33.33
Total
Chi-Square
DF
P-Value
Result
69
0.479
0.489
NS
69
0.160
0.689
NS
Training provided
than first thought has no significant influence on any of the two kinds of training
provided to support the Process Automation tool namely End-users of the automated
process and hence it can be concluded that Process definition was more challenging
than first thought has no significant influence on the kinds of training provided to
support the Process Automation tool.
Analysis H9.22:
333



Process definition was more challenging than first thought Vs Automated Process design/development approach
Automated process
approach
challenging
Count
users
with end-users
Yes
No
52
15
32.13
40.50
Count
52
15
Mean Rank
33.82
34.63
End-user screens
Count
50
15
Mean Rank
34.21
28.97
Process simulations
Count
52
15
Mean Rank
34.14
33.50

effectiveness
Count
54
15
Mean Rank
33.56
40.20

accepting
Count
54
15
Mean Rank
34.74
35.93
Count
54
15
Mean Rank
36.24
30.53
End-users make
Count
54
15
Mean Rank
33.94
38.83

automated process
Count
54
15
Mean Rank
34.15
38.07
Total
Chi-Square
DF
P-Value
Result
67
2.787
0.095
NS
67
0.028
0.868
NS
65
1.004
0.316
NS
67
0.016
0.901
NS
69
1.681
0.195
NS
69
0.047
0.828
NS
69
1.174
0.279
NS
69
0.866
0.352
NS
69
0.549
0.459
NS
334
than first thought has no significant influence on any of the Automated Process
design/development approaches and hence it can be concluded that Process definition
was more challenging than first thought has no significant influence on Automated
Process design/development approach.
Analysis H9.23:


Fear of job loss
Fear of change
definition
Process definition was more challenging than first thought Vs Resistance to process automation
automation
externally imposed

challenging
Yes
No
Count
54
15
Mean Rank
33.83
39.20
Count
54
15
Mean Rank
34.44
37.03
Fear of job loss

Count
54
15
Mean Rank
37.38
26.43
Count
54
15
Mean Rank
36.02
31.33
Fear of change
The perception that
controlling
were not consulted
definition
Count
54
15
Mean Rank
34.50
36.80
Count
54
15
Mean Rank
36.14
30.90
Total
Chi-Square
DF
P-Value
Result
69
0.956
0.328
NS
69
0.213
0.645
NS
69
3.971
0.046
Significant
69
0.760
0.383
NS
69
0.177
0.674
NS
69
0.939
0.332
NS
335
than first thought has no significant influence on five out of the six reasons for
resistance to Process Automation. However, Process definition was more challenging
than first thought has a significant influence on one of the six reasons for resistance to
Process Automation namely Fear of change . Hence it can be concluded that Process
definition was more challenging than first thought has little significant influence on
the reasons for resistance to Process Automation.
Analysis H9.24:
activities:


Process definition was more challenging than first thought Vs Management Support
Management support
activities

challenging
Yes
No
supportive
Count
54
15
Mean Rank
33.25
41.30
supportive
Count
52
15
Mean Rank
34.89
30.90
plan was written
Count
52
15
Mean Rank
34.30
32.97

to by management
Count
52
15
Mean Rank
34.77
31.33

management
Count
52
15
Mean Rank
31.25
43.53
Total
Chi-Square
DF
P-Value
Result
69
2.455
0.117
NS
67
0.655
0.418
NS
67
0.071
0.790
NS
67
0.479
0.489
NS
67
5.705
0.017
Significant
336
than first thought has no significant influence on four out of the five activities of
Management support. However, Process definition was more challenging than first
thought has significant influence on one out of five activities of Management support
namely Design reviewed with management. Hence it can be concluded that Process
definition was more challenging than first thought has little significant influence on
the Management support to Process Automation initiative.
Hypothesis IX: Summary and Conclusion
independent variable Process Characteristics that significantly influence few factors
of the dependent variable Transition and Adoption. Therefore, the hypothesis is
Characteristics has a relation to Transition and Adoption, it does not have a significant
influence on Transition and Adoption.
Hypothesis X: Process characteristics has no significant influence on Impacts and

Insights

Characteristics) and 7 questions from Group G (Impacts and Insights) are analyzed.
presented here.
Analysis H10.01:
337

methods
2. Independent Variable - Group G Question 1: To date, I consider the
process automation project to be a success
data depicted in figures GRP-D-02-03, GRP-D-02-05 & GRP-D-02-06 and GRPG-01.
Projects routinely use documented processes to perform their tasks Vs Process Automation project was a
success
Projects use
documented
processes
Process Automation a
Success
Yes
No
Count
66
Mean Rank
35.05
48.50
Total
Chi-Square
DF
P-Value
Result
71
2.673
0.102
NS

tasks Vs Process Automation project is a success
From the above table, it can be concluded that Projects routinely use
documented processes to perform their tasks has no significant influence on Process
Automation project is a success.
Projects routinely track and meet cost estimates Vs Process Automation project was a success
Projects meet
cost estimates
Success
Yes
No
Count
54
14
Mean Rank
34.09
36.07
Total
Chi-Square
DF
P-Value
Result
68
0.155
0.694
NS
Table ST-HYP-10-01-02: Projects routinely track and meet cost estimates Vs Process
Automation project is a success
estimates has no significant influence on Process Automation project is a success and
hence it can be concluded that Projects routinely track and meet cost estimates has no
significant influence on Process Automation project is a success.
338
Projects routinely provide appropriate training on tools and methods Vs Process Automation project was a
success
Projeccts provide
training on tools
and methods
Success
Yes
No
Count
52
15
Mean Rank
37.03
23.50
Total
Chi-Square
DF
P-Value
Result
67
8.586
0.003
Significant

methods Vs Process Automation project is a success
training on tools and methods has a significant influence on Process Automation project
is a success and hence it can be concluded that Projects routinely provide appropriate
training on tools and methods has a significant influence on Process Automation
project is a success.
Analysis H10.02:
methods
2. Independent Variable - Group G Question 2 - 4: Process Automation
outcomes

Improve end-user productivity

Improve product quality
Manage projects more effectively
Improve communication between end-users
Improve end-user job satisfaction
Improve end-user team-building
Helps reduce tedium
Helps prevent errors
Supports administrative efforts
Provides useful process guidance
Provides timely status information
Provides useful metric data
339
Reduces costs
Helps to enforce defined process
Test Results: The two variables namely Project Routine Activities and Process
Automation Outcomes have multiple factors and hence a two-dimensional
analysis is conducted. Below tables are the result of Kruskal-Wallis Test
conducted on data depicted in figures GRP-D-02-03, GRP-D-02-05 & GRP-D-0206 and GRP-G-02 to GRP-G-04.
Projects routinely use documented processes to perform their tasks Vs Process Automation outcome
Projeccts use
documented
processes
Yes
No
Improve end-user
productivity
Count
66
Mean Rank
36.06
35.20
Improve product
quality
Count
66
Mean Rank
34.94
50.00
Manage projects more

effectively
Count
66
Mean Rank
33.90
63.70
Improve
communication
between end-users
Count
66
Mean Rank
35.48
42.80
Improve end-user job

satisfaction
Count
66
Mean Rank
35.68
40.20
Improve end-user
team-building
Count
66
Mean Rank
34.46
56.30
Helps reduce tedium
Count
66
Mean Rank
37.14
20.90
Count
66
Mean Rank
36.11
34.60
Supports
administrative efforts
Count
66
Mean Rank
36.86
24.60
Provides useful
process guidance
Count
66
Mean Rank
36.17
33.70
Provides timely status

information
Count
66
Mean Rank
36.60
28.10
Provides useful metric

data
Count
66
Mean Rank
35.80
38.70
Reduces costs
Helps to enforce
defined process
Count
66
Mean Rank
36.99
22.90
Count
66
Mean Rank
35.62
41.00
Total
Chi-Square
DF
P-Value
Result
71
0.011
0.917
NS
71
3.138
0.076
NS
71
11.700
0.001
Significant
71
0.726
0.394
NS
71
0.264
0.607
NS
71
5.761
0.016
Significant
71
3.900
0.048
Significant
71
0.032
0.858
NS
71
2.191
0.139
NS
71
0.093
0.760
NS
71
1.076
0.300
NS
71
0.119
0.730
NS
71
2.653
0.103
NS
71
0.420
0.517
NS

tasks Vs Process Automation outcomes
340
processes to perform their tasks has no significant influence on eleven out of the
fourteen Process Automation outcomes. However, Projects routinely use documented
processes to perform their tasks has significant influence on three out of fourteen
Process Automation outcomes namely Manage projects more effectively, Improve
end-user team-building and Helps reduce tedium. Hence it can be concluded that
Projects routinely use documented processes to perform their tasks has some
significant influence on the Process Automation outcomes.
Projects routinely track and meet cost estimates Vs Process Automation outcome
Projects meet
cost estimates
Yes
No
Improve end-user
productivity
Count
54
14
Mean Rank
31.83
44.79
Improve product
quality
Count
54
14
Mean Rank
34.56
34.29

effectively
Count
54
14
Mean Rank
32.72
41.36
Improve
communication
between end-users
Count
54
14
Mean Rank
33.87
36.93

satisfaction
Count
54
14
Mean Rank
32.07
43.86
Improve end-user
team-building
Count
54
14
Mean Rank
33.94
36.64
Helps reduce tedium
Count
54
14
Mean Rank
33.26
39.29
Count
54
14
Mean Rank
36.52
26.71
Supports
Count
54
14
Mean Rank
34.39
34.93
Provides useful
process guidance
Count
54
14
Mean Rank
34.09
36.07

information
Count
54
14
Mean Rank
34.22
35.57

data
Count
54
14
Mean Rank
36.59
26.43
Count
54
14
Mean Rank
32.93
40.57
Reduces costs
Helps to enforce
defined process
Count
54
14
Mean Rank
35.19
31.86
Total
Chi-Square
DF
P-Value
Result
68
6.440
0.011
Significant
68
0.003
0.959
NS
68
2.610
0.106
NS
68
0.336
0.562
NS
68
4.734
0.030
Significant
68
0.233
0.629
NS
68
1.383
0.240
NS
68
3.589
0.058
NS
68
0.011
0.916
NS
68
0.155
0.694
NS
68
0.072
0.788
NS
68
3.807
0.051
NS
68
2.029
0.154
NS
68
0.414
0.520
NS
Table ST-HYP-10-02-02: Projects routinely track and meet cost estimates Vs Process
Automation outcomes
341
estimates has no significant influence on ten out of the fourteen Process Automation
outcomes. However, Projects routinely track and meet cost estimates has a significant
influence on two out of fourteen Process Automation outcomes namely Improve enduser productivity and Improve end-user job satisfaction. Hence it can be concluded
that Projects routinely track and meet cost estimates has little significant influence
on the Process Automation outcomes.
Projects routinely provide appropriate training on tools and methods Vs Process Automation outcome
Projeccts provide
training on tools
and methods
Yes
No
Improve end-user
productivity
Count
52
Mean Rank
30.12
24.17
Improve product
quality
Count
52
15
Mean Rank
37.30
22.57

effectively
Count
52
15
Mean Rank
36.57
25.10
Improve
communication
between end-users
Count
52
15
Mean Rank
37.61
21.50

satisfaction
Count
52
15
Mean Rank
30.20
47.17
Improve end-user
team-building
Count
52
15
Mean Rank
30.61
45.77
Helps reduce tedium
Count
52
15
Mean Rank
32.39
39.57
Count
52
15
Mean Rank
30.92
44.67
Supports
Count
52
15
Mean Rank
30.91
44.70
Provides useful
process guidance
Count
52
15
Mean Rank
31.10
44.07

information
Count
52
15
Mean Rank
31.88
41.33

data
Count
52
15
Mean Rank
32.76
38.30
Count
52
15
Mean Rank
35.93
27.30
Reduces costs
Helps to enforce
defined process
Count
52
15
Mean Rank
35.66
28.23
Total
Chi-Square
DF
P-Value
Result
58
0.764
0.382
NS
67
8.354
0.004
Significant
67
4.689
0.030
Significant
67
10.941
0.001
Significant
67
9.767
0.002
Significant
67
7.789
0.005
Significant
67
1.872
0.171
NS
67
6.390
0.011
Significant
67
6.701
0.010
Significant
67
5.640
0.018
Significant
67
2.925
0.087
NS
67
1.010
0.315
NS
67
2.541
0.111
NS
67
1.856
0.173
NS
342

methods Vs Process Automation outcomes
training on tools and methods has no significant influence on six out of the fourteen
Process Automation outcomes. However, Projects routinely provide appropriate training
on tools and methods has significant influence on eight out of fourteen Process
Automation outcomes namely "Improve product quality", "Manage projects more
effectively", "Improve communication between end-users", "Improve end-user job
satisfaction", "Improve end-user team-building", "Helps prevent errors", "Supports
administrative efforts" and "Provides useful process guidance". Hence it can be
concluded that Projects routinely provide appropriate training on tools and methods
has some significant influence on the Process Automation outcomes.
Analysis H10.03:
methods
2. Independent Variable - Group G Question 5: The technical
implementation was more challenging than first thought
data depicted in figures GRP-D-02-03, GRP-D-02-05 & GRP-D-02-06 and GRPG-05.
343
Projects routinely use documented processes to perform their tasks Vs Technical implementation was more
challenging
Projeccts use
documented
processes
Technical
implementation was
challenging
Yes
No
Count
66
Mean Rank
34.56
55.00
Total
Chi-Square
DF
P-Value
Result
71
5.809
0.016
Significant

tasks Vs The technical implementation was challenging
processes to perform their tasks has a significant influence on The technical
implementation was challenging and hence it can be concluded that Projects routinely
use documented processes to perform their tasks has a significant influence on The
technical implementation was challenging.
Projects routinely track and meet cost estimates Vs Technical implementation was more challenging
Projects meet
cost estimates
Technical
implementation was
challenging
Yes
No
Count
54
14
Mean Rank
34.65
33.93
Total
Chi-Square
DF
P-Value
Result
68
0.018
0.893
NS
Table ST-HYP-10-03-02: Projects routinely track and meet cost estimates Vs The
estimates has no significant influence on The technical implementation was challenging
and hence it can be concluded that Projects routinely track and meet cost estimates
has no significant influence on The technical implementation was challenging.
Projects routinely provide appropriate training on tools and methods Vs Technical implementation was more
challenging
Technical
implementation was
challenging
Projeccts provide
training on tools
and methods
Yes
No
Count
50
15
Mean Rank
29.60
44.33
Total
Chi-Square
DF
P-Value
Result
65
7.636
0.006
Significant

methods Vs The technical implementation was challenging
344
training on tools and methods has a significant influence on The technical
implementation was challenging and hence it can be concluded that Projects routinely
provide appropriate training on tools and methods has a significant influence on
The technical implementation was challenging.
Analysis H10.04:
data depicted in figures GRP-D-07 and GRP-G-01.
The process design is clearly and completely documented Vs Process Automation project was a success
The process
design is
documented
Success
Yes
No
Count
55
11
Mean Rank
32.95
36.27
Total
Chi-Square
DF
P-Value
Result
66
0.372
0.542
NS
Table ST-HYP-10-04: The process design is clearly and completely documented Vs Process
From the above table, it can be concluded that The process design is clearly and
completely documented has no significant influence on Process Automation project
is a success.
Analysis H10.05:
345

outcomes


Helps reduce tedium
Reduces costs
data depicted in figures GRP-D-07 and GRP-G-02 to GRP-G-04.
346
The process design is clearly and completely documented Vs Process Automation outcome
The process
design is
documented
Yes
No
Improve end-user
productivity
Count
55
11
Mean Rank
32.50
38.50
Improve product
quality
Count
55
11
Mean Rank
32.23
39.86

effectively
Count
55
11
Mean Rank
31.82
41.91
Improve
communication
between end-users
Count
55
11
Mean Rank
32.75
37.23

satisfaction
Count
55
11
Mean Rank
34.08
30.59
Improve end-user
team-building
Count
55
11
Mean Rank
33.93
31.36
Helps reduce tedium
Count
55
11
Mean Rank
32.00
41.00
Count
55
11
Mean Rank
33.75
32.23
Supports
Count
55
11
Mean Rank
33.70
32.50
Provides useful
process guidance
Count
55
11
Mean Rank
33.33
34.36

information
Count
55
11
Mean Rank
33.20
35.00

data
Count
55
11
Mean Rank
33.33
34.36
Reduces costs
Helps to enforce
defined process
Count
55
11
Mean Rank
33.37
34.14
Count
55
11
Mean Rank
35.82
21.91
Total
Chi-Square
DF
P-Value
Result
66
1.222
0.269
NS
66
1.843
0.175
NS
66
3.090
0.079
NS
66
0.604
0.437
NS
66
0.356
0.551
NS
66
0.182
0.670
NS
66
2.778
0.096
NS
66
0.076
0.782
NS
66
0.048
0.827
NS
66
0.035
0.851
NS
66
0.111
0.739
NS
66
0.035
0.851
NS
66
0.018
0.893
NS
66
6.334
0.012
Significant
Table ST-HYP-10-05: The process design is clearly and completely documented Vs Process
Automation outcomes
completely documented has significant influence on thirteen out of the fourteen Process
Automation outcomes. However, The process design is clearly and completely
documented has significant influence on only one of the fourteen Process Automation
outcomes namely Helps to enforce defined process. Hence it can be concluded that The
process design is clearly and completely documented has little significant influence
on the Process Automation outcomes.
347
Analysis H10.06:
The process design is clearly and completely documented Vs Technical implementation was more
challenging
The process
design is
documented
Technical
implementation was
challenging
Yes
No
Count
55
11
Mean Rank
34.94
26.32
Total
Chi-Square
DF
P-Value
Result
66
2.370
0.124
NS
Table ST-HYP-10-06: The process design is clearly and completely documented Vs The
From the above table, it can be concluded that The process design is clearly and
completely
documented
has
no
significant
influence
on
The
technical
implementation was challenging.
Analysis H10.07:
348
Functional requirements were used to define tools embedded in the process Vs Process Automation project
was a success
Functional
requirements
used to define
tools
Success
Yes
No
Count
65
Mean Rank
36.60
44.00
Total
Chi-Square
DF
P-Value
Result
74
1.259
0.262
NS
process Vs Process Automation project is a success
From the above table, it can be concluded that Functional requirements were
used to define tools embedded in the process has no significant influence on Process
Automation project is a success.
Analysis H10.08:
outcomes


Helps reduce tedium
Reduces costs
349
Functional requirements were used to define tools embedded in the process Vs Process Automation outcome
Functional
requirements
used to define
tools
Yes
No
Improve end-user
productivity
Count
65
Mean Rank
36.12
47.50
Improve product
quality
Count
65
Mean Rank
34.70
57.72

effectively
Count
65
Mean Rank
36.29
46.22
Improve
communication
between end-users
Count
65
Mean Rank
36.24
46.61

satisfaction
Count
65
Mean Rank
39.21
25.17
Improve end-user
team-building
Count
65
Mean Rank
37.02
41.00
Helps reduce tedium
Count
65
Mean Rank
35.77
50.00
Count
65
Mean Rank
36.21
46.83
Supports
Count
65
Mean Rank
38.70
28.83
Provides useful
process guidance
Count
65
Mean Rank
36.26
46.44

information
Count
65
Mean Rank
37.94
34.33

data
Count
65
Mean Rank
35.72
50.33
Count
65
Mean Rank
37.32
38.83
Reduces costs
Helps to enforce
defined process
Count
65
Mean Rank
37.82
35.22
Total
Chi-Square
DF
P-Value
Result
74
2.951
0.086
NS
74
11.499
0.001
Significant
74
2.031
0.154
NS
74
2.305
0.129
NS
74
3.934
0.047
Significant
74
0.306
0.580
NS
74
4.764
0.029
Significant
74
2.529
0.112
NS
74
2.260
0.133
NS
74
2.513
0.113
NS
74
0.304
0.581
NS
74
4.743
0.029
Significant
74
0.048
0.826
NS
74
0.151
0.697
NS
process Vs Process Automation outcomes
define tools embedded in the process has no significant influence on ten out of the
fourteen Process Automation outcomes. However, Functional requirements were used to
define tools embedded in the process has significant influence on four out of fourteen
Process Automation outcomes namely Improve product quality, Improve end-user job
satisfaction, Helps reduce tedium and Provides useful metrics data. Hence it can be
concluded that Functional requirements were used to define tools embedded in the
process has some significant influence on the Process Automation outcomes.
350
Analysis H10.09:
Functional requirements were used to define tools embedded in the process Vs Technical implementation
was more challenging
Functional
requirements
used to define
tools
Technical
implementation was
challenging
Yes
No
Count
65
Mean Rank
37.92
34.50
Total
Chi-Square
DF
P-Value
Result
74
0.255
0.614
NS
process Vs The technical implementation was challenging
From the above table, it can be concluded that Functional requirements were
used to define tools embedded in the process has no significant influence on The
technical implementation was challenging.
Analysis H10.10:
351
Metrics requirements are specified for the process Vs Process Automation project was a success
Metrics
requirements
specified
Success
Yes
No
Count
33
38
Mean Rank
36.14
46.62
Total
Chi-Square
DF
P-Value
Result
83
4.606
0.100
NS
Table ST-HYP-10-10: Metrics requirements are specified for the process Vs Process
From the above table, it can be concluded that Metrics requirements are
specified for the process has no significant influence on Process Automation project
is a success.
Analysis H10.11:
outcomes


Helps reduce tedium
Reduces costs
352
Metrics requirements are specified for the process Vs Process Automation outcome
Metrics
requirements
specified
Yes
No
Improve end-user
productivity
Count
33
38
Mean Rank
39.20
44.28
Improve product
quality
Count
33
38
Mean Rank
31.77
53.36

effectively
Count
33
38
Mean Rank
38.24
45.95
Improve
communication
between end-users
Count
33
38
Mean Rank
39.65
49.33

satisfaction
Count
33
38
Mean Rank
37.14
44.59
Improve end-user
team-building
Count
33
38
Mean Rank
33.83
50.72
Helps reduce tedium
Count
33
38
Mean Rank
43.82
42.32
Count
33
38
Mean Rank
37.15
51.71
Supports
Count
33
38
Mean Rank
45.91
41.34
Provides useful
process guidance
Count
33
38
Mean Rank
43.73
40.34

information
Count
33
38
Mean Rank
39.09
43.66

data
Count
33
38
Mean Rank
38.18
49.82
Reduces costs
Helps to enforce
defined process
Count
33
38
Mean Rank
41.18
41.97
Count
33
38
Mean Rank
39.89
45.67
Total
Chi-Square
DF
P-Value
Result
83
1.096
0.578
NS
83
19.964
0.000
Significant
83
2.296
0.317
NS
83
11.803
0.003
Significant
83
2.722
0.256
NS
83
10.349
0.006
Significant
83
1.264
0.532
NS
83
17.741
0.000
Significant
83
3.286
0.193
NS
83
0.492
0.782
NS
83
1.108
0.575
NS
83
11.747
0.003
Significant
83
0.186
0.911
NS
83
2.431
0.296
NS
Table ST-HYP-10-11: Metrics requirements are specified for the process Vs Process
Automation outcomes
the process has significant influence on nine out of the fourteen Process Automation
outcomes. However, Metrics requirements are specified for the process has significant
influence on five out of fourteen Process Automation outcomes namely Improve product
quality, Improve communication between end-users, Improve end-user teambuilding, Helps prevent errors and Provides useful metrics data. Hence it can be
concluded that Metrics requirements are specified for the process has some
significant influence on the Process Automation outcomes.
353
Analysis H10.12:
Metrics requirements are specified for the process Vs Technical implementation was more challenging
Metrics
requirements
specified
Technical
implementation was
challenging
Yes
No
Count
33
38
Mean Rank
38.94
42.82
Total
Chi-Square
DF
P-Value
Result
83
1.625
0.444
NS
Table ST-HYP-10-12: Metrics requirements are specified for the process Vs The technical
From the above table, it can be concluded that Metrics requirements are
specified for the process has no significant influence on The technical
Analysis H10.13:
data depicted in figures GRP-D-10-01 and GRP-G-01.
354
The target process was no prior manual process Vs Process Automation project was a success
Target process
was no prior
manual process
Success
Yes
No
Count
36
13
Mean Rank
21.40
34.96
Total
Chi-Square
DF
P-Value
Result
49
11.797
0.001
Significant
Table ST-HYP-10-13: The target process was no prior manual process Vs Process
From the above table, it can be concluded that The target process was no prior
manual process has a significant influence on Process Automation project is a
success.
Analysis H10.14:
outcomes


Helps reduce tedium
costs
data depicted in figures GRP-D-10-01 and GRP-G-02 to GRP-G-04.
355
The target process was no prior manual process Vs Process Automation outcome
Target process
was no prior
manual process
Yes
No
Improve end-user
productivity
Count
36
13
Mean Rank
22.93
30.73
Improve product
quality
Count
36
13
Mean Rank
23.01
30.50

effectively
Count
36
13
Mean Rank
24.29
26.96
Improve
communication
between end-users
Count
36
13
Mean Rank
22.54
31.81

satisfaction
Count
36
13
Mean Rank
24.90
25.27
Improve end-user
team-building
Count
36
13
Mean Rank
23.94
27.92
Helps reduce tedium
Count
36
13
Mean Rank
24.29
26.96
Count
36
13
Mean Rank
24.72
25.77
Supports
Count
36
13
Mean Rank
25.75
22.92
Provides useful
process guidance
Count
36
13
Mean Rank
24.56
26.23

information
Count
36
13
Mean Rank
25.39
23.92

data
Count
36
13
Mean Rank
23.86
28.15
Count
36
13
Mean Rank
24.88
25.35
Reduces costs
Helps to enforce
defined process
Count
36
13
Mean Rank
25.03
24.92
Total
Chi-Square
DF
P-Value
Result
49
3.995
0.046
Significant
49
3.398
0.065
NS
49
0.416
0.519
NS
49
4.967
0.026
Significant
49
0.007
0.932
NS
49
0.812
0.367
NS
49
0.468
0.494
NS
49
0.071
0.790
NS
49
0.500
0.479
NS
49
0.169
0.681
NS
49
0.137
0.712
NS
49
1.160
0.282
NS
49
0.013
0.909
NS
49
0.001
0.979
NS
Table ST-HYP-10-14: The target process was no prior manual process Vs Process
Automation outcomes
process has no significant influence on twelve out of the fourteen Process Automation
outcomes. However, The target process was no prior manual process has significant
influence on two out of fourteen Process Automation outcomes namely Improve endproductivity and Improve communication between end-users. Hence it can be
concluded that the target process was no prior manual process has little significant
influence on the Process Automation outcomes.
356
Analysis H10.15:
data depicted in figures GRP-D-10-01 and GRP-G-05.
The target process was no prior manual process Vs Technical implementation was more challenging
Target process
was no prior
manual process
Technical
implementation was
challenging
Yes
No
Count
36
13
Mean Rank
25.58
23.38
Total
Chi-Square
DF
P-Value
Result
49
0.284
0.594
NS
Table ST-HYP-10-15: The target process was no prior manual process Vs The technical
From the above table, it can be concluded that The target process was no prior
manual process has no significant influence on The technical implementation was
challenging.
Analysis H10.16:
357
Process definition was more challenging than first thought Vs Process Automation project was a success
Process
definition was
challenging
Success
Yes
No
Count
54
15
Mean Rank
31.61
47.20
Total
Chi-Square
DF
P-Value
Result
69
9.749
0.002
Significant
From the above table, it can be concluded that Process definition was more
challenging than first thought has a significant influence on Process Automation
project is a success.
Analysis H10.17:
outcomes


Helps reduce tedium
Reduces costs
358
Process definition was more challenging than first thought Vs Process Automation outcome
Process
definition was
challenging
Yes
No
Improve end-user
productivity
Count
54
15
Mean Rank
33.53
40.30
Improve product
quality
Count
54
15
Mean Rank
30.94
49.60

effectively
Count
54
15
Mean Rank
33.47
40.50
Improve
communication
between end-users
Count
54
15
Mean Rank
31.74
46.73

satisfaction
Count
54
15
Mean Rank
34.65
36.27
Improve end-user
team-building
Count
54
15
Mean Rank
33.84
39.17
Helps reduce tedium
Count
54
15
Mean Rank
33.05
42.03
Count
54
15
Mean Rank
31.76
46.67
Supports
Count
54
15
Mean Rank
33.39
40.80
Provides useful
process guidance
Count
54
15
Mean Rank
33.71
39.63

information
Count
54
15
Mean Rank
33.14
41.70

data
Count
54
15
Mean Rank
32.75
43.10
Reduces costs
Helps to enforce
defined process
Count
54
15
Mean Rank
34.05
38.43
Count
54
15
Mean Rank
33.43
40.67
Total
Chi-Square
DF
P-Value
Result
69
1.815
0.178
NS
69
12.835
0.000
Significant
69
1.730
0.188
NS
69
8.039
0.005
Significant
69
0.089
0.765
NS
69
0.915
0.339
NS
69
3.240
0.072
NS
69
8.664
0.003
Significant
69
2.172
0.141
NS
69
1.453
0.228
NS
69
2.954
0.086
NS
69
4.071
0.044
Significant
69
0.686
0.407
NS
69
2.011
0.156
NS
than first thought has no significant influence on ten out of the fourteen Process
Automation outcomes. However, Process definition was more challenging than first
thought has significant influence on four out of fourteen Process Automation outcomes
namely Improve product quality, Improve communication between end-users, Helps
prevent errors and Provides useful metrics data. Hence it can be concluded that
Process definition was more challenging than first thought has some significant
influence on the Process Automation outcomes.
359
Analysis H10.18:
Process definition was more challenging than first thought Vs Technical implementation was more
challenging
Process
definition was
challenging
Technical
implementation was
challenging
Yes
No
Count
54
15
Mean Rank
33.95
38.77
Total
Chi-Square
DF
P-Value
Result
69
0.892
0.345
NS
Table ST-HYP-10-18: Process definition was more challenging than first thought Vs The
From the above table, it can be concluded that Process definition was more
challenging than first thought has no significant influence on The technical
Hypothesis X: Summary and Conclusion
From the above statistical analysis, it is understood that there are few factors of
the independent variable Process Characteristics that significantly influence few
factors of the dependent variable Impacts and Insights. Therefore, the hypothesis is
Characteristics has a relation to Impacts and Insights, it does not have a significant
influence on Impacts and Insights.
360
Hypothesis XI: The Development Technology has no significant influence on

To substantiate this hypothesis with data, 6 questions from Group E

(Development Technology) and 24 questions from Group F (Transition and Adoption)
are analyzed. However, since all results did not yield any correlation, only relevant
results are presented here.
Analysis H11.1:
1. Independent Variable - Group E Question 1: With which automation
tool(s) are you implementing process automation?
2. Independent Variable - Group F Question 1: How long (in months) has it
taken to transition the process to the production environment?
depicted in figures GRP-E-01 and GRP-F-01.
With which automation tool(s) are you implementing process automation? Vs How long (in months) has it taken to transition the process to the
production environment?
Automation
tools
Total
Procured and
Customized
In-house
developed
Count
% within
Count
% within
Count
% within
How long (in months) has it taken to transition the process to the production
Not
0-2
3-6
7-12
13-24
Over 24
completed
0
2
4
15
11
2
0.00%
5.90%
11.80%
44.10%
32.40%
5.90%
8
16
9
8
1
0
19.00%
38.10%
21.40%
19.00%
2.40%
0.00%
8
18
13
23
12
2
10.50%
23.70%
17.10%
30.30%
15.80%
2.60%
Total
ChiSquare
DF
P-Value
Result
34
100.00%
42
100.00%
76
100.00%
32.797
Significant
Table ST-HYP-11-01: Automation tool used for implementing process automation Vs Time
taken to transition the process to the production environment
From the above table, it can be concluded that Automation tool used for
implementing process automation has a significant influence on Time taken to
transition the process to the production environment.
361
Analysis H11.2:
2. Independent Variable - Group F Question 21: The automation initiative
came from
With which automation tool(s) are you implementing process automation? Vs The automation initiative came from:
The automation initiative came from:
Technical
staff
Automation tool
used for
implementation
Count
Procured and
Customized
% within
In-house
developed
% within
Count
Count
Total
% within
Management
Total
A bit of
booth
40
40
100.00%
0.00%
0.00%
100.00%
14
11
18
43
32.60%
25.60%
41.90%
100.00%
54
11
18
83
65.10%
13.30%
21.70%
100.00%
Chi-Square
DF
P-Value
Result
41.464
Significant
Table ST-HYP-11-02: Automation tool used for implementing process automation Vs The
automation initiative came from
implementing process automation has a significant influence on the automation
initiative came from.
Analysis H11.3:
2. Independent Variable - Group F Question 22-23: Process Automation
Strategy:
A documented transition strategy was developed
A prototyping strategy is being used for implementation
362
data depicted in figures GRP-E-01 and GRP-F-22 & GRP-F-23.
With which automation tool(s) are you implementing process automation? Vs Process
Automation Strategy
Automation tool(s) in implementing process

automation
Procured and
A documented transition
Customized
strategy was developed
In-house
developed
Procured and
A prototyping strategy is being Customized
used for implementation
In-house
developed
Mean Rank
46.94
Chi-Square
DF
P-Value
Result
4.157
0.041
Significant
3.029
0.082
NS
37.41
46.36
37.94
Table ST-HYP-11-03: Automation tool used for implementing process automation Vs

Process Automation Strategy
implementing process automation has no significant influence on one of the two Process
Automation strategies. However, Automation tool used for implementing process
automation has a significant influence on the other of the two Process Automation
strategies namely A documented transition strategy was developed. Hence it can be
concluded that Automation tool used for implementing process automation has
partial significant influence on the Process Automation strategies.
Analysis H11.4:
2. Independent Variable - Group F Question 24: The process model is
being implemented
363
With which automation tool(s) are you implementing process automation? Vs The process model is being implemented:
The process model is being
implemented:
Multiple
All at once
Automation tool(s) in
implementing process
automation
Count
Procured and
Customized
% within
In-house
developed
% within
Count
Count
Total
% within
increment
phases
Total
Others
30
34
88.20%
11.80%
0.00%
100.00%
38
41
0.00%
92.70%
7.30%
100.00%
30
42
75
40.00%
56.00%
4.00%
100.00%
Chi-Square
DF
P-Value
Result
60.397
Significant
Table ST-HYP-11-04: Automation tool used for implementing process automation Vs The
process model is being implemented
implementing process automation has a significant influence on the process model
being implemented.
Analysis H11.5:
1. Independent Variable - Group E Question 2: Strengths of Process
Automation
2. Independent Variable - Group F Question 8: The automated process
improves the effectiveness of end-users in performing their tasks
Test applied: Spearmans Rho Correlation
Test Results: The below table is the result of Spearmans Rho Correlation Test
conducted on data depicted in figures GRP-E-02-01 to GRP-02-12 and GRP-F08.
364
Strengths of Process Automation Tool Vs The automated process improves the

effectiveness of end-users in performing their tasks
Count
The process development
environment
Ability to integrate application
tools
Ability to design effective enduser interfaces
Performance (speed of
response to end-users),
Correlation Coefficient
Sig. (2-tailed)
Result
83
.120
0.279
NS
69
.258*
0.032
Significant
83
.392**
0.000
Significant
83
.426**
0.000
Significant
83
.038
0.732
NS
83
.419**
0.000
Significant
83
.348**
0.001
Significant
Customer support
Availability of training in the
tool
Documentation
83
.401**
0.000
Significant
83
.333**
0.002
Significant
83
.423**
0.000
Significant
83
.202
0.067
NS
83
.346**
0.001
Significant
83
.282**
0.010
Significant
83
.075
0.502
NS
81
.208
0.062
NS
Ease of use of the development

environment
Cost-effectiveness
System crashes affected the
development effort.
It is difficult to recover from
system crashes.
The automation tool supports a
good range of hardware
platforms.
Table ST-HYP-11-05: Strengths of Automation tool Vs The automated process improves

the effectiveness of end-users in performing their tasks
From the above table, it is observed that five of the fifteen strengths of the Process
automation have no significant influence on The automated process improves the
effectiveness of end-users in performing their tasks. However, ten out of the fifteen
strengths of Process automation namely Debugging capabilities, Ability to integrate
application tools, Ability to design effective end-user interfaces, Performance,
Cross-platform compatibilities, Customer support, Availability of training in the
tool and Documentation has significant influence on The automated process
improves the effectiveness of end-users in performing their tasks. Hence, it can be
concluded that the strengths of Process automaton has some influence on the
automated process improves the effectiveness of end-users in performing their tasks.
365
Analysis H11.6:
1. Independent Variable - Group E Question 3: Defects in the automation
tool affected the development effort
2. Independent Variable - Group F Question 4-7: The Process Automation
Development Process:


conducted on data depicted in figures GRP-E-03 and GRP-F-04 to GRP-F-07.
Defects in the automation tool affected the development effort Vs Process Automation
Development Process
Count
The process design was developed in
conjunction with end-users
The process design was reviewed with the
end-users
The end-user screens have been evaluated
by the end-users
Process simulations have been performed
with the end-users
Sig. (2-tailed)
Result
79
-.032
0.777
NS
81
-.039
0.728
NS
77
.456**
0.000
Significant
79
.291**
0.009
Significant
Table ST-HYP-11-06: Defects in the automation tool affected the development effort Vs
Process Automation Development Process
From the above table, it is observed that Defects in the automation tool affected
the development effort has no significant influence on two out of the four Process
automation development processes. However, Defects in the automation tool affected
the development effort has significant influence on two out of the four Process
automation development processes namely The end-user screens have been evaluated by
the end-users and Process simulations have been performed with the end-users.
Hence, it can be concluded that Defects in the automation tool affected the
development effort has partial influence on the Process automation development
processes.
366
Hypothesis XI: Summary and Conclusion
independent variable Development Technology that significantly influence few factors
of the dependent variable Transition and Adoption. Therefore, the hypothesis is
neither accepted nor rejected. Hence, it can be concluded that while Development
Technology has a relation to Transition and Adoption, it does not have a significant
influence on Transition and Adoption.
Hypothesis XII: Transition and adoption has no significant influence on Impacts

and Insights
To substantiate this hypothesis with data, 24 questions from Group F (Transition

and Adoption) and 7 questions from Group G (Impacts an Insights) are analyzed.
presented here.
Analysis H12.1:
1. Independent Variable - Group F Question 3 to 23: Transition adoption
methods:
Training was provided to support:
Automated Process design/development approach:
367

There was resistance to process automation for the following
reasons:
Fear of job loss
Fear of change
End-users feel that they were not consulted sufficiently in
process definition
Management Support activities:
A documented transition strategy was developed
A prototyping strategy is being used for implementation
conducted on data depicted in figures GRP-F-03 to GRP-F-23 and GRP-G-01.
368
Transition and Adoption methods Vs To date, I consider the process automation project to be a
success
Count
Sig. (2-tailed)
Result
83
.010
0.931
NS
83
.035
0.752
NS
79
.274*
0.014
Significant
81
.319**
0.004
Significant
77
.162
0.159
NS
79
.229*
0.043
Significant
83
.145
0.191
NS
83
.156
0.159
NS
83
-.118
0.287
NS
83
-.001
0.990
NS
83
-.083
0.454
NS
83
.196
0.076
NS
Fear of job loss
83
.193
0.081
NS
Fear of change
83
-.122
0.271
NS
The perception that process automation is

too controlling
83
-.083
0.453
NS
End-users feel that they were not consulted

sufficiently in process definition
83
.118
0.290
NS
83
.078
0.482
NS
83
.360**
0.001
Significant
81
.083
0.460
NS
81
.142
0.206
NS
A development plan was agreed to by

management
81
-.036
0.752
NS
81
.191
0.088
NS
83
.006
0.954
NS
81
.232*
0.037
Significant
83
.147
0.186
NS
83
-.258*
0.019
Significant
Training provided to Implementers of the

process-centered environment
Training provided to End-users of the
automated process
The process design was developed in
conjunction with end-users
The process design was reviewed with the
end-users
The end-user screens have been evaluated
by the end-users
Process simulations have been performed
with the end-users
The automated process improves the
effectiveness of end-users in performing
their task(s).
The end-users had difficulty in accepting the
new process.
The end-users feel ownership towards the
automated process
End-users make suggestions to improve the
automated process
Metrics have been used to improve the
automated process
Automation was viewed as externally
imposed
Fear that metrics would be used in job

evaluations
Senior management is supportive of the
process automation project
First-line management is supportive of the
automation project
The project has received adequate funding

for transitioning
The automation project has a champion with
designated authority
A documented transition strategy was
developed
A prototyping strategy is being used for
implementation
Table ST-HYP-12-01: Transition and adoption methods Vs To date, I consider the process
automation project to be a success
369
From the above table, it is observed that twenty out of twenty six Process
automation transition methods have no significant influence on To date, I consider the
process automation project to be a success. However, six out of twenty six Process
automation transition methods namely The process design was developed in conjunction
with end-users, The process design was reviewed with the end-users, Process
simulations have been performed with the end-users, Senior management is supportive
of the process automation project, The automation project has a champion with
designated authority and A prototyping strategy is being used for implementation has
significant influence on To date, I consider the process automation project to be a
success. Hence, it can be concluded that Process automation transition methods has
some influence on the success of Process Automation.
Analysis H12.2:


Fear of job loss
Fear of change
definition
2. Independent Variable - Group G Question 2-4: Process Automation
Outcomes


Helps reduce tedium
370

Reduces costs
Automation has helped to enforce defined process
Test Results: The two variables namely Reasons for Resistance to Process
Automation and Process Automation Outcomes have multiple factors and hence a
two-dimensional analysis is conducted. Below tables are the result of Spearmans
Rho Correlation Test conducted on data depicted in figures GRP-F-13-01 to GRPF-13-6 and GRP-G-02 to GRP-G-04.
371
Reasons for Resistance to Process Automation Vs Process Automation Outcomes

Automation
externally
imposed
Fear of change
Process
automation is too
controlling
End-users not
consulted
Fear that metrics

used in job
evaluations
83
83
83
83
83
83
-0.010
-0.138
-0.021
0.123
-0.170
-0.198
Sig. (2-tailed)
Count
Improve enduser
productivity
Fear of job loss
0.931
0.212
0.851
0.269
0.124
0.073
Result
NS
NS
NS
NS
NS
NS
Count
83
83
83
83
83
83
Improve product Correlation Coefficient

quality
Sig. (2-tailed)
0.014
0.006
-0.126
-0.133
-0.047
-0.065
0.902
0.954
0.257
0.230
0.674
0.559
Result
NS
NS
NS
NS
NS
NS
Count
83
83
83
83
83
83
Manage projects Correlation Coefficient

more effectively
Sig. (2-tailed)
0.019
-0.074
0.097
0.059
-0.095
-0.087
0.867
0.507
0.383
0.597
0.395
0.436
NS
NS
NS
NS
NS
NS
83
83
83
83
83
83
.250*
0.040
-0.078
-0.066
0.153
.275*
0.022
0.720
0.481
0.556
0.168
0.012
Significant
NS
NS
NS
NS
Significant
Result
Count
Improve
communication Correlation Coefficient
between endSig. (2-tailed)
users
Result
Count
Improve enduser job
satisfaction
Improve enduser teambuilding
Helps reduce
tedium
83
83
83
83
0.110
.322**
0.153
0.186
0.026
0.536
0.324
0.003
0.166
0.092
Significant
NS
NS
Significant
NS
NS
Count
83
83
83
83
83
83
-0.041
-0.002
-0.086
0.115
0.129
0.043
Sig. (2-tailed)
0.712
0.988
0.439
0.300
0.245
0.699
Result
NS
NS
NS
NS
NS
NS
Count
83
83
83
83
83
83
-.262*
-.218*
-0.114
-0.084
-.299**
-.297**
0.017
0.048
0.303
0.452
0.006
0.006
Significant
Significant
NS
NS
Significant
Significant
Sig. (2-tailed)
83
83
83
83
83
83
-0.012
0.117
-0.067
-0.150
0.058
0.120
Sig. (2-tailed)
Count
Supports
administrative
efforts
83
0.069
Result
Sig. (2-tailed)
Result
Helps prevent
errors
83
.245*
0.913
0.294
0.550
0.176
0.604
0.280
Result
NS
NS
NS
NS
NS
NS
Count
83
83
83
83
83
83
-0.125
-.268*
-0.180
-0.056
-0.170
-0.131
Sig. (2-tailed)
0.262
0.014
0.104
0.615
0.124
0.236
Result
NS
Significant
NS
NS
NS
NS
Count
83
83
83
83
83
83
-.217*
-.218*
-0.146
-0.073
-0.112
-0.146
Provides useful
process
Sig. (2-tailed)
guidance,
0.048
0.048
0.187
0.511
0.313
0.188
Result
Significant
Significant
NS
NS
NS
NS
Count
83
83
83
83
83
83
Provides timely
status
Sig. (2-tailed)
information
0.048
-0.099
-0.053
0.098
0.023
0.060
0.669
0.373
0.635
0.380
0.834
0.592
Result
NS
NS
NS
NS
NS
NS
Count
83
83
83
83
83
83
Provides useful Correlation Coefficient

metric data
Sig. (2-tailed)
-0.064
0.101
-0.011
-0.153
0.040
0.113
Reduces costs
0.562
0.366
0.920
0.169
0.720
0.310
Result
NS
NS
NS
NS
NS
NS
Count
83
83
83
83
83
83
0.069
-0.131
-0.089
0.085
-0.106
-0.047
Sig. (2-tailed)
0.538
0.236
0.426
0.443
0.340
0.673
NS
NS
NS
NS
NS
NS
83
83
83
83
83
83
0.208
0.150
-0.008
-0.057
0.139
0.160
0.059
0.177
0.940
0.607
0.209
0.147
NS
NS
NS
NS
NS
NS
Result
Count
Automation has
helped to
enforce defined
Sig. (2-tailed)
process.
Result
Table ST-HYP-12-02: Resistance to Process Automation Vs Process Automation outcomes
372
1. From the above table, it is observed that the reason for resistance Automation
externally imposed has no significant influence on eleven out of the fourteen Process
automation outcomes. However, the reason for resistance Automation externally
imposed has significant influence on three out of the fourteen Process automation
outcomes namely Improve communication between end-users, Helps reduce
tedium and Provides useful process guidance. Hence, it can be concluded that the
reason for resistance Automation externally imposed has some influence on the
Process automation outcomes.
2. From the above table, it is observed that the reason for resistance Fear of job loss
has no significant influence on eleven out of the fourteen Process automation
outcomes. However, the reason for resistance Fear of job loss has significant
influence on three out of the fourteen Process automation outcomes namely Helps
reduce tedium, Supports administrative efforts and Provides useful process
guidance. Hence, it can be concluded that the reason for resistance Fear of job loss
has some influence on the Process automation outcomes.
3. From the above table, it is observed that the reason for resistance Fear of change
has no significant influence on all the fourteen Process automation outcomes. Hence,
it can be concluded that the reason for resistance Fear of change has no influence
on the Process automation outcomes.
4. From the above table, it is observed that the reason for resistance Process
Automation is too controlling has no significant influence on thirteen out of the
fourteen Process automation outcomes. However, the reason for resistance Process
Automation is too controlling has significant influence only one of the fourteen
Process automation outcomes namely Improve end-user job satisfaction. Hence, it
can be concluded that the reason for resistance Process Automation is too
controlling has little influence on the Process automation outcomes.
5. From the above table, it is observed that the reason for resistance End-users not
consulted has no significant influence on thirteen out of the fourteen Process
automation outcomes. However, the reason for resistance End-users not consulted
has significant influence only one of the fourteen Process automation outcomes
namely Helps reduce tedium. Hence, it can be concluded that the reason for
373
resistance End-users not consulted has little influence on the Process automation
outcomes.
6. From the above table, it is observed that the reason for resistance Fear that metrics
would be used in job evaluations has no significant influence on twelve out of the
fourteen Process automation outcomes. However, the reason for resistance Fear that
metrics would be used in job evaluations has significant influence on two out of the
fourteen Process automation outcomes namely Improve communication between
end-users and Helps reduce tedium. Hence, it can be concluded that the reason for
resistance Fear that metrics would be used in job evaluations has some influence on
the Process automation outcomes.
Hence, it can be concluded that the Reasons for resistance to Process

Automation have some influence on the Process automation outcomes.
Analysis H12.3:
1. Independent Variable - Group F Question 1: How long (in months) has it
taken to transition the process to the production environment?
2. Independent Variable - Group G Question 1-5: Outcomes of Process
Automation:

To date, I consider the process automation project to be a success

Helps reduce tedium
Reduces costs
Automation has helped to enforce defined process.
374
The technical implementation was more challenging than first

thought
data depicted in figures GRP-F-01 and GRP-G-01 to GRP-G-05.
How long (in months) has it taken to transition the process to the production environment? Vs Outcomes of Process Automation
How long (in months) has it taken to transition the process to the production
environment?
To date, I consider the process

Chi-Square
DF
P-Value
Result
52.5
3.916
0.562
NS
0-2
03-Jun
07-Dec
13-24
Over 24
Not completed
34
36.06
38.27
43.24
34
23.75
35.06
31.58
45.54
45.33
51.5
12.997
0.023
Significant
19
41
35.62
39.48
46.25
55
11.856
0.037
Significant
17
39.75
37.62
41.35
41.04
71
15.14
0.01
Significant
Improve communication between endusers
45.25
41.56
32.69
38
31.17
71.5
9.502
0.091
NS
50.5
32.06
28.31
39.87
43.67
68
12.848
0.025
Significant
40.63
32.69
30.31
45.98
36.67
60.5
8.598
0.126
NS
Helps reduce tedium
23.13
36.31
30.85
47.35
47.46
14
18.74
0.002
Significant
25
38
38.15
43
43.75
16
8.659
0.123
NS
27
40.72
35.04
43.93
39.67
17.5
7.962
0.158
NS
32
40.22
24.88
43.02
50.5
13.5
18.097
0.003
Significant
36.87
44.17
22
4.045
0.543
NS
41
41
33.69
37.5
41.61
30.38
40
43.67
19
5.786
0.328
NS
Reduces costs
34.25
42.5
27.62
43.93
40.29
17
9.133
0.104
NS
Automation has helped to enforce

defined process.
30.88
34
38.81
37.8
47.92
59
7.515
0.185
NS
31
43.5
29.65
36.98
46.83
48.5
8.046
0.154
NS
The technical implementation was

Table ST-HYP-12-03: Time taken to transition the process to the production environment
Vs Outcomes of Process Automation
From the above table, it is observed that Time taken to transition the process to
the production environment has no significant influence on ten of the sixteen outcomes of
Process automation. However, Time taken to transition the process to the production
environment has significant influence on six of the sixteen outcomes of Process
automation namely Improve end-user productivity, Improve product quality,
Manage projects more effectively, Improve end-user job satisfaction, Helps reduce
tedium and Provides useful process guidance. Hence, it can be concluded that Time
taken to transition the process to the production environment has little influence on
the outcomes of Process Automation.
375
Analysis H12.4:
1. Independent Variable - Group F Question 2: How long has the
automated process been operating in a production environment
2. Independent Variable - Group G Question 1-5: Outcomes of Process
Automation:

To date, I consider the process automation project to be a success

Helps reduce tedium
Reduces costs
Automation has helped to enforce defined process.
The technical implementation was more challenging than first
thought
data depicted in figures GRP-F-02 and GRP-G-01 to GRP-G-05.
376
How long has the automated process been operating in a production environment Vs Impacts of Process Automation
How long (in months) has the automated process been operating in a
production environment
Not yet in
07-Dec
13-24
0-2
13-24
Over 24
production
Chi-Square
DF
P-Value
Result
To date, I consider the process

25.79
37.1
34.88
37.15
42.5
44.3
5.232
0.388
26.07
27.83
38.27
35.09
46.33
52.5
16.767
0.005 Significant
NS
34
33
40.54
35.71
36.5
47
4.066
30.93
39.7
33.5
26.56
38.67
61.2
21.501
Improve communication between

end-users
31.14
39.93
34.77
30.94
42.25
47.3
6.393
0.27
NS
27.86
34.6
36.69
34.59
43.5
47.4
5.866
0.319
NS
24.93
39.53
34.08
40.21
38.42
42
3.938
0.558
NS
Helps reduce tedium
30.64
32.03
34.65
37.79
45.42
44.2
6.178
0.289
NS
41
37
37.54
35.47
45.17
30
3.956
0.556
NS
34.36
28.37
38.42
40.26
49.33
33.3
9.571
0.088
NS
Provides useful process guidance,
19.64
36.1
36.65
42.62
44.5
36.1
9.768
0.082
NS
27.29
36.8
41.92
37.24
46.67
29.4
7.867
0.164
NS
24.14
45.4
41.15
40.24
43
19
17.625
0.003 Significant
Reduces costs
Automation has helped to enforce
defined process.
32.71
29.6
35.04
40.79
44.92
41.4
5.768
0.329
NS
30.93
37.53
44.27
35.53
44.83
27.8
7.318
0.198
NS
21.93
41.17
41.73
38.74
40
32.3
6.921
0.227
The technical implementation was

0.54
NS
0.001 Significant
NS
Table ST-HYP-12-04: Duration the automated process has been operational Vs Outcomes
of Process Automation
From the above table, it is observed that Duration the automated process has been
operational has no significant influence on thirteen of the sixteen outcomes of Process
automation. However, Duration the automated process has been operational has
significant influence on three of the sixteen outcomes of Process automation namely
Improve end-user productivity, Manage projects more effectively and Provide
useful metric data. Hence, it can be concluded that Duration the automated process
has been operational has little influence on the outcomes of Process Automation.
Hypothesis XII: Summary and Conclusion
independent variable Transition and Adoption that significantly influence few factors
of the dependent variable Impacts and Insights. Therefore, the hypothesis is neither
accepted nor rejected. Hence, it can be concluded that while Transition and Adoption
has a relation to Impacts and Insights, it does not have a significant influence on
377
4. 4 CONCLUSION
4.4.1 Distribution Analysis Summary
The distribution analysis in section 4.02 has highlighted the knowledge that
the respondents possess regarding software projects execution parameters and software
process automation and also their perception of the relation between the two areas being
researched.
In section 4.2.1 we analyzed the nature of respondents who participated in the
study. It is found that all four organizations have almost equal participation. Additionally,
it is observed that there is a balanced participation from Indian and global organizations.
Also, it is observed that though in comparison to organization strength, the number of
respondents is very small but from the perspective of the number of employees directly
involved in the Process Automation initiative, a reasonable number of respondents have
participated.
In section 4.2.2 we analyzed the nature of responses. In category A:

Business/Product Characteristics, it is found that all participating organizations are
commercial, cater to all industries, provide all kinds of products, services and conduct all
IT services. While some organization may have frequent changes, some do not
incorporate change very often. Most of these organizations are risk takers, formal with
many-layered organization structure, working in a controlled but dynamic environment,
comprise energetic teams allocated to exciting jobs, encourages open-minded culture and
non-political in business. Some organizations maintain a neutral culture. These
organizations may have high turnovers at some points in time but more often operate with
stable staff.
In category B:Process Automation Implementation Team Characteristics, it is

observed that Process Automation development team size is most over 11 numbers led by
a manager with experience more than 11 years and team holding rich experience in
various process automation skills. There is a good representation from end-user group,
378
some use of external consultants expertise and very little use of subcontractors
expertise. In category C:Application Focus, almost all respondents perceive that Process
Automation initiative addresses all process areas except Deployment, Subcontractor
management and Supplier management. Time to market was not considered as a major
motivator but all other elements were strongly considered as motivators for Process
Automation. Majority of respondents felt that adequate funding was provided. The
automated process tool is implemented in all participating organizations, is being used on
a day-to-day basis and as more than 11 transactions per day is being executed.
In category D:Process Characteristics, it is observed that these organizations

have implemented the Process Automation initiative methodically with proper planning,
proper documentation of process notation definition, functional requirements, design and
metrics and though a challenging task, in most cases, it is found that the tool is in stable
operation. In category E:Development Technology, it is found that the participating
organizations have implemented a in-house developed Process Automation tool, their
respondents have agreed that the tool has many strengths such as debugging capabilities
and collection of metrics but performance and quality of the tool is a challenge.
In category F:Transition and Adoption, some respondents agreed that the tool
is operational, adequate training was provided, end-user involvement in design and
reviews and screens evaluation. Most respondents agreed the process simulations were
held with end-users. Some say end-users had difficulty accepting the tool with new
process due to various doubts and fears, but mostly took ownership despite many fears,
and actively participated in successful implementation.
In category H:Impacts and
Insights, almost all respondents agreed that the Process Automation initiative is a success
and the benefits of implementation as perceived by the management has been realized.
4.4.2 Correlation Analysis Summary

The Correlation analysis is a pure statistical analysis of the data collected
from the respondents to understand the two areas of study namely software projects
379
execution parameters and software process automation and to derive a mathematical

relation between them.
With the vast amount of information gathered through questionnaire,
Correlation analysis was conducted only on groups of information that were perceived to
be related. Overall conclusion of this analysis with respect to defined hypotheses are
detailed below:
HYPOTHESIS I: A. Business/Product Characteristics has no significant influence on
Result: There are few factors of Business Product Characteristics that
significantly influence few factors of Implementation Team Characteristics. Therefore,
the hypothesis is neither accepted nor rejected. Hence, it can be concluded that while
Business Product Characteristics has a relation to Implementation Team Characteristics,
it does not have a significant influence on Implementation Team Characteristics.
HYPOTHESIS II: A. Business/Product Characteristics has no significant influence on

Result: There are few factors of the independent variable Business Product
Characteristics that significantly influence few factors of the dependent variable
Application Focus. Therefore, the hypothesis is neither accepted nor rejected. Hence, it
can be concluded that while Business Product Characteristics has a relation to
Application Focus, it does not have a significant influence on Application Focus.
HYPOTHESIS III: A. Business/Product Characteristics has no significant influence on

Result: There are few factors of the independent variable Business/Product
Process Characteristics. Therefore, the hypothesis is neither accepted nor rejected.
Hence, it can be concluded that while Business/Product Characteristics has a relation to
Process Characteristics, it does not have a significant influence on Process
Characteristics.
380
HYPOTHESIS IV: B. Implementation team characteristics has no significant influence

Result: There are few factors of the independent variable Implementation team
characteristics that significantly influence few factors of the dependent variable
Application focus. Therefore, the hypothesis is neither accepted nor rejected. Hence, it
can be concluded that while Implementation team characteristics has a relation to
Application focus, it does not have a significant influence on Application focus.

characteristics
Result: There are few factors of the independent variable Application focus that
significantly influence few factors of the dependent variable Process Characteristics.
Therefore, the hypothesis is neither accepted nor rejected. Hence, it can be concluded
that while Application focus has a relation to Process Characteristics, it does not have a
significant influence on Process Characteristics.

Result: There are few factors of the independent variable Application focus that
significantly influence few factors of the dependent variable Development Technology.
Therefore, the hypothesis is neither accepted nor rejected. Hence, it can be concluded
that while Application focus has a relation to Development Technology, it does not have
a significant influence on Development Technology.
HYPOTHESIS VII: C. Application focus has no significant influence on F. Transition

and adoption
Result: There are very few factors of the independent variable Application
focus significantly influence few factors of the dependent variable Transition and
Adoption. Therefore, the hypothesis is neither accepted nor rejected. Hence, it can be
381
concluded that while Application focus has a relation to Transition and Adoption, it does
not have a significant influence on Transition and Adoption.
HYPOTHESIS VIII: D. Process characteristics has no significant influence on E. The

Result: There are few factors of the independent variable Process
Development Technology. Therefore, the hypothesis is neither accepted nor rejected.
Hence, it can be concluded that while Process Characteristics has a relation to
Development Technology, it does not have a significant influence on Development
Technology.

Transition and Adoption. Therefore, the hypothesis is neither accepted nor rejected.
Hence, it can be concluded that while Process Characteristics has a relation to Transition
and Adoption, it does not have a significant influence on Transition and Adoption.
HYPOTHESIS X: D. Process characteristics has no significant influence on G. Impacts

and Insights
Impacts and Insights. Therefore, the hypothesis is neither accepted nor rejected.
Hence, it can be concluded that while Process Characteristics has a relation to Impacts
and Insights, it does not have a significant influence on Impacts and Insights.
HYPOTHESIS XI: E. The development technology has no significant influence on F.

382
Result: There are few factors of the independent variable Development

Technology that significantly influence few factors of the dependent variable
Transition and Adoption. Therefore, the hypothesis is neither accepted nor rejected.
Hence, it can be concluded that while Development Technology has a relation to
Transition and Adoption, it does not have a significant influence on Transition and
Adoption.

Result: There are few factors of the independent variable Transition and
Adoption that significantly influence few factors of the dependent variable Impacts and
Insights. Therefore, the hypothesis is neither accepted nor rejected. Hence, it can be
concluded that while Transition and Adoption has a relation to Impacts and Insights, it
does not have a significant influence on Impacts and Insights.
PRIMARY HYPOTHESIS: There is no significant contribution by Process Automation

on Software Project Success.
Result: Since the secondary hypotheses are neither accepted nor rejected, the
primary hypothesis remains neither accepted nor rejected and hence inconclusive. Thus,
it can be stated that while Process Automation has certain amount of influence on
Software Project Success and contributed to a considerable extent, it cannot be concluded
that Process Automation has a significant contribution to Software Project Success.
The analysis however, helped to assess the extent of the relationship between
the relevant groups considered. This extensive analysis has revealed that these groups are
related through some factors. Some of these related factors are highly influencing each
other. These significantly influencing factors from pairs of groups of information show
that there is a great dependency among these pairs of information.
To illustrate the above point, two such analyses are highlighted once more. In
Hypothesis V where group C and group D are analyzed, the motivating element being
collection of metrics has a significant influence on automating the software development
383
process. This implies that by automating the process of software development activities,
the organization is able to collect metrics efficiently and effectively. Similarly, in
Hypothesis VII where group C and group F are analyzed, the practice of automated
processes being used on a day-to-day basis has a significant influence on automation
helping the organization to enforce defined processes among practitioners. This implies
that since the Process automation tool has actually automated the quality processes
defined by the organization and it provides the means of using the same on-line, the use
of this tool on a daily basis forces the end-users to follow the defined process. It
indirectly reduces the effort of quality managers, quality assurance managers, quality
auditors and process owners to frequently inspect and ensure proper and timely
application of defined process.
Therefore, it is understood that though none of the hypotheses are either
rejected or accepted, it is important to observe and acknowledge that there are factors
internal and external that influence the Process Automation Initiative. Moreover, the
success of Projects do not directly depend on implementing the Process Automation
Initiative but does benefit from this initiative through productivity improvement and
quality assurance.
384
CHAPTER V: CONCLUSION
5.1.
INTRODUCTION ............................................................................................... 386
5.2.
REITERATION OF RESEARCH PROBLEM ................................................... 386
5.3.
MAJOR FINDINGS ............................................................................................ 388
5.4.
IMPLICATIONS OF THE STUDY .................................................................... 388
5.5.
DELIMITATIONS .............................................................................................. 391
5.6.
MAJOR SUGGESTIONS.................................................................................... 392
5.7.
SCOPE FOR FURTHER RESEARCH ............................................................... 393
In this chapter, the research problem, key findings, suggestions and

conclusion are recapitulated. Based on these findings, a few suggestions on improving the
adoption methodology of process automation to achieve successful project delivery are
put forth for consideration. The extensive study has revealed that Software organizations
welcome initiatives such as Process Automation. Process Automation initiative is
implemented with support from Management, Process owners and End-users. Although
implementation of an initiative such as Process automation across the organization is
challenging, with appropriate approaches and adequate training, it has proven to be a
success. Process Automation is helps project teams to follow process, improve
productivity, collect and use metrics for improving quality and reduce tedium. Thus
project teams effectively and efficiently work to produce successful projects.
385
CHAPTER V
CONCLUSION
5. 1 INTRODUCTION
The research analysis was conducted extensively and the results have been
presented in a comprehensive manner. The seven broad categories of information
gathered through a survey of software professionals have been studied to support the
theory of this particular research. The major findings, some of the critical suggestions and
recommendations for further research are mentioned below.
5. 2 REITERATION OF RESEARCH PROBLEM
Software organizations adopted various methodologies to implement Process

Automation at various points in time. Some organizations took up such initiative because
it was a trend in industry at that time, some took it up because their organizations were
growing big and monitoring and controlling became a challenge and some took up the
same because they saw benefits through successful project deliveries. The problem lies in
organizations investing heavily on process automation initiative but do not look back to
see if it has actually given back the benefits. The reason is that if their inspection reveals
that it has actually not provided the outcome expected, reverting back such initiative
would lead to heavy losses. Thus, there are not much research done on this subject. There
are also not much discussed on this subject.
5. 3 MAJOR FINDINGS
The elaborate and in-depth study and analysis has revealed that the Software
industry does give importance to Process Automation initiative. Software organizations
that are risk takers, open working culture have vigorously implemented Process
automation with great planning and methodical approach. They have employed highly
skilled and experienced professionals to implement Process Automation.
386
The top management has recommended, sponsored and supported Process

Automation initiative which is a key factor for its success. The study also revealed that
Process Improvement, Quality, Metrics collection, Management oversight, and
Productivity improvement are key motivators for Process Automation. Process
Automation implementation in these organizations has impacted the Project delivery by
ensuring quality and increasing productivity.
Software organizations have adopted various methodologies to implement

Process Automation. While some have directly converted the existing manual Process
systems to automated systems, some organizations have defined new process systems and
automated them. Also, some organizations have automated all the process at once while
some have implemented in a phased manner. Also, organizations that frequently change
policies and processes to match the business trends, have gone beyond standard process
automation and implemented even new tools and methodologies recommended by Six
sigma and Lean.
The process owners, middle management and end-users were highly involved
in various stages of Process automation such as defining and validating processes to be
automated, designing screens, testing and prototype simulations. There have been few
hurdles that hindered smooth and successful implementation of Process automation such
as defects in the automated tool, defects in the defined processes, resistance from endusers to use the automated tool, etc. However, the initiative has overcome all these
challenges by systematic implementation with adequate training and provided great
benefits in return.
The study has revealed that Process automation tool being used on a day-today basis has helped in enforcing process adherence. Also, since the tool helps in process
adherence, end-users use the tool on a day-to-day basis thereby increasing productivity.
Extensive training on usage of the tool has helped in enhancing the strengths of process
automation such as provision of a process definition environment, integration of
387
application tools, ability to design effective end-user interfaces, ability to collect metrics,
improve performance, provision of cross-platform compatibilities, documentation and
ease of use of the development environment. These strengths were further enhanced
when metrics were used to evaluate and improve defined and automated processes.
Finally, the study has revealed that there are many benefits derived from
Process Automation. However, the highlights are Productivity improvement, Product
quality, Effective project management, Reduction in tedious work, Process guidance and
Useful metrics outputs. Of the above, Productivity improvement and Product quality are
two direct benefits that positively contribute to project success, the other benefits such as
Effective project management, Reduction in tedious work, Process guidance and Useful
metrics outputs are converted to the main benefits such as Productivity and Quality
thereby indirectly contributing to project success.
5. 4 IMPLICATIONS OF THE STUDY
The study and analysis of the survey information reveals that Software
Services Organizations have realized the importance of software process automation
adoption to meet the challenges posed by todays competitive market. But still, adoption
of such initiatives requires large investments and a strategic approach to the entire
process. So, such initiatives require strong value delivery that is justified to top
management. The value should also be projected as not only quantitative benefits but also
very high qualitative benefits. This will also bring in changes in the prevailing culture of
any organization and its management style.
Further, software services organizations that have already adopted software

process automation have seen its worth through its contribution to success of software
projects delivered to their customers. Software process automation processes have
directly contributed to the quality measure of a successful project but has also contributed
though indirectly to schedule and cost measures of a successful project as well.
388
The investigative study conducted on four software organizations have

revealed a wealth of observations that throws light on various aspects of Software
Process Automation and its contribution to project success. Software organizations are
driven by certain internal and external influences that drive them to go for Software
Process Automation. At the same time, there are also internal and external parameters
that negatively influence the organizations to go for partial fledged software process
automation or even discontinue such initiatives. Organizations that have faired the rough
weather and still managed to adopt software process automation have seen tremendous
benefits in delivering successful projects. These findings are grouped into two major
areas:
1. Influences on Software Process Automation Initiatives
2. Influence of Process Automation adoption in Software Project Successes
5.4.1 Influences on Software Process Automation Initiatives
The main influences on Software Initiatives taken up by Software Services

Organizations are of three major categories
1. Motivators
2. Inhibitors
3. Contributors to success
5.4.1.1 Motivators
The most common and critical parameters driving organizations to software

process automation were actually the needs to remain competitive, improve quality, and
reduce costs. These powerful motivators are:
a.
b.
c.
d.
Process Improvement
Management Oversight
Metrics collection
Quality Management
389
5.4.1.2 Inhibitors
The other set of evil players in the game of Software Process Automation are
those parameters that have hindered the adoption of Software Process Automation in
software organizations or forced some organizations to abandon such initiatives that they
had taken up. Such negative influences are:
a. Resistance to change
b. Metrics used for job evaluation
c. High cost of maintenance
5.4.1.3 Contributors to Successful Software Process Automation Adoption
While there were various parameters that have influenced positively or

negatively on the adoption initiatives of software process automation, there have also
been strong contributors to the success of such initiatives. They are:
a. Top management commitment
b. Effective training to end-users and implementers
c.
Visible benefits of Process Automation
5.4.2 Influence of Software Process Automation on Software Project Successes
This research though originally set out to focus on how software process
adoption has impacted an organization in terms of its business value delivery, it was
found that few software organizations are using software process automation on a day-today basis. So, the study dwelt deeper into whys and hows of software process
automation to understand the background to this whole initiative.
However, the focus of this research was too interesting to be left aside.
The study conducted has quite visibly revealed that 98 percent of respondents have
agreed that software process automation by itself has been a great success in their
organizations. Success of any software process automation adoption is through its
influence on successful business and return on investment. 98 percent of respondents
390
have agreed that their productivity has improved well due to adoption of software process
automation. Quality is another positive outcome of software process automation. 95
percent of respondents have acknowledged that Quality has considerably improved since
adopting software process automation. It is noticed that errors in software development
have reduced considerably. While Productivity and Quality improvement have generated
tangible benefits, there are other qualitative benefits that are seen through software
process automation adoption. Communication among teams have improved and increased
efficiency too.
The research has clearly brought out the fact that software process automation
adoption has positively contributed software services organizations. The various benefits
are seen in terms of quality improvement through error reduction, productivity
improvement, effective project management, process compliance, reduction in mundane
activities and enhanced communication.
5. 5 DELIMITATIONS
This particular research is focused on process automation initiatives taken up

by software services organizations. Hence, the scope has a clear boundary in terms of
automation only in relation to software development and the target audience was selected
based on the practices adopted to implement process automation only in software
organizations. Though the survey was conducted on global and Indian organizations, the
respondents were chosen and interviewed only in India due to geographical constraints.
Though many software professionals were approached, only some responded to the
questionnaire due to the confidentiality clauses that bind them to sharing information
relating to their organization. Those that responded were assured by the researcher that
the data provided would be used with discretion and the organization names will be kept
confidential. The survey was conducted during the years 2005 to 2007. Since then,
changes could have happened in a volatile industry such as Software. These changes are
not considered or included in this research.
391
5. 6 MAJOR SUGGESTIONS
The study revealed many insights into the area of Process Automation.
However, few major suggestions based on the study results are presented here.
It is observed that risk taking organizations seem to be more welcoming such

innovative initiatives such as Software process automation, etc. Being
conservative does not help any organization to grow in the current business
environment. Organizations should take up challenging initiatives that would help
them survive and grow in this competitive business world.
While end-users have been involved in the whole process of introducing and
implementing Process Automation, it is very important that they are first assured
that such an initiative only benefit them and will not have a negative impact on
their profession. Their fears and apprehensions about such initiatives have to be
dealt with before these initiatives are taken up.
Management oversight, quality, metrics collection and process improvement are

the key motivators for initiating Process Automation and it is clear that these are
all the requirements of Management. An end-user who is expected to use this tool
on a day-to-day basis, asks What is in it for me? It is important to keep the endusers in mind while conducting a preliminary feasibility study before any
initiative. What motivates the end-user to use the tool every day? A question if
not answered upfront, will surely see the doom of a process automation initiative.
While the Process Automation has become one of the most required practices in
almost every software organization, the end-result of such initiative is not focused
enough. Every organization should keep in mind that any activity undertaken by
them should have a positive impact on the customers. While many organizations
claim that Process automation does benefit their customers, as this research also
conveys, they do not clearly measure the benefits. Process automation is
guaranteed to bring about quality assurance and productivity improvement. While
quality assurance results in quality product delivery, it means that the cost of
fixing bugs and rework are reduced. Also, productivity improvement results in
392
faster generation of code, reduction in administrative work and increased test

efficiency thereby reducing the cost of development. However, there are no
means to exactly measure this benefit and pass it on to customers. Unless this is
achieved, the Process automation is not considered to be a truly useful and
beneficial initiative.
5. 7 SCOPE FOR FURTHER RESEARCH
The research has only tried to understand how various factors contribute to
Software Process Automation and Software Project Successes. It has also attempted to
study the relation between these factors which might lead to understanding if Software
Process Automation has contributed to Software Project Successes. The study has
revealed that the area of research is too vast that it cannot be studied to its full depth and
breadth. There is a large scope for studying the extent of the contribution made by certain
factors to certain other factors.
There is a lacuna in understanding the big picture of such initiatives since

their benefits are only portrayed at a higher level. Further research can be conducted to
understand the true value of Process Automation initiative by measuring the tangible and
visible benefits that it can bring forth to the organization as a whole.
There is also a need for conducting a study on the various processes that need
to be automated. Not all processes under the roof of ISO, CMMi or any other Process
system needs to be automated. Some of them are better left to manual usage. Automating
such processes would only lead to effort overhead thereby resulting in end-users
resentment towards Process Automaton initiative.
There is so much more that software services organizations can benefit from
software process automation adoption and only time will tell of its true impact. This
study is shedding light on a fraction of the immense journey that Software Process
393
Automation has taken. There is still scope and hope for more in-depth research in this
arena of professional intrigue.
BIBLIOGRAPHY
Alan M. Christie (1994), A Practical Guide to the Technology and Adoption

of Software Process Automation, Carnegie-Mellon University, Pittsburgh
Alan M. Christie (1994), Software Process Automation -- A Technology
Whose Time has Come? CrossTalk -- Journal of Defense Software Engineering
Alan M. Christie (1995), Software process automation: the technology and
its adoption, Springer-Verlag London, UK
Alan M. Christie, Linda Levine, Edwin J. Morris, David Zubrow,(1996),
Software Process Automation: Experiences from the Trenches, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213
Alan M. Christie, Linda Levine, Edwin J. Morris, David Zubrow,(1997),
Software Process Automation: Interviews, Survey and Workshop Results, Software
Engineering Institute
Ali Behforooz, Frederick J Hudson, (2003), Software Engineering
Fundamentals, Oxford University Press, USA
Amith Sheth, Dimitrios Georgakopoulos, Stef M. M. Joosten, Marek
Ruskinkiewicz, Walt Scacchi, Jack Wileden, Alexander Wolf (1996) Report on NSF
Workshop on Workflow and Process Automation in Information Systems, Athens, GA
Ashok M. Kamthane, (2007), Computer Programming, Dorling Kindersley
(India) Private Limited, Pearsons Education in South Asia
394
Baccarini David, (1999), 'The Logical Framework Method for Defining

Project Success', Project Management Journal, vol. 30, no. 4, pp. 25-32
Jean-Claude Derniame, Ali Badara Kaba, David Wastell (2008), Software
Process Principles, Methodology and Technology, Springer.
Balaji S., M K Ahuja, (2005), Critical Team-Level Success Factors of
Offshore Outsourced Projects : A Knowledge Integration Perspective, Offshore Conroe
TX, Volume: 00, Issue: C, Publisher: Ieee, Pages: 1-8
Bedir Tekinerdogan, Motoshi Saeki, Gerson Sunye, Pim Van Den Broek,
Pavel Hruby (1999), Automating the Object- Oriented Software Development Process
Belassi W., O Tukel, (1996), A new framework for determining critical
success/failure factors in projects, International Journal of Project Management,
Volume: 14, Issue: 3, Publisher: Elsevier, Pages: 141-151
Blaney J, (1989), 'Managing software development projects', paper presented
to Project Management Seminar/Symposium, Atlanta, GA, USA
Booch G, (1996), Object solutions : managing the object-oriented project,
Addison-Wesley Pub. Co., Menlo Park
Capability Maturity Management Integration (CMMI) (1991), SEI
International Standard IS0 9000-3, Guidelines for the Application of IS0 9001 to the
Development, Supply and Maintenance of Software, International Organization for
Standardization, Geneva
Cherinka, R.
Overstreet, C.M.
Cadwell, A.
Ricci, J. (1994), Issues in
software process automation-from a practical perspective, Software Maintenance,

Proceedings, International Conference, Canada
395
Chow T., Cao D., (2008), A survey study of critical success factors in agile
software projects, Journal of Systems and Software, Volume: 81, Issue: 6, Publisher:
Elsevier Science Inc., Pages: 961-971
Colin Bentley, Dick Bennett, Alision, Thurlbeck, Alan Ferguson, Tony
Levene, Mike Kirk, Barry Wall, Graham Connellan, Ken Bradley, Peter Weaver, Brian
Coombes, Tim Lulham, Ian Santry, Nick Morgan, Mark van Onna, Bem van der
Wijngaart, (2002), Managing Successful Projects with PRINCE2, HMSO, Licensing
Division, Norwich, UK, published with the permission of the OGC on behalf of the
Controller of Her Majestys Stationery Office.
Danie van der Westhuizen, Edmond P Fitzgerald, (1997), Defining and
measuring project success
DeLone, WH & McLean ER, (1992), 'Information System Success: The
Quest for the Dependent Variable', Information Systems Research, vol. 3, no. 1
Jean Claude Derniame, Ali Badara Kaba, (1999), Software Process:
Principles, Methodology, and Technology, Springer, USA
Drew J. Procaccino, June M Verner, Scott P Overmyer, Marvin E Darter,
(2002), Case study: factors for early prediction of software development success,
Information and Software Technology, Volume: 44, Issue: 1, Publisher: Elsevier, Pages:
53-62
Duncan W., (1987), 'Get out from under', Computerworld Vol 2, pp. 89-93
Eric Verzuh, (2005), The Fast Forward MBA in Project Management, John
Wiley & Sons, New Jersey
Evelyn J. Barry, Chris F. Kemerer, Sandra A. Slaughter (2007), How
software process automation affects software evolution: a longitudinal empirical
analysis, Journal of Software Maintenance and evolution: Research and Practice, 19:1
396
31, Published online in Wiley InterScience (www.interscience.wiley.com). DOI:

10.1002/smr.342
F. Macdonald, J. Miller, A. Brooks, M. Roper, M. Wood, (1995),
Automating the Software Inspection Process, Automated Software Engineering: An
International Journal
Globerson S & Zwikael O, (2002), 'The Impact of the Project Manager on
Project Management Planning Processes', Project Management Journal, vol. 33, no. 3, pp.
58-64
Ilkka Seilonen, (2006), An Extended Process Automation System: An
Approach Based on a Multi-Agent System, Dissertation for the degree of Doctor of
Science in Technology presented at Helsinki University of Technology (Espoo, Finland)
Jack R. Meredith, Samuel J, Mantel Jr., (2005), Project Management: A
Managerial Approach, John Wiley & Sons, New Jersey
James Douglas Beasley (2004), The Impact of Technology on Plagiarism
Prevention and Detection: Research Process Automation, A New Approach For
Prevention, Plagiarism: Prevention, Practice and Policies 2004 Conference
James P. Lewis, (2005), Project Planning, Scheduling & Control: A HandsOn Guide to Bringing Projects in on Time and on Budget, McGraw Hill Publishing
James Persse, (2007), Project Management Success with CMMI@",
Prentice Hall, Prentice Education, New Jersey.
Jan Terge Karlsen, Jeanette Andersen, Live S Birkely, Elise Odegard, (2006),
An empirical study of critical success factors in IT projects, International Journal Of
Management And Enterprise Development, Volume: 3, Issue: 4, Pages: 297-311
Jeff Van Fleet, Reduce software costs & improve quality Top Ten things
you can do right now!
397
Jeffrey K Liker, (2004), The Toyota Way, Tata McGraw-Hill Publishing

Company Limited
Jiang JJ, Klein G & Discenza R, (2002), 'Perception differences of software
success: provider and user views of system metrics', Journal of Systems and Software,
vol. 63
Joseph Berk, Susan Berk, (1995), Total Quality Management: Implementing
Continuous Improvement, Excel Books, New Delhi
Kerzner H, (2002), Project management : a systems approach to planning,
scheduling, and controlling, 8th edn, Wiley, New York
Korin Kendra, Laura J Taplin, (2004), Project success: A cultural
framework, Project Management Journal
Linberg KL, (1999), 'Software developer perceptions about software project
failure: a case study', The Journal of Systems and Software, vol. 49, pp. 177-92
Marchewka JT, (2003), Information technology project management:
providing measurable organizational value, Wiley, Hoboken
Michael Amberg, (2006), Analysis of Critical Success Factors for Offshore
Software Development Projects A German Perspective, Analysis (2006), Volume: 1,
Publisher: DUV, Pages: 6-1-5
Michael Amberg, Martin Wiener, (2005), Towards a Model for Critical
Success Factors in Offshore Development Projects A Grounded Theory Approach,
Journal of Information Technology
Nasir M H N, Shamsul Sahibuddin, (2011), Critical success factors for
software projects: A comparative study, Scientific Research and Essays, Volume: 6,
Issue: 10, Pages: 2174-2186
398
Paulk, M. C., et al. The Capability Maturity Model for Software, Version
1.1, (1993), (CMU/SEI-93-TR-24, ADA 263403). Pittsburgh, PA: Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania
Penny Grubb, Armstrong A. Takang, (2003), Software Maintenance:
Concepts and Practice, World Scientific Publishing Company
D. E. Perry , A. Porter , L. G. Votta , M. W. Wade (1996), Evaluating
Workflow and Process Automation in Wide-Area Software Development, Proceedings
of the Fifth European Workshop on Software Process Technology
Petter Gottschalk, Hans Solli-Sther, (2005), Critical success factors from
IT outsourcing theories: an empirical study, Industrial Management Data Systems,
Volume: 105, Issue: 6, Publisher: Emerald Group Publishing Limited, Pages: 685-702
Quality Management and Quality Assurance Standards - Part 3: Guidelines
for the Application of ISO-9001 to the Development, Supply and Maintenance of
Software, (1991), International Organization for Standardization, Geneve, Switzerland
Rajesh Sharma (2001), Software Process Improvement and Automation,
Addison Wesley Publishing Company, MA
Reel J. S., (1999), Critical success factors in software projects, IEEE
Software, Volume: 16, Issue: 3, Publisher: IEEE, Pages: 18-23
Richard H. Thayer, Mark J. Christensen, (2005), Software Engineering, The
Development Process, Wiley-IEEE Computer Society Pr; Volume 1 edition
Richard H. Thayer, Merlin Dorfman, (2005), Software Engineering, The
Supporting Processes, Wiley-IEEE Computer Society Pr; Volume 2 edition
Rita Mulcahy, (2005), PMP, Exam Prep, A Course in a Book, RMC
Publications
399
Rodrigo Quites Reis, Carla Alessandra Lima Reis, Carla Aless, Ra Lima
Reis, Daltro Jos Nunes, (2001), Automated Support for Software Process Reuse:
Requirements and Early Experiences with the APSEE model, Proceedings of the 7th
International Workshop on Groupware (CRIGW-01) Darmstadt (Germany)
Rory OConnor, (2000), in his doctoral thesis Development of Intelligent
Assistant System for Software Project Planning
Sneed H M, P Brossler, (2003), Critical success factors in software
maintenance: a case study, International Conference on Software Maintenance 2003
ICSM 2003 Proceedings, IEEE Computer Society, Pages: 190-198
Standish Group, (2009), CHAOS Summary 2009", Springer.
Ulrich Remus, Martin Wiener, (2009), Critical Success Factors for
Managing Offshore Software Development Projects, Journal of Global Information
Technology Management, Volume: 12, Issue: 1, Pages: 6-29
Uma G Gupta, Vasant Raval, (1999), Critical Success Factors for
Anchoring Offshore Projects, Information Strategy The Executives Journal, Volume: 15,
Issue: 2, Pages: 21-27
Watts S Humphrey, (1989), Managing the Software Process, AddisonWesley Professional
Wolfgang Narzt, (2000), Design Patterns for Process Automation Systems
400
401
APPENDIX I - SURVEY QUESTIONNAIRE

Critical investigations on Contribution of Process Automation
to Software Project Success
This questionnaire is being administered as part of the research titled "Critical investigations on Contribution of Process
Automation to Software Project Success". It consists of questions that would help gauge the extent of process automation
implemented in software companies and its influence on the success of the projects delivered by these companies.
This section deals with the basic characteristics of the business you are in, the products you produce, and your
organization's culture.
1 What industries do you support?
Electronics
Health
Communications
Aerospace
Scientific
Transportation
Software
Finance/Banking/Insurance
Other (specify)
2 In which type of organization do you work?

Commercial
Government
Academic
Other (specify)
3 What is the focus of your products?

One-of-a kind (conceptually new, may require R&D)
Mass-produced (COTS, assembly line)
Maintenance (corrective, perfective)
Customized (tailoring existing product)

Application Development (unique service to customer)
Other (specify)
4 How often do you undergo organizational change which affects the work you do?
Every few months
Yearly
Every few years
DK/NA
5 How would you characterize your organization's culture (in your experience)?
Neutral
Conservative
5.01
Risk takers
Informal
5.02
Formal
5.03
Many layers
Flat organization
5.04
Controlling
Hands-off
Static environment
Dynamic environment
5.05
Complacent
Energetic
5.06
5.07
Closed minded
Open minded
5.08
Political
Non-political
Jobs are exciting
5.09
Jobs are routine
High turnover
5.10
Stable staff

This section deals with the people who were involved in developing the process-centered environment and transi-tioning the
environment into use
1 How many people are involved in developing the automated process?
<6
7-10
11-20
Over 20
DK/NA
2 How many years of software development experience does the process automation team leader have?
0-2
3-5
6-10
11-15
Over 15
DK/NA
3 How many years of software development experience do you have?
0-2
3-5
6-10
11-15
Over 15
4 People with experience in the following categories are part of the development team:
4.01 Process definition
Yes
No
4.02 Process-centered environment development
Yes
No
4.03 Tool integration
Yes
No
4.04 Computer networking
Yes
No
4.05 Transition and adoption
Yes
No
4.06 Training
Yes
No
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
402
5 There are representatives from each end-user project on the development team
Yes
No
DK/NA
6 Some of the expertise is being provided by external consultants
Yes
No
DK/NA
7 Some of the expertise is being provided by subcontractors
Yes
No
DK/NA
This section covers the process that was automated. If you have been involved in more than one automation project answer
the questions with respect to that project with which you have greatest familiarity.
1 What general areas does the automated processes address?
Project Planning
Project Closure
Release Management
Document Management
Supplier Management

Design
Validation/Testing
Deployment
Change Management
Document Review
Other (Specify)
2 What elements motivated the management to consider the use of a process automation?
Time to market
Quality
Metrics
Process Improvement
DK/NA
Other (Specify)
3 Adequate funding for technical development was supplied.
Yes
No
4 How many process-users are (or will be) involved in the automated process?
1-5
6-10
11-20
Over 20
DK/NA
DK/NA
5 Approximately how many elapsed days does (or will) the automated process take from initiation to completion?
Less than 1
1-10
11-100
Over 100
DK/NA
6 How many processes are currently being automated?
0
1
2
3
More than 3
DK/NA
7 How many automated processes are in operation?

0
1
2
3
More than 3
DK/NA
8 Is the automated process currently being used on a day-to-day basis?
Yes
No
9 Approximately how many times per month is (or will) the automated process be executed?
Less than 1
1-10
11-100
Over 100
10 To the best of my knowledge, our current automation activities include:

10.01
Technology-no product purchases made
10.02
Organization is evaluating a specific commercial process automation tool
10.03
Defining first process to be automated
10.04
Developing first implementation
10.05
One implementation running - field trials being performed
10.06
One implementation successfully deployed
If the response to question 10.6 is "yes" then
10.06.01 Is automation of any additional process(es) planned
10.06.02 Is development of any additional automated process(es) underway
10.06.03 Are additional automated processes being implemented with end-users
10.06.04 Are additional automated processes successfully deployed?
DK/NA
DK/NA
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
Yes
Yes
Yes
Yes
No
No
No
No
DK/NA
DK/NA
DK/NA
DK/NA
This section covers issues associated with manually defined process in your organization.
1 A documented process improvement plan is in place.
Yes
No
DK/NA
403
2 Projects routinely:
2.01 Collect metrics on project management data
2.02 Use metrics to support process improvement,
2.03 Use documented processes to perform their tasks
2.04 Meet external schedules
2.05 Meet cost estimates
2.06 Provide appropriate training on tools and methods.
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
DK/NA
3 Do you have any documented processes in manual operation?
Yes
No
DK/NA
4 If 3 is 'Yes', in what areas are these processes automated?

Project Planning
Quality Assurance
Document Review
Other (Specify)

Document Management
5 Was a recognized process definition notation used to define the process

6 If 5 is "Yes" please indicate which notation was used:
IDEFO/SADT
Role Interaction Nets
StateMate
Process Breakdown Structure
Flow Chart
ETVX
Yes
No
Role Activity Diagrams

ProNet
DK/NA
DK/NA
Rummler-Brache
Petri-Net
Other (Specify)
7 The process design is clearly and completely documented
Yes
No
DK/NA
8 Functional requirements were used to define tools embedded in the process
Yes
No
DK/NA
9 Metrics requirements are specified for the process
Yes
No
DK/NA
10 The target process was either (check one):

A new process (no prior manual operation)
Operated manually prior to the automation initiative
If you checked 'operated manually' then:

10.01
Was the manual process documented?
10.02
Was the manual process operated in a stable manner?
11 Process definition (for automation) was more challenging than first thought?
DK/NA
Yes
Yes
No
No
DK/NA
DK/NA
Yes
No
DK/NA
E. The development technology

This section deals with the capabilities of the tool that was used to build the process-centered environments. The section
should be completed only by those who have knowledge of the implementation technology.
1 With which automation tool(s) are you implementing process automation?
Procured from market (COTS)
Procured from market and customized
In-house developed
DK/NA
Strongly
Disagree
Disagree
Agree
2 The major strengths of the process automation tool I used are:

2.01 The process development environment
2.02 Debugging capabilities
2.03 Ability to integrate application tools
2.04 Ability to design effective end-user interfaces
2.05 Ability to collect metrics
2.06 Performance (speed of response to end-users),
2.07 Cross-platform compatibilities
2.08 Customer support
2.09 Availability of training in the tool
2.10 Documentation
2.11 Ease of use of the development environment,
2.12 Cost-effectiveness
Strongly
Agree
For questions 2 through 6, please check the category that you feel is most appropriate:
404
3
4
5
6
Defects in the automation tool affected the development effort.

It is difficult to recover from system crashes.
The automation tool supports a good range of hardware platforms.

This section deals with how the automated process was transitioned into use.
1 How long (in months) has it taken to transition the process to the production environment?
0-2
3-6
7-12
13-24
Over 24
Transition not completed
DK/NA
Strongly
Disagree
Disagree
3 Training was provided to support:
Agree
How long (in months) has the automated process been operating in a production environment (excluding tran-sitioning
time)?
Not yet in production
0-2
3-6
7-12
13-24
Over 24
DK/NA
Strongly
Agree
DK/NA
3.01 Implementers of the process-centered environment

3.02 End-users of the automated process
Statements 4 through 6 deal with end-users' involvement in the development process.
4
5
6
7

Statements 8 through 13 deal with your impressions of end-users' operational experience

8 The automated process improves the effectiveness of end-users in performing
their task(s).
9 The end-users had difficulty in accepting the new process.
10 The end-users feel ownership towards the automated process
11 End-users make suggestions to improve the automated process
12 Metrics have been used to improve the automated process
13 There was resistance to process automation for the following reasons
13.01
13.02
Fear of job loss
13.03
Fear of change
13.04
13.05
End-users feel that they were not consulted sufficiently
in process definition
13.06
Statements 14 through 20 deal with management sponsorship.
14
15
16
17
18
19
20
Senior management is supportive of the process automation project

First-line management is supportive of the automation project
A development plan was agreed to by management
The project has received adequate funding for transitioning
The automation project has a champion with designated authority
21 The automation initiative came from:

Technical staff
Management
A bit of both
Statements 22 through 23 deal with implementation strategy

22 A documented transition strategy was developed
23 A prototyping strategy is being used for implementation
24 The process model is being implemented:
All at once
In multiple incremental phases
Other (Specify)
DK/NA
405
DK/NA
Strongly
Disagree
Disagree
Agree
Strongly
Agree
Those automation projects that have progressed far enough will likely have practical insights of considerable value. We wish
to capture some of these insights in this section. Respondents who have additional insights, not covered in this section, are
encouraged to describe them textually.
1 To date, I consider the process automation project to be a success

2 Based on my experience, process automation has helped:
2.01 Improve end-user productivity
2.02 Improve product quality
2.03 Manage projects more effectively
2.04 Improve communication between end-users
2.05 Improve end-user job satisfaction
2.06 Improve end-user team-building
3 In the context of my application(s) I feel process automation:
3.01 Helps reduce tedium
3.02 Helps prevent errors
3.03 Supports administrative efforts
3.04 Provides useful process guidance,
3.05 Provides timely status information
3.06 Provides useful metric data
3.07 Reduces costs
4 Automation has helped to enforce defined process.
5 The technical implementation was more challenging than first thought
6 How well has the actual schedule for automation met the planned schedule?
Significant delays
Some delays
On time
Ahead of schedule
DK/NA
7 Based on our experience to date, we will automate additional processes
No
What is your job title?

Programmer
Senior Manager
Analyst
First-line Manager
SEPG/Quaity Assurance
Yes
DK/NA
External Consultant
Other (Specify)
IMPORTANT: The information below is optional. If you would like to remain anonymous, leave the spaces blank.
Name:
Organization:
Address:
Business Phone:
e-mail address:
Thank you very much for taking the time to complete the questionnaire
406
APPENDIX II - CURRICULAM VITAE

EDUCATION:
Masters in Computer Applications, PSG College of Technology, Bharathiar

University
Bachelor of Science Mathematics, Nirmala College for Women, Bharathiar

University
ADDITIONAL QUALIFICATION:
PMP from PMI
Six Sigma Green Belt in DMADV and DMAIC
LEAN Leader
Account Management
ALIGN Customer Management
Making Performance Happen Appraisals
Interviewing Skills
Business Continuity Planning
Insurance 101 and 201
Agile Methodology
WORK EXPERIENCE
Wipro Technologies, Bangalore; Duration: June 1998 to May 2010

Roles played: Delivery Excellence Prime, Delivery Manager, Software Quality
Assurance Manager, Project Manager
Patni Computer Systems, Pune; Duration: January 1997 to May 1998

Roles played: Project Manager, Quality Manager
407
Sakthi Finance Limited, Coimbatore; Duration: December 1994 to December 1996

Roles played: Project Manager
A F Ferguson & Company, Chennai; Duration: June 1989 to November 1996

Roles played: Project Manager, Senior Systems Analyst, Systems Analyst, Programmer
NOTABLES:
Award : Dedicated contribution to Quality through innovations

At
: Wipro Technologies, Bangalore
Award : Outstanding Achievement Award for conceptualizing, developing and

implementing integrated Process Automation Tool (iPAT) across the organization
At
: Wipro Technologies, Bangalore
Award : Quality Award for delivery bug free Y2K solution

At
: Patni Computer Systems, Pune
Award : School First in Higher Secondary Examination

At
: Alvernia Matriculation Higher Secondary School, Coimbatore
PUBLICATIONS:
Impact of Technology in Green Movement, International Conference on Global

Marketing Strategies and Practices, October 2010.
Style IT, The Observer of Management Education; Vol 5, Issue 9,

September 2010.
Modern Quality Control Management in Corporate Sector; Observer Of

Management Education; Vol 5, Issue 4, April 2010.
PERSONAL INFORMATION:
Contact Address: 19/23-A, Rehman Sait Colony, Ramanathapuram, Coimbatore-45.
408
Contact No.: (0422)2319114, (0)9994465945 Maid Id: annemartin2324@yahoo.co.uk

Date of Birth
: 23-March-1965
409

Mba Project

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Mba Project

Загружено:

Авторское право:

Доступные форматы

CRITICAL INVESTIGATIONS ON CONTRIBUTION OF PROCESS

AUTOMATION TO SOFTWARE PROJECT SUCCESS

In partial of fulfillment for the award

Faculty of Management Studies

Certified that this thesis titled Critical Investigations On Contribution Of

CONTRIBUTION OF PROCESS AUTOMATION TO SOFTWARE PROJECT

The research is aimed at understanding how Software Process Automation initiative

characteristics, focus on the initiative, development, deployment and training methodologies

Particulars of Organizations participated in this study

Organization culture Vs Projects routinely use metrics

Automated process used on day-to-day basis Vs Other

Metrics requirements are specified for the process Vs

The process design is clearly and completely

Projects routinely use documented processes to perform

Process definition was more challenging than first

Process User Involvement

Use of Functional Requirements

Automation Business Plan written

Capability Maturity Model integrated

Define, Measure, Analyze, Improve and Control

Define, Measure, Analyze, Design and Verify

Institute of Electrical and Electronics Engineers

International Organization for Standardization

Project Management Professional

Project Management Institute

Project Management Book Of Knowledge

PRojects IN Controlled Environments 2

Software Engineering Institute

Software Engineering Process Group

Total Quality Management

Certified Software Development Professionals

83, 174 The thesis needs to establish

Corrections carried out

The first paragraph in Section

a) Section 3.3.5 added to include

b) The first paragraph of Section

c) Figure RM-02: Number of

referenced in each of the

BACKGROUND OF THE RESEARCH................................................................. 2

RESEARCH PROBLEM AND HYPOTHESIS ...................................................... 6

JUSTIFICATION FOR THE RESEARCH ............................................................. 9

OUTLINE OF THE THESIS ................................................................................. 13

DELIMITATIONS OF THE SCOPE .................................................................... 15

Information is the collection of facts through various means of communication

Information can be categorized into deterministic, probabilistic and quantum information.

Today, the term information technology has ballooned to encompass many

Information Technology plays a vital role in various fields. In business

Information Technology comprises hardware that consists of physical components

Software development and sustenance is an activity that involves high stakes.

One very important initiative taken by Software companies is Software Process

1.2 RESEARCH PROBLEM AND HYPOTHESIS

When Computers were first invented, it was primarily used as a number

Eventually, Software organizations adopted various methodologies to implement

The primary NULL Hypothesis is:

contribution by Process Automation on Software Project Success.

Business/Product Characteristics of the Organization

HYPOTHESIS I: A. Business/Product Characteristics has no significant influence on

HYPOTHESIS VIII: D. Process characteristics has no significant influence on E. The

1.3 JUSTIFICATION FOR THE RESEARCH

Need for the Study

Objectives of the Study

To study and analyze Process Automation in Software Industry in light of emerging

Success rates of Software Projects delivered