PROCESS ACCEPTANCE AND ADOPTION BY IT SOFTWARE PROJ.docx

PROCESS ACCEPTANCE AND ADOPTION BY IT
SOFTWARE
PROJECT PRACTITIONERS
by
Deana R. Guardado
RICHARD DANIELS, PhD, Faculty Mentor and Chair
HENRY GARSOMBKE, PhD, Committee Member
SHARON E. BLANTON, PhD, Committee Member
William A. Reed, PhD, Dean, School of Business and
Technology
A Dissertation Presented in Partial Fulfillment
Of the Requirements for the Degree
Doctor of Philosophy

Capella University
June 2012
All rights reserved
INFORMATION TO ALL USERS
The quality of this reproduction is dependent on the quality of
the copy submitted.
In the unlikely event that the author did not send a complete
manuscript
and there are missing pages, these will be noted. Also, if
material had to be removed,
a note will indicate the deletion.
All rights reserved. This edition of the work is protected against
unauthorized copying under Title 17, United States Code.
ProQuest LLC.
789 East Eisenhower Parkway
P.O. Box 1346
Ann Arbor, MI 48106 - 1346
UMI 3512446
Copyright 2012 by ProQuest LLC.
UMI Number: 3512446

Abstract
This study addresses the question of what factors determine
acceptance and adoption of
processes in the context of Information Technology (IT)
software development projects.
This specific context was selected because processes required
for managing software
development projects are less prescriptive than in other, more
straightforward, IT
contexts. Adopting a process that affects how well custom
software is developed and
implemented may be different from would be required in the IT
Infrastructure field.
Levels of acceptance and adoption are ascertained using the
Unified Theory of the Use
and Acceptance of Technology (UTAUT) model first proposed
by Venkataesh, Morris,
Davis & Davis (2003), combining several technology
acceptance models into one that
demonstrated the best fit for studying acceptance of technology.
As suggested by
Venkatesh (Venkatesh, 2006) in a later study, the model was
applied to the study of

process acceptance. Like the original study, this was based on a
survey sent to IT
software development project practitioners who had actually
worked on projects within
two months of conducting the study. Results show that effort
expectancy, attitude, social
influence, facilitating conditions, and self-efficacy are
significant determinants for
accepting process; and that attitude in particular is a
determinant of process adoption. The
original study on technology acceptance found that performance
expectancy, effort
expectancy, social influence, and facilitating conditions were
significant. While the
studies agree on significance of effort expectancy, social
influence, and facilitating
conditions, this study found that self-efficacy and attitude are
also significant, and that
performance expectancy is not. Attitude, in particular,
demonstrated that the respondents
show that processes have also been adopted as a way of doing
business. Implications are

that determinants are somewhat different for technology and
process acceptance in the
context of software development projects. While performance
expectancy is significant
for accepting technology, it was not found to be significant for
this group of people when
applied to process. Developing process should not be a goal in
itself, managed by
professional consultants, but rather developed in context by
practitioners with the
guidance of process professionals to ensure process ―fit‖ for
the work being done. Further
study should be conducted to determine the appropriate level of
process design and
development that provides value to the client. Additional study
should also be conducted
in other context areas of IT, such as Infrastructure Management.
iii
Dedication
This study is dedicated to Jerry Guardado, my husband and life

partner, who
supported my efforts in completing this study. I could not have
done this work without
his support and belief in me. His love and patience through the
challenges of life, as well
as the demands of this study, have given a deeper level of
meaning to the level of
commitment he has toward me, and the things in life that really
matter.
iv
Acknowledgments
My deepest thanks go to Dr. Richard Daniels, who has provided
guidance,
demonstrated patience, and has shared a deep commitment for
presenting the study
clearly, with the highest level of scholarship that I could
produce. He has been an
exemplary mentor and guide for the final dissertation stage in
becoming a PhD.
I would also like to sincerely thank my committee members, Dr.
Sharon Blanton

and Dr. Perrin Garsombke, who have also provided invaluable
feedback, challenged my
thinking with significant consideration on their part, and have
asked thought-provoking
questions that added significant value to the study. Thank you
so much for taking time
out of your schedules to support this effort.
I could not have done this without the help of the company for
whom I work. I
also want to thank the Director of the organization that was
surveyed, Ann Hutchison,
who was instrumental in opening doors so that the study could
be conducted. She also
helped to ensure that the study was appropriate for the
environment. Thank you to Kevin
Higashi, a General Manager in the same organization, who
encouraged me before the
study began, as well as during the course of the study. Sincere
thanks also go to Heather
Rodriguez, my immediate manager, who has been very
understanding and supportive of
the study, being nearly as excited about its completion as I have
been. I also want to
thank Paul R. Jones, PhD, who was also an instrumental mentor

and partner in my study
at the beginning of my journey. My colleagues and peers at the
company have also
provided a lot of encouragement along the way, even those who
are not directly
connected in any way to the study. The members of the Process
Management team in IT
v
have also been very helpful in providing insight on processes in
context, and business
process management in general. Thank you for your support,
confidence, and excitement
with this study.
I also want to especially thank my family for their enduring
confidence in me,
patience with me for all the times I have not been available, and
for believing that this is
important enough for them to modify their activities around
mine.

vi
Table of Contents
Acknowledgments....................................................................
.............................. iv
List of Tables
...............................................................................................
.......... ix
List of Figures
...............................................................................................
.......... x
CHAPTER 1. OVERVIEW OF PROCESS ACCEPTANCE AND
ADOPTION ............. 1
IT Software Project Management
........................................................................... 4
Why Study Software Project Management?
........................................................... 4
Software Project Management as a Discipline
....................................................... 6
Software Project Management and Process Management
.................................... 13
Factors Influencing Software Project Success
...................................................... 14
Factors Influencing Software Project Failures

...................................................... 15
Technology Acceptance Models
........................................................................... 18
History and Background
....................................................................................... 18
Proposal for
Dissertation.............................................................................
.......... 24
Research Question
...............................................................................................
. 25
CHAPTER 2. LITERATURE REVIEW
......................................................................... 28
Business Process Management
............................................................................. 32
Information Technology Process Management
.................................................... 58
Organizational Change Management
.................................................................... 75
Putting it All Together
.......................................................................................... 82
Research Hypotheses
............................................................................................
84
CHAPTER 3. METHODOLOGY

................................................................................... 86
Research
Design....................................................................................
................ 86
vii
Sample....................................................................................
............................... 87
Setting
...............................................................................................
.................... 89
Instrumentation / Measures
................................................................................... 90
Data Collection
...............................................................................................
...... 90
Data Analysis
...............................................................................................
......... 91
Validity and Reliability
......................................................................................... 93
Ethical Considerations
.......................................................................................... 94
CHAPTER 4. RESULTS

...............................................................................................
.. 96
Introduction
...............................................................................................
............ 96
Reliability of the Data
.........................................................................................
100
Research Results
...............................................................................................
.. 102
CHAPTER 5. DISCUSSION, IMPLICATIONS,
RECOMMENDATIONS ................ 127
Performance Expectancy
.................................................................................... 128
Effort Expectancy
...............................................................................................
130
Attitude
...............................................................................................
................ 132
Social Influence
...............................................................................................
... 133
Facilitating Conditions
........................................................................................ 135

Self-efficacy
...............................................................................................
......... 136
Anxiety
...............................................................................................
................. 138
Summary of Determinants
.................................................................................. 138
Conclusions
...............................................................................................
.......... 139
References
...............................................................................................
............ 142
APPENDIX A TRADITIONAL IT PROJECTS COMPARED TO
TECHNOCHANGE PROJECTS
....................................................................... 153
viii
APPENDIX B SURVEY QUESTIONS
............................................................. 155
APPENDIX C RELATIONSHIPS OF SAP EXPORTED DATA
FOR
PRACTITIONER LIST

...................................................................................... 159
APPENDIX D SIGNIFICANCE OF POTENTIAL
DETERMINANTS BY
CONTEXT AND SURVEY QUESTION
.......................................................... 160
APPENDIX E VERBATIM RESPONSES
........................................................ 161
ix
List of Tables
Table 1. Project Management Knowledge Areas
............................................................... 8
Table 2. Core Constructs of Acceptance
Models.............................................................. 21
Table 3. Moderators of Core Constructs
........................................................................... 22
Table 4. Characteristics of the Role of IT in BPR
............................................................ 40
Table 5. Different Definitions of the BPM Life Cycle
..................................................... 49
Table 6. Items Used in Estimating UTAUT for Process

................................................ 100
Table 7. Reliability Scale Using Cronbach's Alpha
........................................................ 101
Table 8. Means of Potential Determinants by Context
................................................... 105
Table 9. Significance of Potential Determinants
............................................................ 109
Table E1.
How IT Processes and Procedures Affect Software Projects
Table E2.
Respondent’s Role in Understanding the Client’s Business
Table E3.
Message to Management
x
List of Figures
Figure 1. Primary research areas
....................................................................................... 32

Figure 2. IT circle of influence
......................................................................................... 65
Figure 3. Screen shot of
survey.....................................................................................
.. 103
Figure 4. Responses coded as attitude
............................................................................ 120
Figure 5. Coding of responses related to client processes
.............................................. 122
Figure 6. Coding of responses relating to other determinants
........................................ 124
1
CHAPTER 1. OVERVIEW OF PROCESS ACCEPTANCE AND
ADOPTION
The things we do every day, by habit or by assignment, are
likely to be driven, in some
way, by a process. Getting up in the morning and getting ready
for work often involve some kind
of informal routine. Leaving home to go to work often involves
going the same way, to the same
place, every day. These activities are generally a matter of
practice, seldom thought about or

subject to much change. If the need for changes should become
apparent, making those changes
very likely affects only one’s personal routines, while not
having much effect on others.
In most organizations, performing work also follows some kind
of routine or process.
Whether formal or informal, there is generally an accepted way
of getting things done in the
workplace. When interactions are required between individuals
or groups of individuals, it often
becomes necessary, in some way, to document or to formalize
these interactions between groups.
These documents might be informal lists of steps that should be
followed; or they could be more
formal. For example, more formality might be appropriate when
agreements need to be made
between individuals or groups, especially when signatures are
required indicating agreement.
Another type of formality might be required to align with
industry standards by documenting the
way an organization follows accepted practices. In the
accounting field, most accountants are
expected to follow ―Generally Accepted Accounting
Principles‖ in order to ensure that financial

statements meet accepted standards for reporting (―Accounting
developments 2009,‖ 2010).
Most organizations document these principles as processes.
Once processes are documented, they are likely to need
improvement. In fact, one of the
key tenets of process management is that there is a need to
continuously improve existing
processes, because of changes in the business environment,
changes in technology, and the need
2
to ensure that production costs are at an optimum level (Paré &
Jutras, 2004). IT practitioners
and their clients, then, should always be seeking ways to
improve business practices (or
processes).
Process improvements are often enabled by IT solutions
(Attaran, 2004; Davenport,
2005; Steuperaert, 2009). In fact, new IT solutions could
actually be described as process
improvements. Clients understand their own business
requirements, and the processes needed to

satisfy requirements. When business requirements change,
process improvements are often
needed in order to respond to, and support change. If new
technology can support those changing
requirements, IT is asked to implement a technology solution.
Clients expect IT to not only
implement the solution, but to also implement the technology in
a manner that that supports their
new and existing processes (Feurer, Chaharbaghi, Weber, &
Wargin, 2000; Ward & Peppard,
2002). IT support, then, becomes critical for success for the
client who implements process
changes with technology.
Because IT’s role is often critical to enabling and adopting
processes within the
organization, IT practitioners could provide additional value by
understanding their role in
enabling their clients to adopt new and improved processes.
Perhaps the best place to gain this
understanding is within IT itself. By reviewing how processes
are acknowledged, accepted, and
adopted within their own environment, IT practitioners will
have the background needed to learn

about and understand their clients’ processes in context.
IT practitioners are accustomed to following procedures, which
are the building blocks of
process. When asked to fulfill an order for a new laptop
computer, for example, IT follows a
standard list of instructions in order to fulfill the request. In
this sense, following process is the
way work gets done in IT. Following process is unique,
however, for software project managers.
3
In a classic software development project, seeing results of
development effort requires waiting
until the project is nearly complete to see success (e.g.,
software that works). Using traditional
software development processes, getting to this point often
takes months of effort with little
evidence of a good technology solution. Following industry-
standard software project
management practices is critical, then, to ensure that each phase
of a project is as successful and
repeatable as possible. Neither the IT practitioners nor their
clients can see whether the software

development efforts have succeeded until the work is nearly
over. Similar to flying an airplane
on instruments only, there are few visual clues along the path to
project completion that can
demonstrate project success. Only when the destination is
reached will the software project
practitioners know whether their efforts have effectively
delivered the product requested by the
client. Because of this lack of visibility into the progress of
developing the final product, failure
is more likely with these IT efforts than those that deliver and
install hardware products. Good,
solid process management is likely the best mechanism for
ensuring that the software project will
succeed. Failed software projects are costly not only to IT, but
to the client who sponsors them.
These project failures result in loss of trust in IT’s ability to
support any future process changes
(Ewusi-Mensah, 1997).
New software development methods have been developed to
address some of the issues
of not seeing the software product until the software
development project is completed. Agile

software development, for example, is a method that develops
or enhances software, showing the
client progress continually throughout the project (Lindstrom &
Jeffries, 2004; Saran, 2004).
This method comes closer to understanding what the client’s
needs are because of constant
feedback from the client. However, this method still does not
help IT or the client determine
4
whether the software being developed or enhanced will truly
address what the client needs to
fulfill their organization’s overall mission.
IT Software Project Management
Why Study Software Project Management?
Managing software projects is fundamentally different from
managing the infrastructure
operations in IT. Infrastructure operations include ordering and
fulfilling hardware requests, such
as servers, network components, cell phones, and similar
devices. The time it takes to fulfill a
hardware order is repeatable and well defined. The processes

and procedures required to fulfill
these orders are also repeatable and well defined. Timelines and
progress on these orders are
easily observed.
Software project management is fundamentally different from
infrastructure
management. For example, progress on an IT infrastructure
project to install Microsoft Office
upgrades on all PCs in an organization is much more visible. In
this case, a project manager can
easily determine when different groups of PCs have been
upgraded. Determining whether the
project is on schedule and within budget is easier; progress can
be observed on specifically
assigned tasks throughout the entire project. However, progress
cannot be as easily observed
when developing software. IT practitioners depend on following
industry-standard practices in
order to measure progress. A project plan outlines the activities
that must be accomplished in
order to deliver a product that meets the client’s needs and
expectations—developing
requirements, engineering the solution, and writing software
code (McDonald, 2001). Observing

project status depends on each team member accurately
reporting progress on their assigned
tasks on the project schedule. Actual evidence of completion of
the development project occurs
later in the project, when the software is actually tested. The
project manager, therefore, must
5
depend upon process artifacts (documentation required by
standardized software project
management rules) as evidence that different tasks have been
completed throughout the life of
the software development project, according to the project plan.
The project plan is the most important part of the process. It
must include, at a minimum,
agreement among stakeholders about what the project is to
accomplish, who will accomplish
different parts of the plan, when the phases will be complete,
how much it will cost, and what
will be delivered at the completion of the project. This is true
whether the software project is
being run as a traditional project, or whether the software

project is being run using newer
methodologies such as Agile Development. There must be a
plan or a ―blueprint‖ for judging
whether a software project is on track, and the project manager
is responsible for ensuring that
the software development project stays on track, according to
the project plan.
In order to manage software development projects consistently
in an organization, a solid
foundation of project management processes is critical (Sharma
& Sharma, 2010). IT must
integrate at least four levels of processes both vertically and
horizontally to be successful. The
lower-level processes are generally step-by-step procedures.
They include Software Engineering
Processes, are more tactical in nature, and focus on software
development activities. This level
includes, but is not limited to, hardware engineering for servers,
networking, and other technical
requirements. Most IT practitioners supporting software
projects focus their work at this lowest
level of detail. The next level, Project Management, is still
tactical, but a higher level than the
technical layer. It includes standard software project

management disciplines such as estimating,
requirements management, and change management. Project
managers, as well as clients,
generally focus their work at this level. Moving toward strategic
processes, the third level,
Program Management, requires coordinating the efforts of all IT
projects so that the organization
6
has a ―big picture‖ view of project work in the organization.
The organization’s financials are an
important part of this process layer. Finally, at the highest
level, the organization’s strategic
Portfolio Management Processes determine how the overall
portfolio will be managed. IT
governance, IT alignment with the organization’s core business
processes, and IT accounting
processes form the highest-level strategic processes.
Software project management processes are critical not only to
IT but also to the
enterprise and their clients. IT projects are often capital
intensive, requiring large investments in

capital and human resources (Ewusi-Mensah, 1997). Because
software development projects can
be very costly for clients, the processes that are used to manage
these projects are important for
IT to not only manage, but to understand. Clients are not as
interested in the processes used to
manage their projects as they are in the end product; but these
processes are critical for
delivering what the client expects—software products that
support their business.
Software Project Management as a Discipline
The practice of software project management, like many others,
benefits from standards
published by the Project Management Institute (PMI). These
standards help define best practices
in how a project should be controlled in the following areas:
project management methodology
(including both formal and informal procedures); project
management tools and information
systems; earned value calculations; and expert judgments
(Hällgren & Maaninen-Olsson, 2005).
A software development organization can leverage the best
practices established by the PMI to
create its own procedures, processes, and project management

disciplines.
Founded in 1969, the PMI was formed to guide the effective
management of any kind of
project. Since the mid-1980s, the PMI’s guidebook, or the
Project Management Body Of
Knowledge (PMBOK), has been widely used as the guide for
managing construction, IT, and
7
utilities projects (Rivard & Dupré, 2009). A non-profit
organization, the PMI has become widely
recognized as the primary body establishing standards for
successful project management,
offering certifications as a Project Management Professional
(PMP), Program Management
Professional (PgMP), and the Certified Associate in Project
Management (CAPM), to name a
few (Du, Johnson, & Keil, 2004).
The PMBOK is comprised of nine primary areas that are
interdependent on each other. A
successful project manager will need to understand all of these
areas, as well as how each of

them change throughout all phases of a project. Du et al.,
(2004) list and describe these nine
knowledge areas (Table 1). As a guidebook, it is designed to
address project deliverables more
than the human side of project management (Reich & Siew
Yong, 2006). Change and process
management are generally left to Organizational Change
Management and Process Management
practitioners, respectively.
8
Table 1.
Project Management Knowledge Areas
Knowledge Area Description
Project integration management A subset of project management
that includes the processes required to ensure
that the various elements of the project are properly
coordinated.
Project scope management A subset of project management that
includes the processes required to ensure

that the project includes all the work required, and only the
work required, to
complete the project successfully.
Project time management A subset of project management that
timely completion of the project.
Project cost management A subset of project management that
that the project is completed within the approved budget.
Project quality management A subset of project management
that includes the processes required to ensure
that the project will satisfy the needs for which it was
undertaken.
Project human resource
management
A subset of project management that includes the processes
required to make
the most effective use of the people involved with the project.
Project communications
management
A subset of project management that includes the processes
required to ensure

timely and appropriate generation, collection, dissemination,
storage, and
ultimate disposition of project information.
Project risk management Risk management is the systematic
process of identifying, analyzing, and
responding to project risk. It includes maximizing the
probability and
consequences of positive events and minimizing the probability
and
consequences of adverse events to project objectives.
Project procurement management A subset of project
management that includes the processes required to acquire
goods and services to attain project scope from outside the
performing
organization.
Note: The above table is from (Du et al., 2004) and describes
nine knowledge areas found in the
PMBOK.
This does not imply that the PMI has the only – or even the best
– project management
practices. Other organizations have also published frameworks
and best practices for managing

different areas of IT (Sharma & Sharma, 2010). Carnegie
Mellon’s Capability Maturity Model
(CMM), for example, provides a set of key process areas that
software development
9
organizations can follow in order to develop software in the
most consistent, efficient way
(―Capability maturity model for software (SW-CMM),‖). The
more mature a development
organization is, the higher the certification level is. The value
of these processes is to help a
development organization grow toward following more mature
software development processes,
resulting in fewer software defects. The Capability Maturity
Model Integration (CMMI)
expanded the original CMM practices to include integration
between development and other
areas.
Other best practice standards include COBIT and ITIL. In an
attempt to provide a
framework for all areas of IT, COBIT (Control Objectives for

Information and related
Technologies) was developed by auditors to focus on risk
management and controls (Bernstein,
2009). COBIT views IT practices from the IT organization’s
viewpoint, more than from the
enterprise or client views. Additionally, the Information
Technology Infrastructure Library
(ITIL) was developed by IT professionals in Great Britain to
manage IT operations activities,
such as Release Management, Change Management, and
Configuration Management (Bernstein,
2009). ITIL focuses on IT practices in specific areas of IT,
rather than from the enterprise or
client views. Each of these models focuses on a different aspect
of Information Technology, and
they are actually more alike than they are different.
Capability Maturity Model (CMM). Since 1986, Carnegie
Mellon’s Capability
Maturity Model (CMM) has been used to not only define what
different levels of software
development maturity are, but to assess organizations on their
own level of maturity (Hardgrave
& Armstrong, 2005).

The CMM model does not prescribe the exact processes that
must be followed. Rather, it
establishes a set of requirements or key process areas that must
be identified, developed, and
10
followed in order to demonstrate software development maturity
in an organization (Debreceny
& Gray, 2009). IT, in conjunction with the organization it
supports, must develop its own key
processes that it will follow in order to deliver software
products with as few defects as possible.
The intent of the CMM is to assist with implementing processes
to address software
development quality issues, not software development project
management. CMM does not
prescribe specific processes, but does establish standards for
managing development processes
(Davenport, 2005). It does this by identifying five levels of
software development process
maturity, moving from one level to the next by adding specific
process capabilities.
At CMM Level 1, an organization has some processes, but they

are primarily ad hoc,
often at the discretion of individual software development
practitioners (Davenport, 2005). At
CMM Level 2, software development organizations follow
basic, repeatable processes to track
costs, schedules, and functionality. These processes support
software project management
processes by beginning to focus on the schedule, scope, and
budget of development as part of a
project. At CMM Level 3, the organization adds additional
software project management and
engineering practices, such as Quality Assurance. The next
level, CMM Level 4, starts
measuring capability by tracking detailed metrics of the
software development processes.
Finally, CMM Level 5 organizations continuously improve to
optimize their processes, using
controlled experiments and feedback from metrics (―CMM
process,‖ 2005).
The benefit of achieving any improved level in the CMM model
is that the software
development process should see improvements in the time it
takes to develop software, the
overall cost of the custom product, and the number of defects in

the final product (Harter,
Krishnan, & Slaughter, 2000). While these improvements are
not normally evident when the
software product is first released, the improvements in quality,
in theory, reduce rework and
11
defects, resulting in a higher quality product with lower overall
costs. The initial increase in
cycle time has been shown to be outweighed in some situations
by lower costs, overall, for the
software project. CMM also supports the theory that spending
additional time in planning and
analysis results in a better product and reduced time in fixing
defects that appear in the later
stages of software development (Kumari, Sharma, & Kamboj,
2009). In this way, CMM supports
not only the IT organization, but also the entire enterprise,
including the client’s organization, by
reducing overall cost and improving software functionality for
the client.
The road to CMM Level 5 is a long and arduous one, and is not
taken by most software

development organizations. Some industries, however, require
some level of CMM certification.
The U.S. military, for example, requires software development
companies that they work with to
have achieved a CMM Level 3 certification. Results indicate
that software produced for the
military has one-sixth to one-tenth the error rates of
commercially developed software
(Davenport, 2005).
ISO standards. While the Capability Maturity Model is
specifically associated with
processes for developing software, it is not the only standard or
model for software development
process. The International Organization for Standardization
publishes a number of process
standards, including one for software development quality –
ISO 9000-3 (―ISO IEC 90003 2004
software standard translated into plain English,‖ 2010). The ISO
20000 standard covers project
management practices (Bernstein, 2009). Currently in
development, ISO standard 21500 will
establish project management standards for the international
market. While the PMBOK has

been used widely in the United States as a guidebook for
managing projects, it has not been
accepted worldwide as such. To help address this, the PMI is
participating with many other
organizations and the International Organization for
Standardization to complete new project
12
management standards by the end of 2012 (Best, 2011). Rather
than replacing the PMBOK, the
ISO 21500 standards will provide project managers worldwide
with common standards, not
common practices. The two are compatible, focusing on
different areas in managing projects.
Information Technology Infrastructure Library (ITIL). Another
focus area within IT,
not limited to project management, are the Information
Technology Infrastructure Library (ITIL)
standards. ITIL addresses service management, largely in the
area of IT Infrastructure activities.
These standards are not as widely adopted as the PMI standards,
but are gaining wider
acceptance among organizations in the United States (Garbani,

2005). ITIL standards were
developed in the United Kingdom; they are becoming accepted
as the standard for service
management practices, including configuration management,
change, and release management
(Gomolski, 2004). ITIL’s purpose is to summarize best practices
in the industry, to improve IT
and contain costs for attaining high-quality IT products
(Garbani, 2005). IT software
development projects are not specifically addressed by ITIL, but
these standards support projects
by helping to ensure that project changes are implemented
properly.
Control Objectives for Information and Related Technologies
(COBIT). The Control
Objectives for Information and related Technologies (COBIT) is
a framework for managing
controls and metrics across the Information Technology
function. It provides a global view of IT
processes and management principles, more so than ITIL, which
is more focused on the IT
Infrastructure area (Garbani, 2005). As a framework, COBIT
(version 4) focuses on 34 key areas
aimed at IT governance controls, a benefit to the enterprise. A

key benefit of COBIT is that is
enables an organization to structure its IT processes and
controls in alignment with the
organization’s overall strategies (Syndikus, 2009). The four
structural areas of COBIT are: Plan
and Organize, Acquire and Implement, Deliver and Support, and
Monitor and Evaluate.
13
Monitoring controls for software project management fits within
the Plan and Organize area,
while controls for many of the ITIL processes fit within the
Deliver and Support area.
Summary of standards. Each of these preceding areas
complements one another, and
each has a different focus. ITIL standards guide IT
Infrastructure activities. COBIT provides a
framework for organizing and controlling most, if not all, work
that a typical IT organization
performs. CMM provides key performance areas for software
development, a component of
COBIT’s Acquire and Implement. As a standards organization,
ISO fills in the blanks that the

others do not address in its treatment of security processes and
controls (Garbani, 2005). Each of
these, in turn, has a role in defining or supporting software
project management success. It is also
important to note, however, that none of them specifically
addresses the client, or human side of
project management. This is generally left to Organizational
Change Management (OCM)
practitioners and often ignored by software project management
processes.
Software Project Management and Process Management
Each one of the frameworks discussed above contributes to
improving the work of the IT
industry (Sharma & Sharma, 2010). The CMM enables an
organization to assess its software
development process maturity. CMMI, which is an expanded
version of the CMM, provides
more efficiency in software development practices but not
necessarily software project
management. The PMBOK’s guidelines are meant to increase
efficiency, and therefore
contribute to success, in managing software development
projects. These are only guidelines,

however, not prescriptive processes per se.
Separate from software project management, process
management is actually a distinct,
relatively recent discipline that has just recently been
recognized by several of the top journals in
the industry (Houy, Fettke, & Loos, 2010). Process management
provides an organization with
14
tools to indicate what should be done in specific situations, and
with procedures that provide the
hands-on tools to indicate how processes should be performed.
IT software project practitioners,
however, have not been trained specifically to recognize the
role of processes and procedures as
a key enabler for implementing software. Within IT, processes
and procedures show IT
practitioners how that organization manages its work, especially
in conforming to industry
standards. IT’s clients also depend on processes and procedures
to perform their work. The IT
products they request support those business processes and
procedures. The enterprise within

which IT and its clients work also benefits from the lower costs,
improved quality, and
efficiencies gained by following established processes and
procedures, measured by the metrics
captured in various process areas.
Factors Influencing Software Project Success
Three of the most common indicators of project success are time
(schedule), cost
(budget), and performance (scope) (Basu & Lederer, 2004).
These three indicators, along with
customer satisfaction, indicate whether a project was completed
successfully, whether it
delivered what the customer expected, whether the project cost
what was expected, and whether
it was delivered in the expected timeframe. These factors are
important for all software projects,
whether delivering custom-developed software, or implementing
standard, off-the-shelf software
packages. These three indicators are measurable, common to
software project management, and
can be used to compare an IT department’s performance with
industry benchmarks.
Good software project management is important to a project’s

success. Developing
maturity in managing software development projects, however,
is not easy, nor is managing a
large number of projects an indicator of maturity in project
management. In 1986, the United
States government asked the Software Engineering Institute
(SEI) to develop a standard for
15
measuring a contractor’s ability to manage software projects
(Debreceny & Gray, 2009). The
SEI, then, developed a questionnaire in 1987 that was intended
to gauge an organization’s
capabilities along a standard framework to judge maturity and
capability to deliver good
software project management. The difference between this
framework and other standards at the
time (e.g., ISO 9000 or AQAP) was that it emphasized
improvement toward higher maturity
levels (Debreceny & Gray, 2009).
Pre-established, best-practice processes can guide software
project practitioners in

running successful projects (Project Management Institute,
2008). These processes are assets to
an organization, and include formal and informal plans,
policies, procedures, and guidelines.
Over time, an organization adds its own lessons learned and
customized procedures to its process
assets, increasing the value of the processes to the organization.
Project team members contribute
to these lessons learned and updated procedures. Improving the
quality of project management
processes also improves the quality of project results. As the
appropriate knowledge, skills,
processes, tools, and techniques are applied to software project
management practices, better
software products are delivered (Project Management Institute,
2008).
Factors Influencing Software Project Failures
Even with all these project management tools available, not all
software projects succeed.
Software that is delivered to the client may not have the
features or quality that the client
expected. One study indicates that only about 25% of software
projects are considered successful
(Hardgrave, Davis, & Riemenschneider, 2003). According to

another study, 40% of software
development projects are cancelled before they finish; at least
35% of the remaining projects fail
to meet promised schedule, scope, or budget projections (Peng
& Carl, 1999).
16
Some of the causes for not meeting expectations can be
attributed to poor software
project management. When a software project manager does not
follow established processes or
software project management best practices, projects are less
successful. Not determining the
client’s requirements, not defining tangible results, and not
defining a project’s scope are all
mistakes in software project management that contribute to
failed projects (Peng & Carl, 1999).
In some cases, the problems with software projects are cultural:
the organization does not
reward project managers who escalate issues with their failing
projects (Keil & Robey, 1999). In
fact, organization managers who direct software project
managers are often likely to continue

working on failing projects in hopes that something will cause
the projects to somehow turn
around and succeed. Management of these organizations must be
able to recognize issues and
take action to turn projects around, well before they become
failures.
In spite of the impact to the organization’s success, most
organizations do not keep
records or analyze metrics about failed software projects (K.
Ewusi-Mensah & Przasnyski,
1995). Feedback from software development projects comes, in
fact, from analyzing the number
and types of maintenance requests for an application after it has
been implemented. After a new
or updated application is implemented, the number of support
requests immediately after
implementation can be analyzed in order to determine whether
the project that just completed
was, in fact, successful. An organization can choose to use this
information to improve its
software development project processes or to discover where
existing processes are not being
followed.

Another indication of a failed technology project, at least in the
clients’ eyes, is that the
technology implemented is not used as intended. If the end
users of a new system resist using it,
an otherwise successful project can be totally undermined
(Hardgrave et al., 2003). This is a
17
major risk inherent in IT projects. Surprisingly, the project
management discipline does not
address this ―people side of project management,‖ the
individual user resistance to change
(Markus, 2004). Project managers are not trained to think about
addressing resistance to the new
system, but generally leave this up to the client organization
that is requesting the new
technology.
Client organizations that are aware of this project risk may
choose to use some kind of an
organizational change management (OCM) strategy to address
the change brought by a new
technology solution (Markus, 2004). These OCM efforts can
help a project to succeed better than

it would have without the OCM activities. But to understand
what makes people resist a system
in the first place requires more than following steps to prepare
them for a specific new software
solution. It requires studying what can influence people to
accept technologies in general.
Process standards for software project management do not focus
on the software product’s ―fit‖
to the client organization, or the organizational changes that
might be required as a result of
implementing the software. The impact to the client
organization could be minimized if software
project practitioners were not only following good development
and project management
processes, but also including an analysis of the client’s
processes when designing new and
enhanced software. This kind of analysis is not normally part of
an organization’s OCM
activities.
While OCM has provided many tools for studying
organizations, and change within
organizations, it does not specifically address resistance to
implementing technology. OCM

focuses on the organization side of change, not the technology
side of change. In order to address
this, a number of Technology Acceptance Models (TAM) have
been proposed to try to
understand what influences users’ intentions to accept new
technologies (Fisher & Howell,
18
2004). Simply put, TAM models suggest that users are more
likely to accept new technology if
they perceive that it is easy to use, and will help them get their
jobs done. A number of studies
have been conducted to test these models related to technology
acceptance (Hardgrave et al.,
2003). The knowledge gained from studying TAM models can
increase success in managing
software projects, because it provides information on the
―people side‖ of projects. This is not
addressed by the more standard IT project management
practices already discussed. TAM is not
necessarily understood or addressed by software project
management standards.
Technology Acceptance Models

History and Background
When users resist using a new system, the investment that was
made to implement the
system does not produce the return that it could have (Paré &
Jutras, 2004), either in investment
dollars or in gains in productivity, even if the new system
technically meets user requirements.
This is expensive to an organization, and it can be avoided—or,
at least reduced—by
understanding the factors that influence acceptance of
technology.
To this end, a number of technology acceptance models have
been proposed and studied.
While each of these models has a different focus, each is based
on the same concept—individual
end users of technology will have different reactions to using
new technology, depending on a
variety of factors. These reactions influence an individual’s
intent to use the new technology,
which in turn influences the actual use of the new technology
(Venkatesh et al., 2003). This
concept can be displayed as a linear process that can reoccur as
individuals react to using

information technology. As a person reacts to an aspect of using
the new tool, that person forms
the intent to use or not to use the new tool, which in turns
results in behavior (use or non-use).
The cycle may repeat as the person learns more about what the
tool does or does not do.
19
Technology Acceptance Model (TAM). One of the first of its
kind, the Technology
Acceptance Model attempts to model what determines
acceptance of new technologies. It is
thought that those with a higher degree of self-efficacy, or a
higher belief about their own ability
to influence those events that affect their lives (Bandura, 1994),
are more likely to accept a new
technology (Fisher & Howell, 2004).
TAM is based on the belief that new technology is more likely
to be accepted if it is
perceived to be useful in getting one’s work done more
effectively. The new technology must
also be perceived as being easy to use. These beliefs about a
system’s ease of use and usefulness

are predictors of a user’s intent to use a new technology system
(Agarwal & Prasad, 1998).
Theory of Planned Behavior (TPB). Going beyond intent, this
theory is based on the
idea that an individual’s intent to adopt a behavior captures the
motivations behind doing so; that
the intentions indicate how hard a person is willing to try, and
how much effort that person is
willing to exert, to perform whatever the behavior is (Eckhardt,
Laumer, & Weitzel, 2009).
Intentions are influenced by the attitude held toward the
behavior, as well as the attitude that
one’s peers hold toward the behavior as well. Those intentions
form a plan to adopt behaviors,
whether informal or formal, known or unknown. Central to this
model are the influence of
attitude, subjective norm, and perceived control (Venkatesh,
Davis, & Morris, 2007). The Theory
of Planned Behavior has been used in studying a variety of
behavioral questions, such as ethical
decision making, the decision to smoke, and other problems
(Venkatesh et al., 2007). TPB asks
questions related to one’s intent to act. Combined with TAM,
which asks questions related to a

tool’s usefulness, a better picture can be formed of how a tool’s
characteristics might modify a
person’s intent to use the tool.
20
Unified Theory of Acceptance and Use of Technology
(UTAUT). There have been
several variations of TAM models proposed. In a study designed
to synthesize the best of the
most widely used individual acceptance models, Venkatesh et
al. (2003) designed the Unified
Theory of Acceptance and Use of Technology. This model
compares each model’s constructs to
determine which factors are the strongest indicators of
individual acceptance of technology.
Indicators of adoption are also included. Additionally, it
compares the common modifiers of the
constructs, which are the factors that could affect how much
each of the constructs influences
individual behaviors. A comparison of these factors is displayed
below (Table 2).

21
Table 2.
Core Constructs of Acceptance Models
Model/Theory Name Core Constructs
Theory of Reasoned Action (TRA) Attitude toward behavior
Subjective norm
Technology Acceptance Model (TAM) Perceived usefulness
Perceived ease of use
Subjective norm
Motivational Model Extrinsic motivation
Intrinsic motivation
Theory of Planned Behavior (TPB) Attitude toward behavior
Subjective norm
Perceived behavioral control
Combined TAM and TPB (C-TAM-TPB) Attitude toward
behavior
Subjective norm

Perceived behavioral control
Perceived usefulness
Model of PC Utilization Job-fit
Complexity
Long-term consequences
Affect towards use
Social factors
Facilitating conditions
Innovation Diffusion Theory (IDT) Relative advantage
Ease of use
Image
Visibility
Compatibility
Results demonstrability
Voluntariness of use
Social Cognitive Theory (SCT) Outcome expectations –
performance
Outcome expectations – personal

Self-efficacy
Affect
Anxiety
Note: The above table lists the core constructs of a variety of
acceptance models described in
Venkatesh et al. (2003)
In the study mentioned, Venkatesh et al. (2003) studied the
ability of each of these factors
to predict acceptance and adoption of new technologies. The
results indicated that the following
22
four constructs were the strongest predictors of whether users
would accept new technology:
performance expectancy, effort expectancy, social influence,
and facilitating conditions. The
study also found that, by comparing the same eight models,
these four constructs were most
likely to be moderated by age, experience, gender, and the level
of voluntariness (Table 3). Each
of these influencing factors was then studied to determine

whether it was a key determinant in
affecting someone’s intent to use the technology, and in fact
whether the technology was used.
Table 3.
Moderators of Core Constructs
Model
Moderators Studied
Experience Voluntariness Gender Age
Theory of Reasoned Action X X
Technology Acceptance Model (and TAM2) X X X
Motivational Model
Theory of Planned Behavior (TPB) X X X X
Combined TAM–TPB X
Model of PC Utilization X
Innovation Diffusion Theory X X
Social Cognitive Theory
The resulting model, the Unified Theory of Acceptance and Use
of Technology
(UTAUT), was then used in a study to validate the model
(Venkatesh et al., 2003). The authors

found that the model performed better than any one of the other
models that were used as a basis
for determining the constructs and moderators, accounting for
70% of the variance in intent to
use technology.
Theory base to study other areas. The UTAUT model then,
introduced in 2003, was
constructed from eight different models that had been used to
test determinants of intent to use
23
technology. Each of these models had been established as ways
to study a variety of aspects of
behavior. When a model has been used successfully in a given
domain, it is often used as a basis
for study in a different domain (Venkatesh et al., 2007). In fact,
models studying acceptance of
technology have been used in studies outside the field of IT,
such as acceptance of green
technology and innovations in dairy farming. Technology
acceptance research, then, has had a
significant impact on studying problems relevant to acceptance,

adoption, and intentions to
change behavior (Venkatesh et al., 2007) in a number of areas.
Acceptance and adoption of process, especially when it is
associated with technology,
could have significant influence on the success of an
organization’s goals. Knowing what makes
IT professionals accept and adopt processes will not only
benefit IT, but will also IT’s clients.
When IT professionals understand the important role that
processes play for their clients, enabled
by the software they develop, they are better equipped to deliver
quality products. This benefits
IT, their clients, and potentially the enterprise, when large,
enterprise-wide systems are
developed and implemented, such as Enterprise Resource
Planning (ERP) systems (Gosain,
2004). This requires more than Organizational Change
Management, which attempts to prepare
people for an organizational change. This technology-behavioral
acceptance approach, combined
with project management and OCM practices, focuses on
managing not only the development
project, but also those factors that consider the new tool, what it
takes for users to accept the tool,

and the processes and organizational factors that will change
because of the tool. Understanding
the determinants of process acceptance and adoption is key to
the success of this approach. Using
the Technology Acceptance Model could be used, then, as a tool
for understanding and testing
determinants of process acceptance and adoption, especially in
the context of new technology.
24
Application to studying process acceptance. The Technology
Acceptance Model has
been used to study a variety of situations outside of IT:
marketing, green electricity use, dairy
farming, as well as decision support systems, scheduling
systems, and executive information
systems (Venkatesh, 2006). In fact, Venkatesh (2006), who was
one of the authors of the
UTAUT, poses the question, ―where to go from here?‖ How
can the model be applied in other
contexts?
The introduction of new technologies sometimes introduces

change so radical that
processes must be modified (Attaran, 2004; Besson & Rowe,
2001; McLagan, 2002). These
process changes affect the organization at a macro level, but
also at an individual level, and can
result in resistance to process change among individuals in the
organization (Besson & Rowe,
2001).
The organizational change management literature describes
many potential causes for
failure when changes occur that affect the organizational
structure. Few studies, however, have
focused on job change as a result of a change in process, or on
individual acceptance of
processes (Venkatesh, 2006). Little research has focused on
individual employees and the drivers
of accepting and adopting processes, factors influencing
resistance to process change, impacts of
process change on employees (both in their job functions and as
individuals), or potential
interventions that can make acceptance and adoption of process
easier. Research needs to be
done to explore not only technological predictors of process
acceptance, but characteristics of

intent to adopt business processes and relevant outcomes
(Venkatesh, 2006).
Proposal for Dissertation
In order to contribute to knowledge about what influences IT
software development
project practitioners to accept and adopt processes, this study
conducted a survey with a group of
25
IT practitioners who support software development projects in
some way. This group included
project managers, who must follow certain processes in order to
deliver a project on time, within
scope, and within budget. It also included software developers,
who also follow industry-specific
processes for software development, as well as organizational
processes that contribute to
successful project management. Finally, systems analysts,
testers, and project support personnel
were surveyed, who follow processes, though to a different
extent, than software developers, but
also are key players in software project success.

The survey questions addressed the constructs comprising the
Unified Theory of
Acceptance and Use of Technology, as well as the moderating
factors in that model (experience,
voluntariness, gender, and age), in the context of enterprise-
wide processes, IT-wide processes,
job-specific processes and procedures, and client processes.
Both quantitative and qualitative
questions were asked, to provide a mechanism for not only
measuring the range of acceptance
and adoption, but also to provide a means for respondents to
provide verbatim feedback on open-
ended questions regarding beliefs and attitudes. The
quantitative responses to the survey were
compiled using SPSS; and the qualitative responses were coded
using nVivo, The survey’s intent
was address the following research question.
Research Question
What are the determinants of acceptance and adoption of
process by IT software
development professionals, where the process change is driven
by technology, and the IT
professionals have varying awareness of process change enabled

by the very products they
develop and deliver to the groups they serve?
This question addresses the factors that determine both process
acceptance and adoption.
Acceptance implies that a person has given mental assent to the
intent of a process or procedure,
26
but has not necessarily personalized it to the extent that the
process or procedure has become the
preferred method for performing work. Adoption, on the other
hand, implies that the processes
and procedures have become the preferred method for
performing the activities described by
processes and procedures, and that attitudes and behavior have
changed. Adoption indicates that
a fundamental change has occurred, incorporating the new
concept into one’s thinking.
Acceptance, on the other hand, does not require any level of
commitment other than mental
assent that the change (or process) exists but does not require
anything more than

acknowledgment.
The level of acceptance or adoption is difficult to observe, but
can be ascertained by
asking IT practitioners themselves what they believe about their
own processes: accepting them,
adopting them, or even ignoring them. Using the Unified Theory
of the Use and Acceptance of
Technology as a model, acceptance can be determined by how
easy processes are perceived to be
to use; how much effort the processes appear to take to use;
whether one’s peers expect
acceptance or adoption of processes; and any facilitating
conditions that might make it easier to
accept processes. Each of the questions in these areas could
then be correlated with their intent
to use processes. Adoption can be measured by respondents’
attitudes about processes in general,
and how they are related to intent to use processes.
This acceptance or adoption may be different, depending on
who ―owns‖ or governs the
results of the processes. If the process, procedure, or job
instruction comes from the enterprise
level (such as those required by implementing an Enterprise
Resource Planning system), it is

possible that an IT practitioner will have a different incentive to
accept or adopt the process. In
the case of enterprise-wide processes, it is expected that
everyone accept and adopt processes
across the entire enterprise. This is often mandated by the
enterprise, emphasizing at a minimum
27
the acceptance of the process. If the process, procedure or job
instruction is owned by the IT
organization, acceptance or adoption may not carry the same
mandate as those owned by the
enterprise. IT-wide processes are those that the IT organization
expects all of its members to
follow. In the case of IT software projects, following these
processes may be demonstrated by
using templates or forms that are common to IT in order to
support the work that IT performs.
Understanding client-related processes can best be demonstrated
by asking IT practitioners
themselves whether they understand or consider client processes
in fulfilling their work requests.

The following literature review will discuss why process
acceptance and adoption are
necessary for the enterprise, for IT, by IT for their clients, and
how the Technology Acceptance
Model supports the research question.
28
CHAPTER 2. LITERATURE REVIEW
Understanding how business processes are accepted and adopted
in Information
Technology software development projects requires
understanding three key domains: Business
Process Management (BPM), Information Technology Process
Management (ITPM), and
Organizational Change Management (OCM). Each of these
research areas contributes in a
different way to understanding how IT professionals
individually adopt, modify, or reject
changes to processes that affect their work, as well as their
clients’ work. Process changes can
occur across the enterprise, within IT, or within IT’s client

organizations. In effect,
understanding these three domains can work together to help IT
practitioners perform at their
best.
As a discipline, Business Process Management is relatively new
(Trkman, 2010), only
recently being included in top-class peer-reviewed journals
(Houy et al., 2010). This section of
the literature review includes a brief history of BPM, how
adopting a process focus benefits
business, the challenges of becoming a process-focused
business, and various standards for
creating processes. A background in BPM is important in order
to conceptualize how process
management is implemented not only in an enterprise setting,
but in IT organizations in
particular. This in turn contributes to understanding how an IT
professional might approach
implementing processes within IT, as well as for their clients.
The next section of this review discusses the Information
Technology Process
Management domain. ITPM is closely aligned with BPM,
because IT implements software

projects and related technologies that enable business process
management. When managing
software projects, for example, IT provides expertise for
implementing the business processes
that the software provides (Attaran, 2004)—but only in the
context of that particular software. In
29
a typical software project, IT does not generally view process
across the enterprise, or in an
―end-to-end‖ context. This somewhat myopic view of process
(e.g., within a software project
only) is less effective than looking at process as a whole, for
the organization as well as for IT. In
this sense, IT enables a business to improve its processes, but
does not necessarily view process
change as part of what is delivered to the client. In fact,
development and adoption of processes
within IT can be inconsistent. A lack of process focus in IT
contributes to less disciplined work
practices, leading to inconsistencies in product quality, and
potentially software project failures
(K. Ewusi-Mensah & Przasnyski, 1995).

Perhaps more than any other area within IT, the software
development group is most
likely to resist adopting processes. This is because the software
development process is
fundamentally different from other, more tool-specific
processes within IT (Harter et al., 2000).
Many of the IT functional areas take orders, e.g., to fulfill a
request for a new laptop, server, or
architectural service. The mentality behind these kinds of
requests is relatively simple: IT
receives a request for an order; the order goes through a
standard process for acquiring whatever
is ordered; the item is configured for use, and then it is either
installed or delivered. The
processes and procedures supporting this type of work are short-
term, well-defined instructions
specific to fulfilling orders.
Software development projects, however, are more dependent on
the creativity and skill
of development practitioners, business analysts, and systems
analysts, working from a set of
business requirements that may or may not be well established
at the beginning of the project. A

typical software development project might follow the
―waterfall‖ model, where the
requirements are often not well understood until the project has
gone through the development
phase. By then, the project is well underway. Getting to that
point of good business requirements
30
takes more than a simple order fulfillment process. It takes the
creativity, technical development
skills, and interpersonal relationship building skills of software
project participants—especially
developers (Glen, 2003). Because creativity is such an
important part of the development
process, then, conforming to a process that defines specific
steps to follow could actually
prohibit a developer from having the perceived freedom to
create software that meets clients’
needs. The software project processes must be compatible with
the developer’s own
development methods in order to support the creativity required
(Hardgrave et al., 2003).
Furthermore, software developers have been trained to follow

specific development
methodologies, such as object-oriented programming or
structured programming methods. Their
training has not focused on following project process standards,
but on development
methodologies (Schambach & Walstrom, 2002-2003).
Failed IT projects are very costly to a business (Harter et al.,
2000). They are costly not
only in hard dollars wasted in projects, but also in lost
productivity and opportunities to improve
a business. The literature review explores IT’s role in software
project failure, but also client
difficulties in accepting new technologies. To address issues
with clients accepting new software,
as well as the resulting changes in process, several Technology
Acceptance Models have been
proposed by a variety of experts. These acceptance models are
based on behavioral studies that
propose and test some determinants of IT product acceptance
(Agarwal & Prasad, 1998). The
literature review shows how these models have been applied
successfully to understand why
people adopt new technologies and methods, changing their
behavior. A specific technology

acceptance model has been modified to apply to processes, and
used in the research study to
ascertain process acceptance and adoption by IT software
project professionals.
31
A third, very important factor in accepting process change is the
domain of
Organizational Change Management (OCM). While OCM does
not specifically address
acceptance of IT products, nor acceptance of process changes, it
can address some of the more
common organizational issues that occur because of process
changes. Within the context of IT,
the concept of ―technochange,‖ which is an approach
combining project management and change
management principles, contributes significantly to the practical
means for implementing process
changes within IT (Markus, 2005), and has been included in the
literature review.
A clear understanding of each of these three domains (Business
Process Management,

Information Technology Process Management, and
Organizational Change Management) is
necessary to understand the context of study, which is to
propose the determinants of process
acceptance and adoption by IT professionals who participate in
software projects. Process
acceptance implies that processes are agreed as being the way
things are done in context.
Process adoption, on the other hand, implies a deeper level of
assent—using the accepted
processes has become a way of life. Both acceptance and
adoption are important when
understanding whether a specific factor is a determinant of
acceptance (or lack of resistance),
and whether that factor is a determinant of full process
adoption.
The study of BPM contributes to the research by providing the
background of the role of
process in organizations. The study of the ITPM contributes to
the research by setting the stage
for not only the field of ITPM, but also for the practitioners
within the field of IT. Finally, the
study of OCM provides the background in the context of
behavioral science, or how to manage

changes within organizations successfully. The following
diagram depicts these three domains
intersecting; that intersection of their common areas will
provide the basis for the research
(Figure ).
32
Figure 1. Primary research areas
In summary, then, these three concepts can work together to
provide the best quality
products and services to IT clients: Business Process
Management, IT Process Management
(specifically software project management), as well as
Organizational Change Management. The
following three sections describe, in detail, how each of these
contributes to quality products and
services from IT.
In order to understand the role of Business Process Management
(BPM), the basic
definition of a business process, which is the core of BPM, must

first be addressed. A business
process is a set of defined activities that must be performed in
order to provide value to the
customer or to fulfill strategic goals (Trkman, 2010). The
customer can be the business itself, or
an internal or external entity that derives value from the
activities of the business. Within a
33
process, specific procedures provide step-by-step directions on
how to complete specific tasks,
and are considered process assets (2008).
The idea of creating core business processes comes from Adam
Smith’s original idea that
a company’s work ought to be broken down into its simplest
tasks and standardized in order to
optimize performance. Managing work as standardized tasks has
matured into the concept of
business process management (Hammer & Champy, 1993b).
BPM, then, is a structured approach
to analyze, continually improve, and monitor the fundamental
activities that a business performs

in order to provide value to its customers (Elzinga, Horak, Lee,
& Bruner, 1995). It enables an
organization to better meet its customers’ needs, as well as to
more quickly adapt to changes in
what customers want. It helps an organization maintain
competitive advantage, because being
able to respond to changes in a customer’s needs will put that
business in a position to respond
more quickly (Neubauer, 2009). Business activities managed by
BPM can include manufacturing
processes for firms that deliver physical products, core business
processes that every business
must manage, and processes that contribute to services that a
company provides for value. Core
business processes that are common to most businesses include
supply chain management,
human capital management, enterprise asset management, and
finance (Ravesteyn & Batenburg,
2010). These business-level processes have been referred to as
―enterprise-level processes‖ for
this research.
BPM is also described as ―a field of knowledge at the
intersection between Business and
Information Technology, encompassing methods, techniques and

tools to analyze, improve,
innovate, design, enact and control business processes involving
customers, humans,
organizations, applications, documents and other sources of
information.‖ (van der Aalst, ter
Hofstede, & Weske, M. (2003), in Ravesteyn & Batenburg,
2010) This definition of BPM clearly
34
indicates that business processes and information technology
are interdependent; in fact, IT
actually enables BPM (Al-Mashari, 2002; Holland & Skarke,
2008; Ko, Lee, & Lee, 2009;
Pantazi & Georgopoulos, 2006; Trkman, 2010). In other words,
tools are more effective when supported by Information
Technology tools, methods, and
processes.
A primary goal of BPM, then, is not only to establish common
processes, but to improve
existing processes, intended to result in higher customer
satisfaction. These improved processes

drive higher efficiency, increased productivity, reduction of
costs, increased customer
satisfaction and higher quality (Neubauer, 2009). Excellence in
business process improvement is
so important that it is recognized annually by the National
Institute of Standards and Technology
by awarding the Malcolm Baldrige National Quality Award. In
1981, this award was established
to recognize performance excellence and to focus industry on
continuous improvement. The
award is given to organizations that have set themselves apart
as leaders in improving business
processes (Elzinga et al., 1995).
Processes are collections of activities that are intended to
produce outputs that customers
want. Lower-level procedures are components of larger, end-to-
end processes that produce at
least one specific outcome (Benner & Tushman, 2003). An
example of this might be the end-to-
end process of employee management, from hiring an individual
to the day that that individual
retires. There are lower-level procedures for handling hiring,
onboarding, career management,
retirement planning, and finally retirement; but all of them are

parts of one overall process,
human capital management.
In practice, BPM process improvement activities generally fall
into one of four
categories. The first is to address the smaller, localized
processes or procedures for incremental
35
improvements, usually in one functional department. These
kinds of smaller changes are more
likely to limit improvements (and therefore benefits) to the
functional organizations within which
improvements are made. The second category, end-to-end
process improvement, takes more
effort but also can also result in larger, more measurable
changes. This second category is
generally understood as process reengineering. Its scope is
larger, more difficult, and more
costly. It often requires shifting from a functionally viewed
organization to a process-focused
organization. A third category is to introduce automation and
software workflow management

such as is found in an Enterprise Resource Planning (ERP)
system. These process improvement
efforts often take years to implement. A fourth category for
process improvement, post-system
implementation of process improvements, follows a system
change with additional
improvements, enabling components of a system that were not
included in an initial release of
the system, or even operationalizing additional features of a
system-enabled process change that
the business was not yet ready to implement (Subramoniam,
Tounsi, & Krishnankutty, 2009).
When core business processes are managed, changes in the
business environment can
more easily and more quickly be accommodated (Neubauer,
2009). As the market changes and
as customer demands change or shift, business must adapt to
these changes. Making necessary
adaptations quickly becomes possible when core processes are
actively managed. Activities that
contribute to the value that a business provides to its customers
are continuously improved, using
BPM software, techniques and methods.
History of Business Process Management (BPM). Business

Process Management is
primarily a cross-discipline ―theory in practice‖ that continues
to develop. Practitioners hold
different views, have different backgrounds, and approach the
subject from a variety of
viewpoints, from theoretical to behavioral (Ko et al., 2009).
36
Process management as a discipline began with the works of
Ishikawa in 1985, Deming
in 1986, and Juran in 1989 with the introduction of Total
Quality Management (TQM) (Benner
& Tushman, 2003). TQM began the process improvement
discipline as ―continuous
improvement,‖ by making numerous, smaller process
improvements that together lead to a
higher quality product (Schniederjans & Kim, 2003).
As TQM and other quality programs evolved, the discipline of
Business Process
Management began to emerge. Recognized experts in the BPM
field begin with Michael Porter,
who pioneered the concept of competitive advantage through

differentiation in optimizing
internal processes (Harmon, 2007). Porter taught that a business
with optimized internal
processes not only performs better, but would be preferred by
customers. Optimizing processes
better than the competition enables a business to differentiate
itself—offering products or
services with higher quality, more quickly, and potentially at a
lower cost. Competitive
advantage, then, can be achieved a result of economies of scale,
economies of scope, or
knowledge of operational processes that is superior to one’s
competitors (Ramarapu & Lado,
1995). Porter’s research contributed to the field of business
process management because it
focused on doing things better than one’s competitors, making
process improvement something
practical rather than merely theoretical (Houy et al., 2010). IT
directly contributes to these
efficiencies as it supports efficiency and effectiveness through
IT solutions; and it supports
strategic positioning by enabling flexibility and responsiveness
to changing customer
requirements (Tallon, Kraemer, & Gurbaxani, 2000).

Established, recognized processes in an industry might be
characterized as an industry’s
―best practices.‖ A business needs more than best practices,
however, to thrive. Competitive
advantage is not achieved by following ―best practices,‖ or the
processes that similar
37
organizations in the same business all follow in order to be
effective (Harmon, 2007).
Competitive advantage is achieved, rather, by performing better
than ―best practices.‖ If each
business in an industry were to follow best practices, each firm
is then performing to common
standards, not differentiating itself by performing better than
what the customer expects. This is
one of the reasons that organizations strive to find better ways
of delivering goods or services to
their customers, and one of the drivers for good Business
Process Management.
Business Process Reengineering. When improving existing
business processes is not

enough to differentiate one business from another, it may be
necessary to break away from the
norm, and radically change business processes. In 1993,
Hammer and Champy introduced the
concept of Business Process Reengineering (BPR) with the book
Reengineering the Corporation
(Hammer & Champy, 1993a). This book introduced the concept
of radical organizational
change, accomplished by totally redesigning the organization’s
core processes. All existing
processes and systems are discarded, and new processes and
systems are built or acquired to
reinvent the company from the ground up (Hammer & Champy,
1993b). At the time when these
ideas were introduced, radical business process reengineering
was proposed to be the best way to
achieve competitive advantage.
In the mid-1990s, Thomas Davenport was also an early
proponent of BPR. His
contribution to the field was to provide ways to measure process
performance (Davenport &
Beers, 1995), taking a less ―radical‖ view of BPR than Hammer
and Champy (Eardley, Shah, &
Radman, 2008).

Today’s view of BPR has become less radical. A BPR effort
begins by looking at what a
company must do to provide value to customers; it then
determines the best way to accomplish
its tasks (Eardley et al., 2008). BPR emphasizes radical process
redesign of specific process
38
areas—not necessarily the entire company’s processes—
challenging assumptions about the
existing processes and creating totally new ways of working
that are very different from what
has been done before. Information technology solutions are
invaluable in not only designing
what a new process can do, but in enabling that new process to
work.
A business would only consider a more radical business process
reengineering effort if it
has a need for substantial gains in organizational performance
(Attaran, 2004). Making radical
changes in business processes is most often disruptive. The
effort, however, could result in more

efficient ways of working, reduce resources, or improve
productivity. These gains in
performance might be required to get ahead of the competition
or to distinguish oneself from the
competition in the field. BPR is expensive to implement, risky
in an unstable environment, and
not suitable for many, if not most, companies. One of the
primary difficulties with BPR is that
few organizations can truly afford to discard current processes,
working systems, and
technologies in favor of new ones (Eardley et al., 2008). Pure
BPR would require that a business
stop work and totally focus on reengineering the company’s
work. No matter what size a
company is, very few could afford to do that.
Given that discarding all of a business’ processes is impractical,
Hammer and Champy
suggested later that there are three criteria for selecting
processes to reengineer (Eardley et al.,
2008). The first criterion is process dysfunction, or identifying
a process that is not producing the
value required by the customer. The second is to identify
processes that have the most direct
impact on customer satisfaction, or those that could provide

―quick wins‖ when improved.
Finally, the third is to identify those processes that are most
likely to succeed, or are most
amenable to process redesign. Ensuring that those process
changes are adopted and managed
properly typically requires an Organizational Change
Management effort as part of changing
39
business processes (Attaran, 2004). In this sense, Business
Process Management, Information
Technology Process Management (or supporting technologies),
and Organizational Change
Management are all related when determining when improving
business processes is most likely
to have the most benefits.
Because a full implementation of BPR is seldom practical, a
new definition for process
reengineering has been suggested by Eardley et al.:
BPR is the fundamental rethinking and radical redesign of
appropriate business
processes to achieve dramatic improvements in critical,

contemporary measures
of performance, such as cost, quality, service and speed. Such
redesign and pace
of implementation to be suited to the individual organization,
contingent upon the
―gap‖ between the present state of the organization’s structure,
culture and IT
infrastructure, and the state required to implement the new
business processes
successfully. An ideal state would be one in which BPR was an
ongoing,
proactive process (Eardley et al., 2008, p. 634).
This definition implies that BPR should be focused on
redesigning those business
processes that can provide dramatic improvements. The
improvements must be suitable for the
organization’s needs, and must consider the organization’s
structure, culture, and IT
infrastructure. IT’s role, then, can hinder or enable business
process change, depending on IT’s
business capabilities (Table 4) (Eardley et al., 2008).

40
Table 4.
Characteristics of the Role of IT in BPR
Role of IT Characteristics of the role
Constraint Legacy IT systems dominate main business
processes. Inflexible IT infrastructures. Lack of skill
and/or investment in new IT. Business processes embedded in
existing IT systems. Lack of
potential for investment in IT due to budgetary factors. Lack of
perception of the potential of IT
by management. Strategic alignment is low
Catalyst New IT has been acquired. Changes in the business
have been made that favor the use of IT.
New management that sees the potential of IT in business
change. New relationship developed
with IT vendor, consultant, or service provider. Strategic
alignment at crucial stage
Neutral Lack of IS applications and IT infrastructure in the
organization. No IS or IT strategy in place.
Business change targets are not well defined. The business is in
an industry with low information

intensity or little competition through IT. Strategies and
infrastructures are in alignment
Driver The business has technological capability and seeks to
exploit it through business opportunities.
Possibly a new business or a technological innovation.
Sufficient investment is available and IT
development is not a limiting factor. Strategic alignment
process is proceeding rapidly
Enabler IT is a key performance factor and a ―competitive
arena‖ in the industry. Management has a clear
business vision and a future change plan. Business change
targets are well defined. Sufficient
investment is available and IT development not a limiting
factor. Strategic alignment in process
Proactive Management has a clear business vision and future
change plan. The IS and IT infrastructure are
well developed. There are few constraints on IT development.
Management sees the potential of
IT. Strategies and infrastructure are in alignment
Note: The above table describes six different levels of IT’s
roles (Eardley et al., 2008)
Table 4 shows that IT can be a constraint to business process
management; it can be

neutral to, or simply support process change. At the highest
level of process support to the
business, IT can be a proactive component to enabling business
process change. Its role is
dependent not only on its technical capabilities, but also on its
own process alignment and
maturity in supporting business process change. At the low end
of the range, then, when IT is a
constraint, the business typically is supported by legacy,
inflexible technologies—not by IT
process per se. Internal IT practitioners lack the skills necessary
to make dramatic changes to the
software, and the processes that run the business are encoded in
its software systems. In these
41
kinds of cases, IT is more commonly thought of as a service to
the business rather than a
strategic partner (Eardley et al., 2008; Taylor-Cummings,
1998). The business lacks the
resources to fund additional IT support, or perhaps does not see
the value in expanding IT’s
capabilities.

At the other end of the spectrum, when IT is a catalyst to
changes in business processes,
the business organization has begun to evolve from seeing IT as
purely a support function, into
one that sees potential in IT to support business change. IT then
begins to become a strategic
partner with the business (Pantazi & Georgopoulos, 2006). Both
enterprise processes and IT-
specific processes work together to support business strategy
because of their alignment.
Dramatic change to business processes requires support from IT
(Attaran, 2004).
Business processes must be designed in such a way that IT
technologies and processes can
support them. The resulting changes to the organization must
also be considered in order to best
operationalize those improvements. Dramatic process
improvement, therefore, requires all three
disciplines to be most effective: Business Process Management,
Information Technology Process
Management, and Organizational Change Management.
Benefits of BPM. Customers expect businesses to deliver goods
and services that meet

their requirements. In many cases, a customer will choose to
purchase repeatedly from the same
company out of loyalty, brand familiarity, or simply
convenience. But if a customer does not
perceive that the product from a specific company is better in
some way (quality, price,
availability, etc.), then that customer will likely purchase their
products from the company with
the best combination of benefits, such as market forces, cost
factors, or significance of that
product being consistent or high quality for the customer’s
needs (Porter, 1979).
42
Business Process Management can be a tool to establish the
mechanisms to quickly adapt
to changes in customers’ requirements or expectations
(Neubauer, 2009). BPM enables a
business to concentrate on those activities that add value to
their customers. It focuses on
―processes, customers, values, services, employees,
competencies, and learning.‖ (Neubauer,
2009, p. 167)

Used properly, BPM enables a company’s people to respond to
customer demands more
quickly and efficiently (Ko et al., 2009). It enables people to
make decisions more quickly.
Hammer states that business process management leads to a
dramatic boost in performance
because time is not wasted on unimportant processes, projects
do not ―fall through the cracks,‖
and BPM aligns everyone in the business around common goals
(and understanding around those
goals) (Hammer, 2002).
Challenges of BPM. While the benefits of BPM promise
excellent results, some studies
have reported that BPM techniques have not been consistently
helpful (Benner & Tushman,
2003). This may be due to the challenges that businesses face
when implementing BPM.
Adopting a business process orientation requires a shift of
thinking. No longer are
processes viewed as the domain of vertical, hierarchical units
within a larger organization.
Instead, processes are viewed as cross-functional, end-to-end
interactions between these smaller

organizational units. BPM requires shifting one’s thinking from
the power structure of a
hierarchy, to a more collaborative, less power-focused system
of business activities that are
interdependent on one another. This can mean that structural
changes to an organization are
necessary, and that they are likely to be resisted (Al-Mashari,
2002). Organizational change
management practices can address many of the issues when
structural changes to an organization
are required.
43
The challenges of implementing BPM can be generally
classified as internal, external,
and technological (Al-Mashari, 2002). Internal challenges are
primarily cultural in nature. Some
individuals may resist the organizational changes that may be
necessary to implement true end-
to-end processes. Rather than valuing specialized functions that
can be provided by a strictly
hierarchical organizational structure, a process-focused
organization may instead value inputs

from a variety of organizations that contribute to the overall
end-to-end process. Some may resist
radical changes in favor of incremental, less effective changes.
One study suggests that fear of
obsolescence may be a strong factor in resisting change
(Eckhardt et al., 2009). Other internal
factors may include politics, lack of knowledge or
understanding about the change, or inadequate
training (Markus, 1983). An inability to shift from a functional
orientation to a process
orientation also inhibits implementing BPM in an organization
(Elzinga et al., 1995).
External challenges refer primarily to those people, tools, or
technologies that must
interact with the processes (Al-Mashari, 2002). Skilled
resources are most likely to be found
outside the organization, as few possess the knowledge and
training required to implement
process-oriented technologies. These resources are likely to be
in high demand, and may not be
available when needed to implement BPM. Another external
challenge faces globalized
companies. Implementing BPM across an organization has
different implications for different

locales, especially when organizations are located in multiple
countries and cultures.
Finally, technological challenges may make implementing BPM
difficult (Al-Mashari,
2002). As organizations move toward adopting end-to-end
processes, the role of IT and
technological solutions becomes more important. Enterprise
resource management (ERP)
systems, customer relationship management (CRM) systems,
and related internal systems must
all interact with each other in order to efficiently implement
BPM across an organization. These
44
ERP and CRM systems are not only expensive, but they are also
very complex and require
expertise not normally found in a typical organization. These
technology solutions must be
acquired; the expertise to implement them must also be
acquired, since it is rarely found in-
house; and finally, the expertise to use the systems and move
them to process maturity must also

be acquired in order to ensure that the new systems provide
optimal benefit to the organization.
When implementing an enterprise-wide process management
system, organizations often
make the mistake of viewing ERP or CRM systems as primarily
IT or technological projects
(Zhao, 2004). This is a mistake primarily because the
technology of these integrated systems
requires not just changes in technology, but also changes in
processes that affect all of the
business units within the entire organization. Enterprise-wide
processes must be adopted in order
to gain the benefits of these systems. Business units that have
traditionally worked independently
from other business units can no longer be independent when it
comes to making decisions to
change either technology or process in the enterprise tool.
Rather, any proposed changes to these
tools must be considered and agreed to by all business units
within the enterprise. The reality is
that implementing these BPM systems should be viewed as
integration of strategy, end-to-end
business processes, management decision systems, and
organizational culture.

Business process management standards and methods. Business
processes can be
understood in a variety of ways. One of the most common is to
depict business processes as a
hierarchy, starting from the strategic goals of the business, and
ending at the lowest-level activity
view where organization members perform work that contributes
to those higher-level goals.
Harmon (2005) shows that BPM starts at the top with an
organization’s strategy and goals,
moves through high-level business processes, and finally to the
logical and physical activities
45
performed to fulfill those high-level goals. The hierarchy is not
built upon organization structure,
but organization goals and activities.
Business goals will determine the critical success factors that
processes must address.
BPM is successful when it meets, and continues to meet, the
goals established by the business
(Trkman, 2010). At the highest level, organization management
begins by determining those

goals that must be met in order to provide value to the
customer. Those goals are then stated as
high-level process areas. Each of those can be further broken
down into process steps,
procedures, and lower-level job aids and instructions.
Even in the context of business process management, it is
difficult to draw the
relationship of processes across functional areas without
showing some kind of hierarchical
structure. Businesses are generally structured as hierarchies, so
it is natural to think of processes
as extensions of those hierarchical structures. In practice,
however, business processes are not
confined to one functional area; rather, they require not only
interaction between functional
areas, but are often dependent upon horizontal interaction with
each other, without going up and
down the hierarchical chain of activities. The most effective
business processes are those that
cross functional boundaries to accomplish a goal with a
minimum of organizational overhead.
A simple transportation example will illustrate this point. When
traveling the

approximately 70 miles from Moorpark to the City of Industry
in Southern California, the most
expedient path, providing the most utility or value for a
customer, would be to travel in an
automobile (whose route the customer can control) using faster-
paced freeways. These public
freeways connect through interchanges, enabling someone
traveling by car to choose the best
route. The end-to-end travel process does not require going to
the hub or beginning point of any
one freeway to transverse across the freeway system to get to
the destination. The entire trip,
46
without traffic, might take from 1.25 hour (best case) to 2 or
even 3 hours in traffic. The same
trip, however, that is dependent on external processes (public
transportation) will take from 2 to
4 hours to complete. This is because taking public
transportation requires taking two train routes,
two bus routes, some wait time, and some walking in between.
The first train route goes in the
opposite direction from the final destination. After waiting for

PROCESS ACCEPTANCE AND ADOPTION BY IT SOFTWARE PROJ.docx

PROCESS ACCEPTANCE AND ADOPTION BY IT SOFTWARE PROJ.docx

Recommended

Recommended

More Related Content

Similar to PROCESS ACCEPTANCE AND ADOPTION BY IT SOFTWARE PROJ.docx

Similar to PROCESS ACCEPTANCE AND ADOPTION BY IT SOFTWARE PROJ.docx (20)

More from stilliegeorgiana

More from stilliegeorgiana (20)

Recently uploaded

Recently uploaded (20)

PROCESS ACCEPTANCE AND ADOPTION BY IT SOFTWARE PROJ.docx