Strategic planning in Information Technology: Research Design and Methods

Write 2-3 pages of in-dept information on the – Research Design and Methods used in Strategic planning in Information Technology
– Use the attached files and also make use of any interesting resources
– Have the citation and APA 6th or latest edition format
– Prepare 2-3 PPT slides on the same topic: Research Design and Methods

Information Systems Strategic Planning:

Don't use plagiarized sources. Get Your Custom Essay on

Just from $13/Page

Order Essay

Using Design Thinking Method at Startup Company

Jarot S. Suroso
Master in Information Systems Management Bina

Nusantara University
Jl. Kebun Jerk Raya No. 27 Jakarta, Indonesia

jsembodo@binus.edu

1Riswan E. Tarigan, 2Fatkhurozaq B. Setyawan
Master in Information Systems Management Bina

Nusantara University
Jl. Kebon Jeruk Raya No. 27 Jakarta, Indonesia

1retarigan@binus.ac.id, 2fatkhurozaq.budi@gmail.com

Abstract— Like other industries, logistic services especially for
inner city deliveries currently also facing immense changes due
digital disruption. Although many logistics companies use
information technology in their business models, but not all of them
make information technology as their core business. With the new
technology developments, new competitor, new business model and
changing customer behavior, the company should also change to
optimize technology support. Therefore, this startup company for
logistic and especially in last mile deliveries will make an
information systems to support their business by using Design
Thinking (DT) approach as Information System Strategic Planning
(ISSP). With Design Thinking and Personas approach, hopefully able
to create a system with good user experiences and user satisfaction
while using the product. The result is defined proper business flow
and developing website and android applications to facilitate business
activities. The conclusion of this research is Design thinking is one of
alternative method that can be used to make strategic planning of
information system for company, either new company (start-up) or
corporate.

Keywords— Design Thinking; Strategic Planning of
Information Systems; Logistic; Start-u.

I. INTRODUCTION
In past few years, e-commerce growing rapidly in

Indonesia. Starting with online shop using instagram,
facebook, bloggers as selling platform until bigger player in e-
commerce such as Lazada, Zalora, Blibli and others.
Indonesia’s e-commerce market was estimated at Rp 18 trillion
(US$ 1.3 billion) in 2015, with 37 million consumers from a
total population of 255 million [1].

The growth of ecommerce in Indonesia is not aligning
proportionally with current logistics system and infrastructure.
Several logistics company in Indonesia still using
conventional system for delivery process, validating receiver
and tracking of the package. Various problems arise from the
process of picking up the package from the warehouse until
delivered into the buyer or customer [2].

Another problem is the lack of documentation for Proof of
Delivery (POD) and still using paper as evidence. Besides
that, package tracking also become problematic because the
package sender (e-commerce and online shop) or package

receiver (consumer) did not have ability to see the status of
order history and the carrier of the package. Many problems
that occur between delivery services company, consumers and
sellers of the goods themselves. Specifically, the main
problem is online business run without aligning the support of
information systems and technology to business needs.

This research was conducted to startup company for
logistic and especially in last mile deliveries services for
creating Information System Strategic Planning (ISSP) with
Design Thinking approach.

Fig. 1 shows current business process in this company still
manual and lack of technology implementation. Starting
sender come to nearest branch until sender received
notification for completed deliveries.

Fig. 1. Current Business Process

Problems that will be discussed in information systems
strategic planning include:

1) How to plan and create integrated system application
and have unique value from other competitor?

2) How to analyze the needs of applications that can
facilitate the company’s business operations?

To deal with thoose problem, a design thinking approach is
used and combine with Personas in order to improved
communication about the target users within the design team
and with other stakeholders [3]. This studies focus on how to
develop IS Strategic Planning to help startup company for
logistic sevices have competitive advantage and added value
between the competitor.

The purpose of this research is create information system
strategic planning in which is align with vision and mission of
this company and able to support company’s business
operations. Also able to analyze on business environment with
observation approach, interview, personas and analyze the
needs of information systems environment with Design
Thinking approach.

II. LITERATURE REVIEW
Information systems is a media for people and

organizations, by utilizing technology, collecting, processing,
storing, using and disseminating information [4].

Information Systems Strategy is defined as a company’s
needs or requests for information and systems that support the
overall business strategy. An information system strategy is
basically used to define and prioritize the investments required
to obtain the ideal portfolio, and is expected to provide the
necessary changes within resource constraints and system
interdependencies [4].

Information Systems Strategy Planning is important
activities to help organizations for finding companies
opportunities by use information technology, determine
resource requirements to capitalize on those opportunities and
build strategies and workplans to realize opportunities and
meet companies expectation [5].

Design thinking is the journey for something magical
balance between business and art, structured and chaos,
instinct and logic, concepts and execution, playfulness and
formality, and control and empowerment [6].

Personas are abstractions of a set of actual consumers who
share their characteristics and needs. Pesonas manifested
through individual fiction presented as a collection of real
consumers who have the same character with the real
consumer [7].

Researchers also use previous research (Fig. 2) as a
consideration in determining the methodology to be used in
research.

Design Thinking is used to create an innovative data
storage service to the point of market analysis, create new
features and improve technological features and business
models before launching into the market [8]. Design Thinking
is used to create ICT-knowledge base for SMEs in South
Africa [9]. Design Thinking is used to design a smart city
project that ensures the participation of more detailed planning
by various stakeholders (users) of the system to be built [10].
Design Thinking is used to create a website that is expected to
increase customer satisfaction and provide more
communication to the stakeholders [11]. Design Thinking is
used to create hardware and software created at Apple [12].
Ward & Peppard and Enterprise Architecture Planning (EAP)
methods are used to improve existing information systems to
achieve competitive advantage [13]. Ward & Peppard is used
for IS/T Strategic planning framework at a college (STMIK
XYZ) to increasing the business value and creating the

competitive advantage of the college [14]. Ward & Peppard
framework is used to analyze the company’s quadrant position
using SWOT analysis and recommend refinement of 6
existing information systems and the addition of 6 new
information systems to support business strategy [15].

Fig. 2. Previous Research

III. SYSTEM MODEL AND METHODS
Information Systems Strategic Planning at startup

company using Design Thinking approach. Design Thinking
phase is consists of 3 main parts of Understand, Explore and
Materialize. Sub phase from the three main parts, consisting of
Empathize, Define, Ideate, Prototype, Test and Implement
[16]. With Design Thinking approach, Information Systems
Strategic Planning able to be achieve by six phases.

A. Empathize
Empathize phase is consists of 3 parts :observing users and

their habits in their daily lives (Observe), interact with the user
directly and conduct interviews (Engage), position themselves
and think as the user (Immerse). Starting with identifying
internal and external business environment by observe,
gathering information by using Google Form and think as
user.

B. Define
The customer voice in this stage of the design thinking

approach can be obtained by many ways. In this paper, we
used the personas from both stakeholders [11]. Personas will
be used for define and filter all information when we do
company.

C. Ideate
Brainstorm and exploration of creative ideas that meet the

needs of users who have been identified in the Define phase.
Then, each team member share ideas with one another and
collaborate it [16].

D. Prototype
Prototype phase aims to build a clear picture of the ideas

that have been selected. The purpose of the prototype phase is
to understand and sort through between which components
can be implemented or not. In this phase also measured the
impact and complexity of the prototype that has been made.
Any changes made will be required feedback from all
members.

E. Test
Interface demo to some users who will use such

application as courier and online prospective partner. In
addition to the potential application users being built, feedback
is also required from the internal or team involved in the
overall process.

F. Implement
Process of application development is started. Gathering

and selecting technology and application will be used. Fig. 3
shows the design thinking process.

Fig. 3. Design Thinking Process

Method to take Data
Data collected by conducting interviews with consumers

and online shop sellers. Questioner filled by respondents
through Google form and interviews conducted by visiting
several consumers and online shop sellers

IV. RESULT

A. Empathize phase
In Empathize phase we observing 2 object, competitor and

ecommerce. Observation is not only external business
environment but also external IS/T environment. Conclusion
from observe e-commerce is:

• Each shipping address must have zip code, therefore it
needs a mapping of zip code in the system to be built. It
aims to facilitate the process of data integration with e-
commerce.

• Order ID is an order number owned by ecommerce and
the item tracking system does not use an Order ID from
e-commerce but uses the code provided by the shipping
service.

• Each ecommerce has different templates for the size of
the printed receipt and the information on the receipt.
The information included, among other things, the
recipient’s name, recipient address, Order ID, Tracking
ID and barcode.

Meanwhile from competitors side in Jakarta in particular
observations base on their features and services categorized
by:

• Shipping costs

• Tracking system
• Proof of delivery
• Raw printed and embedded on packets sent
• API integration

This observation aims to find more value than the
application to be built compared to that of competitors as
company competitive advantage.

After that, we ask several online shop and e-commerce
seller to fill questionnaire through Google form for data
validation. Table 1 shows the questionnaire result.

TABLE I. QUESTIONNAIRE RESULT

No Question Answer
1 How long you run an

online shop business?
9 people (56.3%) have been in

business for more than 1 year, 3
people (18.8%) for 6 – 12 months and

4 (25%) are under 6 months.
2 What kind of your

business catergory ?
43.8% in clothing & accessories,

18.8% in food & beverage, 6.3% in
automotive and 31.3% for other

fields.
3 What your supporting

tools / device for help
your business operational

93,8% use handphone, 87,5% use
laptop, 62,5% use camera, 37,5% use
printer and 50% use internet modem

4 Are you have physical
store ?

81.3% do not have a physical store
and only 18.8% have a physical store.

5 Where your store
location ?

18.8% in South Jakarta, 12.5% in
North Jakarta, 6.3% in Central

Jakarta, 25% in East Jakarta, 12.5%
in Bekasi and 25% in Tangerang.

6 What delivery services
recently used for

shipping your product ?

87.5% using Tiki and JNE, 50%
using Go-Jek and Grab, 37.5% using

other logistics services
7 Where your package

delivery destination ?
81.3% in DKI Jakarta, 43.8% in

Bekasi, 50% in Depok and
Tangerang, 62.5% in other areas.

8 How often do you use
logistics services for your

online shop?

62.5% use daily delivery service and
37.5% once a week.

9 Do you use insurance
services in the delivery

process?

87.5% did not use insurance and
12.5% chose to use insurance for

delivery.
10 What type of shipments

do you use most often for
shipping?

12.5% use 1 day service (express),
81.3% choose 2 – 3 days, and 6.3%

choose 5 – 7 days.

From the results of the questionnaire, it can be used as a
reference for making strategic planning of information
systems. The conclusions that can be taken are:

• Almost all online shop businesses have used mobile
phones, computers and printers to run their business.
There is no problem in the hardware requirement to use
the newapplication.

• The majority of businesses use TIKI and JNE as their
shipping medium and use 2 to 3 working days delivery
service.

B. Define phase

In Define phase, we uses the Personas and Empathy map
methods which is stored in the Mural website
(https://mural.co/).

Fig. 4. Personas Result

Personas themselves (as shown in Fig. 4) are used to
determine the company’s vision and mission, determine the
services to be provided, the more value it has, how to run the
business. The question is:

1) What is it? This question is to discuss the vision and
mission of the company which will be used as a media
brainstorming team in selling the resulting product.

2) What we do? This question is more focused on
internal activities or features that will be owned by the
company to support its business activities.

3) Our services. This question is to answer the services
that will be provided to online shop and e-commerce partner.

4) Features. This question is to answer the features that
will support the services offered.

5) Unique value. This question is to find more value than
existing competitors.

6) How we do it. This question is to determine which
strategy will be used to reach the previous questions.

Other problem that we found in define phase from
immerce as user and observation with competitor is:

• Unclear change of status or transfer of goods from
ecommerce storehouse to courier.

• Uncertainty of time for consumers will get goods

purchased through ecommerce.

• Unclear recipient of goods if the recipient of goods is
not the consumer itself, such as security guards,
helpers, relatives and others.

• The process of ordering delivery services to logistics
partner who

is still manual (manual entry).

• The reconciliation of invoices for e-commerce is still
manual and not automatic.

C. Ideate phase

From the problems that have been found in the previous
phase, then made the solution presented in the form of Table
2:

TABLE II. PROBLEM AND SOLUTION

Problem Solution
Unclear change of status or

transfer of goods from
ecommerce storehouse to courier

Record and provide status for any
change or movement of goods and
displayed on the internal website.

Uncertainty of time for
consumers will get goods

purchased through ecommerce.

Consumers will get notified when
the goods will be delivered

directly by courier.
Unclear recipient of goods if the

receiving goods is not the
consumer itself, such as security

guards, helpers, relatives and
others.

Provides information to an
ecommerce containing: recipient
name, recipient’s phone number,

digital photo and signature

The process of ordering delivery
service to logistics partner which

is still manual (manual entry).

Create an API integration with
ecommerce and upload csv files.

The reconciliation of invoices for
ecommerce is still manual.

Creating an email containing bills
that delivery can be set (weekly or

monthly)

From the platform side will be divided into 2 parts,
website app and android app. For the website itself is divided
into 3 types of users based on each category, among others:

1) Admin dashboard. This website is used by internal
employees to monitor the daily courier operations, adding and
reducing courier, merchant and ecommerce partner.

2) Merchant dashboard. This website is used by
merchants to monitoring of transactions received from
ecommerce everyday.

3) Webstore dashboard. This website is used to
operational monitoring of ecommerce everyday. In this case e-
commerce can have multiple merchants or sellers from
multiple places.

For the android app is divided into 2 parts, namely:

1) App Driver. This application will be used by courier
for the process of taking and delivery of goods from webstore
or merchant to consumers.

2) Merchant and Webstore apps. This application will
be used by the merchant and webstore to perform the
validation process of goods that are ready to be sent (change
the status of the booking to be wrapped).

D. Prototype phase

To facilitate the creation of a prototype and each member
can contribute without having to do face-to-face directly, we
selects Moqups website (https://moqups.com) as online
tools.The results of personas are also used to determine the
style and themes of the application itself.

We choose a light blue to describe the company’s image.
The blue color itself reflects the reliability, stability and
security in the business [17].

As for design and visualization, we chose to use material
design because the material design is the philosophy of the
design concept from Google that can describe how the
application will look and function in mobile apps [18].

After the prototype phase is complete, the designer will
tidy it up and create the interface design of the application.The
results of the completed design and to facilitate the demo
interface, the team put all screen and interface into the website
invision (https://www.invisionapp.com/). Fig. 5 shows the
prototype results using Android apps.

Fig. 5. Android apps Prototype

E. Test phase
The Test phase will begin when we starts performing a

demo interface to some users who will use the app like courier
and online prospective partner. To validate the application that
has been made, then we make a demo to instagram shop.

At the end of the demo interface, the instagram shop is
given a questionnaire about the new application. Table 3
shows the test phase questioner result.

TABLE III. TEST PHASE QUESIONER RESULT

No Question Answer
1 Will the features provided by

this company help your
business activities?

100% replied that the features
provided by this company can
help their business activities.

2 What features make your
business easier?

100% replied that the most
preferred feature is the create
order feature. Order Tracking
and Invoice feature becomes the
2nd choice with each value of
80%.

3 What do you think about
interface (UI / UX) this
company website?

60% replied that the interface (UI
/ UX) of this company website is
good and 40% answered the
normal.

4 Are you easy to understand
and use this application?

100% replied that that
application is easy to use.

5 Do you agree with the
“Wrapped” status order?

100% of user agree that by order
of status “Wrapped” can reduce
human error or misunderstanding
between shipping service and
sender.

6 Would you like if your
mobile phone is used to
change the status order?

80% of correspondents agree that
their mobile phones are used for
operational activities and status
changes from Booked to
Wrapped. Only 20% answered
disagreeing of the question.

7 Will you use the services
offered by this company?

60% of correspondents are still
hesitant to use the services
offered by sendos. Only 40% of

correspondents will use it.
8 Are the dashboard owned by

this company better than the
shipping service you have
ever used from the design,
feature and functional side?

60% of correspondents replied
that this company app is better
than competitors’ apps. While
40% answer may be better.

F. Implement phase
In this phase we try to breakdown technical side of

application. Starting decide technology for development in
back end, front end and select supporting tools.

Analyze the needs of supporting applications in the
manufacture of systems that are being built based on the
capabilities or skills set of existing Engineers. Although the
applications used are based on the capabilities of the
Engineers, but the applications used include applications that
are being used by startups or other technology-based
companies.

Tasks for each platform and incorporated into the Product
Backlog Item (PBI). Product Backlog Item is a place to store
system needs that will be presented in the product [19].

V. CONCLUSIONS
The conclusions from the Information Systems Strategic

Planning at startup company are as follows:

1. Design Thinking is one of the alternative methods that
can be used to create Information Systems Strategic
Planning for companies, both new companies (start-up)
and corporate.

2. By using Design Thinking in Strategic Information
System planning, hopefully user will get good
satisfaction and experience (User Experience) while
using application.

3. Implementation Design Thinking at startup company
still has many shortcomings, among others:

a. Not directly tested system built, because not yet
launched in market.

b. The absence of iterations or product
improvements based on feedback consumers who
have used the application.

4. Implementation of Thinking Design may found
obstacles from top management of a company that has
been growing and running in a long time and has a
layered organizational structure.

5. Design thinking can be used by companies who want to
make changes to the information system owned at this
time and want to adjust the system information desired
by the user.

REFERENCES
[1] A. Amindoni, “E-commerce to be new driver of growth: ADB –

Business The Jakarta Post,” 2016. [Online]. Available:
http://www.thejakartapost.com/news/2016/01/27/e-commerce-be-
new-driver-growth-adb.html. [Accessed: 19-May-2017].

[2] R. A. Nugraha, “The Issue of E-Commerce in Indonesia in 2015 |

Dailysocial,” 2015. [Online]. Available:
https://dailysocial.id/post/the-issue-of-e-commerce-in-indonesia-in-
2015/. [Accessed: 20-May-2017].

[3] T. Miaskiewicz and K. A. Kozar, “Personas and user-centered design:
How can personas benefit product design processes?,” Des. Stud., vol.
32, no. 5, pp. 417–430, 2011.

[4] J. Ward and J. Peppard, The Strategic Management of Information
Systems: Building a Digital Strategy, 4th ed. West Sussex, United
Kingdom: John Willey & Sons, Ltd, 2016.

[5] A. I. A. and N. A. A. Arwa A. Altameem, “Strategic Information
Systems Planning (SISP),” Proc. World Congr. Eng. Comput. Sci.,
vol. Vol I, 2014.

[6] I. Mootee, “Design Thinking for Strategic Innovation: What They
Can’t Teach You at Business or Design School.” p. 224, 2013.

[7] T. Miaskiewicz and K. A. Kozar, “Personas and user-centered design:
How can personas benefit product design processes?,” Des. Stud., vol.
32, no. 5, pp. 417–430, 2011.

[8] M. Ghajargar, G. Mangano, A. De Marco, and R. Giannantonio,
“Design Thinking Applied to Data Storage Innovation : A Case Study
Design Thinking Applied to Data Storage Innovation : A Case
Study,” EAD Conf., vol. 12, no. April, 2017.

[9] O. Kabiawu, J. Van Belle, and M. Adeyeye, “DESIGNING A
KNOWLEDGE RESOURCE TO ADDRESS BOUNDED
RATIONALITY AND SATISFICING FOR ICT DECISIONS IN
SMALL ORGANIZATIONS,” EJISDC, vol. 73, no. 6, pp. 1–18,
2016.

[10] T. Lee, S.-G. Hong, and H. Jeong, “A Study on Smart City
Development Project for Regional Innovation: Co-creation and
Design Thinking Approach,” Adv. Sci. Technol. Lett., vol. 141, p.
pp.48-52, 2016.

[11] Ahmed Azab and Jaehyun Park, “On Time Cargo: A SMART
TRANSPORTATION SYSTEM DEVELOPMENT IN LOGISTICS
MANAGEMENT BY A DESIGN THINKING APPROACH,” 20th
Pacific Asia Conf. Inf. Syst. (PACIS 2016)20th Pacific Asia Conf. Inf.
Syst. (PACIS 2016), 2016.

[12] S. Thomke and B. Feinberg, “Design Thinking and Innovation at
Apple,” Harvard Buisness Sch., vol. 609–66, no. May, pp. 1–12,
2012.

[13] I. S. Widiati, E. Utami, and H. Henderi, “Perencanaan Strategis
Sistem Informasi Untuk Meningkatkan Keunggulan Kompetitif
Sekolah Islam Terpadu,” Creat. Inf. Technol. J., vol. 2, no. 4, pp.
329–340, 2015.

[14] Maryani and S. Darudianto, “Perancangan rencana strategis sistem
informasi dan teknologi informasi (SI/TI): studi kasus stmik xyz,”
CommIT, vol. 4, no. 2, pp. 77–85, 2010.

[15] T. Kristanto, “PERENCANAAN STRATEGIS SISTEM
INFORMASI DAN TEKNOLOGI INFORMASI PADA PT ADIRA
DINAMIKA MULTI FINANCE,” Semin. Nas. Sist. Inf. Indones. 2-3
Novemb. 2015, no. November, pp. 0–7, 2015.

[16] S. Gibbons, “Design Thinking 101,” Nielsen Norman Gr., p.
https://www.nngroup.com/articles/design-thinking/, 2016.

[17] P. Brittan, “Blue in Color Psychology – Impact on Mood,” May 09,
2016, 2016. [Online]. Available: https://www.verywell.com/the-
color-psychology-of-blue-2795815. [Accessed: 07-Mar-2017].

[18] C. Cousins, “What are the real merits of material design?,” 2015.
[Online]. Available: https://thenextweb.com/dd/2015/11/10/what-are-
the-real-merits-of-material-design/#.tnw_sAMigDxp. [Accessed: 07-
Mar-2017].

[19] V. Szalvay, “Glossary of Scrum Terms,” 2007. [Online]. Available:
https://www.scrumalliance.org/community/articles/2007/march/gloss
ary-of-scrum-terms. [Accessed: 20-May-2017].

<< /ASCII85EncodePages false /AllowTransparency false /AutoPositionEPSFiles false /AutoRotatePages /None /Binding /Left /CalGrayProfile (Gray Gamma 2.2) /CalRGBProfile (sRGB IEC61966-2.1) /CalCMYKProfile (U.S. Web Coated \050SWOP\051 v2) /sRGBProfile (sRGB IEC61966-2.1) /CannotEmbedFontPolicy /Warning /CompatibilityLevel 1.4 /CompressObjects /Off /CompressPages true /ConvertImagesToIndexed true /PassThroughJPEGImages true /CreateJobTicket false /DefaultRenderingIntent /Default /DetectBlends true /DetectCurves 0.0000 /ColorConversionStrategy /LeaveColorUnchanged /DoThumbnails false /EmbedAllFonts true /EmbedOpenType false /ParseICCProfilesInComments true /EmbedJobOptions true /DSCReportingLevel 0 /EmitDSCWarnings false /EndPage -1 /ImageMemory 1048576 /LockDistillerParams true /MaxSubsetPct 100 /Optimize false /OPM 0 /ParseDSCComments false /ParseDSCCommentsForDocInfo false /PreserveCopyPage true /PreserveDICMYKValues true /PreserveEPSInfo false /PreserveFlatness true /PreserveHalftoneInfo true /PreserveOPIComments false /PreserveOverprintSettings true /StartPage 1 /SubsetFonts false /TransferFunctionInfo /Remove /UCRandBGInfo /Preserve /UsePrologue false /ColorSettingsFile () /AlwaysEmbed [ true /Arial-Black /Arial-BoldItalicMT /Arial-BoldMT /Arial-ItalicMT /ArialMT /ArialNarrow /ArialNarrow-Bold /ArialNarrow-BoldItalic /ArialNarrow-Italic /ArialUnicodeMS /BookAntiqua /BookAntiqua-Bold /BookAntiqua-BoldItalic /BookAntiqua-Italic /BookmanOldStyle /BookmanOldStyle-Bold /BookmanOldStyle-BoldItalic /BookmanOldStyle-Italic /BookshelfSymbolSeven /Century /CenturyGothic /CenturyGothic-Bold /CenturyGothic-BoldItalic /CenturyGothic-Italic /CenturySchoolbook /CenturySchoolbook-Bold /CenturySchoolbook-BoldItalic /CenturySchoolbook-Italic /ComicSansMS /ComicSansMS-Bold /CourierNewPS-BoldItalicMT /CourierNewPS-BoldMT /CourierNewPS-ItalicMT /CourierNewPSMT /EstrangeloEdessa /FranklinGothic-Medium /FranklinGothic-MediumItalic /Garamond /Garamond-Bold /Garamond-Italic /Gautami /Georgia /Georgia-Bold /Georgia-BoldItalic /Georgia-Italic /Haettenschweiler /Impact /Kartika /Latha /LetterGothicMT /LetterGothicMT-Bold /LetterGothicMT-BoldOblique /LetterGothicMT-Oblique /LucidaConsole /LucidaSans /LucidaSans-Demi /LucidaSans-DemiItalic /LucidaSans-Italic /LucidaSansUnicode /Mangal-Regular /MicrosoftSansSerif /MonotypeCorsiva /MSReferenceSansSerif /MSReferenceSpecialty /MVBoli /PalatinoLinotype-Bold /PalatinoLinotype-BoldItalic /PalatinoLinotype-Italic /PalatinoLinotype-Roman /Raavi /Shruti /Sylfaen /SymbolMT /Tahoma /Tahoma-Bold /TimesNewRomanMT-ExtraBold /TimesNewRomanPS-BoldItalicMT /TimesNewRomanPS-BoldMT /TimesNewRomanPS-ItalicMT /TimesNewRomanPSMT /Trebuchet-BoldItalic /TrebuchetMS /TrebuchetMS-Bold /TrebuchetMS-Italic /Tunga-Regular /Verdana /Verdana-Bold /Verdana-BoldItalic /Verdana-Italic /Vrinda /Webdings /Wingdings2 /Wingdings3 /Wingdings-Regular /ZWAdobeF ] /NeverEmbed [ true ] /AntiAliasColorImages false /CropColorImages true /ColorImageMinResolution 200 /ColorImageMinResolutionPolicy /OK /DownsampleColorImages true /ColorImageDownsampleType /Bicubic /ColorImageResolution 300 /ColorImageDepth -1 /ColorImageMinDownsampleDepth 1 /ColorImageDownsampleThreshold 1.50000 /EncodeColorImages true /ColorImageFilter /DCTEncode /AutoFilterColorImages false /ColorImageAutoFilterStrategy /JPEG /ColorACSImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >>
/ColorImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >>
/JPEG2000ColorACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >>
/JPEG2000ColorImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >>
/AntiAliasGrayImages false
/CropGrayImages true
/GrayImageMinResolution 200
/GrayImageMinResolutionPolicy /OK
/DownsampleGrayImages true
/GrayImageDownsampleType /Bicubic
/GrayImageResolution 300
/GrayImageDepth -1
/GrayImageMinDownsampleDepth 2
/GrayImageDownsampleThreshold 1.50000
/EncodeGrayImages true
/GrayImageFilter /DCTEncode
/AutoFilterGrayImages false
/GrayImageAutoFilterStrategy /JPEG
/GrayACSImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >>
/GrayImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >>
/JPEG2000GrayACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >>
/JPEG2000GrayImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >>
/AntiAliasMonoImages false
/CropMonoImages true
/MonoImageMinResolution 400
/MonoImageMinResolutionPolicy /OK
/DownsampleMonoImages true
/MonoImageDownsampleType /Bicubic
/MonoImageResolution 600
/MonoImageDepth -1
/MonoImageDownsampleThreshold 1.50000
/EncodeMonoImages true
/MonoImageFilter /CCITTFaxEncode
/MonoImageDict << /K -1 >>
/AllowPSXObjects false
/CheckCompliance [
/None
]
/PDFX1aCheck false
/PDFX3Check false
/PDFXCompliantPDFOnly false
/PDFXNoTrimBoxError true
/PDFXTrimBoxToMediaBoxOffset [
0.00000
0.00000
0.00000
0.00000
]
/PDFXSetBleedBoxToMediaBox true
/PDFXBleedBoxToTrimBoxOffset [
0.00000
0.00000
0.00000
0.00000
]
/PDFXOutputIntentProfile (None)
/PDFXOutputConditionIdentifier ()
/PDFXOutputCondition ()
/PDFXRegistryName ()
/PDFXTrapped /False
/CreateJDFFile false
/Description << /CHS
/CHT
/DAN
/DEU
/ESP
/FRA
/ITA (Utilizzare queste impostazioni per creare documenti Adobe PDF adatti per visualizzare e stampare documenti aziendali in modo affidabile. I documenti PDF creati possono essere aperti con Acrobat e Adobe Reader 5.0 e versioni successive.)
/JPN
/KOR
/NLD (Gebruik deze instellingen om Adobe PDF-documenten te maken waarmee zakelijke documenten betrouwbaar kunnen worden weergegeven en afgedrukt. De gemaakte PDF-documenten kunnen worden geopend met Acrobat en Adobe Reader 5.0 en hoger.)
/NOR
/PTB
/SUO
/SVE
/ENU (Use these settings to create PDFs that match the “Required” settings for PDF Specification 4.01)
>>
>> setdistillerparams
<< /HWResolution [600 600] /PageSize [612.000 792.000] >> setpagedevice

Enterprise Architecture Modeling for Oriental
University in Timor Leste to Support the Strategic

Plan of Integrated Information System.

Sergio Soares
Magister Teknik Informatika

Universitas Atma Jaya Yogyakarta
Yogyakarta, Indonesia, 5528

sergiosoares.official89@gmail.com

Djoko Budiyanto Setyohady
Magister Teknik Informatika

Universitas Atma Jaya Yogyakarta
Yogyakarta, Indonesia, 55281

djoko@mail.uajy.ac.id

Abstract— Enterprise architecture aims to reach
synchronization between information technology and business for
the need of an organization. To develop the information system, a
university really needs a plan to achieve the university strategies
and goals. To build a plan by defining the architectural data first,
applying the applications and technology to support the whole
business process becomes an integrated system. Oriental Timor
Lorosa’e University is one of private universities in Timor Leste
whose development of information system is not integrated, and it
is still conventional in the existing business process needs. The
purpose of the research is to design an enterprise architectural
model which can be used for an organization to reach the strategic
plan of an integrated information system to achieve the vision and
mission efficiently and effectively. Enterprise architectural model
implements TOGAF methodology by Architecture Development
Method (ADM) stages which are flexible, complete, detailed, easy
to implement. The result of enterprise architecture planning is a
blueprint of information system for the data, application and
technology. So, it is useful for better base of information system
development in UNITAL’s business

process.

Keywords: Strategic Plan, Integrated Information System, TOGAF
ADM, UNITAL

I. INTRODUCTIO

Basically, Enterprise architectural modeling aims to create

the standardization and guidance to achieve the vision and
mission of an organization. Enterprise architecture is a tool or
strategy to support the business process and to achieve the
business goal [1]. One of the benefits of using enterprise
architecture is to reduce operational costs and improve
congruence between business and information technology [2]
[3]. Universidade Oriental de Timor Lorosa’e (UNITAL) is a
private university organization in Timor Leste and accredited
by Timorese National Accreditation Agency of National
Education Ministry since 2014. UNITAL is built on 20
September 2002 with the vision is to create the reliable and
competent human to develop knowledge, technology, arts and
culture for Timor Leste country and the mission is to prepare
the human resources as appropriate as the need of the country
and the evolution [4].

A strategic plan for effective information system can
provide the solution to create functional information system to

support the business management [5]. Nowadays, there are so
many organizations that are ready to invest for new technology
in the way to increase the competitiveness in the market. As in
the academic context, the previous research of strategic
information system planning supports the idea to ensure the
integration of information technology and business strategies
[6][7]. In other studies, it is also mentioned that many
universities face challenges, innovation and international
competitiveness [8].

In this case, UNITAL organization itself doesn’t have an
integrated information system yet for the main program and the
supporting programs till now. It is still conventional and it
really needs an adaptation of certain framework model to reach
the well enterprise architecture to gain the target. It is proved
by the lack of application of information technology for the
daily operations and the absence of strategic plan or a certain
framework to support the business architecture of the
organization [9]. The strategic plan of information system is
regarded as computer portfolio identification process with
application-based in the purpose to help the organization to run
the business plan and achieve the business goals [10].

TOGAF is a framework and method for enterprise
architecture that provides methodology to analyze a business
architecture overall [11]. The advantages of using TOGAF are
the flexibility and open source [12]. The goal of the research is
to create a suggestion to adapt enterprise architectural model by
using TOGAF framework. It aims to synchronize the purpose
of the business and the information technology so that it runs
effectively and efficiently. The result of TOGAF methodology
are a design and blueprint in order to develop an integrated
information system [13]. So, UNITAL can achieve organization
objectives.

II. REVIEW OF RELATED LITERATURE

A. Earlier Research
According to Dinesh and Albert, information system

planning is a set of activities as long as an organization chooses
the application portfolio with computer-based to facilitate and
to achieve the business goals. In the research titled “Less is
More: Information System Planning in an Uncertain

Environment”, it emphasizes the main factor of a successful
information system of an organization is plan because the plan
is very important as the beginning to achieve the aim [14].

One of other researches related to the research is “An
Enterprise resource planning system innovation and its
influence on organizational culture: a case study in higher
education” by Teresa Warig and Dimitra Skoumpopoulou. It
gave an illustration of implementing the integrated informatio

system for a university in England. The system is known as
strategic information technology service. It created the
complexity cultural environment with an integrated information
system [15]. As the UNITAL case, to adopt the integrated
system, the first thing to do is identifying the needs of the users
effectively and efficiently.

B. TOGAF ADM
TOGAF is a framework which consists of method and

supporting tools to develop enterprise architecture [11]. The
Enterprise architectural development method of TOGAF is
ADM (Architecture Development Method) which is the core
framework itself. TOGAF ADM is a generic method whose
functions are to develop and manage the enterprise architectural
model and is designed to handle most of the need of the
organization system.

Fig 1. ADM Cycle (The Open Group, 2011)

Figure 1 shows the principles and visions clearly about the
way to develop enterprise architecture. The principles are
implemented as a barometer to evaluate the success of
enterprise architectural modeling of an organization. They can
be described as:

Enterprise principle, an architecture model development
to support the organization program, including to
facilitate the need of the units,

The information technology principle is more leading
the consistency of the uses itself to support the
organization, including the units who will use it, and

The architectural principle is to design an architectural
system based on the need of the business process and the
implementation.

III. RESEARCH METHODOLOGY
This research is conducted in Timor Leste at University of

Oriental de Timor Lorosa’e (UNITAL). The process of
collecting data is done with literature study, interviewing
UNITAL management and observation. Literature study is
done by collecting references from books, journal publications
and previous research results related to this topic. The interview
is done by interviewing the rector, vice rector I, vice rector II,
vice rector III, vice rector IV, structural officials, planning unit
and (ICT) UNITAL information system. Observation is done
towards documents which are related to this study. The
following research shown in figure 2.

Fig 2. Research framework

The next step in this study is to review the current condition
of the enterprise which consist of identification and mapping
business processes, the identification and mapping are done to
get an idea of what business process are currently running at
UNITAL. In identification stage, there are main and supporting
activities, then followed by decomposition process of them,
using functional decomposition diagram (FDD). Once business
processes are identified, then researcher does gap analysis of
current business and ideal business process conditions that are
adjusted to organization expectations by proposing solutions
that are designed by the enterprise architecture.

IV. FINDING AND DISCUSSION

A. Business Process Identification and

Mapping

The main stage is identifying and mapping the business

process in UNITAL right now in accordance with the enterprise
architecture model stages. So, it is found the enterprise range of
the organization, university rules, and supporting framework to

Start

Observation Interview

Review of Current Enterprise Conditions
Business Process
Identification and

Mapping

Gap Analysis

Decomposing of
Business Activiti

Proposed Solutions and
Enterprise Architecture Modeling

Business Architecture
Modeling

End

Data Collection

Data Architecture
Modeling

Applications
Architecture Modeling

determine the architecture framework, architecture tools using,
enterprise architectural principles using. Based on the policy
rules, quality standards, strategic plans and operational plans in
2014-2019, every stakeholder in UNITAL must be able to carry
out the duty based on the work he or she has to do. Rector as
the highest leader has the duty to carry out the obligation to
organize education, research and society service in terms of
decision making, planning and evaluation. The new paradigm
of university quality assurance is university must maintain and
improve its quality to achieve its visions and missions, so that
stakeholders can be satisfied, and willing to be audited from
inside and outside. Based on the paradigm, UNITAL requires
education management that focuses on increasing quality
constantly through the management of university that is based
on modern management in order to improve institution
competitiveness. New students who register must follow the
admission selection first. If they pass, they are required to re-
register and complete the administration payment, so they can
follow the course activities. Lecturers as educators who are
recruited through the faculty and managed by the human
resources department. Then lecturers are assigned in academic
process according to their competence by referring to the
established curriculum. There are Training for lecturers and
other lecturers development activities to improve their quality.
The students follow lecture, practicum, practical work,
proposal, result and final test after they are officially accepted
as student. After the students pass final examination, they will
have graduation ceremony. In order to support education,
teaching, human resource management processes, library
management, facilities and infrastructures, so laboratory is run
as a unity of education and teaching process. The main business
activity process map that runs at UNITAL can be seen in figure
3.

Fig 3. Business Process Map of Educational Activities

And also Based on university principles, lecturers policy
and quality standards rectorate determines policy regarding
process of research, society service, and resource of the process.
Research plan and community service are made in the form of
proposal which after getting approval from the head of research
and dedication department, they can be executed and the results
must be reported. The results are submitted to library manager.
Other resources such as finance, lecturers, students, staff,

facilities and infrastructures play an important role in
supporting this process. In order to support one of the objectives
of UNITAL which requires to carry out education, research,
society service, and technology service center needed. To
define the business process of UNITAL, it is described with
value chain analysis in Figure 4.

Vision,
Mision

&
Goal

Admissions
of New
Student

Academic
Operational

Academic
Release

Research and
Community

Service
Facility and Infrastructure Managementy g

Human Resource

Management

Financial Managementg

Cooperation and Promotion Managementp g
Academic Quality Assurance Management

Pr
im

ar
y

A
ct

iv
iti

es
Su

pp
or

t A
ct

iv
iti
es

Fig 4. Value Chain Activity of UNITAL Business Process

In the figure 4, this is the business process of UNITAL
whose main and supporting programs need information system
and technology to run it all. The main programs are admission
for new students, academic operational, research and
community service, and academic release. And the supporting
programs are: the management of finance, human resource,
facilities and infrastructure, academic and general
administration, and library and computer laboratory. Neither
the main programs nor the supporting do need the information
system and technology to support the business process. After
identifying the business activities, the next is decomposing it
with Functional Decomposition Diagram (FDD) to be detailed
business sub-process and to know the problem of each sub-
process. Functional Diagram that shows main and support
business process at UNITAL can be seen in figure 5 and 6.

Admission of New
Students

Promotions

New

students

enrollment

New students
selection

Announcing
selection result

Choosing
semester subject

Lectures

Final
examination

Grade report

Academic report

Executing
research &
community

service activities

Graduation

Reporting
graduate

Main Activities

Academic Operational
Research and

Community ServiceAcademic Release

Academic
registration

Graduation
registration

Planning research
and community
service activities

Reporting
selection result

Reporting
research &
community

service activities

Fig 5. FDD of main activity at UNITAL

Budget
disbursement

transactions

Reporting of
Human resource
Administrative

Planning cooperation
& promotion

activities
Implementing

cooperation and
promotion

Reporting

cooperation and
promotion

Support Activities

Facility and
Infrastructure
Management

Human
Resource

Management

Financial
Management

Cooperation and
Promotion

Management

Academic Quality
Assurance

Management

Planning

Procurement

Management

Maintenance

Report

Human resource
planningp gp g

Recruitment of
Human resource

Reporting of

Human resource
Development

Planning and
budgeting

Budget

budge gg g
Student
payment

transactions

Finance report

Planning internal
quality assurance

standard document
management

Academic audit
and monitoringgg

Report

Fig 6. FDD of supporting activities at UNITAL

Faculty and Study Program Management

Curriculum
Development

Lectures and
exams

Thesis
Yudisium and

graduation

Educators
development and

assignment

Agencies of Cooperation
and Promotion

Cooperation and
promotion

Finance Administration

Tuition

fee

Graduation

fee

Academic AdministrationA d i A

Registration
Admission of new

students

Ad i i t tiAd

Graduation
administration

General
administration
and facilities

Sources

Library

Development of
academic

atmosphere

Human Resource
Management

Recruiting
lecturers

Recruiting
staff

Developing staff

Mapping and assigning
employee

Agencies of training
and developing

education

Research Agencies

Research and
community service

Student
Administration

Student activities

Teaching and
training foreign

languages

Language Section

Final exam

Facilities and
infrastructures

increasing lecturers’
quality

B. Gap Analysis
The analysis is to identify the problems in certain sub-

process which is described in the previous stage. It provides the
comparison of the recent business process condition and the
ideal one for UNITAL. The gap is considered as the problem to
be solved by several alternative solutions. But later, only an
alternative solution will be offered to develop UNITAL
information system which is the business architectural model.
Gap analysis of admission of new student sub-process can be
seen in table 1.

Table I. Admission of New Students

Admission of New Students

Activities Recent conditions Ideal
Problems
Analysis Solutions

New
students

enrollment
New
students

enrollment
is done

manually,
they must

come to the
campus to

get the form
and

complete
the

requirement
s

New
student

enrollment
can be
done

online by
filling

form in
UNITAL’
S website.

Student
candidates

who live far
from the

university
get

difficulty to
get the
form.

Develop
online

registration
system

New
students
selection

test

The
selection

test is done
directly at
campus

after
completing

the
enrollment

The
selection
tests can

be
scheduled
and done
through

computer
based test
(CBT) on
place and

online
website

Student
candidates

are not
ready to

take exams,
for it is

unscheduled
.

Automate the
scheduling

process of test
selection, and

integrate it
with

registration
and

announcement
process

Selection
result

notificatio
n

The test
result

notification
is

announced
a few days
after it is

done.

The test
result

notificatio
n can be

announced
directly on

place or
online.

Range error
occurs in

the process
of inputting
academic

requirement
and finance

data,
because it

has not been
integrated.

Integrate
announcement

-making
process with

the
registration
and finance

process.

C. Business Architecture Modeling
The architectural planning process is in accordance with

ADM TOGAF framework where the organization needs to
develop a better academic service for all the society of
academicians of UNITAL. One of the identified processes is the
admission for new students. The process is still conventional
and easy to find the problems in the form and queue for the new
student registrations. To solve it, it needs the integrated system
to ease the management. The target of the business process
model is described on the BPMN (Business Process Model and
Notation) diagram to show the comparison of the previous and

the expected business process. One of the sub-processes is the
new student registration as described in Figure 6 and figure 7
below.

Admission of New Students

C
om

m
itt

ee
St

ud
en

t
C

an
di

da
te

R
ec

to
r

D
ea

Registration Sub-process

Start

Registration
Form Filling

End

Reviewing
Registration

Data

Reviewing
Registration
Data

Get the number
of examinee and

the schedule

Registran Data

Registrant Data
Entry

Print out the
examination

card and
schedule.

Figure 6 Current BPMN (Business Process Model and Notation) diagram –
Sub-process registration

Admission of New Students
C

om
m

itt
ee

St
ud

en
t

C
an

di
da

te
R

ec
to

r
D

ea
n

Registration Sub-process
Start

Admission of
New Student
Information

System (ANSIS)
Form Filling

Registrant Data
Entry
End

Reviewing Data
of (ANSIS)

development

Reviewing Data
of (ANSIS)
development

Database

(ANSIS)

Get the login
username and
password of

(ANSIS)

Print out
(ANSIS)

examination
card

Figure 7 Expected BPMN (Business Process Model and Notation) diagram –
sub-process registration

D. Data Architecture Modeling
In this stage, the data architectural model is in accordance

with the need of the previous business and information process.
Data architecture is described with the diagram of entity,
attribute, and relation. The relationship of the inter data entity
support the business in accordance with previous business
architectural model. The model is described on ERD below
figure 8.

Figure 8. ERD Admission of New Students

Origin School

Has

Student
Candidate

N Selection
(ANSIS)

Examination

Has

Exam Sheet

1
N
N
1

Data entity of the admission for new students:
Original_school {school_id, school_name, city, district,
telephone}
Student_candidate {registrant_id, school_id,
name_of_registrant, address, telephone, e-mail,
birthplace, birthdate, gender, weight, height, citizenship,
study_program}
Selection {school_id, registrant_id, exam_id,
exam_score, health_record, status}
ANSIS_examination {exam_id, sheet_id, exam_type,
date_of_examination, the_number_of_participants}
Exam_sheet {sheet_id, exam_type, exam_level}

E. Application Architecture Modeling
In this stage, it is already understood about now situation

and ready to apply a new application architectural model. The
first step is defining the applications to manage the data. It is to
support the business needs. Below is the table of the
applications for a group of candidates.

Table II. Proposed Application

No. Group of Applications Application of Candidates
1 Admission of New

Students Information
System (ANSIS)

1. Online registration
2. On place registration
3. CBT selection
4. ANSIS report

2 Academic Operational 1. Academic Calendar Arrangement
2. Lecturer Management
3. Academic Registration
4. Study Planning Management

(SPM)
5. Study Result Management (SRM)
6. Schedule Management
7. Lecturer and Student Attendance

Management
8. Student Point Management
9. Laboratory/ Field Practice

Management
10. E-Learning Management
11. Semester Examination

Management
12. Final Assignment Management
13. Academic Report Management
14. Academic Leave Management

3 Academic Release 1. Graduation Registration
2. Diploma Management
3. Point Transcript Management
4. Graduate Data Management
5. Alumni Tracking

4 Financial Management 1. Proposed Budgeting
2. Fund Disbursement Management
3. Student Payment Transactional

Management.
4. Financial Report Management

5 Human Resource
Management

1. Proposed Human Resource Intake
2. Human Performance Evaluation
3. Training and Education

Administration
4. Honor, Salary, and Salary Cuts

Administration
5. Human Resource Report

6 Alumni Management 1. Alumni Tracking
7 Research and

Community Service
1. Research and Community Service

Management

8 Academic Quality
Assurance

1. The Data Management of
Academic Quality Assurance

Based on table 2, after listing several application candidates, the
next step is making portfolio application to explain the
relationship of the business sub-process and the features.

V. CONCLUTION
Enterprise architectural model which consists of business,

data and applications architecture absolutely adopts TOGAF
ADM and every stage can be done correctly well as long as the
business process is understood and identified. Based on this
awareness, there are several gaps between the needs and
realities of the information system of UNITAL. With an early
model planning in the research, it can produce an enterprise
architectural model for a whole and complete business process.
Finally, it can be implemented by UNITAL.

References
[1] N. Syynimaa, “Enterprise Architecture Adoption Method for Higher

Education Institutions,” Henley Business School University of Reading,
Tampere, 2015.

[2] D. Simon, K. Fischbach and D. Schoder, “Enterprise architecture
management and its role in corporate strategic management,” Inf Syst E-
Bus Manage, pp. 5-42, 2014.

[3] S. Buckl, C. Schweda and F. Matthes, “A Design Theory Nexus for
Situational Enterprise Architecture Management – Approach and
Application Example,” in Proceedings of the 14th IEEE international
enterprise distributed object computing conference, Munich, 2010.

[4] Administrator, Interviewee, UNITAL. 2016.
[5] P. H. Bermejo, A. O. Tonelli, A. Zambalde, M. J. Brito and J. L. Todesco,

“Implementation of information technology ( IT ) governance through IT
strategic planning,” African Journal of Business Management, vol. 6, no.
November, pp. 11179-11189, 2012.

[6] P. Tallon, “A process-oriented perspective on the alignment of
information technology and business strategy,” Journal of Management
Information Systems, pp. 227-268, 2007/2008.

[7] C. Wilkin and N. Cerpa, “Strategic Information Systems Planning : An
Empirical Evaluation of Its Dimensions,” Journal of Technology
Management & Innovation, vol. 7, no. 2, pp. 52-62, 2012.

[8] H. Paez-Logreira, R. Zamora-Musa and J. Velez-Zapata, “Relation
Analysis of Knowledge Management , Research , and Innovation in
University Research Groups,” Journal of Technology Management &
Innovation, vol. 11, no. 4, pp. 5-11, 2016.

[9] L. Octavia and F. L. Gaol, “Information Technology Strategic Planning
at PT. Ventrum System,” Journal Of Computer Science, vol. 9, no. 12,
pp. 1847-1855, 2013.

[10] V. Cho and R. Wright, “Exploring the evaluation framework of strategic
information systems using repertory grid technique: a cognitive
perspective from chief information officers,” Behaviour & Information
Technology, vol. 29, no. 5, pp. 447-457, 2010.

[11] TOGAF. The Open Group Architecture Framework, 2011.
[12] P. Desfray and G. Raymond, Modeling Enterprise Architecture with

TOGAF A Practical Guide Using UML and BPMN, K. Herbert, Ed.,
Massachusetts, Waltham: Elsevier, 2014, pp. 1-305.

[13] Anggara Wijaya, I. Nyoman Yudi and Setyohadi, Djoko Budiyanto,
“Analysis Business Architecture Study Case: Medical Colleges in
Purwokerto,” Advanced Science Letters, vol. 23, no 3, March 2017, pp.
2401-2403(3)10.1166/asl.20178648

[14] D. Mirchandani and A. Lederer, “Less is More: Information Systems
Planning in an Uncertain Environment,” Information Systems
Management, vol. 29, no. 1, pp. 13-25, 2012.

[15] T. Waring and D. Skoumpopoulou, “An enterprise resource planning
system innovation and its influence on organisational culture: A case
study in higher education,” Prometheus, vol. 30, no. 4, pp. 427-447,
2012.

InformationTechnology Strategic Plan
Development Methodology

Governing from the Perspectives of Enterprise Architecture

Richardus Eko Indrajit
Faculty of Information Technology

ABFI Institute Perbanas
Jakarta, Indonesia

indrajit@post.harvard.edu

Abstract—Information Technology Strategic Plan (ITSP) has
been considered as the most significant document for information
technology development within enterprise. Its existence helps
Chief Information Officer to strategise the construction and
implementation of enterprise information technology – and at the
same time avoiding from unnecessary risks and failures. The
introduction of enterprise architecture concept in the last decade
has altered the development methodology of ITSP. One of the
strong reason to adopt such approach is to ensure agility
behavior of information technology system. This paper proposes
the development of ITSP by adopting the concept of enterprise
architecture.

Keywords—information technology strategic plan; enterprise
architecture; chief information officer; agility

I. INTRODUCTION
Information System Audit and Control Association

(ISACA) states that ITSP is required to help the executives in
governing and managing all IT resources inline with the
business strategy and priorities [1]. All business and
information technology stakeholders bare the responsibilities to
ensure the optimal value delivered from information
technology projects and service portfolios [2]. Example of
potential risks faced by the corporation in the absence of ITSP
as guidance in conducting information technology initiatives
and implementation are: redundant cost, project overrun, low
performance infrastructure, silos applications, complex
architecture, and unaligned development scenario [3].

II. ITSP AND ENTERPRISE ARCHITECTURE
Control Objectives for Information and Related

Technology (COBIT) suggest that six control objectives should
be taken into consideration, which are: IT value management,
business-IT alignment, assessment of current IT capability and
performance, IT strategic plan, IT tactical plans, and IT
portfolio management [1]. This approach brings serious issues
since there is no illustrations or diagrams showing existing and
targeted states of information technology ecosystem. It brings
tendency that all IT projects determined based on gap analysis
are being conducted in isolation with each others [3]. The

common result is the islands of unintegrated silos system and
technology that jeoperdising enterprise in the long run [3][4].

The Open Group Architectural Framework (TOGAF)
suggests that in ITSP, there should include the “As-Is” and
“To-Be” designs of information technology architecture [5].
Within the ecosystem of enterprise architecture, there are at
least four sub-systems should be well described, designed, and
illustrated, which are: business architecture, application
architecture, information architecture, and technology
architecture [6]. “As-Is” architecture represents the existing
condition of information technology while “To-Be”
architecture shows target state that should be realised in a
particular time [5][6][7].

III. ACTION RESEARCH
This proposed methodology is developed through a series

of action research conducted by researcher in five year period.
The first year focused on collecting a good number of ITSP
development methodologes existed in the market. Most of the
methodologies found were developed by global consultant
firms such as Price-Waterhouse Coopers, Accenture
Consulting, Ernst and Young, Booz Allen, McKenzie, Boston
Consulting Group, and KPMG. There were also several
academic papers addressing the issues from different
perspectives that were gathered for the study. In second year,
the researcher was conducting meta analysis to produce
baseline methodology as guidance to develop ITSP. Several
validation techniques were used to challenge the methodology
through one-to-one discussion with experts and industry
practitioners. During the third year of research, the revised
methodology was field tested in a good dumber of medium size
enterprises. A major revision to the methodology has been
undergone based on this field study. In the fourth year, the
researcher was given opportunity by several corporations to
apply the ITSP methodology in various industry, which are: oil
and gas, healthcare, manufacturing, banking and finance,
transportation, and education. Finally in the last year, this
methodology is utilised to develop ITSP for government
agencies and non-for-profit organisations.

IV. THE ITSP DEVELOPMENT METHODOLOGY
This methodology consists of seven stages. Each stage

represents several artifacts that should be produced as part of
ITSP formal and official document.

A. Stage 1: Understanding Enterprise Environment
Every company operates within industrial ecosystem that

has unique characteristics. Assesing the posture and
characteristics of such environment will help management to
understand how the enterprise should position itself inside the
system [8]. Understanding enterprise’s vision, mission, values,
products/services, market segments, customers, and partners is
core for developing ITSP [9]. Furthermore, investigating other
factors such as industry landscape, competitor profiles,
business models, revenue stream, and internal-external forces

will help ITSP developers to comprehend the dynamic nature
of business environment where the enterprise operates. This
information is very crucial to be collected as strategic inputs
for any further decision in defining and determing many
components in ITSP.

B. Stage 2: Defining Business Requirements
Based on the results of previous stage, business

requirements are defined. There are many instruments that can
be used to help ITSP developers in defining enterprise needs,
such as: value proposition, pain points, business opportunities,
industry trend, cost-benefit analysis, benchmarking, and best
practices [10][11]. By undergoing this activity, enterprise
special needs that should be supported by information
technology can be clearly mapped.

C. Stage 3: Determining IT Target Capabilities
By taking into consideration the business requirements that

have been defined, a holistic and systemic enterprise
architecture should be developed. The activity is started by
developing business architecture, followed by information
system architecture – which consists of data architecture and
application architecture [5][6]. After these three architectures
have been determined, a technology architecture should be
designed. As several practitioners suggest, two more types of
architecture can be developed, which are: people architecture
and governance architecture [12][13]. This enterprise
architecture is developed after ITSP developer study about
information technology trend, cost-benefit analysis, and
capability measurement.

D. Stage 4: Assessing Existing IT Performance
Knowing the current information technology capability and

performance is significantly important to help identifying the
issues and real problems faced by the enterprise. It is also
mandatory for ITSP developer to picturise the whole
technoology facilities and installation in the form of enterprise
architecture as mention earlier in the previous stage.
Conducting information technology audit is one effective
approach that can be undergone by the enterprise to get detail
information about existing information technology
performance [4][14].

E. Stage 5: Conducting Gap Analysis
Gap between enterprise expectation (future state) and

existing information technology performance (current state)
which are described in Stage 3 and Stage 4 should be well
analysed. All components of business, data/information,
application, technology, people, and policy/governance should
be compared side-by-side to show the gap exposure between
“To-Be” and “As-Is” environment [3]. Based on these gaps,
various business and information technology initiatives are
being defined and proposed. For every gap, IT developer
should select and decide an optimum solution scenario to be
undergone.

F. Stage 6: Developing IT Initiatives and Projects
In this stage, all initiatives that have been defined and

proposed in earlier Stage 5 are clustered based on its nature and
relationshiops [15]. A projects portfolio of application
development, database construction, network infrastructure
installation, organisation structure formation, and policy
development is determined. For every project, a detail charter
should be developed, consisting the information of project title,
scope, objectives, duration/time, estimated cost, people
involved, risk, quality, and procurement method [16][17].

G. Stage 7: Communicating the Development Roadmap
This last stage is proposed to be conducted to ensure key

stakeholders buy-in with regards to the ITSP being developed
[18]. It starts by forming special task force who has main
responsible to communicate the plan throughout enterprsie.
This group of people will create marketing tools and determine
campaign strategy to be implemented for the purpose of

communicating the roadmap of information technology
development [19].

V. CONCLUSION
As an official document, ITSP is being developed in-line

with business needs. Every information technology should be
considered as business project, because both concepts are
aligned to each other. Adopting enterprise architecture
approach within ITSP will help the business and information
technology practitioners to picturise the demand and the supply
of information technology ecosystem that are expected (To-Be)
and existed (As-Is). It supports the principle stating that
“something that can not be described, can not be developed”.
Understanding that ITSP is a living document required to be
revised periodically is also important to ensure that such plan is
still relevant and contextual with dynamic change.

REFERENCES
[1] ISACA. “COBIT and the IT Governance Institute.” Executive’s Guide to

IT Governance, (2013), 67-86. doi:10.1002/9781118540176.ch5.
[2] Newkirk, Henry E., Albert L. Lederer, and Cidambi Srinivasan.

“Strategic information systems planning: too little or too much?” The
Journal of Strategic Information Systems 12, no. 3 (2003), 201-228.
doi:10.1016/j.jsis.2003.09.001.

[3] Lai, Linda S. “An Expectation-Perception Gap Analysis of Information
Systems Failure.” Methodologies for Developing and Managing
Emerging Technology Based Information Systems, 1999, 130-141.
doi:10.1007/978-1-4471-3629-3_12.

[4] Wu, Ming-chuan. “Continuous Evaluation of Information System
Development.” Integrated Series in Information Systems (n.d.), 179-207.
doi:10.1007/978-0-387-46364-3_7.

[5] Desfray, Philippe, and Gilbert Raymond. “The Components of TOGAF
Architecture.” Modeling Enterprise Architecture with TOGAF, 2014,
41-55. doi:10.1016/b978-0-12-419984-2.00003-3.

[6] Tambo, Torben. “Enterprise Architecture beyond the Enterprise –
Extended Enterprise Architecture Revisited.” Proceedings of the 19th
International Conference on Enterprise Information Systems, 2017.
doi:10.5220/0006277103810390.

[7] Abu-Taieh, Evon M., Asim A. El Sheikh, and Jeihan M. Abu-Tayeh.
“Challenges in Implementing Information Technology Plan.” Strategic
Information Technology and Portfolio Management (n.d.), 250-259.
doi:10.4018/978-1-59904-687-7.ch013.

[8] “The enterprise environment and the entrepreneurial response.”
Enterprise: Entrepreneurship and Innovation, 2006, 177-211.
doi:10.1016/b978-0-7506-6920-7.50012-4.

[9] Gorman, G. “The External Environment of Business.” Business Studies
A Level, 1992, 208-224. doi:10.1007/978-1-349-13846-3_13.

[10] Al kalbani, Asma, and Kinh Nguyen. “Designing flexible business
information system for modern-day business requirement changes.”
2010 2nd International Conference on Software Technology and
Engineering, 2010. doi:10.1109/icste.2010.5608774.

[11] Binjaku, Aurora, Tamara Luarasi, and Hysen Binjaku. “The Information
Technology and Business Requirement Evolution.” Academic Journal of
Interdisciplinary Studies, 2013. doi:10.5901/ajis.2013.v2n3p55.

[12] Coopey, Richard. “Information Technology Policy: Competing for the
Future.” Information Technology Policy, 2004, 1-22.
doi:10.1093/acprof:oso/9780199241057.003.0001.

[13] Gazendam, Henk W. “Semiotics, Virtual Organisations, and Information
Systems.” Information, Organisation and Technology, 2001, 1-48.
doi:10.1007/978-1-4615-1655-2_1.

[14] Pankowska, Malgorzata. “Information System Audit for Investment
Decision.” Contemporary Trends in Systems Development, 2001, 257-
268. doi:10.1007/978-1-4615-1341-4_22.

[15] Parry, Vincent K., and Mary L. Lind. “Alignment of Business Strategy
and Information Technology Considering Information Technology
Governance, Project Portfolio Control, and Risk Management.”
International Journal of Information Technology Project Management 7,
no. 4 (2016), 21-37. doi:10.4018/ijitpm.2016100102.

[16] Lientz, Bennet P. “Project management methodologies.” Information
Technology Project Management, 2011, 20-38. doi:10.1007/978-0-230-
34500-3_2.

[17] Hannach, Driss E., Rabia Marghoubi, and Mohamed Dahchour. “Project
portfolio management Towards a new project prioritization process.”
2016 International Conference on Information Technology for

Organizations Development (IT4OD), 2016.
doi:10.1109/it4od.2016.7479281.

[18] Huijgens, Hennie, Arie Van Deursen, and Rini Van Solingen. “The
effects of perceived value and stakeholder satisfaction on software
project impact.” Information and Software Technology 89 (2017), 19-
36. doi:10.1016/j.infsof.2017.04.008.

[19] Kirchmer, Mathias. “Information Technology Enabling Process
Execution with MPE.” High Performance Through Process Excellence,
2011, 37-53. doi:10.1007/978-3-642-21165-2_3.

Industrial Technology Roadmap as a Decision Making Tool

to Support Public R&D Planning

Yonghee Cho1, Seong-Pil Yoon2, Karp-Soo Kim3, Boyoung Chang4

1Department of Engineering and Technology Management, Portland State University, OR – USA
2Graduate School of Energy and Environment, Seoul National University of Science & Technology, Seoul, South Korea

3Graduate School of Innovation and Technology Management, Korea Advanced Institute
of Science and Technology(KAIST), Daejeon, South Korea

4Korea Institute for the Advancement of Technology, Korea Technology Center, Seoul, South Korea

Abstract–There are a variety of methodologies to forecast

future technology, economy, and society. Technology roadmap
(TRM) is one of the easily implementable methods of technology
forecasting. It is a strategic management tool to support R&D
planning and new product development at various levels such as
a firm and government. This study aims to address a strategic
decision making tool in public R&D programs to affect firms’
strategic behavior under this umbrella. The main purpose of this
paper is to address evolutionary aspects of industrial technology
roadmap and provide a more advanced framework of public
R&D planning.

In South Korea, technology roadmapping has been initiated
by government since 2000 and nowadays popularized in small
and medium-sized companies as well. Despite of its popularity,
there are only a few literatures to provide practical guidelines
and systematic process to develop TRM applicable to R&D
planning in any organizations. The framework of industrial
technology roadmap developed by the Korea Institute for the
Advancement of Technology which is established bringing
together old 6 major government agencies such as Korea
Industrial Technology Foundation, Korea Technology Transfer
Center, Korea Institute of Industrial Technology Evaluation and
Planning, Institute for Information Technology Advancement,
Korea Material and Components Industrial Agency, Korea
National Cleaner Production Center, Korea Institute of Design
Promotion, can be applied to the R&D planning process of
diverse government R&D programs in other countries.

The proposed framework can be applied and modified to the
R&D planning process in any organizations. The study deals
with a variety of industries, having different characteristics, and
proposed similar technology roadmap. Consequently, this paper
attempts to articulate establishing firms’ R&D and business
strategy, accompanying with government R&D programs and
setting priorities among R&D projects.

I. INTRODUCTION

In most cases, technology forecasting is wrong.

Technology forecasting, however, is valuable to give
guidance for the direction of promising technology
development. The value of technology forecasting lies in its
usefulness for making better decisions, not in its coming
true [1]. Technology forecasting, in other words, typically
partially correct and cannot include all exact future forms.
Technology forecasting strives not only to identify research
and knowledge gaps to find the right path to reach goals,
but to search ranges of environment that will be
encountered in the future.

Technology forecasting attempts to reveal a specific
characteristic or an attribute of technology over designated
time. Joseph Martino defines technology forecasting as “a
prediction of the future characteristics of useful machines,
procedures or techniques” [1]. In the 1950s and 1960s,
Technology Forecasting (TF) was driven by military
competition with the Soviet Union. TF was initiated
primarily as a tool to help anticipate military technology
needs and to help plan and prioritize R&D and systems
development [2]. Hal Linstone wrote that technology
forecasting (TF) seems to have peaked around 1970 with a
decline in methodological advance thereafter [3]. In
historical perspective, the use of TF methods is summarized
below figure 1.

The corporate has made its efforts on environmental
scanning such as bibliometric/patent trend analysis and
market analysis to indentify increasingly diversified needs
of customers, in order to establish a steady grasp of
technology initiatives as well as to improve its future
position. In addition, a company should set up R&D
strategy in alignment with business strategy such as
manufacturing, sales and marketing, personnel, finance, and
accounting. Most organizations have investigated major
breakthrough technologies, core technology improvements,
and state-of-the-art defining technologies. Technology
forecasting tool for decision making is more necessarily
needed to predict future technology trend than ever before.

A variety of technology forecasting methods have been
developed and applied to various industries, organization by
diverse purposes. But in the last four decades, especially
after the widespread availability of Information Technology,
some of the different approaches using much information
like patents, journals, and research awards, have been
continuously developed by different researchers combing
with many other tools.

Technology roadmapping which the study focus is an
effective tool for technology planning and communication
which fits within a broader set of business planning
[36][37]. Technology roadmaps in the corporate setting are
used to define the plan for the evolution of a product,
linking business strategy to the evolution of the product
features and costs to the technologies needed to achieve the
strategic objective [38]. There must be a linkage between
the technology investment decisions and the business
requirements [39]. Roadmapping is implemented to grasp a

2986

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

Fig. 1. The Chronological Tree of Technology Forecasting techniques [4].

TABLE 1. TECHNOLOGY FORECASTING TOOLS

Approach Techniques References

Environmental Scanning

– bibliometric analysis
– patent landscape analysis, patent alert system, fuzzy-based

clustering
– data mining, text mining, database tomography, tech mining

[5][6][7][8]
[9][10][11]
[12][13][14]
[15][16][17]

Stochastic forecasting – probabilistic trends and time lags [18]
Trend Extrapolation – multiple regression, multivariate regression, etc [1][19]

Measure of Technology – scoring model, technology frontier [1][20][21]
Time Series Analysis – AR, MA, ARIMA [8][19][22]

Growth Curves (S-curves) – pearl, logistics, gompertz fisher-pry, bass diffusion model, and life cycle analysis [1][23]

Modeling and Simulation – system dynamics, agent-based models [8][24]

Expert Judgmental Forecasting – Delphi, survey, FGI, role playing, AHP, analogy model, scenario planning, technology roadmapping, etc

[1][18] [19]
[25][26][27]
[28][29][30]
[31]

Normative Method – relevance tree, morphological analysis, backcasting, mission flow diagram
[1][32][33]
[34][35]

stronger awareness of how to serve potential and current
market with the right product features at the right time to
improve the cross-functional cooperation required
integrating technology, product and market drivers for the
new product and service creation in terms of customer
requirements [40]. Company must generate an effective

technology planning aligning with business plan to identify
and develop the technologies required to meet its
customer’s future needs.

In 1987, Motorola published its own technology
roadmap as a planning tool to position themselves and their
product better in the market, with the communication

2987

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

between design & development engineers and marketing
personnel which technologies will be required in future
products. The Motorola’s roadmap is an example of a single
layer roadmap, focusing on the technological
evolution associated with a product and it’s
features [41]. Since TRM’s inception more than 25 years
ago [42], Technology Roadmapping can provide quite a bit
implementable tool to align technology strategy with
business strategy, providing a structured framework to
address three key questions: Where do a company want to
go?, Where is a company now?, and How can a company
get its target? [43] Technology roadmapping has gained
significant and subsequent acceptance within
corporations[38][40][41][44], across
industries[45][46][47][48], and national foresights [49].
The development of roadmapping has been largely driven
by practice within companies, government agencies and
consulting firms [50]. In addition, there have been various
studies to broaden application of TRM with other strategic
viewpoint [51]. (See Table 2.)

In case of South Korea, most of government R&D
programs are designed to take part in firms, academia and
government-funded national laboratories. Especially, small
and medium sized firms are proactively engaged in
government R&D projects to acquire R&D funding to
develop their technology and products. In such a context
technology roadmapping provides a decision making tool to
allocate public R&D funding. This paper proposes
evolutionary roadmapping processes to effectively
implement public R&D planning. These processes mainly
developed by KIAT (Korea Institute for the Advancement
of Technology) are expected to provide strategic decision
making tool to effectively help improve the overall R&D
performance and quality in public R&D investment at the
end.

II. THE EVOLUTION OF INDUSTRIAL TECHNOLOGY
ROADMAPPING

Since Sept. 2000, MOTIE (Ministry of Trade, Industry,

and Energy) has initiated a project to develop the industrial
TRM almost annually in South Korea. Since 2001, for
about 4 years, KOTEF (Korea Industrial Technology
Foundation) had been trying to set up the process of
industrial technology roadmap. Each incremental change of
processes has added up, subsequently, the management
system of industrial technology roadmapping has been
established. Technology planning is a deliberate and
delicate task requiring a scientific and methodological
design. The industrial TRM has played a compass role in
technology planning in complex and turbulent
environments. It has been utilized as an effective tool for
the government to allocate R&D resources efficiently and
for participants to share the information and promote
cooperative research among them. Industrial TRM aims to
support industry and a wider community of technology
management by providing focused domains for practical
R&D and a forum to promote productive discussions
among industry-academic-national laboratory entities.

The evolutionary phases of industrial TRM can fall into
two parts with retrospective. The earlier phase of TRM is
summarized below Fig. 2. At this phase, the framework of
industrial TRM has been tested, established and expanded
to the integration of other methodologies, cooperation with
other organizations and dealt with other crucial subject
matter such as international cooperation, R&D
infrastructure, IPR(Intellectual Property Right), Standards,
and Regional Innovation Policy. Specially, at the 5th stage,
industrial TRM was used as a strategic planning tool to
forecast future needs and develop pictures of future vision,
specifically home, industry, and city areas, induced from
new emerging technology development of 19 different
sectors in 2015.

TABLE 2. THE APPLICATIONS OF TECHNOLOGY ROADMAP TECHNIQUE

TRM applications Characteristics Reference
TRM incorporate disruptive technology  identify potential disruptive technologies and products

explaining that disruptive technology roadmapping process is
different from that of sustaining technology

[52][53][54][55]
[56]
(2004)

TRM incorporate supply chain
management

 reduce investment uncertainty through shared information within
an integrated supply chain

[57][58][59]
(2002)

TRM incorporate service strategy  integrate more sophisticated service functions to the
conventional products and systems, bridging Gaps in service
operations

[60] [61]
(2006)

TRM incorporate new product
development

 propose heuristic approach combining technology roadmapping,
information technology (IT) and supply chain management to
make more sustainable new product development decisions

[57]
(2004)

TRM integrate with scenario planning  combine scenario planning with technology roadmapping to
mitigate limitations both have, generate multi-scenario
roadmapping

[62][63]
(2004)

TRM incorporate business model  combine business modelling to create new business value and
strategic roadmapping method

[64]
(2009)

TRM incorporate knowledge management  deal with knowledge management actions upward to business
objectives and strategies and downwards to specific knowledge
assets

[65][66][67]
(1998)

2988

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

Fig. 2. The 1st phase of Industrial TRM 2000-2007

Fig. 3. The 2nd phase of Industrial TRM 2008-2011

The 2nd phase of industrial TRM is illustrated in Fig. 3. At
this phase, industrial TRM has been much more associated
with specific R&D programs or projects by providing a
framework for R&D planning and coordinating R&D efforts
with operational requirements. It also presents a development
plan to meet future needs and fill the technological gaps and
opportunities identified in the process.

At each stage, research results were given an objective
assurance through inspections by a review committee, a
series of workshops and public hearing (on and off) with
various experts and interest groups to ensure the balance of
expertise and viewpoints. Roadmapping committees are
staffed by a mixture of different backgrounds from industry,
government, and academia. For example, from April 2006 to
Feb. 2007, about 522 experts from industries, academia and

research institutes participated and developed industrial
Technology Roadmaps in 19 industrial sectors. Industrial
TRM in 19 domains was open to the public on Mar. 2007. 9
areas of them were regarded as key fields in the economic
growth of South Korea. Among them, 7 areas were related to
the main basic industries of South Korea, such as
semiconductor, automotive, and etc; the others to the future
strategic industries like nano technology, bio technology and
cognitive robot. In 2007, Industrial TRM and Future Vision
2015 proposed images of future of 19 different sectors in
2015, eliciting practical application tools and technologies by
the megatrends of our society such as globalization, multi-
polar economy, climate change, socio-demographic change,
changing customer needs and new emerging technologies in
global surroundings. Not only did it support technology

2989

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

strategy and planning at the national level, but it linked
market opportunities to product and technology development
at the firm level.

Industrial TRM has been employed as a decision making
tool to support public R&D planning and technology
forecasting. It helps to forecast technology trend and industry
trend based on expert decisions as well as quantitative data
such as market trend data, patents, and literatures.
Technology roadmap is used as a market needs-driven R&D
planning process to help identify, select, and develop
technology alternatives that satisfy a set of product needs.
Korean governments, firms, academia and industrial
consortia utilize industrial technology roadmaps to explore
the dynamic linkages among the changing environment,
organizational strategies, and technological resources.

III. THE FRAMEWORK OF INDUSTRIAL
TECHNOLOGY ROADMAPPING

The framework of industrial TRM has been standardized

and established for a decade, designed to support overall and
specific R&D programs. Industrial TRM needs a lot of efforts
to determine industry and technology areas to focus on.
Especially, identifying emerging technologies and setting
R&D development targets in each technology area requires
much more sophisticated tools such as gap analysis, portfolio
analysis, literatures and patent data mining and expert
decisions. To fulfill R&D planning, STEEP (social,
technological, economic, environmental and political) trends
and needs should be investigated along with evaluating

current technology capabilities compared to its competitor’s
in each field. The process of industrial TRM consists of three
stages: preparation stage, roadmapping and follow-up stage.

A. Preparation stage

At this stage, decision-makers discuss and reach a
consensus regarding areas that TRMs are necessarily
developed in order to resolve current issues that society
faces. Consensus is very crucial and required for TRM to be
consecutively maintained and alive.

Preliminary Planning

Determining relevant areas and methodologies requires
great efforts and elaborate works to be done in view of
TRM project management. A TRM team is formed, the
framework of TRM is designed, and a roadmapping
schedule is organized. After a number of discussions on the
methods used in technology roadmapping, a series of peer
reviews and the Delphi method is typically selected. This
process is performed through a survey of thousands of
experts, consensus-building among the external advisory
group, and consulting with related government officials.
Internal team meetings to set up the framework of industrial
TRM usually are held over 10 times.

To develop industrial TRMs, KIAT organize
committees with various experts from academia, firms,
national research labs and government. Committees are one
of the most significant elements for the success of industrial

Fig. 4. The overall process of industrial TRM

2990

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

TRM, since the future demands and needs, target products
and emerging technologies can only be identified through
discussion among them due to extremely high uncertainty.
Consequently, steering committee, operational committee
and supporting group should be carefully selected in each
technology field for the benefit of TRM. Above all,
industry must play a proactive role in the industrial TRM
process, in order to be an industry-led TRM along with
taking into account of consumers and suppliers. Finally,
such issues inherent in peer review system like the ‘old
boys’ network to protect established fields and leniency
effect should be eliminated.

B. Roadmapping stage

It includes all activities associated with industrial TRMs.
Roadmapping process is described in figure 1.
a. Select subjects of TRM
b. Identify major experts in each area
c. Determine decision criteria and clarify roadmap

procedure
d. Select committee
e. Plan workshop for roadmapping in each field
f. Confirm necessary information with respect to TRM
g. Open workshop for roadmapping in each field

• 50% participants consists of experts from industry
• All interested group (Academia, Research Institute,

Consumer, and Company) should be involved
• All participants must have expertise about the

selected area so that they may contribute to the
workshop

h. Sum up workshop reports.
i. Consist of subcommittee to prepare the first draft of

TRM
j. Develop the first draft Roadmap
k. Take feedbacks after circulating the first draft Roadmap
l. Consolidate TRM with additional evaluations and

comments from industry
m. Establish and execute attainable plans.

There are major 7 steps(4~10) of workshops not simply

to provide blueprints of technology development, but to
allocate public R&D investment with the assistance of
experts and knowledge clustering. Furthermore, there were
2~3 small group meetings between 7 steps of workshops.

Visioning and Integration Workshop

TRM project management team must develop the
images of future through workshops, even though it is
recommended that visioning & integration workshop should
be comprised of CEO, technology forecasting expert and
developer of a long term vision. Images of future vision
should be developed with the help of working committee,
via internet and relevant forecasting sources like picture of
future from Siemens, due to the lack of experience as well
as no expertise of selected technologies.

Portfolio analysis
Technology areas are determined by the following

criteria along with the help of experts;
• Can we make commercialized products which meet the

future needs?
• Can it gain access to a niche market?
• Can it achieve world-class competitiveness in a short

time?

While TRM presents a series of milestones to attain the
object of technology development, the portfolio analysis
clearly proposes the priorities of investment related to
various technologies identified by TRM. Decision criteria
includes global market size, strategic importance, market
and technology trends, technology importance, relatively
technology position, potential competitive advantage, and
synergy effects on both economy and industries.

In portfolio analysis, the X-axis indicates the
technological maturity which depends on the possibility of
taking out a patent and the degree of concentration of core
technologies. It is affected by the investment plan and
outcome relevant to a specific technology. Meanwhile, the
Y-axis indicates the technological importance that means
the relative potential in creating value and the value-added
level of a specific technology. It is mainly affected by the
current status of relevant technologies in a technological
life cycle. The concept of each domain of technical
portfolio is described in following figure 4.

Final report of TRM

Following the submission of the final reports from each
working committee, TRM project team critically analyze
them and sum up a synthesis report, which included the
review of the process, a summary of each working committee
report in a coherent format, along with the analysis of
findings and recommendations of the external experts.

C. Follow-up stage

TRM should be reviewed and updated periodically in
order to keep it alive. Follow-up step justifies TRM,
reevaluates, updates and develops feasible plans with respect
to all post activities. This procedure is necessary but,
generally a little bit hard to follow this step.

IV. THE ORGANIZATIONAL PERSPECTIVE ON
INDUSTRIAL TRM

Effectively organizing expert committees is one of the

significant elements for high-quality TRM, because TRM
highly depends upon the commitment of expert committees.
Consequently, it is very important whether TRM team might
select appropriate experts in a committee, especially a
competent person from each relevant association, research
institutes and firms. Furthermore, the quality of TRM belongs
to the facilitator’s management skill of committee. In
committee, some experts should have knowledge and

2991

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

Hi g h

Hi g hLo w

•• Adopting Phase TechnologyAdopting Phase Technology
(Challenging Development)(Challenging Development)

— High in valueHigh in value–added, technology risk, added, technology risk,
and uncertainty in product market and uncertainty in product market
needs/product cycleneeds/product cycle

DrawDraw

•• Growth Phase TechnologyGrowth Phase Technology
(R&D Investment)(R&D Investment)

— High in valueHigh in value–addedadded

— A possibility of new market needs A possibility of new market needs
created by technology innovationcreated by technology innovation

Bet Bet

•• Declining Phase TechnologyDeclining Phase Technology
(Abandoned/Reduction)(Abandoned/Reduction)

— Current market is formed but low Current market is formed but low
technology is appliedtechnology is applied

•• PostPost–Growth technologyGrowth technology
(Maintenance/Preservation)(Maintenance/Preservation)

— Reduction in technology importance Reduction in technology importance
as resource technology development as resource technology development
is completed and production is is completed and production is
progressed progressed

FoldFold Cash InCash In

TechnologicalTechnological
MaturityMaturity

TechnologicalTechnological
ImportanceImportance

Fig. 5. Quadrants of portfolio analysis

Fig. 6. The structure of expert committees of industrial TRM

experience in terms of technology roadmapping. These skills
cover leading people in a committee. They can be other
project managers in technology roadmapping.

In constructing industrial TRM, there are various sub-
groups to interact such as steering committee, working
committee, policy council, IP analysis team, and review panel,
as following figure 5 illustrate. It requires the advanced
management skill of a number of work packages such as
communication, interaction, cooperation, and etc.

Steering Committee

‘Steering Committee(SC)’ serves as a final decision
maker in TRM process. It consists of about 20 experts such
that about 12 members of it come from industry, 6 people

have interdisciplinary backgrounds like in economics or
management, a government official, and a director from the
MOTIE. It prioritizes industry sectors or technology domains
to be focused on and gives some advice on overall technology
roadmapping. From our long experience, the appropriate size
of SC should be around 9~13 for high quality of TRM.

Working Committee

‘Working Committee(WC)’ plays a major role in
technology roadmapping, prioritizing candidate items through
portfolio analysis, selecting criteria such as global market
size and strategic importance, investigating market and
technology trends, potential competitive advantage, and
synergy effects on both overall economy and each relevant

2992

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

industry. WC identifies core technologies and products from
subcommittees in every target domain and develops TRM.
3~4 subcommittees are required to deal with much more
concrete R&D planning in WC. The output of subcommittee
is finally reviewed by the chairperson of WC. Half of WC
comes from each relevant industry, 4 people from academia,
3 members from research institute, a government official, a
facilitator from KIAT and etc. In total, it consists of about 17
experts. A government official in WC usually serves as an
observer rather than as a secretary for the group. In addition,
relevant associations should take part in WC, since it also
have ownership of each industrial TRM. The proactive
involvement and cooperation with industry association is
very significant for technology roadmapping to be successful.
Subsequently, it needs motivation and incentive to establish
the complete TRM development process. We recommend that
the wisdom of it be communication.

IP Analysis

The protection of intellectual property rights (IPRs) has
become an increasingly important issue in multilateral trade
negotiations. In the midst of technology roadmapping, the
strategy of IPRs should be developed simultaneously, through
the participation of KIPO 1 (Korean Intellectual Property
Office)’s officials and experts of each sector from
KIPI(Korea Institute of Patent Information) for IP
information analysis. Patent information is mainly used to
monitor competitors for the development of R&D planning.
They analyze global and local IP trend of targeted items with
the assistance of WC.

Policy Council

‘Policy Council’ is involved in challenges of
infrastructure such as regional innovation, international
cooperation, standardization, intellectual property. Specific
organizations with requisite expertise should participate to
develop a technically credible TRM in each domain. It
requires strong cooperation between these organizations.

V. CONCLUSIONS AND RECOMMENDATIONS

Conclusions

In South Korea, the industrial technology roadmap has
been popularized in the aspect that it attempts to construct
each TRM at industry level, but had limit because this
roadmap had some broad concept and development plan in
the scope of roadmapping, and it did not have any
information in terms of collaborators or sponsors who can
play a major role in the development, acquisition and
operation of technology identified in TRM. Hereafter,
industrial TRM has evolved to R&D planning tool to directly
link specific R&D programs or projects to overcome this kind
of weakness. In addition, it has evolved to have much more

1
KIPO is a major government body in charge of intellectual property iss

ues in South Korea

comprehensive description about why, when, and for whom
the emerging technology is necessary and what consequential
losses may follow if the technology cannot be developed.

In organizational perspective, industrial TRM has been
trying to diversify the alternative solutions through adding
non-technological elements as well as alternative scenarios
by policy council. Industrial TRM necessarily introduce the
availability of identified technologies, which means where,
by whom, how and how much the technology is used right
now. It also addresses the scope of technology application,
whether it can be applied to another industry or not.

Recommendations

There are several critical factors that have to be
considered for the benefit of industrial TRM. Although
developing industrial TRM in itself is significant for political
issues, after that R&D investment plans of government are to
be given with a concrete form and carried out. It enables
TRM much more valuable to stakeholders. Second, cost-
benefit analysis has to be supplemented. In TRM’s activities,
cost is easily calculated including all the expenses to be paid
for the development, acquisition and operation of the
technology. On the other hand, the benefit might be evaluated
as the demand estimated in the market where the technology
is supposed to be.

To accomplish roadmapping successfully, government
should fill the gaps identified in roadmapping process.
Government must play a role of promoter or catalyst by
active participation in a committee. To promote the
development of TRM, it is better way for government to
select target areas of TRM. Moreover, government has to
maintain transparency and objectivity in constructing TRM.
Lastly, government should support sufficient funds and
allocate enough time like over 12 months and within 15
months to effectively develop industrial TRM.

As it is recommended that technology roadmapping be
substantially led by industry [68], industrial TRM also has a
general guidance on that industry should lead roadmapping
process with around 50% participation of experts from
industry in a committee. Finally, it would be more efficient
and worthwhile for industry associations to develop their own
technology roadmapping process. It is clear that much is yet
to be learnt about the structure and development of TRM.
Nonetheless, the framework of industrial TRM presents rich
findings of public R&D planning obtained from Korean cases
over a decade.

REFERENCES

[1] J. P. Martino, Techology Forecasting for Decision Making, vol. 3rd

Editio. McGraw-Hill, Inc., 1993.
[2] A. L. Porter, “Technology Forecasting: An Empirical Perspective,”

Technol. Forecast. Soc. Change, vol. 28, pp. 19–28, 1999.
[3] V. Coates, M. Farooque, R. Klavans, K. Lapid, H. A. Linstone, C.

Pistorius, and A. L. Porter, “On the Future of Technological
Forecasting,” Technol. Forecast. Soc. Change, vol. 67, no. 1, pp. 1–17,
2001.

2993

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

[4] Y. Cho, “Investigating the Merge of Exploratory and Normative
Technology Forecasting Methods,” in PICMET ’13: Technology
Management for Emerging Technologies, 2013, pp. 2083–2092.

[5] A. L. Porter and M. J. Detampel, “Technology Opportunities
Analysis,” Technol. Forecast. Soc. Change, vol. 49, pp. 237–255, 1995.

[6] T. Dereli and A. Durmusoglu, “A trend-based patent alert system for
technology watch,” J. Sci. Ind. Res. (India)., vol. 68, pp. 674–679, 2009.

[7] T. Dereli and A. Durmusoglu, “Classifying technology patents to
identify trends: Applying a fuzzy-based clustering approach in the
Turkish textile industry,” Technol. Soc., vol. 31, no. 3, pp. 263–272,
Aug. 2009.

[8] S. M. Millett and E. J. Honton, A Manager’s Guide to Technology
Forecasting and Strategy Analysis Methods. Columbus, Ohio: Battelle
Press, 1991.

[9] D. J. de S. Price, “Networks of Scientific Papers,” Science (80-. )., vol.
149, no. 3683, pp. 510–515, 1965.

[10] M. Callon, J.-P. Courtial, and W. A. Turner, “PROXAN: A Visual
Display Technique for Scientific and Technical Problem Networks.”
Second Workshop on the Measurement of R&D Output, Paris, France,
1979.

[11] P. Ellis, G. Hepburn, and C. Oppenheim, “Studies on patent citation
networks,” J. Doc., vol. 34, no. 1, pp. 12–20, 1978.

[12] M. Callon, Pinpointing industrial invention: An exploration of
quantitative methods for the analysis of patents: in Mapping the
dynamics of science and technology. London: Macmillan Press Ltd.,
1986.

[13] W. J. Frawley, G. Piatetsky-shapiro, and C. J. Matheus, Knowledge
Discovery in Databases: An Overview. in Knowledge Discovery in
Databases. MIT Press, 1991, pp. 1–27.

[14] R. Kostoff, “Database tomography: multidisciplinary research thrusts
from co-word analysis,” in Portland International Conference on
Management of Engineering and Technology, 1991, pp. 27–31.

[15] R. Kostoff, “Database tomography: Origins and duplications,” Compet.
Intell. Rev., vol. 5, 1994.

[16] R. Feldman and I. Dagan, “KDT – knowledge discovery in texts,” in the
First International Conference on Knowledge Discovery from
Databases, 1995.

[17] S. W. Cunningham, A. L. Porter, and N. C. Newman, “Special issue on
tech mining,” Technol. Forecast. Soc. Change, vol. 73, no. 8, pp. 915–
922, Oct. 2006.

[18] J. P. Martino, “A review of selected recent advances in technological
forecasting,” Technol. Forecast. Soc. Change, vol. 70, no. 8, pp. 719–
733, Oct. 2003.

[19] R. C. J. Lenz, “Technological Forecasting,” US Air Force, Cameron
station, Alexandria, Virginia, 1962.

[20] W. E. Souder, “A Scoring Methodology for Assessing the Suitability of
Management Science Models,” Manage. Sci., vol. 18, no. 10, 1972.

[21] T. Anderson, K. Hollingsworth, and O. L. Inman, “Assessing the rate
of change in the enterprise database system market over time using
DEA,” PICMET ’01. Portl. Int. Conf. Manag. Eng. Technol. Proc.
Vol.1 B. Summ. (IEEE Cat. No.01CH37199), pp. 384–390, 2001.

[22] R. Bradfield, G. Wright, G. Burt, G. Cairns, and K. Van Der Heijden,
“The origins and evolution of scenario techniques in long range
business planning,” Futures, vol. 37, no. 8, pp. 795–812, Oct. 2005.

[23] T. B. Robertson, The Chemical Basis of Growth and Senescenc.
Philadelphia and London: J. B. Lippincott Company, 1923.

[24] L. F. Luna-Reyes and D. L. Andersen, “Collecting and analyzing
qualitative data for system dynamics: methods and models,” Syst. Dyn.
Rev., vol. 19, no. 4, pp. 271–296, 2003.

[25] J. P. Martino, “Thirty Years of Change and Stability,” Technol.
Forecast., vol. 18, pp. 13–18, 1999.

[26] T. F. A. M. W. Group, “Technology futures analysis: Toward
integration of the field and new methods,” Technol. Forecast. Soc.
Change, vol. 71, no. 3, pp. 287–303, Mar. 2004.

[27] T. Daim, G. Rueda, H. Martin, and P. Gerdsri, “Forecasting emerging
technologies: Use of bibliometrics and patent analysis,” Technol.
Forecast. Soc. Change, vol. 73, no. 8, pp. 981–1012, Oct. 2006.

[28] W. R. Huss and E. J. Honton, “Scenario Planning- What Style Should
You Use ?,” Long Range Plann., vol. 20, no. 4, pp. 21–29, 1987.

[29] T. L. Saaty, The Analytic Hierarchy Process. McGraw-Hill, Inc., 1980.

[30] T. L. Saaty, “A scaling method for priorities in Hierarchical
Structures,” J. Math. Psychol., vol. 15, pp. 234–281, 1977.

[31] T. A. Kappel, “Perspectives on roadmaps: how organizations talk about
the future,” J. Prod. Innov. Manag., vol. 18, no. 1, pp. 39–50, Jan. 2001.

[32] E. Jantsch, Technological Forecasting In Perspective: A Framework
for Technological Forecasting, its Techniques and Organization. 1967.

[33] G. J. Wissema, “Morphological Analysis: Its application to a company
TF investigation,” Futures, pp. 146–153, 1976.

[34] J. B. Robinson, “Energy backcasting: A proposed method of policy
analysis,” Energy Policy, vol. 10, pp. 337–344, 1982.

[35] J. Quist and P. J. Vergragt, “Backcasting for Industrial Transformations
and System Innovations towards Sustainability : is it useful for
Governance ?,” in the 2003 Berlin Conference on the Human
Dimensions of Global Environmental Change, 2003, no. December, pp.
1–26.

[36] O. H. Bray and M. L. Garcia, “Technology roadmapping: the
integration of strategic and technology planning for competitiveness,”
Innovation in Technology Management. The Key to Global Leadership.
PICMET ’97. IEEE, pp. 25–28, 1997.

[37] R. Phaal, C. Farrukh, and D. Probert, “Technology Roadmapping:
linking technology resources to business objectives,” Univ. Cambridge,
pp. 1–18, 2001.

[38] R. E. Albright and T. A. Kappel, “Technology roadmapping :
Roadmapping the corporation,” Res. Technol. Manag., p. 31, 2003.

[39] M. L. Garcia and O. H. Bray, “Fundamentals of Technology
Roadmapping,” Sandia Natl. Lab., 1997.

[40] P. Groenveld, “Roadmapping integrates business and technology,” Res.
Technol. Manag., vol. 40, no. 5, pp. 48–55, 1997.

[41] C. H. Willyard and C. W. McClees, “Motorola’s Technology Roadmap
Process,” Res. Manage., pp. 13–19, 1987.

[42] R. Phaal, C. Farrukh, and D. Probert, “Developing a technology
roadmapping system,” Ieee, Cambridge, UK, 2005.

[43] R. Phaal and G. Muller, “An architectural framework for roadmapping:
Towards visual strategy,” Technol. Forecast. Soc. Change, vol. 76, no.
1, pp. 39–49, Jan. 2009.

[44] D. Barker and D. J. H. Smith, “Technology foresight using roadmaps,”
Long Range Plann., vol. 28, no. 2, pp. 21–28, Apr. 1995.

[45] L. Baldi, “Industry roadmaps: The challenge of complexity,”
Microelectron. Eng., vol. 34, no. 1, pp. 9–26, Dec. 1996.

[46] A. Jager-Waldau, “R&D roadmap for PV,” Thin Solid Films, vol. 451–
452, pp. 448–454, Mar. 2004.

[47] S. Harrell, T. Seidel, and B. Fay, “The National Technology Roadmap
for Semiconductors and SEMATECH Future Directions,”
Microelectron. Eng., vol. 30, 1996.

[48] M. L. Garcia, “Introduction to Technology Roadmapping: The
Semiconductor Industry Association ’ s Technology Roadmapping
Process,” Sandia Natl. Lab., no. April, 1997.

[49] O. Saritas and M. A. Oner, “Systemic analysis of UK foresight results
Joint application of integrated management model and roadmapping,”
Technol. Forecast. Soc. Change, vol. 71, no. 1–2, pp. 27–65, Feb. 2004.

[50] R. Phaal and G. Muller, “An architectural framework for roadmapping:
Towards visual strategy,” Technol. Forecast. Soc. Change, vol. 76, no.
1, pp. 39–49, Jan. 2009.

[51] W. F. Hamilton, “Managing technology as a strategic asset,” Technol.
Manag., vol. 14, 1997.

[52] S. Walsh, “Roadmapping a disruptive technology: A case study The
emerging microsystems and top-down nanosystems industry,” Technol.
Forecast. Soc. Change, vol. 71, no. 1–2, pp. 161–185, Feb. 2004.

[53] R. Kostoff, “Disruptive technology roadmaps,” Technol. Forecast. Soc.
Change, vol. 71, no. 1–2, pp. 141–159, Feb. 2004.

[54] B. A. Vojak and F. A. Chambers, “Roadmapping disruptive technical
threats and opportunities in complex, technology-based subsystems:
The SAILS methodology,” Technol. Forecast. Soc. Change, vol. 71, no.
1–2, pp. 121–139, Feb. 2004.

[55] J. D. Strauss, M. Radnor, and J. W. Peterson, “Plotting and navigating a
nonlinear roadmap: knowledge-based roadmapping for emerging and
dynamic environments,” in Proceedings of the East Asian Conference
on Knowledge Creation Management, Singapore, 1998.

[56] N. Gerdsri and D. F. Kocaoglu, “Applying the Analytic Hierarchy
Process (AHP) to build a strategic framework for technology

2994

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

roadmapping,” Math. Comput. Model., vol. 46, no. 7–8, pp. 1071–1080,
Oct. 2007.

[57] I. J. Petrick and A. E. Echols, “Technology roadmapping in review: A
tool for making sustainable new product development decisions,”
Technol. Forecast. Soc. Change, vol. 71, no. 1–2, pp. 81–100, Feb.
2004.

[58] I. J. Petrick, “Technology Choice and Pooled Investment Among
Networks: Supply Chain Roadmaps,” IEEE, 2002.

[59] C. H. Fine, “Roadmapping the Communications Value Chain,” Science.
MIT Sloan School of Management, 2002.

[60] A. Kameoka, K. Nakamura, T. Fujuwara, and N. Kamada, “‘Services
Science’ and Services Layer Added Strategic Technology
Roadmapping,” in Portland International Conference on Management
of Engineering and Technology. Proceedings, 2006, no. c, pp. 9–13.

[61] G. Bitran and S. Gurumurthi, “Roadmap for Service Excellence,”
Management. MIT Sloan School of Management, 2004.

[62] J. D. Strauss and M. Radnor, “Roadmapping for Dynamic and
Uncertain Environments,” Res. Technol. Manag., pp. 51–58, 2004.

[63] M. Pagani, “Roadmapping 3G mobile TV: Strategic thinking and
scenario planning through repeated cross-impact handling,” Technol.
Forecast. Soc. Change, vol. 76, no. 3, pp. 382–395, Mar. 2009.

[64] H. Abe, T. Ashiki, A. Suzuki, F. Jinno, and H. Sakuma, “Integrating
business modeling and roadmapping methods – The Innovation
Support Technology (IST) approach,” Technol. Forecast. Soc. Change,
vol. 76, pp. 80–90, Jan. 2009.

[65] A. Macintosh, I. Filby, and A. Tate, “Knowledge Asset Road Maps,” in
Proceedings of the 2nd International Conference on Practical Aspects
of Knowledge Management (PAKM98), 1998, pp. 29–30.

[66] W. Selen, “Knowledge management in resource-based competitive
environments: a roadmap for building learning organizations,” J.
Knowl. Manag., vol. 4, no. 4, pp. 346–353, 2000.

[67] Miltiadis D. Lytras, A. Naeve, and A. Pouloudi, “A Knowledge
Management Roadmap for E-Learning: The Way Ahead,” J. Distance
Educ. Technol., vol. 3(2), pp. 68–75, 2005.

[68] R. Kostoff and R. R. Schaller, “Science and technology roadmaps,”
IEEE Trans. Eng. Manag., vol. 48, no. 2, pp. 132–143, May 2001.

2995

2014 Proceedings of PICMET ’14: Infrastructure and Service Integration.

TheInternational Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

INFORMATION SYSTEMS STRATEGIC PLANNING TO INCREASE
COMPETITIVE ADVANTAGE OF HIGHER EDUCATION USING

BE VISSTA PLANNING METHODOLOGY
(CASE STUDY: SWCU SALATIGA)

Agustinus Fritz Wijaya

Faculty of Information Technology

Satya Wacana Christian University, Indonesia
agustinus.fritz@gmail.com

Danny Manongga

Faculty of Information Technology
Satya Wacana Christian University, Indonesia

dmanongga@gmail.com

Abstract

Information system and information technology (IS/IT) has taken great effect in business process
of an organization. The research was conducted at the Satya Wacana Christian University
(SWCU). SWCU perceived in running business processes is not optimal in making the
application of IS/IT in the organization. Implementation planning process/IT has not been done
equally for all business units, yet have SWCU Executive Information Systems (EIS) which can
assist in the decision making process. Process of strategic planning of information systems using
Vissta Be Planning has compiled some information systems strategic planning methods. Results
obtained the study of the needs of the IS/IT in SWCU which obtain an application portfolio that
will implemented in the institution.

Keywords: Information Systems, Executive Information System, Strategic Planning,

Competitive Advantage, Be Vissta PEST, Value Chain Activity, Strategic Grid,
Application Portfolio.Planning, Five Forces

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

Introduction

Information system and information technology (IS/IT) has taken great effect in business

process of an organization. IS/IT not only given the efficiently improvement and effectivity of

organization work but also has become the main factor toward organization in order to perform

the business process and to gain the business objective of the organization by: create new ways

in managing organization, improving the productivity and performance, developing new business

and finally give the competitive supremacy (Ward, J., et. al., 2002). Nowadays, IS/IT is expected

to be one kind of aspect from business strategy of an organization so the objective of the

organization will be reached. One of organization objective is reaching competitive superiority in

global market within the way of how the organization able to integrate all the data they owned

which can be help making benefit information that can be used to help organization management

is doing the business process. The use of IS/IT in giving the competitive superiority today still

can not be found. The subject of problem in here is how making the organization able to

harmonize between business strategies with IS/IT strategy in order to create organization

competitive superiority.

To overcome these problems, the organization shall conduct thorough strategic planning

of IS/IT that have been or will be applied. It is important, because it will be used as a basis for

managerial decision-making about application of IS/IT in the future. Managerial decisions

regarding IS/IT is applied in an organization related to how IT Governance that have been

established. IT Governance as a system to direct and control an organization in achieving its goal

by utilizing the IS/IT and processes within it need a strategic plan in order to obtain benefits

(Weill, P., et. al., 2006). To ensure that the strategic planning of IS/IT is one of the pillars of an

IT Governance, it is necessary to answer the following questions: (a) Are we doing the right

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

thing; (b) Do we do it the right way; (c) Does we do well; (d) Do we get the benefit. Answers to

four questions will be referred in the process of strategic planning IS/IT in an organization.

Strategic Planning IS/IT is absolutely necessary for every organization that will utilize IS/IT.

Satya Wacana Christian University (SWCU) Salatiga as one of the non-profit

organization is an educational institute, has long been implementing IS/IT in any organization’s

business processes. However, each IS/IT is used in this organization have not been able to

provide output that can help the leaders in upper management level (top level management) in

SWCU to determine the business strategy forward. The impact of that is the difficulty for top

level management to take decisions in the process of planning, controlling, monitoring, and

performance improvements in business processes institution. Therefore, it is necessary to do a

strategic planning IS/IT in an environment that is able to align SWCU between business strategy

and strategic IS/IT, so SWCU can achieve business goals effectively and efficiently.

In preparing the strategic plan IS/IT in SWCU, we use the method Be Vissta Planning

(BVP) which is a method to produce a strategic planning IS/IT that combines various methods of

strategic planning IS/IT which has advantages such as being able to analyze the information gap

between business activities and IS/IT is used and can provide a competitive advantage based on

the opportunities that are owned by the SWCU (Pavlou, A. P., et. al. 2006). Then, the results of

strategic planning IS/IT able to answer a variety of business requirements based on the analysis

of business environment and the environment IS/IT environment both internal and external

environment.

Review of Literature

Research on information systems strategic planning using BVP methodology to develop a

strategic plan based on the business benefits of information systems that produce a blueprint for

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

systems, technology and information management in an industrial company (Haris, W., 2002). In

that study, researchers analyzed the literature related to information systems strategic planning

methods. Various methods of strategic planning is then compiled into a method. There are

several things that can be summed up in these studies, among them the BVP methodology must

be equipped with a list of questionnaires to help sharpen the analysis of the needs of business and

IS/IT organization. Other research is the methodology used to develop the strategic plan BVP/IT-

related increase in revenue (PAD) (Ellensyah, K., 2003). BVP methodology used has been

adapted to the case study object, the service-oriented organization, in this case the provincial

government (province) of Jakarta. Researchers try to develop a strategic plan/IT-based business

benefits for the city government, where the strategic plan/IT can be a reference in the

manufacturing-based governance of information technology (e-Government). In this research,

BVP used to analyze the internal and external IS/IT of the Government of DKI Jakarta. Based on

the analysis, was made a breakdown potential of IS/IT, which is then mapped to each of the

relevant agencies PAD. Having identified the potential of IS/IT from each institution, then later

made proposals IT infrastructure that supports the potential of IS.

Strategic Planning IS/IT is a process of identifying a portfolio of computer-based

application that will support organizations in the implementation of business plans and realizing

its business objectives (Ward, J., et. al., 2002). Strategic Planning IS/IT study the effect of IS/IT

on business performance and contribution to the organization in selecting the strategic steps. In

addition, strategic planning IS/IT also explains various tools, techniques, and frameworks for

management to align IS/IT with business strategy, and even find new opportunities through the

application of innovative technologies. Some characteristics of strategic planning IS/IT, such as,

the primary mission: strategic or competitive advantage and its relation to business strategy; the

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

direction of the executive or senior management and users; as well as the main approach in the

form of user innovation and development combined bottom up and top down analysis. Figure 1

shows a schematic model of the strategic planning of IS/IT.

Figure 1. IS/IT Strategic Planning Method

(Ward, J., et. al., 2002)

Research Methods

The research method which will be done in this research is in Figure 2. In the first phase,

researchers will be guided by strategic information systems planning methodology proposed

Ward and Peppard (Ward, J., et. al., 2002) that will analyze the business environment and

environmental analysis of IS/IT organization’s internal and external advance. The second stage

until the fourth stage, investigators using methodologies BVP. The first stage is intended to get

an overview about the state of organization and business processes conducted institution. This

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

stage is part of phase 1 methodology BVP, which is examining the needs of the organization.

Input required in this phase is obtained from the vision and mission of the organization’s business

processes SWCU especially in the areas of academic and information technology.

Figure 2. Research Method

The second phase is intended to find the proposed strategy IS/IT that can meet the needs

of institution. The results obtained from phase 1 will be input at this stage. The expected result of

this second stage is a proposed strategy IS/IT in accordance with the needs of institution. In this

study, the proposed strategy IS/IT will be limited to the potential of IS/IT are available at this

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

time SWCU. In the third phase, will be the strategy IS/IT with respect to the existing policy rules

that will be taken against the policy implementation plan IS/ IT in the institution. The next stage

after making the planned implementation of IS/IT is to be applied in the institution.

In strategic planning IS/IT based on the methodology used Value Information Systems

Strategic Planning (Be Vissta Planning) based on the advantages of strategic planning

methodologies of existing information systems (Pavlou, A. P., et. al. 2006). Methodology BVP

collects the advantages of information systems strategic planning method of Ward and Peppard,

Wetherbe, Martin and Tozer, then compiled into a BVP methodology (Raghunarthan, B., et. al.,

1999). The design methodology is based BVP strategic planning activities of IS/IT in some

ways, that is based on the organization’s business plan document. Each data set forth in the

organization’s business plan interprets as information needs to be met by field IS/IT division.

Field IS/IT division was then conducted an analysis of internal and external conditions in order

to determine the ability of its resources and meeting the needs of the business information. The

analysis of internal and external systems strategy, management, and information technology are

then created for the implementation of priority projects and implementation schedules.

Analysis and Strategic Planning

The first stage of the methodology Be Vissta Planning are reviewing and analyzing the

organization’s business environment, the activities carried out at this stage are the analysis of an

organization’s external business environment, the organization’s internal business environment

analysis, analysis of the condition of IS/IT external conditions and analysis of IS/IT internal

institution. Organization’s external environment analysis conducted to determine the

organization’s external environmental conditions, this analysis will be based on assessments of

the leaders SWCU to market conditions in the world of education using interview, questionnaire,

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

and the study of literature on related research. Organization’s external environment analysis

performed with the aim to identify the needs of IS/IT SWCU so as to compete with its rivals,

especially the external conditions. Figure 3 shows the relationship with the organization’s

external environment analysis of the needs of IS/IT institution.

In this study, the analysis of an organization’s external environment is done using two

tools which are the analysis of Five Forces and PEST. Five forces analysis using the five forces

of external organizations. By using this analysis, it can be identified external things what they are

Figure 3. Relationship between Organization’s External Environment

And IS/IT Instituion Needs

positive or negative that may impact/influence on business processes in the institution. This

analysis also aims to provide an overview of solutions IS/IT for the institution. In the analysis of

five forces in SWCU very interesting to see who is the customer and suppliers, the customers

here are students because they are the users of education services within the institution. While

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

the supplier is also a student because they are sent to be educate in the university environment to

produce output as alumni. For product/service substitutes (subtitute products/services) are

different types of services/education services outside the colleges that offer the same learning

methods with lower prices and shorter time to produce graduates that can be used by users of

raduates. Based on the five forces analysis, it can be mapped to the needs of IS/IT in SWCU, as

shown in Table 1.

Table 1. The Need for IS/IT Based on the Five Forces Analysis

Five Forces Factors IS/IT Needs

A formidable competitor that has a
complete information system,
interesting programs, and the
uniqueness of graduates.

– Build a complete information system that
integrates all business processes.

– Building information systems promotion with
attractive multimedia systems.

Threat of New Entrans with various
advantages such as business strategies
and educational programs webomatrix
interesting.

Increase SWCU webomatrix thus becoming one of
the world class university that can compete with
other universities.

Bargaining Powers of Suppliers and

Buyers are able to influence supply,
reception, and service to the institution.

Building information systems that can connect
between SWCU with stakeholders such as the
application of Customer Relationship Management
(CRM) and Supply Chain Management (SCM) that
can accommodate the demands of stakeholders.

Threat of Subtitute Products/
Services that provide an alternative
education program that is relatively
cheaper and faster in terms of the study
period.

Building information systems that can provide
education to stakeholders about the benefits of study
at institutions of formal education are much better.

The next external environmental analysis organizations PEST analysis is performed on

the four factors that may affect the business processes at the institution. These factors are

political, economic, social, and technology. Political factors that some government policies and

laws on education. As the university is located in the jurisdiction of the Republic of Indonesia,

the SWCU also noticed some laws and administrative regulations governing the implementation

of education. Economic factors, among others, economic growth in Indonesia tend to be less

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

stable that directly affect how the attitude of the parents who would send their children to

college. Social factors closely associated with religious and cultural factors. SWCU as one of the

university run by a Christian foundation has the feel of a high religious in any activity on

campus. However, beside known as a Christian university, the SWCU is also the option for non-

Christian students whereas it could be seen from some students who are Muslim, Buddhist, or

Hindu. In terms of culture, SWCU known as “Mini Indonesia” which can be viewed from

various ethnic diversity of the indigenous or ethnic culture from Sabang to Merauke, barely

contained in the institution. This suggests that the lost password can be accepted by all societies

and ethnic cultures as a college that has good quality. Technology factors, namely, the use of

technology is used ranging from administration to teaching and learning, even when it lost

password using technology in terms of promotions and new admissions as a test online and

announcement of test results. Development web 2.0 technologies such as network infrastructure

and influence how business processes are performed in the institution. If the first, each business

unit using technology separately with each information system, currently all business units in lost

password associated with the integrated information system. Based on PEST analysis, it can be

mapped to the needs of IS/IT in SWCU, as shown in Table 2.

While the environmental analysis IS/IT external organization aims to see the development

of the condition of IS/IT today that will affect the implementation of IS/IT in the institution. In

conducting this analysis, the researchers conducted a study of literature from various sources

which will see the various developments of IS/IT such as: development IS/IT for higher

education, software development, hardware development, development of database systems,

development of communication network and data security, and the development of social

networking media (social network) that will be able to see the benefits of the implementation of

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

Table 2. The Need for IS/IT Based on the PEST Analysis

PEST Factors IS/IT Needs

Politics:
Government policies, laws, and laws and
regulations on education through the
Higher Education and Kopertis region VI
of academic quality control and program
evaluation studies.

– Building information systems that can
carry out supervision of academic
quality.

– Build a system which can provide
reporting information related to the
process of accreditation of courses
and extension of the operational
program of study based on self-
evaluation program of study.

Economics:
Purchasing power of prospective students
to the study plan is relatively low due to
the economic conditions are less stable
and thus require colleges to study low
cost, easily accessible location, and has a
scholarship.

Building information systems that can
provide information about tuition fees,
college location, and complete scholarship
information.

Social:
Religious diversity and ethnic cultures
throughout Indonesia that make the
campus lost password “Mini Indonesia”
provides its own characteristics compared
to other colleges.

Building information systems that can
provide information about the diversity of
socio-cultural that can be accessed by the
general public so as to attract potential
students from diverse backgrounds in the
area of Indonesia.

Technology:

Development technology and integrated
information systems have an impact on
the entire organization’s business
processes.

Provision of adequate technology
infrastructure so as to support the
implementation of information systems at
the institution.

IS/IT in the institution. Based on the analysis of external conditions IS/IT, it can be identified

several benefits of the implementation of IS/IT in SWCU as shown in Table 3.

The next stage of analysis is the organization’s internal business environment analysis

was made to have a clear business processes that occur in the SWCU in order to obtain a clear

picture of the strategic plan IS/IT to meet the needs of the organization. Analysis process is to

conduct interviews and questionnaires to the various business units of organizations including

the heads of institution. Analysis tool is the organization’s internal business environment using

the Value Chain Activity. Value chain analysis of activity undertaken to describe the activity of

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

Table 3. Benefits from Applying IS/IT Based on the IS/IT External Conditions

IS/IT External Condition Benefits from applying IS/IT

– The use of information systems
for business processes at the
college began to demand.

– The continued development of
open source software.

– The development of technology
based on Service Oriented
Architecture (SOA) for web
applications.

– Internet broadband mobile
technology is increasingly used
in computer networks.

– Data security system start being
applied in various information
systems.

– The development of social
networking media along with the
increasing use of smartphones.

– Facilitate the organization’s
activities and business processes for
integration of all business units
within an information system.

– Reduce operating costs and
maintenance of information
systems.

– Facilitate the distribution of data
and information from each business
unit are related and interconnected
with information systems.

– Facilitate the communication of data
and information remotely and
improve the efficiency of time and
place.

– Provides data integrity and security
hardware used.

– Facilitate the promotion and
management of the academic
community.

key business processes and supporting business processes of an organization. This analysis also

aims to identify and classify the activities that occur in SWCU into two major parts which are the

major activities and support activities. The results of this analysis will then be used to identify

the needs of IS/IT. Value chain activity that occurs in SWCU can be described as in Figure 4.

In identifying the application of IS/IT in SWCU, they conduct the environmental analysis IS/IT

internally in SWCU to all available resources IS/IT. Resource in question is information systems,

information technology, and human resources or management IS/IT contained in the institution.

The next stage after an analysis of business and IS/IT organization’s external and internal,

that is the proposed solution strategy IS/IT which can meet the needs of IS/IT in the institution.

The results obtained from previous stages of environmental analysis and business IS/IT

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

Figure 4. SWCU Value Chain Activity

organizations will be input at this stage of the solution strategy proposed IS/IT. Then,

applications will be mapped according to their respective functions using the matrix Mc Farlan

Strategic Grid (Raghunarthan, B., et. al., 1999) to determine the priority application to be applied

in future SWCU. Future applications of mapping matrix can be seen in Figure 5.

Figure 5. SWCU Future Applications Portfolio Strategic Grid

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

Based on the applications that have been proposed and mapped in Figure 5, then made a

plan implementation IS/IT to create a roadmap of priorities that takes into account factors of

resources, functions, and complexity of applications that will be implemented in the future.

Priority implementation will be based on the quadrant of Mc Farlan Strategic Grid:

1. Priority #1: Applications that are in key operational quadrant.

2. Priority #2: Applications residing in quadrant support.

3. Priority #3: Applications in the strategic quadrant.

4. Priority #4: Applications that are in the quadrant of high potential.

Summary

Analytical results obtained in this study illustrate that the application of IS/IT which done

in SWCU is unable to support the overall business process. The analysis was done to the

environment and environmental business IS/IT external and internal in order to identify the

needs of IS/IT to support business processes at the institution. Solution strategy IS/IT focused

arranged to support the main activity in SWCU, such as promotions and new admissions,

education and teaching, research and community service, as well as graduation and alumni.

Another strategy is to give the proposed solutions of IS/IT supports to sustain the various

activities that support the main activity, such as: managing human resources, facilities and

information technology, academic administration, finance and accounting, laboratories and

libraries, and public polyclinics in order organizations gain a competitive advantage. BVP

application of the methodology in the preparation of strategic planning IS/IT in SWCU provide

alignment between IS/IT with the vision, mission and goals of the organization as a portfolio of

solutions IS/IT based on the results of the study and analysis of the primary activities and support

activities that are identified using a value chain activity.

The International Journal of Organizational Innovation Vol 5 Num 2 Fall 2012

References

Ellensyah, K., (2003), Penyusunan Rencana Strategis Sistem Informasi Berbasis Value pada
Pemerintah Daerah (Studi Kasus: Pemerintah Daerah Khusus Ibu Kota Jakarta), Jakarta:
Universitas Indonesia.

Haris, W., (2002), Penyusunan Metodologi Perencanaan Strategis Sistem Informasi Berbasis

Value Bisnis (Be Vissta Planning) dalam rangka Meningkatkan Peran Strategis Sistem
Informasi pada Suatu Organisasi. Jakarta: Universitas Indonesia.

Pavlou, A. P., El Sawy, O. A., (2006), From IT Leveraging Competence to Competitive

Advantage in Turbulent Environments: The Case of New Product Development,
INFORMAS: Information Systems Research.

Raghunathan, B., Raghunathan, T. S., & Qiang Tu, (1999), Dimensionality of the Strategic Grid

Framework: The Construct and its Measurement, INFORMAS: Information Systems
Research.

Ward, J., Peppard, J., (2002), Strategic Planning for Information Systems 3

rd
Ed., UK: John

Wiley & Sons, Ltd.

Weill, P., Ross, J. W., 2006, IT Governance, Massachusetts: Harvard Business School Press.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

PROCESS ACCEPTANCE AND ADOPTION BY IT SOFTWARE

PROJECT PRACTITIONERS

Deana R. Guardado

RICHARD DANIELS, PhD, Faculty Mentor and Chai

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 Fulfillmen

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.

All rights reserved. This edition of the work is protected against
unauthorized copying under Title 17, United States Code.

ProQuest LLC.
789 East Eisenhower Parkway

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

UMI 3512446
Copyright 2012 by ProQuest LLC.

UMI Number: 3512446

Abstract

This study addresses the question of what factors determine acceptance and adoption o

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, socia

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 respondent

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

Dedicati

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 ……………………………………………………………………………………………

List of Figures ……………………………………………………………………………………………

CHAPTER 1. OVERVIEW OF PROCESS ACCEPTANCE AND ADOPTION ………….

IT Software Project Management …………………………………………………………………

Why Study Software Project Management? ………………………………………………….. 4

Software Project Management as a Discipline ……………………………………………….

Software Project Management and Process Management ………………………………

Factors Influencing Software Project Success ………………………………………………

Factors Influencing Software Project Failures ………………………………………………

Technology Acceptance Models …………………………………………………………………

History and Background …………………………………………………………………………… 18

Proposal for Dissertation……………………………………………………………………………

Research Question ……………………………………………………………………………………

CHAPTER 2. LITERATURE REVIEW ……………………………………………………………….

Business Process Management …………………………………………………………………..

Information Technology Process Management …………………………………………….

Organizational Change Management …………………………………………………………..

Putting it All Together ………………………………………………………………………………

Research Hypotheses ………………………………………………………………………………..

CHAPTER 3. METHODOLOGY ………………………………………………………………………..

Research Design………………………………………………………………………………………. 86

vii

Sample…………………………………………………………………………………………………….

Setting …………………………………………………………………………………………………….

Instrumentation / Measures ………………………………………………………………………..

Data Collection ……………………………………………………………………………………….. 90

Data Analysis …………………………………………………………………………………………..

Validity and Reliability ……………………………………………………………………………..

Ethical Considerations ………………………………………………………………………………

CHAPTER 4. RESULTS …………………………………………………………………………………….

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 ………………………………………………………

Table 2. Core Constructs of Acceptance Models……………………………………………………..

Table 3. Moderators of Core Constructs …………………………………………………………………

Table 4. Characteristics of the Role of IT in BPR ……………………………………………………

Table 5. Different Definitions of the BPM Life Cycle ……………………………………………..

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

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

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 over

done.

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

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

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.

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

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

n
g

u
rv

e
y
q

e
st

o
n

w
il

b
e
u

e
d

o
r

h
e
r

e
se

a
rc

h
.

E
a

c
h

u
e
st

io
n

e
p
ic

ts
w

h
ic

h
o

f
th

e
f

u
r

c
o

n
st

ru
c
ts

a
re

b
e
in

m
e
a
su

re
d
,

a
s

e
ll

a
s

th
e
r

e
sp

o
n
se

a
n

e
t

a
t

w
il

l
b
e
p

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

rp
ri

se
,

IT
,
jo

b
–

e
c
if

ic
,
a

n
d

li
e
n
t)

Q
u

e
st
io
n

r
ig

a
l

In
st

r
u

m
e
n

M
o
d

if
ie

d
I

n
st
r
u
m
e
n
t

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
t
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

o
b

.
I
w

u
ld

f
in

d
p

ro
c
e
ss

e
s
o
r

p
ro

c
e

d
u

s
u
se
fu
l
in
m

y
j

o
b
.

S
e
le

c
t

0
-5

S
e
le
c
t
0
-5

U
si

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

a
sk

s
m

o
re

q
u

k
ly

.
U
si

n
g
p

ro
c
e
ss
e
s
o
r
p
ro

c
e
d
u
re

n
a

b
le

s
m
e
t

o
a

o
m

p
li

h
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

U
si
n
g
t
h
e
s
y
st
e
m

i
n

c
re

a
se

s
m
y

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
s

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

If
I

u
se

t
h
e
s
y
st
e
m

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

l
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

E
ff

o
r
t

E
x
p

e
c
ta
n
c
y
(
H
y
p
o
th
e
si

s
2

)
5

M
y
i

n
te

ra
c
ti

o
n

w
it

h
t
h
e
s
y
st
e
m

o
u
ld

b
e
c

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

1
F

ro
m

U
se

r
a
c
c
e
p

ta
n
c
e
o

f
in

fo
rm

a
ti

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

rt
e
rl

y
,

2
7

(3
),

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

Q
u
e
st
io
n

O
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
t
E
n
te
r
p
r
is
e

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
ic

P
r
o
c
e
d
u
r
e
s
C
li
e
n
t
P
r
o
c
e
ss
e
s
6

It
w

o
u

ld
b

e
e

a
sy

f
o

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
e

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

I
w
o
u
ld
f
in
d
t
h
e
s
y
st
e
m

e
a
sy

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
s
e
a
sy

t
o

se
.
S
e
le
c
t
0
-5

S
e
le
c
t
0
-5

L
e
a
rn

in
g
t

o
o

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

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

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

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

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.

S
e
le
c
t
0
-5

S
o
c
ia

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

e
m

y
b

e
h

a
v
io

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

S
e
le
c
t
0
-5

1
4

P
e
o
p
le
w
h
o
a

re
i

m
p

o
rt

a
n
t

o
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

p
o

a
n
t
to
m
e
t
h
in
k

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.

S
e
le
c
t
0
-5

1
5

T
h
e
s

e
n
io

r
m

a
n

a
g
e
m

e
n

t
o

f
th

b
u

n
e
ss

h
a
s

b
e
e
n

e
lp

fu
l

in
t

h
e
u

se
o
f

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.

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

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

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

S
e
le
c
t
0
-5

1
5
7

Q
u
e
st
io
n

O
r
ig
in
a
l
In
st
r
u
m
e
n
t1

M
o
d
if
ie
d
I
n
st
r
u
m
e
n
t
E
n
te
r
p
r
is
e

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
ic

P
r
o
c
e
d
u
r
e
s
C
li
e
n
t
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

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
se

p
ro
c
e
ss
e
s
o
r
p
ro
c
e
d
u
re
s.

S
e
le
c
t
0
-5

1
8

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
se

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
se

p
ro
c
e
ss
e
s
o
r
p
ro
c
e
d
u
re
s.

S
e
le
c
t
0
-5

1
9

T
h
e
s
y
st
e
m
i
s

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

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

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

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

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

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

I
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

e
re

w
a
s

n
o

n
e
a

ro
u
n
d

o
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
s

I
g
o

S
e
le
c
t
0
-5

2
2

I
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

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

2
3

I
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
o

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

2
4

I
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

1
5
8

Q
u
e
st
io
n

O
r
ig
in
a
l
In
st
r
u
m
e
n
t1

M
o
d
if
ie
d
I
n
st
r
u
m
e
n
t
E
n
te
r
p
r
is
e

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
ic

P
r
o
c
e
d
u
r
e
s
C
li
e
n
t
P
r
o
c
e
ss
e
s

A
n

x
ie

ty
(

H
y
p
o
th
e
si
s
2
)
2
5

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.

S
e
le
c
t
0
-5

2
6

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

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

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
g

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

2
8

T
h
e
s
y
st
e
m
i
s
so
m

e
w

h
a
t

n
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

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

I
in
te
n
d
t
o
u
se
t
h
e
s
y
st
e
m
i
n

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

n
th

S
e
le
c
t
0
-5

3
0

I
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
s.

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
e

o
n
th

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
s
in
t
h
e
n
e
x
t
th
re
e
m
o
n
th
s.

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

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
ff

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
ff

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.