Fryling, Meg, "ERP Implementation Dynamics", 2005 July 17-2005 July 21

ERP Implementation Dynamics
Meg Fryling, Ph.D. Student
Information Science and Policy
University at Albany
State University of New Y ork
1400 Washington Ave
Albany, NY 12222 USA
Phone: +1 (518) 437-4528

E-mail: mfryling@ uamail.albany.edu

I. Abstract

ERP projects are often undertaken by project managers in an effort to solve a problem,
increase efficiency, and/or provide a higher level of customer service. Although ERP
systems can provide all of these benefits and more, they can also cause havoc in an
organization if not managed correctly. There are far too many horror stories about
organizations failed ERP initiatives. In fact, the success rate of ERP implementations is
only around 33% and approximately 90% of ERP implementations are late or over
budget (Martin 1998).

How can a wonderful thing such as ERP cause such heartache? Often the issue has
nothing to do with technology and everything to do with the individuals involved with the
project. ERP problems arise from unrealistic expectations regarding resources and
cooperation required to implement an ERP system successfully.

ERP implementation articles consistently report that implementation failure or success is
people-related (Tapp 2003 & Peterson 2003). It’s often easier to blame the technology
then to explore these deeper issues but in the end they are the controlling factors. It is
important for managers to understand the complexities of the people-related issues,
relationships and office politics before embarking on a new ERP project. This research is
intended to provide insight regarding ERP implementation dynamics through modeling;
to build and explore theories regarding what causes ERP success/failure and ultimately
aid project managers in avoiding common pitfalls.

Problem Dynamics

Some of the dynamics in ERP implementations include people's belief that the project
will be successful. This belief may change over time and/or be influenced by various
other factors. For example, if people believe there has been significant progress
(perceived progress) then they might feel good about the project and have faith in its
success.

Additionally, has time passes management's willingness to invest additional funds or
workforce might change. In the beginning of the project lifecycle resources might be
plentiful but as managers believe the project is close to completion they may be less
willing to invest additional resources.

Justification for approaching problem with system dynamics

One can easily find feedback behavior when reading articles regarding the challenges of
implementing an ERP system. These feedback loops are essential to the story of what
causes ERP failure. ERP implementations, like many IT projects, have some common
elements that cause enormous headaches for project managers; these elements all have
feedback behavior. Figure 1-1 shows three commons elements of ERP implementations.
If any of the sides of the triangle (time, resources, & scope) are stretched, one or both of
the remaining sides must stretch to accommodate the change. For instance, as the scope
of a project increases, the time required and/or resources needed are augmented. Further,
as time is extended project scope inevitably increases (scope creep). Increasing the scope
of a project unavoidably causes time and resources to grow. The causal nature of these
influences is clear.

Figure 1.1

Reference Modes

As an ERP project moves through time, the willingness to invest additional resources
(money/people) changes drastically. Initially when a project is late, management is
willing to increase workforce in an effort to implement as soon as possible. Nonetheless,
as more time passes thoughts of abandoning the project cause a decline in the willingness
to increase workforce (Figure 1.2).
Figure 1.2 - Effect of Project Lateness on Willingness to Increase Workforce

Graph Lookup - Effect of project lateness on willingness to increase workforce

Expott
Print_ |

‘max:
2 +

Dmnl

“| ia =

J
Import Vals | Xmin:|0 wv ]x=2141 y=2.018 Xmax|100 —_v| Reset Scaling

OK | ClearPoints | ClearAllPoints | CurrRef | ClearReference | Ref>Cur| Cancel |

Time and cost overruns influence several variables. For example, the longer it takes to
implement a project the more likely tasks will need to be revisited. ERP software fix
bundles and upgrades occurring during an implementation cause spikes in task rework.
Unfortunately, these are unavoidable but can be limited by implementing in a timely
fashion. Fix bundles are provided by ERP vendors several times a year. While fixes are
intended to correct issues with the current product, they often break other pieces. The
only way to assess the extent to which fixes negatively impact an implementation is to
retest all previously completed work. In addition, if there are many customizations to the
delivered product the likelihood of rework increases appreciably. Customizations differ
from other tasks in that they must be carefully tracked since the vendor may redeliver a
new version; thus, wiping out the customization work. Each time the item is redelivered
the customization must be reapplied (Figure 1.3). Fixes and upgrades not only break
tasks but they often introduce new tasks (Figure 1.4).
Figure 1.3 - Customizations Needing Rework or Reapplication

Discovering cust needing rework or reapp

20
15
10
5
0
0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72
Time (Month)
Discovering cust needing rework or reapp : Base ERP ———————— tasks/Month
Figure 1.4 - Undiscovered New Work from Fixes/Upgrades
Undiscovered new work
10
75
5
2.5
0
0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72
Time (Month)
Undiscovered new work : Base ERP tasks

Scope reduction is one way to counteract time and cost overruns. Pressure to eliminate
tasks increases as an implementation passes its scheduled completion date. However, if
a project is extraordinarily late then the elimination of tasks becomes difficult to justify
(Figure 1.5).
Figure 1.5 - Effect of Project Lateness on Pressure to Eliminate Tasks

Graph Lookup - Effect of project lateness on pressure to eliminate tasks

I Output

Lg a ES

5 [0.05263

10 0.114

15 [0.1667

20 ‘(0.3246

25 ‘(0.4035

30 0.5351

3 10.7368

40 (0.8246

46 (os211

50 0.9649 zl

——

Import Vals | X-min:|0 >| =51.38 ye1.211 Xmax|100 | Reset Scaling
OK | ClearPoints | Clear AllPoints | Cur>Ref| _ClearReference | Ref->Cur| Cancel |

The pressure of meeting implementation deadlines can have multiple effects. If schedule
pressure is high then one way to reduce this pressure is to complete tasks more rapidly
(Figure 1.6) (Sterman 2000).

Figure 1.6 - Effect of Schedule Pressure on Time per Task

Graph Lookup - Effect of schedule pressure on time per task

ce ee
a

J
Import Vals | Xmin|O _v| x=0 y-0 Xmax|26 _v| Reset Scaling

OK | ClearPoints | ClearAllPoints | CurRet | _ClearReference | Ref>Cur| Cancel _|

Data Source: Sterman 2000

Shortening the time to complete tasks is often accomplished by reducing or skipping
proper testing. The end result of task time reduction is that task quality decreases and it
is likely that tasks will need to be revisited (Figure 1.7).
Figure 1.7 - Effect of Schedule Pressure on Time per Task

Graph Lookup - Effect of time per task on undiscovered rework

200 a4 +f ' : ' Yin:
ee H : H 0 a
|_|
Import Vals | X-min0 | =O yO Xmax|200 _y| Reset Sealing

OK | ClearPoints | Clear AllPoints | _Cur>Ref | _ClearReference | Reft>Cur| Cancel _|

Schedule pressure also influences the normal hours worked per month (Figure 1.7).
Figure 1.7 - Effect of Schedule Pressure on Hours Worked

Graph Lookup - Effect of schedule pressure on hours worked

Export
Print

ox
z
Ed
4

Dmnl

‘Vermin:
r | j
Import Vals | Xmin|0 vf x=0.1867 ——y=3.079 Xmax|1.25 | Reset Scaling

OK | ClearPoints | Clear AllPoints | Cur>Ref| ClearReference | Ref>Cur| Cancel _|

Data Source: Sterman 2000

Increased work hours causes workforce fatigue, which ultimately affects the quality of
work (Figure 1.8).
Figure 1.8 - Effect of Fatigue on Undiscovered Rework

Graph Lookup - Effect of fatigue on undiscovered rework

Input Output Yomax:
Lq oss | } : : |
80 0.6491 ' : :
760 7 Dmnl
240 ‘(1.167
320 ‘(1.298
400 (7.421
480 (1.485
560 (7.509
40 (1.509
Me f i ' min:
oem! | | | —
a |
lnortVals | XminjO | x0 0 %maie|640 | Reset Seana |
OK | ClearPoints | Clear AllPoints | Cur>Ref | ClearReference | RefCur| Cancel _|

Workforce size impacts the pressure to change project scope (Figure 1.9). While a large
gap between indicated workforce and actual workforce decreases the pressure to add new
tasks, as this gap reduces belief that new tasks are justified increases. Consequently, both
resources and scope increase together so anticipated time reduction benefits are not
realized.
Figure 1.9 - Effect of Workforce Gap on Pressure to Add New Tasks

Graph Lookup - Effect of workforce gap on pressure to add new tasks

Input ‘Qutput

a [osc +

20 (0.9825

15 (0.9312

0 (os2i1

5 (0.818

0 (0.6667

5 (04474

10 [0.2982

1 fozis3

20 [0.1879

25 +(o1579 ~ ' ‘ ree hc:

New H H H 0 ad

Import Vals as x) x0 y=0 Xmax|25 >| Reset Sealing
OK | ClearPoints | Clear AllPoints | Cur>Ref| ClearReference | Ref>Cur| Cancel |

Training of the workforce can be costly and time consuming but a properly trained
workforce would produce a better product that is less likely to require rework (Figure

1.10).
Figure 1.10 - Effect of Training on Undiscovered Rework

Graph Lookup - Effect of training on undiscovered rework

I
Import Vals | X-min|0 + | x= ye Xmax|750 _v| Reset Scaling

OK | ClearPoints | Clear AllPoints | Cur>Ref| ClearReference | Ref>Cur| Cancel |

An appropriate ERP system should be purchased that closely matches the business for
which it is intended. Nonetheless, a certain amount of fit gap will be necessary. There
are two ways in which to reduce gaps between an organization’s business needs and the
delivered ERP. The system can be customized (modified) to match current business
processes or the business processes can be modified to better fit the delivered ERP
system. Classic ERP implementation strategies suggest modifying business processes as
much as possible to fit the product.

Figure 1.11 - Effect of Gap Reduction Method on Willingness to Modify Business Processes

Graph Lookup - Effect of gap reduction method on willingness to modify business p...

Input Output aaa
Lg ossa7 =| : : i aa |
a1 [0.8596 : : '
a2 (0.7896 : : mel
03 [0.6867
a4 (0.5986
05 [oatzs
a6 (0.2896
O7 [01687
a8 [0.09649 a
a9 [0.07895 : Pa
1 Q x : ' Y-min:
ioe al ! i ——. 0 |
| |i
_lnportVals | xXenin|O | 0 0 Xmar|1 | _ Reset Scaina |
OK | ClearPoints | ClearAllPoints | Cur>Ref | Clear Reference | Ref-»Cur| Cancel |

II. Model Structure

Some of the dynamics involved with typical ERP implementations are shown in the
diagrams below. The development of these diagrams acted as building blocks toward
the creation of the model for ERP implementation dynamics.

Sector Overview Diagram

The current model contains six sectors (Figure 2.1).

Figure 2.1 - Sector Overview Diagram

Pressure to Ss
Lig esaess+s oustomize ERP Perceived tasies._
_w| Scope Sector oe remaining
Effect of fatigue 4 ¥
on undiscovered ,- :
rework 7 Pressure to add} | Fit Gap Sector
‘ new tasks _—— zh
Effect of time n-.__
; tasks
! Tasks i seg :
iperceived | Workforce Sector Re Er t
ycoeere Effect of costs én, .
sani Tine Sector
8 Financial Sector
Hi Workforce.
1 fg
Workforce fo
Capacitated Sector
~~ “Time perceived
remaining
Causal-Loop Diagrams

Time, project scope and resources (money/workforce) are competing variables in the
model. As the time to implement an ERP extends so does the need to add additional
tasks. Some tasks arise from changing user expectations; since the project time has been
extended the tendency to ask for additional customizations increases. Other tasks occur
from ERP batches and upgrades, which often break previously completed work (Figures
2.2 & 2.3).
Figure 2.2 - Causal-L oop Diagram with Explicit Stocks
, a
Software —

upgrades required See
coraploticn
fo mp ~ Projet Cod Co:
{ fo

@

Mandavory a
See Cres ‘Workforce to decrease
User Requesied ‘nuplementation time
Seope Creep
Pressure io add
new oe a
as ielciei ae +
Pre'sure to increase:
‘workforce
a oo
Inkial project
scope Warksorce
progress
ercsateiaen
f+
“
beat peogsess
progres ee
" Progress rite!
A
Ke

Gross productivity

Figure 2.3 - Causal Loop Diagram with Explicit Stocks and Flows

‘Total une penton
project ena cou tinea
— ‘worktime

Peat A
onan ramen)

pet goal

Pot lides [SEE
z: competion
Ke ‘hie
the of pt ites A To
\ Pei try en
= Mandates Scope Crep, <cmatve

eweived prugess=

y a, te

ee linia sts
‘eg tests Compbtingtiste
Doing J
pe
ae?)
Scape Creep nat os
Cute
T pened pegese a
[Gant See
nner -Preotat tania
+ wwofee=

Progessre
System Archetypes

System archetypes help identify some additional structures that have been or will be
included in the model.

Figure 2.4 - Scope Drifting G oals

Y
‘A
Project | = ‘Pressure to
visi] Gp leita
i \ ‘
( \
eee] See
preene —
oS
/ v\
\. 4e) a

Pg ot

\ f

ERP projects are notorious for not meeting original deadlines. As the gap between the
actual projected go-live date and the deadline goal increases, project scope is reduced
and/or consultants are hired to help reduce the deadline gap. Additionally, there are other

variables such as CIO expectations putting pressure on maintaining the original deadline
goal (Figure 2.4).
ERP projects are also infamous for exceeding budget goals. As the gap between the
actual budget overruns and the budget goal increases, project spending is reduced and/or
project scope is decreased to help reduce the budget gap. Additionally, there are other
variables such as CIO expectations putting pressure on maintaining the original budget
goal (Figure 2.5).

Figure 2.5 - Spending Drifting Goals

&
ye ;
Project 2 rearureto
Airs) A [ee
He +

CIO ~ Me
‘Expectiations Rg
sgramion| 42)

‘Actual
project
overnuts

‘.

Shifting the Burden

ERP systems never completely match the business processes of any particular
organization. It is for this reason that ERP’s are often customized to fit the organization
instead of examining the business processes and modifying to accommodate the new
system. Customizations are a “slippery slope” when it comes to ERP systems because
although a few are necessary, once some are approved end-user expectations change so
that more customizations are requested (Figure 2.6). Customizations may not sound like
a bad option but there are many negative implications, some of which are explored in this
research.

Figure 2.6 - Shifting the Burden

va +

Gap berween
feusuess processes

7 asd ERD

processes

III. Presentation and Analysis of Model Behavior
Formal Model

For purposes of this model, time begins after preliminary fit gap is complete and an initial
project scope is defined. This initial project scope is the starting value for tasks perceived
remaining. There is an initial project scope that establishes the beginning value of tasks
perceived remaining. As time passes the workforce completes tasks based on actually
productivity until all tasks are complete (Figure 3.1).

Figure 3.1
Time to discover “"
rework Bp
emaining:
Normal fraction
( = laeeaeere } wll a satisfactory
a reworl .
Discovering Tasks needing
rework rework Effect of fatigue or
a 4 4 “undiscovered rework>
E f training o: «Effect of time per
discovered rewo task on undiscovered
¥ u d rework
dai, THE
‘ a erceivel
Fermaining Completing pompletd

tasks

Productivity is affected by schedule pressure (Figure 3.2). Pressure may increase work
hours and decrease time spent on tasks in an effort to increase productivity. The negative
effect is that workforce burnout can damage productivity (Workforce Burmout Loop).
Furthermore, reducing time spent on tasks increases the likelihood that the tasks will
require rework (Reduced Task Quality Loop).
Figure 3.2

goo
Moana

Time percewed

maining 4
“m Desied
L- productwiy completion delay
a =
vwoiked
laber,
Eect of schedule
a pressure wi
Sched KR worked,

= Bifect of schedule 7

Lp pressure on tine per
tak : Fatigue onset time ees
Sidi & EY /
/

a Normal

PO sol Actual hateay

Actual hous worked“

weteioe mont?

fe,

Potential ——_

ca ee of fatigne on
—
Effect offatgue on
Worldorce = sevrotke
bamout

ri

Actual time per
tack

Receat i,
worked per month

Project lateness can have many negative affects on an ERP implementation. The longer
it takes to implement the more likely the software will need to be patched or upgraded.
These changes can actually break previously completed work. Sometimes changes are so
drastic that the tasks need to be completely redone. In addition, new work emerges each
time a fix bundle or upgrade occurs (Figure 3.3) and existing customization work often
needs to be reapplied; this is particularly true for full upgrades (Figure 3.4).

Figure 3.3

or reapp

new warh

Discovering cust,
needing rework a

Time to discover
k

feel

Discavering
new work

rework

Time to discover

Discovering

ering customizations tobe
Teno

ng IE

reapplied>

Frequency of
ERP upgrades

Frequency of RP
‘xbundles
ae

Normal neve taske

emerging pertix
bundle

Normal raction
salisfactory

Discovering
rework

ti

1

‘Abandoned
taske

Figure 3.4

“Effect of rainingjon
undiscovered rewark=

Actual
pprouctiviy>

Eliminating Egect ofproject lateness
jacks "on pressure toellininate

<Diseevering
reworle

Effect ofvatigue on

—~undiseevered rewarle
<Effectof ime per
task on undiscovered

Tasks
percetved
complete

Tasks needing

recustemization

Discovering cust
heeding rework or
reapp>
‘Time to discover

oto: aa ‘Unelscovered Custeenizaticns breaking
reapplicetion custonzations to |g 32g fron fivestupgrades
Discdbering be reaped Cage aa A
ctoazafoas to be Customizations j
reaghlied needing reapplication 7 Rew scene of \
“Teeth custemizations needing

f ERP
create Je plea ta agi

“Frequency of ERP Eee
fix bundles» reapplication for Sx bundles
<Discoverng

Ratio of customization customuzations te be

tasks perceived remaning Tape” one
i . ? custonrization rework
cance \ Onions /
& 9 scrccived remaining fe perceived complet ?
hom z ean eae
customization tasks i Completing cartomizahone
customzahon tasks are broken
ros <Hornal fraction
satisfactory? pe
g
Custemizatens
acnally complete
Daisey Customizations iS
Discteng_[elonaben werk Mt —Paresng ray \
customization reworls :
—
Tim to dcover Svatiscovered
rewarl> customizations 10 be
reaprlied>

Project scope never stays constant during a project implementation lifecycle. For various
reasons additional tasks are added to the project plan regularly. As new gaps are
discovered between what the ERP system offers and user community needs,
customization requests are introduced. This also adds complexity in that tasks actually
remaining begin to differ greatly from tasks perceived remaining. Not only does this
disparity include undiscovered rework but approved customizations that have not yet
been given to the technical staff. Furthermore, there may be more customizations in the
requested queue that will eventually be approved.
Figure 3.5

Normal
customization
approval ratio
[Customizations Diesel
rewor
7 sented Tine to review Time to assign
customization tasks Effect
discover gap Denying Fegueate y
ustomizations [a
Tasks
S (Customizations (Customization wl paths
Aedcaing requested [appaing L_apptoved |—assianing ® lemaining
customizations custamizations tasks
<Capbelwoan Eliminating
Pressure to tacts
customize ERP

The intention of ERP systems is that business processes will be redefined to match the
product and not that the product will be customized to meet the existing business
processes. Often the user community is resistant to this type of change and the
adjustment can be extremely challenging. The gap between the product and business
needs will cause pressure to customize the software. By approving customizations user
expectations change and they become even more likely to resist business process change
(Shifting the Burden Archetype).

Figure 3.6
Gap in imbo
waiting for
customization
reduction | “approval
Discovering new via custdhnization
gaps normal
Gap reducing by
v customizing
Gap between ‘Cumulative
S business 7 customizations

Discovering new rovessey = Requesting gap aperaved
&ps reduction via
customization

Business process
modification normal
Gap reducing by

business process

[modification
Time to agree on

‘business process

modification ¥
Effect of gap reduction method
Tasks satisfied on willingness to modify
by business business processes
process
modification aa
Percentage of gap reduction Pressire ta:
accomplished via customize ERP

a

Project lateness introduces rework and new tasks but it may also cause some pressure to
eliminate tasks in an effort to reduce project length and/or cost (Figure 3.7).
Figure 3.7

Completing
tasks

-ssigning
tasks

Eliminating Effect of project lateness
fas on pressure to eliminate

\ ghia [

Task elimination
normal reworl

Model Behavior

In the base run of the model tasks remaining declines over time but customizations
actually increase. Customizations are the tasks that frequently need rework due to fix
bundles and upgrades. As one might expect, actual and perceived tasks remaining differ
fairly significantly. This difference causes incorrect estimation on time and resources

needed to met the implementation deadline.

Figure 3.8

Tasks-Remaining

1,500

1125

750

375

= See SS Se
Ere
PSE

o 4 8 12 6 0 2% 2% 32 36 40 44
‘Time (Month)

‘Tasks perceived remaining : Base ERP

Tasks actually remaining : Base ERP

Customizations perceived remaining : Base ERP

Customizations actually remaining : Base ERP

The nature of customizations, together with project implementation delays, causes
customization rework to slowly increase over time (Figure 3.9).
Figure 3.9

Cust-Tasks- Rework

o 4 8 12 6 220 224 228 32 36 40 44 48 52 56 60 64 68 72
‘Time (Month)

Tasks needing rework : Base ERP tasks/Month
Customizations needing rework : Base ERP tasks/Month

Policy Analysis

Increase Work Hours

In an effort to met project deadlines, management may opt to increase work hours. This
policy change does not have the effect one might expect. Tasks remaining actually
increases (Figure 3.10) over the long term when workforce hours per month is increased
from 160 to 260. This results from a fatigued workforce that is less productive (Figure
3.11) and more apt to produce substandard work (Figure 3.12).
Figure 3.10

Tasks actually remaining

2,000

1,700

1,400

1,100

800
o 4 68 2 6 20 2m 228 2 236 40 44 4 52 56 60 72
Time (Month)
‘Tasks actually remaining : Increase W ork Hours tasks
‘Tasks actually remaining : Base ERP tasks
Figure 3.11
Actual productivity
40
325
5
Fc
175
10
o 4 #8 2 6 20 2m 228 22 3 40 44 48 52 56 60 6 72
‘Time (Month)
Actual productivity : Increase W ork Hours tasks/Month
Actual productivity : Base ERP tasks/Month
Figure 3.12

Effect of fatigue on undiscovered rework

08

o 4 8 2 6 220 224 28 32 3 40
Time (Month)

“a 48

Effect of fatigue on undiscovered rework : Increase Work Hours

Effect of fatigue on undiscovered rework : Base ERP

Decrease Work Hours

Decreasing work hours per month from 160 to 60 increases productivity slightly because
significantly less time is spent on each task (Figure 3.13). Unfortunately, the decrease in

time spent on tasks also decreases task quality (Figure 3.14).

One positive is that

workforce fatigue is lowered, which to some extent positively influences work quality

(Figure 3.15).

Figure 3.13

Actual time per task

200

150

100

0

o 4 8 2 6 20 2& 28 32 36 40
‘Time (Month)

“a 48

Actual time per task : Decrease Work Hours,

hour/(person*task)

Actual time per task : Increase Work Hours,

howrs/(person*task)

‘Actual time per task : Base ERP

hhours/(person* task)
Figure 3.14

Undiscovered rework

200

150

100

50

o 4 #8 2 6 20 22m 28 32 3 40 & 48 52 56 2
Time (Month)
Undiscovered rework : Decrease W ork Hours tasks
Undiscovered rework : Base ERP tasks
Figure 3.15
Effect of fatigue on undiscovered rework
2
1.65
13
0.95
06
o 4 #8 2 6 0 M4 28 32 3 40 44 4&8 52 56 2
‘Time (Month)
Effect of fatique on undiscovered rework : Decrease Work Hours Dm
Effect of fatigue on undiscovered rework : Increase W ork Hours Dm
Effect of fatique on undiscovered rework : Base ERP Dm

Eliminate Customizations

Closing out new customization requests by setting customization approval ratio to 0
instead of 75% slashes the project scope significantly (Figure 3.16). Unfortunately, this
policy is nearly impossible to implement as some customization will be necessary to met
minimum institution requirements. Additionally, the user community is more likely to
accept the system if some effort is made on the technical end to fit the system to better
meet user needs. Nonetheless, customizations must be carefully considered since they
pose an on-going maintenance issue.

Figure 3.16

Tasks actually remaining

2,000

1,650

1,300

o 4 #8 2 UG 20 2M 28 32 2% 40 4 48 52 56 GO 64 G68 72
Time (Month)

Tasks actually remaining : Eliminate Customizations tasks
‘Tasks actually remaining : Base ERP tasks

IV. Conclusions

Project managers should assume a certain percentage of rework when determining time
and resources needed. Having the proper workforce level from the beginning is
particularly important for organizations where the time to adjust workforce is high; this is
often true in the public sector. Controlling the number of customizations approved
during an ERP implementation can have dramatic effects on the implementation
schedule. Allowing the project timeline to slip is particularly dangerous for ERP
implementations because of the fix/upgrade schedule forced by ERP vendors.

Future Research

The current model is exploring causes of scope, time and cost overruns. However, on
time and within budget implementations do not necessarily mean a successful
implementation. If the end result is not well received by the user community or it does
not ultimately provide a retum on investment then an initially successful implementation
can in many ways be perceived as a failure. IT project managers should attempt to
provide an ERP solution that users find valuable and usable, while controlling scope,
costs and timelines. Unfortunately, these can be conflicting goals so the trick is finding
the right balance.

Future extension of this research will include influences from Technology Acceptance
Models (TAM), which are often used to explain why technology is or is not successful.
TAM influenced models (Figure 4.1) clearly point out the relationship between “Client
Trust” and its effect on “Perceived Ease of Use” but do not include many obvious
feedback loops such as the effect of “Perceived Ease of Use” on “Client Trust”.
Figure 4.1 - Research Model Dealing with the Contact Person’s Perspective on
Business Relationships (G efen 2004)

Institution-Based
Mode
(Certification)
Client Trust
(integrity,
Benevolence, and
Ability) Assessment that
the Business
Relationship is
Worthwhile
‘Characteristics-
Based Mode
Perceived
Usefulness
Perceived Ease of
Use
Process Based
Mode

User acceptance and IS success are highly influenced by the user community for which
the ERP system is intended. The earlier a user is involved in the process the more likely
they will ultimately be satisfied with the ERP and the more likely they will actually use
the system.
Figure 4.2: The reformulated model of IS Success (DeL one and McLean, 2003)

INFORMATION
QUALITY
INTENTION | UsE |
TO USE
i
oe
SYSTEM QUALITY Ss NET
mis |
I mz
™d USER | =
. SATISFACTION =
|
SERVICE
QUALITY roa

Expansion of this model will include an ERP Success sector (Figure 4.3); an extension of
TAM and the D&M IS Success Model (Figure 4.2). Additionally, ERP Success could be
expanded to include variables such as cost, organization culture, and top management
attitudes.
Figure 4.3 - ERP Success Model

_ > User trast in ERP

User involvement in vendor
ERP selection

Tntention to use

ERP ERP system use

Net benefits of
ERP system

User involvement in
ERP implementation

User statisfaction

Service quality
Sources

Abdel-Hamid, Tarek, et al. Software Project Dynamics: An Integrated Approach
Prentice-Hall: New Jersey, 1991.

Davenport, Thomas H. “Putting the Enterprise into the Enterprise System” Harvard
Business Review, July-August 1998.

DeLone, W. and McLean, E. “The DeLone and McLean Model of Information Systems
Success: A Ten-Y ear Update” Journal of Management Information Systems, Spring
2003, Vol. 19, No. 4, pp 9 - 30.

Dennis, A, Venkatesh, V, and Ramesh V “Adoption of Collaboration Technologies:
Integrating Technology Acceptance and Collaboration Technology Research”
http://www.indiana.edu/~isdept/research/workingpapers.html, ID TR142-1, (Last updated
February 2004)

Gefen, David, “What Makes an ERP Implementation Relationship Worthwhile: Linking
Trust Mechanisms and ERP Usefulness”, J ournal of Management Information Systems,
Summer 2004, Vol. 21, No. 1, pp 263-288.

Kaiser, K M and King, W R (1982), “The Manager-A nalyst Interface in Systems
Development”, MIS Quarterly, March pp 49-59.

Martin, M.H. (1998) “An ERP Strategy”, Fortune, February 1998, pp. 95-97

Peterson, S (2003), “Lost Signals: How Poor Communication and Other Nontechnical
Issues Hampered Arkansas’ Innovative Statewide ERP Implementation”, Government
Technology, February.

Richardson, George, Modelling for Management: Simulation in Support of Systems
Thinking, The International Library of Management. Aldershot, U.K.: Dartmouth
Publishing Company, 1996.

Senn, J A (1978), “A Management View of Systems Analysts: Failures and
Shortcomings”, MIS Quarterly, September pp 25-32.

Shanks, G. et al. (2000) Differences in Critical Success Factors in ERP Systems
Implementation in Australia and China: a Cultural Analysis, European Conference on
Information Systems

Shih, Hung-Pin, Extended Technology Acceptance Model of Internet Utilization
Behavior, Information & Management, Volume 41, Issue 6, July 2004, Pages 719-729

Skok, W. et al (2001) Potential Impact of Cultural Differences on Enterprise Resource
Planning (ERP) Projects, The Electronic Journal on Information Systems in Developing
Countries
Tapp, R M, Hesseldenz, J and Kelley, G (2003), “The Role of Project Acceptance in the
Successful PeopleSoft Human Resources Management System Implementation for the
Kentucky Community an Technical College System”, Ninth Americas Conference on
Information Systems, pp 1380-1388

Taylor, S. and Todd, P.A. “Understanding Information Technology Usage: A Test of
Competing Models” Information Systems Research, (2001), Vol. 6, No. 2, pp. 144-176

Venkatesh, V and Davis, F. “A Theoretical Extension of the Technology Acceptance
Model: Four Longitudinal Field Studies” Management Science, Vol. 46, No. 2, Feb 2000,
pp. 186-204

Venkatesh, V, Morris, M, Davis G and Davis F. “User Acceptance of Information
Technology: Toward a Unified View” MIS Quarterly, Vol. 27, No. 3, September 2003

Vitale, M R (1986), “The Growing Risks of Information Systems Success”, MIS
Quarterly, December pp 327-334.

Wysocki, Jr., Berard, "Pulling the Plug: Some Firms, Let Down By Costly Computers
Opt to "De-Engineer"" The Wall Street Journal, April, 30, 1998.

Zhang, Liang (2002) “Critical Success Factors of Enterprise Resource Planning Systems
Implementation Success in China”.