Strategic planning in Information Technology: Research Design and Methods

Harsh_Harsh

Process_acceptance_and_adoptio.pdf

Home >Computer Science homework help >Strategic planning in Information Technology: Research Design and Methods

PROCESS ACCEPTANCE AND ADOPTION BY IT SOFTWARE

PROJECT PRACTITIONERS

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

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.

ProQuest LLC. 789 East Eisenhower Parkway

P.O. Box 1346 Ann Arbor, MI 48106 - 1346

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.

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

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.

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

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

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

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

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.

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

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

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

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

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.

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 includes the processes required to ensure

timely completion of the project.

Project cost management A subset of project management that includes the processes required to ensure

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

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

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

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

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.

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

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

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

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

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,

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.

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.

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

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

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

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.

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

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,

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

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.

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

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

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.

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

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.

Business Process Management

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

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

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, Business Process Management

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

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

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

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

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

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

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

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

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.

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

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

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,

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 approximately 45 minutes, the

traveler takes the second train route that ends at Union Station in Downtown Los Angeles. From

there a traveler takes the first bus route, waits a few minutes, and then takes the second bus. This

may still not be the final destination, but it’s the closest that public transportation will get. From

that point, the traveler can walk to his or her final destination, get a ride from someone else, or

potentially take a cab.

While this does not fully illustrate how a hierarchical process works, it does show that

rigid, pre-identified process ―maps‖ that meet business needs, may fall quite short of meeting the

client’s needs. Moving between process areas (e.g., train and bus routes and schedules) is only

possible within pre-established limits. It can take more than twice as long, with much more effort

on the client’s part, to get from one area to another. It often costs more than twice as much to

accomplish, and the client ends up at his or her destination, but tired and potentially frustrated.

This same kind of situation often exists when following hierarchical, pre-established

business processes. While it seems easy enough, from a client’s point of view, to get something

from a business, a rigid hierarchical business structure might deliver less than what the client

wants, at a cost much higher than the client wants to pay. Even when a client is internal to the

organization, these kinds of roadblocks can occur, making it nearly impossible for processes to

work well together. The intent of BPM is to address these kinds of issues, enabling critical

business processes to interact with other areas of the business to deliver a quality product or

service to the client that satisfies the client’s needs at a cost that is suitable for the business.

As previously discussed, IT practitioners support these business process improvement

efforts by using project management skills, implementing new technologies, enabling end-to-end

business processes with specialized software, and providing these tools to clients. IT is a critical

component of delivering these end-to-end process capabilities. IT practitioners who understand

their role in this context, then, have the potential to contribute their skills and knowledge as

strategic partners in bringing the best possible end-to-end solutions, not just service providers

who fulfill orders.

Process Standards. Processes, then, are generally designed to meet strategic goals of a

business, and expedite interaction between different process areas. While there is no single

source of standards for process management, standards have been identified in the following four

areas. Graphical standards allow practitioners to depict business activities and their flows using

modeling tools. Execution standards enable deployment and automation of business processes.

Interchange standards enable practitioners to exchange process data in a variety of formats so

that process management is not dependent on any one toolset. Finally, diagnosis standards

provide monitoring techniques and methods for identifying process bottlenecks and to query

process results real time (Ko et al., 2009).

Standardizing processes enables an organization to streamline activities, as well as to

minimize variation (Ungan, 2006). It helps to make work activities routine, less susceptible to

variations in results and more likely to produce desired results consistently. Standards make

measurements of activities possible, allowing a business to track performance metrics over time

to evaluate quality and customer satisfaction. Process metrics demonstrate that a business

activity is (or is not) performing to expectations, which may be mandated by regulations

(Trkman, 2010).

In some contexts, however, process standardization is not as desirable. Wherever an

activity is considered an art, for example, process standards could stifle, rather than encourage,

creativity and innovation. Accountability actually suffers in these cases, because the person

performing work that depends on their talents, skills, and abilities—rather than just following a

process—could blame ―the process‖ for reduced performance (Trkman, 2010). The most

important consideration when implementing specific business processes is to determine whether

a strict process orientation fits the situation, as well as whether the right process structures have

been deployed. Processes should not be deployed for the sake of the processes themselves, but in

order to fulfill specific goals (Pantazi & Georgopoulos, 2006).

Process design methodology. A number of process development lifecycles have been

developed (Table 5) (Houy et al., 2010). While each of these differ in some aspects—some

having more detail than others—each of them includes at a minimum the following steps in the

process development lifecycle: process design; system configuration; process enactment or

implementation; and diagnosis of the results. This four-step process is very similar to the Plan-

Do-Check-Act (PDCA) cycle made popular by W. Edwards Deming, one of the first proponents

of the quality movement in the 1950s (Arveson, 1998).

Table 5.

Different Definitions of the BPM Life Cycle

Davenport and

Short (1990)

Van der Aalst

et al. (2003)

Netjes et al.

(2006)

Zur Muhlen and Ho

(2006)

Hallerbach et

al. (2008)

Kannengiesser

(2008)

Identifying

processes for

innovation

Identifying change

levers

Developing process

visions

Understanding

existing processes

Designing and

prototyping the

new process

Process

design

System

configuration

Process

enactment

Diagnosis

Design

Configurati

Execution

Control

Diagnosis

Organizational analysis

Specification and

modeling

Workflow modeling

and implementation

Workflow

execution/run time

Warehousing/controllin

g/process mining

Business activity

monitoring

Modeling

Instantiation/se

lection

Execution

Optimization

Process design

Process

implementation

Process

enactment

Process

evaluation

Note: Table 5 shows six different process development lifecycles, as described in Houy et al.

(2010).

A more robust process development methodology consolidates the steps as defined in

Table 5 as (Houy et al., 2010):

 Development of the strategy for business processes;

 Definition and modeling of specific processes;

 Implementation of the processes (e.g., putting the processes in place) within the

organization;

 Execution of the processes, or performing the process steps;

 Monitoring and controlling process results; and

 Continuous improvement of the processes.

This design methodology is consistent with not only typical software development

lifecycle methods, but also with process improvement methods. It begins with definition or

analysis, goes to design and construction, implementation, monitoring, and improving the

processes implemented. Similar to Deming’s PDCA continuous improvement cycle, this process

development lifecycle can also be depicted as a continuous cycle (Houy et al., 2010).

Business process improvement. Good, current processes are critical to having and

maintaining a healthy business. Processes remain relevant by evaluating how they fit in the

current environment; by looking forward toward future needs; and by the interaction between

business process management, information technology process management, and organizational

change management. Hammer (2002) states that not only does process management directly lead

to better performance, but it also ―provides a framework and context for integrating process-

improvement initiatives.‖ (p. 28) This integration not only requires looking at how each of the

three areas interacts with each other, but also continuously evaluating integrated processes for

improvement opportunities.

Process changes that fall under the umbrella of either Information Technology Process

Management (ITPM) or Organizational Change Management (OCM) should only be made if

they support business process improvement (Trkman, 2010), either directly or indirectly. Before

pursuing the role of either ITPM or OCM in process improvement, however, an understanding of

business process improvement is necessary.

The goal of Business Process Improvement (BPI) is to determine what could be done

better in a given process in order to provide value to the customer. Competitive business

environments change, as well as technologies that provide value to the business. In order to be

competitive and, in some cases, to stay in business, processes must be evaluated and improved to

address external forces as well as internal forces. Doing things ―better, faster, cheaper‖ started as

a mantra for promoting business process improvement, and focuses on the need to quickly and

effectively respond to changing customer requirements (Cascio, 2002).

BPI enables a business to evaluate processes in the context of a value chain. Those

activities that add value or that contribute directly to the product or service that a business

provides, can be identified as those that should be evaluated first. BPI helps a business increase

yield and reduce rework through streamlining and improving processes. Product delivery speed

can be increased, as well as communication between departments enhanced, as interdepartmental

process steps are improved. These improvements can be enabled by technology, and may require

organizational changes to support the improvements. These improved processes then result in

better products and services, increasing value to the customer. All of this could (and should)

increase revenue (Benner & Tushman, 2003) or decrease expenses.

In a perfect world, process improvement efforts would always result in better, faster, and

cheaper products. However, in a turbulent environment, larger process improvement efforts

could actually be disruptive. Incremental changes, then, are more appropriate than radical,

business process reengineering efforts in this context (Benner & Tushman, 2003).

Processes vary in complexity, scope, and value to the business. Because of this, there are

at least four levels of business process improvement (Subramoniam et al., 2009). The first level

is incremental, where smaller changes are made in one department or functional unit, with less

far-reaching scope. These kinds of process improvements are often done without impact to other

functional areas of the business, but have good improvement potential for that one functional

area. The second level is more far-reaching: end-to-end process improvement. Multiple

functional areas are generally involved in this kind of improvement, and it requires more

coordination and management than incremental process improvement. In some cases it may also

require adjustments in the organizations performing processes in order to improve cross-

functional handoffs. It also has a better-than-average chance of addressing process issues that are

part of the value chain, as it can focus on larger process improvement opportunities as people

collaborate with each other across functional areas. The third level of process improvement is

enabled by system enhancements or additions. This level of improvement is different from the

second level because it requires the additional component of information technology in its

solution. Some processes may be automated, which could dramatically increase productivity.

Those whose work can be automated can be contributing to the business process in different,

better ways. Technology-enabled process change can also be more dramatic, as in the case of

implementing an Enterprise Resource Planning (ERP) system. In this kind of process

improvement effort, core supporting processes, such as Finance, Human Capital Management, or

Supply Chain Management, are standardized across the enterprise. If organizational structures

are not changed in this level of process improvement, the functions performed by different

functional areas most often does change, therefore involving some kind of organizational change.

Implementing a new ERP system could involve replacing systems that have been used for

decades, as well as the processes that have been in place to support them. The fourth level of

process improvement is the post-implementation improvement efforts that take place to take

advantage of new functionality provided by a new technology. Rather than just replacing old

technology and processes with new, this fourth level actually takes advantage of system

functionality that wasn’t available before.

From the lowest level of process improvement to the highest, enterprise-wide level,

process changes are most effective if they are effectively managed across all three areas of BPM,

ITPM, and OCM. The business must not only know about the process changes being made (and

proposed), but it must be able to collect information about process improvements, evaluate

effectiveness of changes, and ensure that the process improvements are delivering the value

intended (Davenport & Beers, 1995). This requires not only coordination between process

improvement teams, but a central focus on process management in general. Without this central

oversight, a business runs the risk of sponsoring multiple, disconnected process improvement

efforts (Hammer, 2002). Without integrating these improvements across business, information

technology, and organizational change perspectives, process improvements can become

confusing and could cause harmful competition among departments as they vie for scarce

resources or even work toward competing goals. This is where IT could make a real difference in

delivering software to its clients, by embracing a business process perspective when

implementing software. When IT supports the enterprise and its individual business units with its

software solutions, IT software development practitioners are in a unique and strategic position

to ensure that the functionality of new technology is integrated with, or at least not

counterproductive to, processes in place across the enterprise. At a minimum, IT software

development practitioners must understand the role that software plays in enabling processes for

individuals and business units. Those who understand the role of technology in enabling

processes across the enterprise can support development and implementation of software

solutions that truly meet business needs.

One way to address this is to evaluate process improvements in two ways: for

improvements in performance, but also for relevance to business requirements (Davenport &

Beers, 1995). Those companies who have begun to implement process improvement practices

are relatively skilled at evaluating the performance of process improvements. Measuring

performance can be achieved by establishing metrics and goals to be achieved because of those

improvements. However, determining whether those improvements are actually beneficial to the

business is more difficult, and is not typically evaluated. These two focus areas—performance

and relevance—have been called the ―Performance Loop‖ and ―Relevance Loop‖ by Davenport

and Beers (1995). IT is often engaged in measuring work in the performance loop, but is seldom

engaged in ensuring that software fits within the relevance loop.

This approach uses both traditional process improvement activities (the performance

loop), as well as a ―business fit‖ analysis (the relevance loop) to ensure that the processes being

evaluated fit business needs, the process environment, and the level of change needed. Relevance

loop thinking can also help lead to continuous improvement opportunities for the future, by both

business clients and the IT practitioners who support them. Some process improvement

disciplines, such as Total Quality Management and Lean Six Sigma, can lose sight of the overall

goal of ensuring that the improvements are actually important, or relevant, to strategic goals.

It is important to consider future improvement opportunities as well when beginning a

business process improvement activity; doing so ensures that future improvements will be easier

to implement (Elzinga et al., 1995). For example, using standard improvement procedures,

documentation formats, and common tools makes the next process improvement activity easier

to conduct. The business will have a common understanding of not only the tools, but the

meaning of the results of the previous improvement efforts. Initial improvement opportunities

might be classified as the ―low-hanging fruit,‖ enabling quick results to show the value of

process improvement. The true value of process improvement, however, is not to be found so

much in the results that are fast and easy to achieve, but in the collaboration and integration work

done to improve end-to-end work among interdependent functional groups. IT business analysts

could and should be key strategic partners when planning for process improvements.

Continuous Improvement. Not only is there value in performing initial process

improvement activities, but refining improvement and finding new ways to improve processes in

place can be even more beneficial. A program of continuous improvement leads to not only cost

reductions, but also to adoption of products and solutions within an enterprise (Garbani, 2005).

Improving processes is one of the three primary activities in process management: mapping

processes, improving them, and operationalizing or adopting them (Benner & Tushman, 2003).

Continuous process improvement is a cycle of analysis activities that selects and

compares standard activities to benchmarks, either in the industry or in the benchmarks

established by the processes (Elzinga et al., 1995). The cycle begins by preparing for process

improvement, perhaps by completing an inventory of processes that are either critical to

delivering value, or processes that are known to suffer from too much variation. One or more

processes are selected for improvement, then analyzed and described. This may include creating

process maps of the current process or finding maps that may already exist. Process outputs are

measured and quantified. After analysis by those who participate in running the process, as well

as other subject matter experts, an improvement is selected, then implemented.

There is one primary constant in the continuous improvement cycle—the people who

perform the work (Koskela & Dave, 2008). People learn the process, organize the work, and are

in the best position to know what changes should and could be made to an existing process. IT

plays a key role in not only enabling process improvement through technology, but also in

evaluating whether a specific technology ―fits‖ business processes or environment (Gomolski,

2004). IT professionals can be in the unique position of being able to evaluate how technology

solutions can support business processes, improvements in work, and even new opportunities for

changing processes (Trkman, 2010). In this way, business process improvement is dependent on

IT, and IT is dependent on organizational change management to help introduce change—

especially when it is dependent on having the right organizational structure and culture in place.

From a business viewpoint, continuous improvement activities are aimed at reducing

waste, which includes valueless time, variance, and activities (Tersine, 2004). The concept of

business value is critically important when understanding the context of waste. Business value is

more than delivering something of value to the business; it means that the activity directly

contributes to the value chain of activities that are critical to a business delivering its products or

services (Tallon et al., 2000). Continuous improvement activities, therefore, are aimed at

reducing activities that do not contribute to the value (e.g., products or services) that the business

provides to its customers.

Approaches to Continuous Improvement. Radical process improvement is the focus of

pure business process reengineering (BPR). For incremental change, however, BPR’s resulting

disruption in organizational culture, end-to-end processes, and personnel is not only unnecessary,

but counterproductive when the improvements required are less radical. Total Quality

Management (TQM) is one approach toward incremental process change that requires process

measurement, involvement of practitioners, and process documentation standards (Neubauer,

2009).

A more recent approach to continuous process improvement, Lean Six Sigma is a

methodology that is based on a five-phase DMAIC model: (1) Define, (2) Measure, (3) Analyze,

(4) Improve, and (5) Control (Kumar, Nowicki, Ramírez-Márquez, & Verma, 2008). This model

is not inconsistent with the continuous process model depicted in Figure 9. The Define phase is

somewhat equivalent to the Process Selection and Process Description steps. The next phase of

the DMAIC model, Measure, is somewhat equivalent to the Process Quantification phase. Its

purpose is to measure current performance of a process so that the improvement can be evaluated

after implementation. The DMAIC Analyze phase is similar to the Process Improvement

Selection phase, since the goal of the analysis is to define a minimum of two alternatives for

improving a process. In DMAIC, the Improve phase follows, which is roughly equivalent to

implementing the process improvement selected from the Analysis phase. Finally, the last phase

of the DMAIC cycle, the Control phase, is implied in the continuous improvement loop back

cycle, where the process implemented is evaluated. The difference in DMAIC, however, is that a

specific phase is identified to control the process improvement, which ensures that process

outputs are measured, evaluated, and controlled.

Information Technology and Process Improvement. IT not only provides a mechanism for

implementing process improvement for the enterprise. In addition to this, IT can be the focus of

continuous process improvement. While IT practitioners do have expertise in technologies for

supporting business process change, they do not necessarily have the same expertise when

evaluating their own processes. To achieve true excellence in IT, the organization should focus

on streamlining and integrating its own processes with those of the enterprise. Centers of

excellence for various aspects of IT should be established and aligned with the value chain of the

business. Each of these should have dedicated IT staff that continuously finds ways to improve

and integrate processes. This view of IT as an enabler of process improvement will contribute to

a lasting and successful IT organization that provides business value to the enterprise (Allen,

2003), and formalizing this role in IT as centers of excellence for process improvement can bring

the attention needed to succeed.

As IT practitioners who are tasked with understanding business requirements, IT business

analysts are perhaps best prepared to be members of IT process centers of excellence. Business

analysts who support software development projects could be in the best position to understand

IT’s internal processes as well as IT’s clients’ processes. With collaboration from other members

of the team, these business analysts would be trained in not only business analysis from a

software technology viewpoint, but also process improvement. The marriage of this background

in IT software development and implementation with a background in process management

could provide the expertise required to enable processes that support the enterprise’s value chain,

or the activities that deliver what the enterprise’s customers want, expect, and pay for.

Information Technology Process Management

Managing the IT department in a business requires more than just technical expertise.

While IT does deliver the technologies that enable businesses to function efficiently, it can also

deliver expertise in tool selection, deployment, and even use. The true value of IT, however, is to

be found when it is part of the overall strategy of the business, when it can provide expertise,

integration, insight, and tools for managing processes across the enterprise.

The information technology function can be defined as ―capabilities offered to

organizations by computers, software applications, and telecommunications to deliver data,

information, and knowledge to individuals and processes.‖ (Mohsen Attaran, 2003, p. 442) The

capabilities provided by IT enable, and are the foundation for, business processes, reengineering,

and process improvement activities (Subramoniam et al., 2009). Enabling technologies include

database systems that make information available across the enterprise, knowledge-based

systems that assist in decision making, and telecommunications networks that provide the

physical means to transport data and information (Eardley et al., 2008).

Because IT is so important to a successful business, organizational change theorists have

begun looking at IT as more than the technological sum of its parts. The two fields of IT and

OCM could be seen as overlapping fields of study (Orlikowski & Barley, 2001). As

organizations grow and mature, they tend to become more dependent on technologies that IT

implements and supports. When the nature of work changes (and therefore business processes) as

a result of environmental changes, OCM practitioners have tools and methods for ensuring the

organization successfully changes as well. When technology forces changes to the nature of

work and resulting processes, however, OCM has not necessarily evolved to consider how these

changes also affect organizations. In the past, socio-technical depictions of technological change

have treated these changes as ―black boxes‖ with inputs and outputs. This is not enough; the

nature of the changes in work brought by technology should be considered as opportunities for

organizational change as well as the technologies themselves (Orlikowski & Barley, 2001). This

could be enabled by the approach proposed earlier, preparing IT practitioners (perhaps business

analysts) to support process continuous improvement across the enterprise.

Technological changes do not occur in a vacuum of choice. People using new

technologies have choices about how and when to exploit the new tools, thereby indicating that

there is an element of acceptance and personalization in the adoption of technology. Because of

this, people actually shape the technologies that they use. The same technology, for example,

implemented in two different organizations might have two totally different outcomes because

the people who are using the technologies have applied the tools differently (Orlikowski &

Barley, 2001).

IT practitioners also do not normally take organizational changes into account when

implementing new technologies. IT generally approaches the implementation of technology as

part of a project, with defined tasks, milestones, and costs. The IT project stops when the

technology has been deployed, and most often does not contain a process change phase or an

organizational change phase—or even steps to address these—in the project plan. In most

software management projects, IT does not ask the BPM- or OCM-related questions: how

processes are changed, how cultural frameworks shape the use of the technologies deployed, or

how the normative frameworks in place affect system use (Orlikowski & Barley, 2001).

The business clients that receive technology solutions often do not consider process

impacts either. They may not recognize that changes in organizational assignments might

increase the effectiveness of the new technology. The benefit of new technology, however, for

the business is in being able to change itself for the better because of the use of the new

technology (Caldeira & Dhillon, 2010). Most business process improvements are dependent on

technology and organizational improvements to succeed.

IT-business alignment. How, then, should business and IT be aligned? In order to reap

the benefits that IT can offer, IT must align with business in several ways. The first is to align

IT’s strategic plans with the strategic plans of the business. Both the business and IT must be

going in the same direction, with aligned goals, in order to achieve success (Holland & Skarke,

2008).

The second area for alignment is in business processes. IT processes cannot succeed and

also compete with business processes, because these processes often share the same resources.

These resources include people, technology, and the end-to-end processes to which everyone

contributes (Holland & Skarke, 2008). Integrating an organizational view with process

development and management within IT and the business will help ensure that IT’s processes are

aligned with those of the business.

It is also important to align structurally with the business. IT should be positioned to

complement the organization’s structure, to enable the critical activities of ―Run the Business‖

and ―Change the Business.‖ This may require analyzing IT’s structure and making changes to

ensure that IT aligns with the business structure (Holland & Skarke, 2008).

In order to be successful, then, IT must be aligned with the business in strategy,

processes, and organization structure. The mechanism for this is to think and manage by

processes within the context of organizational values. Those processes must be managed by local

owners within IT who are responsible for enhancing them to meet business process requirements

(Holland & Skarke, 2008).

IT support for business processes. Historically, IT practitioners have not been trained

to focus on managing processes. IT practitioners are more focused on using, exploiting, and

managing the tools that they implement—not the end users and how the tools affect them

(Markus, Majchrzak, & Gasser, 2002). Is that, however, really a good measure of IT

competence? Does this view truly deliver what the client needs and wants from IT?

IT competence can be measured by how well IT manages current operations, and how

successfully the organization’s technologies meet current challenges as well as new, future

demands (Caldeira & Dhillon, 2010). Because delivering IT services depends on skilled

resources who have developed business knowledge over time, these resources cannot easily be

outsourced or purchased elsewhere. They have knowledge of the business, and can contribute to

and help influence business processes, as well as implementation of new technologies within the

organization. The value of IT, then, is not limited to delivering the technologies and tools that

clients ask for. Value comes also from making improvements to business processes that IT

technologies enable (Caldeira & Dhillon, 2010).

In order to deliver business value, then, IT must study and understand those business

processes that deliver value to the customer. IT must again focus on business analysis, not just

tool delivery, to understand the business. IT must understand and collaborate with the business in

order to support and even develop important business processes. IT must begin to think and

manage by process (Caldeira & Dhillon, 2010). People, process, and technology must all fit

together for an organization to thrive; they are interdependent upon each other (Koskela & Dave,

2008).

One of the key competencies of an IT organization is delivering software solutions. In

many cases, software is custom developed because of the particular operational needs of the

business; off-the-shelf software solutions do not always meet business needs. While this has long

been a service that IT provides, the quality of software developed in-house does not always meet

client expectations. Development processes, then, are a major concern for IT managers and their

clients (Riemenschneider, Hardgrave, & Davis, 2002).

IT processes. Many of IT’s processes focus on operational or technical basics, such as

how changes to the IT environment are received, recorded, analyzed, approved, prioritized, and

carried out (Gomolski, 2004). While not typically recognized as processes, these lower-level

procedures may or may not be documented or kept up to date. IT professionals who have

performed the same task over a long period of time understand how to do their tasks, and the

procedures are often tacit, rather than formal, knowledge.

In more mature IT organizations, processes are more formalized. However, having

documented processes does not ensure that they are followed consistently, or that they even fit

the strategic goals of the business. Processes that do not fit strategic goals are awkward at best,

and could even be harmful to the overall enterprise’s goals. These processes cannot be relied

upon to deliver strategic value to the business (Sharma & Sharma, 2010).

In large IT organizations, a large number of process areas may exist. These include

everything from architecture-level processes to program management (Sharma & Sharma, 2010).

The important thing to understand is that each of these IT process areas should be interdependent

on each other. Software engineering processes have dependencies on architecture processes,

since software solutions must comply with the organization’s standard architecture policies.

Project management processes drive the timing of software engineering processes in any given

software project. Program management processes drive how project management processes fit

with other projects, and portfolio management processes ensure that the applications and other

technology assets in the portfolio are supported and do not conflict with each other. There may

be multiple programs running at any one time, so it is important to have inter-program and inter-

portfolio processes to ensure proper alignment with each other and with business requirements.

Interfaces between each of the applications, architecture components, and even processes must

also be managed. Finally, governance processes ensure that all of these other processes are

working together as intended (Sharma & Sharma, 2010).

IT project management. Managing software development projects is one process area

that is critical for client satisfaction. The PMBOK ©

(2008, p. 5) defines a project as ―a

temporary endeavor undertaken to create a unique product, service, or result.‖ As temporary

endeavors, projects have a specific beginning date, a specific goal, and a specific end date. When

the project’s objectives have been met, or when it has been determined that the objectives cannot

be met, the project normally ends.

In most IT organizations, the software project management discipline generally follows

the guidelines of the PMBOK ©

. Furthermore, other areas within IT may follow process

guidelines specific to their given expertise. The Information Technology Infrastructure Library

(ITIL), for example, focuses on process around service delivery. This area is normally managed

by the IT organization that manages its physical infrastructure. The software development

discipline has been guided by Carnegie Mellon’s Software Engineering Institute, which

published the measurements for determining process maturity in the Capability Maturity Model

(CMM). These process guidelines are very linear, and very structured in nature, and may or may

not fit the particular environments in which they are being used (Sharma & Sharma, 2010).

Even though an organization might reach the highest level of software development

process development maturity (CMM Level 5), this does not mean that the organization will see

significantly greater returns on software development costs and product quality because of their

certification level (Harter et al., 2000). The most important consideration, when evaluating

whether to implement a software development process, is whether the investment in time,

process development, training, and monitoring are appropriate for the organization. Discipline in

not only project management, but also in software development processes, is important for

delivering higher product quality. However, it is important to weigh the projected benefits

against the projected costs of implementing these processes to determine what is appropriate for

any given organization. If the process itself becomes the goal instead of the means for achieving

higher quality and value for the client, then it is probable that the process focus has become

irrelevant. Software developers, project managers, and other IT practitioners who support

software development projects are unlikely to accept and adopt processes that do not support the

goal of delivering a high-quality product to the client within scope, schedule, and budget.

Software development processes, like project management processes, have been designed

to assist IT practitioners with performing their work at higher quality levels. All of these process

areas are focused on what IT practitioners do, without much emphasis on the eventual impact to

clients—other than acceptance of a completed project. Typically, IT practitioners view

themselves as part of the IT organization, but limit their thinking to the influence they might

have within that organization (Figure ). This approach is shortsighted—IT’s influence is not

limited to its own organization, especially in the context of software projects. IT reaches the

clients who use the software that IT implements; that software also influences how the client

organization runs. This in turn influences organizational strategy. Therefore, IT’s focus on

process should be not only IT-facing, but client-facing as well.

Figure 2. IT circle of influence

In the context of IT process and organizations, little research has been done to determine

how organizations influence the design, use and effects of using technologies, either within

organizations or between organizations. Even the PMBOK ©

, which is the Project Management

Institute’s guide for running successful projects, does not include any dedicated information on

organizational changes that might occur as a result of a project. Organization theory does not

generally perform analysis at these lower levels where IT does its work, but on social

frameworks that drive how people work with one another. IT research, on the other hand, tends

to focus on the more hands-on approaches, in a materialistic sense, of how IT supports business

goals and strategies (Orlikowski & Barley, 2001). It is apparent, however, that looking at how

organizational change theory could contribute to process management and information

technology acceptance (and vice versa) would contribute to an understanding of how each

discipline could benefit from the other.

Organizational change from an IT perspective would most often be relevant as a

component of IT projects. The focus of an IT project might be to implement new software,

update existing software, or to make changes or additions to the IT infrastructure in some way.

To see where OCM might be applicable in the context of an IT project, an overview of IT project

management would be helpful.

While there are many models for managing projects, the most common, and perhaps the

most well-known, is the waterfall methodology. It is called a waterfall method because the

phases of project management are distinct, leading from one phase to the next, in a logical

succession of events (Chapman, 2004), often pictured as a stair step diagram or waterfall. Other

methodologies or models exist, but many are based on the waterfall method, beginning with

System Concept, followed by System Requirements, Design, Construction and Testing, and

finally Implementation or Integration.

A project manager is primarily concerned with following the prescribed steps from

project beginning to project closure. From this viewpoint, a project is successful if it is

implemented on time, with the required functionality or scope, and on budget. Most of the time

there is no requirement for the project manager to ensure that the system can or will be used by

the end users; that is generally thought to be the client’s responsibility. A software development

project normally ends shortly after the software is delivered; projects may not even look at client

acceptance of the technology developed, or whether the process changes supported by the new

software have been implemented.

However, from a process perspective, this view of IT project management could not be

more incorrect. From the client’s perspective, an IT project is successful if the software

developed and implemented does what it is intended to do. While the software might be

technically correct, it can be totally incorrect in the context of the organization for which it was

built, if organizational changes that the software requires are not made (Caldeira & Dhillon,

2010). If client processes are considered as well as specific functions requested by the client

while gathering requirements, designing the system, and during construction, then the system has

a much greater likelihood of being integrated and usable when delivered to the client (Sharma &

Sharma, 2010). Process and system design issues are also not confined to new systems being

developed. As organizations mature in process management, new requirements become

necessary for integrating processes across the enterprise. Services, system architectures, and

enterprise end-to-end processes are all shared, and must be considered when implementing any

new technology.

Because organizational change issues are largely ignored in traditional IT project

management, the likelihood of project failure is increased (Caldeira & Dhillon, 2010). While a

working system might be delivered, the project will have failed if clients do not use the system,

if they misuse the system, or if they do not get the desired results from using the system (Markus,

2005). These results can be symptoms of a bigger problem, resistance to change. One way to

address resistance to new technology is to apply one of the several Technology Acceptance

Models that are available.

Technology acceptance models. Organizational leaders can assess the likelihood of

project success and proactively design interventions that will encourage use of a new technology.

Technology acceptance models are tools that can assist strategy development toward system

acceptance (Neufeld, Dong, & Higgins, 2007). These technology acceptance models are used by

managers to make acceptance of new technology as likely as possible. While similar to

organizational change management methods, they are primarily focused on features of the tools

being implemented as well as the clients who will receive the tools.

The most notable acceptance models are the Technology Acceptance Model (TAM), the

Theory of Planned Behavior (TPB), and the Theory of Reasoned Action (TRA). Both TPB and

TRA are behavioral models that were created in the field of social psychology, outside the

context of Information Technology, and are models that describe the determinants of intent to

take some kind of action (Eckhardt et al., 2009). This distinction is important, because it shows

that social psychology is the basis for behavioral theories in the context of Information

Technology. While most of the technology acceptance models are primarily interested in

measurable indicators of behavior around technology, their basis is formed from the behavioral

aspect of intent. Social psychology is also important in understanding how to apply

Organizational Change Management techniques.

Technology acceptance models generally measure acceptance immediately after new

technology has been implemented. This is understandable, because IT projects generally end,

and the personnel who were dedicated to the project move on to new projects. The clients

themselves are left to measure success of the system and to ensure that it is being used as

intended. If new technology has been implemented without adequate post-implementation

planning, however, system use is likely to be most intensive only immediately after installation,

and only by those who championed or sponsored the new technology. It is possible that only

subsets of the new system are immediately used, if the client users have not had time or

opportunity to explore additional features of the system beyond what was delivered to satisfy an

immediate requirement (Jasperson, Carter, & Zmud, 2005).

The new system, therefore, has not truly been accepted for all the benefits it could

provide to the business. Technology acceptance is characterized by a number of different levels

of acceptance, and can be measured by evaluating the system features employed by the users. At

one end, users may resist the new system even more after it has been implemented than they did

during its development. They may treat the new system and its features with indifference, as

though no change has been made at all. A more common reaction is to use only a limited set of

features of a new system, rather than exploiting all of the system’s capabilities. If there is a move

toward fully adopting the system, users may modify their routines to incorporate the system’s

features that support the work they would normally be doing with or without the system. Those

who are enthusiastic about the system may champion its features to other users. Finally, those

who fully exploit the system extend its capabilities from the basics of what was delivered into

expanding the tool in new ways that enhance their work processes (Jasperson et al., 2005). While

this is likely to be seen as the most favorable outcome to an IT professional, the business client

may feel that value was delivered by incorporating primarily those features of the new

technology that contribute to the value chain of the business, or those activities that are critical to

quality for the client. Each situation is different and requires an understanding of the unique

business needs that the system can support. Therefore, within the area of post adoptive

behaviors, individual feature adoption, use, and extension could all be acceptable results to the

sponsoring client.

Enthusiastic system adopters might be those who have a greater propensity to take risks

when it comes to personal innovativeness and the use of systems (Agarwal & Prasad, 1998).

These are the clients who are most likely to be the enthusiastic champions of system use, and

those who might exploit the features beyond original intent, and perhaps beyond what is

beneficial for the business. While it is important to value the efforts of these enthusiastic users, it

is also equally important to ensure that system use stays on track, and supports business needs.

Client users who are most likely to benefit from new systems are those that recognize that

the technology ―fits‖ the tasks that they must perform (Jasperson et al., 2005). This is called the

―task-technology fit‖ aspect of new technology. It is important from a project management

perspective to identify that fit and ensure that it is understood before implementing the new

technology. It is also important to recognize that business benefits derived from the new

technology actually come from adopting new processes enabled by the system (Caldeira &

Dhillon, 2010). Therefore, it is not just using specific features of technology that support the

business, but adopting and using those specific features that support business process the best.

Acceptance models, in general, have been formulated to discern those factors that are

important for motivating users to adopt a new system. They postulate interventions that could be

used to motivate system use and acceptance, and are generally focused on influencing actions

more than attitudes or beliefs. A common misconception among managers is that employees will

accept new processes, methodologies, or tools just because the organization mandates it

(Riemenschneider et al., 2002). While organizational mandate has typically been found to be a

strong factor in tool acceptance, it cannot alone ensure that tools are truly adopted, accepted and

used. It takes more than that.

As mentioned, research in this field has resulted in several theoretical models, including

the Technology Acceptance Model and the Unified Theory of the Use and Acceptance of

Technology. These various models have been used to explain over 40% of the variance in

individual intention to use technology (Venkatesh et al., 2003). In fact, one of the greatest

strengths of these models is that they are generalizable across a variety of technologies and

settings (Venkatesh, 2006). While the models are intended to help predict acceptance of

computer technology, they have been used successfully in other fields that also have a

technology component: marketing, green electricity use, and dairy farming. This indicates that

the models have reached a strong level of maturity and are generalizable across other contexts.

Since the use of technology is so closely tied to acceptance and adoption of process,

determinants for process acceptance might also be measured by one of the technology

acceptance models.

Technology Acceptance Model (TAM). The Technology Acceptance Model is very likely

one of the more commonly known and understood models. Based on the Theory of Reasoned

Action (TRA), the TAM proposes that attitudes or beliefs form the basis of accepting new

technologies. Attitudes are based on how a person views a technology’s ease of use, as well as its

perceived usefulness. Perceived ease of use is the belief that using the technology will not

require additional effort, and perceived usefulness is the degree to which the tool will increase

effectiveness or performance levels (Hernandez, Jimenez, & Martin, 2008). Other, extrinsic

values may affect those perceptions or beliefs, including peer group pressure, the business

environment, internal culture, or compatibility with one’s work processes.

Compatibility is an important concept in TAM because it evaluates whether the user

perceives the new technology to be compatible with performing the work. It is very similar to the

concept discussed earlier, task-technology fit. The model has been criticized because it is so

simple and so succinct (Venkatesh et al., 2007). While it is true that the model is relatively

simple, that simplicity can also be one of its strengths: it is relatively easy to apply to various

situations and to provide value.

Attitude is also an important construct of the TAM model. The strength of the attitude

moderates the actual behavioral intent, therefore affecting actual system use (Kim, Chun, &

Song, 2009). The original technical acceptance model depicted by Kim et al. shows that attitude

is formed by perceptions of usefulness and ease of use, which leads to behavioral intention and

actual system use. Kim et al. (2009) propose that attitude is a stronger determinant of behavior,

and is manifested by persistence, perhaps resistance, influence on the technology, and guidance

for behavior. These also further imply that attitude is a strong measure of not only intent, but also

adoption.

Other Acceptance Models. TAM2 is an extension of the original TAM model. In

addition to perceived ease of use and perceived usefulness, this model adds two additional

factors. Subjective norm could simply be defined as the peer pressure one feels to adopt a

behavior or tool, and is defined as the degree to which people who are important to the user

expect acceptance or rejection of the new technology or system. The degree of voluntariness for

using the system affects the influence of the subjective norm as well. If using a system is not

perceived to be voluntary, its use may not expand beyond just the minimum required

(Riemenschneider et al., 2002). Previously, Figure 13 depicted this concept: extending use of

system features beyond the minimum or expected is only likely to occur when it is voluntary.

The Theory of Planned Behavior (TPB) is based on social psychology, and proposes that

there are three main determinants of intent, leading to behavior: perceived behavioral control,

subjective norm, and attitude (Riemenschneider et al., 2002). Behavioral control is the degree to

which a person (whether the potential user or someone external) has control over performing the

behavior. Internal constraints are likely to be different from external constraints of behavioral

control, but are equally likely to affect the perception of behavioral control. Subjective norm in

this model is the same as in the TAM2 model, referring to peer pressure or external influences

that one perceives from one’s peers to perform or refrain from performing the behavior. Finally,

attitude refers to the favorable or unfavorable feeling about performing the behavior. These three

constructs together form a behavioral intent, which leads to use or non-use of a technology.

Unified Theory of the Use and Acceptance of Technology (UTAUT). The Unified Theory

of the Use and Acceptance of Technology (UTAUT) was compiled by Venkatesh, Morris, Davis,

and Davis (2003) in order to standardize the most common elements of eight of the then-current

technology acceptance models in use. This model proposes that the following four constructs

comprise the four factors most likely to predict post-adoptive behavior in the use of technology:

performance expectancy, effort expectancy, social influence, and facilitating conditions

(Jasperson et al., 2005).

Understanding these factors is important from a management point of view. A strong

manager or leader can set the stage to inspire motivation in people using a new technology

(Neufeld et al., 2007). Preparing for implementing a new technology, then, goes beyond the

technology itself. No technology provides value if it is not used. Regardless of how well an

Information Technology project goes from a project management perspective, an IT project is

not successful if the technology implemented is not used at least as well as intended. Technology

Acceptance Models assist in planning implementation of a new system from the user perspective.

The common elements to all of these models is that there are factors leading to attitudes,

which further lead to behavioral intent, hopefully leading to positive behaviors regarding

technologies being introduced. While the focus of these models is activity based, the basis for

actions is always an internal behavioral intent based on internal (psychological) and external

(environmental) factors. Both of these internal and external factors are components of the

traditional Organizational Change Management discipline, demonstrating that factors for

accepting technology are also important determinants of behavior in the organizational context.

In this discussion, we have seen the benefits of process management for a business.

Standardized processes can help a business respond more quickly to internal or external changes,

responding to client needs more quickly and more effectively. IT processes are specific to the IT

organization, and can also lead to better quality products and services, not the least of which is

IT software development projects. In order to deliver IT software development projects more

effectively, it is helpful to understand the clients’ needs as an organization, as well as to

understand clients as individual users. The Technology Acceptance Models have been used

successfully to do this. Organizational Change Behavior, however, can also provide additional

insight into the effects of process and IT product (e.g., technology) changes.

Organizational Change Management

Organizational design theory draws upon knowledge from several disciplines.

Organizational behavior, organizational design, sociotechnical systems design, systems theory,

engineering design, political behavior, and incentive systems all contribute to an understanding

of how organizations are designed, and therefore are important factors to consider when changes

to that organization become necessary (Markus et al., 2002).

In the context of a large technology change that affects enterprise-wide process,

organizations, and technology, the following five aspects are important when establishing a

process change management framework (Al-Mashari, 2003):

 Change management, which includes commitments, people, tools and

methodologies, communications, and interactions between those elements;

 Project management, beginning with team formation and development,

establishing appropriate roles and responsibilities, any external interactions

required, and measurements of progress;

 Strategic planning around process, which addresses process redesign,

measurements, and improvements;

 Continuous process management, with gap analysis of process details between the

―as is‖ process and the ―to be‖ future process, justification for changes to the

process, and integration with the project; and

 Technology management, ensuring that the right tools are selected, implemented,

and designed for end users.

These technology projects benefit the business most by updating and making sense of

process, more than just by implementing the new tools (Caldeira & Dhillon, 2010). Changes in

not only the technology occur, but also changes in organizational structure, workplace, and

workforce may all be necessary because of large-scale technology projects. The project, then,

must ensure that the process changes affecting the organization are not only managed but

incorporated into the business structure itself. This is not an easy task.

One author has coined the term ―technochange‖ to mean ―technology-driven

organizational change.‖ (Markus, 2005, p. 3) In the sense that organizational change is required

by technology projects such as those described above, this term can be applied when IT projects,

process, and organizational change must be applied in order to effectively implement a

technology that has large-scale change effects. The concept of technochange has been introduced

as an approach to ensure that all of these areas are considered. Assuming that it applies only to

large-scale technology projects, however, may not be accurate. It is possible that considering all

three of these areas—OCM, ITPM, and BPM—are necessary components in most, if not all,

technology projects. In order to be clear about the intent of technochange, this paper will refer to

the concept as Integrated Technology Change, implying that process management, IT process or

project management, and organizational change management are all considered when making a

change in technology.

Change is constant in business, from both internal and external forces. Political and

economic changes can drastically change the profit structure of a business, and therefore the core

business processes, without much warning. Regulatory and other legal requirements can also

change, necessitating more rigor in some areas than what may have been required before. The

Sarbanes-Oxley Act, for example, changed the way financials are reported. Managers must now

provide a much greater level of attention to financial reporting, as well as to how financial data

sources are managed for the business (Labate, 2005). In order to comply with the new reporting

laws, organizational structures may have had to change to be less ―fluid‖ or ad hoc; supporting

processes and policies had to change; and technology had to be modified to ensure that

everything financial could be traced back to original records. IT has had to respond by becoming

more process oriented and more business focused in order to support these requirements. Perhaps

more than any other business unit within any organization, IT has had to learn to become more

process centric in order to support quickly changing requirements in the business. Because of

this, there is a stronger need to integrate process management, organizational change

management, and technology, regardless of project size.

IT, then, must position itself to understand and implement the requirements of

organizational change management in ways that were not necessary before. It must incorporate

institutional analysis into its standard ―toolkit‖ in order to support the business, to understand

and explain the nature and consequences of the technical and social changes that pervade

business (Orlikowski & Barley, 2001).At the project level, IT must also incorporate business

analysis in order to support the changes that the new technology will require in the client’s

business processes.

OCM approaches. Organizational change theorists generally consider IT to be an

applied science, whereas organizational change management theory is considered a more general

discipline (Orlikowski & Barley, 2001). Organizational theory focuses on observable behavior

between individuals, groups, and business units within organizations. Research in this area

strives to find causal relationships, general principles, and regularities that explain how and why

people behave the way they do.

A typical approach, from an OCM view, is to see IT as merely a potential factor in

determining behavior (Orlikowski & Barley, 2001). IT has been seen as a deterministic factor,

which is important, but not something that might be the catalyst for changing organizations

because of the decisions that people make when using technology. For example, technology

users can choose to use technology in ways that are not intended. They can also choose not to

use technology at all. Both of these situations affect organizational planning, because the

expected benefits, results, or use of technology may or may not be realized as planned. OCM,

then, has been short-sighted in understanding how important IT is within the scope of

organizations. IT practitioners have also not typically understood how important their role is

within the context of how organizations work, especially in the area of IT projects. Most IT

projects do not consider how the organization may have to change after implementing a new

technology, and IT practitioners generally do not study organizational change that occurs as a

result of completing a software project.

In any organizational change effort, success depends on the joint efforts of managers who

want the change, and the change agents who are working to make the changes (Trkman, 2010).

This has to be done, then, in the context of IT, for any IT project that makes changes to the way

people work. An IT project, for example, that upgrades a version for a supporting system—such

as a UNIX server—may be invisible to the end user of that server. An IT project that makes

changes to the way people work, however—such as an IT software project—will require some

level of organizational change management in order to ensure that the end users are enabled to

use the system as intended by the project sponsors. It is not as much a matter of project size as

much as it is a matter of significance of the change required by the end users of the new

technology. The scope for the interaction between BPM, ITPM, and OCM is especially

important in IT software projects, requiring more effort for large-scale projects, but also not

ignoring the need for this level of change management for small- to medium-scale projects.

Facilitating change requires equipping people as well as changing process (Gillies &

Howard, 2003). Change agents who are closest to understanding what needs to change in the

way people work are the IT practitioners who are either designing, coding, and implementing

those changes, or working with those on the project team who are (Markus & Benjamin, 1996).

Therefore, one or more IT practitioners who are working on a software project could implement

a simple organizational change process as depicted by Gillies & Howard (2003). This model

focuses on ensuring that people have the capability to implement change, especially within the

context of processes. The end result is defining the training that will be required by the process

changes required by the new technology.

Integrated technology change management. Within an IT software development

project, then, more change is required than simply software tool changes. Process and

organizational changes must also be considered. Digging deeper into the current processes is

required in order to understand what needs to change to accommodate the new system.

Organizational structure changes may even be required, which could be determined by process

analysis. While the new technology may be a powerful tool for a business, the traditions and

social norms within an organization are more powerful, and must be considered in order to

ensure process acceptance necessitated by the new technology (Markus, 2005).

There are significant differences between a typical IT project, an Integrated Technology

Change project, and a typical Organizational Change project. APPENDIX A contains a table

describing the differences between the three approaches (referring to Integrated Technology

Change as ―technochange‖). The primary differences between the three approaches can be

summarized in the intent. An IT project’s target outcome is to deliver a new technology that

works as expected, within scope, schedule, and budget. The same project performed with an

Integrated Technology Change viewpoint would include the same outcome as an IT project, but

would also focus on improvements in organizational performance (process)—a bigger picture

approach. An organizational change approach to the project would focus on changes or

improvements in the organization’s culture or performance, with little regard for the technology

itself (Markus, 2005).

Another key difference between the three is that what is delivered for an IT project is

simply the new solution or technology. Using the Integrated Technology Change philosophy, the

solution would be delivered, but would also deliver complementary organizational changes, such

as realignment of roles that might occur as a result of the new technology. New training, and new

step-by-step procedures or job aids would follow. This Integrated Technology Change approach

is more holistic, perhaps resulting in restructuring business processes, changes in reward

systems, and redesigning jobs. The organizational change perspective is needed as well, since

that would address attitudes and behaviors of management, assist the Human Resources

department with development and training, and ease transition of the new system into the

existing organization’s culture.

The role of the IT practitioner, who is supporting the project, is central to both standard

IT projects and Integrated Technology Change projects. In a typical IT project, the IT

practitioner performs most of the project labor. In an Integrated Technology Change project, an

IT practitioner might work together with the client’s managers, IT managers, and other IT

practitioners to design a solution that meets all objectives of the new solution. The IT practitioner

becomes one of many change agents working to achieve system success (Markus, 2005). This is

a new process role for IT, requiring not only additional training, but a new mindset or attitude

toward process.

IT practitioners are not necessarily trained to think about process as a core competency

that they deliver to clients, especially in the context of software projects. One way to enable this

is to establish a Process Center Of Excellence (COE) (Strickler, 2009) that will not only train IT

professionals, but also ensure that process management is integrated with business processes, IT

processes, and organizational change management requirements (Allen, 2003). This COE would

help design post-project work to include ensuring that technologies are used as the project

sponsors intended, requesting the necessary resources for user training, producing metrics to

monitor process adoption, and reporting on client satisfaction well after project completion

(Jasperson et al., 2005).

A second way to address the issues around process management is to ensure that

processes are not only accepted but adopted by IT practitioners. Process acceptance implies that

IT practitioners acknowledge that processes are the standard ways that things get done; process

adoption, however, indicates that the processes have become a way of life, reflected in attitude

and intent, an accepted part of one’s toolkit in getting things done. Adopted processes are those

that are embraced, rather than just those that are acknowledged. This process adoption is what is

most desired by managers who want to rely on critical work being done in a way that best

supports the business. Adoption by IT practitioners, however, may be different for IT

practitioners because of their unique characteristics as technology professionals (Glen, 2003).

These IT professionals tend to be ―highly intelligent, usually introverted, extremely valuable,

independent-minded, hard-to-find, difficult-to-keep technology workers who are essential to the

future of your company.‖ (Glen, 2003, p. 5)

Putting it All Together

IT processes, in review, are important to ensure that appropriate industry best practices

are being followed; to enable review of standard processes so that expected results are most often

achieved; to ensure that IT is performing in alignment with business strategies; and to provide

value to IT’s clients. These have been established by reviewing the importance of business

processes in running a business, in understanding the meaning and context of continuous process

improvement, and in addressing some of the most common challenges to business process

management. IT’s role in not only following the organization’s processes, but in developing its

own, have been shown to be critical to successfully supporting the organization’s needs. While

IT’s processes must be in alignment with those of the business, they must also be relevant and

appropriate for supporting the core activities that IT performs. One of the most critical areas for

process management is in the area of IT software project management, because of the unique

nature of developing software, as well as meeting the client’s requirements. IT software projects

generally follow industry standards established by a variety of important sources, including the

Project Management Institute; but most of these standards do not include any formalized

component for managing organizational change, or for customizing processes in a way that

supports organizational change necessitated by the new technologies that software projects

implement. While there are a variety of approaches to performing OCM activities, perhaps the

one most compatible with IT software projects is the Integrated Technology Change approach,

which requires that IT practitioners embrace not only IT software development processes, but

also end-user process management, in order to ensure that the software products meet the needs

of the client as implemented. This approach to process will require more emphasis on user

process acceptance, which is not a metric measured by standard project management practices

(Markus, 2005).

In order to address these two levels of process capability, then, it would be valuable to

understand the determinants of process acceptance and adoption by IT practitioners. These

acceptance levels could be evaluated by surveying a group of practitioners using a survey

modeled after the Unified Theory of the Use and Acceptance of Technology (UTAUT)

(Venkatesh et al., 2003). The model tests acceptance of a technology from the following four

aspects:

 Performance expectancy

 Effort expectancy

 Social influence

 Facilitating conditions

These four determinants are further moderated by gender, age, experience and

voluntariness of use, leading to behavioral intent, and finally to observed behavior, or process

acceptance. Process adoption is measured by relating behavioral intent to attitude and measuring

the level of positive (or negative) attitude toward process.

Additional information about acceptance and adoption of process could be gathered by

asking open-ended questions regarding the concept of a deeper level of process support in IT

software projects. This is the concept proposed by Markus & Benjamin (Markus, 2005; Markus

& Benjamin, 1996) termed ―technochange,‖ or ―change agentry‖ in the context of client support.

These verbatim responses added value and depth to the responses gathered by the survey.

Research Hypotheses

The literature review has demonstrated that the three areas of Business Process

Management, IT Process Management, and Organizational Change Management, are all critical

to success of software development projects. Core to each of these areas is an understanding and

acceptance of process within IT, within the enterprise, and on behalf of IT’s clients. With this in

mind, the technology acceptance model, as stated in the Unified Theory of the Acceptance and

Use of Technology (UTAUT), was used as an instrument to judge determinants of acceptance

and adoption of processes by IT practitioners who support software development projects. While

this instrument has been used primarily to measure acceptance of new technology, it has been

used effectively to measure acceptance in other areas.

Acceptance and adoption of not only the importance, but also of the use of processes by

IT practitioners who support software development (and enhancement) projects was measured by

the same instrument. The instrument for the UTAUT measures acceptance and use by assessing

each of the following areas:

 Performance expectancy (The process helps me perform my job more

effectively.)

 Effort expectancy (The process is easy to use.)

 Social influence (The process is accepted and expected by others with whom I

work.)

 Facilitating conditions (My organization has made changes to make the process

easier to follow.)

Acceptance and adoption of process can be moderated by a number of factors, such as

age, gender, experience, and level of voluntariness. Other factors, not suggested by the UTAUT

but still of interest, may also moderate or influence the level of acceptance, such as job title or

function on a software project development team. For example, a developer may be required to

follow processes to support standard development practices, such as those required by the

Capability Maturity Model. Project managers may be required to follow processes to support

industry-standard practices suggested by the Project Management Institute. Business analysts

may not be required to follow industry-standard processes, and may therefore have a different

attitude or belief about processes.

To support analysis of acceptance and use of process, then, within the context of the

enterprise, the IT organization, job-specific IT procedures, and IT’s clients, the following

hypotheses will be tested.

Hypothesis 1: Processes and procedures are more likely to be accepted and adopted if

they are perceived to increase one’s effectiveness on the job.

Hypothesis 2: Processes and procedures are more likely to be accepted and adopted if

they are perceived to be easy to use.

Hypothesis 3: Processes and procedures are more likely to be accepted and adopted if

social influence is strong.

Hypothesis 4: Processes and procedures are more likely to be accepted and adopted if

facilitating conditions exist, making it easier to implement the processes.

These hypotheses will be tested by using a survey instrument, similar to that employed to

test the UTAUT, described in Chapter 3.

CHAPTER 3. METHODOLOGY

The methodology for conducting this study is discussed, including the sampling, setting,

measurements used, data collection method, and data analysis. Additional consideration has been

given to establishing validity and reliability, as well as ethical considerations for conducting this

study.

Research Design

This study is designed to test the acceptance and adoption of process, following the same

method used to test the Unified Theory of the Acceptance and Use of Technology (UTAUT)

number of studies (Foon & Fah, 2011; Hong, Thong, Chasalow, & Dhillon, 2011; Lu, Yu, &

Liu, 2009; Wang, Liu, Tseng, & Tsai, 2010), each with a different focus. This study has been

conducted specifically to ascertain the determinants of process acceptance, as suggested in an

article by Venkatesh (2006) as one of the future directions that should be explored using this

model. In that article, he states ―The three specific avenues for future research that I identify and

discuss at length are: (i) business process change and process standards; (ii) supply-chain

technologies; and (iii) services.‖ (Venkatesh, 2006, p. 499) For this study, business processes

within the context of IT software development processes and procedures were selected.

This study was conducted using a quantitative survey. Three open-ended questions were

also included at the end of the survey to give respondents an opportunity to express their own

opinions on a variety of questions related to adoption of process. (See Appendix B for the

questions in the survey, as well as the coding that was used to measure each question.) Using

primarily quantitative data for the research enables analysis on more specific questions. Adding a

short qualitative component, through open-ended questions at the end of the survey, enables the

researcher to cross-check, or validate the respondents’ understanding of the quantitative

questions, and to potentially gain a different perspective than would have been available on

strictly quantitative responses (Miles & Huberman, 1994). Permission to use the original survey

in Venkataesh et al. (2003) was granted by Dr. Venkatesh in an email dated January 18, 2012.

As stated by the UTAUT by Venkatesh et al. (2003), the four expected determinants for

acceptance and adoption are: performance expectancy, effort expectancy, social influence, and

facilitating conditions. While initially designed to study technology acceptance, these

determinants were used to test process acceptance. These were then correlated with age, gender,

and experience, demonstrated by the Venkatesh study. To test additional correlations, I have

added job classification (or title), years of experience (in five-year ranges), and the company’s IT

group or organization. This additional information was used to test dependencies of process

acceptance that are more closely related to the job that the respondents perform, such as job

classification and organization. The job classification demonstrated types of jobs that are more

likely to accept the role of processes and procedures; and the organization name was collected to

relate to the culture of the organization, the nature of the work performed by the organization, or

even the management style of the organization. Since these are beyond the scope of the study, it

is expected that no definitive conclusions will be drawn from this data, other than to compare

responses between organizations and job classifications. The study, then, was correlational,

studying responses from a specific group of people within one company’s IT organization. Each

question was correlated with the respondent’s stated intent to use processes.

Sample

IT practitioners who work on software development or enhancement projects in some

way comprise the target population. For this study, the sample was drawn from one company’s

IT workforce. In order to find those practitioners, data was extracted from the company’s work

management system, SAP, as follows:

 Using SAP transaction IW39, extracted open work orders with work types that

correspond to project work. (E1 and E2 are work types that indicate consultations

for projects; A1 and A3 are work types that indicate project work.)

 Using SAP transaction CADO, extract a timekeeping report to find IT

practitioners who charged time to these work types within the months of

November and December 2011, extracting the name, personnel number (PERNR),

manager name, and contact information.

 Produced a ZHCMDATA report (custom SAP report written for the company) to

extract the titles and email addresses of each IT practitioner. Having the titles

allowed the researcher to ensure that at least 10 practitioners from each HR

classification (e.g., manager, analyst, developer) were selected to participate, and

to double-check that each respondent’s reported job title matches that in SAP. The

email addresses were used to send invitations and follow-up emails to potential

survey respondents.

 Using Microsoft Access, created a practitioner list from the CADO report, joined

(by PERNR) with HR data from the ZHCMDATA report, selecting only those

practitioners who reported time on E1, E2, A1, and A3 work orders included in

the IW39 report, to compile the final list of participants and email addresses.

Included employees, contingent workers, and their managers in the list. The

relationships of the data exported from SAP are depicted in APPENDIX .

 Exported the final list into Excel, ensuring that the employee’s name, title, and

email address were exported.

 Manually validated the data from the report. Counted the number of participants

in each HR title category to ensure that there were at least 10 in those HR titles

represented. (Not all IT titles were represented in the sample. Executive

Assistants, for example, do not charge time to projects and were excluded.)

Excluded any groups for which there are not at least 10 representatives.

 Prepared the data to be imported into the online tool, Survey Gizmo. This tool

managed emailing all participants, and compiled responses that were exported

into SPSS.

Setting

The setting for this study was a large company on the west coast of the United States,

with an IT department of approximately 3000 employees and contingent workers. IT is divided

into four divisions: Cybersecurity and Technology Resiliency (CTR); Infrastructure Technology

Services (ITS); Technology Delivery & Maintenance (TDM); and Client Service, Planning, and

Controls (CSPC). Project managers generally report to TDM, as do most of the traditional

software development roles. Infrastructure experts generally report to ITS, but generally do not

charge time to specific projects. Project engineers generally report to CSPC, and are asked to

participate only at various key points in the project, where engineering expertise is required. It is

because of this organizational structure that the survey is designed to capture both job

classification and organization. Finding job classifications in unexpected organizations may have

add additional understanding to responses from respondents in those organizations. No

anomalies, however, were found.

Instrumentation / Measures

The survey instrument contained 31 quantitative questions. These questions were

designed to indicate level of agreement or disagreement, using a Likert scale, with a statement

about processes, as they are related to the constructs of the Unified Theory of the Use and

Acceptance of Technology. The respondent could also choose to select ―Not Applicable.‖ The

constructs that were hypothesized as significant were: Effort Expectancy, Performance

Expectancy, Social Influence, and Facilitating Conditions. Additional constructs were: Anxiety,

Self-Efficacy, Behavioral Intent, and Attitude. The responses to the ―Behavioral Intent‖

questions were used to correlate with the others to determine process acceptance. Responses to

questions in the ―Attitude‖ section were correlated with intent to measure process adoption.

Following the questions, the respondent had the opportunity to write a response to each

of three open-ended, qualitative questions. These questions were intended to provide a richer

context of response from each of the respondents, asking them to provide their own opinions in

their own words. The responses to these questions were coded, analyzed, and compiled using

nVivo software, in order to discover trends and beliefs that underlie the quantitative portion of

the survey, specifically about how processes relate to software projects and their clients.

In order to understand how different factors might also play a role, the survey ended with

several demographics questions asking the respondent to identify age range, years of IT

experience, gender, education, certifications, and HR classification (or Title).

Data Collection

Data was collected using an online survey tool, SurveyGizmo.com. The tool was used to

send the invitation email, a reminder email to those who had not responded within two weeks of

the initial invitation letter, and thank you emails to those who responded. The invitation email

described the survey and invited the recipient to participate, with a personalized link to the

survey. The survey then began with the informed consent form, and was open for responses for a

total of three weeks. During this time, SurveyGizmo collected responses and recorded who had

responded to the survey, thanking those who completed the survey. For those who had not opted

out and yet had not completed the survey, SurveyGizmo sent a reminder email two weeks after

the initial invitation was sent. At the conclusion of the third week, the survey closed.

SurveyGizmo allows the researcher to export responses in either Excel or SPSS format,

so that the responses can be imported directly into these tools for analysis. As with all electronic

data captures, however, some clean-up of the data was required in order to ensure that the data

exported correctly. This clean-up activity was completed before beginning to analyze the data.

Data Analysis

Because the survey is testing the level of acceptance and adoption of processes and

procedures by IT professionals, the data was analyzed to show overall acceptance and adoption

for each of the four proposed determinants (performance expectancy, effort expectancy, social

influence, and facilitating conditions) as well as three additional potential determinants (anxiety,

self-efficacy, attitude, and behavioral intent). Each of the questions in the survey was designed to

answer one or more aspects of one of these determinants, as shown in APPENDIX B.

The survey asked for level of agreement (strongly disagree to strongly agree, as well as

not applicable) with statements that showed how much the respondent accepts processes and

procedures. Each question asked for level of acceptance in each of four working areas or

contexts where processes and procedures are commonly used: enterprise processes, IT-wide

processes, job-level procedures, and client processes and procedures.

The survey also collected demographic information from each respondent, including age,

gender, experience, education, organization, certifications, and job title. The original article,

upon which this survey is based, only considered age, gender, and experience as moderators of

the data. However, because this survey is being conducted in one company, it was useful to

compare responses from people in organizations that perform different functions on software

projects. It was thought that adding certifications as a moderator might also change the way a

respondent views processes, as some certifications are very process-centric. However, none of

the certifications were found to be significant moderators.

After the initial data analysis was complete, results were compared, showing which of the

constructs contribute to process acceptance and adoption, as well as differences in responses

between various demographic groups.

In order to complete this data analysis, the data was first exported from Survey Gizmo

and prepared for analysis. Before importing the data into SPSS, an initial sweep of the data was

be made using Microsoft Excel. This data sweep found and repaired obvious misalignments of

data. The data was then imported into SPSS, which was used as the primary tool for analyzing

the survey data.

The survey ended with the following three open-ended questions:

1. How do you believe that IT processes and procedures affect the way you support IT

software projects?

2. What is your role in understanding the way your clients do business?

3. If you could express one important thing to your management about how processes

and procedures are managed within IT, what would that be?

Responses from question 1 were tabulated across each of the potential determinants to

add depth to the quantitative responses. Responses from question 2 were tabulated to show three

levels of understanding of how the clients’ processes affect the work that the respondent does.

Finally, responses from question 3 were tabulated as specific suggestions that will be provided to

management in a summary form.

In order to prepare for coding responses, nVivo was prepared with nodes corresponding

to the eight determinants to provide a mechanism for recording statements that corresponded

with these determinants. All open-ended responses were imported into nVivo, and each response

was categorized into the nodes. Additional nodes were added as the context evolved.

Validity and Reliability

It is also important to consider the study’s generalizability. Being generalizable implies

that the results of the study could be equally applied across similar groups—in this case, IT

departments in large companies (Maxwell, 2002). If this study were being conducted across a

number of companies or departments, rather than one, it would be more generalizable to the

population of IT practitioners as a whole. However, because the sample size is relatively large,

and the practice of software development is common, the results of the study are still helpful and

useable in similar circumstances. One would not, however, automatically assume that the results

are generally true, or generalizable to all IT departments in large companies.

In order to help ensure that the instrument is valid, terms will be defined in the left

margin of each of the three pages of the survey. The same information was repeated on all three

pages to ensure that the same definitions were available at all times while answering questions.

This increased the likelihood that the questions and terminology used were understood by the

participants. The survey tool did not require an answer for any of the questions, and each one had

a ―not applicable‖ response available if the respondent does not understand or chooses not to

answer a specific question. If any one question had received a larger percentage of ―not

applicable‖ responses, those questions were not likely understood, truly not applicable to one’s

situation, or asked in such a way that the respondent felt uncomfortable answering the question.

However, none of the responses indicated any patterns of ―not applicable‖ responses.

Ethical Considerations

Since the researcher is employed by the company being researched, special consideration

was given to ensuring confidentiality of the respondents. The survey was designed to be as

anonymous as possible. None of the respondents are direct reports of the researcher. Job titles

provided in the demographics section were broad enough to keep one’s identity secure. If,

however, less than five people within a job classification had responded, and each of those

provided information on the division for whom they work, it may have been possible for

someone who is looking for clues on identity to guess a respondent’s identity. To ensure that did

not happen, results were summarized only at generic job titles that have 10 or more respondents

(analyst, developer, technical, manager, and project manager). The more specific the

demographic information provided, the greater is the danger that a respondent’s identity would

be guessed. Therefore, those demographic areas were handled with special care to ensure that

each person’s confidentiality was not breached.

The online tool, SurveyGizmo, tracks the respondents’ identity, assigning a respondent

number corresponding to each email address that responded. In order to ensure that respondents’

identities are protected, this identifying data will be kept online.

As noted earlier, each respondent was given the opportunity to provide informed consent

before beginning the survey. An incentive to participate was also given. Upon completion of the

study, a random drawing was held. The prize was a choice of a Kindle Fire, an Apple TV device,

or $100 cash. The winner selected the Kindle Fire.

At the conclusion of the survey, each participant was given a separate place to enter the

email address they would like used to participate in the drawing, since they had been invited to

participate in the survey using their company email address. Giving the participant the option to

use a different email address for the drawing provided an additional level of separation of their

identities from the survey.

CHAPTER 4. RESULTS

Introduction

The purpose of this study was to identify those factors that contribute to the acceptance

and adoption of processes within the context of software development project management

teams. An online survey was used as the tool to gather data from participants on software

development projects at a large corporation within Southern California. The survey itself was

modeled after a similar survey used to measure acceptance of technology using the following

eight factors:

 Performance Expectancy

 Effort Expectancy

 Attitude Toward Using Technology (or Processes)

 Social Influence

 Facilitating Conditions

 Self-efficacy

 Anxiety

 Behavioral Intent to Use the Technology (here, Processes)

The survey was sent to 460 potential participants at the company. These potential

participants were selected from all employees and contractors within the Information

Technology Department of a large company in Southern California, who had charged time to

software development projects during two of the last months of 2011. These are the people

whose time directly impacted software development projects specifically, and not those whose

jobs are to support all projects equally. For example, developers, testers, and analysts charge

time to specific projects, whereas server technicians charge their time to the departments they

support, which may or may not support projects directly. Targeting employees who charge time

to projects will give the best representation of the impact of processes and procedures within the

software development environment, and not supporting all of IT. The people who responded,

then, can be said to reflect the opinions of processes and procedures within the context of

software development, not within the overall context of IT processes and procedures. This is an

important distinction, because the nature of software development and project management is not

as clearly associated with following processes and procedures as it might be elsewhere within IT.

Of those surveyed, sixty-three people responded to and completed the survey,

representing a 14% response rate. Of those, eleven were incomplete. It was felt, however, that

those responses should still be included in the results, but treated as missing responses when

performing the analyses with SPSS. Removing the eleven responses would have had a large

effect on the total percentage of responses received, and may have negatively impacted the

analysis of groups using moderators, such as title, IT organization, gender, age, and experience.

With that said, all of the analyses were run, excluding missing responses where they occurred

without ignoring the rest of the information supplied by the respondent. In the SPSS software,

this was done by indicating that each analysis should be run, excluding missing responses in

pairs (pairwise), rather than entire responses (listwise).

To show how the respondents represented participants in software development project

teams, descriptive analysis shows that among those who responded, one-third are between the

ages of 30 and 39, with roughly 20% in the age categories of 40 to 49 and 50 to 59. Only 6% are

60 years of age or older; 14% are between the ages of 20 to 29. This demonstrates that there is a

larger percentage of employees who have likely been working for several years, with relatively

few younger employees working on software development projects. Another aspect of the

workforce to be considered is the number of years of experience. Over half of the respondents

(55%) have between 0 and 15 years of experience; 13% have over 30 years of experience. As

expected, there is a significant correlation between years of experience and age. Assuming

significance at p < .05, Pearson’s rho is .000 with a strong correlation of .811.

Only 11% of the respondents had less than a bachelor’s degree. Another 59% had a

bachelor’s degree, with 30% holding advanced degrees. Correlating education with experience,

however, does not show a significant relationship. Also, age and education do not appear to be

significantly related in this group.

Disappointingly, only one person from the Infrastructure Technology Services (ITS)

division responded. Therefore, any analyses using the home room as a factor will exclude this

division. Most of the respondents (86%) are from the Technology Delivery and Maintenance

(TDM) division, while nearly 13% are from the Client Services, Planning and Controls (CSPC)

division. In context, this would appear to be valid, because most of the people charging time to

software development projects would be from the TDM division within IT. Only the more

technical analytical positions (such as project architects) would be from the CSPC division,

which represents a very important (but also a very small) part of the overall software

development process.

Each respondent also indicated his or her general job title, divided into the following four

groups: analysts (35%), developers (9%), managers and project managers (35%), and technical

experts (21%). These distinctions are important in understanding the level of acceptance and

adoption of processes, since each group might utilize procedures or processes differently.

Analysts and developers, for example, would have a very ―hands-on‖ perspective of procedures,

while managers and technical experts may be more concerned with higher-level processes, with

the ―big picture‖ in mind. Further analysis will show how these might be related.

Since the survey was conducted using an online survey tool, and no interaction was

required between the respondents and the researcher, it is assumed that no bias was introduced in

conducting the survey. Other than the introductory and reminder emails, the researcher had no

personal contact with the respondents of the survey.

Questions on the survey were modeled after questions asked on a survey conducted by

Venkatesh et al. (2003). The context of the original 31 questions was changed from a focus on

technology to a focus on processes. As previously mentioned, this is supported by Venkatesh

(2006). While the original survey found that four of the eight potential determinants of

technology acceptance were significant, it was felt that for this study, testing the respondents on

all eight of these focus areas would be appropriate to compare the results between the two

studies.

The research question, posed early in this study, is: 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? In order

to address the different functional areas served by IT, the current study also added the four

contexts of processes from four viewpoints: enterprise-wide processes, IT-wide processes, job-

specific procedures, and client processes. Results of this study found that each of these four areas

indicate that there are differences in acceptance and adoption of processes and procedures for

each functional area. PASW Version 18 was used to perform the analysis of the data, using an

export from the SurveyGizmo online tool.

100

Reliability of the Data

The structure of this study closely mimicked that of the original study, using the same

number of questions for the same determinants (see Table 6).

Table 6.

Items Used in Estimating UTAUT for Process

Potential Determinant Number of Questions

Performance expectancy 4

Effort expectancy 4

Attitude toward using processes 4

Social influence 4

Facilitating conditions 4

Self-efficacy 4

Anxiety 4

Behavioral intent to use processes 3

To ensure that the current study maintained internal consistency and reliability, the

Cronbach’s Alpha test was used. Results of this test demonstrated internal consistency in the

instrument as a whole, and within each of the eight potential determinants (Table 7).

101

Table 7.

Reliability Scale Using Cronbach's Alpha

Scale Cronbach’s Alpha

Entire instrument .943

Performance expectancy .833

Effort expectancy .905

Attitude toward using processes .921

Social influence .922

Facilitating conditions .880

Self-efficacy .908

Anxiety .964

Behavioral intent to use processes .962

A reliability coefficient of .70 or greater is normally considered to be acceptable (―What

does Cronbach's alpha mean?,‖). The values in Table 7, then, demonstrate that there is internal

consistency and reliability not only in the entire instrument, but within each of the eight

determinant areas.

Testing for normality revealed that all eight determinant areas are distributed normally.

Only the histograms for anxiety are negatively skewed to the right, while the histograms for the

other seven functional areas tend to be positively skewed to the left. Comparing this to the data

reveals that in fact, most of the responses, on a scale of 1 to 5, fall somewhere between 3 and 4,

except those for anxiety, which fall between 2 and 3 on average. This simply means that most of

the responses were somewhere between neutral (neutral = 3) or positive (agree = 4), except for

the questions measuring anxiety. Here, most people disagreed with the process areas causing

anxiety (disagree = 2), or were simply neutral about anxiety surrounding use of processes and

procedures (neutral = 3).

102

In order to point out any obvious problems with the hypotheses, a nonparametric test was

run for each of the questions. This test demonstrated that each one, at first glance, appears to

meet the test for rejecting the null hypothesis. For example, the first question tested, ―I would

find processes or procedures useful in my job,‖ in the context of enterprise processes, was found

to be likely to occur with equal probabilities, rejecting the null hypothesis. The one-sample Chi

square test was selected by SPSS for this particular question to determine that the probability for

a response in each of the values was likely, with a significance of p = .001. Similar tests were

selected by SPSS to show that each question, in turn, had been tested to show that the null

hypothesis should be rejected.

Research Results

The results of the survey were analyzed in order to test the following four hypotheses:

Hypothesis 1: Processes and procedures are more likely to be accepted and adopted if

they are perceived to increase one’s effectiveness on the job.

Hypothesis 2: Processes and procedures are more likely to be accepted and adopted if

they are perceived to be easy to use.

Hypothesis 3: Processes and procedures are more likely to be accepted and adopted if

social influence is strong.

Hypothesis 4: Processes and procedures are more likely to be accepted and adopted if

facilitating conditions exist, making it easier to implement the processes.

Each of these four hypotheses was tested in the context of the enterprise, IT as an

organization, IT job-specific procedures, and the processes of IT’s clients. Moderators of these

hypotheses included age, gender, experience, education, organization, and job title.

103

Data aggregation. Even though there are fundamental differences in each of the four

contexts, it would still be useful to analyze the means of the four context areas for each question

in aggregate in order to get not only a general idea of what the mean values are, but also as a

basis to compare each of the four different contexts. For example, question one of the survey

read: ―I would find processes or procedures useful in my job.‖ Response areas were provided for

the contexts of enterprise-wide, IT-wide, job-specific, and client processes; there was no

response area provided for processes or procedures in general, as shown in a screen shot of the

survey (Figure ).

Figure 3. Screen shot of survey

The data, therefore, was aggregated into another data set having one response with the

mean of all four contexts areas, in order to generate a mean score for each question. From this

analysis, it was easy to see that the means of most of the responses were between 3 (neutral) and

4 (agree), with the notable exception of the questions regarding anxiety and those regarding

attitude toward using processes. The mean scores show that respondents generally are neutral

toward or disagree with the following statements:

 Processes or procedures make work more interesting.

 Using processes or procedures is fun.

104

 I feel apprehensive about using processes or procedures.

 It scares me to think that I could fail at my job if I were to use processes or procedures

incorrectly.

 I hesitate to use processes or procedures for fear of making mistakes that I cannot correct.

 Processes or procedures are somewhat intimidating to me.

Those aggregate items that respondents felt most strongly about (agree to strongly agree)

were:

 I would find processes or procedures useful in my job.

 Using processes or procedures is a good idea.

Further analysis of the questions and responses will demonstrate differences between

each of the four contexts.

Data analysis of responses. The online survey tool collected ordinal responses to thirty-

one questions, each with four different contexts. This resulted in a total of 124 individual

responses per survey that are related to the original UTAUT survey by Venkatesh et al. (2003).

Because the data is ordinal, it is important to select tests appropriate to this type of data.

According to Newton & Rudestam (1999), the tests most appropriate for ordinal data are

crosstabulation, using bivariate and multivariate contingency table analysis, and correlation. The

data, therefore, was converted from text to numbers to make analysis easier. In this case,

―Strongly disagree‖ was converted to a score of 1, ―Disagree‖ was converted to a score of 2,

―Neutral‖ was converted to a score of 3, ―Agree‖ was converted to a score of 4, and ―Strongly

agree‖ was converted to a score of 5. ―Not applicable‖ was given a score of 0 so that it would not

skew the results, and missing values were coded with the number 8 so that SPSS would ignore

missing values in its calculations. Because each question is basically the same question but with

105

four different contexts, there were no dependencies in the data within questions. Missing values

were ignored only for the individual context for the question (missing values excluded pairwise);

the entire question was not ignored (which would have been coded as missing values listwise).

In order to evaluate the responses for the eight potential determinants, means were

calculated in each of the four context areas (Table 8). This shows, at a glance, where responses

are generally positive (greater than 3) or negative (less than 3). The table shows that only the

potential determinant ―anxiety‖ is negative.

Table 8.

Means of Potential Determinants by Context

Context

Potential Determinant Enterprise IT Job-Specific Client

Performance Expectancy 3.74 3.92 4.04 3.60

Effort Expectancy 3.59 3.73 3.89 3.33

Attitude 3.33 3.44 .346 3.20

Social Influence 3.49 3.57 3.58 3.28

Facilitating Conditions 3.50 3.60 3.67 3.11

Self-efficacy 3.65 3.69 3.68 3.28

Anxiety 2.37 2.38 2.36 2.32

Behavioral Intent 3.98 4.00 3.99 3.56

Performance expectancy (PE). The first four questions of the survey solicited

respondents’ perceptions about how processes and procedures support job performance. In all

four contexts, respondents generally felt that processes and procedures would support better job

performance. The last question for PE, however, proposed that using processes or procedures

would increase one’s chances of getting a raise. Most respondents generally disagreed with this

statement. For this particular company, current economic conditions have made getting a raise

unlikely. Using this question as a factor, then, would likely introduce bias in the responses for

106

PE. For the purposes of further analysis, then, this particular question will be excluded from the

analysis.

Effort expectancy (EE). Responses for EE were generally positive, ranging from

―neutral‖ to ―agree‖ in most instances. Only one question in the context of client processes had

lower scores. More respondents disagreed that client processes were clear and understandable

than in any other context. Even for that question, though, the mean of the responses was 3.05,

with a relatively higher standard deviation of 1.408. Generally, however, the responses appear to

show agreement that work is easier to accomplish with processes and procedures.

Attitude toward using processes (ATT). Responses for ATT were somewhat neutral

when it came to enjoying processes and procedures, or even somewhat negative, when

evaluating whether following them was ―fun.‖ While some indicated that they ―like‖ following

processes and procedures, more of them agreed that having and following them is a good idea.

Here, then, the responses ranged from giving mental assent that it is a good idea to follow them,

but not necessarily fun or interesting. Because the responses for ―a good idea‖ were relatively

strong, it is important to note that the means for the contexts of Enterprise, IT, Job-Specific, and

Client processes were 4.19, 4.37, 4.37, and 4.05 respectively. The median scores for these were

4, 5, 5, and 4 respectively, indicating that respondents felt very strongly that processes and

procedures were good for all areas but especially for IT-wide and job-specific contexts. There is

less agreement about enterprise-wide, and even less for client contexts.

Social influence (SI). Perhaps more than any other potential determinant, responses for

SI demonstrate general agreement that there are others who influence the acceptance of

processes and procedures. Most agree that people who are important to them or who influence

their behavior believe that processes and procedures should be followed. Respondents are more

107

neutral about senior management being helpful; mean responses were 3.18, 3.24, 3.29, and 3.08

in the context of the enterprise, IT, job-specific procedures, and client processes respectively.

Respondents generally agreed, however, that their own organizations support the use of

processes and procedures (mean scores of 3.87, 4.0, 3.95 and 3.48).

Facilitating conditions (FC). Questions regarding facilitating conditions centered around

having the resources, knowledge, and experts available to help with using processes and

procedures. More respondents agreed, though mildly so, with saying that these conditions are

present. One question asked whether the existing processes and procedures are compatible with

the way work gets done; responses to this question were more neutral. It would appear from

these responses, then, that facilitating conditions may be less a factor toward behavioral intent

than some of the other potential determinants.

Self-efficacy (SE). Since the respondents of this survey are all members of the

Information Technology Department, and since processes and procedures tend to be predominant

in completing work on software development projects, it is expected that self-efficacy, or the

ability to understand and follow processes and procedures, would be relatively strong in this

group. Responses to these questions indicate that indeed these IT professionals generally agree,

across all contexts, that they could use processes and procedures to complete their tasks.

Anxiety (ANX). More than any other potential determinant area, ANX was not found to

be a factor in accepting or adopting processes. In fact, the mean scores were 2.37, 2.38, 2.36, and

2.32, in the contexts of enterprise, IT, job-specific, and client processes respectively. These

means indicate that respondents do not agree that they experience apprehensiveness, fear,

hesitation, or intimidation from having processes in any context. It is unlikely that these

responses will correlate with intent to use processes or procedures.

108

Behavioral intent to use processes. Nearly all responses indicated agreement that there

was positive intent to use processes and procedures. Mean responses for these questions were

3.98, 4.0, 3.99, and 3.56 in the contexts of enterprise, IT, job-specific, and client processes

respectively. Because all of the questions indicated positive intent or behavior, just one of these

questions was used to correlate intent with the other potential determinants for using processes

and procedures in order to ascertain whether intent is a significant factor in the responses. One

question specifically stated ―I intend to use processes,‖ and was used to correlate across all other

determinants to test behavioral intent, or acceptance. These correlations support analysis of the

four hypotheses stated earlier, that performance expectancy, effort expectancy, social influence,

and facilitating conditions influence acceptance and adoption of processes and procedures. The

same statement was also used to correlate with the other three potential determinant areas, which

are attitude, self-efficacy, and anxiety. A similar approach was used in the original study by

Venkatesh et al. (2003).

The four contexts. Initial evaluation of the four contexts (enterprise, IT-wide, job-

specific, and client processes) suggests that processes and procedures are generally more agreed

to be important and compatible in the contexts of IT-wide and job-specific processes and

procedures. This is less so for enterprise processes, and even less for client processes. While this

survey did not attempt to understand why this might be the case, it does nevertheless demonstrate

that agreement is weaker in the context of enterprise processes, and nearly neutral in the context

of client processes. A correlation study, then, of a variety of moderators will provide value in

determining whether there are relationships influencing acceptance of process.

Correlation analysis. The research question is to ascertain the determinants of software

acceptance and adoption by IT software project practitioners. In order to judge acceptance, the

109

test of behavioral intent was used. While three of the questions at the end of the survey focused

on intent, one question specifically stated ―I intend to use processes or procedures in the next

three months.‖ This particular question was correlated with the 28 questions not specifically

related to Behavioral Intent. Results of this correlation analysis indicate that of the seven

potential determinants, only Anxiety was found not to have any significant correlations with

intent. Significance differed, however, on the context being studied (Table 9). Specific

significance values are also charted in Appendix D.

Table 9.

Significance of Potential Determinants

Context

Potential Determinant Enterprise IT-wide Job-specific Client

Performance Expectancy X

Effort Expectancy X X

Attitude X X X X

Social Influence X X X X

Facilitating Conditions X X X X

Self-efficacy X X X

Anxiety

Performance Expectancy. Judging IT professionals’ thoughts about performance

expectancy was accomplished by asking agreement with usefulness, accomplishing tasks

quickly, increasing productivity, or increasing the chances of getting a raise. While respondents

generally felt that processes and procedures would be helpful when performing their work, intent

was demonstrated to be significant only for client-specific processes and procedures.

Additionally, while fewer people agreed that their clients’ processes and procedures would help

them perform better, this is the only area that demonstrated significance of positive intent to use

110

processes and procedures. The two questions that were found to be significantly related to intent

were ―I would find processes or procedures useful in my job,‖ and ―Using processes or

procedures enables me to accomplish tasks more quickly.‖ Correlation analysis did not find a

significant relationship between intent and an increase in productivity, as a result of processes

and procedures, in any of the four contexts.

Additional correlation analysis was conducted for the same questions, with the

moderators of age, gender, experience, education, organization, and title. None of these was

found to be significant factors in the intent to use processes and procedures.

Hypothesis 1 stated: ―Processes and procedures are more likely to be accepted and

adopted if they are perceived to increase one’s effectiveness on the job.‖ Given the lack of

significant correlations between intent and the related questions, this hypothesis does not appear

to be supported, except perhaps in the context of client processes and procedures.

Effort Expectancy. The intent of the statements about effort expectancy was to measure

agreement with the idea that processes are clear and understandable, whether it would be easy to

become skillful at using them, whether they are easy to use or easy to learn. Respondents

generally agreed with the statements proposing that processes and procedures are relatively easy

to learn and to use. While the mean scores tended to indicate agreement, the significance of

intent was only significant in the contexts of job-specific procedures and client processes.

Only two statements from this potential determinant were found to be significant. The

statement ―It would be easy for me to become skillful at using processes or procedures‖ was

significant for behavioral intent in the contexts of both client processes and job-specific

procedures with no moderators. The correlation with behavioral intent was significant for the

111

second statement, ―My use of processes or procedures is clear and understandable,‖ in only the

context of client-specific processes, with the additional moderators of age and experience.

Regression analysis can be a useful tool to measure how two data points link to, or relate

to one another (Dizikes, 2012). Using this tool, it appears that there is a correlation between both

age and the statement (―My use of processes or procedures is clear and understandable‖), as well

as experience and the same statement, in the context of job-specific procedures. The value of p =

.050 for the correlation between age and the statement demonstrates that age is significant, and

the value of p = .029 for the correlation between experience and the statement demonstrates

significance for experience. Further correlation analysis, split by age and experience,

demonstrates that age is significant for job-specific procedures in the age ranges of 30–39 and

50–59. The same question is significant only for those with experience from 11–15 years, and

from 20–30 years. There is no similar relationship between behavioral intent alone and the two

moderators, however. From this it appears that experience and age (to a somewhat lesser extent)

are significant moderators, in the context of job-specific procedures, for clearly and

understandably using procedures. This is not the case for enterprise-wide, IT-wide, or client-

specific processes.

Hypothesis 2 states ―Processes and procedures are more likely to be accepted and

adopted if they are perceived to be easy to use.‖ Given the significance of intent with effort

expectancy being positive for being easy to become skillful, as well as processes being clear and

understandable, this hypothesis cannot be rejected, especially in the context of client-related

processes.

Attitude toward using processes. The concept of attitude in using processes measures

how IT professionals experience processes in context—whether they feel it is a good idea to use

112

them, whether they make the job more interesting, whether they believe the processes are fun, or

whether they even like using them. While most respondents felt that using processes is a good

idea, few felt that they made the work more interesting or fun. Given those responses, it is

interesting to note that more respondents like using processes or procedures than those who did

not, in every context.

These attitudes, however, are not necessarily correlated with intent to use processes or

procedures. The first statement, ―Using processes or procedures is a good idea,‖ was found to be

significant in all contexts except for those that are designed to be used IT-wide. None of the

moderators was significant for this statement. Why there is no significant relationship between

intent and attitude about IT-wide processes cannot be answered from the data gathered.

While few felt that processes and procedures make work more interesting or fun, it is

interesting to note that respondents still indicated that they liked using them. The responses were

found to be significant in all contexts, meaning that there is a relationship between liking

processes and the intent to use them. In this case the relationship appears to be positive.

Significant moderators were found only in the last statement, indicating whether the respondent

liked using processes or procedures. In the context of processes that are IT-wide, both experience

and education were found to be significant moderators. For job-specific procedures, only

experience was found to be a significant moderator. Regression analysis did not find a significant

relationship between the statement and either education or experience alone.

In the Theory of Planned Behavior (TPB), attitude is used as an indicator of adoption of a

concept (Venkatesh et al., 2003). In this study, therefore, the correlation of attitude with intent

was used to demonstrate process adoption. In three of the four contexts (all but IT-wide

processes), attitude is significantly correlated with intent, demonstrated by the question ―Using

113

processes or procedures is a good idea.‖ This answers the research question, demonstrating that

attitude is a determinant of process adoption. While not a hypothesis for the study, it is still a

significant finding, based on the literature supporting the Theory of Planned Behavior.

There was no specific hypothesis regarding attitude as a potential determinant of

acceptance or adoption of processes. However, given that significant relationships were found

with intent to use processes, as well as attitude toward processes and procedures, it is

hypothesized that attitude is determinant of acceptance, or intent to use, processes or procedures.

Social influence. For social influence to be a determinant, four areas were suggested as

potential influencers of behavior and intent: people who influence respondents’ behavior, people

who are important to the respondents, senior management’s support, as well as organizational

support. Respondents generally agreed that each of these four areas of influence were important,

with the possible exception of senior management being less influential. Mean scores of the

responses indicated general agreement, but were more neutral about senior management’s

influence in all contexts except client processes.

As potential determinants of behavior, all were found to be significant in the context of

client processes. For the other three contexts, all statements were found to be significant with the

exception of senior management’s influence on intent. In general, this would indicate that the

null hypothesis is not supported, that social influence is significant in the intent to use processes

in the four contexts. It is interesting to note, however, that the median responses for all four

questions was ―4,‖ meaning agreement with the statement, except for the statement regarding

senior management’s support. For that statement, the median responses were ―3,‖ indicating a

neutral opinion about whether senior management’s helpfulness is a factor in accepting processes

and procedures.

114

Both education and experience appeared to be moderators in the case of job-specific

procedures. Running a bivariate correlation of these two revealed that education is a significant

moderator where people that influence respondents’ behavior in the context of job-specific

procedures. Experience alone, however, was not found to be significant.

Hypothesis 3 stated Processes and procedures are more likely to be accepted and

adopted if social influence is strong. From these correlations, it would appear that the null

hypothesis cannot be rejected, and that social influence does influence intent to follow processes

and procedures, with the possible exception of senior management’s influence. This did not

appear to be a significant factor in acceptance.

Facilitating conditions. When asked about conditions for using processes, four

statements were given. The first two stated that resources were available, and that each

respondent had the knowledge necessary to use processes and procedures. The third statement

proposed that the processes and procedures are compatible with the work that the respondent

does. The fourth statement proposed that there was help available for questions should they arise

when using processes and procedures.

A brief glance at the means and medians of the responses indicate that facilitating

conditions are generally positive. Most indicated agreement with all statements except the third

one, about which respondents were neutral. This would generally indicate that the processes and

procedures currently in place are not necessarily, or not always, compatible with the way they

perform their jobs. This was especially true in the context of client processes.

Significance of intent with these responses was again analyzed by correlating each

statement with the corresponding statement on intent. In the first two statements indicating

whether the respondents had the necessary resources and knowledge, intent was found to be

115

significant in all four contexts. The significance of intent was also significant when processes are

judged to be compatible with current practices, in all contexts except IT-wide processes and

procedures. Even though respondents were neutral about whether the processes are compatible,

the data does not show support that intent to use them was significant in that context. Finally,

only in the context of client processes was there significance of intent if someone who

understands the processes is available for questions. In general, moderators of age, experience, or

education were not found to be significant.

Hypothesis 4 states: Processes and procedures are more likely to be accepted and

adopted if facilitating conditions exist, making it easier to implement the processes. The null

hypothesis cannot be rejected in this case, because the data showed that intent to use processes

was significant when respondents had resources and knowledge to use them. This was less clear

when judging whether intent was affected when the processes are compatible with their current

work practices or whether there was someone available for assistance.

Self-efficacy. Statements about one’s self-efficacy, or resourcefulness in following

processes at one’s own direction, were not found to be significant in the original study on

technology acceptance. In the context of processes, however, there is some support for self-

efficacy being a factor in intent to use processes.

Compared with responses to some of the other potential determinant areas, respondents

felt fairly positive about their ability to use processes and procedures, even if there were no one

to help them figure out what to do, or when someone is available to call for help. They also felt

relatively positive (between ―3‖ or neutral and ―4‖ or agree) if there were plenty of time to

accomplish what was required by the processes, or if there were job aids available to go to for

reference. Their relationship to intent, however, was significant for all but IT-wide processes if

116

there were no one to tell them what to do, step by step. One cannot assume, however, that this

means that respondents need help, step by step, in IT-wide processes. It means that not having

this available for IT-wide processes is not a significant factor in intent. Having or not having it

available, however, might be significant in the other three contexts of enterprise-wide, job-

specific, or client processes.

Intent to follow processes, if someone was available to call for help when encountering a

problem, was only significant in the contexts of job-specific and client processes. The data did

not support significance of intent in the contexts of enterprise or IT-wide processes. This does

not indicate lack of intent, only that the significance of having someone available to call is not

significant for enterprise and IT-wide processes.

Surprisingly, having a lot of time to complete a process was not found to be a significant

predictor of intent, except in the context of client processes. While it is tempting to guess some

reasons for this, there is no support for that within the statements themselves.

The last statement in the potential determinant area of self-efficacy is whether having job

aids available would be a significant factor influencing intent. Having a job aid is not significant

for enterprise-wide or IT-wide processes, but is significant for both job-specific and client

processes. Since job aids are generally only written for hands-on, step-by-step procedures, this

makes sense. There would be no reason to have job aids available for higher-level processes at

either the enterprise level or IT level, since these are more general in nature.

There is no hypothesis that self-efficacy would be a significant determinant of intent to

follow process. However, there is evidence from this study that, at least in the context of IT

software project professionals, self-efficacy could be a determinant of following processes and

procedures, especially in the context of job-specific and client processes and procedures.

117

Anxiety. The last potential determinant, anxiety, proposed that apprehension, fear,

making mistakes, or being intimidated would have a negative impact on intent to use processes

and procedures. The respondents, however, disagreed with, or were neutral about, the statements

in all four contexts. The mean and median responses were all in the range of a response of ―2,‖

or disagreement, with the statement. None of the statements were found to correlate with

behavioral intent. This indicates that anxiety is not a significant factor; none of the statements

was found to be significant in judging intent

Summary of findings. The intent of this research was to ascertain what some of the

determinants might be for accepting and adopting processes and procedures within IT

professionals. Specifically, the audience of software development project practitioners was

selected, because the nature of processes and procedures for these professionals differs from

those in other functional areas of IT. For example, processes and procedures followed by an

Infrastructure function within IT are more likely to be straightforward, where the products and

services are more standardized products such as Windows Servers and network components.

However, processes and procedures that might be required to run an IT software development

project are more likely to be derived from a variety of standards, such as the Project

Management Institute, or Carnegie’s Capability Maturity Model.

It was hypothesized that, like the Unified Theory of the Use and Acceptance of

Technology, processes might be accepted using the same determinants as those in the original

study by Venkatesh et al. (2003). The original study included the following potential

determinants:

 Performance Expectancy

 Effort Expectancy

118

 Attitude

 Social Influence

 Facilitating Conditions

 Self-efficacy

 Anxiety

 Behavioral Intent

Of those, only performance expectancy, effort expectancy, social influence, and

facilitating conditions were found to be significant in the context of technology.

In this study, however, the results indicate that the following are actually significant:

 Performance Expectancy

 Effort Expectancy

 Attitude

 Social Influence

 Facilitating Conditions

 Self-efficacy

Only anxiety was found not to be a significant predictor or determinant of acceptance of

process.

There are differences in the four contexts as seen in Table 9. In the context of enterprise

processes, In the context of enterprise-wide processes, 36% of the responses were significantly

related to intent. For IT-wide processes, only 21% of the responses were significantly related to

intent. Job-specific procedures were significantly related to acceptance in 46% of the cases, and

client processes were significantly related to acceptance in 68% of the cases. The findings for

119

these context areas are somewhat surprising, given the level of understanding that was evident in

the verbatim responses at the end of the survey.

Verbatim responses. Three open-ended questions were asked each respondent at the

end of the survey:

 How do you believe that IT processes and procedures affect the way you support

IT software projects?

 What is your role in understanding the way your clients do business?

 If you could express one important thing to your management about how

processes and procedures are managed within IT, what would that be?

Each of the responses was coded using nVivo software, attempting to map responses as

close to the original hypotheses as possible. Coding of each question, however, found few

relationships between statements, but some common themes, organized into the following

categories:

 Attitude toward using processes

 Client processes

 Effort expectancy

 Facilitating conditions

 Performance expectancy

 Social influence

Some of these categories had more input than others. Suggestions given by respondents

from the last open-ended question (―If you could express one important thing to your

management about how processes and procedures are managed within IT, what would that be?)

resulted in many different suggestions that were simply compiled in a list. Some were related to

120

processes, and some were not. The responses that were related to attitude were coded as such

(Figure ).

Figure 4. Responses coded as attitude

These responses suggest that while some believe processes are done well, some feel that

in their current state, they are frustrating confusing, inefficient, and redundant (―Too many

process and procedures. Too confusing‖; ―If we had well designed, well communicated and well

supported processes, we could be more efficient in daily work and provide services to our clients

more cheaply and more quickly.‖). Still others feel that the processes are adequate, important,

and created well (―Processes are setup very effectively and I would like them to be more

reachable to every individual,‖ ―Processes are important and taken seriously‖).

The next area, client processes, was coded to record positive and negative responses

(Figure ). The responses show that differences in understanding of the role of client processes.

The most obvious role that respondents felt important was that of understanding the client’s

business (―A better understanding of [how] clients do business means a better requirement

121

gathering and analysis which results in cheaper and better code,‖ ―Unstanding [sic] how my

clients do their business is vital to producting [sic] a useful product.‖). Other important responses

indicated an understanding of gathering client business requirements, project management, and

understanding the client’s specific procedures and how they work with IT (―I need to clearly

understand and follow my cleint's [sic] business processes and procedures in order to effectively

manage their programs, which are develped [sic] due to critical business needs.‖). Still others felt

that their role was to provide suggestions to the clients for ways they could improve their work

using IT (―My role is also as an SME [subject matter expert] to help my client determine the best

way to perform his/her work‖). These were encouraging responses in the context of this study,

because they demonstrate an awareness of the importance of not only the client, but of the way

the client’s processes work in tandem with software product development.

122

Figure 5. Coding of responses related to client processes

The remainder of the responses, related to the research question, were also coded (Figure

). It was surprising to see how few respondents mentioned effort expectancy as an important

aspect of processes and procedures (―There are way to [sic] many. Not all process and

procedures are effective and tend to be cumbersome and casue [sic] delays‖). There was some

information on how facilitating conditions impacted their understanding of processes, primarily

123

around the place of processes being part of their job (―I am in IT and processes and prodedures

[sic] are an integral part of my job‖), and the thought that there were too many (―That some of

them are archaic or had good intentions but now are more busywork then [sic] useful‖). There

were also conflicting comments regarding the performance expectancy of processes, or the

expectation that processes would help them perform better. A large number felt that processes

could increase their productivity and make work go more smoothly (―It helps in a standard

procedure to follow and stick to‖); still others felt that the processes increase bureaucracy too

much, making work less efficient bueracratic [sic]‖). Finally, some mentioned that management

does not support the use of processes in the environment (―I feel that upper management, my

peer managers, and staff employees overall do not believe in the processes / procedures and

avoid following them at all costs. There is no penalty for non compliance‖).

124

Figure 6. Coding of responses relating to other determinants

Another look at the verbatim responses, organized by general job title, revealed that

analysts and developers in general felt that the lower-level procedures were useful, that they

understood the need to work with clients very closely to understand their day-to-day operations,

and that doing so would make them better IT professionals. Some of the respondents did not

answer the verbatim questions; some answered with just their job title and did not display an

125

understanding of the question. Respondents whose job title was more technical also displayed a

better understanding of how processes were important to integrate everything together not only

within IT, but also with IT’s clients. Project managers and functional managers in general felt

that their role was to manage expectations and client relationships more than it was to truly

understand the clients’ processes. Each group had specific messages to management, most of

which were negative reflections on the current state of processes with suggestions on how to

improve them. Appendix E contains a summary of the responses, first by question, then by job

title, and whether the response was negative, neutral, or positive.

An interesting aspect to these verbatim responses is that the responses appeared to be

balanced between negative, neutral, and positive comments regarding their understanding of

business processes in general. Respondents were more neutral, or matter of fact, about the role

they played in supporting client processes. Finally, most of the suggestions or comments to

management reflected a negative attitude about the current state of processes that they use. This

does not necessarily disagree with the findings of the survey, where respondents generally agreed

with the importance of processes. Rather, the comments reflect a general feeling of

dissatisfaction with (not disagreement about) the way processes are used in their work.

These verbatim responses do not represent statistically significant responses. They do,

however, provide additional information regarding the true understanding of processes and

procedures from not only IT’s viewpoint, but also from IT’s viewpoint regarding their clients.

While not everyone in every role demonstrated a rich understanding of their role, nevertheless

the responses of some did indicate that this understanding at least appears to be moving in the

right direction—toward understanding client procedures and processes.

126

This is an important distinction in this study. The original research question sought a way

to understand the determinants of not only process acceptance, which is giving mental assent to

the concept of, and need for, processes and procedures within IT software development projects.

Adoption, however, implies not only a deeper understanding, but evidence that processes have

become a way of thinking, almost a way of life, in the context of performing work. The

significance of the responses in the first section of the survey (e.g., the thirty-one questions)

indicates level of acceptance more than level of adoption. It is only through observation over

time that the level of adoption could be measured—perhaps not even using an objective survey

as the tool. More remains to be done to understand and study adoption of process.

127

CHAPTER 5. DISCUSSION, IMPLICATIONS, RECOMMENDATIONS

The intent of the study was to ascertain what factors might determine acceptance and

adoption of processes by software development project practitioners. This group was selected

specifically because the nature of processes is less straightforward than it would be for an IT

organization that fulfills orders, maintains the infrastructure, or performs more repetitive work.

The nature of software products indicates that the same processes may not always apply from

one project to another, and that the practitioners must be able to use them effectively where

ambiguity is more prevalent.

The Unified Theory of the Use and Acceptance of Technology (UTAUT) was used as a

basis for performing the study. The purpose of software development projects is to implement

not only technology, but also to enable the processes that the client needs or follows in order to

conduct business. The importance of processes, then, when technology enables their use is

important for not only the client who receives the technology, but also for the practitioners who

develop and implement the technology. Venkatesh, the primary author of the UTAUT study,

indicated that the same model had been used to study determinants of acceptance in different

contexts, and suggested that another key area to study would be the process area (Venkatesh,

2006). For accepting technology, the original study found that performance expectancy, effort

expectancy, social influence, and facilitating conditions were significant determinants. Self-

efficacy, anxiety, and attitude did not play a significant role in intent to use technology.

However, in the same article by Venkatesh et al., attitude had been seen as a determinant of

process adoption in a different acceptance model, the Theory of Planned Behavior (TPB)

(Venkatesh et al., 2003).

128

This study found that there were differences between accepting technology and accepting

processes. It is also important to note that the respondents were selected from only one company.

It was felt that this company’s software development organization would be similar to other large

companies’ development organizations. The addition of open-ended questions at the end of the

survey also added depth and understanding for this specific group.

This group may differ, however, from similar large organizations because of the

economic conditions that were present when the survey was conducted. Even though the

company had seldom withheld raises in the past, employees had recently been warned that for

most people, raises would not be given for the current year. There was one question on the

survey that asked for level of agreement that following processes would make it more likely to

receive a raise. This question, then, is invalid for this company and was not included in the

analysis. One other factor that should be mentioned is that the study was conducted within two

months of a local workplace shooting within IT, in the same building where some of the

respondents work. The shooter and his victims were indirect participants in software

development projects; they were in the Infrastructure group that does not charge time directly to

projects. However, the attitude of the respondents may have been affected somewhat by the

shock and aftermath of losing three coworkers as a result of workplace violence.

Within these constraints, then, the results of the study are presented here to discuss how

the level of intent to use processes might be significantly influenced by seven potential

determinants.

Performance Expectancy

The respondents felt strongly that using processes is a good idea, indicating a high degree

of process acceptance. Processes that apply to all of IT, as well as job-specific procedures, were

129

seen as the most valuable, while enterprise-wide and client-specific processes were seen as

somewhat less valuable. None of the statements about processes increasing productivity,

however, were influenced by intent to actually use the processes. Performance expectancy is not

significantly related to intent to use processes in this study, with the possible exception of client-

related processes. This is also supported by the verbatim comments about the specific processes

being used at the company. While some rated the processes as well done (e.g., one respondent

classified them as ―world class‖), most of the analysts and developers tended to rate their current

processes as difficult to use, complicated, not well integrated, and overdone. In concept, then,

the respondents tend to agree that processes are important, that they do contribute to performing

work better and more efficiently. However, they find that the processes that they currently use do

not provide the benefit that they could. This is most likely one of the strongest factors for not

finding a significant relationship between intent to use processes and the benefit that they

provide, thereby not supporting Hypothesis 1.

Of the four contexts in the study, client processes are the only ones that are not mandated.

Analysts, developers, and project managers, however, use client processes in order to better meet

their clients’ needs, to understand the work that systems support, and to produce systems that

work in context. Therefore, while following these processes is not mandated, it is important to

note that these professionals choose to use client processes in order to perform more effectively.

This indicates that client processes are being used voluntarily, and that client processes support

IT’s work. In this case, IT professionals demonstrate an attitude of adoption of processes.

Several of the verbatim responses on the survey indicated that the processes they use are

frustrating, inadequate, and not well thought-out. They do not provide the value that the

professionals expect. Some suggested that the processes need to be reworked with input from

130

those who perform the tasks, not designed by consultants or people that are not involved in

actually doing the work. This has significant implications not only for this company, but for

process management in general. Companies that hire consultants, or that use in-house process

development experts, are more likely to miss the mark when creating processes. Without getting

input, as well as hands-on testing of processes and procedures developed from the actual users,

these professionally developed processes are less likely to provide the business value that they

should. This requires more than traditional Organizational Change Management; it requires

organizational involvement with those who are the intended users of the processes. This is

supported in the literature by Markus (Markus, 2004), who introduced the concept of

―technochange‖—the synthesis of project management and organizational change management,

to provide context-specific work enablement with processes.

This study did not go beyond looking at moderators such as age, experience, and

education to understand process acceptance and adoption. Further study, incorporating level of

user involvement in creating process, would add tremendous value in understanding how

processes and performance expectancy are related, especially in the context of technochange.

Effort Expectancy

Effort expectancy scores show that the respondents do feel that the processes can help

make work easier in all contexts except job-specific procedures. Both age and experience affect

responses in this context. The verbatim responses, however, appear to contradict the survey

scores. Some responses indicate that the current processes are too complex, slow work down,

and do not add to getting work done more easily. These responses appeared to apply primarily to

IT-wide and job-specific processes, since none mentioned enterprise-wide or client-level

processes unless the question asked specifically about their role with client processes. Some

131

suggested improvements, especially in cross-organizational processes, to make them easier to

follow. Respondents differed, however, in whether the processes should be the same across the

board, or customized for each organization. A balance of this is needed. Since Hypothesis 2

cannot be rejected, it is likely that effort expectancy is a determinant of process acceptance.

It also appears from the verbatim responses that more people feel that their current

processes are cumbersome and difficult to use, especially if their job titles indicate that they

follow the processes hands-on (e.g., analysts and developers). Managers, and in some cases,

project managers, feel that the processes are useful tools for ensuring compliance and

communicating with their clients. Most are neutral in stating the processes’ effectiveness with

clients, however.

For this group of people, the specific processes they have are not easy to use. One

respondent called the processes ―onerous,‖ while others said they were confusing and overdone.

These are characteristics of the specific processes the way they are written, not of processes in

general. Here it appears that the processes are more difficult than they need to be. One answer

would be to simplify them. Perhaps a better answer would be that the processes themselves have

become the goal of process designers, not a tool in providing business value (e.g., a software

product) that the client has asked for. Instead of designing processes to support clients’ needs,

the processes have been made to be complicated and piecemeal, in response to the many

different stakeholders who want to have influence in how processes are followed.

This has two implications. The first is that the processes in this situation should be

refocused on delivering software products to clients, not for delivering processes that different IT

groups want to follow. The second implication is that further study is needed to determine the

level of processes that would be appropriate for ease of use, but also for delivering products that

132

clients are willing to pay for. This study would contribute to processes in the context of IT and

business alignment, noted earlier by Holland & Skarke (2008).

Attitude

Significance of attitude was demonstrated primarily with the concept of following

processes in general. While the respondents did not particularly find processes interesting or fun,

respondents liked using them, and strongly agreed that following processes is a good idea. Intent

is highly correlated with the attitude that following processes is a good idea. This demonstrates

that there is also evidence of process adoption, beyond mere acceptance, as posited by the

Theory of Planned Behavior (Venkatesh et al., 2003). Some of the verbatim responses support

this, saying that following processes gave them a sense of continuity across tasks and when

working with different workgroups.

The dissatisfaction demonstrated by the verbatim responses indicate that processes have

indeed become more important to respondents than mere acceptance. A few respondents

indicated that processes were very important for performing their work (―…I would like them to

be more reachable to every individual‖; ―They affect everything I do since I’m constantly

working on projects‖). Some comments expressing dissatisfaction are not about processes

themselves, but about the quality of the processes in place (―It benefits in that we have standard

procedure to follow that have a backround [sic] in success. But it does hinder projects on

occasion [sic].‖; ―Too much processes and procedures slow down the progress and tend to make

the setup too bueracratic [sic]. Too little processes and procedures lose control of the direction of

the progress‖). The verbatim responses also show that the respondents believe that it is someone

else’s responsibility to create and modify processes and procedures. Some want to have input

into what the processes and procedures should be, also indicating adoption, or a willingness to

133

continuously improve, the processes that affect their work. Continuous improvement is a key

goal in Business Process Management (BPM), evidenced by not only the literature on the goals

of BPM, but also in the variety of models that implement BPM practices such as Carnegie

Mellon’s Capability Maturity Model (―CMM process,‖ 2005).

Perhaps the most interesting of the potential determinants, attitude has been demonstrated

to be a significant factor in determining adoption of process. The actual state of the processes at

the organization being surveyed may indicate that there is more than mere acceptance of

processes. The attitudes demonstrated by the respondents indicate that processes are an integral

part of their jobs, providing structure for the way work is done. This could be partly due to the

nature of IT work – much of it depends on process in order to get work from one function to

another. But it could also be a characteristic of IT professionals in general. Further study relating

the characteristics of IT professionals (such as personality characteristics, cognitive behaviors,

etc.) with acceptance and adoption of process would contribute to managing processes more

effectively within IT, adding to the work done by Glen (2003).

Social Influence

A brief glance at the significance of responses reveals that social influence is very likely

to be a significant determinant of acceptance of process. The strongest influence from a social

perspective appeared to be from their own organizations, or people who directly influence their

behavior. Respondents were neutral about the influence of senior management, indicating that

immediate managers are more influential in the use of processes and procedures. Some of the

verbatim responses indicated that senior management does not support processes, yet processes

are an integral part of their jobs. Some of the comments about senior management were:

―Current processes and procedures make it easy to support software projects by keeping

134

everything consistent, across all projects. However, some management think that we are process-

heavy and would prefer to accomplish the goals with less process‖; ―I feel that upper

management, my peer managers, and staff employees overall do not believe in the processes /

procedures and avoid following them at all costs‖: and finally, ―Walk the talk and always mean

what we say by showing support. Often, I see that management sends mixed messages when

challenged by employee pushback.‖

In the context of software development projects, the processes and procedures really are

longer and more complex than those that would be required for fulfilling IT orders, setting up a

server, or performing more repetitive work. The nature of software development, as well as the

long duration of software projects, necessitates using processes for a longer time. There are more

opportunities to insert process for projects that may not have a tight deadline. Management, like

everyone else who is responsible for the delivery of excellent software products, could initially

support processes (because it’s such a good idea), but then opt for bypassing process when the

realities of project deadlines and client satisfaction push them to get the work done quicker,

faster, and cheaper. Conflicting goals (excellent software products that follow process versus

delivering the software quickly and inexpensively) are perhaps not balanced well or

communicated to stakeholders (analysts, developers, technical experts, project managers,

managers, and clients). Each stakeholder has a stake in the outcome, but perhaps not the same

stake.

Implications for this are significant. Respondents often felt that senior management did

not support processes. They also did not feel that a mandate by senior management would have

influence on their following processes. This is supported by Riemenschneider et al. (2002) in

their study on acceptance of development methodologies. However, influence from those closer

135

to the work (immediate managers and supervisors) did have a significant effect on their intent to

follow process. Even there, managers are inconsistent in how well they support process. Rather,

getting the work done on time is more important; the process is the first thing to lose focus and

importance when an issue arises that affects a project’s scope, schedule, or budget. It is more

important to measure up to client and manager expectations on a project than it is to follow

process. This is actually the right thing to do, indicating that processes really do get in the way of

delivering the final product. But it also indicates that management does not present a unified

message about processes. The problem, however, is not all with the managers. Rather, the

processes themselves are also at fault in this situation; they are inadequate. The processes do not

―fit‖ the needs of the organization (Pantazi & Georgopoulos, 2006).

Further study is merited for management support of processes, as well as how well IT

software project management processes ―fit‖ the business situation, rather than conforming to

industry standards that might not support business needs and goals.

Facilitating Conditions

Respondents generally agreed in the survey that they had the knowledge and resources to

follow processes and procedures. Even though some complained of being rushed to complete

work according to process, the survey responses indicated that having a lot of time would not be

a significant factor in using processes. Verbatim responses did not disagree with the survey

responses, indicating that the conditions around following processes (e.g., resources, knowledge,

tools, and compatibility) are not absent in context. Perhaps the aspect of having enough time is

more a function of how the processes are specifically designed, rather than a condition that

pervades the work that is done. In this context, then, the survey found that facilitating conditions

are significant; verbatim responses did not indicate that these conditions are not present.

136

Facilitating conditions could be improved. Respondents indicated that ongoing training is

not provided. It is also not provided for contingent workers, who are often project managers and

key analysts on projects. While it is against company procurement policies to train contingent

workers on company time, the company still has not provided any web-based or CBT training as

a means for contingent workers to train themselves, or for employees to refresh their training.

Processes are also not easy to find. There is no single place for everyone to find all the

processes that would be required to complete a software development project. This is partly

because different workgroups have responsibility for process components. It is also because

there are no central guidelines on what should be included in a process document, where it

should be located on the company’s portal, or where version control is managed. There are too

many owners with different stakes (often political) in how work is accomplished. Because of

this, processes should be centrally controlled and managed for software development projects.

Also, process documentation standards should be developed and managed, so that each process

has predictable content. These are basic principles for managing business processes that are not

being followed at this company (Harmon, 2005).

Self-efficacy

The survey results indicate that respondents felt very good about their ability to perform

processes in all contexts. This is not inconsistent with the verbatim responses that indicated

different levels of frustration with the current state of processes in their work. Rather, the

verbatim responses indicated that these professionals felt that the processes themselves were

inadequate, not their ability to follow them. This is a very positive finding in this context. Self-

efficacy, when it comes to process, does appear to influence intent to follow processes. This was

not true in the original study on determinants to accept technology. This audience is comprised

137

of IT professionals who in general have a number of years of experience. It is apparent that they

felt that they had the knowledge and resources necessary to perform processes. One implication

is that given well-designed, thoughtfully written processes and procedures, this team of

professionals has the personal resources necessary to follow them. The management of this

company does have the ―raw material‖ required in these employees to make process adoption

possible.

This specific study group demonstrated a higher level of self-efficacy than was

experienced in the original UTAUT study. This is likely because the respondents were all from

the IT organization, where processes are an integral part of doing their jobs. It could also mean,

however, that because these practitioners are accustomed to following process, they are also the

best resources for developing processes that work. Many of the respondents appeared to be eager

to be involved in developing processes that work for them. Some implied that they were never

consulted when processes were developed. This is perhaps one of the most significant

implications for practice for the entire study—that processes should be developed with in-depth

involvement by those who will be using them. Developing process should be more like

developing software, with user acceptance testing (hands-on users ensuring that the processes

work for them); system testing (ensuring that the processes work as a whole); and end-to-end

testing (involving all workgroups who are touched by process). This is a deeper level of

involvement than what is normally found in organizational change management efforts, and

would also result in adoption of the processes. Those who would use them would actually be key

participants in developing them. Because this group of people demonstrates a high level of self-

efficacy or self confidence in their ability to follow process, they are prime candidates to

participate in their development.

138

Additional work with this in mind would contribute to the practice of process

management, especially with the lens of organizational change management. This is what

Markus (Markus, 2004) calls ―technochange.‖ IT becomes the agent for change (Markus &

Benjamin, 1996), as well as a major participant in the development of change. More should be

contributed to the literature to explore this relationship between IT professionals and process

development.

Anxiety

The results of both the survey and the verbatim responses indicate that these employees

experience very little anxiety from having to follow processes and procedures. This could mean

that the organization has done a good job of incorporating process into its culture, and the way

work is done. It could also mean that the training of these professionals included process

training, providing a background for acceptance.

The results of the survey do agree with the original survey on technology (Venkatesh et

al., 2003). Anxiety does not appear to be a significant determinant of accepting processes and

procedures.

Because there is a general lack of anxiety about following processes, this also supports

the argument that this group of IT professionals should participate in process development and

management. It should not be left up to only professional process developers or management.

Summary of Determinants

Performance expectancy does not appear to influence intent to use processes. Hypothesis

1 is not supported.

139

Effort expectancy does influence intent to use processes, but only in the contexts of job-

specific and client processes. Both of these contexts are very important for practice; therefore,

Hypothesis 2 is supported.

Attitude was not hypothesized to be a determinant of process acceptance, as it was not

found to be significant in acceptance of technology. It is significant, however, in studies on the

Theory of Planned Behavior, indicating that attitude contributes to adoption. Therefore, attitude

is a determinant of process adoption.

Social influence is also a determinant for intent to follow process, in all four contexts.

Hypothesis 3 is therefore supported.

It was also expected that facilitating conditions would influence the intent to follow

processes. This is, in fact, true for this study. Hypothesis 4 is supported.

Perhaps because the audience is IT, self-efficacy is also supported as a determinant of

intent to follow processes, in all but IT-wide contexts.

Finally, anxiety was not expected to be a determinant of process acceptance. This is in

fact true.

In summary, the following are found to be determinants of process acceptance and

adoption: effort expectancy, attitude, social influence, facilitating conditions, and self-efficacy.

Only performance expectancy and anxiety were not found to be significant factors for modifying

intent to use processes.

Conclusions

The survey method used provided a good framework for study of process acceptance and

adoption. It was conducted in one organization, among software development project

practitioners, but limited to those who specifically charged time to projects within a specific time

140

period. Additional responses from those who support projects indirectly may lead to different

responses regarding the usefulness of job-specific procedures. The addition of the verbatim

questions at the end of the survey provided additional insight to the responses that were not

present in the original study, adding not only depth to the responses, but also site-specific

suggestions for improvement.

The suggestion that seemed to be repeated the most for this specific company was to

refine the existing processes to make them easier to follow, consistent, and redesigned from end-

to-end so that they would be applicable to everyone in the software development process. The

practitioners are not only willing to follow processes and procedures, but they have the self-

efficacy to believe that they can perform.

Circling back to the original scope of the study, the contexts of business process

management, IT process management, and organizational change management were initially

proposed as the framework for understanding the importance of process development and

management. Verbatim responses also appear to support the need for process management, from

a business standpoint (enterprise-wide and client processes), from IT’s viewpoint (IT-wide and

job-specific processes), and from an organizational change management perspective (processes

need to be relevant and well thought-out for the specific jobs being performed).

This particular organization has some specific issues with out-of-date, cumbersome

processes and procedures. The employees do not feel that they have the support of senior

management, and that management is inconsistent in its use of and support for processes.

However, this company also has the advantage of having employees who have not only accepted

process management as a valuable tool, but who also believe that they have the resources and

141

skills within themselves to be able to follow processes and procedures. They have also

demonstrated adoption of processes by the significant correlation of intent with attitude.

142

References

Accounting developments 2009. (2010). Business Lawyer, 65(3), 909-922.

Agarwal, R., & Prasad, J. (1998). A conceptual and operational definition of personal

innovativeness in the domain of information technology. Information Systems Research,

9(2), 204-215.

Al-Mashari, M. (2002). Business process management—major challenges. Business Process

Management Journal, 8(5), 411.

Al-Mashari, M. (2003). A process change-oriented model for ERP application. International

Journal of Human-Computer Interaction, 16(1), 39-54.

Allen, B. (2003). Transforming IT. Optimize, 20.

Arveson, P. (1998). The Deming Cycle Retrieved November 11, 2010, from

http://www.balancedscorecard.org/TheDemingCycle/tabid/112/Default.aspx

Attaran, M. (2003). Information technology and business-process redesign. Business Process

Management Journal, 9(4), 440.

Attaran, M. (2004). Exploring the relationship between information technology and business

process reengineering. Information & Management, 41, 585-596.

Bandura, A. (1994). Self efficacy. In V. S. Ramachaudran (Ed.), Encyclopedia of human

behavior (Vol. 4, pp. 71-81). New York: Academic Press. (Reprinted from: H. Friedman

[Ed.], Encyclopedia of mental health. San Diego: Academic Press, 1998).

Basu, V., & Lederer, A. L. (2004). An agency theory model of ERP implementation. Paper

presented at the Proceedings of the 2004 SIGMIS conference on Computer personnel

research: Careers, culture, and ethics in a networked environment, Tucson, AZ, USA.

http://www.balancedscorecard.org/TheDemingCycle/tabid/112/Default.aspx

143

Benner, M. J., & Tushman, M. L. (2003). Exploitation, exploration, and process management:

the productivity dilemma revisited. Academy of Management Review, 28(2), 238-256.

Bernstein, C. (2009). The alphabet soup of process frameworks. Baseline(99), 10-10.

Besson, P., & Rowe, F. (2001). ERP project dynamics and enacted dialogue: perceived

understanding, perceived leeway, and the nature of task-related conflicts. SIGMIS

Database, 32(4), 47-66.

Best, K. (2011). International standards activities Retrieved June 22, 2011, from

http://www.pmi.org/PMBOK-Guide-and-Standards/Standards-International-Standards-

Activities.aspx

Caldeira, M., & Dhillon, G. (2010). Are we really competent? Business Process Management

Journal, 16(1), 5.

Capability maturity model for software (SW-CMM). (n.d.) Retrieved December 11, 2003, from

http://www.teraquest.com/SW-CMM/static/Model_MainPage.html

Cascio, W. F. (2002). Strategies for responsible restructuring. Academy of Management

Executive, 16(3), 80-91.

Chapman, J. R. (2004). Software Development Methodology Retrieved October 31, 2005, from

http://www.hyperthot.com/pm_sdm.htm

CMM process. (2005) Retrieved March 19, 2005, from

http://www.askprocess.com/Products/CMM.html

Davenport, T. H. (2005). The coming commoditization of processes. Harvard Business Review,

83(6), 100-108.

Davenport, T. H., & Beers, M. C. (1995). Managing information about processes. Journal of

Management Information Systems, 12(1), 57-80.

http://www.pmi.org/PMBOK-Guide-and-Standards/Standards-International-Standards-Activities.aspx

http://www.teraquest.com/SW-CMM/static/Model_MainPage.html

http://www.hyperthot.com/pm_sdm.htm

http://www.askprocess.com/Products/CMM.html

144

Debreceny, R., & Gray, G. L. (2009). IT governance and process maturity: a research study.

COBIT Focus, 2009(2), 14-16.

Dizikes, P. (2012, March 16). Explained: Regression analysis Retrieved April 10, 2012, from

http://web.mit.edu/newsoffice/2010/explained-reg-analysis-0316.html

Du, S. M., Johnson, R. D., & Keil, M. (2004). Project Management Courses in IS Graduate

Programs: What is Being Taught? Journal of Information Systems Education, 15(2), 182-

188.

Eardley, A., Shah, H., & Radman, A. (2008). A model for improving the role of IT in BPR.

Business Process Management Journal, 14(5), 629.

Eckhardt, A., Laumer, S., & Weitzel, T. (2009). Who influences whom? Analyzing workplace

referents’ social influence on IT adoption and non-adoption. Journal of Information

Technology, 24(1), 11.

Elzinga, J., Horak, T., Lee, C.-Y., & Bruner, C. (1995). Business process management: survey

and methodology. IEEE Transactions on Engineering Management, 42(2), 119.

Ewusi-Mensah, K. (1997). Critical issues in abandoned information systems development

projects. Communications of the ACM, 40(9), 74-80.

Ewusi-Mensah, K., & Przasnyski, Z. H. (1995). Learning from abandoned information systems

development projects. Journal of Information Technology, 10(1), 3-14.

Feurer, R., Chaharbaghi, K., Weber, M., & Wargin, J. (2000). Aligning strategies, processes, and

IT: a case study. Information Systems Management, 17(1), 23-35.

Fisher, S. L., & Howell, A. W. (2004). Beyond user acceptance: an examination of employee

reactions to information technology systems. Human Resource Management, 43(2 & 3),

243-258.

http://web.mit.edu/newsoffice/2010/explained-reg-analysis-0316.html

145

Foon, Y. S., & Fah, B. C. Y. (2011). Internet banking adoption in Kuala Lumpur: an application

of UTAUT model. International Journal of Business & Management, 6(4), 161-167. doi:

10.5539/ijbm.v6n4p161

Garbani, J.-P. (2005). Building blocks of process and innovation. Optimize, 4(11), 93.

Gillies, A., & Howard, J. (2003). Managing change in process and people: combining a maturity

model with a competency-based approach. Total Quality Management & Business

Excellence, 14(7), 779. doi: 10.1080/1478336032000090996

Glen, P. (2003). Leading Geeks: How to manage and lead people who deliver technology. San

Francisco: Jossey-Bass.

Gomolski, B. (2004). It’s time to re-engineer IT. Computerworld, 38(16), 30.

Gosain, S. (2004). Enterprise information systems as objects and carriers of institutional forces:

the new iron cage? Journal of the Association for Information Systems, 5(4), 151-182.

Hällgren, M., & Maaninen-Olsson, E. (2005). Deviations, ambiguity and uncertainty in a project-

intensive organization. Project Management Journal, 36(3), 17.

Hammer, M. (2002). Process management and the future of six sigma. MIT Sloan Management

Review, 43(2), 26-32.

Hammer, M., & Champy, J. A. (1993a). Reengineering the Corporation: A Manifesto for

Business Revolution (1st ed.). New York: Harpercollins.

Hammer, M., & Champy, J. A. (1993b). Reengineering work processes Classics of

Organizational Behavior (Third ed., pp. 399-411). Prospect Heights: Waveland Press,

Inc.

Hardgrave, B. C., & Armstrong, D. J. (2005). Software process improvement: it’s a journey, not

a destination. Communications of the ACM, 48(11), 93-96.

146

Hardgrave, B. C., Davis, F. D., & Riemenschneider, C. K. (2003). Investigating determinants of

software developers’ intentions to follow methodologies. Journal of Management

Information Systems, 20(1), 123-151.

Harmon, P. (2005, February 13). The evolution of business process management. Paper

presented at the DCI Business Process Management, New Orleans.

Harmon, P. (2007). Once more: Porter on competitive advantage. BPTrends, 5, 6. Retrieved from

http://www.bptrends.com/publicationfiles/advisor20070130.pdf

Harter, D. E., Krishnan, M. S., & Slaughter, S. A. (2000). Effects of process maturity on quality,

cycle time, and effort in software product development. Management Science, 46(4),

451-466.

Hernandez, B., Jimenez, J., & Martin, M. (2008). Business acceptance of information

technology: expanding TAM using industry sector and technological compatibility.

International Journal of Enterprise Information Systems, 4(4), 62.

Holland, D., & Skarke, G. (2008). Business and IT alignment: then and now, a striking

improvement. Strategic Finance, 89(10), 42.

Hong, W., Thong, J., Chasalow, L. C., & Dhillon, G. (2011). User acceptance of agile

information systems: a model and empirical test. Journal of Management Information

Systems, 28(1), 235-272.

Houy, C., Fettke, P., & Loos, P. (2010). Empirical research in business process management—

analysis of an emerging field of research. Business Process Management Journal, 16(4),

619.

ISO IEC 90003 2004 software standard translated into plain English. (2010, January 6, 2010)

Retrieved August 9, 2010, from http://www.praxiom.com/iso-90003.htm

http://www.bptrends.com/publicationfiles/advisor20070130.pdf

http://www.praxiom.com/iso-90003.htm

147

Jasperson, J. S., Carter, P. E., & Zmud, R. W. (2005). A comprehensive conceptualization of

post-adoptive behaviors associated with information technology enabled work systems.

MIS Quarterly, 29(3), 525-557.

Keil, M., & Robey, D. (1999). Turning around troubled software projects: an exploratory study

of the deescalation of commitment to failing courses of action. Journal of Management

Information Systems, 15(4), 63-87.

Kim, Y. J., Chun, J. U., & Song, J. (2009). Investigating the role of attitude in technology

acceptance from an attitude strength perspective. International Journal of Information

Management, 29(1), 67-77. doi: DOI: 10.1016/j.ijinfomgt.2008.01.011

Ko, R. K. L., Lee, S. S. G., & Lee, E. W. (2009). Business process management (BPM)

standards: a survey. Business Process Management Journal, 15(5), 744.

Koskela, L., & Dave, B. (2008). Editorial: process and IT. Construction Innovation, 8(4), 244.

Kumar, U. D., Nowicki, D., Ramírez-Márquez, J. E., & Verma, D. (2008). On the optimal

selection of process alternatives in a six sigma implementation. International Journal of

Production Economics, 111(2), 456-467. doi: DOI: 10.1016/j.ijpe.2007.02.002

Kumari, M., Sharma, A., & Kamboj, V. (2009). Replacement of software inspection with

software testing. International Journal of Information Technology and Knowledge

Management, 2(2), 257-261.

Labate, J. (2005). And You Thought the First Year Was Bad--Just Wait. Treasury & Risk

Management, 15(4), 24-29.

Lindstrom, L., & Jeffries, R. (2004). Extreme programming and agile software development

methodologies. Information Systems Management, 21(3), 41-52.

148

Lu, J., Yu, C.-S., & Liu, C. (2009). Mobile data service demographics in urban China. Journal of

Computer Information Systems, 50(2), 117-126.

Markus, M. L. (1983). Power, politics, and MIS implementation. Communications of the ACM,

26(6), 430-444.

Markus, M. L. (2004). Technochange management: using IT to drive organizational change.

Journal of Information Technology, 19, 3-19.

Markus, M. L. (2005). Technochange management: using IT to drive organizational change.

Journal of Information Technology (Palgrave Macmillan), 20(1), 3-19.

Markus, M. L., & Benjamin, R. I. (1996). Change agentry--the next IS frontier. MIS Quarterly,

20(4), 23.

Markus, M. L., Majchrzak, A., & Gasser, L. (2002). A design theory for systems that support

emergent knowledge processes. MIS Quarterly, 26(3), 179-212.

Maxwell, J. A. (2002). Understanding and validity in qualitative research. In M. A. Huberman &

M. B. Miles (Eds.), The qualitative researcher's companion (pp. 37-64). Thousand Oaks:

Sage Publications.

McDonald, J. (2001). Why is software project management difficult? and what that implies for

teaching software project management. Computer Science Education, 11(1), 55-71.

McLagan, P. A. (2002). Success with change. T+D, 56(12), 44-53.

Miles, M. B., & Huberman, M. A. (1994). Qualitative data analysis: An expanded sourcebook.

Thousand Oaks: Sage Publications.

Neubauer, T. (2009). An empirical study about the status of business process management.

Business Process Management Journal, 15(2), 166.

149

Neufeld, D., Dong, L., & Higgins, C. (2007). Charismatic leadership and user acceptance of

information technology. European Journal of Information Systems, 16(4), 494.

Newton, R. R., & Rudestam, K. E. (1999). Your statistical consultant: answers to your data

analysis questions. Thousand Oaks, California: Sage Publications.

Orlikowski, W. J., & Barley, S. R. (2001). Technology and institutions: What can research on

information technology and research on organizations learn from each other? MIS

Quarterly, 25(2), 145.

Pantazi, M.-A. A., & Georgopoulos, N. B. (2006). Investigating the impact of business-process-

competent information systems (ISs) on business performance. Managing Service

Quality, 16(4), 421.

Paré, G., & Jutras, J.-F. (2004). How good is the IT professional's aptitude in the conceptual

understanding of change management? Communications of AIS, 2004(14), 25.

Peng, S. C., & Carl, L. (1999). Implementing reengineering using information technology.

Business Process Management Journal, 5(4), 311.

Porter, M. E. (1979). How competitive forces shape strategy. Harvard Business Review, 57, 86-

93.

Project Management Institute. (2008). A guide to the project management body of knowledge

(PMBOK Guide) (4th ed.). Newtown Square, PA: Project Management Institute, Inc.

Ramarapu, N. K., & Lado, A. A. (1995). Linking information technology to global business

strategy to gain competitive advantage: an integrative model. Journal of Information

Technology, 10(2), 115-124.

Ravesteyn, P., & Batenburg, R. (2010). Surveying the critical success factors of BPM-systems

implementation. Business Process Management Journal, 16(3), 492.

150

Reich, B. H., & Siew Yong, W. (2006). Searching for knowledge in the PMBOK guide. Project

Management Journal, 37(2), 11-26.

Riemenschneider, C., Hardgrave, B., & Davis, F. (2002). Explaining software developer

acceptance of methodologies: A comparison of five theoretical models. IEEE

Transactions on Software Engineering, 28(12), 1135.

Rivard, S., & Dupré, R. (2009). Information systems project management in PMJ: A brief

history. Project Management Journal, 40(4), 20-30.

Saran, C. (2004). European banking giant adopts agile development methodology. Computer

Weekly, 24.

Schambach, T. P., & Walstrom, K. A. (2002-2003). Systems development practices: circa 2001.

Journal of Computer Information Systems, 43(2), 87-92.

Schniederjans, M. J., & Kim, G. C. (2003). Implementing enterprise resource planning systems

with total quality control and business process reengineering survey results. International

Journal of Operations & Production Management, 23(3/4), 418.

Sharma, M., & Sharma, R. P. (2010). Process integration in IT portfolio management. Journal of

American Academy of Business, Cambridge, 15(2), 145.

Steuperaert, D. (2009). Identify, govern and manage IT risk. COBIT Focus, 2009(4), 15-17.

Strickler, J. (2009, January 14). The process center of excellence. Agile Elements Retrieved

November 14, 2010, from http://agileelements.wordpress.com/2009/01/14/the-process-

center-of-excellence/

Subramoniam, S., Tounsi, M., & Krishnankutty, K. V. (2009). The role of BPR in the

implementation of ERP systems. Business Process Management Journal, 15(5), 653.

http://agileelements.wordpress.com/2009/01/14/the-process-center-of-excellence/

151

Syndikus, W. (2009). COBIT as a Method for Deliberate and Emergent Strategies. COBIT

Focus, 2009(4), 13-15.

Tallon, P. P., Kraemer, K. L., & Gurbaxani, V. (2000). Executives’ perceptions of the business

value of information technology: a process-oriented approach. Journal of Management

Information Systems, 16(4), 145-173.

Taylor-Cummings, A. (1998). Bridging the user-IS gap: a study of major information systems

projects. Journal of Information Technology (Routledge, Ltd.), 13(1), 29-54.

Tersine, R. J. (2004). The primary drivers for continuous improvement: the reduction of the triad

of waste. Journal of Managerial Issues, 16(1), 15-28.

Trkman, P. (2010). The critical success factors of business process management. International

Journal of Information Management, 30(2), 125.

Ungan, M. C. (2006). Standardization through process documentation. Business Process

Management Journal, 12(2), 135.

Venkatesh, V. (2006). Where to go from here? thoughts on future directions for research on

individual-level technology adoption with a focus on decision making. Decision Sciences,

37(4), 497.

Venkatesh, V., Davis, F. D., & Morris, M. G. (2007). Dead or alive? the development, trajectory

and future of technology adoption research. Journal of the Association for Information

Systems, 8(4), 267.

Venkatesh, V., Morris, M. G., Davis, G. B., & Davis, F. D. (2003). User acceptance of

information technology: toward a unified view. MIS Quarterly, 27(3), 425.

152

Wang, C.-H., Liu, W.-L., Tseng, M.-C., & Tsai, H.-S. (2010). A study of Taiwanese college

teachers' acceptance of distance learning. International Journal of Organizational

Innovation, 3(2), 243-260.

Ward, J., & Peppard, J. (2002). Strategic planning for information systems. New York: Wiley.

What does Cronbach's alpha mean? (2012) Retrieved April 9, 2012, from

http://www.ats.ucla.edu/stat/spss/faq/alpha.html

Zhao, F. (2004). Management of information technology and business process re-engineering: a

case study. Industrial Management + Data Systems, 104(8/9), 674.

http://www.ats.ucla.edu/stat/spss/faq/alpha.html

153

APPENDIX A

TRADITIONAL IT PROJECTS COMPARED TO TECHNOCHANGE PROJECTS

The following table describes the differences between a traditional IT project

management approach, a technochange (Integrated Technology Change) project, and a typical

OCM approach to a new IT solution (Markus, 2005).

IT Projects Technochange Situations

Organizational Change

Programs

Target

Outcomes

Technology

performance, reliability,

cost of operation and/or

maintenance, within

project schedule and

budget parameters

Improvement in organizational

performance

Improvement in

organizational culture and/or

performance

The Solution New IT New IT applications, often in

conjunction with complementary

organizational changes

Interventions focused on

people, organization structure

and culture, or human

resource management

policies

Example Replace outdated

management reporting

software with data

warehouse and analysis

tools to reduce time that

in-house IT personnel

spend preparing ad hoc

reports at the request of

business managers

Achieve significant savings in

procurement through a restructuring

of the procurement function

(centralizing at headquarters the

process of contracting with vendors

of key supplies and consolidating

purchases to achieve deep discounts)

in conjunction with the adoption of a

new procurement software package

that will allow headquarters to

monitor business units’ compliance

with the consolidated purchasing

contracts

Transform a mature

organization that is

underperforming its

competitors by making

people more innovative,

customer-focused, and

empowered to take initiative

and make decisions

Basic

Approach

The ―project‖—a

temporary

organizational structure

led by a project

manager who is

expected to produce an

outcome (e.g., a

working system) that

meets stated

specifications on time

and within budget

Typically, an IT project followed by

implementation efforts; in effective

technochange management, a

―program‖ of change initiatives of

which an IT project is one; others

may include organizational or

business process restructuring,

change in reward systems, job

redesign, training, etc.

Organizational

development—the umbrella

term for a collection of

change methodologies that

target one or more of the

following: managers’

attitudes and behaviors,

human resource development

and training, organization

culture, reward systems, job

redesign, organizational

structure, etc.

154

IT Projects Technochange Situations

Organizational Change

Programs

Role of

Organization’s

Managers

Oversight—to approve

the project, to provide

funding for the project,

possibly to initiate the

project by identifying

need, sometimes

providing input for

requirements

specification

Leadership—to initiate the project, to

act as sponsors and champions of

change, to explore process options

enabled by the new technology, to

design and implement non-

technology changes, to change their

own management systems and

behaviors as required to ensure

benefits, to provide key design inputs

and oversight for the IT project

Leadership—to initiate the

change effort, to change their

own management styles and

behaviors in ways to lead by

example, to reward the

desired new behaviors and

the achievement of

objectives, etc.

Role of IT

Specialist

Central—to perform the

project management

role and most of the

project labor; to

coordinate with

business managers,

vendors and external

consultants

Central—to work together with

organizational managers and other

specialists to design a technochange

in which the IT part meshes with

other changes to achieve desired

objectives; to lead and staff the IT

project

Negligible

Role of Other

Specialists

Technology vendors

and consultants may

perform various tasks

Internal staff specialists (human

resources, industrial engineering,

strategic planners, etc.),external

management and technology

consultants, and technology vendors

may all play key roles

Internal human resource

management and

organizational development

specialists and external

management and organization

development consultants

often perform key roles

Key Success

Factors

Project manager

performance,

technology

performance, vendor

performance

Performance of organizational

managers, performance of internal

and external organizational change

consultants; project manager

performance, technology

performance, vendor performance;

tight ongoing coordination between

people involved in the organizational

change program and the IT project

Performance of

organizational managers,

performance of internal and

external organizational

change consultants

1 5 5

A P

P E

N D

IX B

S U

R V

E Y

Q U

E S

T IO

N S

T h e f

o ll

o w

in g s

u rv

e y q

u e st

io n s

w il

l b e u

se d f

o r

th e r

e se

a rc

h .

E a c h q

u e st

io n d

e p ic

ts w

h ic

h o

f th

e f

o u r

c o n st

ru c ts

a re

b e in

m e a su

re d ,

a s

w e ll

a s

th e r

e sp

o n se

r a n

g e t

h a t

w il

l b e p

ro v id

e d f

o r

e a c h q

u e st

io n ,

b y e

a c h o

f fo

u r

w o

rk in

g a

re a s

(e n te

rp ri

se ,

IT , jo

b -

sp e c if

ic , a n d c

li e n t)

Q u

e st

io n

r ig

in a l

In st

r u

m e n

M o d

if ie

d I

n st

r u

m e n

E n

te r p

r is

P r o c e ss

e s

IT -w

id e

P r o c e ss

e s

J o

b -S

p e c if

P r o c e d

u r e s

C li

e n

P r o c e ss

e s

P e r fo

r m

a n

c e E

x p

e c ta

n c y

( H

y p

o th

e si

s 1 )

I w

o u

ld f

in d

t h

e s

y st

e m

u se

fu l

in m

jo b

I w

o u ld

f in

d p

ro c e ss

e s

o r

p ro

c e d u re

u se

fu l

in m

y j

o b .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

U si

n g t

h e s

y st

e m

e n

a b

le s

m e t

a c c o

m p

li sh

t a sk

s m

o re

q u

ic k ly

U si

n g p

ro c e ss

e s

o r

p ro

c e d u re

e n a b le

s m

e t

o a

c c o m

p li

sh t

a sk

s m

o re

q u ic

k ly

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

U si

n g t

h e s

y st

e m

i n

c re

a se

s m

p ro

d u

c ti

v it

y .

U si

n g p

ro c e ss

e s

o r

p ro

c e d u re

in c re

a se

s m

y p

ro d u c ti

v it

y .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

If I

u se

t h

e s

y st

e m

, I

w il

l in

c re

a se

m y

c h

a n

c e s

o f

g e tt

in g a

r a is

e .

If I

u se

p ro

c e ss

e s

o r

p ro

c e d u re

s, I

w il

in c re

a se

m y c

h a n c e s

o f

g e tt

in g a

ra is

e .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

E ff

o r t

E x p

e c ta

n c y

( H

y p

o th

e si

s 2

)

M y i

n te

ra c ti

o n

w it

h t

h e s

y st

e m

w o u ld

b e c

le a r

a n

d u

n d

e rs

ta n

d a b

M y u

se o

f p ro

c e ss

e s

o r

p ro

c e d u re

s is

c le

a r

a n d u

n d e rs

ta n d a b le

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 F

ro m

U se

r a c c e p

ta n c e o

f in

fo rm

a ti

o n t

e c h

n o

lo g

y :

to w

a rd

a u

n if

ie d

v ie

w ,

b y V

e n k a te

sh ,

V .,

M o

rr is

, M

. G

., D

a v is

, G

. B

., &

D a v is

, F

. D

., 2

0 0

3 .

M IS

Q u a

rt e rl

y ,

2 7

(3 ),

4 2 5

, C

o p

y ri

g h t

2 0

0 3

b y V

. V

e n k a te

sh e

t a l.

A d

a p

te d

w it

h p

e rm

is si

o n .

1 5 6

Q u

e st

io n

r ig

in a l

In st

r u

m e n

M o d

if ie

d I

n st

r u

m e n

E n

te r p

r is

P r o c e ss

e s

IT -w

id e

P r o c e ss

e s

J o

b -S

p e c if

P r o c e d

u r e s

C li

e n

P r o c e ss

e s

It w

o u

ld b

e e

a sy

f o r

m e t

o b

e c o m

sk il

lf u

l a t

u si

n g t

h e s

y st

e m

It w

o u ld

b e e

a sy

f o r

m e t

o b

e c o m

sk il

lf u l

a t

u si

n g p

ro c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

I w

o u

ld f

in d

t h

e s

y st

e m

e a sy

t o u

se .

I w

o u ld

f in

d p

ro c e ss

e s

o r

p ro

c e d u re

e a sy

t o u

se .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

L e a rn

in g t

o o

p e ra

te t

h e s

y st

e m

i s

e a sy

fo r

m e .

L e a rn

in g t

o u

se p

ro c e ss

e s

o r

p ro

c e d u re

s is

e a sy

f o r

m e .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

A tt

it u

d e T

o w

a r d

U si

n g

T e c h

n o

lo g

y (

H y p o th

e se

s 1 a

n d 2

)

U si

n g t

h e s

y st

e m

i s

a b

a d

/g o

o d i

d e a .

U si

n g p

ro c e ss

e s

o r

p ro

c e d u re

s is

g o o d i

d e a .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 0

h e s

y st

e m

m a k e s

w o

rk m

o re

in te

re st

in g .

P ro

c e ss

e s

o r

p ro

c e d u re

s m

a k e w

o rk

m o re

i n te

re st

in g .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 1

o rk

in g w

it h

t h

e s

y st

e m

i s

fu n .

U si

n g p

ro c e ss

e s

o r

p ro

c e d u re

s is

f u n .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 2

li k e w

o rk

in g w

it h

t h e s

y st

e m

li k e u

si n g p

ro c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S o c ia

l In

fl u

e n

c e (

H y p

o th

e si

s 3 )

1 3

e o

p le

w h

o i

n fl

u e n

c e m

y b

e h

a v io

th in

k t

h a t

I sh

o u

ld u

se t

h e s

y st

e m

P e o p le

w h o i

n fl

u e n c e m

y b

e h a v io

th in

k t

h a t

I sh

o u ld

u se

p ro

c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 4

e o

p le

w h

o a

re i

m p

o rt

a n t

to m

e t

h in

th a t

I sh

o u

ld u

se t

h e s

y st

e m

P e o p le

w h o a

re i

m p o rt

a n t

to m

e t

h in

th a t

I sh

o u ld

u se

p ro

c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 5

h e s

e n io

r m

a n

a g e m

e n

t o

f th

b u

si n e ss

h a s

b e e n

h e lp

fu l

in t

h e u

se o

th e s

y st

e m

T h e s

e n io

r m

a n a g e m

e n t

o f

th is

c o m

p a n y h

a s

b e e n h

e lp

fu l

in t

h e u

o f

p ro

c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 6

g e n

e ra

l, t

h e o

rg a n

iz a ti

o n h

a s

su p

p o

rt e d t

h e u

se o

f th

e s

y st

e m

In g

e n e ra

l, t

h e o

rg a n iz

a ti

o n h

a s

su p p o rt

e d t

h e u

se o

f p ro

c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 5 7

Q u

e st

io n

r ig

in a l

In st

r u

m e n

M o d

if ie

d I

n st

r u

m e n

E n

te r p

r is

P r o c e ss

e s

IT -w

id e

P r o c e ss

e s

J o

b -S

p e c if

P r o c e d

u r e s

C li

e n

P r o c e ss

e s

F a c il

it a ti

n g C

o n

d it

io n

s (H

y p

o th

e si

s 4

)

1 7

h a v e t

h e r

e so

u rc

e s

n e c e ss

a ry

t o u

th e s

y st

e m

I h a v e t

h e r

e so

u rc

e s

n e c e ss

a ry

t o u

p ro

c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 8

h a v e t

h e k

n o

w le

d g e n

e c e ss

a ry

t o u

th e s

y st

e m

I h a v e t

h e k

n o w

le d g e n

e c e ss

a ry

t o u

p ro

c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 9

h e s

y st

e m

i s

n o t

c o

m p

a ti

b le

w it

o th

e r

sy st

e m

s I

u se

O u r

p ro

c e ss

e s

a n d p

ro c e d u re

s a re

n o t

c o m

p a ti

b le

w it

h o

th e r

p ro

c e ss

e s

o r

p ro

c e d u re

s I

u se

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

2 0

s p

e c if

ic p

e rs

o n

( o r

g ro

u p )

a v a il

a b le

f o

r a ss

is ta

n c e w

it h

s y st

e m

d if

fi c u

lt ie

A s

p e c if

ic p

e rs

o n o

r g ro

u p i

a v a il

a b le

t o h

e lp

m e w

h e n I

h a v e

d if

fi c u lt

ie s

w it

h p

ro c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e lf

-e ff

ic a c y

( H

y p

o th

e si

s 4 )

2 1

c o

u ld

c o

m p

le te

a j

o b

o r

ta sk

u si

n g

th e s

y st

e m

i f

th e re

w a s

n o

o n e a

ro u n d

to t

e ll

m e w

h a t

to d

o a

s I

g o

I c o u ld

c o m

p le

te a

j o b o

r ta

sk u

si n g

p ro

c e ss

e s

o r

p ro

c e d u re

s if

t h e re

w a s

n o o

n e a

ro u n d t

o t

e ll

m e w

h a t

to d

o a

I g o .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

2 2

c o

u ld

c o

m p

le te

a j

o b

o r

ta sk

u si

n g

th e s

y st

e m

i f

I c o

u ld

c a ll

s o m

e o n e f

o r

h e lp

i f

I g o

t st

u c k .

I c o u ld

c o m

p le

te a

j o b o

r ta

sk u

si n g

p ro

c e ss

e s

o r

p ro

c e d u re

s if

I c

o u ld

c a ll

so m

e o n e f

o r

h e lp

i f

I g o t

st u c k .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

2 3

c o

u ld

c o

m p

le te

a j

o b

o r

ta sk

u si

n g

th e s

y st

e m

i f

I h

a d

a l

o t

o f

ti m

e t

c o

m p

le te

t h

e j

o b

f o

r w

h ic

h t

h e

so ft

w a re

w a s

p ro

v id

e d

I c o u ld

c o m

p le

te a

j o b o

r ta

sk u

si n g

p ro

c e ss

e s

o r

p ro

c e d u re

s if

I h

a d a

l o t

o f

ti m

e t

o c

o m

p le

te t

h e j

o b f

o r

w h ic

th e p

ro c e ss

e s

o r

p ro

c e d u re

s w

e re

d e si

g n e d .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

2 4

c o

u ld

c o

m p

le te

a j

o b

o r

ta sk

u si

n g

th e s

y st

e m

i f

I h

a d

j u

st t

h e b

u il

t- in

h e lp

f a c il

it y f

o r

a ss

is ta

n c e .

I c o u ld

c o m

p le

te a

j o b o

r ta

sk u

si n g

p ro

c e ss

e s

o r

p ro

c e d u re

s if

I h

a d o

n ly

th e a

ss o c ia

te d j

o b a

id s

a v a il

a b le

f o r

a ss

is ta

n c e .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

1 5 8

Q u

e st

io n

r ig

in a l

In st

r u

m e n

M o d

if ie

d I

n st

r u

m e n

E n

te r p

r is

P r o c e ss

e s

IT -w

id e

P r o c e ss

e s

J o

b -S

p e c if

P r o c e d

u r e s

C li

e n

P r o c e ss

e s

A n

x ie

ty (

H y p

o th

e si

s 2

)

2 5

fe e l

a p

p re

h e n si

v e a

b o u

t u si

n g t

h e

sy st

e m

I fe

e l

a p p re

h e n si

v e a

b o u t

u si

n g

p ro

c e ss

e s

o r

p ro

c e d u re

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

2 6

s c a re

s m

e t

o t

h in

k t

h a t

I c o

u ld

l o se

a l

o t

o f

in fo

rm a ti

o n

u si

n g t

h e s

y st

e m

b y h

it ti

n g t

h e w

ro n

g k

e y .

It s

c a re

s m

e t

o t

h in

k t

h a t

I c o u ld

f a il

a t

m y j

o b i

f I

w e re

t o u

se p

ro c e ss

e s

o r

p ro

c e d u re

s in

c o rr

e c tl

y .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

2 7

h e si

ta te

t o

u se

t h

e s

y st

e m

f o r

fe a r

o f

m a k in

g m

is ta

k e s

I c a n

n o

t c o

rr e c t.

I h e si

ta te

t o u

se p

ro c e ss

e s

o r

p ro

c e d u re

s fo

r fe

a r

o f

m a k in

m is

ta k e s

th a t

I c a n n o t

c o rr

e c t.

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

2 8

h e s

y st

e m

i s

so m

e w

h a t

in ti

m id

a ti

n g

to m

e .

P ro

c e ss

e s

o r

p ro

c e d u re

s a re

so m

e w

h a t

in ti

m id

a ti

n g t

o m

e .

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

B e h

a v io

r a l

in te

n ti

o n

t o

u se

t h

e s

y st

e m

( A

ll H

y p o th

e se

2 9

in te

n d

t o

u se

t h

e s

y st

e m

i n

t h e n

e x t

< n

> m

o n

th s.

I in

te n d t

o u

se p

ro c e ss

e s

o r

p ro

c e d u re

s in

t h e n

e x t

th re

e m

o n th

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

3 0

p re

d ic

t I

w o

u ld

u se

t h

e s

y st

e m

i n t

h e

n e x

t <

n >

m o

n th

I p re

d ic

t th

a t

I w

il l

b e u

si n g p

ro c e ss

e s

o r

p ro

c e d u re

s in

t h e n

e x t

th re

m o n th

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

3 1

p la

n t

o u

se t

h e s

y st

e m

i n

t h

e n

e x t

< n

> m

o n

th s.

I p la

n t

o u

se p

ro c e ss

e s

o r

p ro

c e d u re

in t

h e n

e x t

th re

e m

o n th

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

S e le

c t

0 -5

O p

e n

-E n

d e d

Q u

e st

io n

H o w

d o y

o u b

e li

e v e t

h a t

IT p

ro c e ss

e s

a n d p

ro c e d u

re s

a ff

e c t

th e w

a y y

o u s

u p p o rt

I T

s o

ft w

a re

p ro

je c ts

W h a t

is y

o u

r ro

le i

n u

n d e rs

ta n d in

g t

h e w

a y y

o u r

c li

e n ts

d o

b u si

n e ss

If y

o u c

o u ld

e x

p re

ss o

n e i

m p o rt

a n t

th in

g t

o y

o u

r m

a n a g e m

e n t

a b o u t

h o w

p ro

c e ss

e s

a n d p

ro c e d u re

s a re

m a n

a g e d w

it h in

I T

, w

h a t

w o u ld

t h a t

b e ?

159

APPENDIX C

RELATIONSHIPS OF SAP EXPORTED DATA FOR PRACTITIONER LIST

The following screen shot depicts the data as exported from SAP into Microsoft Access

in order to generate the potential respondents list. The initial data set, entitled ―qryWork-

EmployeesList,‖ is a different query that joins data from two SAP transactions, IW39 and

CADO, in order to find employees who have charged time to the appropriate work types. The

second data set, entitled ―HCMORGDATA,‖ provides the SAP job description and Manager

name. The third data set is simply a lookup table used to group classifications of job titles

together, such as Analyst-Program/Project 1, Analyst-Program/Project 2, etc.

160

APPENDIX D

SIGNIFICANCE OF POTENTIAL DETERMINANTS

BY CONTEXT AND SURVEY QUESTION

The following table contains the significance values of each of the survey questions correlated

with the survey question indicating intent to use processes or procedures. Highlighted cells are

those values where p < .050 and are therefore significant values.

Potential Determinant Enterprise-wide IT-wide

1 2 3 4 1 2 3 4

Performance Expectancy 0.24 0.40 0.27 0.00 0.81 0.63 0.19 0.13

Effort Expectancy 0.09 0.41 0.40 0.29 0.22 0.99 0.09 0.23

Attitude 0.01 0.37 0.66 0.00 0.13 0.87 0.49 0.01

Social Influence 0.02 0.00 0.10 0.03 0.02 0.01 0.22 0.00

Facilitating Conditions 0.00 0.00 0.02 0.66 0.01 0.01 0.09 0.81

Self-efficacy 0.00 0.07 0.27 0.07 0.05 0.06 0.11 0.09

Anxiety 0.55 0.73 0.31 0.41 0.36 0.90 0.14 0.97

Potential Determinant Job-specific Client processes

1 2 3 4 1 2 3 4

Performance Expectancy 0.11 0.45 0.06 0.01 0.00 0.02 0.08 0.01

Effort Expectancy 0.01 0.56 0.27 0.37 0.00 0.00 0.13 0.15

Attitude 0.00 0.19 0.98 0.01 0.01 0.24 0.42 0.00

Social Influence 0.01 0.00 0.07 0.00 0.00 0.00 0.00 0.00

Facilitating Conditions 0.00 0.00 0.03 0.72 0.00 0.00 0.00 0.00

Self-efficacy 0.02 0.01 0.23 0.04 0.00 0.00 0.04 0.03

Anxiety 0.07 0.85 0.25 0.78 0.17 0.06 0.12 0.10

161

APPENDIX E

VERBATIM RESPONSES

The following tables summarize the responses to the open-ended questions in the survey. Each

table responds to one of the following three questions:

 How do you believe that IT processes and procedures affect the way you support IT software projects?

 What is your role in understanding the way your clients do business?

 If you could express one important thing to your management about how processes and procedures are managed within IT, what would that be?

Table E1.

How IT Processes and Procedures Affect Software Projects

General Rating

Negative Neutral Positive

A n

a ly

st s

Completing process gets in the

way and takes longer than

completing the work; redundant;

too much focus on paperwork

Standard procedure to stick to Helps execute and monitor

project

Need to be more up-to-date; we

have a lot of work to do in this

area

100% should follow processes

and procedures

Help perform job effectively

with little or no help

Managers believe we are

process heavy and should

accomplish goals with less

process

Make work flow, increase

productivity, and help

implement projects

Missing clear, end-to-end

processes

Easier to identify issues and

tackle them

Missing training for newcomers Standardization across the

organization; increases quality,

efficiency, productivity

Common processes do not apply

to all business units

D e v

e lo

p e r s

Must go through more people to

get work done

Clear procedures reduce

confusion and increase

communication

Hinders projects on occasion Helps to have standards to

follow.

Processes are not coordinated

between business units

Establishes common standards

162

General Rating

Negative Neutral Positive T

e c h

n ic

a l

S ta

Process makes work slower but

more complete.

Processes are done according to

standards, in a specific way.

Processes facilitate completion

of work with fewer errors

Introduce complexity and do not

achieve what they were

designed for.

Define approaches and methods The right tools make the

process easy to manage and

complete

Too many processes increase

bureaucracy and slow progress;

too few results in loss of control

Streamlines work.

M a

n a

g e r s

Some processes are overbuilt,

counterproductive, and delay

support.

Supports transition of work

between workgroups.

Ensure consistency and

repeatability, increasing

likelihood of successful

implementation

Following processes does not

mean a better product.

Provide framework for

completing work.

Provide consistency

Processes not well defined,

communicated, or supported

PMs should follow processes Reduce duplication of effort

Processes are developed without

integration with other processes,

resulting in overlap, delay, and

confusion

Following processes helps

Maintenance take over after

completion of a project

Guide toward most effective use

of resources

Some processes are built

without the business need in

mind.

Integral part of my job. Enable uniform governance

across projects.

P r o

je c t

M a

n a

g e r s

Processes are time consuming

and cause delays, which bothers

the clients

Important for consistency and

collaboration

Positive outcome on

productivity

Too many processes and

procedures; too confusing

Ensures consistency and quality

of overall product

The backbone of the way we

work

Puts structure around what we

do and minimizes possibility of

chaos

163

Table E2.

Respondent’s Role in Understanding the Client’s Business

General Rating

Negative Neutral Positive

A n

a ly

st s

Ask about client processes or

figure them out on my own

Liaison between IT and the

client

Support clients' efforts for

success

Gather requirements,

troubleshoot problems, provide

suggestions

Understand clients' business

problem and provide IT solution

Vital to understand clients and

the intent of system

We understand clients' business

Communication is essential

D e v

e lo

p e r s

Better understanding results in

better requirements, resulting in

better code and getting more

done

Help implement the way clients

do business.

Know pain paints of clients

better than anyone else

T e c h

n ic

a l

S ta

Must understand clients'

business to implement

requirements

Must thoroughly understand

clients' business to support

applications

M a

n a

g e r s

Ensure proper project

management.

Provide needed business

capabilities.

Clients are trained to do specific

tasks.

Help understand problem,

gather client requirements, and

build solution

Ensure clients are happy.

Intimate with client processes

and procedures.

Define and analyze client

processes.

Ensure clients get proper

support from teams.

Ensure clients understand

maintenance needs.

P r o

je c t

M a

n a

g e r s

Some follow their own process;

no consistency

Understand the client's business Programs are developed to

address clients' critical business

needs

Understand integration points

Necessary part of my job.

164

General Rating

Negative Neutral Positive

Involved in understanding the

way the client wants to do

business

Table E3.

Message to Management

General Rating

Negative Neutral Positive

A n

a ly

st s

Way behind in ITIL processes Allow for exceptions In general, we create processes

well

Processes need to be up-to-date,

relevant, and Intentions clear; not

redundant or too much reporting

Involve the end user in

defining processes and

procedures

Processes are set up effectively

and need to be available to

anyone

Contractors should also be trained

in process

People developing procedures

need to have been in the client

world to understand steps

needed.

Exceptions to process are ―on

the fly,‖ not well defined and

confuse the teams

All managers should follow

processes and procedures

Processes are important and

should be taken seriously

Not enough communication

No criteria to choose what

processes to follow for projects of

different sizes; takes extra time

when getting audited

Changing too rapidly, having to

constantly adjust work

D e v

e lo

p e r s

Processes are a mess Establish one end-to-end

process

Process change too often

People move to different jobs and

have to learn new processes

Some are more busy work than

useful.

T e c h

n ic

a l

S ta

Timeliness of responses to

processes in IT is lacking.

Be open to change.

Too many processes to manage;

sometimes overlap

Need a balanced approach to

implementing processes.

Too many people required to

implement processes

Are processes applicable to my

job? How can they help me do

my job? Can we rework some

of them?

Processes should be followed

the same way across business

units

165

General Rating

Negative Neutral Positive

Processes should be designed

for the type of work being

done.

M a

n a

g e r s

Processes should be easier to find. Helps PMs understand

minimum requirements of their

work.

Do not create conflicting processes Close collaboration is essential

Enforce processes Make the processes lean but

effective.

Less process and more value

delivered.

Upper management does not

believe in the processes.

No penalty for not being compliant

People who develop processes are

not those who perform them; not

well designed

Training and communication are

inadequate

Management should be consistent

in what they say and what they do

with processes.

Too complicated and not aligned

between organizations

Do not add to processes; simplify

them

Too onerous

Not efficient

P r o

je c t

M a

n a

g e r s

Processes should not be designed

with only one Business Unit in

mind.

Processes should be consistent

with the client PMO's

processes

Processes are developed with

collaboration in mind and

continuously updated to

respond to changing business

needs

There are way too many processes;

they are cumbersome and cause

delays

Simplify processes, and

everyone should then follow

them.

Roll out web-based training.