Strategic planning in Information Technology: Background and Significance of Study

strats3.pdf

Home >Computer Science homework help >Strategic planning in Information Technology: Background and Significance of Study

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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.

PR EV

IE W

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.

PR EV

IE W

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

PR EV

IE W

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.

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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.

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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.

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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

PR EV

IE W

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.

PR EV

IE W